标准回答
一、先给出结论和背景
- 先区分成本与延迟，再分别下手：成本主要由 Token 量 × 单价决定，延迟由模型大小、输出长度、网络与排队共同决定。要按「质量-成本-延迟」三角，针对瓶颈逐项优化。
- 模型路由与分级：用一个轻量分类器或小模型判断请求难度，简单任务交给小模型/SLM、复杂任务才用大模型；同理可把「判断/路由」用小模型做、「最终合成」用大模型做，显著降本（见 Token 经济学）。
二、拆开关键步骤和判断点
- 缓存：精确缓存命中相同请求；语义缓存对相似问题复用答案；Prompt 前缀缓存复用固定 system/few-shot 部分的 KV Cache，降低首 Token 时延与成本。
- 延迟优化：流式输出（streaming）大幅降低用户感知延迟；并行化相互独立的检索/工具调用；控制输出长度、减少 RAG 注入的片段数；选用就近区域部署与更快推理引擎（如 vLLM/TGI）。
三、补上落地边界和取舍
- Prompt 与批处理：压缩上下文、去冗余指令、用 Prompt 压缩技术；离线/高吞吐场景用批处理与连续批处理（continuous batching）提升 GPU 利用率。
常见误区
⚠️ 常见踩坑
误区一：容易答偏的地方：别一上来就「全量换小模型」省钱——盲目降级会损失质量、引发更多重试与人工兜底，反而更贵；应先按请求难度路由，并用评测集守住质量底线。
追问
追问 1：语义缓存如何避免「相似但答案不同」的错误命中？
设较高的相似度阈值，并对缓存命中加二次校验（如比对关键实体/约束）；对时效性强或带个性化参数的请求禁用缓存，按命中后果分级控制。
追问 2：Prompt 前缀缓存为什么能降首 Token 时延？
把固定的 system/few-shot 前缀的 KV Cache 复用，模型无需对这部分重新做 Prefill 计算，直接从缓存继续，减少了首 Token 前的计算量，省时也省成本。
追问 3：流式输出降低的是真实延迟还是感知延迟？
主要是感知延迟：用户在首 Token 后即可看到内容逐步产出，总生成时间不变甚至略增，但体验显著改善；对需要完整结构化结果的场景收益有限。
🔗 相似问题
同一考点的不同问法，换着练更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习
