Skip to content

multi2api v1.9.9

Choose a tag to compare

View all tags
@github-actions github-actions released this 20 Oct 03:27
· 114 commits to master since this release
v1.9.9
767667f

总 token 算法：三条路径统一

v1.9.8 改了「总 token 自己加（prompt + completion），不信上游 total_tokens」，但那个修复只覆盖了渠道路径。live 实测发现账号池的两条路各有一份同样的错。

这个 bug 一共有三个副本

路径 原来的代码 状态
渠道 sseUsage.total() ✓ v1.9.8 修过
账号池非流式 st.toks = completionTokens(resp) ✓ 本版修
账号池流式 s.tokens = UsageInt(chunk.Usage["completion_tokens"]) ✓ 本版修

三条路各自解析字段，所以每修一处就漏掉另一处。 现在统一走 totalTokens()。

live 实测证据（重启后）

11:23:38  tokens=823    out=64    hit=640   miss=119    ✓ == 640+119+64
11:23:53  tokens=39967  out=985   hit=26624 miss=12358  ✓ == 26624+12358+985
11:24:09  tokens=3480   out=1007  hit=640   miss=1833   ✓ == 640+1833+1007

重启前（旧进程）仍是 tokens == out 的旧行为 —— 这个对比就是修复生效的证据。

顺带修正 4 处测试判据

夹具的 usage 是 prompt=1 + completion=1：旧算法得 1（正是 bug 行为），新算法得 2。断言跟着改 —— 不改的话测试会一直拦住正确的修复。

⚠ 仍然存在的两个问题（不在本版范围）

1. 历史数据不回填

尝试过，但 cache_hit_tokens 本身不可信：

hit 的 P50 = 175,232    最大 = 1,039,616
最大那条 hit=1,039,616 而该行旧 tokens=980（差 1060 倍）
而上下文窗口不可能有 100 万 token

疑似读到了累积值而非单次值。照这个回填会把 20 亿级错误量灌进日志，所以放弃。

2. cache_hit_tokens 的值可疑

上面那组数字说明缓存命中量的解析或累加有问题。它影响：

  • 缓存命中率（四窗已隐藏，暂不影响界面）
  • 近 24 小时缓存命中率趋势折线（会显示 >100% 的怪值）

因为新算法用 hit + miss 当总输入，这个可疑字段现在会直接影响 tokens。实测那三条是对的（== hit+miss+out），但前提是 hit/miss 本身可信 —— 这一层还没验。

3. csg 上游不发缓存字段

日志里 hit=0 miss=0，走 total_tokens 回退（tokens=540341 out=1165）。这个回退是合理的，但意味着 csg 的 tokens 仍依赖上游那个可能漏算的 total_tokens。

升级注意

前端 embed 在二进制里，必须重新 build 才能看到界面变化：

git pull
go build -o bin\wb2api-server.exe ./cmd/server
Assets 8
Loading