10. 面试题

覆盖多模态 serving 与实时语音基础设施三个层级：初级（概念与计算）、中级（系统设计与权衡）、高级（架构裁决与成本）。

初级

1. 视觉语言模型（如 Qwen-VL）的架构分几段？数据怎么流？

答：三段：vision encoder（ViT）→ projector（对齐 LLM embedding 空间）→ LLM。图像先被切成 patch 经 encoder 变成视觉 embedding，prompt 中的占位符 token 在模型前向时被这些 embedding 替换，之后与文本 token 走同一个注意力上下文。调度、KV、prefix cache 对两类 token 同权处理。

2. 一张图片会变成多少 token？由什么决定？

答：由动态分辨率策略决定。以 Qwen2.5-VL 为例：像素总量钳制在约 0.2M~1M（对应 256~1280 个 28×28 merge block），token 数 = 缩放后边长所含 block 数的乘积。原始分辨率、长宽比与钳制上下限共同决定最终 token 数；同一张图不随内容变化。

3. 语音 Agent 的 first-audio 延迟由哪几段构成？给一个典型数值。

答：五段：VAD 端点检测（150-250ms）+ STT 定稿（80-150ms）+ LLM TTFT（200-300ms）+ TTS 首帧（80-120ms）+ 网络与播放缓冲（30-60ms），典型合计 600-900ms；生产目标一般压到 600ms 内（Mini Demo 场景 3 的默认配置为 850ms，需优化）。

4. 什么是 barge-in（打断）？工程上要实现哪几件事？

答：用户在 Agent 播放时开口并接管对话。工程上需要：VAD 快速触发（约 80ms）、取消传播到 TTS/LLM（<50ms）、按用户实际听到的位置截断对话历史、全链路重启响应。还要处理误触发（咳嗽/回通道）——不截断历史并恢复播放。

5. 音频 codec token 是怎么来的？为什么说它决定语音模型的上下文上限？

答：神经音频编解码器（EnCodec/Mimi 类）把波形按帧率（12.5-75Hz）切成帧，每帧用 RVQ 的多个 codebook 各产出一个 token。tokens/秒 = 帧率 × codebook 数（Mimi 为 100/s）。1 分钟音频上下文即 6000 token，约为同等文本信息量的 30 倍——KV 与上下文预算被 codec 选择直接锁定。

6. WebRTC 和 WebSocket 在语音接入上怎么选？

答：浏览器/移动端直连优先 WebRTC：UDP 抗抖动、有回声消除参考、OpenAI Realtime 浏览器场景官方推荐（且要求临时密钥）；服务端到服务端、电话桥接用 WebSocket，简单可靠但要小心 TCP 队头阻塞。Gemini Live 当前只提供 WebSocket。

中级

7. 图文混合 batch 会出现什么调度问题？怎么处理？

答：skew：一张高清图的 prefill 量可顶数个文本请求，batch 内成本方差极大，长视觉请求会饿死短文本请求并拉爆 TTFT。处理：chunked prefill 把长请求分块与短请求交错；encoder 与 LLM 解耦成两个资源池流水重叠（重叠后 makespan = max(两池耗时) 而非求和）；入口限额防止单请求极端化。

8. 端到端语音 API（Realtime 类）与三段式（ASR→LLM→TTS）怎么取舍？

答：端到端延迟与自然度好（目标 500ms 级、内建打断），但黑盒、贵（音频按 token 计）、绑定云厂商、文本中间态仅旁路；三段式每段可替换/审计/自托管、成本可控，但延迟是三段累加、打断要自己实现。2026 生产主流是混合：体验敏感主链路走端到端，需审计/私有化/特殊音色场景走三段式，框架层（LiveKit/Pipecat）统一抽象。

9. 打断时为什么要「按已播放截断历史」？怎么实现？

答：Agent 生成了 4 秒回答但用户 0.4 秒就抢话，LLM 上下文若保留全部 4 秒，模型会基于用户没听到的内容继续推演，产生幻觉式对话。实现：transcript 每段绑定音频区间，打断确认时以播放游标（playback cursor）截断；截断点落在帧边界；误触发不截断、续播。

10. 如何降低语音 Agent 的 first-audio 延迟？按优先级列出手段。

答：先测量归因（逐段埋点），再按杠杆优化：①LLM TTFT——级联小模型先答、prefix cache、PD 分离、量化；②endpointing——语义端点模型替代固定静音窗口、动态静音时长；③并行化——ASR 定稿与 LLM 预热/预取重叠、TTS 边收 token 边合成；④传输——边缘接入、自适应播放缓冲。TTFT 与 endpointing 通常占预算 60%+，优先投资。

11. 视频理解的推理成本高在哪？有哪些降本手段？

答：高在三处：解码（CPU 解码是瓶颈，应迁 NVDEC GPU 解码）、帧 token 数（帧数 × 每帧 token，1 分钟视频可达数万 token）、KV 膨胀（远超文本）。手段：动态 FPS 采样、token 剪枝（Qwen3-VL vidcom2 类，稀疏视频表示把每帧 token 减半）、跨帧视觉 embedding 缓存、先粗检后精读的两段式管线。

12. 语音系统的容量怎么规划？与文本 serving 有何不同？

答：文本按 token/s 与并发请求规划；语音按「并发路数」规划——一路会话稳定占用 ASR 一路 + TTS 一路 + LLM 一份会话态，算力需求随路数线性。扩缩容信号用活跃会话数而非 QPS；LLM 侧因音频上下文大（分钟级 6000 token），单路 KV 占用按长上下文会话估算，prefix cache 命中率与打断率直接影响有效并发。

高级

13. 设计一个支持 10 万并发语音会话的系统，关键决策是什么？

答：①分层解耦：SFU 接入层（边缘就近）、媒体处理（VAD/降噪）、感知（ASR 池按路数扩）、推理（LLM 池 + prefix cache + 级联路由）、发声（TTS 池 + 短语缓存）；②编排中枢：双工状态机统一裁决打断/取消/工具等待，历史按已播放截断；③双模共存：端到端 API 与三段式按租户分流，降级链保证任何一级故障「能出声」；④预算运营：逐段认领制 SLO + P95 告警；⑤成本：按会话完整账本核算，缓存命中率与打断率进毛利看板。

14. 端到端语音模型把 ASR/LLM/TTS 合一后，基础设施团队还剩下什么工作？

答：①会话接入与密钥安全（WebRTC 临时凭证、防密钥泄露）；②工具编排与 function calling 的执行回填——这是唯一留在你手里的「大脑」；③记忆系统（长期记忆注入/回写、按已播放截断的会话记忆）；④成本治理（音频 token 计费比文本贵 5-15 倍，需缓存、路由、级联）；⑤可观测与降级（API 超时降级三段式兜底）。模型能力外包了，系统责任没有外包。

15. 打断风暴（用户频繁打断）下如何保证系统稳定？

答：①取消传播独立快路径（<50ms），打断信号高于一切新请求；②新响应高优先级但限速（token bucket），防止无限重启循环；③连续打断检测：N 秒内打断次数超阈降入「确认模式」（让说完再动）；④打断浪费核算进成本与体验双看板，归因到端点模型误触发或回答质量；⑤算力隔离：保留保底算力给「已确认 turn」的响应，打断请求不得挤占。