核心要点

  • 首选流式输出（边生成边显示）：大幅降低「首字延迟」的感知，用户看到字在动就不觉得卡

  • 体验侧：加 loading/骨架屏/打字机效果，把等待变得可感知、不焦虑

  • 性能侧：换更快/更小的模型、缓存高频请求、预取、把多步并行

  • 长任务异步化：丢后台跑 + 进度提示，别让用户对着转圈干等；核心是优化「感知延迟」不只看总时长

标准回答

先分清：感知延迟 vs 真实延迟

用户体验的关键是「感知延迟」，不一定是总耗时。同样 10 秒，干等转圈很难受，而流式逐字蹦出来就能接受。所以优化分两条线。

体验线（成本低见效快）

  1. 流式输出：用 SSE/流式 API 边生成边推给前端，首字几百毫秒就出来，感知延迟骤降。
  2. Loading 反馈：骨架屏、打字机效果、「正在思考/正在检索」状态，让等待有进度感。
  3. 异步化：耗时长的任务（生成长报告）丢后台跑，给进度条/完成通知，用户不被阻塞。

性能线（降真实延迟）

  1. 选型：简单任务用更小更快的模型，别一律上最大模型。
  2. 缓存：高频相同/相似请求缓存结果，命中直接返回。
  3. 预取/并行：能提前算的提前算，多个独立调用并行发而非串行。
  4. 推理优化：自部署的话用 vLLM 等做连续批处理、KV Cache 提吞吐。

实战里先上流式 + loading，性价比最高。

常见误区

⚠️ 常见踩坑

只盯着「降低总耗时」死磕模型推理，却不上流式输出，用户对着转圈干等几秒体验依旧差；以及把所有任务都同步阻塞，长任务把请求线程占满拖垮整个服务。

追问

追问 1：流式输出具体怎么实现，前后端要做什么？

后端用大模型的 stream 模式拿到逐 token 输出，通过 SSE（Server-Sent Events）或 WebSocket 持续推给前端；前端监听数据流，把 token 增量拼接渲染成打字机效果。注意处理中断（用户停止）、错误中途回收、以及结束标志。这是降低首字延迟感知最有效的一招。

追问 2：哪些请求适合缓存，缓存又怎么避免返回过时/错误的内容？

适合缓存的是高频、确定性强、结果稳定的请求（固定问答、常见翻译）。对 query 做规范化或语义去重再当 key。注意：带个性化上下文、实时数据的别缓存；设过期时间，底层数据变了要失效缓存；temperature 高的创意生成缓存会让所有人拿到一样的结果，要权衡。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。

📚 知识库

📖 术语表

🛠️ AI 工具

  • vLLM

    高吞吐 LLM 推理引擎，77,418+ stars。采用 PagedAttention 显存优化技术，吞吐量比 HuggingFace Transformers 高 24 倍，是生产环境部署大模型推理的首选方案，支持 OpenAI 兼容 API

🎯 相关面试题