主题
高频面试题
推理优化
面试官问推理优化，不是要求前端开发手写 CUDA，而是看你能不能解释 AI 应用为什么慢、为什么贵、慢在哪里，以及应用侧能怎么优化。
面试官角度分析，想考什么
LLM 推理为什么比普通接口慢？
考你能否把慢归因到 prefill、decode、排队、工具链路和网络，而不是笼统说“模型大”。KV Cache、batching、量化、speculative decoding 分别优化什么？
考机制差异：有的省重复计算，有的省显存，有的提吞吐，有的加速输出。应用开发侧能做哪些优化，边界在哪里？
考工程取舍：token 控制、RAG 精筛、缓存、模型路由、异步任务、streaming、指标拆分和降级。
可直接抄走的 30 秒参考答案
text
LLM 推理慢主要因为它先用 prefill 处理整段 prompt，再自回归地一个 token 一个 token decode。KV Cache 能避免重复计算历史上下文，但会占显存；batching、PagedAttention、量化、speculative decoding、prefix caching 分别优化吞吐、显存、带宽、decode 和重复前缀。应用侧不一定改推理引擎，但可以减少无效 token、做 RAG 精筛、缓存、模型路由、异步任务和 streaming，并用 TTFT、tokens/sec、总延迟、排队时间和工具耗时定位瓶颈。面试回答详解，知其所以然
这道题的核心不是列优化名词，而是能沿着一次请求的生命周期定位瓶颈。只有知道慢在哪里，才知道该压 prompt、换模型、开缓存、做异步，还是优化工具调用。
1. 先区分 prefill、decode、排队和工具耗时
text
prefill：处理完整 prompt，生成首个 token 所需的上下文状态
decode：每次基于历史状态生成下一个 token输入越长，prefill 越慢；输出越长，decode 越久。前端感知到的首字延迟主要和 prefill、排队、工具调用和网络有关；用户拿到完整答案的总耗时，则更多受输出长度、tokens/sec 和中间工具链路影响。
所以指标要拆开看：
- TTFT：首 token 时间，影响“是不是卡住”的感知。
- tokens/sec：生成速度，主要影响长回答。
- 总延迟：用户拿到完整结果的时间。
- input/output token：成本来源，也是 prefill/decode 压力来源。
- queue time：高峰期常被误判为模型慢。
- tool latency：Agent 或 RAG 链路里经常比模型本身还慢。
2. 服务端优化手段各自解决不同瓶颈
自回归生成时，历史 token 的 Key/Value 不会改变，可以缓存起来，避免每一步重新计算全部历史。
KV Cache 降低计算，但占显存。长上下文、高并发、大 batch 都会放大 KV Cache 压力。
- Continuous batching：把不同时间到来的请求动态合批，提高 GPU 利用率。
- PagedAttention：更高效管理 KV Cache，减少显存碎片。
- 量化：用更低精度表示权重或 KV Cache，降低显存和带宽压力。
- Speculative decoding：小模型先草拟 token，大模型验证，加速 decode。
- Prefix caching：复用相同 prompt 前缀的 KV 结果。
这些手段多数属于模型服务或推理平台层。应用开发岗位不一定要实现它们，但要知道它们优化的对象：吞吐、显存、带宽、首字延迟、decode 速度或重复 prompt 成本。
3. 应用侧优化重点是少算、早返回、可降级
即使不做底层推理引擎，AI 应用开发也能优化很多：
- 减少输入 token：压缩 system prompt、摘要历史消息、RAG 只放高质量证据，不把全文塞给模型。
- 控制输出 token：合理设置
max_output_tokens，让模型先给结论，长内容分段生成。 - 缓存稳定内容：热门问题、检索结果、摘要、稳定 prompt 前缀都可以缓存。
- 模型路由：简单任务走小模型，复杂推理和高风险任务走强模型。
- 异步化长任务：调研、代码分析、批量处理不要伪装成普通同步接口。
- streaming 和进度事件：降低用户感知等待，允许中断，长任务展示阶段性状态。
- 降级策略：限流或超时时可以切轻量模型、减少上下文、排队、返回部分结果或转人工。
面试里要避免两个误区：Streaming 主要改善体验，不直接减少总计算；长上下文能放更多内容，但会增加 prefill、KV Cache 和噪声成本。
面试官追问3个问题
追问一：Streaming 能减少推理成本吗？
- 考察点：体验和计算的区别。
- 回答方向：通常不减少总计算，它只是让用户更早看到首 token，降低等待焦虑。但 streaming 可以支持提前中断、边生成边渲染、边生成边审核，所以可能间接减少无用输出和用户重试。
追问二：长上下文为什么会拖慢服务？
- 考察点：prefill 和 KV Cache。
- 回答方向：输入越长，prefill 要处理的 token 越多；生成时 KV Cache 也更大，高并发下显存和带宽压力更明显。长上下文还可能引入位置偏置和噪声，模型并不一定稳定利用所有信息，所以要配 RAG 精筛、摘要和缓存。
追问三：应用开发如何判断该换模型还是优化 prompt？
- 考察点：定位能力。
- 回答方向：先看 trace：输入 token、输出 token、TTFT、tokens/sec、queue time、工具耗时和失败类型。如果 TTFT 高且输入很长，先压 prompt、做 RAG 精筛或 prefix cache；如果 decode 慢且输出长，控制输出或换更快模型；如果任务质量不足，再考虑强模型或分阶段路由。
扩展知识
优化方向对应关系
text
输入长 -> 压缩 prompt / prefix cache / RAG 精筛
输出长 -> 控制 max tokens / streaming / speculative decoding
并发高 -> batching / KV 管理 / 模型路由
成本高 -> 小模型 / 缓存 / 量化 / 减少 token相关资料
Hugging Face KV Cache 适合理解自回归推理为什么要缓存历史 K/V；vLLM PagedAttention 适合理解 KV Cache 显存管理；OpenAI Latency Optimization 适合理解应用侧如何从 token、模型、streaming 和并行化角度降低延迟。