docs: 采纳独立复核精化 v6 注释与不变量(reserve 阈值/consume 快照口径)

docs/volc-quota-notes.md

@@ -259,7 +259,7 @@ limit = balance_at_sync + usage_at_sync - SMALL_BUFFER(5 万) = B0 + L - SMALL_B
 真实剩余 = `B0 − usage` = **`SMALL_BUFFER + reserve − L`**。
 
 - L=0(滞后收敛)：剩余 = SMALL_BUFFER + reserve > 0 → **永远不扣费** ✓(原论证仅此情形成立)
-- L > SMALL_BUFFER：剩余可 < 0 → **已进扣费区** ✗
+- L > SMALL_BUFFER + reserve：剩余 < 0 → **已扣费**(超扣下界,取决于 reserve;保守写 L > SMALL_BUFFER)
 - **今日为何安全(08-13)**：真实 B0=2,242,178 > 静态 2M → `min(2M, B0+L−S)` 被静态 2M 压住，
   撞线发生在 usage=2M，真实剩余 242,178 > 0——是**静态墙**兜底，不是 v6 不变量。
   **若某日 B0 < 2M(包变小)，静态墙失效，L > SMALL_BUFFER 即可能超扣。**
@@ -357,8 +357,9 @@ reserve = input_tokens + max_out
 **为什么中文偏高更安全**：DeepSeek 自有 tokenizer 对中文 ~1.5 token/字，
 cl100k_base ~2-3 token/字。估算偏高 = 预留更多 = 提前撞线 = 更保守。
 
-**效果**：输入 200k 的请求，旧 reserve 只有 50k，新 reserve 250k+，
-在 usage=1.8M 时就拦住(而非放行后超 2M)。
+**效果**：输入 200k 的请求，旧 reserve 只有 50k，新 reserve 250k+，在 usage=1.8M 时拦住
+(而非放行后超 2M)。⚠️ 该阈值仅对 `input ≥ 150k` 成立(由 `1.8M + input + 50k ≥ 2M` 反推)；
+小输入请求(如 126k)仍会在 usage<2M 时放行，封口实际依赖后置 `soft_evict`(见下节)。
 
 #### 后置闸门兜底
 
@@ -378,8 +379,12 @@ if current_total >= effective_limit:
 | **前置** | `reserve = token_counter(messages) + max_tokens` | 预估超限的请求 | 实际消耗 > reserve 的请求 |
 | **后置** | `current_total >= effective_limit → soft_evict` | 超限后的后续请求 | 已发出正在执行的请求 |
 
-**遗留**：若 `max_tokens` 未声明且模型输出无上限，前置仍可能预估过低。
-此时只有后置 `soft_evict` 兜底(挡后续不挡本次)。
+**遗留解决（2026-08-13 短文本实证）**：`max_tokens` 未声明时前置仍可能预估过低；更隐蔽的是
+**思考模型** —— deepseek-v4-flash(ga-260731) 默认思考模式，usage.total_tokens 含 reasoning tokens
+且不受 `max_tokens` 限制（max_tokens 只约束正文 completion）。实测「彩虹有几种颜色」：
+reserve = 18输入 + 16声明 = 34，实际消耗 +167/+150（正文 ~16 + 思考 ~120-130）。
+修复：输出侧取 `max(声明 max_tokens, THINKING_RESERVE_FLOOR=4096)` 兜底思考开销。
+大输入请求仍偏保守（cl100k_base 中文 2-3 token/字高估），方向安全。
 
 ---
 
@@ -396,6 +401,7 @@ if current_total >= effective_limit:
    与消耗扣减区分(如 08-12 余额 1,558,307 → 596,869，其中约 50 万为滞后修正 + 过期)
 6. 2M 采集上限可被单请求 + 并发击穿(§7.6)：reserve 估算不足时已放行的请求继续消耗，
    `soft_evict` 后置兜底只能挡后续。修复：reserve = `litellm.token_counter(messages)` + `max_tokens`
+   （输出侧另加 `THINKING_RESERVE_FLOOR` 兜底思考模型 reasoning tokens，§7.6）
 7. B0 守恒仅在 API 滞后收敛后成立；同步快照期间 `balance + usage = B0 + L`(虚高，§4.2)，
    不是真实 B0。判扣费用网页真实初始余额或收敛时点反推
 
@@ -415,5 +421,9 @@ if current_total >= effective_limit:
 - [ ] 数据库泄漏：08-12 一天 deepseek-v4 消耗记录量级约 5 万条导致 Redis 内存膨胀；触发监控/清理机制
 - [ ] v6 无静态 2M 兜底时的安全：08-13 幸由 B0(2,242,178) > 2M 静态墙兜底；若某日 B0 < 2M，
       滞后 L > SMALL_BUFFER 时 v6 限额虚高 → 可能放行到余额 0 → 扣费(§7.5 遗留风险 1)
-- [ ] reserve 精度验证：token_counter fallback cl100k_base 对中文偏高，需实测确认偏差范围
-      (DeepSeek 自有 tokenizer ~1.5 token/字 vs cl100k_base ~2-3 token/字，§7.6)
+- [x] reserve 精度验证(2026-08-13 短文本实证：估算 34 vs 实际 167 的根因 =
+      思考模型 reasoning tokens 不计入 reserve，已用 THINKING_RESERVE_FLOOR 兜底；
+      token_counter cl100k_base 对中文偏高对输入侧仍是安全方向)
+- [ ] consume clamp2 余额快照口径不同步：`plan ≤ balance − SMALL_BUFFER` 用拉包时刻余额快照
+      (volc_consume.py:455)，**不含 23:00→00:00 真实用户消耗**；clamp1 用共享 daily_usage 实时精准，
+      但余额维度两方不同步。深夜真实消耗大时两方合计可超烧余额。建议运行时重取余额或扣减预估