糖果题 · 多模型并发测试台

填 URL + Key → 拉取 /v1/models → 勾选多个模型并发跑题,自动判分,并统计 首包、首 token(含推理)、总耗时、tok/s 与 提示缓存命中。

预期答案 21

1 · 接入

只要 URL 和 Key,其它默认即可跑
代理检测中… 未拉取
URL 会智能补 /v1。很多网关不开放浏览器跨域(CORS),「自动」模式在直连失败后会把请求改走本站同源代理 /proxy/<域名>/… 转发;这需要你通过 http://<本机IP>:16666/ 打开本页(file:// 打开时没有代理)。代理默认放行任意域名,换新接口无需改配置;想收窄时可在 /etc/candy-bench/proxy.json 的 allowed_hosts 里列具体域名。
高级设置(轮次 / 并发 / 温度 / 缓存压测前缀 / 提示词)

缓存压测说明:OpenAI 系前缀缓存要求提示 ≥1024 tokens 才自动生效,题目本身太短,所以默认会在这段题目前面塞一段填充文本把上下文顶到阈值以上。填充文本的开头带有 [cache-bench run=… model=…] 标记:每次运行都会换一个随机串,保证 R1 一定是真冷启动(不会被上一次运行预热);同时带上模型名,避免并发时不同模型互相预热对方的缓存。R1 冷、R2 起应能看到 cached_tokens > 0。

2 · 题目

发给模型的就是下面这段文本,可自行替换成任意题目
在一个黑色的袋子里放有三种口味的糖果,每种糖果有两种不同的形状(圆形和五角星形,不同的形状靠手感可以分辨)。现已知不同口味的糖和不同形状的数量统计如下表。参赛者需要在活动前决定摸出的糖果数目,那么,最少取出多少个糖果才能保证手中同时拥有不同形状的苹果味和桃子味的糖?(同时手中有圆形苹果味匹配五角星桃子味糖果,或者有圆形桃子味匹配五角星苹果味糖果都满足要求)
形状苹果味桃子味西瓜味
圆形798
五角星形764
参考答案(21)与最坏情况推演 —— 只在页面看,不会发给模型

关键点:形状能靠手感分辨,所以取糖时可以指定摸圆形还是五角星(口味不可控)。要让“苹果圆+桃子星”或“桃子圆+苹果星”凑齐,就是跟一个刻意拖延的最坏情况对抗。

下界(对手可以拖到第 21 个):对手按「圆形:先给 8 西瓜 → 7 苹果 → 最后 9 桃子;五角星:先给 4 西瓜 → 7 苹果 → 最后 6 桃子」的顺序出糖。
此时:想拿到苹果圆要 ≥9 个圆形;想拿到桃子星要 ≥12 个五角星(4+7+1)→ 9+12 = 21;
另一条路:想拿到苹果星要 ≥5 个五角星;想拿到桃子圆要 ≥16 个圆形(8+7+1)→ 5+16 = 21。
所以 20 个以内对手一定拖延成功,至少 21 个。

上界(21 个一定够):先摸 9 个圆形 —— 圆形西瓜只有 8 个,所以 9 个圆形里必有苹果或桃子。
· 拿到桃子圆 → 转摸五角星,非苹果的五角星只有 4西瓜+6桃子=10 个,第 11 个必是苹果星 → 9+11 = 20 个成功;
· 拿到苹果圆 → 转摸五角星,非桃子的五角星有 4西瓜+7苹果=11 个,第 12 个必是桃子星 → 9+12 = 21 个成功。

常见陷阱:若完全盲摸(不能按形状挑),最坏情况的“坏集合”是「8西瓜圆+9桃子圆+7苹果圆+4西瓜星」共 28 个都还不满足,答案是 29。题目特意说了形状可凭手感分辨,所以正解是 21。

3 · 运行

同模型的轮次按顺序跑,不同模型之间并发
总任务 0 已完成 0 运行中 0 失败 0 正确(21) 0 总墙钟 — 吞吐 —

4 · 汇总(按模型)

冷=R1(须 cached=0 才有效),热=R2 起的中位数;提速=(冷−热)/冷,按首个 token(含推理)
模型判分冷启动首 token缓存后首 token 首 token 提速缓存命中平均总耗时平均输出 tok/s备注
还没有结果

5 · 明细(每次请求)

首包=首个 SSE 包到达,首 token=首个 token(含推理)到达
模型轮状态首包首 token 总耗时提示tok缓存tok输出tok 推理toktok/s提取答案判定回复
还没有请求