sillydaddy

@malagebidi #8 谬奖了，我修改一下之前的错误：

这个错了： 「 Elo 胜率公式：胜率 = 1 / (1 + 10^(分差/400))」
应该是： 「 Elo 得分公式：得分 = 1 / (1 + 10^(分差/400))」

因为 Elo 打分时有「胜」「负」「平」这 3 种。胜者得 1 分，负者得 0 分，平局各得 0.5 分。

我没有考虑平局，所以得出 10 次比赛里面，GLM5.1 也会对 Opus4.7 有 4 次战胜的情况。其实弱者得分，主要是从平局里面得来的（也不排除从战胜中得分，但比例应该很小，特别是分差大的情况下）：

Elo 相差 10 分 得分 51.4% vs 得分 48.6%，A 胜率 2.9%，平局率 97.1%，
Elo 相差 50 分 57.1% 42.9% A 胜率 14.3%，平局率 85.7%
Elo 相差 100 分 64.0% 36.0% A 胜率 28.0%，平局率 72.0%
Elo 相差 200 分 76.0% 24.0% A 胜率 52.0%，平局率 48.0%
Elo 相差 400 分 90.9% 9.1% A 胜率 81.8%，平局率 18.2%
Elo 相差 800 分 99.0% 1.0% A 胜率 98.0%，平局率 2.0%

换成这种的话，GLM5.1 与 Opus4.7 差的 50 分意味着：在 20 次提问中，用户有 3 次觉得 Opus4.7 的答案比 GLM5.1 更好，其余 17 次，都很好。即 3 胜 vs 17 平。

可能这种情况更符合真实情况。

所以，Elo 用在围棋比赛、赛车比赛时，就是绝对实力的差距。因为 1 场比赛，赢就是赢输就是输，不分情况。但用在编程上时，因为是先给定题目，再 PK ，那题目的选择就是比赛的关键变量，出简单题目 PK 与出难题 PK ，结果会不一样，导致分数计算也不一样。

Arena 的 PK 是类似于众包，所以，没办法控制用户向大模型提的问题是什么，难度分布是怎样的。同样 2 个模型，比如 GLM5.1 和 Opus4.7 ，都出简单题目 PK 得到的 2 者分差，肯定比都出难题 PK 时，得到的分差小。

换句话说，如果你自己平时用的时候，问的问题的难度分布（比如 1 个超级简单的，10 个中等难度的，3 个架构设计的），与 Arena 用户在对答案投票时，问的问题难度分布（比如 2 个超级简单的，18 个中等难度的，5 个架构设计的）类似，那这个分数就很适用，分差完美反映了 2 者的实力差距。

Elo 评分还是比较可靠的：Elo 基本是所有赛事都常用的评分机制：围棋、游戏、赛车等等。
这个分数，表明了 2 个对手比赛时的胜率。

Elo 胜率公式：胜率 = 1 / (1 + 10^(分差/400))

Elo 相差 10 分 胜率 51.4% vs 胜率 48.6%，优势比较均衡，运气因素更大
Elo 相差 50 分 57.1% 42.9% 有不小的优势，五六次对局就能看出来
Elo 相差 100 分 64.0% 36.0% 明显优势，约 2:1 的胜率
Elo 相差 200 分 76.0% 24.0% 显著优势，约 3:1 的胜率
Elo 相差 400 分 90.9% 9.1% 碾压性优势，约 10:1 的胜率
Elo 相差 1000 分 99.0% 1.0% 几乎不可能输，约 100:1 的胜率


领先 50 分是什么概念呢？有 10 个问题，都给到 2 个模型，你会采用 A 模型的答案 6 次，B 模型 4 次。如果 2 个模型都很优异，这种采用率的差距比较明显了。但反过来想，如果与 Opus 4.7 thinking 比赛时，GLM 5.1 能在 10 次里面让用户采纳它的答案 4 次，那它的实力也不容小觑。

一个关键点就是，在比赛时，用户向 2 个模型提出的问题是什么，如果是写斐波那契数列程序，那甚至 qwen 都能战胜 opus ，毕竟这么简单的问题，所有的模型都能答的很好，用户只有选择「同样好」，这就会拉近 2 者的分数，如果都是用这样的问题 PK ，那么 Elo 分差就是 0 。

所以，要看 Arena 里面的 13 万次 votes ，用户都是问的什么问题，这是最关键的。如果 13 万次 votes 问的都是中等难度的问题，在中等问题难度 PK 中，都能让分差拉开 50 分，那么在高难度问题中，分差只会更大。

@iorilu 其实就是 1 个页面。参考 README.md ，配置好小米的 api_key 。

https://wormhole.app/KBloE0#PxVWasE4rRXo1UUK0YsM9w

汇报一下我的情况：
等了 24 小时吧，拿到了 7 亿 token 。感觉是因为我上传了 Cursor 里面消耗的 6 亿 token 的截图。

然后简单配了下 API key 。

然后开始用。

1. 为了问清楚给 Cursor 配 API key 的一些疑问（比如 Cursor 自身只开了一个 API key 的槽），调用了 6 次 mimo-v2.5-pro 。花了 0.25 刀，总计 token 73 万。其中 read cached 64 万，read 8 万，output 1 万。

2. 后来发现，上面配的 API key 是按 token 计价的那种，不是用的赠送的 7 亿 credits 额度。所以，又赶紧改回来。然后看到 mimo-v2-tts 模型是免费的，就让 mimo-v2.5 和 mimo-v2.5-pro 生成了一个网页工具（前、后端共 800 行代码），可以调用 mimo-v2-tts API 来实现文字转语音。问了 5 次，花了大概 500 万~600 万 credits 吧，平均一次 100 万 credits 。

效果还可以，还没有深度测试，像上面的工具之类的还可以：



3. 后来发现 mimo-v2.5-pro 算 2 倍费率。用 mino-v2.5 算 1 倍（=2credit?）。

4. credits 消耗太快了，一个编码任务至少 100 万 credits 起步。


谁来用我的邀请码？你我都可以获得$2 的 API key 额度，可以用在 token 计费模式中，与 coding plan 是独立计价的。（第 1 条的 0.25 刀就是用的这个额度）

邀请码：A2ZFD2 。注册： https://platform.xiaomimimo.com?ref=A2ZFD2 （注册后点控制台左下方入口填入，体验金 40 天有效）

本来就没有自定义功能。。