GPU Flight — System Architecture

The previous post was about thread divergence at the SASS level. Before I move on to other optimization strategies, I think it makes sense to first review GPU Flight’s architecture. Understanding the overall structure will make the upcoming topics easier to follow, and it should also be helpful for anyone trying to run the full system locally or in the cloud. In this post, I want to step back and show the bigger picture: what each component does, why I separated them this way, and what kind of deployment setup makes the most sense in production. The Big Picture This is how all the components fit together:  In short: gpufl-client — runs on the GPU machine, hooks into CUDA activity, and writes structured logs gpufl-agent — watches those logs and sends them to the backend through HTTP or Kafka gpufl-backend — receives the events, stores them, and provides APIs for querying gpufl-front — React UI for bro