GPU 上面塞咗幾個任務，點分先至唔互咬
NVIDIA 喺 10 月 6 日嘅技術博客講明，而家 GPU 應用越嚟越係「一個程式度入面有幾個獨立部件同時跑」：一個講低延遲嘅運算，同埋一個講吞吐嘅背景 kernel；或者數據預處理同模型推理同時用住同一塊卡。以前呢啲任務會互相影響，而開發者冇乜工具可以幫佢哋瓜分資源。
Green Context 做咗乜
簡單講就係俾應用「自己揀」用邊啲 GPU 執行資源，再將工作直接送到呢啲資源。傳統 CUDA context 唔係為呢個用法而設——佢地笨重、有 hardware context-switch 嘅開銷，而且係基於早年「GPU 細、一個程式就係一個主負載」嘅假設。Green context 就輕得多，建立同銷毀都唔會隱式同步無關嘅 GPU 工作。
兩條線：SM 分區同 workqueue 配置
主要用途之一係 SM 分區：你可以將特定一組 SM（Streaming Multiprocessor，即 GPU 嘅基本運算單元）指給某個 green context，由嗰個 context 送出嘅工作就會被送到呢啲 SM，令多個任務並行跑而唔互相搶。
另一條線係 workqueue 配置。傳統做法入面，兩個獨立 stream 可能映射到同一個底層 workqueue，造成本應並行嘅工作被意外序列化，即使用户明明有足夠資源。Green context 可以明確 provision workqueue，減少呢啲假依賴。
點樣由 Driver API 行到 Runtime API
Green context 早喺 CUDA 12.4 已經喺 Driver API 有提供；到 CUDA 13.1 先延伸至 Runtime API。喺 Runtime API，綠上下文以 cudaExecutionContext_t 類型表示；cudaGreenCtxCreate() 回傳嘅句柄可以直接傳入 cudaExecutionCtxStreamCreate() 等 API，唔使再依賴隱式嘅 thread-local 裝置或 context 狀態。
對用家嘅意思
呢個係低層排程機制，唔係預設「開箱即用」嘅應用層功能。如果佢哋嘅工作流真係要喺同一塊卡跑低延遲同高吞吐兩類負載，開發者需要喺程式度級別顯式建立同綁定 green context。文中有代碼片段，但未帶完整錯誤檢查，文中亦提醒生產環境必須檢查每個 API 回傳值。
模姐驗嚇貨
呢度冇跑分、冇實測，亦冇獨立第三方驗證；NVIDIA 自己嘅技術博客講自己嘅排程機制，係廠商自評材料，唔同於獨立評測。Green context 喺實際部署下嘅效能改善，仍要跟住後續嘅獨立測試先至有譜。
（本圖為示意圖）
模姐｜深度調教
