Streaming + Tool use 真实成本拆解

关键事实

流式不会改变 token 消耗——输入输出 token 数跟非流式一样
流式改变的是 TTFT（Time To First Token）——从 ~2 秒降到 ~200 毫秒
流式 + tool use 的成本陷阱在「反复 stream 同样 prefix」

定价对比（Claude 3.5 Sonnet）

模式	Input	Output	流式加价
非流式	$3/M	$15/M	—
流式	$3/M	$15/M	0

流式本身不贵。成本陷阱在下面。

5 个生产 case

Case 1：纯聊天流式（最常见）

input:  1k token
output: 500 token
成本:   1k × 3 + 500 × 15 = $10.5/M

流式 vs 非流式总成本一样。流式只省 TTFT。

Case 2：Tool use 失败重试

第 1 次:  input 5k + output 2k（含 tool_call 错）= $45
第 2 次:  input 5k + output 1k（修正后成功）= $30
总共:    $75

流式在重试时浪费了——第 1 次 stream 输出 2k token 全是废的。

对策：tool use 失败时不流式（直接 non-streaming 重试，省首 token 延迟但省 token）。

Case 3：长 output（>4k token）

input:  2k
output: 5k
成本:   2k × 3 + 5k × 15 = $81/M

流式在这个 case 下用户感知最好——第一个 token 200ms 出现，之后持续输出。

适合用流式。

Case 4：多 tool use 嵌套

tool 1 → tool 2 → tool 3 → 总结
input 累加:  3k + 4k + 5k = 12k
output:      200 + 200 + 200 + 800 = 1.4k

关键问题：每层 tool 调用的 input prefix 都包含之前所有内容。流式对这种情况没影响——token 数固定。

Case 5：流式 + 用户中断

用户关掉浏览器 / 切走 30 秒
agent 还在 stream 输出
但 token 已经算了

流式在用户中断时最浪费——output token 已经返回并计费，用户没看到。

对策：

加 user activity 监测（visibility API / focus 事件）
用户 5 秒不活动 → 暂停流式

决策树

你的 case
├── 纯聊天 < 2k output
│   └── 用流式（改善体验，成本不变）
├── 长 output > 4k
│   └── 用流式（必须流式，否则首字延迟太高）
├── Tool use 多步
│   ├── 重试概率高
│   │   └── 第 1 次用流式（看响应），第 2 次起非流式
│   └── 重试概率低
│       └── 流式
├── 实时（用户在看）
│   └── 流式
└── 后台批处理
    └── 非流式（流式 0 收益）

写在最后

流式不是 token 优化，是延迟优化。把它当延迟工具用，别当 token 工具用。

真正省 token 的是 T2 · prompt cache + T1 · system prompt 压缩。流式只是锦上添花。

下一篇：Sonnet 4.5 vs 3.5 怎么算账。