Hy4 preview、GLM-5.3 和 Kimi K3：如何做一次公平的模型对比

腾讯混元在 Hy4 preview 发布稿中披露，163 名内部专家完成了 203 个工程任务的盲测：Hy4 preview 平均 2.99/4.00，GLM-5.3 为 2.92，Kimi K3 为 2.94。这个结果值得关注，但它更适合当作比较的起点，而不是一句“Hy4 赢了”的结论。

先说结论

腾讯内部盲测是方向性证据，不是独立的普遍排名。

对比前要冻结提示词、工具、模型版本、预算和评分规则。

除最终文本外，还要评估工具轨迹、失败恢复、延迟和成功工作流成本。

最终选型应依据团队真正运行的任务结构和失败特征。

为什么单个分数不够

模型对比至少受到任务类型、提示词、工具、上下文、采样设置和评分标准影响。一个模型可能更擅长前端交互，另一个更擅长代码修复；把所有任务压成一个平均分，会隐藏真正影响选型的差异。

更稳妥的报告方式是同时展示胜、平、负比例，按任务类别拆分，并保留失败案例。腾讯披露 Hy4 preview 相对 GLM-5.3 的胜率为 46.8%、平局 12.8%、负 40.4%；相对 Kimi K3 的胜率为 51.2%、平局 7.9%、负 40.9%。这些数字说明优势存在，但并不压倒性。

一套可复现的比较方案

准备同一份任务集，至少包含跨文件代码修复、前端视觉改动、结构化数据分析和工具调用。冻结模型版本、系统提示、token 预算和工具权限；每个任务用相同的验收标准评分。对于 Agent 任务，不只看最终文本，还要看工具调用是否正确、是否产生不必要副作用，以及失败后能否恢复。

成本也要一起比较。记录输入、输出、缓存、重试、人工介入和总耗时，计算“成功交付一个工作流”的成本，而不是只比较每百万 token 的价格。通过 SandBase 等网关时，可以统一保存 provider、模型、request ID 和最终状态，但前提是模型已在实时目录中确认可用。

如何理解 Hy4 preview 的定位

Hy4 preview 的特点是大规模 MoE、超过 1M 上下文，以及对代码、办公、游戏和科学任务的生产力定位。它适合被放进长程工作流里测试，而不是只做单轮问答排行榜。

腾讯同时说明 Hy4 preview 仍是早期版本，复杂任务可能过度思考和过度自我验证。因此，对比时应把稳定性、延迟和失败恢复列为一等指标。

让比较经得起复核

先把“能力”和“偏好”分开。能力是模型是否在约束内完成任务，偏好是评审者更愿意采用哪个结果。为每次运行记录成功标记、失败原因和最终产物：代码任务应有通过测试的补丁，办公任务应有可追溯的表格，工具任务应有最终状态和执行轨迹。这样可以避免用流畅的解释掩盖错误的文件修改。

任务矩阵至少应覆盖多文件修复、前端交互、结构化分析、工具规划和长上下文检索。固定模型版本、系统提示、工具、预算和重试策略，并把提示词放进版本库。模型如果主动请求澄清，应记录为交互成本，而不是自动判定失败；安全提问有时比不可逆猜测更好。

测量完整工作流

记录首 token 延迟、总耗时、输入输出 token、缓存命中、工具调用、重试、人工介入和验收结果，再计算“成功工作流成本”。这样才能看出低 token 单价是否被额外重试和人工修复抵消。腾讯公布的 2.99、2.92 和 2.94 分应作为后续测试的先验，而不是公共排行榜结论。

当前判断

目前最准确的说法不是“Hy4 preview 全面超过 GLM-5.3 或 Kimi K3”，而是：在腾讯披露的内部工程任务集上，Hy4 preview 平均得分略高。开发者应使用相同任务、相同工具和可审计日志复测，再根据自己的工作流决定模型选择。

把分数变成选型决定

完成第一轮任务矩阵后，不要把所有结果平均成一个“冠军”。先为最重要的工作设最低门槛：代码补丁必须通过测试，财务抽取必须逐项引用，工具工作流必须把工作区留在已知状态。然后按任务类别展示取舍。这样团队可以在长上下文修复中选择 Hy4，同时保留另一个模型处理更窄、更快的交互。

如果 provider 正在快速迭代 preview，最好隔一段时间重复一次。记录完整模型标识、endpoint、区域、系统提示、采样参数和 SDK 提交。六周后无法复现的结果仍可作为带日期的观察，但不应描述成稳定能力。模型、提示词、工具 schema 或评测器发生变化时，保留变更日志，方便判断回归原因。

最终报告应包含任务样例、简洁结果表、代表性的成功与失败、成功工作流成本，以及带有“不要用于什么”的明确建议。发布前让第二位评审者查看原始轨迹，把运行测试和解释结果分开。