企业官网建设流程全解析

1. 项目概述：为什么“首字延迟”成了大模型应用的隐形门槛

你有没有遇到过这样的场景：用户在网页端输入一句“今天北京天气怎么样”，光标刚离开输入框，页面却像卡住了一样——空白三秒，才突然“唰”地一下，整段回答全涌出来？不是模型没响应，是它明明已经算好了，却迟迟不把第一个字吐出来。这个“第一颗字等得比泡面还久”的问题，就是业内常说的首字延迟（Time to First Token, TTFT）。它不像总响应时间那样容易被量化，却直接决定用户是否愿意继续等下去。实测数据显示，TTFT 超过 800ms，用户放弃率就会上升 23%；超过 1.5 秒，近半数用户会刷新页面或切换工具。这不是模型能力问题，而是服务链路中一个被长期低估的“毛细血管堵塞点”。

我最近在搭建一个面向教育场景的轻量级问答助手时，就栽在这个坑里。后端用的是本地部署的 7B 级别开源大模型，推理框架选了 vLLM，前端通过标准 SSE（Server-Sent Events）协议接收流式响应。理论上，vLLM 支持真正的 token 级流式输出，前端也能逐字渲染，体验应该丝滑。但上线压测时发现：平均 TTFT 高达 1.2 秒，最差一次达到 2.7 秒，而模型实际推理耗时（从接收到生成首个 token）仅 320ms 左右。这意味着将近 900ms 的时间，被消耗在“看不见”的环节里——请求还没进模型，字还没出模型，数据却卡在中间某处不动了。

这个标题里的“复盘”，不是事后总结，而是带着探针钻进整个调用链路，一层层剥开 HTTP 协议栈、Web 服务器缓冲机制、反向代理策略、前端 EventSource 实现细节，甚至浏览器内核对 SSE 的解析逻辑。它不涉及模型结构优化，也不依赖 GPU 算力升级，纯粹是工程侧的“管道疏通”。关键词“SSE 流式”点明了技术载体，“踩坑”二字则暗示这不是教科书式的理想流程，而是真实生产环境里，那些文档不会写、论坛没人提、但每天都在悄悄拖慢你产品体验的隐性损耗。适合正在做 AI 应用落地的后端工程师、全栈开发者，以及对“为什么我的大模型看起来不够快”感到困惑的产品同学——尤其当你已经确认模型本身没问题，却仍被延迟困扰时，这篇复盘就是为你写的。

2. 整体设计与思路拆解：为什么非得用 SSE？又为什么偏偏是它最容易出问题

2.1 为什么选 SSE 而不是 WebSocket 或普通 AJAX

在流式响应方案里，WebSocket、SSE、轮询（Polling）和长连接（Long Polling）是四个常见选项。我们最终锁定 SSE，不是因为它“高级”，而是它在当前项目约束下，综合成本最低、兼容性最好、侵入性最小。具体来看：

• WebSocket：双向实时通信的标杆，但代价是前后端都要重写连接管理逻辑。我们的前端是基于 Vue 的静态站点，没有维护长连接的心跳、重连、状态同步机制；后端 API 网关也未开启 WebSocket 支持。强行上马，意味着要额外引入 Socket.IO 服务、改造 Nginx 配置、增加连接保活逻辑——为了解决“首字延迟”，先给自己加三倍复杂度，不划算。

• 普通 AJAX（短连接）：每次请求都新建 TCP 连接，HTTP/1.1 下至少 3 次握手 + TLS 握手（约 200–400ms），模型生成再快，光建连就吃掉一半延迟。HTTP/2 虽支持多路复用，但浏览器对单个域名的并发连接数有限制（通常 6–10 个），且无法真正实现“边生成边推送”，必须等整个响应体收完才能解析。

• 长轮询（Long Polling）：服务器挂起请求直到有数据或超时，看似流式，实则每次响应结束就要立刻发新请求，存在请求间隙（哪怕只有 10ms），导致前端渲染出现肉眼可察的“卡顿感”，且服务器连接数压力陡增。

• SSE（Server-Sent Events）：HTTP 协议原生支持，服务端只需按规范输出text/event-streamMIME 类型 +data:前缀的纯文本块；前端用原生EventSourceAPI 接收，自动处理重连、解析事件格式；底层复用 HTTP/1.1 或 HTTP/2 连接，无额外握手开销；最重要的是——它天然支持“首字即推”，只要服务端 write() 一个字节，TCP 层就会尝试发送，无需等待缓冲区填满。这正是我们想要的“最小干预、最大收益”路径。

提示：SSE 的本质是“服务器单向推送的 HTTP 长连接”，它不追求双向实时，只专注解决“服务端有数据就立刻告诉前端”这一件事。对于大模型问答这类“一问一答、结果单向流出”的场景，它是精准匹配的工具，而非妥协方案。

2.2 为什么 SSE 反而成了“首字延迟”的重灾区

正因为它轻量、简单、基于 HTTP，反而放大了传统 Web 架构中那些被忽略的缓冲环节。一个典型的 SSE 请求链路是：
用户浏览器 → CDN/边缘节点 → 反向代理（Nginx）→ Web 应用服务器（FastAPI）→ 推理引擎（vLLM）

在理想情况下，vLLM 生成第一个 token 后，FastAPI 立即调用response.write()，数据经由操作系统内核 TCP 缓冲区发出，一路直达浏览器。但现实是，每一层都可能设置自己的缓冲策略，且默认行为往往以“吞吐优先”而非“延迟优先”。比如：

• Nginx 默认启用proxy_buffering on，会将上游响应暂存到内存缓冲区，等攒够 4KB 或收到完整响应头才转发给客户端；
• FastAPI 的 StreamingResponse 在某些异步中间件（如 CORS、GZip）包裹下，会触发内部 chunk 缓存；
• 浏览器 EventSource 对接收到的原始字节流有最小解析单元要求，若前几个字节不符合data:格式，可能静默丢弃或延迟触发message事件；
• 更隐蔽的是：Linux 内核的 TCP_NODELAY（Nagle 算法）默认开启，当发送小包（< MSS）且未填满时，会等待后续数据合并发送，造成毫秒级延迟。

这些环节单独看都合理，合起来却形成一条“延迟放大链”。我们最初以为问题在模型或框架，花两天调优 vLLM 的--max-num-seqs和--block-size参数，结果 TTFT 毫无改善——因为第一个 token 根本没机会从 vLLM 出来，就被卡在 Nginx 的缓冲区里了。

2.3 复盘方法论：从“黑盒测试”到“白盒追踪”

面对这种跨层延迟，不能靠猜。我们的复盘采用三级定位法：

1. 现象层（What）：用 Chrome DevTools 的 Network 面板记录完整请求生命周期，精确标记Request Start、Response Headers Received、First Byte、Content Download时间点，确认延迟发生在“首字到达浏览器”之前还是之后；
2. 链路层（Where）：在 Nginx 日志中开启$upstream_header_time和$upstream_response_length，对比upstream_header_time（后端返回首字节耗时）与浏览器First Byte时间差，判断瓶颈在 Nginx 之后还是之前；
3. 代码层（Why）：在 FastAPI 路由中插入time.time()打点，在vLLM.generate()返回首个 token 后立即记录，再与StreamingResponse的write()调用时间对比，确认框架层是否有隐式缓存。

这套方法帮我们快速排除了模型和浏览器问题，将焦点锁定在 Nginx 和 FastAPI 的缓冲配置上。它不依赖任何特殊工具，仅靠浏览器开发者工具 + 服务器日志 + 代码打点，就能完成一次完整的“延迟归因”。

3. 核心细节解析与实操要点：逐层击穿缓冲陷阱

3.1 Nginx 层：关闭代理缓冲与禁用 Nagle 算法

Nginx 是绝大多数 Web 服务的流量入口，也是首字延迟最常见的“藏污纳垢”之地。默认配置对流式响应极不友好，必须显式覆盖：

# 关键配置项（放在 location /api/chat {} 块内） location /api/chat { proxy_pass http://backend; # 【核心】彻底关闭代理缓冲，让数据“所见即所得” proxy_buffering off; # 【核心】禁用缓冲区，避免等待填满 proxy_buffers 8 4k; proxy_buffer_size 4k; # 【核心】设置超时，防止连接假死 proxy_read_timeout 300; # 与后端超时一致 proxy_send_timeout 300; # 【核心】强制使用 HTTP/1.1，确保 Connection: keep-alive 生效 proxy_http_version 1.1; proxy_set_header Connection ''; # 【核心】透传必要的 SSE 头部 proxy_set_header X-Accel-Buffering no; # Nginx 特有指令，强制不缓冲 proxy_set_header Cache-Control no-cache; proxy_set_header X-Requested-With XMLHttpRequest; }

这里每一条都不是可选项，而是针对 SSE 的定制化手术：

• proxy_buffering off是总开关，但仅此一项不够。Nginx 在off模式下仍会使用proxy_buffers分配内存块，若后端发送小包，可能因内存分配策略导致延迟。因此必须配合proxy_buffers 8 4k（8 个 4KB 缓冲区）和proxy_buffer_size 4k（首行缓冲区大小），确保即使只写 1 字节，也有足够空间暂存并立即转发。
• X-Accel-Buffering no是 Nginx 的“隐藏王牌”。它直接告诉 Nginx：“别管什么缓冲策略，我让你转发就立刻转发”。很多教程只提proxy_buffering off，却漏掉这一行，导致配置看似生效，实则无效。
• proxy_http_version 1.1和proxy_set_header Connection ''是为了维持长连接。HTTP/1.0 默认关闭连接，每次都要重连；而Connection: ''清空了 Connection 头，避免 Nginx 错误地添加close指令。

注意：proxy_buffering off会略微增加 Nginx 内存占用（每个连接独占缓冲区），但在流式场景下，这是必须付出的代价。我们实测 1000 并发连接下，内存增长仅 12MB，远低于模型推理本身的开销。

3.2 FastAPI 层：绕过中间件缓存与手动 flush

FastAPI 的StreamingResponse看似开箱即用，但它的底层依赖 Starlette 的StreamingResponse，而后者在处理异步生成器时，会默认启用 chunked encoding 缓存。更麻烦的是，如果你启用了CORSMiddleware或GZipMiddleware，它们会包裹原始响应流，引入额外的缓冲逻辑。

我们的解决方案是：不用StreamingResponse，改用Response手动控制流。代码对比：

# ❌ 问题代码：StreamingResponse 自动缓存 @app.post("/chat") async def chat_stream(request: Request): async def event_generator(): async for token in vllm_generate(...): # vLLM 异步生成器 yield f"data: {json.dumps({'token': token})}\n\n" return StreamingResponse(event_generator(), media_type="text/event-stream") # ✅ 正确代码：Response + 手动 write & flush @app.post("/chat") async def chat_stream(request: Request): # 创建响应对象，指定媒体类型 response = Response( content=iter(()), # 占位迭代器 media_type="text/event-stream", headers={ "Cache-Control": "no-cache", "X-Accel-Buffering": "no", # 再次声明，防 Nginx 忽略 "Connection": "keep-alive", } ) # 获取底层流写入器（Starlette 的 StreamingResponse 不暴露此接口） # 我们改用更底层的 ASGI 接口：直接操作 scope['send'] 函数 async def send_event(data: str): await request.scope["send"]({ "type": "http.response.body", "body": data.encode("utf-8"), "more_body": True, }) # 发送 SSE 初始化头（必需，否则浏览器不识别） await send_event("event: message\n") # 逐 token 推送 try: async for token in vllm_generate(...): event_data = f"data: {json.dumps({'token': token})}\n\n" await send_event(event_data) # 【关键】强制刷新 TCP 缓冲区，避免 Nagle 算法延迟 await asyncio.sleep(0) # 让出控制权，触发底层 flush except Exception as e: await send_event(f"event: error\ndata: {str(e)}\n\n") finally: # 发送结束标志 await send_event("event: end\ndata: \n\n") await request.scope["send"]({ "type": "http.response.body", "body": b"", "more_body": False, }) return response

这段代码的核心在于三点：

• 绕过中间件：直接操作 ASGI 的scope['send']，完全避开 Starlette 的StreamingResponse和所有中间件封装，确保每个send()调用都直通网络栈。
• 手动 flush：await asyncio.sleep(0)是 Python 异步生态中的经典技巧。它不等待时间，只是主动让出当前协程的执行权，强制事件循环检查 I/O 就绪状态，从而触发底层 socket 的flush()操作。实测表明，没有这行，TTFT 波动极大（400ms–1.8s）；加上后，稳定在 350ms±50ms。
• SSE 协议合规：严格遵循event: xxx\n+data: yyy\n\n格式，末尾双换行是分隔符，缺一不可。浏览器靠这个识别消息边界，格式错误会导致message事件不触发。

3.3 操作系统与网络层：禁用 Nagle 算法与调整 TCP 缓冲区

即使 Nginx 和 FastAPI 都已优化，Linux 内核的 TCP 栈仍可能成为最后一道关卡。Nagle 算法旨在减少小包数量，提升网络吞吐，但对流式响应却是灾难——它会把多个小 write() 合并成一个大包发送，导致首字被“扣押”。

在 Nginx 配置中加入：

# 在 http {} 或 server {} 块中 tcp_nodelay on; # 全局禁用 Nagle # 或针对特定 upstream upstream backend { server 127.0.0.1:8000; keepalive 32; }

同时，检查服务器的 TCP 缓冲区设置。过大的net.ipv4.tcp_rmem和net.ipv4.tcp_wmem会让内核倾向于缓存更多数据。我们将其调整为更激进的低延迟模式：

# 临时生效（重启后失效） sudo sysctl -w net.ipv4.tcp_nodelay=1 sudo sysctl -w net.ipv4.tcp_rmem="4096 16384 32768" sudo sysctl -w net.ipv4.tcp_wmem="4096 16384 32768" # 永久生效：写入 /etc/sysctl.conf echo "net.ipv4.tcp_nodelay = 1" | sudo tee -a /etc/sysctl.conf echo "net.ipv4.tcp_rmem = 4096 16384 32768" | sudo tee -a /etc/sysctl.conf echo "net.ipv4.tcp_wmem = 4096 16384 32768" | sudo tee -a /etc/sysctl.conf sudo sysctl -p

这里的数值含义是：min default max，单位字节。我们将default从默认的 212992（约 208KB）大幅降低到 16384（16KB），让内核更积极地发送小包。实测在千兆内网环境下，此举将 P95 TTFT 从 920ms 降至 380ms。

实操心得：不要盲目调小min值（如设为 1024）。过小会导致频繁系统调用，反而增加 CPU 开销。16KB 是我们在 7B 模型、1000QPS 场景下验证过的平衡点——既保证小包及时发出，又避免 syscall 过载。

3.4 浏览器层：EventSource 的隐藏陷阱与兜底方案

前端看似最简单，但EventSource的实现细节同样埋雷。Chrome 和 Firefox 对text/event-stream的解析策略略有差异，且都存在一个共性问题：如果接收到的字节流开头不是合法的event:或data:行，会静默丢弃，直到遇到第一个合法行才开始触发事件。

我们曾遇到一个诡异问题：后端日志显示data: {"token":"H"}\n\n已发出，但前端onmessage回调从未触发。抓包发现，Nginx 在响应头后、第一个data:前，意外插入了 3 个空格字符（源于某中间件日志打印）。这 3 个空格让整个流被浏览器判定为“非法格式”，直接忽略。

解决方案是：在后端发送任何data:之前，先发送一个空的event:声明，作为协议握手：

# 在 send_event 循环前 await send_event("event: message\n") # 声明事件类型 await send_event("data: \n\n") # 发送空数据，确保流以合法格式开始

此外，EventSource默认重连间隔为 3 秒，且不支持自定义超时。一旦连接中断（如网络抖动），用户会经历长达 3 秒的“无响应”空白期。我们用fetch + ReadableStream作为兜底：

// 前端兼容方案 async function streamChat(input) { const controller = new AbortController(); const timeoutId = setTimeout(() => controller.abort(), 5000); // 5秒超时 try { const response = await fetch("/api/chat", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ input }), signal: controller.signal, }); if (!response.ok) throw new Error(`HTTP ${response.status}`); if (response.headers.get("content-type") !== "text/event-stream") { // 降级为普通 JSON 请求 return await response.json(); } const reader = response.body.getReader(); let buffer = ""; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += new TextDecoder().decode(value); const lines = buffer.split("\n"); buffer = lines.pop(); // 保留未完成的行 for (const line of lines) { if (line.startsWith("data: ")) { const data = line.slice(6).trim(); if (data) { const parsed = JSON.parse(data); renderToken(parsed.token); // 逐字渲染 } } } } } catch (err) { console.error("Stream failed:", err); // 可触发重试或降级提示 } finally { clearTimeout(timeoutId); } }

这个方案的优势在于：完全掌控字节流解析，规避EventSource的格式校验和重连策略；支持自定义超时；且ReadableStream在现代浏览器中兼容性良好（Chrome 43+, Firefox 65+）。唯一代价是需要手动解析 SSE 格式，但几行代码即可搞定。

4. 实操过程与核心环节实现：从压测到上线的完整闭环

4.1 基准测试：建立可量化的 TTFT 监控体系

优化前，我们必须有一套客观、可复现的测量基准。不能只看“感觉快了”，而要精确到毫秒。我们搭建了一个轻量级压测脚本，模拟真实用户行为：

# ttft_benchmark.py import asyncio import aiohttp import time async def measure_ttft(session, url, payload): start_time = time.time() async with session.post(url, json=payload) as response: # 等待第一个 data: 块 async for line in response.content: decoded = line.decode('utf-8').strip() if decoded.startswith("data:"): first_token_time = time.time() return first_token_time - start_time return -1 # 超时 async def run_benchmark(): url = "http://localhost:8000/api/chat" payload = {"input": "请用一句话介绍量子计算"} connector = aiohttp.TCPConnector(limit=100, limit_per_host=100) timeout = aiohttp.ClientTimeout(total=30) async with aiohttp.ClientSession(connector=connector, timeout=timeout) as session: ttfts = [] for i in range(50): # 50次请求 ttft = await measure_ttft(session, url, payload) if ttft > 0: ttfts.append(ttft) await asyncio.sleep(0.1) # 避免请求风暴 print(f"TTFT P50: {np.percentile(ttfts, 50)*1000:.1f}ms") print(f"TTFT P95: {np.percentile(ttfts, 95)*1000:.1f}ms") print(f"TTFT P99: {np.percentile(ttfts, 99)*1000:.1f}ms") if __name__ == "__main__": asyncio.run(run_benchmark())

这个脚本的关键在于：它模拟的是真实浏览器的接收逻辑——不是等 HTTP 响应头，而是等第一个data:行。这比单纯测response.headers_received更贴近用户体验。我们用它在每次配置变更后运行，确保优化效果可量化。

4.2 分阶段优化与效果对比

我们将优化过程分为四阶段，每阶段只改一个变量，记录 TTFT 变化：

可以看到，最大的收益（58%）来自 FastAPI 层的绕过中间件，这印证了我们最初的怀疑：问题不在基础设施，而在应用框架的“善意封装”。而 Nginx 配置只是打开了通道，真正的“疏通”发生在代码层。

4.3 上线灰度与熔断策略

优化不是一蹴而就。我们采用渐进式上线：

• 灰度 1% 流量：在 Nginx 中用split_clients指令，根据用户 IP 哈希分流，监控 24 小时 TTFT 和错误率；
• AB 测试面板：在管理后台嵌入实时 TTFT 看板，对比新旧路径的 P95 延迟、连接成功率、内存占用；
• 自动熔断：当新路径的 P95 TTFT 连续 5 分钟高于基线 20%，或错误率突增 5%，Nginx 自动将流量切回旧路径。

熔断逻辑通过 Lua 脚本实现：

# nginx.conf http { lua_shared_dict ttft_stats 10m; server { location /api/chat { access_by_lua_block { local dict = ngx.shared.ttft_stats local key = "ttft_p95_new" local p95 = dict:get(key) or 0 -- 如果新路径 P95 > 基线 * 1.2，切回旧路径 if p95 > 800 then -- 基线 P95 为 660ms，1.2 倍为 792ms ngx.exec("@old_path") end } } } }

这套机制让我们在上线第三天，成功捕获了一次因 CDN 缓存头污染导致的 TTFT 异常（P95 突增至 1100ms），并在 2 分钟内自动回滚，避免了用户影响。

4.4 持续监控与告警

优化完成后，监控不能停。我们在 Prometheus 中新增了两个核心指标：

• ai_ttft_seconds_bucket{path="/api/chat", le="0.5"}：TTFT < 500ms 的请求数
• ai_sse_connection_errors_total{path="/api/chat"}：SSE 连接异常次数（含超时、解析失败）

告警规则设定为：

# prometheus.rules.yml - alert: HighTTFT expr: rate(ai_ttft_seconds_bucket{le="0.5"}[5m]) < 0.85 for: 10m labels: severity: warning annotations: summary: "High TTFT for /api/chat ({{ $value }}% < 500ms)" - alert: SSEConnectionFailures expr: rate(ai_sse_connection_errors_total[5m]) > 0.01 for: 5m labels: severity: critical annotations: summary: "SSE connection failure rate high ({{ $value }}%)"

当 TTFT 达标率低于 85% 或连接错误率超 1%，企业微信机器人会立刻推送告警，并附带最近 10 分钟的 TTFT 分布直方图链接。这让我们能第一时间感知到 CDN 配置变更、模型版本升级等外部因素对流式体验的影响。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 “TTFT 时好时坏，毫无规律” —— GZip 中间件的幽灵

现象：优化后大部分请求 TTFT 稳定在 350ms，但偶尔（约 5%）会飙升至 1.2s，且无明显规律。

排查过程：

• 抓包发现，高延迟请求的响应体被压缩（Content-Encoding: gzip），而正常请求未压缩；
• 检查 FastAPI 配置，发现GZipMiddleware默认启用，且对text/event-stream类型也会尝试压缩；
• 但 GZip 压缩是流式阻塞的：它需要积累一定数据量（通常 4KB）才开始压缩并输出，导致首字被卡住。

解决方案：
在GZipMiddleware初始化时，显式排除text/event-stream：

from fastapi.middleware.gzip import GZipMiddleware app.add_middleware( GZipMiddleware, minimum_size=1000, # 【关键】排除 SSE 媒体类型 exclude_paths=[r"/api/chat"], # 或更通用：exclude_types=["text/event-stream"] )

实操心得：GZip 对文本压缩率高，但对流式响应是“毒药”。永远不要对text/event-stream启用任何压缩中间件。如果必须压缩，应在 Nginx 层用gzip_types text/event-stream;，并确保gzip_min_length 1;，但这会增加 Nginx CPU 开销，我们最终选择彻底禁用。

5.2 “前端收不到第一个 token，但后端日志显示已发送” —— Nginx 的proxy_buffer_size陷阱

现象：后端日志明确打印sent data: {"token":"H"}，但 Chrome Network 面板的First Byte时间始终 >1s。

排查过程：

• curl -v http://localhost/api/chat测试，发现First Byte正常（350ms），证明问题在客户端；
• 对比curl和浏览器请求头，发现浏览器带Accept-Encoding: gzip, deflate，而curl默认不带；
• 查阅 Nginx 文档，proxy_buffer_size不仅控制响应头缓冲，还影响Accept-Encoding头的处理逻辑；
• 当proxy_buffer_size小于Accept-Encoding头长度时，Nginx 会延迟转发整个响应头，直到缓冲区足够。

解决方案：
将proxy_buffer_size从默认4k提升至8k，并显式清除编码头：

location /api/chat { proxy_set_header Accept-Encoding ""; # 彻底禁用编码协商 proxy_buffer_size 8k; # 确保容纳所有可能的请求头 }

5.3 “移动端 TTFT 比桌面端高 300ms” —— TLS 握手与 HTTP/2 优先级

现象：iOS Safari 和 Android Chrome 的 TTFT 普遍比桌面 Chrome 高 200–400ms。

根因分析：

• 移动端网络环境更复杂（蜂窝网络、Wi-Fi 切换），TCP 重传概率更高；
• 更关键的是：移动端浏览器对 HTTP/2 的流优先级（Stream Priority）支持不一致。当多个资源（JS、CSS、SSE）并发请求时，SSE 流可能被降级为低优先级，导致 TCP 包被延迟调度。

解决方案：

• 服务端：在 Nginx 中为 SSE 路径强制使用 HTTP/1.1，避免优先级干扰：

  location /api/chat { proxy_http_version 1.1; # 其他配置... }

• 客户端：在fetch请求中添加priority: "high"（Chrome 111+ 支持）：

  fetch("/api/chat", { priority: "high", // 提示浏览器提升此请求优先级 // ... });

• 兜底：为移动端单独配置更激进的tcp_nodelay和更小的 TCP 缓冲区。

5.4 “模型生成很快，但 TTFT 仍高” —— vLLM 的--max-num-batched-tokens误导

现象：vLLM 日志显示first_token_time: 0.32s，但整体 TTFT 为 0.85s。

真相：
first_token_time是 vLLM 内部计时，从generate()调用开始，到首个 token 产出。但它不包含：

• 请求从 FastAPI 传入 vLLM 的序列化/反序列化时间（JSON 解析）；
• vLLM 的prefill阶段（处理 prompt）本身耗时，而first_token_time仅统计decode阶段。

验证方法：
在 FastAPI 路由中打点：

start_parse = time.time() payload = await request.json() # 解析 JSON parse_time = time.time() - start_parse start_vllm = time.time() async for token in vllm_generate(payload["input"]): # ... vllm_time = time.time() - start_vllm

我们发现，parse_time平均 80ms，vllm_time平均 320ms，总和 400ms，与实测 TTFT 450ms 基本吻合。

优化：

• 用msgpack替代 JSON 传输（体积小 30%，解析快 2 倍）；
• vLLM 启用--enable-prefix-caching加速 prompt 处理；
• FastAPI 使用pydantic.BaseModel预编译解析器，避免运行时 schema 检查。

5.5 SSE 流式问题速查表