AI 大模型通信机制解析：流式传输与数据封装逻辑

响应格式：非流式

服务端生成完毕后一次性返回所有数据。

• 缺点： 用户需等待数秒才能看到完整回复，体验较差。
• 结构： 包含 id, choices (回复选项), usage (Token 消耗统计)。

JSON 示例：

{
  "id": "chatcmpl-123",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {"role": "assistant", "content": "这是一个冒泡排序的实现..."},
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 20,
    "completion_tokens": 100,
    "total_tokens": 120
  }
}

响应格式：流式

这是现代 AI 聊天的核心体验（打字机效果）。基于 SSE (Server-Sent Events) 技术。

• 传输格式： HTTP 连接保持长连接，服务端分块传输数据。
• 数据帧格式： 每一行以 data: 开头，以 \n\n 结尾。
• 增量更新： delta 字段只包含本次新增的几个字符，而不是全量文本。

原始数据流示例：

data: {"id":"chatcmpl-123","choices":[{"delta":{"content":"这"},"index":0}]}
data: {"id":"chatcmpl-123","choices":[{"delta":{"content":"是"}}]}
data: [DONE]

*注意：实际生产中，为了平衡网络开销和用户体验，服务端通常会设置微小的缓冲（例如攒够 2-3 个 Token 或间隔 10ms）再发送一个 TCP 包，这就是为什么有时看到文字是一小段一小段蹦出来的原因。

流程图分析：从输入到输出

这里分析最常用的流式交互流程，它展示了数据如何在客户端、网关、推理引擎之间流转。

流程逻辑描述

1. 客户端组装数据： 将历史对话和当前输入封装为 JSON。
2. 建立连接： 发送 HTTP POST 请求，Header 设置 Accept: text/event-stream。
3. 网关鉴权与转发： API Gateway 验证 API Key，进行限流，转发至推理服务。
4. 推理引擎处理： LLM 模型逐个 Token 生成内容。
5. 数据分片回传： 每生成一小段文本，立即封装为 SSE 格式推送给客户端。
6. 客户端渲染： 前端接收到 delta 内容，追加到 UI 文本框中。

流程图示意

graph TD
    Client[客户端] -->|HTTP POST /chat/completions<br/>Accept: text/event-stream| Gateway[API 网关]
    Gateway -->|鉴权 & 限流 | Engine[推理引擎]
    Engine -->|Prompt 处理 & Tokenize| Model[LLM 模型]
    Model -->|流式生成 Token| Engine
    Engine -->|SSE 流推送 | Gateway
    Gateway -->|text/event-stream| Client
    Client -->|实时渲染文字 | Render[UI 界面]
    Engine -->|更新 Token 用量 | DB[(数据库)]

原理架构图分析

数据传输不仅仅是格式问题，更涉及到整个系统的架构设计。AI 聊天工具的架构通常采用控制面与数据面分离的设计。

架构层级说明

• 接入层： 负责 HTTP 请求的接入、SSL 卸载、SSE 连接保持。
• 应用逻辑层： 处理会话管理、历史记录存储、Prompt 拼接。
• 推理引擎层： 真正运行模型的地方，如 vLLM, TensorRT-LLM。这一层通常是高算力节点，不直接对外暴露。
• 数据层： 存储 Vector DB (向量数据库用于 RAG) 和 Redis/SQL (会话历史)。

架构图示意

graph TB
    subgraph ClientLayer [客户端层]
        Web[Web/App 界面]
        SDK[OpenAI SDK / HTTP Client]
    end

    subgraph AccessLayer [接入与协议层]
        LB[负载均衡]
        GW[API Gateway<br/>支持 SSE 长连接]
    end

    subgraph LogicLayer [业务逻辑层]
        Session[会话管理服务<br/>上下文拼接]
        RAG[RAG 检索增强服务<br/>向量数据库查询]
        Security[内容安全审核]
    end

    subgraph InferenceLayer [模型推理层]
        GPU[GPU 计算集群]
        Engine[PagedAttention/vLLM]
    end

    subgraph DataLayer [数据存储层]
        Redis[Redis 缓存]
        MySQL[MySQL/Mongo 持久化]
        VectorDB[向量数据库]
    end

    Web -->|HTTPS/JSON| SDK
    SDK -->|POST /chat| GW
    GW -->|鉴权通过 | Session
    Session -->|获取历史上下文 | Redis
    Session -->|查询知识库 | RAG
    RAG -->|组装最终 Prompt| Security
    Security -->|合规请求 | Engine
    Engine -->|调度 | GPU
    GPU -->|生成 Token| Engine
    Engine -->|SSE 流 | GW
    GW -->|text/event-stream| Web
    Engine -->|持久化 | MySQL
    RAG -->|存储 | VectorDB

关键技术原理深度解析

为什么选择 SSE 而不是 WebSocket？

虽然 WebSocket 是全双工的，但在 AI 聊天场景下，数据主要是单向流动（服务端 -> 客户端）。

• SSE 优势：
  • 基于 HTTP，无需握手升级协议，穿透防火墙能力强。
  • 天然支持断线重连（浏览器自动重连）。
  • 数据格式简单（纯文本），解析效率高。
  • 完美契合 LLM 的'生成即推送'模式。

Token 与数据传输的关系

在传输层，我们看到的 JSON 字符串，但在模型计算层，数据是 Token（词元）。

• 原理： 英文通常 1 Token ≈ 4 字符，中文通常 1 Token ≈ 1.5-2 汉字。
• 传输影响： 并非每生成一个 Token 就立即传输一个网络包。为了平衡网络开销和用户体验，服务端通常会设置一个微小的缓冲（例如攒够 2-3 个 Token 或间隔 10ms）再发送一个 TCP 包。

数据压缩

由于 JSON 是文本格式，且包含大量重复的键名（如 choices, delta, content），在高并发场景下，通常会在 HTTP 层开启 Gzip 或 Brotli 压缩，能将数据体积压缩 60%-80%，显著降低带宽成本。

总结

开发或分析 AI 聊天工具时，必须掌握的数据传输核心点如下：

1. 格式标准： 遵循 OpenAI API 的 JSON Schema 结构。
2. 交互模式： 必须支持 stream: true 以提供打字机体验，协议首选 SSE。
3. 数据流转： Client -> API Gateway -> Logic (拼 Prompt) -> Model Engine -> SSE Stream Back。
4. 上下文管理： 客户端发送的 messages 数组通常需要服务端进行裁剪以适应模型的 Context Window（上下文窗口限制）。

这套数据传输体系是目前大模型应用开发的事实标准。