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 掏钱，不如把开源生态里口碑最好的推理引擎接入自己的数据处理底座。不过大家在尝试时也要注意，这套方案针对的是吞吐优先的高并发和流处理场景；对于极端追求单次请求首字延迟的交互式产品，它并不能替你解决大模型本身的计算开销。