在构建面向大语言模型的流式补全系统时，Server-Sent Events（SSE）仍然是工程落地的首选方案。它原生于 HTTP 协议，无需引入 WebSocket 的双向握手复杂度和额外的基础设施适配成本，同时能够提供逐 token 渲染的用户体验。然而，在生产环境中，SSE 连接的稳定性、超时控制以及断线后的续传能力，直接决定了用户体验的流畅程度和后端资源的有效利用。本文将从连接管理、断线续传、参数阈值和可观测性四个维度，给出面向多模型流式输出的工程化实践建议。
SSE 在多模型流式场景下的适用性判断
在讨论具体参数之前，有必要明确 SSE 的边界。多模型流式补全的核心特征是服务器向客户端单向推送文本 token 或结构化 JSON 补丁，这与 SSE 的单向广播模型高度吻合。当业务需要同时支持多个模型实例（如同时调用 GPT-4o、Claude-3.5 和本地部署的推理模型）时，SSE 的无状态特性使得每个模型可以独立返回流式响应，而无需维护复杂的会话层。
但如果业务场景涉及双向控制流（例如多 Agent 协作编辑、实时工具调用反馈），或者需要推送大型二进制载荷，则应考虑 WebSocket 或 gRPC Stream。在大多数纯文本补全场景下，SSE 的简单性带来的开发和运维收益远超其功能限制。
连接保持与心跳参数设计
长连接的稳定性是流式系统的第一道门槛。HTTP 协议本身是无状态的，但实际部署中，代理服务器、负载均衡器和 CDN 通常会为空闲连接设置超时阈值，常见值为 30 秒到 60 秒。当 LLM 推理耗时较长时（特别是复杂推理模型的首次 token 生成），连接很可能被中间设施强制断开。
心跳间隔推荐值为 15 秒。 每隔 15 秒发送一个空注释行 :\n\n（或 data: ping\n\n），可以有效保活经过 Nginx、AWS ALB、CloudFlare 等常见中间件的 SSE 通道。心跳不应包含业务数据，纯粹用于维持 TCP 连接和中间件状态的活跃判定。
超时阈值需根据模型推理耗时设定。 对于大多数对话场景，60 秒至 120 秒的空闲超时足够覆盖首 token 延迟；但在复杂推理任务中，可能需要将超时上限放宽至 300 秒。关键在于设定一个有限的最大值，避免僵尸连接无限占用后端 worker 资源。推荐的做法是将连接超时与模型层面的最大生成时间统一管控：在超过预设阈值（如 180 秒）后主动关闭连接并返回超时错误，而非让客户端无限等待。
断线续传的核心机制
断线续传是可穿戴通流式系统的用户体验保障。当网络抖动、客户端切换网络或服务端短暂重启时，客户端需要能够从断开点继续接收后续 token，而非让用户重新发起完整请求。
实现断线续传需要两个前提条件：序列化和缓冲区。
每个 token 事件必须携带递增的序列号（index 或 sequence_id），从 0 开始顺序编号。客户端在断开后重连时，通过 HTTP Header 或请求参数携带 Last-Event-ID（原生 EventSource 机制）或自定义的 resume_index。服务端根据该索引从缓冲区中取出对应位置之后的 token 继续发送，从而实现无缝续传。
服务端的 token 缓冲区设计需要考虑内存占用和业务语义。 推荐的缓冲区策略是保留最近 2 到 3 秒内生成的 token（大约对应 50 到 150 个 token，具体取决于模型输出速度）。这个时间窗口足以覆盖大多数网络瞬时抖动，而不会显著增加内存压力。对于需要更持久保障的场景（如长文档生成任务），可以将缓冲区扩展为基于 Redis 或内存缓存的会话级存储，按会话 ID 索引。
在客户端一侧，原生 EventSource 已经内置了自动重连能力，但仅依赖默认行为是不够的。推荐在客户端维护自己的重连策略：首次重连使用 1 秒延迟，此后采用指数退避（2 秒、4 秒、8 秒），上限设为 30 秒，并加入随机抖动以避免惊群效应。同时，客户端应当检测到 done 事件后再标记会话结束，避免在收到完整的流式响应前误判为失败。
流式参数与边界控制
除了连接层面的参数，业务层面的参数控制同样关键。以下是一组可落地的推荐阈值，适用于大多数中等规模的 LLM 流式服务：
单次请求最大 token 数 建议限制在 4096 到 8192 之间（取决于模型上下文窗口），配合 max_tokens 参数在请求层面强制约束，防止客户端意外发起过长的生成任务。
并发流数限制 方面，建议按 API Key 或用户 ID 进行单实例并发上限控制，推荐值为 5 到 10 个并发流式连接。超出限制后返回 429 错误并携带重试 - after 信息。
背压处理 策略上，当检测到客户端读取速度显著落后于服务端发送速度时（例如缓冲区积压超过 100 个未消费 token），服务端应主动暂停或降低发送频率，而非持续堆积导致内存溢出。在极端情况下，可以丢弃最旧的待发送 token 并在后续事件中标记 “部分内容已省略”，这比阻塞整个 worker 池更具工程可行性。
可观测性与监控要点
流式系统的监控需要区分两个阶段：连接建立阶段和 ** token 传输阶段 **。
在连接建立阶段，核心指标包括连接成功率、首次 token 延迟（Time To First Token，TTFT）和连接超时率。TTFT 是评估模型推理冷启动性能的敏感指标，如果某模型的 TTFT 显著高于其他模型，往往意味着该模型的调度或推理服务存在瓶颈。
在 token 传输阶段，需要监控 token 速率（tokens/second）、丢事件率（因背压或网络问题导致的事件丢失）和 重连频率。重连频率过高（超过每分钟一次）通常意味着心跳参数或代理超时配置不合理，需要进一步排查。
日志策略 上，不建议对每个 token 都记录完整日志，这会产生巨大的存储开销。推荐的做法是记录每个请求的元数据（请求 ID、用户 ID、模型名称、生成总 token 数、耗时），并在调试模式下按需开启完整 token 流日志。关键事件（如 done、error）应当作为结构化日志的独立字段记录，便于后续查询和分析。
面向多模型场景的特殊考量
当系统同时对接多个模型供应商时，每个模型的推理特性可能差异显著：有的模型首 token 延迟低但 token 输出慢，有的模型则相反。在 SSE 层统一心跳和超时参数的前提下，建议为每个模型单独配置 TTFT 阈值 和 最大生成时长，而不是使用统一的全局配置。这样可以在模型级别实现精细化的流量控制和异常检测。
此外，多模型场景下的一个常见问题是模型返回格式不统一。建议在 SSE 事件层之上设计一个轻量的协议适配层，将不同模型的输出统一映射为 {type: "delta" | "done" | "error", content: string, index: number, meta: object} 的结构。协议层面的统一可以大幅降低前端渲染逻辑的复杂度，使前端能够以一致的方式处理来自不同模型的流式响应。
小结
SSE 在多模型流式补全场景下的工程化落地，核心在于三个层面：连接保活（15 秒心跳、60-300 秒超时）、断线续传（序列号 + 缓冲区 + 指数退避重连）以及 可观测性（TTFT、token 速率、重连频率）。在参数设计上，建议采用模型级别的差异化配置，并通过统一的协议适配层屏蔽多模型返回格式的差异。这些工程实践可以在不引入额外协议复杂度的情况下，为用户提供接近原生对话应用的流畅体验。
参考资料