同一段消息队列文档发给 13 个模型做 API文档翻译，头名和末名的均分差了 0.98——更扎眼的是末名 Claude-Sonnet-5 的全部输出只有两个字：「在的」。这次模型实测不止看排名，更有意思的是各维度的分差形状：术语维度挤成一列，格式维度却拉开了 0.62。下面把打分表、翻车原文和整套评测脚本的实现都摊开讲。

复现口径：数据采集于 2026 年 7 月，运行环境为 Python 3.11 + openai SDK 1.x（仅用到 OpenAI 类与并发调度，另以 json、os 标准库落盘）。裁判模型为 gpt-5.6-sol，非参赛款，七个维度各打 0-1 分。所有分数对应采集当天的线上版本，厂商静默更新权重后结果会漂，复现时以你自己的采集时间为准。

这次测了什么：Driftline 死信队列文档翻译考题

任务给模型的角色设定是一位熟悉分布式系统与消息队列的本地化工程译者，目标是把「涧流 Driftline」消息队列产品的英文开发文档节选译成简体中文，供官方中文文档使用。原文覆盖重试与死信行为：ack_deadline_seconds 语义、至少一次投递与幂等要求、max_delivery_attempts 超限后的路由、message.dropped 事件监控、以及 driftline.replay() 重放行为。

三层约束叠在一起

• 术语以 2026 年 6 月版术语表为准绳：topic→主题、consumer group→消费者组、dead-letter queue→死信队列、at-least-once delivery→至少一次投递等。
• 代码与标识符零改动：ack_deadline_seconds、driftline.replay(topic, since=timestamp)、message.dropped 这类内容必须原样保留。
• 题目附了一份社区旧译，里面埋了已废弃术语和误译，属于干扰材料，模型需要甄别而不是照抄。

难点就在这。术语表是权威的，旧译是坑。模型如果习惯「参考上下文里已有的译文」，很容易把废弃术语捡回来。这是 API文档翻译里最常见的雷区之一。

13 款模型七维总分排名

先看全量结果。七维分别是 accuracy（准确性）、completeness（完整性）、fluency（流畅度）、格式、judgment（判断力）、register（语域）、terminology（术语），裁判为 gpt-5.6-sol：

排名	模型	accuracy	completeness	fluency	格式	judgment	register	terminology	均分
1	GPT-6-Sol	0.98	1.00	0.96	1.00	0.99	0.99	1.00	0.99
2	Kimi K3	0.98	1.00	0.94	0.99	0.99	0.98	1.00	0.98
3	DeepSeek-V4-Pro	0.97	1.00	0.94	1.00	0.99	0.98	1.00	0.98
4	Kimi-K2.6	0.97	0.99	0.93	0.99	0.98	0.97	1.00	0.98
5	Qwen3.6-Plus	0.96	0.99	0.93	0.98	0.98	0.96	1.00	0.97
6	GLM-5.2	0.96	0.99	0.89	0.99	0.96	0.97	0.99	0.96
7	GLM-5.3-Flash	0.94	0.99	0.89	0.96	0.97	0.95	0.99	0.96
8	GLM-5.3	0.88	0.99	0.94	0.91	0.95	0.97	0.99	0.95
9	Qwen3.5-Flash	0.93	0.96	0.88	0.97	0.97	0.92	0.99	0.95
10	Gemini-3.7-Flash	0.87	0.99	0.95	0.92	0.88	0.96	0.99	0.94
11	MiniMax-M2.7	0.82	0.97	0.84	0.58	0.84	0.72	0.96	0.82
12	MiniMax-M3	0.62	0.88	0.84	0.38	0.48	0.78	0.97	0.71
13	Claude-Sonnet-5	0.00	0.00	0.05	0.00	0.00	0.00	0.00	0.01

头部咬得很紧：GPT-6-Sol 到 Qwen3.6-Plus 五款模型均分只差 0.02，但耗时从 10.69s 到 134.15s 不等。尾部断崖明显，MiniMax-M2.7 掉到 0.82，M3 掉到 0.71，Claude-Sonnet-5 直接归零。中段的 Gemini-3.7-Flash 用时 14.14s，速度接近头部，但 accuracy 0.87 和 judgment 0.88 拖了后腿。

评测流水线：并发调用、断点续跑与七维打分

整套模型实测脚本的核心是三段式：并发调用参赛模型、落盘缓存、裁判打分。代码用 openai SDK 直连，base_url 指向网关的 OpenAI 兼容端点，密钥从环境变量取：

import os, json, time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SILVAMUX_API_KEY"],
    base_url="https://www.silvamux.com/api/v1",
)

MODELS = ["deepseek-v4-pro", "kimi-k3", "glm-5.3", "minimax-m3", "qwen3.6-plus"]

def run_one(model: str, prompt: str, out_dir: str = "outputs"):
    path = os.path.join(out_dir, f"{model}.json")
    if os.path.exists(path):          # 断点续跑：已有输出直接跳过
        return json.load(open(path, encoding="utf-8"))
    for attempt in range(3):          # 500/502 按官方建议间隔重试
        try:
            t0 = time.time()
            resp = client.chat.completions.create(
                model=model, messages=[{"role": "user", "content": prompt}],
                temperature=0.2,
            )
            result = {"text": resp.choices[0].message.content,
                      "elapsed": round(time.time() - t0, 2)}
            json.dump(result, open(path, "w", encoding="utf-8"),
                      ensure_ascii=False, indent=2)
            return result
        except Exception as e:
            if attempt == 2:
                raise
            time.sleep(2 ** attempt)

几点说明。缓存按模型名分文件存 JSON，跑挂了重跑不会重复扣量——注意如果你改了提示词，务必换输出目录或清缓存，否则旧译文会污染新一轮打分。重试只兜 500/502 这类可重试错误，遇到 400 应该改参数而不是硬撞。响应头里的 X-Request-Id（形如 REQ-xxxx）建议一并落盘，排错时能直接定位到具体请求。

打分阶段把译文连同原文、术语表一起发给裁判模型，让它按七维各回一个 0-1 的小数，最后聚合出均分排名。整条链路长这样：

注意 D 这个分支：本次没有对译文做任何清洗，<think> 标签原样交给裁判——这正是 MiniMax 两款的格式分失真来源，后面细说。

翻车现场：0.38 的格式分与两个字的全军覆没

MiniMax-M3：思考链直接外泄进正文

MiniMax-M3 的格式分只有 0.38，judgment 也只有 0.48。原因看输出第一行就明白——它把推理过程原样吐在了译文前面：

<think>The user wants me to translate a developer documentation excerpt for “Driftline” message queue product into Simplified Chinese for official Chi…（后文省略）

这不是翻译错误，是输出窗口污染。中文官方文档的读者打开页面先看到一段英文思考过程，格式分和 register 分（0.78）一起被拉垮。MiniMax-M2.7 同样外泄了 <think> 标签，格式分 0.58、register 0.72，但它的思考内容是中文且正确复述了术语表，失分轻一些：

<think> 用户要求我翻译一段关于 Driftline 消息队列的开发者文档，需要注意：1. 术语表（2026年6月版，权威）：topic → 主题…（后文省略）

有意思的是，M3 的 terminology 拿了 0.97——思考链里明明把术语都想对了，外泄这一下把其他维度的账全砸了。

Claude-Sonnet-5：全部输出是「在的」

末名的答卷堪称行为艺术。完整输出如下：

在的

裁判对它 fluency 0.05 的理由原文是：「‘在的’虽是自然口语，但孤立且与开发者文档内容无关，无法构成可读译文」。terminology 0.00 则是「未使用’主题’‘消费者组’‘至少一次投递’‘死信队列’‘确认’‘重新投递’‘重放’'幂等’等任何权威术语」。耗时 11.3s，说明模型确实跑了，只是没干活。这种输出更像是请求链路上的异常而非模型翻译能力，单看这一次样本不能下能力结论。

高分范本：GPT-6-Sol 的 0.99 长什么样

头名的 completeness 拿到 1.00，裁判理由是「标题、四段正文以及确认丢失导致重复投递、未配置死信队列时确定丢弃、生产监控和重放属性等信息均无遗漏，并按要求附全术语清单」。看它的正文开头：

当消费者未能在 ack_deadline_seconds 内确认消息时，Driftline 会将该消息重新投递给同一消费者组。投递语义为至少一次投递：消息处理程序必须具有幂等性，因为即使确认已成功发出，只要确认信息在传输途中丢失，仍可能发生重新投递。

术语全部踩中，代码标识符零改动，警告段的「不得将其设为低于 10 秒」也保住了警示语气。它还在文末附了术语对照清单，从 topic 到 at-least-once delivery 逐条列出。唯一的失分点在 fluency 0.96：裁判认为「投递语义为至少一次投递」稍显重复，更自然的写法是「采用至少一次投递语义」。对照第二名 Kimi K3 的「投递采用至少一次投递语义」，高下确实就在这几个字的衔接上。

机理：术语分为什么挤成一列，格式分却拉开 0.62

术语表的「喂到嘴边」效应

看 terminology 这一列：前五名全是 1.00，中段六款 0.99，最差的 MiniMax-M3 也有 0.97，唯一的 0.00 是啥都没译的 Claude-Sonnet-5。这列几乎没有区分度。原因不复杂——术语表就在提示词里，模型只需做「查表替换」，不需要任何领域推断。凡是认真生成译文的模型都能抄对，连思考链外泄的 M3 都抄对了。反过来说，terminology 这一项对选型几乎没有参考价值，真正拉开差距的是需要判断力的维度。

判断与格式的分差来自推理链管理

judgment 从 0.99 一路掉到 0.48，format 从 1.00 掉到 0.38，两条断层都出现在 MiniMax 两款上。更可能的解释是：这两款模型的推理链没有被正确路由到独立的思考通道，而是直接写进了输出窗口。思考链本身质量不差（M3 的术语复述是对的），但它的存在破坏了交付格式，还可能挤占输出长度预算——M3 的 completeness 0.88 低于全场平均，与输出前半段被英文思考占据的观察吻合。这是推断，不是数据包里直接给出的结论，但与各维度分数的形状对得上。头部模型则把推理收敛在内部通道，输出窗口干干净净只剩译文。

边界：这次 0.99 与 0.01 之外还没测什么

采样与裁判的单一性

每个模型只跑了一次，temperature 固定 0.2，没有做多样本重复。Claude-Sonnet-5 的「在的」尤其需要多跑几次才能判断是稳定性问题还是偶发故障。补洞做法：每个模型采样 3-5 次，看分数方差而不只看均值。裁判也只有 gpt-5.6-sol 一位，裁判模型也有自己的偏好（比如对「投递语义为」这类重复表述的容忍度），换一个裁判排名可能微调。补洞做法：加一位异构裁判，取双裁判一致率。

任务外推与分数时效

这是单一任务：一段消息队列文档的中译。翻译能力强不等于写代码、摘要、长文的能力强，单任务结论不能外推成能力结论。补洞做法：换三个不同领域的文档（前端 API、数据库、支付协议）各测一轮再下判断。另外，所有分数只对应采集当天的线上版本，MiniMax 的 <think> 外泄完全可能在一次更新后消失，复测才有意义。还有一点：七维等权求均分，掩盖了维度重要性差异——生产场景里格式和 terminology 的权重通常高于 fluency，等分排名会把 MiniMax-M2.7 压得比实际可用性更低。补洞做法：按自己的场景自定义权重再聚合。

选型建议：按分数结构挑，不按均分挑

• 译文要直接进生产文档：GPT-6-Sol、DeepSeek-V4-Pro，completeness 1.00、格式 1.00，拿来即用。GPT-6-Sol 快一个量级（10.69s vs 163.9s）。
• 对延迟敏感的批量翻译：Qwen3.6-Plus（79.56s、均分 0.97）和 GLM-5.2（16.59s、均分 0.96）性价比结构更好。
• MiniMax 两款在格式分修复前慎用于直接交付，但如果你的下游有清洗 <think> 标签的管道，terminology 0.96/0.97 说明译文本体是能用的。
• Gemini-3.7-Flash 速度不错，但 accuracy 0.87 意味着细节语义有丢，做草稿可以，终稿要人审。

常见问题

Q1：MiniMax-M3 的 terminology 0.97 那么高，为什么均分只有 0.71？

因为七维等权，格式 0.38 和 judgment 0.48 把均分拖垮了。失分源头是 <think> 推理链外泄到输出窗口，译文本体的术语反而全对。如果你的管道能剥掉思考链标签，它的实际可用性比 0.71 显示的要好。

Q2：断点续跑的 outputs 缓存，要不要按提示词版本分目录？

要。本次脚本用模型名做缓存键，如果你修改了 Driftline 术语表或调整了角色设定，旧缓存会被误当成新结果直接跳过调用，打分就成了旧译文的分数。建议在 out_dir 里带上提示词版本号，比如 outputs_v2/。

Q3：为什么干扰材料（社区旧译）没能拉开 accuracy 的差距？

从分数看，前七名的 accuracy 都在 0.94 以上，说明主流模型都能识别术语表的权威性并忽略旧译里的误译。真正被干扰拉开的是 judgment 一列（0.99 到 0.48），这个维度考察的警示语义处理和格式取舍，比单纯的术语甄别更能分出高下。

如果你打算复现这轮 API文档翻译模型实测，模型调用名（如 deepseek-v4-pro、kimi-k3、minimax-m3）以网关模型广场详情页为准，别按展示名自行拼接；接口参数与错误码说明见开发者文档，出错时拿响应里的 X-Request-Id 去查最快。本次示例代码在千木SilvaMux的 OpenAI 兼容端点上验证通过，裁判与参赛模型均通过该端点调用。