Gemma 推理新方案：Dataflow 結合 vLLM 提速超 23 倍

Google 提供了一套將開源推理引擎 vLLM 接入 Dataflow 資料管道的方案，讓你在雲端做流式處理或批次生成時，用極少的程式碼把 Gemma 跑出很高的吞吐效率。

這套方案解決的核心痛點是大模型落地生產時的資源浪費問題。傳統的 GPU 批處理就像餐廳後廚做飯，把類似的任務湊在一起做；但大模型推理是逐個 token 生成的，一道短問題和一道長問題打包在一起，短問題算完了也不能走，只能眼睜睜看著長問題霸佔 GPU，計算資源就被活活耗在等待上。

連續批處理加模型管理器

為了解決這個問題，vLLM 採用了連續批處理機制。它每生成一組 token 就會動態重新整理一次批次，算完的請求立刻返回，新來的請求當場插隊塞進佇列，充分壓榨 GPU 的每個計算核心。

但在流式資料管道里部署 vLLM 一向很麻煩。以前開發者不僅要自己寫多程序通訊，還要根據機器核數和網路拓撲小心調整配置，一旦換了機器規格就得推倒重來。

Dataflow 這次引入的模型管理器把這些髒活包攬了過去。Dataflow 預設會在每個 CPU 核心上起一個工作程序，如果每個程序都載入一份 Gemma 這樣的大模型，記憶體馬上就會爆掉。模型管理器做的事情很簡單：在機器上單獨拉起一個 vLLM 例項，其他工作程序收到資料後，非同步把請求送進 vLLM 的佇列排隊。開發者只需要配置幾行引數，底層的拓撲和路由完全不用操心。

23 倍提升是怎麼跑出來的

在程式碼量上，利用 RunInference 轉換運算元和預置的 vLLM 處理器，搭建一個包含讀取、推理和輸出的完整管道，核心程式碼只要 5 行，整個指令碼也不到 20 行。

Google 公佈了一組對照測試：在單個配備 T4 GPU 的工作節點上，用 P3 資料集的 10000 條提示詞對 google/gemma-2b 模型進行推理。

採用傳統固定大小批處理的樸素管道，總共消耗了 59.137 個 vCPU 小時；而接入 vLLM 連續批處理後，處理同樣的 10000 條資料只花了 2.481 個 vCPU 小時。計算資源消耗驟降，效率提升超過 23 倍。

需要指出的是，這項測試雙方都沒有經過針對性調優。樸素管道如果精心調整批處理尺寸，成績會有所回升；但 vLLM 的優勢恰恰在於不用費心思微調引數，插拔即用就能拿到理想的吞吐表現。想要測試其他模型，也只需修改模型處理器裡的一行模型名稱字串。目前完整的示例筆記本已經在 Google Cloud 官方文件中上線，開發者可以直接在雲端執行體驗。

為什麼重要

如果你正在用 Apache Beam 或 Dataflow 做資料清洗、資訊抽取或者即時內容分類，這套方案非常值得立刻試試。它最大的價值在於把複雜的 GPU 多程序排程降維成一個普通運算元，大幅降低了在流式流水線裡塞進自建開源大模型的工程門檻。

我們認為 Google 這一步走得很務實。與其逼著使用者在雲原生大模型 API 上按 token 掏錢，不如把開源生態裡口碑最好的推理引擎接入自己的資料處理底座。不過大家在嘗試時也要注意，這套方案針對的是吞吐優先的高併發和流處理場景；對於極端追求單次請求首字延遲的互動式產品，它並不能替你解決大模型本身的計算開銷。