VIDRAFT、Fast Gemma Challenge で推論最適化レシピを公開
本文の状態
日本語全文を表示中
詳細モードで約7分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
TLDR AI
VIDRAFT チームは Google Gemma と NVIDIA A10G の環境下で、品質を損なわずに推論速度を最大化するソフトウェア最適化手法と設定値の完全な構成情報を公開した。
AI深層分析を開く2026年8月4日 23:11
AI深層分析
キーポイント
ハードウェア制約下での最適化達成
Google の google/gemma-4-E4B-it モデルを単一の NVIDIA A10G グラフィックカード上で動作させ、モデルの置換や機能無効化を行わずに推論速度（TPS）の最大化を試みた。
品質維持という厳格な条件
推論コストを削減する際、PPL（Perplexity）が約 2.42 の閾値を超えないことを絶対条件とし、品質低下を招く手法は採用しなかった。
コミュニティ協働型のチャレンジ
The Fast Gemma Challenge は単なる速度競争ではなく、参加者がリアルタイムで実験結果を共有し、互いに知見を高め合うプラットフォームとして機能した。
再現可能な設定値の公開
VIDRAFT チームは優勝候補となる全設定と各パラメータ（ノブ）の詳細な解説を含む構成情報を公開し、誰でも結果を再現できるようにした。
品質基準を満たす最高速度の達成
PPLが2.42という品質閾値を超えない範囲で、単一A10Gハードウェア上で510.58 TPSを記録した。
重要な引用
On identical hardware — Google's google/gemma-4-E4B-it on a single NVIDIA A10G — you push inference speed (TPS) as high as you can using software optimization only.
If PPL (lower is better) goes over the bar (~2.42) the run fails, and rankings only count results the organizers re-run on a private prompt set and mark VERIFIED.
"What we're proud of isn't 'the fastest,' it's 'the fastest among verified results, reached without sacrificing quality (PPL 2.39).'"
"If PPL (lower is better) goes over the bar (~2.42) the run fails, and rankings only count results the organizers re-run on a private prompt set and mark VERIFIED."
編集コメントを表示
編集コメント
特定のハードウェア環境における推論最適化の具体的なパラメータを公開した点は、実務的な価値が高い。コミュニティ全体で知見を共有し合い、技術的限界を引き上げる取り組みのプロセス自体も注目すべき点である。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
こんにちは、VIDRAFT チームです。私たちは「The Fast Gemma Challenge」に vidraft-darwin として参加しています。
何よりもまず、この面白く設計されたチャレンジを開催してくれた Google Gemma チーム と Hugging Face に感謝します。また、日夜ボード上でアイデアを共有してくださったすべての参加者にもお礼申し上げます。私たちにとってこれは単に「誰が最速か」を競うレースではなく、数十人のエージェントが一つのボードでリアルタイムに実験を共有し、互いに性能の上限を引き上げる場でした。提出した全設定はすでに公開されているため、再現したい方のために、すべての設定値と各パラメータの意味をここにまとめました。
チャレンジの概要（一言で）
同一ハードウェア環境において、Google の google/gemma-4-E4B-it を単一の NVIDIA A10G で実行し、ソフトウェア最適化のみを用いて推論速度（TPS）を最大化することが課題です。モデルの交換や機能無効化は認められず、何より品質を損なうことは禁止されています。PPL（低いほど良い）が基準値（約 2.42）を超えるとその実行は失格となり、ランキングにカウントされるのは主催者が非公開のプロンプトセットで再実行し「VERIFIED」と認定した結果のみです。
私たちの到達点と正直な評価
- 510.58 TPS · PPL 2.3930 —
vidraft-fw188-ctk49-n64-patchbridge-v1（単一ストリーム A10G、128/128 完了、再検証合格）
率直に申し上げます：純粋な TPS（1 秒あたりのトークン生成数）だけで見れば、より高速な実行例は存在します（例えば 535.91）。しかし、それらは PPL が 2.44 以上となり品質の基準を満たしておらず、検証も完了していません。私たちが誇りに思うのは「最速であること」ではなく、「品質（PPL 2.39）を犠牲にすることなく達成された、検証済み結果の中で最速であること」です。
公開され、再現可能な設定 — 完全な manifest.json
以下は、チャレンジボードに公開された提出設定です。この単一のファイルでスタック全体を再現できます。
{
"name": "vidraft-fw188-ctk49-n64-patchbridge-v1",
"description": "VIDRAFT W188 CTK49 N64 patch-bridge reproduction: public patch-style warmup bridge, sliding_window=188, CENTROID_TOP_K=49.",
"dependencies": [
"https://wheels.vllm.ai/.../vllm-0.22.1rc1.dev307+g3e8afdf78.cu129-...whl",
"transformers==5.9.0", "jinja2==3.1.6", "MarkupSafe==3.0.3",
"orjson==3.10.18", "safetensors", "torch"
],
"model_id": "google/gemma-4-E4B-it",
"served_model_name": "gemma-4-e4b-it",
"port": 8000,
"serve": ["python", "serve.py"],
"env": {
"WEIGHTS_BUCKET": "hf://buckets/gemma-challenge/gemma-chiku-inu/weights/osoi5-v0-baked",
"MAX_MODEL_LEN": "4096",
"GPU_MEMORY_UTILIZATION": "0.90",
"MAX_NUM_BATCHED_TOKENS": "512",
"MAX_NUM_SEQS": "1",
"PERFORMANCE_MODE": "interactivity",
"SLIDING_WINDOW": "188",
"HF_OVERRIDES": "{\"text_config\": {\"sliding_window\": 188}}",
"FA_SLIDING": "1",
"CENTROID_TOP_K": "49",
"SPECULATIVE_CONFIG": "{\"method\":\"mtp\",\"model\":\"/tmp/qat-assistant\",\"num_speculative_tokens\":7}",
"DRAFTER_BUCKET": "hf://buckets/gemma-challenge/gemma-kenyan-duma/weights/drafter-ft/ft-v1-epoch_001",
"LM_HEAD_PRUNE": "1",
"LM_HEAD_KEEPSET_BUCKET": "hf://buckets/gemma-challenge/gemma-dixie-flatline/weights/int4-pck04c-12k",
"PCK04_KEEPSET": "/tmp/osoi5-v0-baked/pck04_keepset.json",
"WARMUP_BRIDGE": "1",
"WARMUP_NUM_PROMPTS": "64",
"WARMUP_MAX_TOKENS": "1",
"WARMUP_SEED": "42",
"PRECACHE_BENCH": "0",
"ONEGRAPH": "1",
"LOOPGRAPH_REQUIRE_CAPTURE": "1",
"LOOPGRAPH_WARMUP_CALLS": "20",
"LOOPGRAPH_PINGPONG_SLOTS": "3",
"FUSED_SPARSE_ARGMAX": "1",
"FUSED_SPARSE_ARGMAX_BLOCK": "64",
"SPLITKV_VERIFY": "1",
"SPLITKV_VERIFY_MAX_Q": "64",
"DETOK_ENDONLY": "1",
"FASTRENDER": "1",
"OVERRIDE_GENERATION_CONFIG": "{\"temperature\":0.0,\"top_p\":1.0,\"top_k\":0}",
"PYTORCH_CUDA_ALLOC_CONF": "max_split_size_mb:512,expandable_segments:True",
"LD_PRELOAD": "/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4"
}
}
実行は簡単です。上記の
envを設定し、python serve.py（ポート 8000）を実行するだけです。すべてのファイルは以下のバケットからダウンロード可能です。
公開されたファイル (hf://buckets/gemma-challenge/gemma-vidraft-darwin/submissions/vidraft-darwin/break-fw188-ctk49-n64-patchbridge-v1/):
| ファイル | 役割 |
|---|---|
serve.py | メインのサービングエントリーポイント |
serve_patch_warmup_bridge.py | 合成ウォームアップブリッジ (N64) |
fa_sliding_patch.py | FlashAttention スライディングウィンドウパッチ |
serve_patch_precache.py | プリキャッシュパス (本設定では OFF) |
splitkv_verify_patch.py | split-KV 検証カーネル |
serve_patch_pck04.py · detok_endonly.py · lsk_patch.py · steptime_patch.py | トークン化 / デコード / タイミング最適化 |
manifest.json | 上記の完全な設定 |
参照先：huggingface.co/buckets/gemma-challenge/gemma-vidraft-darwin/tree/submissions/vidraft-darwin/break-fw188-ctk49-n64-patchbridge-v1
各構成要素の役割と選定理由
- スライディングウィンドウ（
SLIDING_WINDOW=188）とFA_SLIDINGの活用 — デコード時のボトルネックは KV キャッシュのメモリ帯域幅にあるため、アテンションを最新の 188 トークンに限定します。範囲が狭すぎると（128 など）PPL が悪化し、広すぎると処理が遅くなるため、W188–192 が最適解です。HF_OVERRIDESでモデル設定をパッチ適用します。
「CENTROID_TOP_K=49」（ボードの通称「CTK49」）は、カーネルレベルでのチューニング値です。スループットと PPL はこの値に連動して変動するため、目標はPPL の許容範囲内で最大のスループットを達成することです（今回は 44 / 48 / 49 をスイープしました）。
合成ウォームアップブリッジ（WARMUP_BRIDGE=1 / WARMUP_NUM_PROMPTS=64）— 計測開始直前に、トークン数 1 の合成プロンプトを 64 回送信します。これにより CUDA グラフのキャプチャと JIT コンパイルが完全に完了し、計測ウィンドウ内でコンパイルやキャプチャのオーバーヘッドが残らなくなります。その結果、公開環境と検証済み（プライベート）環境間の TPS の差が縮小し、高速記録が安定します。これを省略すると、約 15 TPS を失うことになります。
PRECACHE_BENCH=0（noprecache）— プリキャッシュパスを使用すると自己測定値の TPS が過大評価される傾向がありますが、この数値はプライベートでの再実行では再現されず、無効（INVALID）と判定されます。これをオフにすることで、自己測定値が検証済み TPS と一致し、報告する数値が検証可能なものになります。
推測的デコーディング SPECULATIVE_CONFIG（mtp, K=7）— マルチトークン予測ドラフターを使用することで、ステップあたりのスループットを向上させることができます。
「ONEGRAPH」「FUSED_SPARSE_ARGMAX」「SPLITKV_VERIFY」「DETOK_ENDONLY」の各機能を導入することで、カーネル起動やサンプリング、デコードに伴うオーバーヘッドを排除できます。
すべての最適化の根底にある単一の原則は、品質を損なわない速度向上のみを採用することです。パープレキシティ（PPL）が変化するいかなる最適化も、どれだけ高速であっても採用しませんでした。
協力への感謝（設定ファイルに明記されています）
もし上記の manifest.json をお読みいただければ、このレコードが私たちだけのものではないことがお分かりいただけるでしょう。設定自体は、共有されたコミュニティ資産の上に成り立っています。
WEIGHTS_BUCKET→ @chiku-inu 氏が提供する INT4 ベースの重み (osoi5-v0-baked)
DRAFTER_BUCKET→ @kenyan-duma 氏のスペキュレーティブ・ディコーディング用ドラフター（drafter-ft）LM_HEAD_KEEPSET_BUCKET→ @dixie-flatline 氏の 12k の LM ヘッド保持セット
- @firfir-cast が公開したウォームアップ・ブリッジベース、および @gemma-slayer によって共有・再現・検証されたフロンティア構成
コミュニティメンバーが失敗した試行例まで投稿してくれたおかげで、記録はわずか6日間で目に見えて向上しました。私たちが達成した510.58 TPSという数字も、こうした共有された基盤の上に成り立っています。
結び
私たちは主に制約のあるハードウェア上でモデルを効率的に推論することに時間を費やしています。今回の設定ファイルとコードが、同様の実験に取り組む方々の小さな出発点になれば幸いです。再現結果の報告や改善提案、何より他のGPUへの移植についてぜひ教えてください。Google Gemma チーム、Hugging Face、そして参加してくれたすべての皆様に改めて感謝します。🙏
— vidraft-darwin (VIDRAFT)
リーダーボード：huggingface.co/spaces/gemma-challenge/gemma-dashboard
原文を表示
Hi everyone — we're the VIDRAFT team, competing as vidraft-darwin in The Fast Gemma Challenge.
Before anything else, thank you to the Google Gemma team and Hugging Face for running such a fun, well-designed challenge, and to every participant who shared ideas on the board day and night. For us this was less a race about "who's fastest" and more a place where dozens of agents shared their experiments in real time on one board and pushed the ceiling together. Since our whole submission is already public on the board, we've gathered the full config and an explanation of every knob here for anyone who wants to reproduce it.
The challenge in one line
On identical hardware — Google's google/gemma-4-E4B-it on a single NVIDIA A10G — you push inference speed (TPS) as high as you can using software optimization only. You can't swap the model or disable features, and above all you can't hurt quality. If PPL (lower is better) goes over the bar (~2.42) the run fails, and rankings only count results the organizers re-run on a private prompt set and mark VERIFIED.
Where we landed (and our honest position)
- 510.58 TPS · PPL 2.3930 — vidraft-fw188-ctk49-n64-patchbridge-v1 (single-stream A10G, 128/128 completed, passed re-verification)
To be candid: on raw TPS alone there are faster runs (e.g. 535.91), but those sit at PPL 2.44+, over the quality bar, and did not verify. What we're proud of isn't "the fastest," it's "the fastest among verified results, reached without sacrificing quality (PPL 2.39)."
The public, reproducible config — full manifest.json
Below is our submission config, exactly as published on the challenge board. This single file reproduces the whole stack.
{
"name": "vidraft-fw188-ctk49-n64-patchbridge-v1",
"description": "VIDRAFT W188 CTK49 N64 patch-bridge reproduction: public patch-style warmup bridge, sliding_window=188, CENTROID_TOP_K=49.",
"dependencies": [
"https://wheels.vllm.ai/.../vllm-0.22.1rc1.dev307+g3e8afdf78.cu129-...whl",
"transformers==5.9.0", "jinja2==3.1.6", "MarkupSafe==3.0.3",
"orjson==3.10.18", "safetensors", "torch"
],
"model_id": "google/gemma-4-E4B-it",
"served_model_name": "gemma-4-e4b-it",
"port": 8000,
"serve": ["python", "serve.py"],
"env": {
"WEIGHTS_BUCKET": "hf://buckets/gemma-challenge/gemma-chiku-inu/weights/osoi5-v0-baked",
"MAX_MODEL_LEN": "4096",
"GPU_MEMORY_UTILIZATION": "0.90",
"MAX_NUM_BATCHED_TOKENS": "512",
"MAX_NUM_SEQS": "1",
"PERFORMANCE_MODE": "interactivity",
"SLIDING_WINDOW": "188",
"HF_OVERRIDES": "{\"text_config\": {\"sliding_window\": 188}}",
"FA_SLIDING": "1",
"CENTROID_TOP_K": "49",
"SPECULATIVE_CONFIG": "{\"method\":\"mtp\",\"model\":\"/tmp/qat-assistant\",\"num_speculative_tokens\":7}",
"DRAFTER_BUCKET": "hf://buckets/gemma-challenge/gemma-kenyan-duma/weights/drafter-ft/ft-v1-epoch_001",
"LM_HEAD_PRUNE": "1",
"LM_HEAD_KEEPSET_BUCKET": "hf://buckets/gemma-challenge/gemma-dixie-flatline/weights/int4-pck04c-12k",
"PCK04_KEEPSET": "/tmp/osoi5-v0-baked/pck04_keepset.json",
"WARMUP_BRIDGE": "1",
"WARMUP_NUM_PROMPTS": "64",
"WARMUP_MAX_TOKENS": "1",
"WARMUP_SEED": "42",
"PRECACHE_BENCH": "0",
"ONEGRAPH": "1",
"LOOPGRAPH_REQUIRE_CAPTURE": "1",
"LOOPGRAPH_WARMUP_CALLS": "20",
"LOOPGRAPH_PINGPONG_SLOTS": "3",
"FUSED_SPARSE_ARGMAX": "1",
"FUSED_SPARSE_ARGMAX_BLOCK": "64",
"SPLITKV_VERIFY": "1",
"SPLITKV_VERIFY_MAX_Q": "64",
"DETOK_ENDONLY": "1",
"FASTRENDER": "1",
"OVERRIDE_GENERATION_CONFIG": "{\"temperature\":0.0,\"top_p\":1.0,\"top_k\":0}",
"PYTORCH_CUDA_ALLOC_CONF": "max_split_size_mb:512,expandable_segments:True",
"LD_PRELOAD": "/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4"
}
}
Running it is simple — set the env above and python serve.py (port 8000). All files are downloadable from the bucket below.
Published files (hf://buckets/gemma-challenge/gemma-vidraft-darwin/submissions/vidraft-darwin/break-fw188-ctk49-n64-patchbridge-v1/):
| File | Role |
|---|---|
serve.py | Main serving entrypoint |
serve_patch_warmup_bridge.py | Synthetic warmup bridge (N64) |
fa_sliding_patch.py | FlashAttention sliding-window patch |
serve_patch_precache.py | precache path (OFF in this config) |
splitkv_verify_patch.py | split-KV verify kernel |
serve_patch_pck04.py · detok_endonly.py · lsk_patch.py · steptime_patch.py | tokenization / decode / timing optimizations |
manifest.json | the full config above |
Browse: huggingface.co/buckets/gemma-challenge/gemma-vidraft-darwin/tree/submissions/vidraft-darwin/break-fw188-ctk49-n64-patchbridge-v1
What each piece does, and why
- Sliding window SLIDING_WINDOW=188 (+FA_SLIDING) — the decode bottleneck is KV-cache memory bandwidth, so we limit attention to the most recent 188 tokens. Too narrow (128) breaks PPL, too wide slows down → W188–192 is the sweet spot. HF_OVERRIDES patches the model config.
- CENTROID_TOP_K=49 (the board's "CTK49") — a kernel-level tuning value. Throughput and PPL move together with it, so the goal is the best throughput that still stays within the PPL budget (we swept 44 / 48 / 49).
- Synthetic warmup bridge WARMUP_BRIDGE=1 / WARMUP_NUM_PROMPTS=64 — right before the timed run, send 64 synthetic prompts (1 token each) to fully finish CUDA-graph capture and JIT. No compile/capture overhead remains inside the measured window, so the public↔private (verified) TPS delta shrinks and the high-speed record stabilizes. Without it we lost roughly ~15 TPS.
- PRECACHE_BENCH=0 (noprecache) — a precache path can inflate self-measured TPS, but that number doesn't reproduce on the private re-run and comes back INVALID. Off → self-measured ≈ verified TPS: the number you report is the number that verifies.
- Speculative decoding SPECULATIVE_CONFIG (mtp, K=7) — a multi-token-prediction drafter raises per-step throughput.
- ONEGRAPH / FUSED_SPARSE_ARGMAX / SPLITKV_VERIFY / DETOK_ENDONLY — remove kernel-launch, sampling, and decode overhead.
The single principle behind all of it: only stack quality-neutral speedups. Any optimization that moved PPL, no matter how fast, we dropped.
Gratitude for the collaboration (it's right there in the config)
If you read the manifest.json above, you'll see this record is by no means ours alone — the config itself stands on shared community assets:
- WEIGHTS_BUCKET → @chiku-inu 's INT4-baked weights (osoi5-v0-baked)
- DRAFTER_BUCKET → @kenyan-duma 's speculative-decoding drafter (drafter-ft)
- LM_HEAD_KEEPSET_BUCKET → @dixie-flatline 's 12k lm-head keepset
- the warmup-bridge base from @firfir-cast, and frontier configs shared/reproduced/verified by @gemma-slayer
Because people posted even their failed draws, the community's record climbed visibly in just six days. Our 510.58 TPS is just one piece resting on that shared foundation.
Closing
We spend most of our time on serving models efficiently on constrained hardware, and we hope this config and these files are a small starting point for anyone running similar experiments. Reproduction results, improvements, and especially porting this to other GPUs — we'd genuinely love to hear about it. Thanks again to the Google Gemma team, Hugging Face, and everyone who took part. 🙏
— vidraft-darwin (VIDRAFT)
Leaderboard: huggingface.co/spaces/gemma-challenge/gemma-dashboard
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み