LLM 推理服务架构设计¶

这类题是 AI Infra / 推理平台 / 大模型系统工程 岗位的核心题型。到 2028，面试官不只会问“怎么部署模型”，而会直接追到 prefill / decode、KV Cache、批处理、路由、容量、成本 和 降级策略。

这章解决什么问题¶

很多候选人讲推理服务时会停留在：

• 前面一个网关
• 后面一个模型服务
• 再加个缓存

这还不够。真实推理服务设计至少要回答：

• 请求如何调度
• 模型如何路由
• GPU 如何利用
• 不同长度请求如何共存
• 高峰和故障怎么处理
• 成本如何控制

先讲清 LLM 推理为什么特殊¶

LLM 推理和普通分类模型推理的差别非常大：

所以推理服务设计题的关键，不只是模型本身，而是运行时调度。

一个合格的主链路¶

客户端请求
→ 鉴权 / 限流 / 参数校验
→ 请求分类与模型路由
→ 调度与排队
→ 推理执行（prefill / decode）
→ 流式输出
→ 计量 / 日志 / 监控
→ 反馈到容量与扩缩容系统

你最好一开始就按这条主线讲。

面试里一定要主动提的 6 层¶

只讲模型和 API 远远不够，真正像平台工程师的回答通常会主动把下面 6 层补齐。

1. 接入层¶

负责：

• 鉴权
• 限流
• 请求合法性校验
• 输入长度控制
• 基本内容安全

这层不是亮点，但不提会显得系统不完整。

2. 路由层¶

这是非常关键的一层。

你要解释：

• 为什么不是所有请求都走同一个模型
• 什么请求走小模型
• 什么请求走大模型
• 什么请求直接拒绝或降级

一个成熟表达¶

我会做模型分层路由：简单总结、分类或短回复优先走小模型；复杂推理、代码生成或高价值请求再走大模型。这样可以同时控制延迟和成本。

3. 调度与队列层¶

这层是 LLM 服务和普通 API 最大的差异之一。

你可以讲：

• 优先级队列
• 请求长度分桶
• 背压
• 慢请求隔离

为什么重要¶

因为长请求会明显拖慢整体 decode 阶段。

4. 推理执行层¶

这层要讲得更细一点。

必须知道的 2 个阶段¶

Prefill¶

• 处理输入上下文
• 通常计算量大
• 对长 prompt 特别敏感

Decode¶

• 逐 token 生成
• 对请求并发和 KV Cache 管理特别敏感

如果你能主动区分这两阶段，Infra 方向面试官会更认可。

5. 缓存与状态层¶

常见对象：

• prefix cache
• session / conversation state
• KV Cache
• 热门结果缓存

如果你做的是企业应用推理服务，还可以补：

• prompt 模板缓存
• RAG 结果缓存

6. 运维治理层¶

至少要讲：

• 指标监控
• GPU 利用率
• 队列长度
• 错误率
• 扩缩容
• 灰度和回滚

这部分决定答案有没有“生产感”。

推理服务最核心的 5 个技术问题¶

这 5 类问题几乎覆盖了推理服务从“能跑”到“可规模化”的主要矛盾。

1. KV Cache¶

这是 LLM 推理题的高频点。

你要讲清什么¶

• KV Cache 为什么占显存
• 为什么长上下文和高并发都让它更重
• 如何通过分页、量化和共享来优化

一个够用的表达¶

LLM decode 阶段需要缓存历史 token 的 key/value，随着并发和上下文增长，KV Cache 会迅速成为显存瓶颈。所以我会优先关注分页管理、量化和 prefix 复用。

2. Continuous Batching¶

如果你不提这一点，推理题很容易显得偏初级。

核心点：

• 请求不是同时到达
• 输出长度不一致
• 固定 batch 利用率低

continuous batching 的价值是：

• 让空出的 slot 及时填充新请求
• 提升 GPU 利用率
• 减少短请求被长请求拖住

3. Prefix Caching¶

在很多企业应用里很有用，因为：

• system prompt 重复
• 角色设定重复
• 工具说明重复

如果命中率高，收益会非常可观。

4. Speculative Decoding¶

你不一定要讲得非常底层，但最好知道它是：

• 小模型先草拟
• 大模型验证
• 用一致率换速度

适合回答成：

在高成本大模型场景下，可以用 speculative decoding 降低 decode 阶段平均延迟，但要评估草稿模型和主模型的一致率，否则收益不稳定。

5. 量化与多模型池¶

真实系统里，成本和容量往往比“最强效果”更重要。

所以经常需要：

• 小模型池
• 大模型池
• 量化后的服务池
• 专项模型池（代码、多模态、推理）

这类题怎么做规模估算¶

你不用算得很精，但要算得足以支持架构选择。

至少估 5 个量¶

• 平均 QPS
• 峰值 QPS
• 平均输入 token
• 平均输出 token
• 每层模型路由比例

一个简单示例¶

如果日调用 1 亿次，
平均 QPS 约 1157，
峰值按 3 倍估算约 3500。
假设只有 20% 请求真正需要大模型，
那么大模型池和小模型池的容量规划就必须分开做，而不能一刀切。

这种估算就已经很够用了。

成本怎么答才像真实系统¶

面试官非常关心你是否有成本意识。

常见成本项¶

• GPU
• 存储
• 网络
• 模型 license 或 API 费用
• 缓存和向量服务

常见优化手段¶

• 模型路由
• 量化
• prefix cache
• 语义缓存
• prompt 压缩
• 低峰缩容

一个成熟说法¶

我不会默认所有请求都用最强模型，而是通过路由、缓存和量化把大模型只留给真正需要高质量推理的请求。

稳定性和降级怎么答¶

这类题不能只讲性能，必须讲可用性。

建议你固定讲下面这些：

• 队列过长时背压
• 长请求走慢车道
• GPU 故障自动摘除
• 大模型池不足时降级到小模型
• 超长输入先压缩或拒绝
• 关键路径超时时返回保守结果

一个很像生产的表达¶

如果高峰期大模型池拥塞，我会优先保证小模型和核心场景可用，对低优先级大模型请求做降级、排队或限流，而不是让全系统一起超时。

灰度和回滚怎么讲¶

推理服务和普通服务一样，也必须灰度。

建议你讲：

• 影子流量
• 小流量分桶
• 指标对比
• 自动回滚

指标不要只看延迟，还要看：

• 输出质量
• 错误率
• 用户投诉 / 差评
• 单请求成本

这类题最常见的高频追问¶

真正拉开差距的，通常不是主流程，而是这些围绕性能、容量和故障场景的追问。

1. 为什么需要把请求按长度分桶¶

答：

• 长短请求混在一起会拖慢 decode
• 更利于 batch 效率和延迟稳定性

2. 为什么 prefill 和 decode 要分开看¶

答：

• 优化重点不同
• 长 prompt 和长输出的瓶颈不同
• 资源调度策略也可能不同

3. GPU 掉了怎么办¶

答：

• 健康检查
• 自动摘除
• 重试和重路由
• 多 AZ / 多池冗余

4. 如何降低大模型调用占比¶

答：

• 路由分类
• 缓存
• 小模型先处理
• 复杂请求识别

5. 如何处理超长输入¶

答：

• 截断
• 摘要压缩
• 检索增强只保留关键信息
• 拒绝不合规请求

一个适合面试的结尾¶

LLM 推理服务设计的核心不只是把模型跑起来，而是围绕 prefill/decode、KV Cache、批处理、路由和容量做系统级优化。
如果继续扩展，我会优先做模型池分层、成本治理和更细粒度的流量调度。

本章小结¶

• 推理服务题的重点是 runtime 和资源调度，不只是模型部署
• 高质量答案必须覆盖：路由、队列、prefill/decode、KV Cache、批处理、稳定性、成本
• 2028 面试里，能主动讲到容量和降级策略的候选人会更有优势

下一步¶

• 继续看 07-AI 系统设计高频追问与深度题
• 如果偏平台方向，再看 06-大模型训练平台设计
• 如果偏应用方向，结合 02-RAG 系统设计深入 一起准备