AI令牌流式传输：重点不在于SSE与WebSocket之争
本文指出，在生产环境中实现AI令牌流式传输的真正挑战并非选择SSE还是WebSocket作为传输协议，而是需要解决重连、恢复、取消、令牌压缩、多用户支持等复杂功能。文章提出了一个分离请求与响应流的架构，并强调了在实际部署中存在的巨大差距。
在AI应用中，令牌流式传输是将模型生成的令牌实时推送给客户端的关键技术。许多开发者首先想到的是SSE（服务器发送事件）与WebSocket的协议选择，但作者指出，真正的困难并不在此。
文章提出了一种适用于生产环境的架构：将用户提示请求与响应流分离。客户端先通过POST请求提交提示，服务器立即返回一个流ID，然后客户端通过另一个GET请求连接该流获取令牌。所有令牌在生成后存入一个令牌缓存数据库中，这样即使连接中断，客户端也能从上次断点处恢复。这种设计天然适用于水平扩展的无状态服务器，因为任何服务器都可以处理请求或响应。
与WebSocket相比，SSE在这个架构中更为简单。WebSocket需要客户端维持长连接并自定义消息格式，而SSE通过HTTP标准实现，并且内置了Last-Event-ID支持断点续传。但无论哪种协议，都必须解决以下生产级问题：重连与恢复、检测连接断开、处理用户取消请求、令牌压缩（将已存储的令牌合并为完整响应）以及多用户或多设备同步。
取消功能尤为棘手：当用户点击停止按钮时，服务器需要中断令牌生成，这要求令牌缓存支持读写检查。而令牌压缩在重连和响应完成后都需要：重连时大量丢失的令牌应一次性发送，而非逐个；响应完成后则需合并存储供后续历史查询。
多用户场景是最复杂的。如果多个用户共享同一个聊天会话，当一个用户发送提示时，其他用户如何自动获取响应？一种解决方案是将整个聊天会话视为一个响应流，所有提示和响应都在该流上传输。
作者强调，简易演示和博客文章与真正生产部署之间存在巨大鸿沟。多数开发者要么没意识到这个差距，要么低估了填补差距的工作量。作为解决方案，他所在的公司Ably提供了一个基于发布/订阅系统的产品，能自动处理上述所有问题，仅需几行代码即可集成。