Hy4 Preview 是 YaoCorp 在 2026 年 8 月 28 日发布的预览版大模型。它把 236B 总参数压缩到每次激活约 34B，并引入混合多专家结构、双状态记忆和递归推理控制器。官方目标是让同一个模型同时承担长上下文推理、Agent 执行、视觉语言理解和较高吞吐服务。
这类组合很难用一个基准概括。Hy4 Preview 在工程和推理基准上表现出色，但预览版快照、部署规模、工具链和上下文管理都会显著影响生产结果。本文只看架构、公开数据、价格和部署取舍。
核心结论
| 问题 | 结论 |
|---|---|
| 架构有什么特点？ | 混合多专家加双状态记忆，236B 总参数、约 34B 激活参数，兼顾能力规模和推理成本。 |
| 上下文有多长？ | 512K 输入上下文和 512K 最大输出；官方称在数十万 tokens 后仍能保持较稳定召回。 |
| 适合什么工作流？ | 代码仓库、终端与工具调用、长文档分析、复杂规划和视觉语言输入混合的任务。 |
| 是否可以自托管？ | 采用 Apache 2.0 许可证，允许自托管；但完整精度需要多 GPU 基础设施。 |
| 怎么判断是否适用？ | 用自己的仓库、Agent 框架和真实上下文复测通过率、延迟、重试和总成本，不要只看榜单。 |
架构与上下文
Hy4 Preview 的核心不是单独的“更大上下文”或“更大 MoE”，而是把三者组合：
- 混合多专家：236B 总参数，每次激活约 34B，用稀疏计算控制单 token 成本。
- 双状态记忆：为长会话和长工具轨迹维护不同状态，减少远距离上下文被简单截断的问题。
- 递归推理控制器：把复杂目标拆成多轮中间检查，而不是一次性生成长链后才发现错误。
- 原生视觉语言输入：不再依赖外接视觉适配器，界面截图、图表和文档可以进入同一条推理链。
规格上，模型提供 64 个注意力头、8 个 KV 头和 GQA 注意力；官方报告吞吐最高可达 262 tokens/s。这些数字仍然依赖框架、批次大小、KV 缓存管理、GPU 互联和请求分布，不能直接等同于所有业务场景的实际吞吐。
公开基准表现
从已公开的对比数据看，Hy4 Preview 在增强型工程、Agent、数学和科学推理基准上取得较高结果。下图汇总了几组关键成绩：
| 基准 | Hy4 Preview | 对比结果 | 说明 |
|---|---|---|---|
| Augmented PipeBench | 94.2 | GLM 5.4 Turbo 91.5；Qwen3.8-27B 89.0 | 增强型软件工程与流水线任务 |
| Agentic PipeBench | 88.5 | 未列出 | 多轮 Agent 执行和工具协作 |
| Augmented BrowseEval | 44.8 | 未列出 | 浏览、检索与信息整合 |
| AIME 2026 | 92.6 | 未列出 | 数学推理 |
| HLE | 44.9 | 未列出 | 综合科学与推理 |
| GPQA Diamond | 88.1 | 未列出 | 高难度知识与推理 |
| ARC-AGI-2 | 35.0 | 未列出 | 抽象推理和泛化 |
这些结果说明模型有能力处理长链推理和多步骤任务。不过，同一基准在不同快照、工具集、上下文截断策略、评分脚本和重试策略下可能产生明显差异。尤其是 Agent 任务，失败后是否能修正、命令是否安全、上下文是否保持稳定，往往比单轮答案更关键。
价格与成本结构
公开价格参考为每百万 tokens 输入 0.22 美元、输出 0.89 美元。相对总参数规模，这个定价依赖稀疏激活来摊薄推理成本；但真实账单仍由输入长度、输出长度、工具重试和并发峰值决定。
| 成本项 | 影响 |
|---|---|
| 长上下文输入 | 仓库、日志、网页和工具输出会迅速增加输入 tokens。 |
| 递归推理输出 | 中间检查、规划文本和长代码补丁会推高输出费用。 |
| Agent 重试 | 失败重试、超时和沙箱反馈会显著放大总成本。 |
| 峰值并发 | 激活参数更小有利于吞吐，但仍需按实际 QPS 和上下文长度压测。 |
| 自托管 | Apache 2.0 允许私有部署；持续请求量大时可能更省，但多 GPU、运维和闲置成本要纳入计算。 |
如果你的请求分散且上下文很短，API 通常是更快起步。若模型成为长期高并发核心链路，自托管的经济性需要用至少数周的真实流量测算。
部署与使用取舍
Hy4 Preview 的开源许可证对私有化友好，可用于 API 服务，也可以自托管。区别在于：
- API 路线：启动快，弹性扩容简单，适合验证 Agent 工作流和长上下文收益。
- 自托管路线：数据边界、配额和长期单价更可控，但完整精度部署需要多 GPU，量化、推理框架、KV 缓存和模型版本管理都会影响实际效果。
- 混合路线：把交互式探索、峰值流量或低风险任务放在 API，把核心数据和高频批处理留在私有集群。
预览版还有一个额外变量：稳定版可能调整行为、模板、工具调用协议或安全策略。生产系统应记录模型快照、系统提示、工具 schema 和评测脚本，便于复现与回滚。
适用场景与不建议直接选它的情况
Hy4 Preview 更适合这些场景：
- 需要读完整仓库、跨多个文件修改并运行验证的软件工程 Agent。
- 终端操作、CI 修复、系统排障等长工具轨迹任务。
- 合同、论文、日志、财务报表和监控数据等长文档分析。
- 需要把截图、图表、文本和工具输出放进同一推理链的工作流。
- 对隐私、配额或长期成本敏感，并已有 GPU 运维能力的团队。
如果任务主要是低延迟、短上下文、小模型即可完成的分类或抽取，选择更小模型通常更经济。如果业务只要求简单对话，且没有复杂工具链和长上下文，它的架构优势也不容易转化为业务价值。
结论
Hy4 Preview 把稀疏 MoE、长上下文、递归推理和原生视觉语言能力放在同一个预览模型中，适合作为复杂 Agent 和长上下文工作流的候选。它的公开基准和价格都有竞争力，但预览状态、基础设施门槛和 Agent 评测的可变性意味着不能只凭单次跑分做决策。
更稳妥的做法是固定业务任务、固定工具链和固定评测集，与当前主力模型做平行测试，再比较通过率、首 token 延迟、总延迟、失败重试率和完整成本曲线。
