01

60 秒回答模板

vLLM 和 Streaming 解决的是不同层面的体验和效率问题。vLLM 通过 PagedAttention、KV-cache 管理和连续批处理提升吞吐和显存利用率；Streaming 则让用户更早看到首 token，改善体感。但三者有取舍：为了低首 token，要减少排队、控制 prompt 长度、避免过大的 batch；为了高吞吐，服务通常希望做 continuous batching，让请求等待合批，这可能增加 TTFT；为了低总延迟，要控制生成长度、解码速度和后处理。我的设计会按场景分层：交互式请求优先 TTFT 和稳定流式输出，设置较小排队窗口和优先级；批量任务优先吞吐，可以接受更大 batch；长输出任务要做输出长度限制、分段返回和取消。监控上同时看 TTFT、TPOT、总耗时、tokens/s、队列等待和 GPU 利用率，不能只优化一个指标。

考点 LLM serving 链路
难度 真实面经题
回答目标 权衡首 token、总延迟和吞吐
02

深入解析

01

先区分三个性能目标

首 token 延迟关注用户什么时候看到第一段输出；总延迟关注完整答案什么时候结束；吞吐关注单位时间服务能处理多少 token 或请求。这三个目标经常冲突，所以面试中不能只说 streaming 能降低延迟，而要说明它主要降低体感首响，不一定降低完整生成时间。

02

vLLM 的价值在推理资源效率

vLLM 的核心价值是更高效地管理 KV-cache 和批处理，让 GPU 显存利用更好，支持更多并发请求。KV-cache 避免每步解码重复计算历史 token，PagedAttention 类似分页管理减少显存碎片。它偏向服务端吞吐和并发效率，不等于所有请求的 TTFT 都自动降低。

03

Streaming 改善体感但不消除排队

Streaming 可以在生成过程中逐 token 或逐 chunk 返回，让用户更早看到输出。如果请求已经进入解码阶段，体验会明显改善；但如果前面排队、prefill 很长、batch 等待很久，TTFT 仍会高。因此还要优化队列等待、prompt 长度和 prefill 阶段。

04

batching 是吞吐和首响的核心取舍

为了提高吞吐，推理服务会把多个请求合批，提升 GPU 利用率。但合批通常会带来等待窗口，交互请求的首 token 可能变慢。工程上可以做优先级队列、短请求优先、小批量快速发车、不同业务隔离队列，避免低优先级长任务影响实时请求。

05

按请求类型做策略分层

实时聊天、Agent 工具决策和用户前台交互应优先 TTFT，控制 max tokens、限制上下文、使用较小合批等待。离线总结、批量生成和后台任务优先吞吐，可以提高 batch 和并发。长上下文请求要单独隔离，因为 prefill 成本高，容易拉高其他请求延迟。

06

监控要覆盖完整链路

指标至少包括 TTFT、每 token 间隔、总生成时间、输入 token 数、输出 token 数、队列等待、prefill 时间、decode 时间、吞吐、GPU 利用率和取消率。只看平均延迟会掩盖 P95/P99 问题，只看 tokens/s 也无法解释用户为什么觉得慢。

03

易错点

  • 把 Streaming 说成直接提升模型推理速度，混淆体感首响和总生成时间。
  • 只背 vLLM 优势，没有回答首 token、总延迟和吞吐之间的取舍。
  • 只看平均延迟，不看 TTFT、P95/P99、队列等待和输出 token 间隔。
  • 为了吞吐盲目增大 batch，导致交互请求首响变慢。
  • 忽略 prompt 长度和 prefill 成本，把所有延迟都归因于 decode。
  • 没有按实时请求、后台任务、长上下文请求做隔离策略。
04

面试官追问

Streaming 会不会降低总延迟？

不一定。Streaming 主要让用户更早看到部分输出，改善体感；完整生成仍受模型解码速度、输出长度和排队影响。

vLLM 为什么能提升性能？

它通过更高效的 KV-cache 管理、减少显存碎片和连续批处理提升 GPU 利用率，从而提高并发和吞吐。

如何降低 TTFT？

减少队列等待，缩短 prompt，控制合批等待窗口，隔离长上下文请求，优化 prefill，并给交互请求更高优先级。

吞吐上去了但用户仍觉得慢，可能是什么原因？

可能是 TTFT 或 P95 延迟高，长请求阻塞短请求，batch 等待太久，或者输出 token 间隔不稳定。吞吐不能代表单个用户体验。

长上下文请求如何处理？

长上下文 prefill 成本高，应限制长度、做摘要或检索压缩，并放到独立队列或低优先级池，避免影响普通交互请求。