DeepSeek加速了模型平权，随之而来的是大模型推理需求的激增。推理并发的提升，正在催生计算、存储、网络等领域新的工程化需求。在大模型应用场景中，一个基础性的技术问题摆在每个开发者面前：客户端和服务端之间的实时通信到底该用什么协议？
传统Web应用依赖的HTTP请求响应模式，在大模型流式输出的场景下显得力不从心。SSE、WebSocket、gRPC各有千秋，而IETF等标准化组织也在探索面向Agentic AI的新型协议。本文将系统梳理大模型实时通信的协议选型路径，帮助开发者在不同场景下做出合理的技术决策。
一、大模型应用对通信协议的新需求
1.1 从全量输出到流式输出
传统AI对话系统的全量输出模式存在显著缺陷：用户需等待完整响应才能看到内容，交互卡顿感强烈。流式输出技术通过将响应拆分为多个数据块实时传输，使对话界面能够逐字或逐段显示内容。
流式输出的核心价值在于：首块数据平均在200毫秒内到达，比全量输出快3到5倍；减少客户端内存占用；支持打字机效果、实时纠错等增强功能。某电商客服系统接入流式输出后，用户平均等待时间从4.2秒降至1.8秒。
1.2 大模型场景的通信需求特征
不同类型的大模型应用对网络通信的需求不尽相同，但几乎都离不开以下几点：
实时对话是基础需求，用户与模型进行连续交互，模型需要即时响应。这要求通信协议具备低延迟特性。
流式输出是最核心的差异化需求。大模型生成内容时，需要逐字或逐句返回结果，而不是一次性返回。这要求协议支持服务端向客户端的持续数据推送。
长时任务处理同样关键。大模型可能需要较长时间处理复杂任务，同时需要向客户端反馈进度，尤其是处理长文本以及多模态内容时。大模型计算的响应消耗的资源远超人为写入的业务逻辑，这也是为什么大模型计算要依靠GPU而非CPU。
二、传统HTTP协议为何不够用
2.1 HTTP的请求响应模型
大模型应用出现前，互联网在线应用以Web类应用为主，通常通过HTTP/HTTPS协议与服务器通信。HTTPS是一种无状态的、应用层的协议，基于请求响应模型，每次请求都是独立的，服务器不会保存客户端的状态。
HTTP的优势在于简单易用、广泛支持，几乎所有的浏览器、服务器和开发框架都支持HTTP。它支持多种数据格式，无状态特性简化了服务器的设计，适合分布式系统。
2.2 HTTP在大模型场景中的短板
传统HTTP协议在大模型实时通信场景中面临三个核心问题：
长等待问题。HTTP请求响应模式要求客户端等待服务端处理完所有内容后才能收到完整响应。在大模型生成长文本时，用户需要等待数秒甚至数十秒才能看到结果。
单向通信局限。HTTP是客户端发起请求、服务端返回响应的模式。虽然支持分块传输，但在需要服务端主动推送的场景下实现复杂。
状态管理缺失。HTTP的无状态特性在多轮对话场景中需要额外的机制来维护会话上下文，增加了实现复杂度。
三、SSE：大模型流式输出的首选方案
3.1 SSE的工作原理
SSE是一种基于HTTP的网络通信协议，允许服务器向客户端单向推送实时数据。客户端和服务端之间需要频繁地传输生成的内容，SSE支持服务器一边生成结果，一边分块发送给客户端，用户能逐步看到生成的内容。
SSE的主要特点包括：
高效的单向通信。SSE专为服务端到客户端的单向通信设计，完美匹配大模型场景：客户端发送一次请求，服务端持续返回流式结果。
低延迟。每次生成一个token即可立即推送，避免传统HTTP请求响应模式的长等待。
轻量协议。基于HTTP/HTTPS，无需额外协议握手，减少连接开销。
3.2 SSE的流式响应格式
SSE响应使用标准的text/event-stream格式，服务端通过data:前缀推送数据块。OpenAI、Anthropic、Google Gemini等主流大模型提供商均采用HTTP/2加SSE作为流式输出的传输方式。
SSE的优势还体现在其回退能力上。当HTTP/2不可用时，SSE可以降级到HTTP/1.1正常工作，而gRPC在纯HTTP/1.1环境下可能无法运行。
3.3 SSE的适用场景
SSE最适合以下大模型应用场景：
简单对话场景，如智能客服、问答机器人，客户端发送一次请求，服务端持续返回流式结果。
需要打字机效果的文本生成应用，用户希望看到逐字输出的过程。
开发者希望快速实现流式输出、不想引入复杂双向通信协议的场景。
四、WebSocket：双向交互场景的利器
4.1 WebSocket的全双工能力
WebSocket是一种网络通信协议，允许在客户端和服务器之间建立全双工、持久的连接，实现实时、双向的数据传输。
WebSocket的核心特点包括：
全双工通信。客户端和服务器可以同时发送和接收数据，无需等待对方完成。
持久连接。连接建立后保持打开状态，直到主动关闭，避免了反复建立连接的开销。
低延迟。数据可以即时传输，适合实时应用。
4.2 WebSocket的适用场景
当SSE的单向通信能力无法满足需求时，WebSocket成为必要选择：
需要双向实时通信的复杂对话系统，如多轮谈判、实时翻译。
用户与AI进行连续交互、模型需要基于用户反馈动态调整输出的场景。
语音AI应用，等待过长的响应会让交互显得生硬，WebSocket可以帮助实现更自然的交互体验。
4.3 WebSocket的实践考量
WebSocket的优势伴随一定的实现复杂度。如果WebSocket连接断开，客户端和服务端都会丢失共享状态。与HTTP可以简单重试失败请求不同，恢复断开的WebSocket连接通常需要从零重建上下文，这使得WebSocket应用的健壮实现更加复杂。
在生产环境中使用WebSocket时，需要关注以下优化要点：心跳机制保持连接，建议30秒间隔；缓冲区控制，推荐512KB阈值；错误重连策略，使用指数退避算法。
五、gRPC：高性能服务间通信的选择
5.1 gRPC的核心优势
gRPC是Google开源的高性能远程过程调用框架，基于HTTP/2构建，支持双向流式通信。它使用Protocol Buffers定义API，提供模式验证和强类型支持。
gRPC的核心优势包括：高性能，基于HTTP/2的多路复用和低延迟特性；强类型，Protobuf定义API，提供模式验证；流式支持，原生支持客户端流、服务端流和双向流。
5.2 gRPC的适用场景
gRPC最适合：高吞吐的服务间通信、需要强类型和模式验证的系统、以及已经采用微服务架构的团队。如果应用是纯浏览器端且不需要服务间的高性能通信，gRPC可能不是最优选择。
六、协议选型决策框架
6.1 SSE与WebSocket与gRPC对比
| 维度 | SSE | WebSocket | gRPC |
|---|---|---|---|
| 通信方向 | 服务端到客户端单向 | 全双工双向 | 全双工双向 |
| 协议复杂度 | 低 | 中 | 高 |
| 浏览器兼容性 | 全支持 | IE不支持 | 需gRPC-Web |
| 连接开销 | 2个TCP包 | 4个TCP包 | 基于HTTP/2 |
| 适用场景 | 简单流式输出 | 双向实时交互 | 高性能服务间通信 |
6.2 选型建议
基于以上分析，选型决策可以参考以下路径：
对于简单对话场景，优先使用SSE。这是最轻量的方案，与主流大模型API的流式输出方式一致，实现简单、兼容性好。
对于需要双向实时交互的复杂场景，选择WebSocket。当应用需要多轮实时对话、用户动态干预模型输出时，WebSocket的全双工能力不可或缺。
对于服务间通信的高性能需求，考虑gRPC。当通信发生在后端微服务之间，且需要强类型和模式验证时，gRPC是最佳选择。
6.3 新趋势：面向Agent通信的协议演进
IETF等标准化组织正在探索面向Agentic AI的新型通信协议。SLIM作为一种新兴方案，支持基于MLS的安全组通信、流式RPC和连接多路复用，旨在解决分布式Agent系统的通信需求。此外，ACP的Streamable HTTP传输协议也在推进标准化。
这些新协议尚处于早期阶段，对于当前的生产应用，SSE和WebSocket仍然是成熟可靠的选择。
结语
大模型客户端的实时通信协议选择，没有放之四海而皆准的答案。SSE以轻量、简单成为流式输出的默认选择，WebSocket以全双工能力支撑双向交互场景，gRPC以高性能和强类型服务服务间通信。
对于绝大多数大模型应用，一个务实的策略是：用SSE实现流式输出，仅在需要双向交互时才引入WebSocket，用gRPC处理服务间通信。随着Agentic AI和标准化协议的演进，这一格局可能会持续变化，但SSE和WebSocket在可预见的未来仍将是AI应用实时通信的基石。