一个模型的隐藏推理轨迹里,英语突然写得七拐八绕,连语法都不管了——这是软件研究者 Simon Willison 测试腾讯新模型 Hy4 Preview 时留下的细节。他用自己那套经典的"画一只骑自行车的鹈鹕"提示词试了一下,拿到的推理文本里全是"It could improve riding theme, but may obscure head"这种半通不通的句子。原因大概不复杂:反正没人看这段草稿,语法通不通不重要,省 token 才重要。
这句别扭的英文只是表象。真正值得拆开看的,是 Hy4 规格表背后那套更大的故事:参数量比上一代跳了 2.6 倍,上下文窗口翻了 4 倍,但腾讯自己晒出的胜率图、发布两天内攒出来的"太慢"抱怨、以及从 1.56TB 权重到真的能跑起来所需要的硬件门槛,合在一起,才是这次"开放权重"的全貌。
参数跃升的账本
Hy4 Preview 总参数 770B,激活参数 49B,上下文窗口 1M token,Hugging Face 仓库 1.56TB。对比 7 月发布的 Hy3(295B 总参 / 21B 激活 / 256K 上下文 / 598GB),这是一次实打实的跳级。
支撑这个跳级的不只是堆参数。Hy4 用 Gated DeepSeek Sparse Attention 配合跨层索引复用(IndexCache)去压百万 token 的注意力算力开销,256 个路由专家里每次只点亮 top-8,再加上原生的多 token 预测层做投机解码——这套组合是应对"上下文变长、算力不能同步变贵"的正经工程活。
胜率图是怎么画出来的
腾讯给出的内部测评显示 Hy4 相比 Hy3 有断层式提升:DeepSWE 从 28.0 跳到 64.3,SWE Atlas Codebase Q&A 从 30.8 跳到 64.0。官方基准还包括 Terminal-Bench 2.1(85.4)、SWE-bench Multilingual(82.9)、GPQA Diamond(92.3)、Humanity's Last Exam 文本版(43.4)。
这些数字要打个折扣看。基准是以图片形式发布,不是可复现的文本报告;官方在内部盲测里把 Hy4 拿来和 Kimi K3、GLM 5.3 对比,而不是和 Hy3 同期的 Kimi K2 比——代际错位,胜率就没那么干净。检索到的横向数据也显示,Qwen3.8 Max 和 Kimi K3 在 DeepSWE、ProgramBench、HLE 文本版等子项上仍能反超 Hy4。旗舰这个词,腾讯自己贴的标签比外部验证跑得快。
- 风险.自测基准图片化、对比对象代际错位,读者拿这套数字当独立排行榜成绩会失真。
鹅骑车推理里藏着的因果链
chat template 里定义的 reasoning_effort 只有两档:high(默认)和 no_think(关闭推理)。OpenRouter 的模型元数据却多出一档"low",这只是平台层面的抽象包装,不是模型原生支持——想省钱调低档位的开发者,得先分清自己在跟哪一层 API 打交道。
开源开的是协议,不是门槛。
Simon 观察到的那段磨磨蹭蹭的推理轨迹——纠结要不要给鹅加头盔、要不要加墨镜——不是孤立的趣味细节。腾讯自己在模型卡里承认 Hy4 存在"困难任务上耗时过长"和"过度自我验证"的问题,发布两天内,社区里已经有人直接吐槽响应"太慢"。一段啰嗦的草稿、一句官方自认的缺陷、一批用户的实际抱怨,三件事对上了。
开放权重的价格
Apache 2.0 协议听起来很友好,但 1.56TB 的 BF16 权重不是随便一台机器能加载的。FP8 版本能省一些,量化到 GGUF 的 Q4_K_M 版本也要 435GB 左右,更激进的混合低比特版本能压到约 214GB,在 8 张 H20 上跑满载,解码速度也只有大约 19.5 token/s。
本地部署的坑更具体:主线 llama.cpp 目前还不支持 Hy4 的架构,得靠定制补丁,而这个补丁目前没有 ROCm/AMD 支持;通过 NFS 挂载模型会因为随机访问速度太慢(约 12MB/s)而卡住,得换本地 NVMe。
- 结论.规格表上的"开放",到工程落地那一步,门槛比协议文本暗示的高得多。
一段没人会读的英文草稿,一张自己画的胜率图,一份还没打完的补丁——这三样东西凑在一起,才是 Hy4 这次发布真正的样子。规格跃升是真的,旗舰称号是自封的,能不能落地,还得看接下来 llama.cpp 主线支不支持、独立评测什么时候出现。