推理系统总体架构解剖：七层全景图

一个生产级推理系统（inference system）不是「一个模型 + 一个 Flask」，而是七层结构的系统工程：请求入口、服务层、推理引擎、资源层，以及横切的三个支撑面——数据与版本、可观测性、治理。本文先用一张全景图立住框架，再逐层拆解职责、选型与常见故障，最后用一个请求的生命周期把七层串起来。

一句话：推理系统 = 让「请求 → 预测」稳定、低成本、可观测地发生的所有组件之和。

一、整体架构：七层全景图

                          客户端（App / Web / 上游服务）
                                     │
                                     ▼
┌───────────────────────────────────────────────────────────────────┐
│ ① 请求入口层                                                       │
│   网关/负载均衡：路由、鉴权、限流、超时（Nginx / Envoy / API 网关）    │
├───────────────────────────────────────────────────────────────────┤
│ ② 服务层                                                           │
│   API（REST/gRPC）→ 预处理（tokenize/归一化）→ 推理调度 → 后处理      │
│   FastAPI / Triton / KServe / vLLM                               │
├───────────────────────────────────────────────────────────────────┤
│ ③ 推理引擎层                                                       │
│   图优化、量化内核、批处理执行器（ONNX Runtime / TensorRT / vLLM）    │
├───────────────────────────────────────────────────────────────────┤
│ ④ 资源层                                                           │
│   GPU / CPU / 内存 / 网络，K8s 节点与调度                            │
├───────────────────────────────────────────────────────────────────┤
│ ⑤ 数据与版本层（横切）                                              │
│   模型注册（MLflow）、特征版本、tokenizer/vocab 版本                  │
├───────────────────────────────────────────────────────────────────┤
│ ⑥ 可观测性层（横切）                                                │
│   指标（Prometheus）、日志、链路追踪、漂移检测                        │
├───────────────────────────────────────────────────────────────────┤
│ ⑦ 治理层（横切）                                                    │
│   灰度、回滚、容量规划、安全与配额                                    │
└───────────────────────────────────────────────────────────────────┘

读图顺序建议：先看懂纵向主线 ①→④（请求怎么被打成预测），再理解三个横切面 ⑤⑥⑦（它们不参与计算，但决定了系统能不能长期活着）。

主线的记忆锚点

入口管进、服务管编、引擎管算、资源管跑——四层主线的职责一次记住。

二、逐层拆解：职责、选型与故障

1. 请求入口层：管「谁可以进来」

• 职责：负载均衡、路由、鉴权、限流（rate limiting）、超时熔断、TLS 终止。
• 典型选型：Nginx、Envoy、Kong；K8s Ingress；云上 API 网关。
• 常见故障：入口层健康检查探活失败导致全部流量被摘除；限流配置过松，请求洪峰直接打穿到服务层。
• 排查方向：看网关访问日志与延迟分布，区分「没进来」与「进来后慢」。

2. 服务层：管「把请求编成一次推理」

• 职责：解析请求、输入校验、预处理（图像 resize、文本 tokenize）、组装推理请求、后处理（softmax 转分数、decode）、组装响应。动态批处理（dynamic batching）策略也在这层编排。
• 典型选型：FastAPI、Triton、vLLM、KServe；LLM 场景由 vLLM/Triton 直接承担服务与调度。
• 常见故障：请求 schema 不匹配（缺字段、类型错）、预处理慢于推理、批处理策略不当导致长尾延迟（head-of-line blocking）。
• 排查方向：把「预处理耗时 / 推理耗时 / 后处理耗时」拆开埋点，见 可观测性实践。

服务层的两种形态

传统 CV/NLP 模型常是「自己写 FastAPI 调用引擎」；LLM 模型则普遍用 vLLM 这类「引擎+服务一体化」框架，服务层与引擎层被合并。形态不同，但「编排」职责不变。

3. 推理引擎层：管「算得快」

• 职责：把模型图优化成高效执行计划——算子融合（operator fusion）、量化内核（INT8/FP16）、显存复用、批处理内核执行。
• 典型选型：ONNX Runtime（跨平台）、TensorRT（NVIDIA GPU 极致性能）、vLLM（LLM 调度 + PagedAttention）、OpenVINO（Intel CPU）。选型对比见 推理引擎对比。
• 常见故障：引擎不支持某算子导致回退到慢路径（fallback）；显存碎片/OOM；量化后精度漂移。
• 排查方向：引擎 profiling 工具（NVIDIA Nsight、ONNX Runtime profiler）定位到算子级耗时，详见 性能优化。

4. 资源层：管「有机器可跑」

• 职责：GPU/CPU 算力、显存、内存、网络带宽的供给与调度；节点扩缩容。
• 典型选型：Kubernetes 节点池、GPU 共享调度（如 MIG、时间片）、Serverless 自动伸缩。
• 常见故障：GPU 显存被邻居 Pod 打满、节点 OOM 导致 Pod 被杀、冷启动拉镜像慢。
• 排查方向：看 K8s 事件与节点指标，区分「资源不足」与「代码浪费资源」。

5. 数据与版本层（横切）：管「用的是哪一版模型」

• 职责：模型版本登记（model registry）、镜像标签、特征版本、tokenizer/vocab 对齐。这是模型系统最容易「静默出错」的一层：模型换了，特征没跟上。
• 典型选型：MLflow Model Registry、Hugging Face Hub、自建版本表。
• 常见故障：线上推理用的特征口径与训练不一致；新模型上线但缓存了旧特征。
• 排查方向：对比模型/特征版本的 git commit 与上线时间戳。完整流程见 MLOps 流水线。

6. 可观测性层（横切）：管「有没有在悄悄变坏」

• 职责：指标（延迟、吞吐、错误率、GPU 利用率）、日志、链路追踪、漂移检测、告警。
• 典型选型：Prometheus + Grafana、OpenTelemetry、ELK/Loki、漂移检测脚本。
• 常见故障：指标采样过粗抓不到偶发尖峰；没有告警，漂移发生数周无人察觉。
• 排查方向：先看 SLO 指标再下钻日志，指标体系设计见 监控。

7. 治理层（横切）：管「变更和风险」

• 职责：灰度发布、回滚、容量规划、配额、安全与合规（模型权限、数据脱敏）、模型审计。
• 典型选型：K8s 滚动更新、Argo Rollouts、网关灰度（A/B、金丝雀）、模型审计日志。
• 常见故障：全量发布新版本出问题只能整体回滚；灰度流量切分不均影响实验结论。
• 排查方向：灰度实践见 网关灰度发布，安全基线见 模型安全。

三、一个请求的生命周期走查

把七层串起来，看一个 HTTP 请求如何变成预测：

1. App 发起 POST /predict（JSON：{feature_a: 0.7, text: "..."}）
     ↓ ① 请求入口层
2. 网关：鉴权通过 → 限流计数 → 按路由转发到服务 Pod
     ↓ ② 服务层
3. API 解析请求、校验 schema；不合法返回 422
4. 预处理：文本 tokenize / 图像 resize + 归一化
5. 组装 batch（动态批处理把 4 个请求合成一个 batch）
     ↓ ③ 推理引擎层
6. 引擎执行图：算子融合后的前向计算，INT8 内核，显存复用
7. 返回原始输出（logits / embedding）
     ↓ ② 服务层
8. 后处理：softmax → top-k 分数 / detokenize 文本
9. 组装响应 JSON（含延迟头信息）→ 返回 App
     ↓ ⑥ 可观测性层（全程旁路记录）
10. 上报 latency 直方图、batch 大小、错误码到 Prometheus
     ↓ ⑤ 数据与版本层（旁路校验）
11. 记录本次请求使用的模型版本与特征版本，供审计与回放

关键观察：①→④ 决定快不快，⑤→⑦ 决定稳不稳。面试中被问「请求会经过哪些层」，按主线 ①→④ 答完，再补三个横切面，就是满分结构。

四、层间契约：系统稳定靠协议，不靠自觉

层与层之间必须有明确契约（contract），否则任何一层升级都可能震碎上下游：

契约点	内容	破坏后的表现
输入输出 schema	字段名、类型、取值范围、缺省策略（JSON Schema / gRPC proto）	上游新老版本混发，解析报错
批处理协议	单条 vs 批量、batch 上限、超时语义	批处理错乱，长尾延迟失控
错误语义	4xx/5xx 划分、错误码、重试安全（幂等性）	重试放大故障（重试风暴）
版本对齐	模型版本 ↔ 特征版本 ↔ 引擎版本 ↔ 镜像标签	静默精度退化，难以定位

最容易忽略的契约：重试

网关层通常会重试 5xx。如果推理接口不幂等（如重复扣费类推理），一次超时可能触发三次执行。契约里必须写清「哪些错误可以重试、重试几次、是否退避」。

服务层契约的完整设计见 模型服务。

五、故障在每层的表现：从症状定位到层

同一个故障症状，可能来自不同层。排查的第一步是用症状反定位到层：

症状	最可能所在层	验证方法
全部请求超时	① 入口层（网关配置/上游不可达）	网关日志 + 健康检查状态
偶发 P99 飙升	② 服务层（批处理排队）	分阶段耗时拆分
稳定变慢	③ 引擎层（fallback 到慢算子）	引擎 profiler
OOM / 显存溢出	④ 资源层	节点指标 + 引擎显存日志
结果对但偶尔错	⑤ 版本层（特征口径漂移）	版本对比 + 样本回放
线上静默变差	⑥ 可观测性层（漂移未告警）	漂移检测指标趋势
新版本上线后异常	⑦ 治理层（灰度没拦住）	灰度日志 + 回滚

排查口诀

先分阶段再下钻：先把「请求进来到出去」拆成网关、服务、引擎、资源四段埋点，哪段慢就进哪段；不要一开始就怀疑引擎算子，八成问题在服务层与资源层。完整排查方法论见 常见坑点。

六、七层架构怎么用：三类人三种用法

• 部署工程师：把 ①→④ 当「性能与稳定性地图」，把 ⑥⑦ 当「日常操作面板」，优化永远从量化过的瓶颈出发。
• 算法工程师：理解 ⑤ 的关键性——「我训好的模型为什么线上不灵」，一半答案在特征与版本对齐。
• 面试者：本文的架构图与生命周期走查就是一份可复述的「系统设计」框架，配合 面试题 练到能默画。

延伸阅读

• 什么是模型部署 —— 七层架构背后的定义与四要素
• 模型服务 —— 服务层（②）的批处理与接口设计
• 性能优化 —— 引擎层（③）与资源层（④）的优化方法论
• 监控与漂移检测 —— 可观测性层（⑥）的指标体系
• MLOps 流水线 —— 数据与版本层（⑤）的流程支撑
• 网关灰度发布 —— 治理层（⑦）的一个完整实战

参考资料

• The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction（IEEE 2017）
• Uber – Michelangelo：机器学习即服务架构实践
• Netflix – 机器学习基础设施的演进
• Martin Fowler – Continuous Delivery 与部署管道（部署自动化参考）
• Prometheus 官方文档（可观测性层指标工具）