核心要点
首选流式输出（边生成边显示）：大幅降低「首字延迟」的感知，用户看到字在动就不觉得卡
体验侧：加 loading/骨架屏/打字机效果，把等待变得可感知、不焦虑
性能侧：换更快/更小的模型、缓存高频请求、预取、把多步并行
长任务异步化：丢后台跑 + 进度提示，别让用户对着转圈干等；核心是优化「感知延迟」不只看总时长
标准回答
一、先分清：感知延迟 vs 真实延迟
用户体验的关键是「感知延迟」，不一定是总耗时。同样 10 秒，干等转圈很难受，而流式逐字蹦出来就能接受。所以优化分两条线。
二、体验线（成本低见效快）
- 流式输出：用 SSE/流式 API 边生成边推给前端，首字几百毫秒就出来，感知延迟骤降。
- Loading 反馈：骨架屏、打字机效果、「正在思考/正在检索」状态，让等待有进度感。
- 异步化：耗时长的任务（生成长报告）丢后台跑，给进度条/完成通知，用户不被阻塞。
三、性能线（降真实延迟）
常见误区
⚠️ 常见踩坑
误区一：容易答偏的地方：只盯着「降低总耗时」死磕模型推理，却不上流式输出，用户对着转圈干等几秒体验依旧差；以及把所有任务都同步阻塞，长任务把请求线程占满拖垮整个服务。
追问
追问 1：流式输出具体怎么实现，前后端要做什么？
后端用大模型的 stream 模式拿到逐 token 输出，通过 SSE（Server-Sent Events）或 WebSocket 持续推给前端；前端监听数据流，把 token 增量拼接渲染成打字机效果。注意处理中断（用户停止）、错误中途回收、以及结束标志。这是降低首字延迟感知最有效的一招。
追问 2：哪些请求适合缓存，缓存又怎么避免返回过时/错误的内容？
适合缓存的是高频、确定性强、结果稳定的请求（固定问答、常见翻译）。对 query 做规范化或语义去重再当 key。注意：带个性化上下文、实时数据的别缓存；设过期时间，底层数据变了要失效缓存；temperature 高的创意生成缓存会让所有人拿到一样的结果，要权衡。
🔗 相似问题
同一考点的不同问法，换着练更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习
