LLM 推理服务架构设计¶

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

这章解决什么问?¶

很多候选人讲推理服务时会停留在? - 前面一个网?- 后面一个模型服?- 再加个缓? 这还不够。真实推理服务设计至少要回答? - 请求如何调度 - 模型如何路由 - GPU 如何利用 - 不同长度请求如何共存 - 高峰和故障怎么处理 - 成本如何控制

先讲?LLM 推理为什么特?¶

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

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

一个合格的主链?¶

图源：Google Cloud GKE 教程 - Build and deploy an agentic AI application with ADK and vLLM on GKE，许可：CC BY 4.0。当前主图强调 CPU 业务层与 GPU 推理层分离部署。

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

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

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

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

1. 接入?¶

负责? - 鉴权 - 限流 - 请求合法性校?- 输入长度控制 - 基本内容安全

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

2. 路由?¶

这是非常关键的一层? 你要解释? - 为什么不是所有请求都走同一个模?- 什么请求走小模?- 什么请求走大模?- 什么请求直接拒绝或降级

一个成熟表?¶

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

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 为什么占显存
• 为什么长上下文和高并发都让它更重
• 如何通过分页、量化和共享来优?

一个够用的表达¶

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

2. Continuous Batching¶

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

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

continuous batching 的价值是? - 让空出的 slot 及时填充新请?- 提升 GPU 利用?- 减少短请求被长请求拖?

3. Prefix Caching¶

在很多企业应用里很有用，因为? - system prompt 重复 - 角色设定重复 - 工具说明重复

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

4. Speculative Decoding¶

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

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

适合回答成：

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

5. 量化与多模型?¶

真实系统里，成本和容量往往比“最强效果”更重要? 所以经常需要：

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

这类题怎么做规模估?¶

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

至少?5 个量¶

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

一个简单示?¶

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

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

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

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

常见成本?¶

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

常见优化手段¶

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

一个成熟说?¶

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

稳定性和降级怎么?¶

这类题不能只讲性能，必须讲可用性? 建议你固定讲下面这些? - 队列过长时背?- 长请求走慢车?- GPU 故障自动摘除 - 大模型池不足时降级到小模?- 超长输入先压缩或拒绝 - 关键路径超时时返回保守结?

一个很像生产的表达¶

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

灰度和回滚怎么?¶

推理服务和普通服务一样，也必须灰度? 建议你讲? - 影子流量 - 小流量分?- 指标对比 - 自动回滚

指标不要只看延迟，还要看? - 输出质量 - 错误?- 用户投诉 / 差评 - 单请求成?

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

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

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

答：

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

2. 为什?prefill ?decode 要分开?¶

答：

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

3. GPU 掉了怎么?¶

答：

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

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

答：

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

5. 如何处理超长输入¶

答：

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

一个适合面试的结?¶

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

本章小结¶

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

下一?¶

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

⚠️ 核验说明（2026-03-26）：本页已纳入 2026-03-26 全站统一复核批次。若文中涉及外部模型、API、版本号、价格或第三方产品名称，请以官方文档和实际运行环境为准。

最后更新日期： 2026-03-26