用 Hy4 preview 维护老博客的几天试用记录
作者是 发布于 在 LLM.

腾讯混元在 2026 年 8 月 28 日发布了 Hy4 preview，WorkBuddy、CodeBuddy、元宝、ima 同步上线，限时免费约两周。WorkBuddy 侧给出的截止时间是 9 月 10 日 23:59，CodeBuddy 的官方口径只说"两周"，以客户端实际显示为准。免费期内每天有额度上限，触顶后消耗积分，繁忙时需要排队。

发布当天的报道集中在一组跑分上：12 项 benchmark，Terminal Bench 2.1 得 85.4，DeepSWE 从上一代的 28.0 涨到 64.3。需要说明的是，这些分数目前都出自腾讯官方自述——发布首日 Artificial Analysis 尚未收录，Hugging Face Open LLM Leaderboard 没有数据，第三方媒体基本是通稿转载，还没有看到独立的社区实测。

我自己更关心的是它在日常场景里的表现，所以把它拉到一个我维护了十余年的个人博客上试了几天。这篇记录一下过程和结果。

先说它是什么

能确认的基础信息如下：

项目Hy4 previewHy3（上一代）
架构MoEMoE（快慢思考融合）
总参数 / 激活参数770B / 49B295B / 21B
上下文长度1M tokens256K
开源协议Apache 2.0开源
多模态暂不具备暂不具备

官方口径的 770B 指 backbone，Hugging Face 文件页显示的 780B 是算上了内置的 MTP 投机解码层（10B 总参、0.7B 激活）。架构上共 78 层，第 1 层是 dense FFN，其余 77 层为 MoE，每层 256 路由专家加 1 共享专家，每 token 激活 top-8 路由加 1 共享专家。

官方的定性是"稳居开源模型第一梯队"，同时说明这是早期版本，预训练和后训练都还有提升空间。

还有一个信息：Hy4 preview 参与了自身的研发过程，包括训练方法、数据策略、评估体系和底层算子优化，由它自己提方案、跑实验、看结果再迭代。其中推理系统优化部分，官方给出的数字是端到端吞吐相较基线提升 31.8%，decode 侧增益在 44% 到 69% 之间。

测试环境

测试对象是我自己维护了十多年的个人技术博客。

这类老站的特点是历史包袱比技术难度更花时间。早年的代码现在看有不少不合理的地方，但运行正常就不敢乱动；改动一处可能牵出连锁反应；遇到问题去搜，答案未必对得上自己的场景，得自己换算回来。

拿它做测试的好处是：没有标准答案，也不能从零设计，必须理解既有代码的上下文、在约束条件下做改动。

一、改一个布局 bug

第一个任务是修侧边栏的显示问题：某个链接列表区域在窗口收窄时，下方会多出一个类似方格的空白单元格。

我只描述了现象，没给代码。它的排查顺序是：

  1. 判断这类空白格通常来自浮动布局下元素高度不一致导致的边框残留
  2. 定位到对应的 CSS 规则，指出 float 加固定百分比宽度的组合在文字换行时会出问题
  3. 给出改用 flex 的改法，并顺带处理了相邻边框叠加

改动如下：

#link-list ul {
    display: flex;
    flex-wrap: wrap;
}
#link-list li {
    flex: 0 0 50%;
    box-sizing: border-box;
    border: 1px solid #ddd;
    margin: -0.5px 0;
}

margin: -0.5px 0 是用来压掉相邻元素边框叠加产生的双线。这类细节如果没自己踩过坑，通常不会主动处理。另外它还指出模板里残留的一个用于清除浮动的空标签，改成 flex 之后已经没有作用。

这个任务整体没什么难度，它的表现和其他主流模型差别不大。

二、查一次日志异常

第二个任务偏运维：分析站点最近一段时间的访问日志，看流量构成有没有变化。

要处理几个前提：日志按天切割并压缩，需要跨文件合并统计；日志里混杂大量爬虫，识别爬虫主要靠 User-Agent 关键词；referer 字段在 HTTPS 下会被剥离，导致来源统计偏低，不能直接拿表面数字当结论。

它给出的脚本结构清楚，也提到了 referer 口径的局限。

过程中出现一个异常值：某一天某个来源的流量突然涨到平时的七八倍。它没有把这个数直接计进去，而是去查了来源 IP 的分布：

# 按来源 IP 聚合
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -5

结果显示绝大部分请求来自同一个 IP。顺着这个 IP 看它请求的路径，是一串常见的配置文件名，说明有人伪造了 referer 字段，在批量探测站点配置。

因为站点没有这些静态文件，请求都返回 404，没有造成泄露。但如果只看汇总数字，很容易把这天当成真实的流量高峰。

这是这几天里我觉得比较有用的一处：它没有停在"把命令写出来"，而是对数据里的不合理之处做了追查。

几个需要注意的地方

慢热

官方把"复杂任务的长思考和过度自我验证倾向"列进了已知问题。体感上确实如此，眼看要出结果了，它还要再验证一轮，复杂任务的等待时间偏长。

自部署可以关掉深度思考直接出结果：

response = client.chat.completions.create(
    model="hy4-preview",
    messages=[{"role": "user", "content": "..."}],
    temperature=0.9,
    top_p=1.0,
    extra_body={"chat_template_kwargs": {"reasoning_effort": "no_think"}}
)

官方推荐 temperature=0.9、top_p=1.0，reasoning 默认 high。要速度就传 no_think，要质量保留默认。简单任务用这个开关能省不少时间。

没有多模态

官方说明里写得很直接：Hy4 preview 和 Hy3 都是大语言模型，暂不具备多模态能力。跑图像、视频这类任务时会切到其他模型，照常消耗积分。

跑分待验证

目前所有性能数据都是腾讯自述，没有第三方评测和社区实测。等 Artificial Analysis 或社区数据出来，结论可能有出入，看跑分表时留一点余地。

其他

几个用得上的信息：

  • 免费期到 9 月 10 日左右，每天限量
  • 自部署门槛不低：vLLM 和 SGLang 都还没有现成支持，需要从源码编译，FP8 版也要至少 8 卡
  • Hugging Face：tencent/Hy4-preview；在线体验入口是腾讯 AI Studio；API 在腾讯云 TokenHub，OpenRouter 上 ID 为 tencent/hy4-preview

整体用下来，它在"理解既有代码上下文、在约束下做改动"这类任务上表现正常，处理日志分析时会对异常数据做追查，这两点对我维护老项目有用。慢热是主要问题，简单任务建议关掉深度思考。这些都是有限场景下的试用结果，不足以代表它的整体水平。

本文链接：https://bookshadow.com/weblog/2026/08/30/hy4-preview-legacy-blog-trial/
请尊重作者的劳动成果，转载请注明出处！书影博客保留对文章的所有权利。

Pingbacks已打开。

引用地址

暂无评论

张贴您的评论