教程
Qwen3 Embedding 上 Cloud TPU：16K 长上下文检索怎么做生产化
Google Cloud 在 2026 年 8 月 26 日公布了 vLLM 原生 TPU Embedding 推理方案，重点不是普通 LLM Chat，而是企业 RAG、Semantic Search 和多模态检索常用的高维 Embedding 工作负载。Google 以 Qwen3-Embedding-8B 和 Qwen3-VL-Embedding-8B 为工程目标，处理 4K+ 文本和 15K+ 图文上下文，并在 TPU 上解决 Tensor Alignment、Lazy Loading、JAX/XLA 编译预热、Chunked Prefill 与 StepPool 状态累积问题。官方给出的 Qwen3-Embedding-8B 结果中，在 bf16、16K+ 序列、TP=4 条件下达到 83,996 total token/s 和 5.13 req/s，同时使用文本 ≥0.999、多模态 ≥0.995 的余弦相似度阈值验证跨硬件数值一致性。真正重要的问题是：Embedding 服务扩容和换硬件以后，检索结果能不能保持稳定。
# Qwen3 Embedding 上 Cloud TPU：16K 长上下文检索怎么做生产化
## 文章摘要
Google Cloud 在 2026 年 8 月 26 日公布了 vLLM 原生 TPU Embedding 推理方案，重点不是普通 LLM Chat，而是企业 RAG、Semantic Search 和多模态检索常用的高维 Embedding 工作负载。Google 以 Qwen3-Embedding-8B 和 Qwen3-VL-Embedding-8B 为工程目标，处理 4K+ 文本和 15K+ 图文上下文，并在 TPU 上解决 Tensor Alignment、Lazy Loading、JAX/XLA 编译预热、Chunked Prefill 与 StepPool 状态累积问题。官方给出的 Qwen3-Embedding-8B 结果中，在 bf16、16K+ 序列、TP=4 条件下达到 83,996 total token/s 和 5.13 req/s，同时使用文本 ≥0.999、多模态 ≥0.995 的余弦相似度阈值验证跨硬件数值一致性。真正重要的问题是：Embedding 服务扩容和换硬件以后，检索结果能不能保持稳定。
---
很多团队做 RAG 时，最容易低估的组件不是 Vector Database，而是 Embedding Serving。
Demo：
```text
100 个文档
↓
Embedding API
↓
Vector DB
```
很简单。
生产环境可能是：
```text
几亿段文档
+
图片
+
实时查询
+
批量重建索引
+
多租户
```
Embedding 已经是独立推理基础设施。
## 两条完全不同的工作负载
### Indexing
```text
Document
↓
Chunk
↓
Embedding
↓
Vector DB
```
重点是 Token Throughput。
### Query
```text
User Query
↓
Embedding
↓
Vector Search
↓
LLM
```
重点是 Latency。
成熟平台必须同时解决 Batch 和 Online。
## 长上下文 Embedding 为什么变重要
早期 Embedding 常见输入只有几百 Token。
现在企业想直接处理：
- 长文档；
- 图文页面；
- PDF Section；
- Slide；
- Image + Text。
Google 这次讨论的是 4K+ 文本和 15K+ 多模态输入。输入越长，Memory Pressure、Pooling Correctness 和 Serving Complexity 都会快速上升。
## vLLM 原生 TPU 支持意味着什么
vLLM 已经是主流开源 Serving Engine。Google Cloud 把 TPU 纳入 vLLM Serving 后，企业可以用更统一的框架服务 GPU 和 TPU，而不是维护两套完全不同的推理栈。
这对平台团队很重要，因为真正昂贵的往往不是单次推理，而是：
> 运维两套不兼容系统。
## GKE 异构弹性怎么用
Google 给出的架构允许：
```text
Primary TPU Pool
↓
容量不足
↓
Secondary GPU Spot / On-demand Pool
```
结合 GKE Custom Compute Classes，可以按优先级做节点自动扩容。
这非常适合周期性的大规模 Index Build。
## 为什么 Embedding 特别关注数值一致性
Chat Model 在不同硬件上输出略有差异通常可以接受。
Embedding 不一样。
如果同一段文本在 GPU 和 TPU 上生成的 Vector 差异太大，Vector Search 排名就可能变化。也就是说你只是换了一套硬件，搜索结果却悄悄变了。
## Golden Reference 怎么测
设参考向量：
```text
v_ref
```
TPU 向量：
```text
v_tpu
```
计算：
```text
cosine_similarity(v_ref, v_tpu)
```
Google 使用的目标阈值：
### Text
```text
>= 0.999
```
### Multimodal
```text
>= 0.995
```
这是很严格的跨硬件一致性要求。
## 切硬件不能只看 QPS
从 GPU 迁 TPU 时，不要只比较吞吐。
至少还应该测：
```text
Vector Cosine
Recall@K
NDCG
TopK Overlap
Business Success
```
如果基础设施更快，但 Retrieval Quality 下降，迁移就是失败的。
## 16K 输入为什么容易吃爆 HBM
长上下文意味着更多 Token、中间状态和内存压力。Chunked Prefill 可以把长输入拆成多个 Step，降低峰值内存。
但 Embedding 有一个特殊问题：最后需要整个序列的 Pooling Result。
如果：
```text
Chunk 1
Chunk 2
Chunk 3
```
之间状态没有正确累积，最终向量会错。
## StepPool 解决什么
Google 实现 Hybrid StepPool，并把 Pooling Metadata 放进 CachedRequestState，让状态能够跨 Step 和 Preemption 保持。
这说明生产 Embedding 最危险的问题不是 Crash，而是：
> 没报错，但 Vector quietly 错了。
## Tensor Alignment 为什么是 TPU 特有工程点
TPU MXU 对 Tensor Sharding 有严格对齐约束。Vocabulary Size 和 Tensor Parallel Size 不一定整除，因此需要做统一 Padding，再进行 Shard、All-Gather 和还原。
如果这个细节处理不好，不只是性能问题，甚至会直接导致 Shape 或执行异常。
## JAX/XLA 预热为什么重要
TPU Serving 依赖编译。如果新 Pod 第一次接生产请求时才触发 JIT，就会出现明显 Latency Spike。
更合理：
```text
Pod Start
↓
Load Model
↓
Compile Warm-up
↓
Health Ready
↓
Receive Traffic
```
尤其在 Auto Scale 场景，Pre-warm 应该成为 Ready Condition 的一部分。
## 官方最值得引用的结果
Google 给出的 Qwen3-Embedding-8B 条件：
```text
bf16
16K+ Sequence
TP = 4
```
在 TPU Ironwood 上达到：
```text
83,996 total token/s
5.13 req/s
```
必须强调：这是特定模型、序列长度和 TP 配置下的官方测试点，不是所有 TPU Embedding 的固定性能。
## 为什么 req/s 看起来不高
因为单请求本身很长。
如果每个 Request 都有几千到上万 Token，那么 5 req/s 对应的 Token Throughput 已经很高。对于批量建索引，total token/s 往往比 req/s 更有意义。
## 多模态 Embedding 更复杂
Qwen3-VL-Embedding 同时处理 Text 和 Image。Google 当前 vLLM-TPU 方案只对多模态 Prefill 的文本部分做 Chunk，说明多模态 Serving 还要额外处理 Vision Token、Image Feature、Pooling 和 Memory。
它不是“文本模型换个 Input”这么简单。
## 推荐的企业架构
```text
Document Pipeline
↓
Chunk / Multimodal Parser
↓
Embedding Gateway
↓
vLLM
├── TPU Pool
└── GPU Fallback
↓
Vector DB
```
Query 侧：
```text
User Query
↓
Embedding Gateway
↓
Online Pool
↓
Vector Search
↓
Reranker
↓
LLM
```
## Index Pool 和 Query Pool 最好分开
Indexing 是高吞吐、能排队的任务；Query 是低延迟、用户在线等待。
如果两者共用一个 Accelerator Pool，大规模 Index Job 很容易把 Online P99 拉爆。
所以更推荐：
```text
Batch Embedding Pool
Online Embedding Pool
```
## Embedding Gateway 应统一哪些字段
至少统一：
```text
Model Version
Dimension
Normalization
Max Length
Pooling
Hardware Backend
```
尤其是 Model Version。Embedding 模型升级往往意味着 Vector Space 已变化，旧向量和新向量不应该随便混用。
## 模型升级要做双索引
不要今天切新 Embedding Model，然后拿新 Query Vector 去搜旧 Index。
更合理：
```text
Old Model → Old Index
New Model → New Index
```
做 Shadow Query、Compare、Reindex，再正式 Cutover。
## TPU 是否一定比 GPU 好
不是。
选择取决于云平台、模型支持、QPS、Batch、成本、团队经验和供应。
Google 这次真正有价值的是：
> vLLM 把 TPU 纳入主流 Serving 选择。
而不是 TPU 取代 GPU。
## 生产必须监控什么
### Performance
- token/s；
- req/s；
- P50/P95/P99；
- queue time。
### Quality
- cosine parity；
- Recall@K；
- TopK overlap；
- NDCG。
### Infrastructure
- HBM；
- compile time；
- preemption；
- autoscale。
### Business
- retrieval success；
- answer success；
- conversion。
## 最终判断
Google 这次更新真正重要的不是“Qwen3 可以跑 TPU”，而是 Embedding Serving 正在从一个被忽略的小服务，变成需要高吞吐、长上下文、跨硬件数值一致性、弹性调度和可复现能力的独立基础设施。
官方在特定 Qwen3-Embedding-8B 配置下给出：
```text
16K+
TP=4
83,996 total token/s
5.13 req/s
```
同时用非常严格的 Cosine Threshold 验证跨硬件一致性。
对生产 RAG 来说，真正应该问的不是“模型能不能跑”，而是：
> **换硬件、扩规模以后，检索结果还能不能保持一致。**
想继续了解 RAG、Embedding、vLLM 和 AI 推理基础设施，可以访问 **智元选**：https://www.zyentorpicks.com/。