加载失败
原文主张“SSE 不适合传输 LLM tokens”引发讨论，评论集中在两个层面：协议本身能否支持续传，和实际系统是否做了持久化/缓存。SSE 规范有 id 字段与重连机制，但若服务端不持久化就无法 resume，因此很多人认为问题在实现或架构而非传输协议。替代方案包括 WebSocket + pub/sub、缓存代理或使用幂等性 key；权衡点在于推理成本高、缓存成本与供应商按 token 计费的商业激励、以及企业安全/运维限制。
多位评论指出作者混淆了SSE协议本身与常见的实现/架构。SSE规范包含 id 字段和重连行为，服务器可以基于序列号或 id 恢复流并让客户端从断点继续接收，从协议层面并不阻止历史回放或 resume。文章之所以看起来不能续传，往往是因为服务端没有做持久化或序列化的实现，而不是因为SSE本身的限制。有人还强调，采用pub/sub层或在SSE之上实现持久化后，就能达到作者期望的行为。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多条评论强调要实现断线重连或回放，唯一办法是在某处存储已生成的tokens，否则只能放弃或重跑推理。具体建议包括客户端生成 UUID/prompt id 并在服务器缓存输出以便后续相同 id 返回缓存结果、使用幂等性 key 来利用缓存、或在前端/边缘放置缓存代理来避免重复推理。评论还指出实际动机与成本权衡：推理成本往往高于传输，缓存可节省重复计算，但大模型供应商按token计费，可能缺乏为你做持久化缓存的商业动力。实现细节还涉及缓存过期策略、是否允许后台继续推理以及用户隐私/缓存开关等工程决策。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
许多人推荐用 WebSocket 配合 pub/sub 将生成的 token 流写入消息层，并用 id 回放给重连的客户端，这在工程上容易实现且支持双向通信。该方案需要额外的内存/消息层资源（DRAM 或队列），并需自动过期或快速清理以避免无谓占用；这也是不少评论提到的实现成本。另一个权衡是继续在后台完成推理可能浪费资源，保存断点时刻的部分结果更节省。企业合规与安全也会影响选择：一些组织更容易批准 SSE 而非 WebSocket，导致可选方案受限。
有人批评原文在没有基准测试或成本/延迟对比的情况下就断言某种传输“更好”，认为這只是个想法而非已被证明的优解。评论要求看到重连率、重复推理成本、实现复杂度等量化数据，才能判断 Pub/Sub 或 WebSocket 是否真优于 SSE。部分评论将问题归结为“skill issue”，指出很多网络与流式问题在既有系统中已有成熟解法，更多是架构选择与实现细节而非新协议的根本缺陷。总体上，讨论倾向于用数据和工程实践来验证结论而不是单纯的观点宣称。
SSE (Server-Sent Events): 一种单向的 HTTP 流式传输机制，用于服务器向浏览器持续推送事件。SSE 规范包含 id 字段和重连逻辑，理论上可以用序列号/ID 实现断点续传与历史回放，但需要服务端保存相应状态。
WebSocket: 浏览器与服务器之间的双向持久连接，适合低延迟双向通信、事件推送和对流的回放（replay），常用于实现 pub/sub 风格的实时消息传递。
pub/sub: 发布-订阅消息传递模式（pub/sub），通过消息总线或队列把生成的 token 流发布，订阅者可按需回放或接收消息，常作为持久化/分发层。
幂等性 key (idempotency key): 请求的唯一标识符，用于判定重复请求并返回相同的缓存结果，从而避免重复触发推理或重复计费。
缓存代理 (caching proxy): 位于 LLM 提供者与客户端之间的仲裁层，用于临时保存已生成的 tokens 或完整响应，以支持重连、回放并减少重复推理开销。