VIDRAFT 如何在 Gemma-4 上達到 510.58 TPS
VIDRAFT 如何在 Gemma-4 上達到 510.58 TPS：「The First Gemma Challenge」冠軍深度解析
TL;DR: VIDRAFT 在「The First Gemma Challenge」排行榜上以單一 NVIDIA A10G GPU 在
google/gemma-4-E4B-it模型上取得經驗證的 510.58 tokens-per-second (TPS) 成績，同時擊敗了一個原始速度更快但未通過品質門檻的競爭對手。本文剖析使其成功的公開設定選擇，以及工程師們能在自己的推論調校工作中借鏡的技巧。
這是什麼
「The First Gemma Challenge」是一場受嚴格限制的推論速度競賽，有兩項硬性規則：固定使用單一 GPU（NVIDIA A10G）與固定模型（google/gemma-4-E4B-it）。參賽者無法更換更強的硬體或更輕量的模型，唯一能操作的槓桿就是軟體層級的最佳化。
評分指標為TPS（Tokens Per Second，每秒生成 token 數），但同時設有Perplexity（PPL）預算——PPL 超過約 2.42 的提交將被取消資格，無論速度多快。主辦單位還針對參賽者從未見過的保留提示集進行盲測重新評估，這意味著任何過度擬合自報基準的設定都會被抓出來。
VIDRAFT 的優勝提交——設定名稱為 vidraft-fw188-ctk49-n64-patchbridge-v1——的成績如下：
- TPS： 510.58
- PPL： 2.3930
- 狀態： 通過盲測重新評估 ✅
另一個競爭提交雖然錄得 535.91 TPS，但其 PPL 約為 2.44，超過品質門檻。因此這個較低的原始數值被認定為經驗證的 SOTA。
運作原理
優勝設定的公開 manifest.json 揭示了三個概念性的最佳化支柱：
1. 滑動視窗注意力壓縮（SLIDING_WINDOW=188）
KV-cache 記憶體頻寬是自迴歸生成過程中的主要瓶頸。將注意力視窗限制在最近的 token 上能減輕這項壓力並提升吞吐量——但視窗縮得太小就會喪失上下文，導致 PPL 急遽上升。188 這個數值顯然不是整數，這強烈暗示它是透過實證調整而非直接採用預設值。團隊透過 HF_OVERRIDES 覆寫了模型的 text_config.sliding_window，並啟用 Flash Attention 滑動功能（FA_SLIDING=1）來配合。
2. 質心 Top-k 核心調校（CENTROID_TOP_K=49）
此參數更接近核心層級，會同時影響吞吐量與 PPL。根據原始碼分析，團隊依序測試了 44、48、49 等數值——目標是找出在 PPL 仍在預算內的前提下所能使用的最大值。越大並不一定越好，這是在品質限制下的 Pareto 搜尋。
3. 暖機紀律——將初始化過程排除在測量視窗之外
該設定使用了：WARMUP_BRIDGE=1、WARMUP_NUM_PROMPTS=64、WARMUP_MAX_TOKENS=1、WARMUP_SEED=42。這會在計時基準測試開始前先執行 64 個單一 token 的虛擬提示，讓 CUDA graph capture 與 JIT 編譯的成本在計時開始前就被吸收。原始文章指出這個暖機步驟大約貢獻了 15 TPS——在一個以數十 TPS 決勝負的競賽中，這是相當可觀的差距。
同樣重要的是：PRECACHE_BENCH=0 被明確設定，停用了會讓自報 TPS 虛增的旗標。團隊選擇測量盲測評估器實際會看到的真實表現。
其他值得注意的參數（已公開）
-
推測解碼： 透過
SPECULATIVE_CONFIG啟用，設定num_speculative_tokens=7與method=mtp——這是一種先草稿再驗證的方法，能增加每次正向傳遞所生成的 token 數 MAX_MODEL_LEN=4096GPU_MEMORY_UTILIZATION=0.90MAX_NUM_BATCHED_TOKENS=512MAX_NUM_SEQS=1
基準測試與結果
| 提交 | TPS | PPL | 盲測 |
|---|---|---|---|
VIDRAFT（vidraft-fw188-ctk49-n64-patchbridge-v1） |
510.58 | 2.3930 | ✅ 通過 |
| 競爭提交 | 535.91 | ~2.44 | ❌ 未通過（PPL > 2.42） |
最重要的啟示：原始吞吐量排名與驗證後排名出現分歧，因為品質門檻是根據保留提示分佈來執行的，而非參賽者自己的測試集。
如何嘗試
競賽中所使用的模型已由 Google 在 Hugging Face 公開提供：
huggingface-cli download google/gemma-4-E4B-it
Enter fullscreen mode
Exit fullscreen mode
特定的 VIDRAFT 設定（vidraft-fw188-ctk49-n64-patchbridge-v1）以及任何 VIDRAFT 專屬工具在本文撰寫時尚未確認已公開釋出。請查看 VIDRAFT 的 Hugging Face 組織 與他們的 GitHub 以取得最新資訊。如果開放取得管道，會優先在那裡公布。
常見問題
Q：在「速度」競賽中，為什麼 PPL 門檻比原始 TPS 更重要？
A：因為沒有品質底線的 TPS 很容易被操縱——你可以讓模型輸出垃圾內容來快速生成。PPL 上限加上盲測重新評估，共同確保速度數字反映的是真實、可部署的推論品質。
Q：我能將這些技術應用在其他模型或 GPU 上嗎？
A：概念——品質門控的參數搜尋、暖機分離、滑動視窗調校、推測解碼——都是通用的推論工程實務。特定數值（SLIDING_WINDOW=188、CENTROID_TOP_K=49 等）是針對單一 A10G 上的 google/gemma-4-E4B-it 所調校的，應該視為其他硬體或模型設定的起點，而非直接複製貼上的目標。
Q：推測解碼（method=mtp）在這裡的作用是什麼？
A：一個更小、更快的「草稿」模型會先預測主模型接下來的幾個 token。主模型再在單一次正向傳遞中驗證這些預測。如果預測被接受，你就能在每個步驟中實際生成多個 token——在不改變模型權重或降低輸出品質的情況下提升測得的 TPS。
原文由 note（日本）於 2026-08-15 報導 — 原始文章。