Hy3 把价格写进了评测

腾讯混元发布的 Hy3 文章把 Hy3 定位为 Hy3 preview 的后续版本，称团队收集了超过 50 款产品的反馈，扩大了后训练规模，并在推理、Agent 能力和长上下文方面做了改进。我的判断是，这次发布真正想说的不是又刷了一个榜单，而是一个更便宜的开源模型，能不能便宜到足以塞进日常 Agent 工作流里。

这个区分很关键。一个模型在发布文章里可以很好看，可一旦要调用工具、维持上下文、保持输出格式，或者在混乱的编码和文档流程里跑起来，就可能立刻露馅。Hy3 最站得住的说法不是"它打败了所有前沿模型"，而是腾讯可能找到了一个成本和可靠性的平衡点——在这个平衡点上，不少团队更愿意把更多任务交给一个活跃参数更小的模型，而不是每一步都留给最贵的那个。

答案快照

问题	我的判断
发生了什么？	腾讯发布了 Hy3，同步上架 OpenRouter、GitHub、Hugging Face、ModelScope 和 AtomGit，定位为 Hy3 preview 之后更强的 Agent 和生产力模型。
为什么重要	这次发布把开源权重、256K 上下文、低 API 价格和 OpenRouter 免费路由打包在一起，真正的问题变成了每一块钱能换来多少有效产出。
如果好用，谁受益？	在做编码 Agent、文档工作流、办公自动化、研究助手，以及需要更便宜初筛或辅助模型容量的路由系统的团队。
我的核心观点	Hy3 应该按路由后的工作流可靠性来评判，而不是只看腾讯的基准截图。
需要留意的地方	多数具体成绩来自腾讯内部或平台方，外部实测更关心的是：输出质量是否真的对得起这个价格。

价格改变了提问方式

原文提到 Hy3 以 Apache 2.0 协议开源，API 定价为每百万输入 Token 1 元、每百万输出 Token 4 元、每百万缓存输入 Token 0.25 元。OpenRouter 的腾讯页面还列出了 Hy3 和 Hy3 free 两条路由，其中免费版本标注将于 2026 年 7 月 21 日下线。这是我最想先验证的部分——便宜的推理成本只有在团队真的改变任务分配方式时，才会真正发挥作用。

模型贵的时候，团队倾向于省着用；模型足够便宜时，就可以拿来做初稿、重试、分类、抽取、格式修复，以及后台 Agent 步骤。这不代表质量可以妥协，而是让质量更容易被衡量——因为可以用多得多的真实任务去试。

这也是为什么我不把 Hy3 看作"腾讯对抗前沿实验室"的故事。我更愿意把它理解成一个路由的故事。如果 Hy3 能以低成本处理足够多的常规 Agent 步骤，它不需要成为整个技术栈里最强的模型，只需要足够可靠，让昂贵模型不再是每一个中间步骤的默认选项。

开源是真的，但分量不轻

GitHub README 和 Hugging Face 模型卡显示，Hy3 是一个 295B 参数的混合专家模型，活跃参数 21B，MTP 层参数 3.8B，192 个专家、每次激活 8 个，BF16 权重，上下文长度 256K。README 还展示了通过 vLLM 或 SGLang 部署后的 OpenAI 兼容调用，以及 reasoning_effort 选项，可在 direct、low、high 三种推理模式之间切换。

这让开源权重的信号更有分量，但也让我不至于把它当成可以随便本地跑的软件。Simon Willison 指出，完整模型在 Hugging Face 上占 598GB，FP8 量化版本也要 300GB。对大多数开发者来说，现实路径不是"下载下来随便跑"，而是托管推理、托管端点，或者一套认真的自部署方案。

所以开源更大的意义在生态层面：它给了社区一份模型卡、一份许可证、一套部署方案，以及多个分发渠道。但日常采用与否，还是要看服务成本、延迟、路由、评测，以及当提示词不再像演示那么规整时，工具调用行为是否还稳得住。

腾讯卖的是可靠性，不只是分数

原文的措辞刻意往产品体验方向靠。腾讯称组织了 270 位专家用真实工作任务做盲评，Hy3 拿到 4 分中的 2.67 分，GLM-5.1 为 2.51 分，优势最明显的是前端开发、数据与存储、CI/CD 任务。文中还提到内部幻觉率从 12.5% 降到 5.4%，常识错误率从 25.4% 降到 12.7%，多轮问题率从 17.4% 降到 7.9%。

这些恰好是我最在意的 Agent 能力：工具调用、输出格式、事实依据、上下文保持、多轮意图追踪。一个模型就算文字写得漂亮，只要破坏格式、丢掉约束、编造缺失细节，Token 再便宜也是贵的。

但这也是我会对发布话术打折扣的地方。内部产品反馈和内部评测是有参考价值的信号，不是独立证明。腾讯自己的文章里附了 WorkBuddy、元宝、ima、Marvis、QQ 浏览器、腾讯文档的产品团队案例。这些案例值得读，因为它们透露了腾讯关心的工作负载类型。但我不会把它们当成"用自己的失败场景去跑一遍模型"的替代品。

外部信号仍然褒贬不一

我找到的外部反馈之所以有用，恰恰因为它不是一片叫好。Willison 的关注点落在 Apache 2.0 许可证、模型体积、256K 上下文，以及限时免费的 OpenRouter 路由上。一个关于 Hy3 preview 的 Reddit 帖子里，用户对速度和 Agent 编码能力感到兴奋，同时也在追问免费期能持续多久。这是典型的早期采用者行为：大家先试不花钱的那条路。

更有力的质疑来自 Max Woolf 对 Hy3 preview 在 OpenRouter 上的五月分析。他认为这个预览版模型走红，并不像是发现了什么质量奇迹，更像是低价、OpenRouter 平台效应和难以解释的真实使用量共同作用的结果。一份更偏实测的批评指出，Hy3 在初稿和结构化工作流上有用，但在多项交互式构建测试中，GLM-5.2 的手感更顺。

我觉得这种批评在某个具体层面上是成立的。实际问题不是 Hy3 能不能产出东西——大多数能力足够的模型都能。问题是它产出的东西需要多少返工，这些返工是否抵消了省下的钱。便宜的粗糙初稿有价值，便宜的残破初稿只是把审查成本藏起来了。

基准跑不到终点

GIGAZINE 的报道概括了标题层面的对比：Hy3 对标 GLM-5.2、DeepSeek-V4-Pro 这类更大的开源模型，腾讯自己的图表声称尽管活跃参数更少，性能仍有竞争力。我能理解为什么这是标题——模型发布需要一个计分板。

对我来说，更有意义的计分卡是运营层面的：Hy3 在多长的任务链里能保持工具调用格式不出错？命令失败后它恢复得怎么样？low 和 high 推理模式是不是真的在对应的任务上有效？256K 上下文窗口在大型代码仓库和长文档里帮得上忙，还是只是给过时信息多提供了一个藏身之处？审阅者接受初稿的频率有多高？

这些问题不够亮眼，但它们决定了 Hy3 是变成技术栈里真正干活的成员，还是又一个在免费窗口期被试了一轮、热度过去就被遗忘的模型。

我的结论

Hy3 值得关注，因为它在尝试把开源权重的 Agent 能力做到足够便宜，从而真正路由进生产工作流。这比"这张图上这个模型打赢了那个模型"的说法更站得住。如果模型足够可靠，低价会改变架构设计：更多重试、更多后台检查、更多初稿自动化，以及更有选择性的升级。

但我不会在没有自己任务的实际结果之前，就接受基准故事。腾讯在论证 Hy3 在 Agent 工作里最棘手的环节——事实依据、上下文追踪、工具调用、输出格式——上有所改进，这个论证是说得通的。它对某个团队真正成立的方式，只有一种：拿自己的工作负载去做评测，统计修改次数、重试次数、延迟、接受率和审阅时间。

所以我的态度是谨慎地感兴趣。Hy3 不需要成为所有人的最强模型，它需要让便宜这条路变得可信。如果做到了，最重要的 Hy3 基准不会是一个静态分数，而是某个时刻——路由系统默认把那些无聊但必须做的活交给 Hy3，而没人觉得需要逐个盯结果。