实时 AI 面试只谈模型不谈成本和延迟，为什么很难过追问

面试官问“怎样把实时 AI 做得又快又便宜”，最容易失分的回答，是直接报一个更快的模型，再补一句开启 streaming。追问很快就会到来：快是第一段文字更早出现，还是完整答案更早结束？便宜是单次请求少花钱，还是高峰期少扩容？如果质量下降导致用户重试，成本真的降了吗？

这道题不是让你背某个供应商的价格表，而是考你能否先定义体验与质量，再把每项优化放回同一组可测指标中。

先问用户能等多久、错一次有多贵

第一层回答常从模型开始，高分回答先从场景开始。实时语音问答、长文总结和离线批处理对等待的容忍完全不同；一句澄清提示、一道系统设计解释和一段可直接朗读的回答，对长度与正确性的要求也不同。因此不存在可以套给所有实时 AI 的通用延迟目标。

先定义质量底线：哪些事实不能错，答案至少要覆盖哪些要点，允许多短，何时宁可拒答或请求补充信息。再定义用户可见的等待预算：多久必须出现可用反馈，多久必须完成主要内容，超过什么条件进入降级或超时。这里的预算是产品假设，必须被实验验证，不是行业常数。

“错一次有多贵”决定优化空间。低风险建议可以用较小模型先给方向，高风险判断可能需要更多上下文、校验或更稳的模型。若快速答案经常被用户追问、重试或人工修正，单次账单虽低，总会话成本和信任损失反而更高。

面试时可以把目标写成四组指标：质量通过率、首段可见时间、完整答案时间和单位任务成本，再补充超时率、重试率与降级率。这样后续每个选择都有可比较的落点。

如果面试官继续追问为什么不先选最强模型，可以用工程约束选型框架说明：模型只是候选方案，质量底线、预算、可靠性和可运维性才是决策输入。

首 token、完整答案和感知延迟不是一个指标

首 token 时间描述请求发出后，用户何时看到模型输出的第一部分；完整答案时间描述最后一部分何时结束；感知延迟还受界面反馈、转写稳定性、输出是否立即有用和用户是否需要继续等待影响。把三者混成“平均响应两秒”，会掩盖真正瓶颈。

例如，流式输出可能让第一句话更早出现，从而改善感知等待，但它不保证完整生成更快。输出很长时，用户仍可能在关键结论到来前等待；如果前半段不稳定、不断改口，早出现也未必更可用。因此要同时记录首 token、有效首句、完整答案和中止比例。

延迟还应拆成链路：输入准备、网络、排队、模型首 token、持续生成、后处理和渲染。多个串行 LLM 请求会累计等待；可独立的检索或校验有时可以并行，但并行也会增加资源占用、取消管理和失败合并成本。不能看到某段慢，就默认把所有步骤并发。

平均值也不够。面试官通常会追问高峰期和长尾请求，因此应展示分位数、并发量、输入输出长度分布与错误率。只有工作负载一致，优化前后的数字才可比较。

实时语音场景还要把转写稳定性与回答质量连起来，实时语音答案质量可以帮助你避免把上游识别错误误判成模型延迟或生成质量问题。

缓存、短输出、小模型分别省什么、牺牲什么

缩短输出通常直接减少生成工作，也可能同时降低完整答案时间与输出费用，但前提是没有删掉任务所需信息。做法不是粗暴设置更小上限，而是先要求答案先给结论、控制重复、按场景选择详细度，并观察用户是否因信息不足再次提问。

较小模型可能降低单次成本与部分请求的等待，但质量变化取决于任务。意图分类、格式转换和低风险摘要，可能适合较轻模型；复杂权衡、证据冲突或高风险回答，可能需要更强模型或校验。路由的价值来自任务分层和可测结果，不来自“大小模型混用”这句架构口号。

Prompt caching 主要利用可重复的上下文。稳定系统指令、重复知识前缀或固定示例可能受益，动态问题和频繁变化的事实则未必命中。供应商的计费、缓存单位、有效期与命中规则并不相同，发布或面试引用时必须标明当前文档条件。还要测命中率、未命中退化、新鲜度和失效后的突发负载。

路由与 fallback 也不是免费保险。主模型失败后切换备用模型，会增加一次调用、延长尾部等待，还可能改变回答风格。更成熟的说法是：只为明确失败类别设计降级，并规定质量底线、尝试预算和停止条件。

用实验回答扩容与降级追问

先建立代表性请求集，覆盖短问、长上下文、不同输出长度、缓存可命中与不可命中、高峰并发和供应商错误。每个方案使用相同输入与评分标准，记录质量、首 token、完整答案、成本、超时、重试和降级结果。不要用一组短提示测出的漂亮数字代表全部线上流量。

实验可以按单变量推进：先缩短输出并验证覆盖率，再比较模型；随后测试缓存命中与失效；最后加入路由、并行和 fallback。一次同时改六项，即使数字改善，也难以解释是哪项起作用，更无法回答回滚哪一步。

保留未优化基线同样重要。只展示新方案的最好一次结果，无法判断收益来自缓存预热、低峰网络还是样本变短。每轮实验都应保存配置、请求分布、供应商条件和测量时间，并重复运行到结果足够稳定。这样价格或模型版本变化后，团队可以用同一方法重测，而不是继续引用已经失效的数字。

容量追问要把排队与推理分开。并发升高后，如果主要问题是队列等待，盲目换模型未必解决；如果输出生成占主导，就应先检查答案长度、批处理条件或模型选择。扩容方案还要说明限流、优先级、背压和降级，避免用无限资源掩盖没有预算的设计。

一段可信的面试收口可以是：我不会先承诺某个统一毫秒数，而会按真实会话定义质量底线和可见等待预算，分别测首 token 与完整答案；再用匹配请求分布的实验比较短输出、模型、缓存和路由，并把重试、长尾与降级成本计入总任务成本。这个框架比背价格更能经得起追问。

准备岗位级追问时，可以再用 LLM 工程师面试框架把这套实验语言连接到模型评估、系统边界与线上复盘。

来源

• OpenAI Docs：Latency optimization，访问于 2026-07-28
• OpenAI Docs：Prompt caching，访问于 2026-07-28
• Anthropic Docs：Prompt caching，访问于 2026-07-28
• Google Cloud：Generative AI pricing，访问于 2026-07-28

价格、模型名称和缓存规则会变化。实际决策应在发布或面试准备时重新核对日期、地区、模型与计量单位，并用自己的工作负载复测。

常见问题

实时 AI 面试题有没有通用延迟目标？

没有。目标应由交互场景、用户容忍度、答案长度、网络条件和质量底线共同决定。可以给出本项目的测量目标，但必须说明来源和验证方法，不能包装成行业通用标准。

流式输出会缩短完整生成时间吗？

不一定。流式输出主要让用户更早看到部分内容，可能改善感知等待；完整答案何时结束仍要独立测量。若关键结论靠后或输出频繁修正，体验收益也会变小。

Prompt caching 一定能省钱和降延迟吗？

不一定。收益取决于供应商规则、稳定前缀比例、命中率、失效策略和流量分布。缓存未命中、新鲜度要求与失效后的负载都应进入实验。

面试里应该直接比较不同供应商价格吗？

只有在标明查询日期、地区、具体模型、输入输出单位和缓存条件时才有意义。更稳妥的做法是先讲比较框架，再引用当日官方定价作为阶段性输入。

下一步

• 查看 Interview AiBox 功能全景
• 深入了解 核心功能使用指南
• 通过 产品路线图 了解能力演进
• 下载 Interview AiBox 建立自己的实时问答实验记录