AI 原生后端实战：从 QPS 思维到 TPS 架构的完整落地指南
2026-06-12 14:22:52
# AI 原生后端实战：从 QPS 思维到 TPS 架构的完整落地指南
> 适用读者：有 Spring Boot / K8s 经验的后端工程师，正在将 LLM 能力接入生产系统。
> 预计阅读：25 分钟 · 含完整配置示例与排障清单
## 一、为什么 AI 后端不能用 QPS 思维？
传统 REST API 的请求-响应模型中，**QPS（Queries Per Second）** 足以描述系统容量：每个请求占用连接时间短、CPU 可预测、内存峰值低。
AI 推理场景完全不同：
| 维度 | 传统 API | AI 推理 API |
|------|----------|-------------|
| 响应形态 | 一次性 JSON | SSE 流式 Token |
| 连接时长 | 50–500 ms | 5–300 s |
| 资源瓶颈 | CPU / DB 连接 | GPU 显存、Token 生成速率 |
| 核心指标 | QPS、P99 延迟 | **TPS**、**TTFT**、并发流数 |
| 成本模型 | 固定机器 | 按 Token 计费 |
**TPS（Tokens Per Second）** 衡量模型每秒生成的 Token 数；**TTFT（Time To First Token）** 决定用户「多久看到第一个字」。国内多数 AI 产品用户流失发生在 TTFT > 2s 时。
### 架构目标
1. TTFT P95 < 1.5s（含网关 + 路由 + 缓存命中路径）
2. 流式连接可优雅断连，不泄漏 goroutine/线程
3. 语义缓存命中率 15–40%（视业务而定）
4. Token 成本可观测、可按租户/功能分摊
---
## 二、整体架构
```
Client → CDN/WAF → API Gateway (SSE) → 模型路由层 → LLM Provider
↓ ↓
语义缓存(Redis) Function Calling → 业务微服务
↓
CDC → Embedding → 向量库(Milvus/PGVector)
```
Gateway 层负责：**鉴权、限流、SSE 代理、断连回收**；模型路由层负责：**按任务复杂度选模型、Fallback、重试**；业务层只暴露 **Tool/Function**，禁止模型直接写 SQL。
---
## 三、SSE 流式网关实现
### 3.1 Spring WebFlux 代理示例
```java
@PostMapping(value = "/v1/chat/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux> streamChat(@RequestBody ChatRequest req,
ServerHttpResponse response) {
response.getHeaders().setCacheControl("no-cache");
response.getHeaders().set("X-Accel-Buffering", "no"); // Nginx 禁用缓冲
return llmClient.stream(req)
.map(chunk -> ServerSentEvent.builder()
.data(chunk)
.build())
.doOnCancel(() -> llmClient.cancel(req.getRequestId()))
.timeout(Duration.ofSeconds(300));
}
```
**关键配置：**
- Nginx：`proxy_buffering off; proxy_read_timeout 300s;`
- K8s Ingress：调大 `proxy-read-timeout`
- 客户端断连时调用上游 cancel，避免 GPU 空跑
### 3.2 并发流限制
按租户维度限制同时打开的 SSE 连接数，推荐 **令牌桶 + 信号量**：
```yaml
# resilience4j 示例
resilience4j.ratelimiter.instances.chat-stream:
limitForPeriod: 10 # 每租户同时 10 路流
limitRefreshPeriod: 1s
timeoutDuration: 0 # 超限立即拒绝
```
超限返回 **HTTP 429**，Header 带 `Retry-After: 5`。
---
## 四、背压（Backpressure）设计
当推理队列深度超过阈值时，继续接收请求会导致：
- 内存中排队请求暴增
- TTFT 线性恶化
- 最终 OOM 或全站超时
**推荐策略：**
1. **网关层**：队列深度 > 80% → 429
2. **推理层**：动态批处理窗口收缩
3. **客户端**：指数退避重试，展示「排队中」UI
```java
if (inferenceQueue.depth() > MAX_DEPTH * 0.8) {
throw new ServiceUnavailableException("系统繁忙，请稍后重试");
}
```
国内大厂实践：在高峰时段主动 **降级到小模型** 或 **缩短 max_tokens**，比无限排队体验更好。
---
## 五、语义缓存工程落地
### 5.1 流程
1. 用户提问 → Embedding（bge-m3 / text-embedding-v3）
2. 在 Redis Vector 或 Milvus 中 ANN 检索 Top-1
3. 相似度 > 0.92（阈值需 A/B 调优）→ 直接返回缓存答案
4. 否则走 LLM，异步写入缓存
### 5.2 Redis Stack 示例
```python
# 伪代码：写入
embedding = embed(query)
redis.ft("cache_idx").add_document(
f"q:{hash(query)}",
{"query": query, "answer": answer, "embedding": embedding}
)
# 检索
results = redis.ft("cache_idx").search(
Query("*=>[KNN 1 @embedding $vec]").dialect(2),
query_params={"vec": embed(new_query)}
)
```
### 5.3 注意事项
- **敏感数据**（医疗、金融）按租户隔离索引，禁止跨租户命中
- **时效性内容**（股价、政策）TTL 不超过 1h
- **缓存污染**：用户点「答案不对」时立即失效该条目
实测国内客服场景：语义缓存可降 **40–60%** API 成本，TTFT 从 1.2s 降至 80ms。
---
## 六、CDC + 实时 RAG
静态知识库是 RAG 最大坑：业务数据变了，AI 还在念旧答案。
**推荐链路：**
```
MySQL Binlog → Canal/Debezium → Kafka → Embedding Worker → Milvus
```
1. 监听 `UPDATE/INSERT` 业务表（如产品、政策、FAQ）
2. 变更事件触发 Chunk 重新切分 + Embedding
3. 检索时带 **版本号** 过滤，避免读到半更新状态
4. 全量重建每周一次，增量实时同步
Spring 侧通过 `@Scheduled` 或 Flink 消费 Kafka，Embedding 批大小建议 32–64。
---
## 七、模型路由层
| 任务类型 | 路由策略 | 示例模型 |
|----------|----------|----------|
| 简单 FAQ | 小模型 + 高缓存 | Qwen2.5-7B |
| 复杂推理 | 大模型 | DeepSeek-V3 / GPT-4o |
| 代码生成 | 专用 Code 模型 | Qwen-Coder |
| 失败 Fallback | 降级 + 人工 | 小模型 → 工单 |
路由决策可基于：**意图分类器、Token 预估、用户等级、实时负载**。
```java
public LlmRoute resolve(ChatRequest req) {
if (semanticCache.hit(req)) return LlmRoute.CACHE;
if (intentClassifier.isSimple(req)) return LlmRoute.SMALL;
return LlmRoute.LARGE;
}
```
---
## 八、可观测性扩展
除 RED 指标外，AI 服务必须监控：
| 指标 | 说明 | 告警阈值示例 |
|------|------|--------------|
| `llm_ttft_seconds` | 首 Token 延迟 | P95 > 2s |
| `llm_tps` | Token 生成速率 | 低于基线 30% |
| `llm_tokens_total` | Token 消耗 | 日环比 +50% |
| `semantic_cache_hit_ratio` | 缓存命中率 | < 10% 异常 |
| `llm_hallucination_feedback` | 用户负反馈率 | > 5% |
OpenTelemetry 建议在 Span 中记录：`model`, `prompt_tokens`, `completion_tokens`, `route`, `cache_hit`。
---
## 九、Function Calling 边界
**禁止**：让模型直接生成 SQL 并执行。
**推荐**：注册有限 Tool，由后端校验参数后执行。
```json
{
"name": "query_order_status",
"parameters": {
"order_id": { "type": "string", "pattern": "^ORD[0-9]{8}$" }
}
}
```
领域逻辑封装在微服务内，模型只负责 **选 Tool + 填参数 + 组织自然语言**。
---
## 十、生产 Checklist
- [ ] SSE 断连上游 cancel 已验证
- [ ] Nginx/Ingress 关闭缓冲、超时 ≥ 300s
- [ ] 按租户限流 + 429 背压
- [ ] 语义缓存租户隔离 + 负反馈失效
- [ ] CDC RAG 增量同步延迟 < 5min
- [ ] Token 成本按功能/租户分摊报表
- [ ] TTFT/TPS 大盘 + 告警
---
## 小结
AI 原生后端不是「把 HTTP 接口换成 OpenAI SDK」——它要求团队在 **连接管理、背压、缓存、知识同步、模型路由、可观测性** 六个维度重新设计。国内 2026 年落地较成熟的团队，普遍已将 TPS/TTFT 纳入 SLO，并与 FinOps 打通 Token 成本治理。
> 延伸阅读：Spring AI Alibaba、LangChain4j、阿里 Higress AI 网关文档；InfoQ《AI 工程化》系列。