Tencent Hy4 Preview 评测：百万 Token 上下文值得试点吗？

如果长上下文、多步骤工具调用或重复检索代码库已经成为瓶颈，Tencent Hy4 preview 值得进行受控的编程智能体试点。但它还不适合作为所有生产工作流的默认模型。模型规模极大，自托管属于数据中心项目，而且 Tencent 明确说明这个早期版本可能在复杂任务上思考和验证过久。

Tencent 于 2026 年 8 月 28 日发布 Hy4 preview，主干规模为 7700 亿参数，每个 Token 激活 490 亿参数，上下文超过 100 万 Token。Tencent 官方公告列出了 WorkBuddy、CodeBuddy、Tencent Cloud TokenHub 和 OpenRouter 等访问方式。WorkBuddy 与 CodeBuddy 的首发免费体验期公布为两周。

本文核查日期为 2026 年 9 月 1 日，只负责一个搜索意图：软件团队是否应针对长时程编程任务试用 Hy4 preview。市场范围的模型筛选请参阅开放权重 LLM 对比。检索、微调与长上下文之间的架构选择，请参阅 RAG、微调与长上下文决策指南。

60 秒了解 Hy4 preview

Tencent Hy4 preview 是什么？

Hy4 preview 是 Tencent Hy 团队面向编程、办公、分析、游戏和科研任务推出的稀疏 Mixture-of-Experts 旗舰模型。官方 Hugging Face 模型卡记录了 78 层主干。第一层使用 Dense FFN，其余 77 层各有 256 个路由专家和 1 个共享专家。每个 Token 激活 8 个路由专家与共享专家。

770B 指主干参数。原生 Multi-Token Prediction 层另有 10B 总参数和 0.7B 激活参数，用于推测解码。因此部分模型目录显示 780B。Gated DeepSeek Sparse Attention、跨层 IndexCache 和 identity Hyper-Connections 旨在降低长输入与持续推理的成本。

权重、FP8 版本、微调代码、部署文档与许可证都在 Tencent 官方 Hy4 preview 仓库中。这种开放程度具有实际价值，但 770B 模型仍然不是普通笔记本能运行的下载包。

我们的 WorkBuddy 编程测试说明了什么？

我们让 WorkBuddy 中的 Hy4 preview 构建一个完整的交互式 AI 模型基准仪表板。关键不只是生成 HTML。它还编写了核心逻辑，建立无头测试框架，使用 Stub DOM 验证 JavaScript，并在交付前检查筛选器与成本模拟的边界情况。

这是积极的现场观察，不是独立基准。一次成功的仪表板任务不能证明总体成功率、安全水平或经济优势，但它提出了可验证的假设：当智能体需要在长时间运行中保持需求、实现状态、测试证据与工具输出时，Hy4 可能产生价值。

Hy4 preview 的基准有多强？

Tencent 让 163 名内部专家对 203 项工程任务进行盲评。Hy4 平均获得 2.99/4，GLM-5.3 为 2.92，Kimi K3 为 2.94。与 GLM-5.3 相比，Tencent 报告 46.8% 胜、12.8% 平、40.4% 负；与 Kimi K3 相比为 51.2% 胜、7.9% 平、40.9% 负。

这些数字足以支持评估，不足以支持直接迁移。不同基准的框架、工具、上下文、硬件、重试规则与评分方法不同。Hy4 仍是 preview，服务行为也可能继续变化。

百万 Token 是否等于记住整个代码库？

不是。百万 Token 是输入容量，不是记忆或准确率保证。它可以减少破坏性的切块，并让模型同时查看更广的关系，但不能保证位于中间的细节会影响正确修改，也不能保证每个输入 Token 都值得付费。

LongCodeBench 研究发现，此前多种模型在代码上下文增长时性能明显下降，即使它们在规格上支持长窗口。Hy4 发布更晚，并未参加该研究。这篇论文支持测试方法，不支持任何 Hy4 分数。

生产环境应提供仓库地图、清晰任务边界、变更文件提示、验收测试与精简证据。我们的编程智能体更需要上下文而非宣传式智能文章解释了为什么结构化上下文通常优于直接倾倒整个仓库。

选择托管 API 还是自托管 Hy4？

大多数团队应从 WorkBuddy、CodeBuddy、TokenHub、OpenRouter 或经过审查的其他托管方式开始。请向实际购买的服务商确认实时价格、区域、保留策略、吞吐量、上下文限制和工具支持。

官方 vLLM 方案列出 16 张 NVIDIA B200 或 8 张 B300 GPU。vLLM 与 SGLang 示例提供 OpenAI 兼容端点、FP8 权重以及 Hy4 专用推理和工具解析器。这适合已有分布式推理运维能力的团队，不适合普通产品团队的第一次实验。

在把开放权重变成硬件采购前，请使用我们的本地模型与 API 盈亏平衡框架。正确的分母是被接受的任务，而不是理论 Token 数量。

两周 Hy4 编程智能体试点

1. 固定 20 至 30 项任务：包含缺陷修复、仓库导航、功能开发、测试修复、长文档与工具故障。
2. 保持框架可比：使用相同提交、指令、工具、时间限制与验收测试。
3. 按档位测试上下文：精简上下文、经过整理的大上下文与接近上限的压力用例。
4. 记录完整成本：输入、缓存命中、输出、重试、耗时与人工审查分钟数。
5. 主动制造故障：失败命令、格式错误输出、过期文件与缺失依赖。
6. 检查安全边界：分类数据，限制凭据与网络，脱敏日志，对高风险操作要求批准。
7. 根据被接受结果决策：只有验收率、成本、审查时间或数据控制改善时才扩大使用。

商业评估应测量什么？

• 首次通过率与每项被接受变更的总成本
• 上下文不同位置的长文本检索准确率
• 有效工具调用、错误恢复与正常停止
• 验证质量以及对测试失败的正确解释
• P50 与 P95 交付时间，包括过度思考
• 安全例外、密钥暴露与人工覆盖

如果一个模型无法赢得所有角色，请把路由决策与本评测分开。我们的多模型编程智能体采购指南按实测能力分配规划、实现与独立验证。

建议

当长时间工程任务已经成为可量化瓶颈，而且你能与真实基线对比时，应试用 Hy4。先选择托管访问，整理仓库上下文，监测缓存，并让测试而不是模型的自信决定验收。

如果任务适合更小窗口、代码库缺少可靠测试，或无人负责服务商风险与智能体权限，应继续等待。只有经过验证的工作负载、数据控制需求与稳定利用率足以支撑 8 至 16 张数据中心 GPU 及其运维团队时，才考虑自托管。

主要来源与时效边界

架构、访问方式、价格、内部评测与首发优惠来自 Tencent 8 月 28 日公告。详细规格、公开评测、限制和 Apache 2.0 来自模型卡与仓库。硬件信息来自 vLLM。LongCodeBench 只提供一般测试方法，没有评测 Hy4。Wavect 未复现 Tencent 基准。产品访问、价格、隐私条款和服务限制可能在 2026 年 9 月 1 日后改变。