Google Cloud TPU 跑 Qwen3 Embedding：生产级长上下文检索实战

Google Cloud 于 2026 年 8 月 26 日发布了面向 embedding 推理的原生 vLLM TPU 支持，聚焦生产级检索场景而非聊天生成。工程工作围绕 Qwen3-Embedding-8B 和 Qwen3-VL-Embedding-8B展开，覆盖长文本和多模态上下文，包括 16K 类文本序列以及 15K+ 的多模态输入。Google 通过混合 StepPool 设计解决了 TPU 张量对齐、懒加载、JAX/XLA 编译预热、分块 prefill 以及 pooling 状态保持等问题。在一项发布的 Qwen3-Embedding-8B 配置中（bf16、16K+ 序列、TP=4），TPU Ironwood 达到了 83,996 total tokens/s 和 5.13 requests/s。Google 还验证了跨硬件的向量一致性，要求文本余弦相似度阈值至少 0.999、多模态输入至少 0.995。

Embedding 基础设施很容易被低估。

原型可能看起来像：

documents
→ embedding API
→ vector database

生产环境则涉及数亿级 chunks、图片、重索引任务、在线查询以及多租户。

到了这个规模，embedding 推理就成为真正的服务平台。

两种不同负载

建索引优先考虑 token 吞吐量。

在线查询 embedding 优先考虑延迟。

成熟平台需要同时满足两者。

为什么长上下文 embedding 很重要

现代检索越来越需要长文档、多模态页面、幻灯片片段以及图文对，而非 512-token 片段。

Google 讨论的是 4K token 以上的文本负载和 15K 以上的多模态输入。

长序列增加了内存压力，也让 pooling 正确性更难保证。

为什么原生 vLLM TPU 支持很重要

vLLM 已经是主流开源推理引擎。

增加 TPU 支持让团队可以在不同类型加速器上使用更统一的推理技术栈，而无需维护一套独立的 TPU 专用系统。

基于 GKE 的异构弹性

Google 描述了优先级容量方案：TPU 作为主资源池，GPU 容量作为次级备选。

这对于突发性建索引负载尤其有用。

Embedding 正确性比生成正确性要求更严

跨硬件的小幅生成差异通常可以接受。

Embedding 差异会改变最近邻排序。

如果向量发生了实质性变化，搜索结果可能仅仅因为硬件后端改变就发生变化。

黄金基准测试

v_ref = reference embedding
v_tpu = TPU embedding

然后计算余弦相似度。

Google 使用的目标阈值：

text >= 0.999
multimodal >= 0.995

这是一个严格的迁移标准。

不要只测 QPS

在跨硬件迁移 embedding 推理之前，测量向量一致性、Recall@K、NDCG、top-K 重叠率以及下游业务质量。

如果检索质量静默变化，再快的基础设施也没有意义。

为什么分块 prefill 对 embedding 很难

长输入会耗尽加速器内存。

分块 prefill 通过将输入拆分到多个步骤来降低峰值内存。

但 embedding 模型仍然需要整个序列的最终 pooled 表示。

如果 pooling 状态没有在 chunks 之间正确累积，向量可能出错而不会产生明显失败。

StepPool 和缓存状态

Google 的混合 StepPool 设计在 chunk 边界和请求抢占时保持 pooling 状态，使用缓存的请求元数据。

这是"能运行的代码"与"数学上保持正确的推理"之间差异的重要例证。

TPU 矩阵单元在张量并行分片时施加了严格的整除约束。

Google 添加了词汇填充以保证分片执行时的硬件安全性，同时保留逻辑输出。

TPU 推理通常依赖编译。

生产 pod 不应该让第一个真实用户承担 JIT 成本。

更安全的生命周期：

pod starts
→ model loads
→ compilation warm-up
→ health ready
→ traffic

发布的吞吐量结果

一项 Qwen3-Embedding-8B 配置：

bf16
16K+ sequence
TP=4

83,996 total tokens/s
5.13 requests/s

这是一个特定的基准点，不是通用的 TPU 数值。

为什么 requests/s 看起来偏低

每个请求可能包含数千个 token。

对于长上下文建索引，总 token 吞吐量可能比原始请求数更有用。

多模态推理更难

Qwen3-VL-Embedding 结合了文本和图像输入。当前的 vLLM-TPU 设计只对多模态 prefill 的文本部分进行分块，这凸显了视觉特征、pooling 和内存方面的额外复杂性。

推荐企业架构

document pipeline
→ parser / chunker
→ embedding gateway
→ vLLM
   ├── TPU pool
   └── GPU fallback
→ vector database

在线查询流量理想情况下应使用独立的低延迟池。

分离批处理和在线容量

大型重索引任务如果与在线任务共享同一加速器队列，会摧毁在线 P99 延迟。

使用独立的批处理和在线 embedding 池，具有不同的调度目标。

Embedding 网关应该标准化

追踪模型版本、向量维度、归一化、最大长度、pooling 方法和硬件后端。

Embedding 版本控制很重要，因为不同模型版本产生不同的向量空间。

使用双索引进行模型升级

old model → old index
new model → new index

运行影子流量、比较检索结果、重建索引，然后切换。

不要盲目地将新的查询 embedding 与旧的索引混用。

TPU 总是更好吗？

决策取决于云平台、模型支持、负载特征、成本和团队专业知识。

此版本战略价值在于：TPU 成为一级 vLLM 推理选项。

性能：tokens/s、requests/s、延迟、队列时间。

质量：余弦一致性、Recall@K、top-K 重叠率、NDCG。

基础设施：HBM、编译时间、抢占、自动扩缩容。

业务：检索成功率和下游答案质量。

重要变化不仅仅是 Qwen3 embedding 可以在 TPU 上运行。

Embedding 推理正在成为独立的生产基础设施，要求：

高吞吐量
+ 长上下文
+ 数学一致性
+ 弹性扩缩
+ 可复现性

Google 发布的配置在应用严格的跨硬件余弦相似度阈值的同时，达到了 83,996 total tokens/s 和 5.13 requests/s。

对于生产级 RAG，关键问题不是"模型能否在另一种加速器上运行？"

而是：

系统能否在扩缩容和切换硬件时不会静默改变检索质量？

更多 RAG、embedding、vLLM 和推理基础设施指导，请访问 Zyentor Picks：https://www.zyentorpicks.com/。

Originally published on Zyentor Picks.