🚀

[翻訳+検証] SGLangでDiffusion LLMをサポート：LLaDA 2.0のDay-0実装

2026/01/06に公開

SGLangでDiffusion LLMをサポート：LLaDA 2.0のDay-0実装

TL;DR

私たちは、SGLang内にDiffusion Large Language Model（dLLM）フレームワークの設計と実装を導入できることを嬉しく思います。既存のChunked-Prefill機構を活用することで、以下を実現しました：

シームレスな統合：コアアーキテクチャを変更せずにSGLangエコシステムに組み込み
継承されたパフォーマンス：既存の推論最適化の恩恵を受ける
最大限の柔軟性：ユーザーがdiffusionデコーディングアルゴリズムを定義・カスタマイズできる完全な柔軟性

用語解説：主要な技術用語

Diffusion LLM（dLLM）

従来の自己回帰（AR）モデルとは異なる、拡散（Diffusion）プロセスを用いた大規模言語モデル。並列処理が可能で、特定のタスクで高速な推論を実現。
SGLang

高性能なLLM推論エンジン。数千社の本番環境で利用されており、バッチング、スケジューリング、最適化技術を豊富に備えている。
Chunked-Prefill

長いシーケンスを複数のチャンクに分割して処理する技術。GPU利用率を最大化するためにSGLangで使用されている。
Block Diffusion

トークン単位ではなくブロック単位でdiffusion処理を行うアーキテクチャ。計算効率とKVキャッシュ利用効率が向上。

背景

動機

2025年初頭、LLaDAが世界初のDiffusion Large Language Modelとしてデビューし、学術界と産業界の両方から即座に大きな注目を集めました。人民大学とAnt Groupの共同研究によるこの成果は、dLLMの独自の実行パラダイムが優れたデータ理解能力を示すことを実証しました。さらに、dLLMは自己回帰モデルと比較して、特に小バッチサイズなどの低レイテンシシナリオにおいて、より高速な推論速度を実現します。

同時に、dLLMのパラメータ規模が拡大し続けるにつれて、AR LLMで見られるものと同様のスケーリング則効果も観察されました。より優れたdLLMを追求するために、私たちは100BのLLaDA2.0-flashモデルをトレーニングしました。

しかし、LLaDA2.0-flashのトレーニングプロセスにおいて、一連の深刻なAIインフラストラクチャエンジニアリングの課題に遭遇しました。最も重要な課題は、モデル評価とRLポストトレーニングの効率と安定性です。

LLaDA1からLLaDA2への進化

LLaDA1の特徴
世界初のDiffusion LLM
新しい実行パラダイムの実証
優れたデータ理解能力
LLaDA2.0-flashの進化
パラメータ数：100B（1000億）
スケーリング則の適用
より大規模で実用的なモデル
本番環境での運用を見据えた設計
直面した課題
大規模モデルの評価効率
RLポストトレーニングの安定性
既存の推論エンジンの限界

課題

dLLMに対して現在利用可能な推論エンジンは、より大規模なdLLMの評価とRLポストトレーニング要件をサポートするには不十分です。例えば、Fast-dLLMのようなツールは優れた研究ツールであり、アルゴリズム研究者が様々なDiffusionデコーディングアルゴリズムを調整・検証するのにより適しています。しかし、バッチング、スケジューリング、RLエコシステム統合、並列処理などの本番環境対応のサービング機能を提供する点では不足しています。

対照的に、SGLangは今日最も人気のあるLLM推論エンジンの1つであり、複数の利点があります：

本番環境対応：数千社の推論サービスで導入されており、成熟した信頼性の高いエンジニアリング能力を提供
技術的リード：SGLang自体が膨大な優れた先進的推論最適化技術を組み込んでおり、コミュニティから継続的に新しい最適化が生まれている
完全なエコシステム：RLポストトレーニングエコシステムと非常によく統合されており、特に分散重みGPU P2P更新などの分野で優れている

しかし、核心的な問題は、SGLangが現在、自己回帰計算パラダイムのみをサポートしており、LLMのdiffusion計算手法にはまだ対応していないことです。

Fast-dLLM vs SGLangの比較

特徴	Fast-dLLM	SGLang
用途	研究・アルゴリズム開発	本番環境での推論サービス
バッチング	❌ 限定的	✅ 完全サポート
スケジューリング	❌ 限定的	✅ 完全サポート
RLエコシステム統合	❌ なし	✅ 完全統合
並列処理	⚠️ 限定的	✅ 完全サポート
導入実績	研究環境のみ	数千社の本番環境
コミュニティ	小規模	大規模・活発
最適化技術	基本的	豊富・継続的に追加

したがって、私たちが直面する課題は次のとおりです：既存のSGLangフレームワーク内でdLLMのサポートをどのように導入し、現在のアーキテクチャを損なわないようにするか？ 目標は2つあります：dLLMがSGLangが提供するすべての最適化の利点を享受できるようにすること、そして、diffusion計算に対応するためだけにSGLangフレームワークに大規模で妥協的な変更を加えることを避けることです。

設計

重要な洞察

現在のdLLMの開発状況に基づいて、いくつかの重要な洞察を得ました：

双方向アテンションDiffusionの膨大な計算コストと非効率的なKVキャッシュ利用のため、主流のdLLMはますますBlock Diffusionアーキテクチャに移行している
Block Diffusionの計算パターンは、SGLangの既存Chunked-Prefillプロセスと高い類似性を持つ
自己回帰言語モデルとは異なり、diffusion言語モデルは様々なデコーディング戦略を利用するため、柔軟なデコーディングアルゴリズムのカスタマイズのための専用インターフェースが必要

Block Diffusionアーキテクチャの技術的詳細

なぜBlock Diffusionが主流になったか
双方向アテンションの問題点
計算コスト：O(n²)の複雑度で全トークン間の関係を計算
KVキャッシュ：全トークンのKey/Valueを保持する必要があり、メモリ効率が悪い
Block Diffusionの解決策
ブロック単位での処理により計算を効率化
ブロック内は双方向、ブロック間は因果的関係を保つ
KVキャッシュの効率的な利用が可能
Chunked-Prefillとの類似性
どちらもシーケンスを分割して処理
GPU並列処理に最適化
バッチング処理との親和性が高い
この類似性により、既存のSGLangインフラストラクチャを最大限活用できる設計が可能になりました。

アーキテクチャ

私たちのアプローチは、SGLangの既存Chunked-Prefillパイプラインを活用してBlock Diffusion LLMの計算サポートを実装することです。この方法により、SGLangのコアフレームワークを変更することなく、dLLMをSGLangエコシステムにシームレスに統合でき、dLLMがSGLangが蓄積したすべての推論最適化技術から直接恩恵を受けることができます。

メイン実行フロー

図に示されているように、SGLangフレームワークへの変更は非常に抑制されており、そのコアにほとんど触れていません。SGLangの元のgenerate request実行フローは変更されていません。私たちの実装は主に既存のChunked Prefill機構の活用と変更に焦点を当てており、具体的な作業は2つの重要なコンポーネントに集中しています：prefill adderとchunked reqsです。

SGLangアーキテクチャへの統合の詳細

変更箇所の最小化
SGLangにおけるChunked Prefillの元々の目的はGPU利用率の最大化でした。したがって、単一チャンクのサイズは通常かなり大きく設定されており、GPUモデルに応じてシーケンス長で2Kから16Kトークンの範囲です。シーケンスが十分に長い場合、自然に1つのリクエストのみを処理します。これが現在のprefill adderとchunked reqの実装方法です。
しかし、dLLMのデコーディングプロセスは異なります：シーケンス長をブロックレベルでセグメント化します。LLaDA2.0を例にとると、そのブロックサイズは32トークンです。SGLangの以前のロジックに従って、一度に1つの大きなリクエストのみを処理すると、GPU性能が明らかに無駄になります。したがって、バッチングは解決すべき重要な問題です。
効率的なバッチングの実現
効率的なバッチングを実現するために、chunked reqsとprefill adderの両方を変更し、単一の計算サイクル内で複数のDiffusion Blockを処理できるようにしました。
Diffusionアルゴリズムの抽象化レイヤー
さらに、実際のデコーディング実行レベルでは、TP WorkerとModel Runnerの間にdiffusionアルゴリズムの抽象化レイヤーを挿入しました。
具体的には：
WorkerがDiffusionモデルを処理していることを識別すると、実行フローはこの専用ブランチに入ります
TP Workerはdiffusionアルゴリズムのrun関数を呼び出します
内部的に、このアルゴリズムは前方反復ループを使用して、ブロック全体（例：32トークンすべて）がデコードされるまでModel Runnerを継続的に駆動して推論計算を実行します
メリット
コアフレームワークの変更なし
既存の最適化技術を継承
柔軟なアルゴリズムカスタマイズ
SGLangの進化に追従可能

Attention Mask

Attention Maskの比較

単一モデルforward pass中のBlock DiffusionとChunk Prefillの最も重要な違いは、attention maskの扱いにあります。

Block Diffusionはブロック単位のcausal maskを利用
ARモデルのChunk Prefillは従来のトークン単位のcausal maskを使用

Block Diffusionは、SGLang内の既存のChunk Prefill機構の機能拡張として見ることができます。具体的なattention計算に関しては、単一forward passには2つの計算部分が含まれ、その最終出力が連結されます：

Context Query：現在のQ_curr（現在のブロックのクエリベクトル）を使用して、既存のKVキャッシュに対して双方向attentionを実行します。この計算はBlock DiffusionとChunk Prefillで完全に同一です。ここでの目的は、現在のブロックがすべての履歴情報にアテンドできるようにすることです。
Intra-Block Query：現在のQ_currを自身のKV（つまり、現在のブロック内のキーと値）に対して使用してforward計算を実行します。
- Block Diffusionはこのステップで双方向attentionを採用
- Chunk Prefillはこのステップでcausal Maskを使用する必要があります

Attention Maskの幾何学的理解

簡単に言えば、attention maskをQ_curr部分の幾何学的形状として視覚化すると：

Chunk Prefill（causal mask）の計算

台形（または三角形）マスク
└─ トークン単位で順次制約
└─ 各トークンは前のトークンのみを参照可能

Block Diffusion（双方向attention）の計算

矩形マスク
└─ ブロック内は相互参照可能
└─ ブロック間は因果的関係を維持

視覚的な比較

Chunk Prefill (Causal):

■ □ □ □
■ ■ □ □
■ ■ ■ □
■ ■ ■ ■

Block Diffusion (Bidirectional):

■ ■ □ □
■ ■ □ □
□ □ ■ ■
□ □ ■ ■

この違いにより、Block Diffusionはブロック内の並列処理が可能になり、推論速度が向上します。

ストリーミング出力アニメーション

以下は、LLaDA2.0-flash-CAP（100B / BF16）とgpt-oss-120B（117B / MXFP4）のストリーミング出力を比較したアニメーションです。LLaDA2.0-flash-CAPはSGLang dLLMを使用して8×H20上のTP8で提供され、gpt-oss-120Bは同じハードウェア上でSGLangの標準ARプロセスを使用して提供されています。

両モデルは10のプログラミング言語でクイックソートアルゴリズムを実装するよう求められています。これは、diffusion LLMに特に適したタスクです。図に示されているように、LLaDA2.0-flash-CAPはこのシナリオで935 tokens/sという大幅に高いスループットを達成し、gpt-oss-120B（263 tokens/s）と比較して優れています。

LLaDA2.0-flash-CAP vs gpt-oss-120B

SGLang dLLMは、SGLang自己回帰モデルと同様にストリーミング出力をサポートしています：ただし、1トークンずつではなく、1ブロック（例：32トークン）ずつ出力します。

dLLMアニメーション

ストリーミング出力の技術的詳細

従来のARモデルとの違い
ARモデル（自己回帰）:
1トークンずつ順次生成
各トークンは前のトークンに依存
レイテンシ：トークン数に比例
dLLM（Block Diffusion）:
1ブロック（32トークン）ずつ並列生成
ブロック内のトークンは同時処理
レイテンシ：ブロック数に比例
パフォーマンスの秘密
並列処理
ブロック内の32トークンを同時に計算
GPUの並列処理能力を最大活用
キャッシュ効率
ブロック単位でのKVキャッシュ管理
メモリアクセスパターンの最適化
バッチング
複数のブロックを同時処理
スループットのさらなる向上
適したタスク
コード生成（本例のクイックソート実装）
定型文の大量生成
並列性の高い応答が可能なタスク

使用方法

サーバー起動コマンド例

python3 -m sglang.launch_server \
  --model-path inclusionAI/LLaDA2.0-mini \ # HFまたはローカルパスの例
  --dllm-algorithm LowConfidence \
  --dllm-algorithm-config ./config.yaml \ # オプション。設定しない場合はアルゴリズムのデフォルト値を使用
  --host 0.0.0.0 \
  --port 30000

コマンドオプションの詳細

主要なパラメータ
--model-path: モデルのパス（HuggingFaceまたはローカル）
例：inclusionAI/LLaDA2.0-mini
例：/local/path/to/model
--dllm-algorithm: 使用するdiffusionアルゴリズム

LowConfidence: 低信頼度トークンを優先的に再生成
その他のアルゴリズムも選択可能
--dllm-algorithm-config: アルゴリズムの設定ファイル（オプション）
YAML形式で詳細なパラメータを指定
コードから設定を分離し、柔軟なカスタマイズを実現
--host, --port: サーバーのホストとポート設定
利点

この機能は、選択された--dllm-algorithmの高度な設定を可能にします。コードから設定を分離することで、統一されたエントリポイントを介してユーザー定義アルゴリズムの柔軟なカスタマイズと引数の受け渡しを実現します。

クライアントコード例

dLLMは他のサポートされているモデルと同様に、REST APIまたはオフラインエンジンAPI経由で使用できます。

curlを使用したリクエスト例：

curl -X POST "http://127.0.0.1:30000/generate" \
     -H "Content-Type: application/json" \
     -d '{
        "text": [
            "<role>SYSTEM</role>detailed thinking off<|role_end|><role>HUMAN</role>Write the number from 1 to 128<|role_end|><role>ASSISTANT</role>",
            "<role>SYSTEM</role>detailed thinking off<|role_end|><role>HUMAN</role>Write a brief introduction of the great wall<|role_end|><role>ASSISTANT</role>"
        ],
        "stream": true,
        "sampling_params": {
            "temperature": 0,
            "max_new_tokens": 1024
        }
    }'

Pythonオフラインエンジンの使用例：

import sglang as sgl

def main():
    llm = sgl.Engine(model_path="inclusionAI/LLaDA2.0-mini",
                     dllm_algorithm="LowConfidence",
                     max_running_requests=1,
                     trust_remote_code=True)

    prompts = [
        "<role>SYSTEM</role>detailed thinking off<|role_end|><role>HUMAN</role>Write a brief introduction of the great wall<|role_end|><role>ASSISTANT</role>"
    ]

    sampling_params = {
        "temperature": 0,
        "max_new_tokens": 1024,
    }

    outputs = llm.generate(prompts, sampling_params)
    print(outputs)

if __name__ == '__main__':
    main()

API使用の詳細とベストプラクティス

REST APIの利点
ネットワーク経由でリモートアクセス可能
複数のクライアントから同時利用可能
プログラミング言語に依存しない
オフラインエンジンAPIの利点
Pythonスクリプト内で直接使用
ネットワークオーバーヘッドなし
より細かい制御が可能
推奨設定
temperature: 0
決定論的な出力が必要な場合
再現性の確保
max_new_tokens: 1024
生成する最大トークン数
タスクに応じて調整
stream: true
リアルタイムでの出力確認
ユーザー体験の向上
プロンプト設計のヒント
システムプロンプトで動作モードを指定
ロール（SYSTEM, HUMAN, ASSISTANT）を明確に
タスクに応じた適切な指示を含める

パフォーマンス

LLaDA2.0-flashメインベンチマーク

私たちは、幅広い標準評価タスクで同程度の規模の先進的自己回帰（AR）モデルとベンチマークを行うことで、LLaDA2.0-flashのタスク効果を評価しました。

全体的な結果は、LLaDA2.0アーキテクチャが競争力が高いだけでなく、ARモデルとの能力ギャップを縮める有望な傾向を示していることを示しています。

LLaDA2.0-flashパフォーマンス

このグラフは、LLaDA2.0‑flashの2つの補完的な測定値を示しています：

12のベンチマークタスク全体で、Confidence-Aware Parallel（CAP）トレーニングありとなしで取得された平均スコアとトークン毎フォワード（TPF）
LLaDA2.0‑flashの推論速度（秒あたりのトークン数）を、HumanEval、MBPP、GSM8K、CRUXEvalスイートで同等サイズのARモデルとベンチマーク

すべての数値は、一貫したサービング環境（H20上のTP8を使用したSGLang）で収集されており、diffusion LLMと自己回帰ベースラインの公平な比較を保証しています。

0.95閾値デコーダーを使用して、LLaDA2.0-flash-CAPは500 TPSを達成し、標準LLaDA2.0-flash（383 TPS）を大幅に上回り、小バッチサイズでARベースライン（258 TPSと237 TPS）に対して最大1.9倍の高速化を実現しました。

パフォーマンス詳細分析

ベンチマークタスクの内訳
評価に使用された12のベンチマークタスク：
プログラミング：HumanEval、MBPP、CRUXEval
数学：GSM8K
その他の標準評価タスク
Confidence-Aware Parallel (CAP) トレーニングの効果
CAP トレーニングなし：
平均スコア：良好
TPF（Tokens Per Forward）：高い
CAP トレーニングあり：
平均スコア：若干向上
TPF：大幅に削減（効率向上）
推論速度：500 TPS（1.9倍高速化）
なぜdLLMが高速なのか
並列処理の優位性
ブロック内の32トークンを同時生成
ARモデルは1トークンずつ順次生成
小バッチサイズでの最適化
レイテンシ重視のシナリオで真価を発揮
GPUリソースの効率的利用
アルゴリズムの最適化
0.95閾値デコーダー
低信頼度トークンの選択的再生成
実用的な意味
リアルタイムアプリケーションに最適
コスト効率の向上
ユーザー体験の改善

ロードマップ

実装済みの主要機能

現在の実装は、以下の重要なサービング機能を完全にサポートしています：

✅ Block Diffusion LLMフレームワークのメインロジック
✅ シーケンス管理用の完全なKVキャッシュサポート
✅ LLaDA-2.0-mini/flashのモデル統合
✅ カスタムデコーディングアルゴリズムのサポート
✅ 完全なストリーミングI/O機能
✅ バッチングサポート（レビュー中）
✅ テンソル並列化サポート
✅ Cudaグラフ最適化

各機能の技術的詳細

Block Diffusion LLMフレームワーク
コアロジックの完全実装
Chunked-Prefillとの統合
柔軟なアルゴリズム抽象化
KVキャッシュ管理
ブロック単位での効率的な管理
メモリ使用量の最適化
シーケンス長の動的調整
モデル統合
LLaDA2.0-mini（小規模モデル）
LLaDA2.0-flash（100Bパラメータ）
他のBlock Diffusionモデルへの拡張可能性
カスタムアルゴリズム
プラグイン可能なアーキテクチャ
YAML設定ファイルでのカスタマイズ
コミュニティによる拡張
ストリーミングI/O
リアルタイム出力
ブロック単位での配信
クライアント側での処理最適化
バッチング
複数リクエストの同時処理
GPU利用率の最大化
スループットの向上
テンソル並列化（TP）
複数GPU間でのモデル分散
大規模モデルのサポート
通信オーバーヘッドの最小化
Cudaグラフ最適化
カーネル起動オーバーヘッドの削減
レイテンシの最小化
スループットの向上

中長期ロードマップ

2025-Q4および2026-Q1のロードマップ：

Roadmap for 2025-Q4 and 2026-Q1
RFC: Block Diffusion Large Language Model (dLLM) Framework In SGLang

主な計画：

自己回帰言語モデルが既に持つシステム最適化をさらにサポート
追加の一般的なdiffusionデコーディング戦略/アルゴリズムの統合（例：Fast-dLLM v2）
非ブロックdLLMとの互換性追加（例：LLaDA & RND1）

ロードマップの詳細

システム最適化の強化
より高度なメモリ管理
スケジューリングアルゴリズムの改善
マルチGPU環境での最適化
新しいデコーディング戦略
Fast-dLLM v2の統合
コミュニティからの新アルゴリズム
ユーザー定義戦略のサポート強化
アーキテクチャの拡張
非ブロックベースのdLLM対応
より柔軟なブロックサイズ
ハイブリッドアプローチのサポート
エコシステムの拡大
より多くのモデルのサポート
推論最適化技術の追加
コミュニティとの協力強化

参考文献

謝辞

このプロジェクトは、以下のチームの協力により実現しました：

Ant Group DeepXPU Team: Zehuan Li, Tiwei Bie, Zhonghui Jiang, Jinghua Yao, Yusong Gao, Mingliang Gong, Jianfeng Tan
Ant Group inclusionAI Team: Kun Chen, Zenan Huang, Lin Liu, Fuyuan Chen, Lun Du, Da Zheng
SGLang dLLM Team: Jinwei Yao, Mick Qian, Liangsheng Yin, BBuf, Banghua Zhu, Chenyang Zhao
NVIDIA Fast-dLLM Team: Chengyue Wu, Hao Zhang, Enze Xie, Song Han

動かしてみる

初学者向け記事ではないので環境構築はいい感じでやってください。作業メモは残しますが説明しません。

1. 依存パッケージのインストール


sagemaker-user@default:~$ nvidia-smi 
Mon Jan  5 16:19:26 2026       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.163.01             Driver Version: 550.163.01     CUDA Version: 12.6     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA L4                      On  |   00000000:38:00.0 Off |                    0 |
| N/A   22C    P8             11W /   72W |       1MiB /  23034MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   1  NVIDIA L4                      On  |   00000000:3A:00.0 Off |                    0 |
| N/A   22C    P8             11W /   72W |       1MiB /  23034MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   2  NVIDIA L4                      On  |   00000000:3C:00.0 Off |                    0 |
| N/A   24C    P8             12W /   72W |       1MiB /  23034MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   3  NVIDIA L4                      On  |   00000000:3E:00.0 Off |                    0 |
| N/A   23C    P8             10W /   72W |       1MiB /  23034MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
                                                                                         
+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+

sagemaker-user@default:~$ which python
/opt/conda/bin/python

sagemaker-user@default:~$ python3 -m pip install sglang[all]

# PyTorchのインストール (CUDA 11.8の場合)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

# Transformersとその他の依存関係
pip install transformers accelerate sentencepiece protobuf

2. モデルのダウンロード

uv pip install -U 'huggingface-hub<1.0'

huggingface-cli download inclusionAI/LLaDA2.0-mini-CAP --local-dir ./models/LLaDA2.0-mini-CAP

3. サーバーの起動

# ml.g6.12xlarge を使用
python3 -m sglang.launch_server \
  --model-path ./models/LLaDA2.0-mini-CAP \
  --host 0.0.0.0 \
  --port 30000 \
  --trust-remote-code \
  --tp-size 4 \
  --mem-fraction-static 0.85 \
  --kv-cache-dtype bf16 \
  --max-running-requests 16 \
  --max-total-tokens 16384 \
  --chunked-prefill-size 4096 \
  --enable-p2p-check

Capturing batches (bs=1 avail_mem=13.13 GB): 100%|█| 6/6 [00:23<0
[2026-01-05 16:30:02 TP1] Capture cuda graph end. Time elapsed: 24.50 s. mem usage=0.22 GB. avail mem=13.10 GB.
[2026-01-05 16:30:02 TP2] Capture cuda graph end. Time elapsed: 24.51 s. mem usage=0.22 GB. avail mem=13.10 GB.
[2026-01-05 16:30:02 TP0] Capture cuda graph end. Time elapsed: 24.54 s. mem usage=0.22 GB. avail mem=13.10 GB.
[2026-01-05 16:30:02 TP3] Capture cuda graph end. Time elapsed: 24.56 s. mem usage=0.22 GB. avail mem=13.10 GB.
[2026-01-05 16:30:02 TP0] max_total_num_tokens=16384, chunked_prefill_size=4096, max_prefill_tokens=16384, max_running_requests=16, context_len=32768, available_gpu_mem=13.10 GB
[2026-01-05 16:30:02] INFO:     Started server process [7553]
[2026-01-05 16:30:03] INFO:     Waiting for application startup.
[2026-01-05 16:30:03] INFO:     Application startup complete.
[2026-01-05 16:30:03] INFO:     Uvicorn running on http://0.0.0.0:30000 (Press CTRL+C to quit)
[2026-01-05 16:30:04] INFO:     127.0.0.1:48034 - "GET /model_info HTTP/1.1" 200 OK
[2026-01-05 16:30:04 TP0] Prefill batch, #new-seq: 1, #new-token: 6, #cached-token: 0, token usage: 0.00, #running-req: 0, #queue-req: 0, 
[2026-01-05 16:30:05] INFO:     127.0.0.1:48048 - "POST /generate HTTP/1.1" 200 OK
[2026-01-05 16:30:05] The server is fired up and ready to roll!

リクエストしてみます。なんかダメそうですが動かすのが目的なので検証終了です！泣

 curl http://localhost:30000/generate \ 
  -H "Content-Type: application/json" \
  -d '{
    "text": "Write a quicksort algorithm in Python",
    "sampling_params": {
      "temperature": 0.0,
      "max_new_tokens": 512
    }
  }'
{"text":".\ninan\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n","output_ids":[13,198,127734,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198,198],"meta_info":{"id":"5fd14ade784c43f3a92986f48c11a7bd","finish_reason":{"type":"length","length":512},"prompt_tokens":8,"weight_version":"default","total_retractions":0,"completion_tokens":512,"cached_tokens":0,"e2e_latency":2.526175022125244,"response_sent_to_client_ts":1767630693.1551077}}s