1. 今天的 Chat Streaming 到底在流什么？#

OpenAI-compatible /v1/chat/completions 的常见流式接口，本质上是不断发送结构化 delta。

最简单的情况是：

1
模型 token
2
  ↓
3
detokenizer
4
  ↓
5
text delta
6
  ↓
7
SSE
8
  ↓
9
浏览器

如果模型只是普通聊天，这个模型看起来很自然。

例如模型内部生成：

1
[1234, 567, 89, 42]

detokenize 后可能逐步得到：

1
"你好"
2
"，"
3
"世界"
4
"！"

于是客户端只保存：

1
你好，世界！

对于“展示内容”，这通常足够。

但如果你的目标变成：

中断后精确恢复模型的输入前缀

文本就不再是最可靠的状态表示。

为什么？

因为 tokenizer 并不是“一个汉字 = 一个 token”，也不是“一个文本 delta = 一组唯一 token”。

实际系统里还存在：

• whitespace normalization；
• special tokens；
• byte fallback；
• Unicode 边界；
• incremental detokenization；
• reasoning parser；
• tool-call parser；
• structured output parser；
• stop token trimming。

客户端看到的文本，可能已经经过多层转换。

而真正让模型继续运行所需要的，是模型词表空间中的 token prefix。

2. SGLang 当前为什么不允许 Chat Streaming 直接 return_token_ids？#

SGLang 当前主线代码已经存在 return_token_ids 和 return_prompt_token_ids 等扩展字段。

但在 /v1/chat/completions 的 streaming 路径中，代码会显式拒绝它们。

当前实现中可以看到类似约束：

1
if request.stream:
2
    if request.return_prompt_token_ids:
3
        raise ValueError(...)
4

5
    if request.return_token_ids:
6
        raise ValueError(
7
            "return_token_ids is not supported with streaming on "
8
            "/v1/chat/completions..."
9
        )

源码：

SGLang serving_chat.py

这并不是因为 SGLang 完全没有 token-ID streaming 的基础设施。

相反，/v1/completions 的 streaming 实现里已经存在对 output token IDs 做增量切片的逻辑：

1
output_ids
2
  ↓
3
按照上一次发送位置切片
4
  ↓
5
chunk_token_ids

源码：

SGLang serving_completions.py

所以今天这份 RFC 真正要补的，不只是“把某个字段从 false 改成 true”。

难点在于 Chat Completions 比传统 Completions 多了一层语义解析系统。

3. Reasoning 与 Tool Calling 让“文本 delta = token delta”彻底失效#

这是整个问题最值得注意的地方。

现在的大模型输出已经不再只是：

1
Hello world

模型原始生成序列可能同时包含：

• reasoning token；
• final answer token；
• tool name；
• tool arguments；
• special delimiters；
• parser control tokens。

然后 Serving 层再把这些 token 解析成 OpenAI-compatible 结构。

一个简化流程可能是：

1
raw model tokens
2
      │
3
      ├── reasoning parser ──> reasoning_content
4
      │
5
      ├── tool parser ───────> tool_calls
6
      │
7
      └── text parser ───────> content

也就是说：

客户端收到的是协议层事件，而不是模型原始生成日志。

某些 token 甚至可能：

• 不直接出现在 content 中；
• 被 parser 吃掉；
• 被合并进一个 tool call；
• 在多个 SSE chunk 之间重新切分。

于是，如果你试图这样做：

1
resume_text = "".join(all_content_deltas)
2
new_prompt = old_prompt + resume_text

你很可能得到的只是“看起来像之前内容”的文本，而不是模型当时真正走过的 token prefix。

对于普通自然语言聊天，也许多数情况下看不出差异。

但对以下场景就可能出问题：

• JSON schema generation；
• function calling；
• reasoning model；
• code generation；
• grammar constrained decoding；
• tokenizer-sensitive prompt；
• 带特殊控制 token 的模型。

这就是为什么这份 RFC 强调：

raw token-ID stream 应该独立于 parsed text / tool-call delta。

这个设计思路非常重要。

4. “Transport Resume”与“Generation Resume”不是一回事#

很多现有系统已经支持“可恢复流式输出”。

但这里必须问一句：

它恢复的到底是什么？

1
LLM generation continues
2
        │
3
        ▼
4
server-side stream buffer
5
        │
6
   client disconnects
7
        │
8
        ▼
9
client reconnects
10
        │
11
        ▼
12
replay missing chunks

1
网络连接断了
2
≠
3
推理任务本身必须重启

1
推理任务真的中断了
2
→
3
我能不能保存一个模型可重新消费的精确 token prefix？

5. Raw Token Stream 到底提供了什么能力？#

可以把 RFC 的核心状态简化成：

1
P = prompt_token_ids
2
O = output_token_ids_so_far

中断时，客户端持久化：

1
checkpoint = P + O

恢复时：

1
input_ids = checkpoint

然后重新调用生成。

SGLang 本身的 generation API 已经支持 input_ids 作为文本输入形式之一。

文档：

SGLang Sampling Parameters - input_ids

于是恢复链路变成：

1
messages
2
   │
3
chat template
4
   │
5
P = prompt token IDs
6
   │
7
model generates O1 O2 O3 ...
8
   │
9
raw token stream
10
   │
11
client persists P + O
12
   │
13
request interrupted
14
   │
15
new request(input_ids=P+O)
16
   │
17
continue decoding

最大的价值是：

你不需要把“屏幕上的文本”重新猜回模型 token 序列。

6. 但它并不等于“零成本恢复”#

这里很容易出现第二个误解：

既然 token 都保存了，那恢复是不是瞬间完成？

不一定。

Raw token prefix 解决的是逻辑状态可重建性，不是自动保存 GPU runtime state。

假设原请求：

1
prompt = 100,000 tokens
2
output = 8,000 tokens

中断以后你把：

1
108,000 tokens

重新作为 input_ids 发给另一台 Worker。

如果新 Worker 没有对应 KV Cache，它仍然必须对这 108k token 做 prefill，重建 attention state。

所以：

1
Token Prefix Resume
2
≠
3
KV Cache Resume

更加准确地说：

1
raw token checkpoint
2
解决“生成历史是什么”
3

4
KV checkpoint / cache transfer
5
解决“历史计算结果是否还在”

这是两条完全不同的优化轴。

7. Prefix Cache 能不能让恢复更快？#

如果 Serving 系统的 prefix cache 恰好还保留：

1
P + O[0:k]

那么恢复请求就有机会复用已有 cache。

这时流程可能变成：

1
P + O
2
  │
3
lookup prefix cache
4
  │
5
命中已有部分 KV
6
  │
7
只 prefill 未命中的 suffix
8
  │
9
继续 decode

但这里有几个现实限制：

• 恢复请求可能被调度到另一台 Worker；
• cache 可能已经 eviction；
• tokenizer/config/model revision 必须一致；
• LoRA adapter 必须一致；
• multimodal embedding 状态可能不能仅靠 text token 重建；
• hybrid recurrent model 还可能有额外 recurrent state；
• speculative decoding 的 draft model 也有自己的状态。

所以真正成熟的 resumable serving 通常需要同时考虑：

1
Protocol checkpoint
2
+ Scheduler routing
3
+ Prefix-cache locality
4
+ Runtime-state compatibility

而不是只加一个 HTTP 字段。

8. Raw Token IDs 仍然不等于“完全相同的未来输出”#

再深入一步。

假设第一次请求已经生成：

1
A B C D

然后中断。

你用精确 token prefix：

1
Prompt + A B C D

恢复。

后面的 token 是否一定和“如果第一次请求没有中断”时完全相同？

也不能一概而论。

因为后续生成除了依赖 token prefix，还可能依赖：

• sampling RNG state；
• temperature；
• top-p / top-k；
• repetition penalty bookkeeping；
• speculative decoding state；
• distributed reduction numerical differences；
• model / kernel revision；
• deterministic execution configuration。

如果是：

1
temperature = 0

并且执行环境稳定，那么 token-prefix continuation 更容易得到一致结果。

如果是随机采样：

1
temperature > 0

即使 prefix 完全相同，恢复后的 future trajectory 也未必与原本未中断时一模一样，除非采样状态也被恢复或系统提供足够强的确定性保证。

所以我们最好区分两个目标：

9. Token Checkpoint 应该绑定哪些元数据？#

如果未来真的实现生产级 raw-token resume，我不会只保存：

1
{
2
  "token_ids": [1, 2, 3]
3
}

因为 token ID 本身只在一个确定的 tokenizer / model contract 下有意义。

更合理的 checkpoint 至少应该考虑：

1
{
2
  "model": "...",
3
  "model_revision": "...",
4
  "tokenizer_revision": "...",
5
  "input_ids": [],
6
  "output_ids": [],
7
  "sampling": {
8
    "temperature": 0.0,
9
    "top_p": 1.0
10
  },
11
  "adapter": null,
12
  "created_at": "..."
13
}

如果是更严格的系统，还应该加入：

• chat template hash；
• tokenizer hash；
• LoRA identity；
• grammar / JSON schema identity；
• reasoning mode；
• tool schema version；
• server implementation version；
• model quantization identity。

可以把它理解成一个：

Generation Checkpoint Contract

这个词是本文的工程归纳，不是 SGLang 官方术语。

10. 为什么 Tool Calling 特别需要 raw token checkpoint？#

想象模型正在生成：

1
{
2
  "name": "search_code",
3
  "arguments": {
4
    "query": "..."
5
  }
6
}

但 OpenAI-compatible stream 可能把它拆成很多 tool_calls.delta。

甚至 parser 会把模型特有格式：

1
<tool_call>...</tool_call>

转换成标准字段。

如果中断发生在中间：

1
raw token stream
2
   ↓
3
parser state
4
   ↓
5
partial JSON

你只保存 parser 输出，很难保证能够重新构造：

1
模型真实 token prefix

这时 raw token checkpoint 很像数据库的 WAL：

• UI 可以有自己的 view；
• protocol 可以有自己的 parsed representation；
• 但恢复时应该依赖更接近事实源的数据。

当然，这个类比不是严格等价，只是为了说明分层思想。

11. 对 Coding Agent 来说，这比普通聊天重要得多#

普通聊天中断一次，用户可能重新问一句就行。

Coding Agent 不一样。

一个真实 Agent 回合可能包含：

1
读取 40 个文件
2
→
3
分析依赖图
4
→
5
规划修改
6
→
7
生成长 patch
8
→
9
准备 tool call
10
→
11
执行测试
12
→
13
继续修复

如果一次模型 generation 本身就非常长，中断会带来明显浪费。

尤其是：

• 100k+ context；
• reasoning-heavy model；
• 大型代码 diff；
• remote GPU；
• spot / preemptible instance；
• server rolling upgrade。

这时“可恢复生成”就不只是 UX 功能，而是资源效率问题。

可以粗略写成：

1
Wasted Compute
2
≈
3
Repeated Prefill
4
+
5
Repeated Decode
6
+
7
Repeated Tool Planning

raw token checkpoint 至少可以减少“必须重新生成已经生成过的 decode prefix”这一部分浪费。

至于 prefill 是否能省，则取决于 cache locality 与 runtime state 是否还存在。

12. 我会怎样设计一套真正可复现的测试？#

如果未来 SGLang 把 RFC 落地，我认为不能只测试：

1
接口里有没有 output_ids 字段

应该做故障注入。

1
temperature=0
2
max_tokens=4096

1
Prefix Exact Match
2
Post-resume Exact Match
3
Resume TTFT
4
Repeated Prefill Tokens

1
streamed text
2
→ tokenizer.encode(text)
3
→ resume

1
raw output_ids
2
→ resume

1
parsed tool delta
2
raw token IDs

1
raw reasoning tokens
2
→ parser
3
→ reasoning_content / final content

1
temperature=0

1
temperature=0.8

1
resume prefix 是否精确
2
future token trajectory 是否精确

1
resume TTFT
2
prefix cache hit tokens
3
prefill tokens
4
GPU time
5
end-to-end latency

13. 一个更完整的 Agent Serving 恢复架构#

如果让我为长任务 Agent 做设计，我会把恢复能力分成四层。

1
浏览器断网
2
移动网络切换
3
WebSocket/SSE reconnect

1
prompt token IDs
2
+
3
raw output token IDs

1
推理进程真正终止以后还能从逻辑 prefix 重建

1
KV Cache
2
recurrent state
3
possibly draft-model state

1
避免长前缀重新 prefill

1
messages
2
tool results
3
workspace state
4
file patches
5
approval state
6
budget

1
模型 generation 恢复之后，整个 Agent workflow 仍然一致

14. 为什么这个 API 可能值得进入 OpenAI-compatible 扩展层？#

现在推理框架越来越多：

• SGLang；
• vLLM；
• llama.cpp；
• TensorRT-LLM；
• 各云厂商自研 serving stack。

大家通常都兼容：

1
/v1/chat/completions

但“高可靠长任务”需要的能力早已超出最初 Chat API 的设计目标。

如果每个框架分别发明：

1
return_ids
2
return_token_ids
3
raw_tokens
4
resume_prefix
5
stream_checkpoint

客户端最终又会出现一层适配地狱。

所以从工程生态看，raw-token streaming 的价值不一定只在 SGLang 自己。

真正值得观察的问题是：

LLM Serving API 是否会逐渐从“文本生成接口”升级为“可恢复生成状态接口”？

这比“多一个字段”重要得多。

15. 这件事和上午讲的 MCP Roadmap 有什么区别？#

今天上午我写的是 MCP 的 Agent Runtime 演化：

• Tasks；
• Events；
• Identity；
• Progressive Discovery；
• HTTP transport。

它关心的是：

Agent 与工具系统如何通信、委托和管理长任务。

而本文关心的是更底层的一层：

当 Agent 背后的模型 generation 自身被中断时，Serving Runtime 如何留下可以继续的精确生成前缀？

一个在 Agent Protocol 层。

一个在 Model Serving State 层。

二者最后确实可能在长任务 Agent 中相遇，但不是同一个问题。

16. 我认为这个 RFC 最值得继续追踪的五个问题#

结论：真正值得保存的不是“最后一句话”，而是生成轨迹#

过去我们做 Chat UI 时，通常认为：

1
messages[]

就是全部状态。

到了 Coding Agent、长上下文推理、分布式 Serving、可抢占 GPU 和长时间 reasoning 时代，这已经越来越不够。

模型生成过程本身开始拥有值得被持久化的状态。

SGLang 这份 2026 年 8 月 26 日的新 RFC 还只是提案，不应该把它写成已经 GA 的功能。

但它提出的问题非常真实：

如果客户端只拥有解析后的文本，而没有模型真实生成过的 token prefix，那么“恢复生成”就缺少一个稳定的事实源。

raw token stream 提供的正是这个事实源候选。

不过工程上必须继续保持边界清晰：

1
SSE Replay
2
≠
3
Token Prefix Resume
4
≠
5
KV Cache Resume
6
≠
7
Full Agent State Resume

如果未来要做真正可靠的长任务 Coding Agent，我更愿意把恢复体系设计成：

1
事件流可重放
2
+
3
生成 token 可 checkpoint
4
+
5
缓存尽可能可复用
6
+
7
Agent workflow 独立持久化

而不是把希望全部寄托在“一条不会断的 HTTP 连接”上。

因为在真正的生产系统里，连接一定会断，Worker 一定会升级，GPU 一定会被重新调度。

可靠系统的目标从来不是永不中断，而是中断以后仍然知道自己走到了哪里。

参考资料#

• SGLang RFC: Resumable raw token stream for /v1/chat/completions
• SGLang: serving_chat.py
• SGLang: serving_completions.py
• SGLang Docs: Sampling Parameters / input_ids
• Cloudflare Agents: Resumable Streaming
• llama.cpp server: Resumable streaming