8 月 28 日，腾讯混元团队把 Hy4 preview 的权重扔上了 HuggingFace——770B 总参数、49B 激活、1M 上下文窗口、Apache 2.0 许可证。三天后，OpenRouter 上的 token 消耗量已经突破 1.1 万亿。这个模型不是又一个刷榜的中国大模型，它的定位很明确：给编程 Agent 当大脑。
我花了一个下午研究这个模型的 API 接口规格、推理控制参数和工具调用能力，也把它的 benchmark 数据和 GLM-5.3、Kimi K3 做了横向对比。结论先放前面：编程能力确实能打，但”慢热”问题比你想象得更严重。
从 Hy3 到 Hy4：不只是参数翻倍
今年 4 月我写过 腾讯混元 Hy3 preview 深度评测，当时 Hy3 是 295B 总参数、21B 激活、256K 上下文。四个月过去，Hy4 把这三个数字分别拉到了 770B / 49B / 1M——总参数涨了 2.6 倍，激活参数涨了 2.3 倍，上下文翻了 4 倍。
但真正让我意外的是 DeepSWE 指标：从 Hy3 的 28.0 直接飙到 64.3，单代际提升 2.3 倍。这个 benchmark 衡量的是真实软件工程场景下的任务完成率，不是刷题分数。腾讯自己的说法是”Hy4 能协调多个 Codex 会话并行工作，评估结果后合并”——这不是聊天模型的定位，这是编排器（orchestrator）的定位。
MoE 架构的好处是推理成本可控。770B 听着吓人，但每次推理只激活 49B 参数，实际成本远低于同等规模的 dense 模型。OpenRouter 上的定价也印证了这一点：$0.834/百万输入 token、$2.501/百万输出 token——大约是 GPT-5.6 Sol 输出价格的十分之一。
5 行代码跑通 API 调用
Hy4 preview 已上线 OpenRouter，model slug 是 tencent/hy4-preview。最快的上手方式就是用 OpenAI 兼容 API 直接调：
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["OPENROUTER_API_KEY"],
base_url="https://openrouter.ai/api/v1",
)
response = client.chat.completions.create(
model="tencent/hy4-preview",
messages=[
{"role": "user", "content": "用 Python 写一个二分查找函数，要求处理空列表和重复元素"}
],
max_tokens=1024,
)
print(response.choices[0].message.content)
print(f"\nPrompt tokens: {response.usage.prompt_tokens}")
print(f"Completion tokens: {response.usage.completion_tokens}")运行环境：Python 3.10+，pip install openai，设置 OPENROUTER_API_KEY 环境变量。
关于 OpenRouter 的实测数据（截至 8 月 31 日，模型上线第 3 天）：
| 指标 | 数值 |
|---|---|
| P50 吞吐量 | 44 tokens/s |
| P50 延迟 | 2.88 秒 |
| P50 端到端延迟 | 12.6 秒 |
| 3 天运行时间 | 99.99% |
| 3 天可用率 | 98.68% |
| 缓存命中率 | 94.06% |
| 工具调用错误率 | 0.49% |
| 结构化输出错误率 | 14.43% |
吞吐量 44 tokens/s 在开源模型里不算快——对比之下 GLM-5.3-Flash 要快得多。但考虑到 770B 的体量和深度推理的默认行为，这个速度可以接受。缓存命中率 94% 说明大部分请求命中了 prompt 缓存，实际输入成本远低于 $0.834/M。
reasoning_effort 参数：解决”慢热”的关键
Hy4 preview 有一个被官方承认的问题：慢热。模型默认开启深度思维链推理（deep CoT），即使是简单问题也会反复自我验证。腾讯在已知问题里直接列出了”复杂任务的长思考和过度自我验证倾向”。
这在实际使用中意味着什么？以一个简单问题为例：”Python 列表和元组的区别？”根据多个来源的报告，模型在 high 模式下可能花费将近 15 秒才返回结果，其中大部分时间在 reasoning tokens 上。对于需要快速交互的场景，这个延迟不可接受。
解决方案是 reasoning_effort 参数。Hy4 的 chat template 内置了两档推理强度：
high（默认）：深度推理，适合复杂编程和数学问题no_think：关闭推理，适合简单问答和快速交互
通过 OpenRouter 调用时，可以用以下方式切换：
response = client.chat.completions.create(
model="tencent/hy4-preview",
messages=[{"role": "user", "content": "Python 列表和元组的区别？"}],
extra_body={
"chat_template_kwargs": {"reasoning_effort": "no_think"}
},
max_tokens=512,
)我的建议：开发阶段用 no_think 快速迭代，确认逻辑正确后切回 high 做最终生成。这比一直开着 high 模式等 15 秒要实际得多。
工具调用与结构化输出
Hy4 preview 支持 OpenAI 兼容的 function calling 和 structured output。这意味着你现有的 Agent 框架（LangChain、CrewAI、AutoGen 等）可以直接接入，不需要改解析层。
OpenRouter 的实测数据显示工具调用错误率只有 0.49%——在开源模型里属于优秀水平。但结构化输出错误率 14.43% 偏高，意味着约七分之一的 JSON 格式化请求会出格式问题。如果你的 Agent 依赖严格的 JSON schema 输出，需要加一层容错解析。
一个可直接运行的 function calling 示例：
import json
tools = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的天气",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名"}
},
"required": ["city"],
},
},
}
]
response = client.chat.completions.create(
model="tencent/hy4-preview",
messages=[{"role": "user", "content": "北京今天天气怎么样？"}],
tools=tools,
tool_choice="auto",
)
if response.choices[0].message.tool_calls:
call = response.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)
print(f"模型调用了 {call.function.name}，参数: {args}")
# 输出: 模型调用了 get_weather，参数: {'city': '北京'}这段代码按 OpenAI 标准 function calling 接口编写，调用后模型应返回 get_weather 的 tool_call（预期输出见注释）。实际效果取决于模型对意图的识别，拿到 API Key 后建议先跑一遍确认参数提取是否符合预期。
编程能力横评：Hy4 vs GLM-5.3 vs Kimi K3
三大中国开源模型在 8 月最后一周密集发布，我把能找到的独立 benchmark 数据整理如下：
| Benchmark | Hy4 preview | GLM-5.3 | Kimi K3 | Claude Opus 5 |
|---|---|---|---|---|
| SWE-bench Multilingual | 82.9 | 81.3 | 80.8 | — |
| Terminal-Bench 2.1 | 85.4 | 88.2 | 88.3 | — |
| SWE-bench Pro | 65.7 | — | — | 79.2 |
| DeepSWE | 64.3 | — | — | — |
数据来源：byteiota.com 和 clauday.com 的独立评测整理，以及腾讯官方技术报告。
几个值得注意的点：
- SWE-bench Multilingual 上 Hy4 领先，说明多语言编程场景（中英文混合代码库）是它的强项
- Terminal-Bench 上 GLM-5.3 和 Kimi K3 都比 Hy4 高 3 分，说明在持续终端工具调用场景 Hy4 不占优
- SWE-bench Pro 上 Claude Opus 5 仍然领先 Hy4 13.5 分，顶级编程任务的开源-闭源差距还在
- 所有 Hy4 benchmark 数据来自腾讯内部评测，尚无独立 leaderboard 验证——这个 caveat 必须说清楚
如果你的场景是中文为主的编程任务、代码审查、文档处理，Hy4 的性价比很高。如果是纯英文持续 Agent 工具调用，GLM-5.3 或 Kimi K3 可能更合适。
定价对比：它到底便宜多少
把几个主流模型放一起看：
| 模型 | 输入 $/M | 输出 $/M | 上下文 |
|---|---|---|---|
| Hy4 preview | $0.834 | $2.501 | 1M |
| GPT-5.6 Sol | $4.00 | $20.00 | 256K |
| Claude Sonnet 5 | $2.00 | $10.00 | 1M |
| GLM-5.3 | ~$0.60 | ~$1.80 | 1M |
| Kimi K3 | ~$0.55 | ~$2.20 | 256K |
注：GLM-5.3 和 Kimi K3 的价格为 OpenRouter 上的近似值，可能随提供商变动。
Hy4 的输出价格 $2.501/M 大约是 Claude Sonnet 5 的四分之一、GPT-5.6 Sol 的八分之一。加上 94% 的缓存命中率（缓存读取只要 $0.042/M），如果你的 prompt 中有大量重复的系统提示或上下文，实际输入成本可以低到 $0.081/M。
免费试用渠道
如果不想花钱，有两个渠道可以白嫖：
WorkBuddy / CodeBuddy：腾讯自己的 AI 编程助手和办公工具，Hy4 发布后限时两周免费使用。这个窗口大约在 9 月 11 日左右关闭。如果你还没用过 WorkBuddy，可以参考我之前写的 腾讯 WorkBuddy 独立 App 上线指南。
OpenRouter 每日免费额度：OpenRouter 对部分模型提供每日免费调用额度，Hy4 是否包含在内需要查看你的账户额度页面。
如果你更倾向于自己跑模型，可以参考之前写的 本地部署大模型完全指南——不过 Hy4 的 770B 体量意味着你需要至少 8 张 H200（720GB VRAM），普通开发者的 Mac 或单卡服务器跑不动。
自部署路径（给有 GPU 集群的团队）
Hy4 preview 在 HuggingFace 上以 Apache 2.0 许可证开源，包含 BF16 原版（约 1.56TB）和 FP8 量化版（约 770GB）。官方提供了 vLLM 和 SGLang 两套部署方案：
# 方式一：vLLM 从源码编译后启动（8 卡 FP8）
vllm serve tencent/Hy4-preview-FP8 \
--tensor-parallel-size 8 \
--max-model-len 1048576 \
--gpu-memory-utilization 0.92 \
--trust-remote-code \
--port 8000
# 方式二：Docker 一键启动（vLLM 官方镜像）
docker run --gpus all -p 8000:8000 --ipc=host \
vllm/vllm-openai:hy4-preview tencent/Hy4-preview-FP8 \
--tensor-parallel-size 8 \
--served-model-name hy4-preview来源：腾讯云开发者社区和 byteiota.com 的部署文档。
相关 vLLM 部署的详细参数调优，可以参考我之前写的 vLLM v0.28.0 上手指南，那篇文章覆盖了从 pip install 到 tensor parallel 配置的完整流程。
踩坑提醒
1. 不要在 preview 阶段用于生产环境。 Hy4 的 API 行为可能变更，OpenRouter 上前 3 天的可用率是 98.68%（意味着大约每天有 11 分钟不可用）。腾讯自己也说”预训练和后训练都还有提升空间”。如果你要做产品决策，等稳定版。
2. 结构化输出不可靠。 14.43% 的错误率意味着你不能假设模型返回的 JSON 一定合法。务必加一层 try/except 和 schema 校验。对比之下，工具调用（function calling）的 0.49% 错误率可以放心使用。
3. “慢热”不只是延迟问题，还是成本问题。 深度推理模式下的 reasoning tokens 也计费。一个看似简单的问题，模型可能在 reasoning 阶段花掉几百 token 的”思考费”。如果你的应用是高并发低延迟场景，务必关掉默认推理或切到 no_think。
4. 不建议用于： 纯英文持续 Agent 工具调用（GLM-5.3 更快）、需要 100% JSON 可靠性的结构化数据抽取（错误率偏高）、对延迟敏感的实时交互场景（P50 端到端 12.6 秒）。
关于腾讯的”产品即训练场”模式
Hy4 发布当天就集成进了腾讯自己的四款产品：WorkBuddy、CodeBuddy、元宝和 ima。这不是常见的”API 先行”策略，而是”产品先行”——模型在发布前已经在真实用户场景中跑过。
这种模式的好处是模型的”可用性”在发布前就经过了验证，不是只在 benchmark 上好看。坏处是 benchmark 数据全部来自腾讯内部评测，没有独立第三方验证。我整理的数据虽然来自多个独立来源的汇总，但原始 benchmark 仍然是腾讯自己跑的。读者在做选型决策时需要把这个 caveat 考虑进去。
更宏观的背景：8 月最后一周，三家中国实验室密集发布了开源权重模型——8 月 27 日 Qwen3.8-Flash-Next、8 月 28 日 GLM-5.3 权重、8 月 28 日 Hy4 preview。闭源前沿模型每个季度涨价，开源旗舰每 24 小时出一个新的。这个差距正在变成一个结构性的故事。
发表回复