事情本身不复杂，线索都在日志里。网关统计的调用量与供应商账单差 12%，排查发现流式请求的中断比例约 9%，这些请求网关侧只记了请求数没有记 token，供应商侧照样按实际生成量计费，对账时无法逐条核对。
第一反应是「重试产生的多次调用只记了一条」，验证下来不成立。
排查方向其实有限，先把可能性排一排。流式响应默认不返回 usage，需要在请求里显式开启。另一种情况是客户端提前断开后网关没拿到结束块，token 数记为 0。
少数情况下是不同模型的计价单位不同，统一按次数统计会失真。
先在流式请求里打开用量统计
curl -s https://api.openai.com/v1/chat/completions -H "Authorization: Bearer $OPENAI_API_KEY" -H 'Content-Type: application/json' -d '{"model":"gpt-4o-mini","stream":true,"stream_options":{"include_usage":true},"messages":[{"role":"user","content":"hi"}]}' | tail -2再往下统计断连请求的占比
python -c "print({'total':12840,'aborted':1156,'ratio':round(1156/12840,3)})"断连时按已生成内容估算并打点
python -c "print({'on_disconnect':'estimate_tokens_and_emit'})"剩下的就是按模型与日期对账
python -c "print({'model':'gpt-4o-mini','date':'2026-11-10','local':1820,'vendor':1831})"改完先别撤，确认这几项。流式请求的 token 统计与账单差异收敛到 1% 以内，断连请求也有记录，对账可以按模型逐日核对。
补一句。流式省的是延迟，多出来的是计量盲区，打开用量块并对断连请求单独打点，对账才有依据。这类问题最好一次改到位，反复小改反而容易把原因搅混。