|
|
94c1e7688f
|
fix(gateway): 流式请求从未记录 reasoning_tokens
## 症状
接了一个 reasoning-heavy 的源之后，读生产审计文件发现：它的**流式**请求全部
只有 completion、没有 reasoning。实测对照：
流式 compl=8166 reasoning=— ← 网关记的
非流式 compl=751 reasoning=167 ← 同一个 adapter，非流式正常
客户端两种情况的响应都正确，所以**没有任何报错**。只有审计记录更安静。
## 根因
两条记账路径，只有一条读了它：
recordChatUsage(非流式) 读 resp.TokenUsage.CompletionTokensDetails
流式的 usage 合并(内联在 handler) 只读 Prompt 和 Completion
cache 记账当时被镜像过去了，**reasoning 单纯没加**。所以一个花了几百 token
思考的模型，在流式下看起来像什么都没想。
这不是 qwen38 的问题 —— 是任何流式 reasoning 模型的问题，之前没有源暴露它。
## 为什么是「读审计文件」发现的，而不是失败的测试
现有判据 `TestRecordChatUsageKeepsReasoningTokens` 只覆盖非流式那条路径。
流式那段内联在 handler 里，测不到。抽出 `applyStreamUsageDetails` 之后
才有地方挂判据 —— 抽取不是为了好看，是因为不抽就没法测。
## 判据（四条）
- 流式记录 reasoning，且精确值（512）
- **reasoning 绝不被加进 completion** —— 关系式断言，不是「字段存在」检查。
写成 `rec.Compl += reasoning` 会让每个思考 token 被收两次费。
- 上游没报 reasoning 时不写字段（0 在审计里表示「未上报」，与「没思考」不同）
- cache 记账未被顺带破坏 —— 三种输入形态各测一遍
变异自证三次变红：删掉 reasoning、加到 completion 上、破坏 cache 块。
第四次变异（`d.ReasoningTokens > 0` 改成无条件赋值）没变红 —— 那一版与原版
**行为完全相同**：rec.Reasoning 初值就是 0，且 json tag 带 omitempty，两种情况下
客户端都看不到这个字段。这是无行为差异的变异，不是判据漏放。
## 生产实测
部署前（13 条）：compl=204/277/1822/1264/740/… reasoning 全部未记录
部署后（ 1 条）：compl=213 reasoning=42 status=200
Co-Authored-By: ModelRouter <noreply@modelrouter.dev>
|
2026-10-06 15:02:42 +08:00 |
|
