OpScale 把 LLM 擴縮單位拆至算子，Qwen2 服務平均少用 35%至50% GPU

LLM 服務通常以完整模型副本作為自動擴縮單位，但載入 70B 級權重需時約十秒，難以追上秒級流量尖峰；而且 attention、線性投影、正規化與 MoE 算子對 batch、序列長度及記憶體的敏感度並不相同。新系統 OpScale 因此把模型視為算子 DAG，只複製或縮減當前限制 TTFT、TBT 的節點。

系統先離線量度每類算子的執行時間、權重與暫存記憶體、通訊量，以及分配不同 SM 比例時的效能。線上控制器再以毫秒級貪婪演算法調整 batch、算子副本、張量平行切分與裝置位置；其估算資源成本距離暴力搜尋 oracle 不超過 8%。實體放置則把 HBM、SM、NVLink／InfiniBand 通訊及共置干擾納入 best-fit packing。執行層使用 [CUDA Green Contexts](https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__GREEN__CONTEXTS.html) 劃分 SM，並以可重用 stream、動態 KV 記憶體與 shortest-queue routing 接通算子副本。

研究團隊在 [nano-vLLM](https://github.com/GeeeekExplorer/nano-vllm) 上改寫約 17,000 行 Python，以 Qwen2-7B、Qwen2-57B-A14B 和生產流量軌跡測試。密集模型平均使用 7.1 張 GPU，對照系統為 11.2至14.3 張，SLO 達成率為 98.4%，基線則為 88%至95%；MoE 模型平均使用 10.8 張，SLO 達成率為 98.1%。單算子擴容平均只需 0.03 秒，即使同時擴充全部算子，P99 仍低於 0.45 秒；模型級擴容平均為 10.68 秒。固定 SLO 下，GPU 最多減少 36.3%，叢集功耗降低 14%至28%。

這項結果把服務彈性由「多開一個模型」改成資料流排程問題，對混合模型與短促 coding 流量尤其有吸引力。不過比較是在共同 nano-vLLM 後端重現其他擴縮策略，並非直接部署各系統原生版本；收益也仰賴高速互連與 GPU 空間切分，作者承認 GB200 NVL domain 的增益較大。更重要的是 OpScale 本身尚未釋出，工程團隊仍無法驗證 17,000 行原型、故障復原及多租戶隔離成本。