第九篇：降级矩阵与 Token 限流 —— 生产系统的八道防线
·
生产系统不是在"一切正常"时体现价值的，是在"一切都在崩"的时候。
最坏情况推演
如第一篇决策5所述的最坏情况推演（Qwen API 超时 + Milvus OOM + Redis 断连 + BGE Embedding 挂了 + NebulaGraph 不可用），系统能退化到"Qwen2.5-1.5B-Instruct 本地 GPU 推理，无 RAG 增强直接回答"。不是完美的回答，但不是 500。基于这个推演，我们为此设计了以下八维降级矩阵。
降级
每条链路至少两条退路，独立降级：
路由层
| 功能点 | L1 | L2 | L3 |
|---|---|---|---|
| 意图识别 | 规则过滤 | FAISS 向量匹配 | LLM → RAG 兜底 |
| 参数抽取 | 纯正则 | 本地 Qwen3-1.7B | 云端 LLM |
| 工具选择 | 规则过滤 | FAISS HNSW | —（P0+P1 已覆盖，无需额外层） |
数据层
| 功能点 | L1 | L2 | L3 |
|---|---|---|---|
| Embedding | 本地 BGE | 切 BM25 | 空上下文（LLM 通用知识） |
| 图查询 | NebulaGraph | 返回空 | 不影响主线 |
保护层
| 功能点 | L1 | L2 | L3 |
|---|---|---|---|
| 速率限制 | Redis 滑动窗口 | 内存 Fallback | 仅限请求数 |
| Token 预估 | HF tokenizers | 字符估算 | 跳过限流 |
| 内容安全 | 规则引擎 | 本地 LLM | 云端 LLM |
Token 限流：为什么请求次数是最差的指标
A 用户每次只问"在吗"，B 用户每次发 5000 字投诉——对 LLM 压力天差地别。
HF tokenizers 方案：100% 精度 + 11MB 依赖 + <200ms 加载。比 tiktoken（85%）准，比 transformers（500MB+）轻。LRU 缓存命中率 >80%，多轮对话只需首次编码。
三阶段限流：Pre-check 预估 → LLM 调用 → Post-report 修正。
降级 UX：什么时候告诉用户？
- P2→云端 LLM（延迟 80→300ms）：不告知
- LLM→P1 Top-1（准确率 95%→85%）：不告知，记录 flag
- 全部不可用→必须告知
原则：降级是内部韧性，不是用户负担。
北京人形旗下天工造物具身智能开源社区，聚焦具身天工与慧思开物两大平台
更多推荐
8
0- 0
已为社区贡献2条内容
所有评论(0)