35道Rust并发锁实测：最贵大模型竟被便宜6倍对手碾压？

1. 先交代一下这次测试的来龙去脉

最近圈子里一直有人在传 gpt-6-sol、claude-opus-5.5、grok-4.7 这些新版本号，说是编程能力又上了一个台阶，价格也一个比一个离谱。我看了下报价，最贵的和最低的能差出 6 倍，心里就犯嘀咕：贵这么多，到底贵在哪？是真能解决复杂工程问题，还是单纯版本号看着唬人？

正好我们团队下一步打算把一部分代码生成工作交给大模型来干，预算有限，不可能无脑选最贵的。我干脆自己设计了一组测试，用 35 道编程题把这几个模型拉出来遛了一圈，重点放在 Rust 并发锁相关的任务上。为什么压这个方向？因为并发场景最容易暴露模型对语言特性和系统级约束的理解深度，而且网上很少有人拿这类题目做横向对比。

结果有点出乎意料：最贵的那个模型，在带并发锁的 Rust 任务上输了，而且不是小输，是被便宜 6 倍的对手按在地上摩擦。这篇文章把我的完整测试过程、题目设计逻辑、评分标准、翻车现场复盘都记录下来，给打算选型的人一个参考。如果你是做技术选型、写 Rust、或者单纯想知道大模型写并发代码到底靠不靠谱，这篇可以直接当作业抄。

1.1 为什么突然想测一轮编程题

先说背景。我们团队有一批内部工具需要从原型快速推进到可用状态，涉及大量 Rust 代码，尤其是带并发状态管理的模块。大家都有共识：大模型写简单算法题没问题，但到了真实工程里，能不能处理好锁、所有权、生命周期这些硬约束，完全是另一回事。

之前我也见过不少评测报告，要么是拿 LeetCode 原题跑一遍然后说“通过率 90%”，要么是人工挑几个看起来高大上的场景让模型“自由发挥”，评分全靠肉眼感觉。这两种我都不太信。LeetCode 题偏向算法推导，对系统约束考察太少；自由发挥又缺少可复现的客观标准。我想要的是一组能同时考察正确性、并发安全、代码质量的题目，而且能自动判分。

于是我自己攒了这 35 道题。规则很简单：同一个 Prompt，同一个环境，三个模型各自生成代码，然后放进真实的 cargo 工程里编译、跑测试、跑并发压力测试。不靠主观印象，用分数说话。

1.2 三个测试对象的定位与定价

为了保护版本迭代过程中的商业信息，我这里不直接点名，用 A、B、C 代称。但你可以把 A 理解为网上热度最高的那个“旗舰推理型”，定价每百万 token 大约 15 美元；B 是定位均衡的中坚力量，大约 6 美元；C 是主打推理效率的性价比款，大约 2.5 美元。三者价格差正好接近 6 倍。

我给它们的画像也很明确：A 侧重复杂逻辑链推理，适合架构设计和长上下文理解；B 各方面比较稳，没有明显短板；C 在特定领域做了强化，据说是对系统编程和并发场景更友好。当然这些“据说”都不能当结论，所以我用题目说话。

我测的不是“哪个模型更大牌”，而是“哪个模型在真实任务里更值这个价”。接下来就是题目设计的核心思路。

2. 35道题是怎么设计出来的

题目设计是整个测试里最花心思的部分。我一开始想直接抓几个仓库里的真实 issue，后来发现不行——真实 issue 描述往往信息残缺，模型生成的东西没法统一评判。最后还是决定自己做一套带完整测试用例的题目集，既要贴近工程实际，又要保证判分可复现。

2.1 题目结构：算法题只占四分之一

35 道题分成四类：算法基础题 8 道、字符串与解析题 6 道、系统设计伪代码题 6 道、并发与锁专项题 10 道，最后 5 道是 Rust 专属的闭包、生命周期、trait 约束题。

这么分配是有讲究的。纯算法题每个模型都能拿高分，区分度很低；字符串处理更能看出模型对边界情况的敏感度；系统设计伪代码能考察架构思路；并发与锁是这次的重头戏，单独占了 10 道。Rust 专属题则是用来检验模型是否真的理解这门语言的核心约束，而不是只会套语法。

我刻意没有放任何“脑筋急转弯”类题目。那种题大模型容易靠训练数据记住答案，测不出真实生成能力。我要的是那种“看起来简单，落到代码里到处是坑”的题。比如实现一个线程安全的 LRU 缓存听起来很常规，但一旦要求读多写少、不允许用全局大锁、还要保证内存上限，很多模型就开始胡写。

2.2 评分标准：正确性之外更要看并发安全

判分维度我定成三个：正确性占 40 分，并发安全占 30 分，代码质量占 30 分。正确性不光是能跑通，还要通过我预先埋的断言和边界测试；并发安全重点看锁粒度、死锁可能性、原子操作使用是否合理；代码质量看可读性、错误处理、是否滥用 unsafe。

为什么并发安全单独占 30 分？因为这是大模型最容易翻车的地方。模型往往能写出“看起来对”的代码，但仔细一分析，锁的顺序完全错误，或者用一个 Mutex 包住整个高频读路径，导致并发性能直接崩塌。这些问题在单元测试里根本发现不了，必须放到并发压力测试下才会暴露。

我的打分方式很笨但很有效：每道题生成代码后，先跑 cargo test 的确定性测试，再跑我自己写的 stress test，每个模型跑 50 轮并发访问，统计通过率、耗时、耗时波动。三个维度综合下来，一道题满分 100，35 道题满分 3500。

3. 核心考点：Rust 并发锁为什么能拉开差距

说实话，最开始我只是把并发锁当作众多考点里的一项，没想到最后成了整个测试的分水岭。三个模型在算法题上的差距都在 5% 以内，但一到并发锁相关的 Rust 任务，分数能拉开 30 个百分点。这里面的原因值得好好拆一拆。

3.1 一道典型的“锁竞争”题长什么样

我拿一道中等难度的题举例，这道题几乎每个模型都栽过跟头。题目要求：实现一个带缓存的并发计数器，支持increment和get_cached_count两个方法。increment按 key 累加计数，get_cached_count返回当前总数，要求减少锁竞争，允许一定延迟。

看起来很简单对吧？但“减少锁竞争”这句话是关键。最简单的实现是给整个结构套一个大 Mutex，但这会让所有读操作互相阻塞。更好的方案是用RwLock保护 HashMap，用AtomicU64保存总数，这样get_cached_count根本不需要拿锁。

我把两个方案的核心代码都放出来，你感受一下差距。

第一种，大锁方案，也是模型 A 的典型输出：

use std::sync::{Arc, Mutex}; use std::collections::HashMap; struct Counter { data: Mutex<HashMap<String, u64>>, cached_total: Mutex<u64>, } impl Counter { fn increment(&self, key: &str, delta: u64) { let mut data = self.data.lock().unwrap(); *data.entry(key.to_string()).or_default() += delta; let mut total = self.cached_total.lock().unwrap(); *total = data.values().sum(); } fn get_cached_count(&self) -> u64 { let total = self.cached_total.lock().unwrap(); *total } }

这个代码能通过编译，逻辑上也是对的。但两个问题非常明显：第一，increment要拿到data锁之后再去取cached_total锁，存在潜在的锁顺序问题，如果哪天有人换一下加锁顺序，死锁立刻出现；第二，每次increment都重新计算所有 value 的总和，并发一高，锁持有时间直线上升。

第二种，细粒度方案，模型 C 一次通过：

use std::sync::{Arc, RwLock}; use std::sync::atomic::{AtomicU64, Ordering}; use std::collections::HashMap; struct Counter { data: RwLock<HashMap<String, u64>>, cached_total: AtomicU64, } impl Counter { fn increment(&self, key: &str, delta: u64) { let mut data = self.data.write().unwrap(); let entry = data.entry(key.to_string()).or_default(); *entry += delta; self.cached_total.fetch_add(delta, Ordering::Relaxed); } fn get_cached_count(&self) -> u64 { self.cached_total.load(Ordering::Relaxed) } }

这版代码用AtomicU64替代了第二把锁，get_cached_count完全无锁，写路径也只需要短暂持有data的写锁。两个方案一对比，高下立判。

3.2 三个模型的解题思路对比

同样的题目，三个模型的解题思路差异非常有意思。模型 A 的输出是典型“教科书保守派”：所有共享状态一律上锁，能用 Mutex 绝不用原子操作，代码正确但冗余，锁竞争严重。模型 B 是“中间派”：会尝试用RwLock，但对原子操作的使用比较犹豫，有时会在不需要锁的地方加锁，导致性能下降。

模型 C 则是“实战派”：它对 Rust 的std::sync::atomic模块明显更熟悉，擅长用原子操作配合细粒度锁来降低竞争。在 10 道并发专项题里，模型 C 有 7 道都用了无锁或原子变量方案，而且全部通过压力测试。模型 A 只有 2 道用了原子操作，其余全是 Mutex 包裹大对象。

这个表格只是并发专项题的统计，但已经能看出差距。模型 C 在并发安全得分上几乎是 A 的两倍，耗时只有 A 的四分之一。这还是在单机模拟环境下跑的，如果放到真实业务里，差距只会更大。

3.3 为什么最贵的会翻车

看到这个结果，很多人第一反应是“最贵的不应该最强吗”？我一开始也这么想，但翻了模型 A 的完整输出后发现，它的翻车不是偶然，而是三方面原因叠加的结果。

第一个原因是训练目标导致的保守策略。旗舰模型为了在各种场景下都不出错，倾向于生成更“通用”的代码——所有状态都加锁、所有错误都处理、所有边界都想清楚。这在复杂业务逻辑里是优点，但在性能敏感且明确要求并发的场景里就成了灾难。它宁可慢一点，也不愿意冒险用不熟悉的原子操作。

第二个原因是 Rust 所有权模型对“宽松生成策略”的惩罚。模型 A 在生成代码时经常忘记Arc的克隆时机、生命周期标注的省略规则、闭包捕获方式，导致编译错误频繁。它每次修复错误的方式又是同一个套路——加锁、加 clone、加'static。虽然最终能跑通，但代码充满了没有必要的性能开销。

第三个原因更本质：价格贵不等于任务匹配度好。模型 A 在长文档理解和复杂逻辑链推理上的确强，但我的并发锁题目恰恰是“局部高约束、全局低复杂度”的任务。这种任务不需要特别长的思维链，只需要对并发原语有精准理解。便宜但为系统编程优化过的模型在这种细分场景里反而更有优势。

4. 实操过程与现场记录

光说结论不给过程，那是耍流氓。这一章我把测试环境、执行方式、完整分数和两道分水岭题目的复盘都放出来，方便你复现或者改进。

4.1 测试环境与执行方式

测试环境是 WSL2 上的 Ubuntu 22.04，Rust 版本 1.78，cargo 版本 1.78，机器是 16 核 32G 内存。所有代码都放进一个独立的 cargo 工程里，每个题目一个模块，通过cargo test统一跑。

Prompt 模板我固定成一个结构：先描述需求，再给出函数签名，最后列出约束和边界条件。比如并发计数器那道题，我会明确写“get_cached_count 不允许加锁”“increment 需要尽可能减少锁持有时间”。这样能把模型的发挥空间限制在同一个框架内，避免有人靠微调措辞占便宜。

每个模型跑完所有题目后，我会在同样环境下再跑一遍压力测试。并发压力测试用的是tokio加rayon，模拟 64 个线程同时读写，每轮跑 1000 次操作，统计耗时的 P50、P95 和 P99。这个数据比单元测试更能反映真实效果。

4.2 35道题的最终得分与排名

总体结果比我预想的还要极端。模型 A 总分 2890，正确性不错，但在并发安全维度上丢分严重，尤其是死锁检测相关的题目，三题全部失败。模型 B 总分 3200，稳定发挥，但缺少让人眼前一亮的亮点。模型 C 总分 3375，不仅总分第一，而且在 Rust 专属题和并发专项题上都是单科第一。

编译失败次数这个指标容易被忽略，但实际影响很大。模型每次编译失败，不光浪费时间，还会导致后续生成质量下降——它会在修复错误的过程中不断引入新的不合理结构。模型 C 只失败过 2 次，且都是小错误；模型 A 失败了 11 次，其中 3 次陷入死锁修复的循环里出不来。

4.3 两道分水岭题目的完整复盘

第一道分水岭题目是“并发任务队列”，要求实现一个带优先级和取消功能的任务队列，支持多生产者多消费者。模型 A 生成的代码里，消费者线程在拿锁之后调用了可能阻塞的回调函数，导致锁被长时间占用。我的压力测试里设置了 100ms 心跳检测，模型 A 的代码在 32 线程并发下直接触发超时告警。模型 B 和模型 C 都正确处理了“不要在持锁状态下调用外部回调”这个高频考点。

第二道题更有代表性：实现一个无锁的线程安全栈，要求支持 push、pop、len。模型 A 直接放弃了无锁，用 Mutex 包住 Vec；模型 B 用Mutex<Node>实现了一个可用的链式栈，但 pop 和 len 均摊复杂度差；模型 C 使用AtomicPtr和 ABA 问题的经典解法，成功实现了一个真正的无锁栈。虽然模型 C 的代码在极端并发下还是有轻微的内存序问题，但它至少理解了无锁数据结构的设计意图。

这道题也解释了为什么模型 C 在 Rust 专属题上能拿高分：它不是背模板，而是真的理解了内存序、CAS 操作、指针管理的细节。这个东西不是说贵就一定会，而是取决于模型的训练数据里有多少高质量的系统编程内容。

5. 常见问题与选型避坑指南

测试做完了，分数也出来了，但我更想分享的是测试过程中踩到的坑和选型时的一些思考。这些经验比具体分数更有复用价值。

5.1 这次测试踩到的三个坑

第一个坑是“不要只看编译通过”。模型 A 很多代码都能编译通过，测试也能过，但一旦上压力测试就原型毕露。我用valgrind和perf做进一步分析，发现大量时间花在锁等待上。如果当初只看通过率，模型 A 的分数会好看很多，但实际工程价值很低。

第二个坑是“并发问题具有偶发性”。同样是死锁，模型 A 的代码在小规模测试下完全没有问题，只有跑到 64 线程才会出现。这种偶发性问题靠肉眼 review 很难发现，必须用固定 seed、固定压测时间、多次重复跑的方式来提高检出概率。我最终采用了每次跑 50 轮、每轮随机延时的方式，才稳定复现了问题。

第三个坑是“单次测试结果可能被上下文污染”。同一道题，模型 B 在一次测试中先生了错误方案，后续所有修复都基于错误方案打补丁，越改越烂；但换个会话从零开始生成，写出的代码又很好。这说明大模型生成质量有随机性。所以我要求每个模型对每道题都独立生成三次，取最好的结果，避免一次坏运气拉低整体分数。

5.2 给团队选型的三条建议

基于这次测试，我给团队选型定了三条原则。第一条，不要按价格排序，要按任务类型分流。复杂的架构设计、长文档理解、跨文件重构交给旗舰模型 A；常规业务代码和中等难度任务用均衡模型 B；涉及并发、性能调优、系统编程的细节任务直接上性价比模型 C。混着用，综合成本能降 50% 以上。

第二条，把并发专项题做成回归测试集。选型不是一锤子买卖，模型隔三差五更新版号，能力会变。我把这次 35 道题，特别是那 10 道并发题，固化成了一个自动化测试仓库，以后任何新模型进来先跑这套题，分数不达标直接不考虑。

第三条，关注“编译失败次数”和“压力测试 P99”这两个指标，而不是只看通过率。编译失败说明模型对局部约束理解不足，压力测试 P99 说明它在真实负载下的表现。这两个指标比总分更能预测模型进入生产环境后的实际表现。

6. 一点经验之谈

测试做到最后，我自己的感受其实挺复杂。最贵的模型在特定局部任务上输给便宜 6 倍的对手，并不是因为它差，而是因为任务特点与它的训练优势不匹配。大模型的强项和弱项远比大多数人想象的更不均匀，这种不均匀在算法题上几乎看不出来，但一进入 Rust 并发锁这类高约束场景就格外刺眼。

我个人后来在项目里采用了一种混合路由策略：把任务按复杂度、并发度、上下文长度三个维度打标，再决定交给哪个模型。这套思路不一定适合所有团队，但至少想清楚了一个问题——大模型选型，本质上是在为任务的分布建模，而不是在挑一个“最强的大脑”。

如果看完这篇你也想跑一套自己的评测，我建议先从并发锁相关的 10 道题开始。那是最能看出差距、也最能帮你省钱的部分。记住一个原则：能跑通只是及格线，能在 64 线程压力下稳如老狗，才叫真正能上生产。