OpScale、LLMのスケーリング単位を演算子レベルに分解、Qwen2サービスのGPU使用量を平均35～50％削減

LLMサービスでは通常、完全なモデルレプリカをオートスケーリングの単位とする。しかし、70Bクラスの重みのロードには約10秒かかるため、秒単位のトラフィックスパイクに追従するのは難しい。また、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、および本番トラフィックのトレースを用いて評価した。denseモデルのGPU使用数は平均7.1基で、比較システムの11.2～14.3基を下回った。SLO達成率は98.4％で、ベースラインは88～95％だった。MoEモデルでは平均10.8基のGPUを使用し、SLO達成率は98.1％だった。単一演算子のスケールアウトに要する時間は平均わずか0.03秒で、全演算子を同時にスケールアウトした場合でもP99は0.45秒未満だった。一方、モデル単位のスケールアウトには平均10.68秒を要した。SLOを固定した条件では、GPU数を最大36.3％削減し、クラスタの消費電力を14～28％低減した。

この結果は、サービスの弾力性を「モデルをもう1つ立ち上げる」という方式から、データフローのスケジューリング問題へと転換するものであり、モデルが混在する環境や、短時間に集中するcodingトラフィックには特に魅力的だ。ただし、比較では共通のnano-vLLMバックエンド上に他のスケーリング戦略を再現しており、各システムのネイティブ版を直接デプロイしたわけではない。また、効果は高速インターコネクトとGPU空間分割にも依存しており、著者らはGB200 NVL domainでの改善幅がより大きいことを認めている。さらに重要なのは、OpScale自体がまだ公開されておらず、エンジニアリングチームが17,000行のプロトタイプ、障害復旧、マルチテナント分離に伴うコストを依然として検証できない点だ。