LLM推論課題の入口
今年のAI側で出ている名前
メモ上では、2026年AI側の議論に次の名前が出ています。
| 名前 | 何か | 現時点の扱い |
|---|---|---|
| Qwen | Alibaba/QwenチームのLLMシリーズ | 公式モデルカードあり |
| Qwen3-235B-A22B | 総235B、活性化22BのMoEモデル | 公式モデルカードあり |
| SGLang | 高スループット・低レイテンシ向けLLM serving framework | 公式ドキュメントあり |
| Dynamo | NVIDIAの分散推論serving framework | 公式ドキュメントとGitHubあり |
| PD disaggregation | prefillとdecodeを別workerに分ける推論構成 | SGLang/Dynamoに公式説明あり |
Qwen3-235B-A22B
Qwen3-235B-A22BのHugging Faceモデルカードでは、主な仕様が次のように説明されています。
| 項目 | 内容 |
|---|---|
| 種類 | Causal Language Model |
| パラメータ数 | 総235B、活性化22B |
| 層数 | 94 |
| Attention heads | Q: 64、KV: 4 |
| Experts | 128 |
| Activated experts | 8 |
| Context length | native 32,768 tokens、YaRNで131,072 tokens |
| ライセンス | Apache-2.0 |
MoEなので、全パラメータを毎token使うわけではありません。ただし、重みはGPUメモリ上に載せる必要があるため、active parametersだけで必要VRAMを見積もると失敗します。
SGLang
SGLang公式ドキュメントでは、SGLangは大規模言語モデルとマルチモーダルモデル向けの高性能serving frameworkと説明されています。特徴として、RadixAttention、prefix caching、multi-GPU parallelismなどが挙げられています。
2025年大会のAI側では、DeepSeek-R1 671BをSGLangで推論する課題だったことが公式発表で確認できます。
Dynamo
NVIDIA Dynamoは、分散LLM servingのためのframeworkです。メモ上では、Dynamoのbenchmarksとrecipes/qwen3-235b-a22b-fp8が2026年AI側の参考として示されています。
ただし、該当recipeのREADMEはTensorRT-LLM向けと説明しているため、SGLang課題とどう関係するのかは大会運営への確認が必要です。
推論の2段階: prefillとdecode
LLM推論は大きく2段階に分かれます。
| 段階 | 何をするか | 性能特性 |
|---|---|---|
| prefill | 入力prompt全体を処理し、KV cacheを作る | 計算量が大きい。長い入力で重くなる |
| decode | 1 tokenずつ次tokenを生成する | メモリ帯域、KV cacheアクセス、batchingが効く |
SGLangのPD Disaggregationドキュメントも、prefillは計算集約、decodeはKV cache管理を伴うメモリ集約と説明しています。
continuous batchingとKV cache
concurrencyを上げるとは、複数requestを同時に投げ、serving engine側で並行処理させることです。ただし、GPU上で完全に別々の処理を8本走らせるという意味ではありません。
SGLangやvLLMのようなserving engineでは、schedulerがrequest queueから実行対象を選び、prefill/decode単位でbatch化し、GPUへまとめてforwardします。このときrequestごとの途中状態はKV cacheとして管理されます。
押さえる語彙:
| 用語 | 意味 |
|---|---|
| request queue | まだ処理待ちのrequestを置く場所 |
| scheduler | 次にどのrequestを処理するか決める部分 |
| continuous batching | decode中でも新しいrequestを取り込み、GPUを空けにくくする処理方式 |
| KV cache manager | requestごとのKV cache領域を管理する部分 |
| paged attention | KV cacheをblock単位で管理し、メモリを効率よく使う考え方 |
concurrencyを上げると総throughputは伸びやすい一方、TTFTやtail latencyが悪化することがあります。チームのQwen3-30B初期測定でも、concurrency 8ではoutput TPSが伸びる一方でTTFT p50とP99 latencyが悪化しました。