快手万擎大模型、推論コストと性能の全链路最適化手法を公開

快手技術 2026-07-31 15:07 北京

本稿では、快手万擎（ワンチン）が並列戦略、PD 分離、KV キャッシュ、投機型デコーディング、そしてスケジューリングシステムにおいて行った全体的な最適化手法について解説します。

大規模モデルの能力が急速に向上した現在、その実用化を決定づけるのはもはやパラメータ数やベンチマークスコアだけではありません。重要なのは、高並行処理、長いコンテキスト、複雑な Agent シナリオといった過酷な環境下でも、低遅延・低コストで安定したトークンサービスを提供できるかという点です。オンラインビジネスにおいて、推論最適化とは単に「モデルを速く動かす」ことではありません。モデルの能力を損なわずに、トークンあたりのコストを下げつつスループットを向上させ、TTFT（First Token Time）や TPOT（Time Per Output Token）といったサービス品質指標を維持することこそが目的です。

本記事では、GLM-5.2 や DeepSeek-V4 などのモデルにおける推論最適化の実際の取り組みを紹介し、快手万擎が並列戦略、PD 分離、KV キャッシュ、投機型デコーディング、スケジューリングシステムで実現した全体的な最適化手法について解説します。

一、推論最適化：大規模モデルの実用化における鍵

大規模モデルが「能力検証」の段階から「実用的な展開」へと移行するにつれ、システムの関心は「タスクをこなせるか」から「安定して低コストでビジネスを支えられるか」へとシフトしています。トレーニングがモデルの性能上限を決める一方で、推論はスループット、遅延、そしてトークンあたりのコストに直結します。つまり、推論こそがモデルの能力を実際の製品価値に変換する重要なプロセスなのです。

従来のインターネットコンテンツのように複製・配布・キャッシュが容易な大規模モデルとは異なり、推論ではリクエストごとに継続的な計算が必要となり、GPU リソースを占有し続けます。さらに、Agent による多段階の計画やツール呼び出し、百万トークン単位の長いコンテキスト、そして長大な推論出力はトークン消費量を急増させ、コスト、スループット、遅延が実用化における最大の制約要因となっています。

そこで重要なのは、モデルの能力を維持したまま、トークンあたりのコストを下げ、限られた計算リソースでスループットを最大化し、TTFT や TPOT などの指標を安定して満たすことです。快手システムソフトウェアは GLM-5.2 や DeepSeek-V4 といった次世代モデルを対象に、並列実行、オペレーターと通信の最適化、KV Cache の管理、量子化、スケジューリング、そして弾力的なサービス提供など多角的な観点から全体的な最適化を進め、コストパフォーマンスの高い推論ソリューションを構築しています。

二、モデル性能の低下を許さない最適化

推論サービスの価値は、トークン単価だけで測れるものではありません。過度な量子化や精度の切り捨て、推論パラメータの調整はコスト削減に寄与する一方で、複雑な推論能力、ツール呼び出し、長いコンテキストの処理といった重要な機能を損なうリスクがあります。したがって、私たちが目指すのは絶対的な低価格ではなく、「モデルの性能をほぼ維持したまま、トークンあたりのコストを下げる」ことです。

「快手万擎」大模型平台的对外推理服务官方提供者は、快手技術の商業化ブランドである StreamLake です。今回紹介する推論エンジン kLLM は、並列実行、PD 弾性、階層型 KV キャッシュ、演算子とコンパイラ最適化などの機能を備え、高性能かつ低コストな推論サービスを支える基盤システムです。

OpenRouter の AutoExacto ベンチマークにおける Provider 間の能力比較は、スクリーンショット時点での 32 日間の移動平均値です。新バージョンの TAU-Bench では大幅な改善が見込まれており、データ更新後はさらに数値が向上する見込みです。出典：OpenRouter

Prompt Cache を考慮した実際のトークン価格は、スクリーンショット時点での 30 日間の移動平均値です。出典：OpenRouter

図に示す通り、OpenRouter 上での同モデル Provider 比較において、StreamLake の GPQA Diamond および TAU-Bench Airline の結果は、モデル公式および他の主要な Provider と同等の水準を維持しています。さらに、Prompt Cache を適用した場合でも、競争力のある実質的なトークン価格を実現できています。これらの公開データから明らかなのは、低価格化のためにモデル性能を犠牲にしたわけではないということです。むしろ、システムレベルでの推論最適化を通じて、性能とコストの両立を図っています。

三、モデル構造の進化と推論における課題

GLM-5.2 や DeepSeek-V4 に代表される次世代大規模言語モデルは、単にパラメータ数を拡大するだけでなく、巨量パラメータとスパース活性化、スパース/圧縮アテンション、そして百万レベルのコンテキスト長という 3 つの方向へ同時に進化を遂げています。このモデル構造の変化は、理論上の計算コストやストレージコストを下げる一方で、推論システムの実行形態そのものも変えています。

次世代モデル構造の進化と推論システムが直面する課題

システム全体の視点から見ると、これらの構造進化は単に推論コストを削減するだけでなく、モデル側の理論コストを下げる一方で、計算・通信・メモリ・スケジューリングの負荷を再配分しています。具体的には以下の通りです。

まず、膨大なパラメータ数とスパースな活性化により、モデルは総パラメータ数を増やして容量を拡大しつつ、1トークンあたりのアクティブ化パラメータ比率を低く抑えることが可能になります。ただし、動的なエキスパートルーティングの導入に伴い、エキスパート間の負荷偏り、小行列計算の増加、およびカード間での All-to-All 通信オーバーヘッドといった課題も生じます。

次に、スパースアテンションと百万トークン単位のコンテキスト長は、長文シーケンスにおけるアテンション計算コストを理論上大幅に削減しますが、超長文コンテキストでは依然として、長い Prefill 処理、KV キャッシュの容量圧力、不規則なメモリアクセス、およびデータ転送負荷が顕著に増大します。

これらの要因により生じる推論上の課題は、「モデル側のコスト削減＝システム全体の効率化」とはならない点です。推論のボトルネックは単なる計算能力の問題から、計算・通信・メモリ・スケジューリングが相互に絡み合うシステム全体の問題へと変化しました。システム側では、スループットとリソース利用率の向上を図りつつ、TTFT（First Token Time）、TPOT（Time Per Output Token）、および尾遅延（Tail Latency）といったサービス品質目標も満たす必要があります。最終的には、モデル構造が持つ理論的なメリットを、実際のスループット、応答時間、そして 1 トークンあたりのコスト削減という形で実現することが求められます。

四、中核技術の全体像

過去2年間、クワショウ（快手）のシステムソフトウェアチームは推論エンジン「kLLM」の構築に注力し、長年培ってきたシステムレベルのパフォーマンス最適化手法を大規模モデルの推論領域へ展開しました。大規模モデル時代において極限のパフォーマンス追求を続け、クワショウ万擎（Wanqing）向けに高性能・低コスト・高品質な大規模モデル推論エンジンを提供し、業界全体に対して高可用性・低遅延・高精度なトークン生成を安定的に供給することを目指しています。

システムソフトウェア推論エンジン kLLM は、ビジネス接入からスケジューリング、推論エンジン、ハードウェアリソースに至るまでの全チェーンをカバーする高性能推論プラットフォームです。その中核となるエンジン層では、PD（Prefill/Decode）の分離・解耦、TP/PP/EP/CP を含む多次元並列戦略、DeepEP/Mooncake による効率的な異種通信、FlashAttention-4/FlashInfer といった高性能演算子、L1 GPU/L2 CPU/L3 Remote の 3 段階 KV キャッシュ体系、FP8/INT8/NVFP4 を活用した多精度量子化圧縮、MTP/EAGLE-3/DSpark による投機的デコーディングなどの主要技術を統合しています。これにより、超長文コンテキストと MoE（Mixture of Experts）大規模モデルに対する高スループット・低遅延・高並列推論を実現しました。

さらに、SLO（Service Level Objective）を認識したスケジューリング、Prefix 親和性に基づくルーティング、弾力的なリソース拡張、全チェーンにわたる Metrics/Trace モニタリング、およびグレーデッドフェールオーバー（段階的低下）メカニズムによって生産環境の安定性を担保し、国内 GPU およびネットワークエコシステムとの互換性も確保しています。これにより、社内・社外を問わず多様なビジネスシーンでの高効率なサービス提供を支えています。

クワショウシステムソフトウェア大規模モデル推論フレームワーク kLLM の全体アーキテクチャ

五、中核技術の突破と実装

2025 年に DeepSeek R1 が発表された際、私たちは独自開発した時間分割 PD 分離、DeepEP Auto 通信モード（Prefill は Normal モード、Decode は Low Latency モード）、精度損失のない FP8 KV キャッシュ、およびスケジューリング最適化などの技術を導入しました。テストセット、ハードウェア機種、キャッシュヒット率、そして TTFT や TPOT の制約条件を厳密に一致させた条件下で、業界最高水準のトークン推論コストを実現することができました。

今年に入り、これらの関連能力はさらに GLM、DeepSeek、KIMI などの次世代モデルへ拡張され、モデル適応・推論エンジン・分散実行・キャッシュ管理・スケジューリングを網羅するフルスタック最適化体制が整いました。これにより、複数の主要モデルに対する大規模なオンライン展開も完了しています。以下にその代表的な最適化技術をいくつか紹介します。

5.1 MLA と DP を組み合わせたアテンション：Attention のデータ並列と MoE のエキスパート並列のハイブリッド

5.1.1 単一トークンのコスト削減から、ノード全体の有効 KV キャパシティへの拡張

百万レベルの長文コンテキストにおいて、Attention の計算量と KV Cache の使用量は文脈長に応じて急増します。GLM-5.2 では、DSA（Dynamic Selective Attention）を用いて履歴コンテキストから Top-k トークンを選別して Attention 計算に用いることで計算量を削減し、さらに MLA（Multi-head Latent Attention）の圧縮表現 cKV を活用することで、1 トークンあたりのキャッシュコストを低減しています。

しかし、DSA と MLA は主に計算量と単一トークンの KV サイズの最適化に焦点を当てており、マルチカード環境における状態分布の問題までは解決していません。文脈長や同時実行数が増加し続ける中で、ボトルネックは次第に「ノード内の複数 GPU が、有効な KV キャパシティをどのように共同で拡張できるか」という点へと移っていきます。

5.1.2 純粋な TP：Attention の計算は分割されるが、cKV は複製されてしまう

GQA（Grouped Query Attention）では複数の独立した KV Head を持ち、これを Head 次元に沿って TP（Tensor Parallelism）で分割することが可能です。一方、MLA の cKV は Head を跨いで共有される圧縮状態であるため、同じ方法での分割はできません。

そのため、Attention に従来の TP Group をそのまま適用すると、各 Rank が計算を分担する一方で、同一の要求に対して同じ cKV を処理・保存する必要が生じます。TP=8 の場合、同じリクエストの KV Cache がノード内で 8 回複製されることになります。GPU を増やしても計算能力は拡張されますが、有効な KV キャパシティは同比例には向上しません。

長文コンテキストかつ高同時実行の環境では、システムにまだ余力があるにもかかわらず、KV Cache の容量不足によってバッチサイズを拡大できず、新しいリクエストを受け付けられない事態が発生します。この時点で、真のボトルネックは Attention の計算能力から、TP Group 内で重複して保存されている要求状態へと移っています。

5.1.3 並列戦略の再構築：Attention は「リクエスト単位」で、MoE は「エキスパート単位」で並列化

MLA と MoE は構造が異なるため、モデル全体を単純に DP（Data Parallelism）へ切り替えるのではなく、Attention と MoE の間の並列境界を再定義しました。

Attention には Request DP を採用します。各 Rank が異なるリクエストを担当し、自らが担当するリクエストの cKV、トークン履歴、インデックス状態のみを保持します。これにより、Attention 処理中に DP Rank 間で結果を同期する必要はなくなります。

MoE には EP（Expert Parallelism）を採用します。Router が各トークンに対して Top-k のエキスパートを選択し、All-to-All Dispatch を用いてトークンを該当するエキスパートが配置された Rank に転送します。エキスパートによる計算完了後、All-to-All Combine で結果を元の要求担当 Rank へ返却します。

Dense/Shared FFN（Fully Connected Network）については、必要に応じて TP を維持します。非ルーティング計算もモデル次元で分割する場合、対応するサブパスでのみ Gather/Reduce-Scatter を実行し、EP の Dispatch/Combine と通信経路を混在させません。

重要なのは、一つの並列方式でモデル全体を覆い尽くすことではなく、異なる状態データがそれぞれ最適な分布方法に従うようにすることです。

MLA 環境における、Attention の DP と MoE の EP を組み合わせた並列境界の再構築

Attention の計算を TP8 から Request DP8 へ変更し、各 GPU は自身が担当するリクエストの cKV だけを保持します。MoE については引き続き EP8 を採用し、All-to-All Dispatch/Combine によってトークンと専門家（エキスパート）間のルーティングを行います。

5.1.4 効果と適用範囲

図 8 の 8 GPU 構成において、DP Attention を導入することで各 GPU が異なるリクエストの cKV を分散保存できるようになり、ノードあたりの有効 KV 容量は純粋な TP 構成時の 290 万トークンから 2120 万トークンへと約 7.3 倍に増加しました。これにより平均 TTFT は 25% 低下しています。

最適化後のシステムボトルネックは、TP グループ内での KV の複製から、Request DP における負荷分散や EP 段階の専門家負荷、そして All-to-All 通信へと移行します。したがって、DP Attention は長文コンテキスト、大規模バッチ処理、および KV キャッシュ容量が制限される高スループットなユースケースに特に適しています。一方、小規模バッチや低同時実行環境では、データレイアウトの変換コストや EP 通信によるオーバーヘッドがメリットを相殺する可能性があるため、実際の負荷特性とクラスター間の通信能力を踏まえて選択する必要があります。

5.2 Ring Attention：同期集約から分块パイプラインへ

5.2.1 百万トークンコンテキストにおける CP の拡張

コンテキスト長が 20 万トークンから 100 万トークンに拡大すると、KV キャッシュ容量はシーケンス長に比例して増加し、Prefill 段階での Attention 計算量とメモリ負荷も急激に高まります。百万トークン規模の超長文コンテキストをサポートするために、まず Context Parallelism（CP）を導入しました。これにより、シーケンス次元に沿ってコンテキストトークンを複数の CP ランクに分割し、各 GPU は一部の Query を処理するとともに対応する KV の断片を保持します。これによって、単一の GPU では処理しきれないリクエストを複数 GPU で分散実行することが可能になります。

しかし、シーケンスの分割だけでは KV キャッシュの基本的な配置問題しか解決できません。各ランクがローカルの Query を用いて、利用可能なすべての K/V に対して Attention 計算を実行できるかが、CP の実際のメモリ使用量と実行効率を決定します。

5.2.2 ブロック単位 Ring Attention の実装

推論エンジン内の CP 実行パスにおいて、ブロック単位の Ring Attention を実装しました。CP ランクにおいては、ローカルの Query は計算全体を通じて固定されたままです。一方、ローカルの KV 断片は他のランクの KV ブロックと共にリングトポロジー上を順次転送されます。各ラウンドで GPU は現在の KV ブロックを用いてブロック Attention の一部を計算すると同時に、次のラウンド用の KV ブロックを非同期で受信します。計算が終了したら、すでに到着している次のブロックへ即座に切り替えます。

N 回のラウンドを経ることで、すべてのランクが有効な KV ブロック全体に対する Attention 計算を完了し、KV の断片もリング上を一周して元の位置に戻ります。

Ring Attention におけるシーケンス分割とリング計算の仕組み

分块計算において、完全な Attention と同じ数値結果を維持するために、Online Softmax を用いて各ラウンドで最大値、正規化の分母、出力の累積状態を跨いで管理します。KV Block を一つ処理するたびに局部状態を更新し、すべての有効な Block の処理が完了すれば、ローカル Query に対する最終出力が得られます。これにより、完全な Attention Matrix を物理的に生成する必要はありません。

5.2.3 All-Gather CP との実行経路の比較

従来の All-Gather CP では、各層の Attention 計算の前に、まず各 Rank の KV 分片を全 GPU に集約します。最終的には各 GPU がローカル Query に対応する出力のみを計算しますが、その層が実行されている間は完全な K/V を一時的に生成する必要があり、All-Gather の完了を待ってからでないと Attention の処理を開始できません。

Ring Attention は Attention の数学的な結果を変えるものではなく、K/V の組織方法と通信のタイミングを変更するものです。各 GPU はローカルの KV 分片と単一の通信バッファのみを保持し、一度きりの全量同期・集約を連続したブロック転送に分解します。これにより、Block Attention と連携してパイプライン処理を実現します。

Ring Attention は、VRAM の節約や通信と計算の重なりにおいて相対的に有利です。詳細な比較は以下の通りです。

All-Gather CP と Ring Attention の実行経路比較

5.2.4 実際の効果

検証結果によると、同じモデル、バッチサイズ、CP Degree、KV 精度、ハードウェア構成において、ISL が 512K の場合、Ring Attention CP は All-Gather CP に比べてスループットが 16.9% 向上しました。

5.3 DSpark：最先端アーキテクチャからオンラインでの収益へ

5.3.1 主要なスペキュレーション・デコーディング・アーキテクチャのパフォーマンスのトレードオフ

スペキュレーション・デコーディングは、単一のドラフトモデル同士の競争から、ドラフト生成、ターゲット検証、ハードウェアスケジューリングを連携させたシステム全体の最適化へと進化しています。DeepSeek V4 Flash の推論レイテンシ最適化を中心に、Eagle3、DFlash、DSpark といった技術動向を追跡し続けています。オフラインでの受容率だけを唯一の選定指標とするのではなく、ドラフトの遅延、受容長さ、そして動的負荷下における検証コストも同時に評価しています。

Eagle3 と DFlash はそれぞれ、自己回帰型と並列ドラフト型の両極端を代表します。前者はモデル化が十分ですが、推測長が増えるほどドラフトのコストが高くなります。後者は一度にブロック単位の候補を生成するため遅延が低く済みますが、サフィックス（末尾）の品質が低下しやすいという課題があります。DSpark は半自己回帰構造によって両者の間に新たなバランスを生み出し、さらに信頼度に基づくスケジューリングでターゲットモデルの検証コストを制御します。これは長文入力を扱うオンラインサービスのコスト構造に合致しています。

主流投机解码アーキテクチャの、ドラフト遅延、受容長、検証オーバーヘッドにおける性能特性。位置は定性的な示唆です。

5.3.2 ドラフトモデルから完全デコードチェーンへ

DSpark はまず並列ネットワークで複数のトークン位置のロジットを一度に生成し、その後軽量シーケンスモジュールが各位置ごとにサンプリングを実行します。各位置では、サンプリング前に直前のサンプリング済みトークンに基づいてバイアスを計算し、現在の位置のロジットを修正します。このシリアルの部分はバイアス修正とサンプリングのみを行い、完全なモデル前向き伝播を繰り返す必要がないため、並列ドラフトの低遅延性を維持しつつ、サフィックス（末尾）の品質低下を緩和できます。

DSpark の半自己回帰ドラフト生成の例。並列モジュールが各位置のロジットを一度に生成し、軽量シーケンスモジュールが直前のサンプリングトークンに基づいて現在の位置を修正・サンプリングします。図中の数値は示唆値です。

5.3.3 エンドツーエンドでの性能向上

DeepSeek V4 Flash のオンラインにおける典型的なシナリオでは、ISL（Initial Sequence Length）は約 3K〜6K、OSL（Output Sequence Length）は約 0.5K です。ベースラインと比較して DSpark を導入した結果、平均 TPOT は 15% 低下しました。

5.4 階層型 KV Cache：容量拡張から効率的な再利用へ

5.4.1 L1 の容量制限とキャッシュミス

長文脈のシナリオでは、KV Cache はシーケンス長に比例して増大しますが、GPU メモリにはモデル重みやランタイム状態も保持される必要があります。L1 のみに依存すると、容量不足によりキャッシュが頻繁に淘汰され、システムプロンプト、ツール定義、履歴対話などの重複するプレフィックスを安定して再利用できなくなります。その結果、同種のリクエストでも毎回 Prefix Prefill を再実行する必要が生じます。

プレフィックス KV のライフサイクルを延長し、再利用範囲を広げるため、GPU HBM、CPU DRAM、SSD/分散ストレージからなる 3 段階の KV Cache を構築しました。

5.4.2 階層型キャッシュ、プレフィックス再利用と Cache-Aware ルーティング

3 段階のキャッシュはそれぞれ異なる役割を担います：

L1 · GPU HBM：インスタンス内で最もホットな KV を保存し、ヒットすれば即座に計算に参加します。

L2 · CPU DRAM：L1 から降格されたデータを保持し、インスタンス内での低遅延なリフィルを提供します。

L3 · SSD/分散ストレージ：プレフィックス KV をインスタンス間で共有し、容量やシステム負荷に応じて全データまたは高頻度再利用されるプレフィックスを永続化します。

「万擎」大模型では、最初の Prefill 生成時に作成された Prefix KV を L1 から L2/L3 に格納し、Cache Event を通じてキャッシュ位置を同期します。その後、同じ前缀を持つリクエストはゲートウェイがマッチング長さやキャッシュ位置、負荷状況に基づいて Cache-Aware ルーティングを行います。キャッシュにヒットした場合は KV を L1 に戻し、未命中部分の計算のみを実行すればよいのです。

Chunked Prefill の場合、前回の前缀ツリー状態を再利用して新しいトークンのみを処理するため、完全な前缀を再度スキャンする必要はありません。

L1/L2/L3 階層型 KV Cache と跨インスタンス共有メカニズム

5.4.3 階層型 KV Cache の最適化効果

オンラインの生産環境データを見ると、依然として L1 が主要なヒット流量を担っています。ただし、L1 が容量圧力によりヒット率が低下した際も、L2/L3 が淘汰された Prefix KV を引き受けることで、全体のヒット率を比較的安定して保つことができます。

図示の期間における総ヒット率は平均約 87.6% で、内訳は L1 が約 77.5 ポイント、L2 が約 9.6 ポイント、L3 が約 0.6 ポイントです。もちろん、運用環境や負荷状況によって改善幅は異なりますが、典型的なシナリオでは L3 の導入によりヒット率が最大で 15 ポイント（PP）向上します。L3 を活用することで、ヒット率は理論上の上限に近づきます。

同じモデル・流量・SLO 条件下において、L1 のみのベースラインと比較すると、完全な階層型キャッシュと Cache-Aware ルーティングの導入により、キャッシュヒット率が 20 ポイント向上し、SLO 制約下でのスループットは 30% 増加しました。

5.4.4 前缀ツリーの重要パス最適化

長文入力シーンで階層型キャッシュを有効化した際、前缀関連の処理に深刻なパフォーマンス問題が発生し、明らかな GPU のアイドル（Bubble）が観測されました。フレイムグラフによるホットスポット分析と前缀ツリーソースコードの詳細調査の結果、その根本原因は「全トークン系列を用いた前缀マッチングおよび挿入」を常時実行している点にあることが判明しました。この計算方式は、チャンク化されたリクエストに対して大きな冗長性を生み出します。

例えば、「この前缀は少し長い」という新規リクエストに Prefill を行う場合、ChunkSize が 4 と仮定すると、2 つの Chunk に分割して処理する必要があります：

1. 第 1 ラウンド：前缀をマッチングし、Prefill を実行して前缀ツリーに挿入
2. 第 2 ラウンド：再度全量の前缀でマッチングを行い、全量の前缀を挿入

このため、中間状態のキャッシュを活用した増分前缀マッチング/挿入最適化アルゴリズムを提案し、こうした冗長計算を排除しました。

5.4.5 接頭辞の再利用による最適化効果

最適化を完了後、同じ負荷テストデータセットを用いて再測定した結果、GPU のバブル（アイドル時間）は平均で 400ms から 30ms に劇的に減少しました。また、長文リクエストにおけるプリアフィル（Prefill）のエンドツーエンド性能も約 40% 向上しています。

最適化前：平均バブル 400ms

最適化後：平均バブル 30ms

5.5 PD 分離：固定比率から SLO ドライブへ

PD（Prefill/Decode）の分離により、プリアフィルとデコードのリソースを個別に設定できるようになりました。しかし、本番環境においてより重要なのは、いかにして適切な P/D の比率を継続的に維持するかという点です。

同じ QPS（1 秒間のリクエスト数）でも、入力シーケンス長（ISL）の増加は主にプリアフィルへの負荷を増大させます。一方、出力シーケンス長（OSL）や並行度の増加は、デコード側の容量をより多く消費します。このようにリクエストの形態が常に変化する中で、固定された P/D 比率では対応しきれないのです。

初期段階で採用されていた「固定 xPyD」サービスグループはシンプルで安定していましたが、グループ単位でのスケールアップ・ダウンしかできず、片側がキューイング（待ち行列）する一方で他側が遊んでいるという非効率が発生しやすいという課題がありました。また、インスタンスの起動に数分を要するため、リソース調整が即座に反映されないという問題もありました。

そこで私たちは、PD 分離システムを TTFT（First Token Time：初回トークン到達時間）や TPOT（Time Per Output Token：出力トークンあたりの時間）といった SLO（サービスレベル目標）達成を目指すオンラインリソース制御システムへと進化させました。SLO を通じて両側の負荷状況を感知し、10 秒級でのインスタンス起動と P/D 間のグローバルなリソースプールを組み合わせることで、P/D の容量比率を動的に調整するフィードバックループを実現しています。

キャッシュを考慮した負荷感知型インテリジェントルーティング

5.5.1 SLO Load：P と D の圧力を別々に計測する

GPU 利用率は単にデバイスの繁忙度を示すだけで、それがユーザー体験に悪影響を与えているかどうかまでは判断できません。Prefill（初期生成）と Decode（逐次生成）はそれぞれ TTFT（初回トークン到達時間）と TPOT（トークン間時間）を主に決定するため、両者の SLO からの乖離度を指標として、それぞれの負荷圧力を統合的に計測します。

実際の性能低下を反映する実測値には観測の遅れという課題がありますが、キューの积压状況や実際のサービスレートから算出される予測値は、混雑を事前に察知できる一方で推定誤差が生じる可能性があります。タイミングと信頼性の両立を図るため、ここでは予測値と実測値のいずれか大きい方（上界）を採用します。

SLO で正規化された結果、P と D の両側で統一された負荷スケールが得られました。Load=1 は目標境界に達していることを意味し、Load>1 は該当する処理段階に容量圧力がかかっている状態を示します。

5.5.2 10 秒級起動：スケーリングを確実に追従させる

従来の推論インスタンスの起動では、モデル重みのロード、JIT（Just-In-Time）コンパイル、メモリ初期化、ランタイムのウォームアップが順次行われ、完全なコールドスタートには通常数分かかります。この長い起動時間はトラフィックの変動に即応できず、P と D の比率調整や障害復旧の速度も制限されてしまいます。

そこで、起動のボトルネックとなる主要経路に対して 3 つの最適化を施しました。

• RDMA を利用して稼働中のインスタンスから直接モデル重みをロードし、遠隔ストレージからの重複読み込みを回避する
• JIT キャッシュを共有し、すでに完了したオペレータのコンパイル結果を再利用する
• CUDA VMM（仮想メモリ管理）を活用してメモリレイアウトを流用し、unmap/remap 操作によってメモリの再割り当てと初期化を最小化する

これらの施策により、推論インスタンスの起動時間を約 10 分から 10 秒未満に短縮しました。これにより、P と D のスケーリングが現在の負荷変化に対して即座に反映されるようになりました。

同様に「稼働中のインスタンスから RDMA で重みを配布する」という手法は、コミュニティにおいても迅速な弾力性確保の重要な方向性として定着しつつあります。例えば Dynamo Model Express は、既存ワーカーの GPU メモリから新しいワーカーへモデル重みを転送する機能（Dynamo Model Caching）をサポートしています。

5.5.3 大規模 P/D：固定グループバインドの解除

初期段階では、x 個の P インスタンスと y 個の D インスタンスをセットにして「xPyD」というサービスグループを構成する固定デプロイを採用していました。スケーリングもこの完全なサービスグループ単位で行われていました。

この方式はトポロジーが明確で実装が容易ですが、リソース調整の粒度が実際の負荷変動と一致していませんでした。ISL（入力シーケンス長）、OSL（出力シーケンス長）、および並行度の増加は、まず P 側または D 側のいずれかの圧力を高める傾向がありますが、固定された xPyD グループでは片側だけを独立して調整することができません。

例えば、長い入力テキストのトラフィックが増加した場合、P 側にキューが形成されても D 側にはまだ余裕があるにもかかわらず、P をスケールアップするには xPyD グループ全体を同時に増やす必要がありました。

大 PD アーキテクチャ：固定の xPyD サービスグループから P/D グローバルリソースプールへ

この課題を解決するため、従来の固定 PD グループを「大 PD アーキテクチャ」へと進化させました。P インスタンスと D インスタンスはそれぞれグローバルな Prefill Pool と Decode Pool を構成し、必要に応じて独立してリソースプールへの参加・退出が可能です。各リクエストはもはや事前に設定された PD グループに紐付けられるのではなく、Global Router が P_i と D_j をその都度選択し、リクエスト単位で動的なペアを形成します。

具体的には以下の手順で動作します。

リクエスト到着時：KV キャッシュの状況と負荷分散戦略に基づき、P インスタンスを選択します。

Prefill 完了後：D 側の負荷状況、KV キャストの位置情報、転送コストを総合的に判断し、最適な D インスタンスを選定します。

P と D のインスタンスはライフサイクルが独立しており、それぞれの負荷に応じて個別にスケールアップ・ダウンが可能です。

大 PD アーキテクチャにより、容量調整をボトルネックとなる側に直接行えるようになりました。P 側の負荷が高い場合は Prefill Pool だけを拡張し、D 側の負荷が高い場合は Decode Pool だけを拡張します。これにより、ボトルネックではない側が不必要にスケールアップするのを防ぎつつ、インスタンス単位で P/D の比率を継続的に最適化できます。

5.5.4 最終的な効果

SLO ロードテスト、10 秒級のスループット、そして P/D グローバルリソースプールが組み合わさることで、PD エラスティシティの完全なクローズドループが実現されました。システムは P と D の両側における容量圧力を検知し、単一インスタンス単位で独立したスケールアップ・ダウンを実行します。さらに、追加された容量を 10 秒以内にサービス投入可能としました。従来の約 10 分かかっていたインスタンス起動に比べ、容量有効化の速度は約 60 倍向上しています。

OpenRouter の公開モニタリングデータによると、StreamLake が提供する GLM‑5.2 サービスの過去 30 日間のプロバイダー稼働率は 99% を超えています。

5.6 長文リクエストの安定性最適化

前述した CP と Ring Attention は、超长コンテキストにおける「計算可能な」状態を実現し、推論エンジンに百万トークン単位のコンテキスト処理能力をもたらしました。本節ではさらに、「安定的に運用できる」状態の実現を目指します。実際の業務において、長文入力や長文出力を伴うリクエストの割合は通常 5% に満たないものの、1 つのリクエストが消費する計算時間、KV キャッシュ量、およびリソースの保持時間は通常のケースと比べて格段に大きくなります。これが局所的な渋滞を引き起こし、それがグローバルなキューイングへと拡大することで、主流となるリクエストの TTFT（Time to First Token）を著しく悪化させる要因となります。

この課題に対し、エンジン側とグローバルスケジューリング側の両面から長文リクエスト向けのスケジューリングクローズドループを構築しました。これにより、インスタンス内では単一のリクエストが長期間リソースを独占することを防ぎ、インスタンス間では過負荷ノードへのトラフィック集中を抑制します。

KV Events はキャッシュ状態を、Engine Load はリアルタイムの負荷状況をそれぞれ示します。エンジン側では公平な実行と KV の高水位保護を担当します。

5.6.1 長文入力向けエンジンスケジューリングの改修：Chunk Prefill による公平スケジューリング

長文入力は主に以下の 2 つの経路で TTFT に影響を及ぼします。

Chunk Prefill によるブロック：長文リクエストは複数の Chunk に分割されます。これらが連続して実行されると、後から到着した短文リクエストが数輪にわたって待たされることになり、TTFT が著しく引き伸ばされます。

KV アドミッション（受付）によるブロック：Decode インスタンスでは、各リクエストのために KV スペースを確保する必要があります。残量が不足すると長文リクエストは受付段階で停止し、結果として後続の短文リクエストもブロックされる可能性があります。

そこで、Chunk をスケジューリングの単位とし、KV バジェットに基づいて実行クォータを割り当てる方式を採用しました。1 つの Chunk 内で完結できる短文リクエストは優先的に実行されます。一方、長文リクエストはクォータが尽きた時点で Chunk の境界でリソースを譲り渡し、すでに計算済みのプレフィックス KV は保持したままにします。再度実行機会を得た際は、長文リクエストは中断点から直接再開され、重複計算は不要となります。

長文リクエストが長時間実行されずに待機状態になるのを防ぐため、その回復用クォータはリソース譲渡の回数に応じて段階的に増加させます。これにより、短文リクエストの TTFT（Time to First Token）を保護しつつ、長文リクエストも最終的には確実に完了できるようになります。

チャンクプリフィルにおける公平なスケジューリングメカニズムです。公平性を考慮しない場合、長文リクエスト B が計算資源を連続して占有し、短文リクエスト C や D は第 11 ラウンドまで実行機会を得られません。一方、公平なスケジューリングでは KV（Key-Value）予算に基づいて実行クォータを発行し、チャンクの境界でプレフィックス KV を保存してリソースを譲渡し、断点から復元します。これにより C と D は第 2 ラウンドで完了でき、回復クォータの段階的増加によって B が長期間待機させられる（飢餓状態になる）ことを防ぎます。

最適化効果

既存の混合トラフィックテストでは、公平なスケジューリングにより平均 TTFT は 17.8% 低下し、P50 は 26.0%、P95 は 12.1% それぞれ改善されました。一方、全体としての P99 は 2.7% 上昇しています。これは「短文リクエストを優先して早期に処理し、長文リクエストはわずかに遅らせる」という公平なスケジューリングのトレードオフを反映した結果です。

公平なスケジューリング導入前後の全体 TTFT 分布です。平均値、P50、P90、P95 はそれぞれ 17.82%、25.96%、14.02%、12.10% 低下し、P99 は 2.65% 上昇しました。

5.6.2 長文出力のガバナンス：Decode KV の高水位保護

長文出力リクエストは Decode インスタンスに長時間滞在し、生成プロセスが進むにつれて KV キャッシュの使用量が継続的に増加します。高負荷下では、少数の長文出力が KV Cache を高水位まで押し上げ、新規リクエストの受付を拒否して恒久的な待ち行列を引き起こす可能性があります。これに対処するため、私たちは二層構造の保護策を採用しています。

• スケジューリング側での負荷分散：Decode インスタンスの負荷状況を継続的に監視し、高負荷状態にあるインスタンスへの追加負荷を停止します。既存のリクエストが完了して KV リソースが解放されるまで待機させます。
• エンジン側での保護：KV 使用量が閾値（高水位）に達した場合は新規リクエストの受付を一時停止します。必要に応じて、ループ出力などの異常な長文リクエストが占有している KV を解放し、リソースに余裕のある他のインスタンスへ再スケジューリングします。

公平な実行、状態の可視化、負荷分散、そして高水位保護を通じて、少数の長文リクエストが主流のリクエストの TTFT やシステム全体の安定性に与える影響は、許容範囲内に抑えられています。

六、今後の展開

究極の推論最適化にゴールはありません。既存の全工程における最適化成果を基盤に、チームは計算資源の効率化、国産ハードウェアへの対応、インテリジェントな運用管理（AIOps）の強化に注力し、コストのさらなる削減とサービス能力の上限引き上げを目指します。これにより次世代の推論インフラを構築していく予定です。主な重点方向は以下の 4 つです。

6.1 異種 PD アーキテクチャのアップグレード

従来の同型 PD クラスターでは、Prefill における密集計算と Decode における高帯域メモリアクセスの異なる特性を正確にマッチできず、算力（計算リソース）が浪費される課題がありました。これを解決するため、今後「異種 PD 協調アーキテクチャ」を導入します。

具体的には、高性能な計算リソース（例：国産 GPU など）で Prefill のバッチ前処理タスクを担い、大容量メモリと高帯域を持つ計算リソース（例：NVIDIA GPU など）で Decode の生成タスクを担当する仕組みです。これらを統合した異種算力の統一管理プラットフォームを構築し、トラフィックのインテリジェントな分散と負荷均衡を実現します。さらに、デバイス間通信の最適化や動的なタスク分割機能を強化することで、短・長リクエストの両方への対応や、業務における需要の波（ピーク・バレー）にも柔軟に適応できるようにします。

6.2 Program-Aware 全ライフサイクル调度

调度（スケジューリング）の対象を「単一のリクエスト」から「Program（1 つのエージェントセッションまたはワークフロー）」へと引き上げます。これにより、一時停止と再開の制御、およびツール呼び出し時のリソース空窓における回収を統合的に管理します。これらは本来同じライフサイクルの両面であり、これを一体化して実装します。

核心となるメカニズムは以下の通りです。容量が逼迫した際には「最短プログラム優先」でリソースを解放し、グローバルな BFD（Best Fit Decreasing）アルゴリズムを用いて再配置を行い、リクエスト境界でのアクセス制御を行います。また、エージェントがツールの応答を待機している間に GPU が空いている時間を活用して KV キャッシュのアンロードやプリフェッチを行い、限られたメモリをアクティブな Program に優先的に割り当てる仕組みです。

6.3 SLO 感知调度（リクエストの優先度付け）

マルチテナント環境や複数の業務が混在する状況では、長時間かかるリクエストが短時間のリクエストをブロックし、遅延の尾数値（Tail Latency）を悪化させるリスクがあります。これを防ぐため、「緊急度」に基づく優先度调度を導入します。

Prefill の完了時間を予測し、SLO（サービスレベル目標）の達成率を最大化するリクエストを選択的に実行します。また、遅延に敏感なリクエストに対しては QoS（サービス品質）保護と流量制限を適用します。万擎が運用する多業務共有推論クラスターにおいて、この仕組みは低遅延 SLA を満たす高品質なトークン生成を保証するための鍵となります。

6.4 全栈智能化自适应调优与 Kernel 优化

人手による固定ルールでは対応しきれない柔軟性の欠陥を解消するため、「AI による全栈（フルスタック）智能调优」体系を導入します。強化学習モデルが業務トラフィック、シーケンス特徴、ハードウェア負荷をリアルタイムで感知し、PD の比率調整や弾性閾値、長短トラフィックの调度、CP（Compute Partitioning）分割粒度などを自動的に最適化します。

さらに、時系列予測を用いてホットスポットキャッシュを事前準備し、淘汰戦略を最適化することで、全リンクにおける動的な最適を実現。従来の静的設定に代わり、無人での極限運用を目指します。また、Agentic RL（エージェント型強化学習）で訓練された大規模モデルが Kernel オペレーターを生成する手法についても、重点的な研究対象として取り組んでいきます。

七、まとめ

本稿では、GLM‑5.2 や DeepSeek‑V4 といった次世代大規模言語モデルを対象に、並列実行、ランタイム调度、KV Cache、オペレーターコンパイル、量子化、投機デコーディングを網羅する全栈推論最適化体系を構築しました。

Ring Attention、DP Attention + EP、大規模 PD、階層型 KV Cache、DSpark などの技術を軸に、SLO 感知调度や弾性スケーリング、長短リクエストのガバナンスを組み合わせることで、長文コンテキスト、動的負荷、大規模展開における計算・通信・メモリ容量のボトルネックを体系的に緩和します。モデル構造とシステムエンジニアリングの協調最適化を通じて、モデル側で理論的なコスト削減を実現し、実際のスループット、レイテンシ、リソース利用率、およびトークン単価のコストメリットへと変換しました。これは、大規模言語モデルサービスのスケールアウト展開に向けた、汎用性の高いエンジニアリング実践です。

私たちについて

システムソフトウェアセンターは、当社の中核となる技術エンジンであり、従来のソフトウェアと大規模モデルソフトウェアをつなぐ重要な層です。最先端の計算リソースと最新ソフトウェア体系を有しています。チームは JVM/JDK、コンパイラ、ビルドシステムといった伝統的なシステムソフトウェアのコア能力に深く取り組む一方で、AI Infra として大規模モデルのトレーニング・推論エンジンも全面的に構築し、社内各事業ラインに対して高速、安定、拡張性があり、低コストな大規模モデルトレーニングと推論サービスを提供しています。

AI Infra の方向性

AI Infra トレーニング・推論エンジンチームは、当社の基盤モデルと MaaS（Model as a Service）プラットフォームの中核エンジンを支えています。業界をリードする大規模モデルのトレーニングおよび推論インフラストラクチャの実現を目指しています。

チームは独自に SFT/RL 訓練フレームワークを開発・最適化し、新モデルや訓練パラダイムへの迅速な適応を実現。極限の計算効率とイテレーション速度で、アルゴリズムチームがモデル性能の限界を探求するのを支えます。また、推論エンジン、调度、運用体系を深く最適化し、プラットフォーム上の多様なモデルが、より低コストで、より高速に、高性能で、多数のユーザーにサービスを提供できるようにしています。これにより、「大規模モデルを使えるようになり、かつ使いこなせる」環境を実現します。

AI インフラのトレーニング・推論エンジンチームに参加すれば、PD 分離や KV Cache の移行、マルチモーダル性能など最先端のアーキテクチャに深く入り込み、技術的な課題を解決できます。次世代の計算リソースを活用し、オペレーターの最適化、量子化、通信の重なり処理を通じてハードウェアの可能性を引き出します。また、SLO を維持しながらリソース効率を最大化するインテリジェントなスケジューリングとコスト最適化システムを構築。さらに、次世代トレーニングフレームワークを開発し、兆規模のパラメータを持つモデルや RLHF といった複雑なプロセスの効率的な訓練をサポートします。大模型時代の中核エンジン作りを共に担いましょう。

システムソフトウェア分野

チームは JVM、C++ の高性能計算、コンパイラなどの領域における製品機能の研究開発と最適化に注力しています。快手のビジネスを支える技術基盤として、性能の極限まで追求したシステムソフトウェアの開発を目指し、コアビジネスシーンでの重要な技術的ボトルネックを解決。システム技術による突破でビジネス価値を生み出します。

システムソフトウェアチームに参加すれば、システムソフトウェアの基盤を深く最適化し、快手の億単位の DAU（日次アクティブユーザー）を支える高同時接続アクセスに対応できます。Java のトランスペアレント・コルーチンや高性能 GC など業界をリードする JVM 製品機能の開発、Protobuf ライブラリやメモリアロケータといったハードコアな基礎ソフトウェアの改善推進、LLVM や GCC をはじめとする最先端のコンパイラ最適化技術の実装などに取り組みます。革新的なシステムソフトウェア製品機能を通じて、快手のコードをより速く、より安定して実行させ、ビジネス発展に確固たる基盤を提供します。

現在募集中のポジション

1. 大模型トレーニングエンジニア（LLM Training Engineer）

職務内容

• 大模型トレーニングフレームワークとプラットフォームの研究開発および進化を担当し、兆規模パラメータを持つモデルの実装を支援
• DP/TP/PP/ZeRO/FSDP/MoE などの分散トレーニング手法の設計と最適化を行い、スループットとリソース利用率を向上
• トレーニング性能のチューニングを担当。オペレーター最適化、混合精度計算（BF16/FP16/FP8）、メモリ最適化、通信最適化、パイプライン重なり処理を含む
• 訓練の安定性構築を担当。フォールトトレラントな回復、モニタリングとアラート、性能回帰テスト、トレーニング診断、自動化運用機能の開発
• リンforcement ラーニング（RL）トレーニングフレームワークとアライメントトレーニングプロセスの構築に参加し、RLHF/PPO/DPO/GRPO などのトレーニングタスクに対するエンジニアリング最適化とプラットフォーム化を支援
• 最先端のトレーニングシステム技術を追跡し、ビジネスシーンでの大規模展開を推進

応募要件

• 学士号以上。コンピュータサイエンス、ソフトウェア、電子工学関連専攻
• Python/C++ を習熟しており、堅牢なエンジニアリング能力とシステムデバッグ能力を有すること
• PyTorch のトレーニングメカニズムに精通し、逆伝播、勾配同期、メモリ管理などの原理を理解していること
• Megatron-LM、DeepSpeed、FSDP などの分散トレーニングフレームワークの知識があり、実務経験があること
• GPU/NPU の性能最適化手法に詳しく、Nsight や perf などのツールを用いたプロファイリングとボトルネック特定を単独で実施できること
• トレーニング側の計算リソース最適化技術（オペレーター融合、グラフ最適化、Triton/CUDA Kernel 開発、コンパイラ最適化など）の知識があること
• リンforcement ラーニングトレーニングの基本プロセスや一般的なフレームワークの理解があり、rollout、reward model、policy update などのメカニズムに詳しい方が優遇される
• 問題分析能力とチーム間連携能力に優れていること

加点項目

• MoE（Mixture of Experts）や長序列、マルチマシン・マルチカードでの大規模トレーニング経験がある方
• NCCL/HCCL/RDMA/IB の通信最適化に詳しい方
• 量子化トレーニング、低ビットトレーニング、QAT（Quantization-Aware Training）の実践経験がある方
• 国産チップの適応と性能最適化の経験がある方
• オープンソースへの貢献実績や、高性能システム関連の論文・特許を持つ方

1. 大模型推論エンジニア（LLM Inference）

職務内容

• 大模型推論エンジンの研究開発と最適化を担当し、スループットの向上、レイテンシの低減、推論コストの削減を実現
• KV Cache の管理、バッチ処理/スケジューリング、Prefill/Decode パイプライン、PD 分離など、推論のコアモジュール構築を担当
• TTFT（Time to First Token）、TPOT（Token Per Output Time）、TPS（Tokens Per Second）、RPM（Requests Per Minute）などの指標を目標に、オペレーター、メモリ、通信、スケジューリングの観点からシステムレベルでの性能最適化を実施

推論側のオペレーター開発と最適化を担当します。具体的には、オペレーターの融合、カーネルの最適化、グラフの最適化、推論コンパイラの最適化、そして INT8/FP8/FP4 などの量子化による推論加速の実装を推進します。

推論システムの安定性と高可用性の構築も担当します。故障からの復旧、負荷制限と機能の段階的低下（デグレード）、キャパシティ評価、自動化された診断、そして SLA の保証などを行います。

また、推論プラットフォーム化の基盤整備を主導します。モデルの公開フロー、グレーディング（段階的なロールアウト）、監視、ログ管理、トレーシング、そして自動化された運用ツールチェーンの構築です。

応募要件

• 学士号以上を取得し、コンピュータサイエンスやソフトウェア工学関連の専攻であること
• C++ と Python を習熟しており、高性能システム開発の実績があること
• Transformer の推論原理に精通し、Attention メカニズム、KV Cache、サンプリング戦略などの仕組みを理解していること
• 主要な推論フレームワークまたはエンジン（TensorRT、Sglang、vLLM など）の経験があること
• G