💡

文章摘要

2026年4月23日,腾讯混元发布重建后首个模型 Hy3 preview——295B总参数/21B激活参数的MoE架构,支持256K上下文和快慢思考融合。本文系统解读其架构设计、强化学习重建、基准测试表现、定价策略,以及与竞品的对比分析。

前置阅读收获

读完本文,你将理解:腾讯混元 Hy3 preview 的完整技术架构(295B/21B MoE、快慢思考融合、256K上下文窗口)、混元重建的三大核心原则(能力体系化、评测真实性、性价比追求)、基准测试表现(SWE-Bench Verified、BrowseComp、ClawEval、FrontierScience-Olympiad 等)、定价与性价比分析(输入1.2元/百万tokens、缓存0.4元/百万tokens),以及与同类开源模型的对比定位

2026年4月23日,腾讯混元正式发布并开源Hy3 preview语言模型。这是混元完成底层技术重构后的首个成果,采用快慢思考融合的混合专家MoE)架构,总参数量达 295B,激活参数仅 21B,最大支持 256K 上下文长度。发布仅两周,该模型在 OpenRouter 的全球 API 调用量排行榜上登顶总榜第一,Token 调用量较上代 Hy2 增长超 10 倍。

本文所有技术数据均来自腾讯官方公告、ModelScope、OpenRouter 官方页面及权威科技媒体(澎湃新闻、品玩、上观新闻)报道,经交叉验证。

💡 一句话理解

如果你对 MoE 架构设计、快慢思考推理机制、或者 Agent 场景下的模型选型感兴趣,本文将提供从架构到实战的完整分析框架。建议重点关注第三章「快慢思考机制」和第六章「与竞品对比」。'

⚠️ 常见踩坑

Hy3 preview 为技术预览版本(preview),非最终正式版。腾讯明确表示将继续扩大预训练和强化学习规模,Hy3 正式版的性能和能力可能显著不同。本文基于 preview 版本的实际数据,不代表最终产品表现。

一、混元重建:为什么需要从头来过

要理解 Hy3 preview 的技术路线,首先要了解腾讯混元为何在 2025 年底进行了全面重建

重建背景

2025年下半年,腾讯对大模型研发架构进行了全面升级:

  • 新成立AI Infra 部——负责基础设施和训练平台
  • 新成立AI Data 部——负责数据工程和数据治理
  • 新成立数据计算平台部——负责算力调度和资源管理
  • 28 岁的姚顺雨(Vinces Yao)出任首席 AI 科学家,同时兼任 AI Infra 部和大语言模型部负责人

姚顺雨毕业于清华大学姚班,曾加入 OpenAI 参与 Operator 和 Deep Research 项目开发。2025年5月,他以27岁年龄入选《麻省理工科技评论》「35岁以下科技创新35人」中国区名单,成为最年轻入选者。

重建的三大核心原则

混元团队在重建中确立了三个核心原则,这直接决定了 Hy3 preview 的设计方向:

第一,能力体系化——不推崇"偏科"

即使是最单一的代码智能体应用,也涉及推理、长文本理解、指令遵循、对话、代码生成、工具调用等多种能力的深度协同。混元认为模型必须在所有维度上均衡发展,而不是在某个榜单上刷高分。

第二,评测真实性——主动跳出易被"刷榜"的公开榜单

通过自建题目、最新考试、人工评测、产品众测等多种方式评估模型的"真实战斗力"。这意味着混元不追求在可能被数据污染的公开数据集上拿第一,而是关注模型在真实场景中的表现

第三,性价比追求——让智能用得起、用得好

深度协同模型架构和推理框架的设计,大幅降低任务成本。在2026年 AI 算力集体涨价的背景下,这一原则尤为重要。

来源交叉验证:重建细节来自腾讯官方公告和澎湃新闻报道;姚顺雨背景来自《麻省理工科技评论》官方名单;三大原则来自腾讯混元技术博客。

图表加载中…

💡 一句话理解

理解混元重建的关键在于认识到这不是简单的模型迭代,而是从基础设施、数据工程到评估体系的全栈重构。这与单纯'换个更大的模型'有本质区别。'

⚠️ 常见踩坑

姚顺雨虽然是混元重建的技术负责人,但大型模型项目是团队协作的成果。不要把 Hy3 preview 的成功归因于单个人,而应理解为腾讯 AI 体系化建设的第一阶段成果。

二、Hy3 preview 架构:295B/21B MoE 的设计哲学

Hy3 preview 采用混合专家MoE, Mixture of Experts)架构,这是当前大语言模型实现"大参数、小激活"的主流技术路线。

2.1 MoE 架构基础

在传统的稠密模型(Dense Model)中,所有参数在每次推理时都被激活。一个 200B 参数的稠密模型,每次推理都需要计算全部 200B 参数的激活值。

MoE 架构中,模型被拆分为多个"专家"(Experts),每个输入 token 只激活其中一小部分专家。Hy3 preview 的具体配置:

-总参数295B(2950亿)
-激活参数21B(210亿)
-激活比例:约7.1%(21B/295B)

这意味着 Hy3 preview 拥有 295B 参数级别的知识容量,但每次推理只消耗相当于 21B 稠密模型的计算量。知识容量与推理成本的解耦MoE 的核心优势。

2.2 为什么选择 295B/21B 这个比例?

295B 总参数确保了模型的知识广度——足够的参数来编码海量知识。21B 激活参数则确保了推理效率——每次推理只需要 21B 参数的计算量,这使得:

-显存占用可控:加载完整模型权重需要约 590GB(FP16),但推理时的活跃计算只需要约 42GB
-推理延迟低:21B 活跃参数意味着更快的 token 生成速度
-部署灵活:可以在单台 8×H100 甚至更小的 GPU 集群上部署

技术参考MoE 激活比例的设计需要在知识容量和路由效率之间权衡。激活比例过低(如 1-3%)会导致专家利用率不足,过高(如 20-30%)则失去 MoE 的成本优势。7.1% 是一个相对保守但稳健的选择。

图表加载中…

💡 一句话理解

对比稠密模型时,不要只看激活参数MoE 模型的知识容量取决于总参数,而不仅仅是激活参数。一个 295B/21B 的 MoE 模型在知识丰富度上远超 21B 稠密模型,因为它的专家网络可以编码更多样化的知识。'

⚠️ 常见踩坑

MoE 架构的路由稳定性是一个开放研究问题。在 Hy3 preview 中,如果路由门控不够稳定,可能导致某些专家被过度使用或某些专家几乎不被使用,从而影响模型性能。腾讯通过大规模强化学习训练来优化路由策略。

三、快慢思考融合:Hy3 preview 的推理机制

Hy3 preview 最引人注目的设计之一是快慢思考融合(Fast & Slow Thinking Hybrid),这允许模型在不同任务复杂度下自动调整推理深度。

3.1 什么是快思考和慢思考?

这个概念源自心理学家丹尼尔·卡尼曼的双系统理论:

  • 系统一:快思考,直觉性、自动化的思考,几乎不需要意识努力
  • 系统二:慢思考,分析性、深思熟虑的思考,需要集中注意力

LLM 语境中:

  • 快思考:模型直接生成回答,不经过额外的推理步骤,类似直觉回答
  • 慢思考:模型在生成最终答案之前,先进行链式推理,类似深思熟虑

3.2 Hy3 preview 的三档推理模式

Hy3 preview 通过 reasoning_effort 参数控制推理深度:

模式 参数值 适用场景 行为
直接响应 "no_think" 简单问答、闲聊、格式转换 直接生成答案,无额外推理步骤
低强度推理 "low" 中等复杂度的任务 有限的推理步骤,平衡速度与质量
高强度推理 "high" 数学、编程、复杂推理 深度链式推理,最大化推理质量

3.3 快慢思考融合的技术优势

快慢思考融合的核心优势在于 智能密度 (Intelligence Density)——在相同计算成本下获得更高的智能输出。

Hy3 preview 的推理效率相比上代模型提升 40%,这得益于:

  • 模型与推理框架的深度协同优化
  • 算子性能提升(底层计算加速)
  • 量化算法优化(降低精度损失)

在腾讯文档 AI PPT 场景中,Hy3 preview 相较 Hy2:

  • 生成成功率提升 20%
  • 评测得分提升 10%
  • 生成耗时缩短 20%

在 CodeBuddy 和 WorkBuddy 智能体应用中:

  • 首字延迟(TTFT)降低 54%
  • 端到端响应时间缩短 47%
  • 成功率超过 99.99%

💡 一句话理解

在实际使用 Hy3 preview 时,建议默认使用 'no_think' 模式。对于绝大多数日常任务(文本生成、摘要、翻译),快思考模式已经足够。只在数学计算、代码调试、复杂推理等场景下切换到 'high' 模式。'

⚠️ 常见踩坑

高强度推理模式会显著增加 Token 消耗和响应时间。在 Agent 工作流中,如果每个步骤都使用 'high' 模式,一个 495 步的复杂工作流的成本可能超出预算。建议仅在关键推理节点启用慢思考。

四、基准测试表现:真实场景而非刷榜

混元坚持"评测真实性"原则,因此在公开基准和自建评测上都进行了测试。以下是 Hy3 preview 的关键测试结果:

4.1 代码与智能体基准

代码和智能体是 Hy3 preview 提升最为显著的方向:

-SWE-Bench Verified:取得有竞争力的结果(该基准测试模型在真实 GitHub Issue 上的修复能力)
-Terminal-Bench 2.0:测试模型在终端环境中的代码执行能力
-BrowseComp:测试模型在开放网络中的搜索和信息整合能力
-WideSearch:测试模型在大规模信息空间中的检索、筛选与整合能力
-ClawEvalWildClawBench:测试模型在复杂智能体场景中的表现,包括工具调用、多步推理等

4.2 推理与数学基准

-FrontierScience-Olympiad:高难度理工科推理任务
-IMOAnswerBench:国际数学奥林匹克竞赛级别的数学推理
-清华大学求真书院数学博资考(26春):博士生资格考试级别的数学测试
-全国中学生生物学联赛(CHSBO 2025):生物学竞赛

4.3 自建内部评测

腾讯混元构建了多个内部评测集,这些评测更贴近真实用户场景

-Hy-Backend:后端工程任务集,测试模型在真实开发场景中的后端代码生成能力
-Hy-Vibe Bench:贴近真实用户开发交互的评测,关注模型与开发者的交互质量
-Hy-SWE Max:高难度软件工程开发任务集

4.4 产品集成表现

在腾讯真实产品环境中,Hy3 preview 的表现:

-元宝:意图理解准确率和文本生成质量显著提升
-CodeBuddy:首字延迟降低 54%,成功率 99.99%+
-WorkBuddy:端到端响应时间缩短 47%,稳定驱动最长495 步的复杂 Agent 工作流
-腾讯文档 AI PPT:生成成功率提升 20%
-QQ 小Q 助手:数学推理明显提升,多场景指令遵循与泛化能力增强

来源:基准数据来自腾讯混元官方技术博客;产品数据来自腾讯官方公告和上观新闻报道。

💡 一句话理解

评估一个模型时,不要只看公开基准分数。混元的自建评测体系(Hy-Backend、Hy-Vibe Bench、Hy-SWE Max)更能反映模型在真实工程场景中的表现。如果你的使用场景类似(企业内部 Agent、代码辅助、文档处理),混元的内部评测结果参考价值更大。'

⚠️ 常见踩坑

混元公开的具体基准分数较为有限(仅描述为'有竞争力的结果'),这在开源模型中不太常见。建议在决定采用前自行测试,特别是针对你的具体业务场景进行 PoC 验证。

五、上下文学习能力的创新评估

在 Hy3 preview 的技术报告中,腾讯混元提出了一个创新性的评估框架:CL-benchCL-bench-Life

5.1 什么是上下文学习(In-Context Learning, ICL)?

上下文学习是指模型在不更新参数的情况下,仅通过在提示词中提供少量示例(few-shot),就能学会完成新任务的能力。这是大语言模型最强大的特性之一。

5.2 CL-bench 的设计思路

混元团队观察到,在真实的生产与生活场景中,模型的首要挑战是:

1.理解杂乱冗长的上下文——用户提供的信息往往是无序、不完整、充满噪声的
2.遵从复杂多变的规则——不同场景有不同的约束条件,模型需要准确识别并遵守

CL-bench 和 CL-bench-Life 正是基于这些观察设计的评测集,它们模拟了腾讯真实业务场景中的上下文理解和指令遵循挑战。

5.3 为什么这很重要?

大多数公开基准(如 MMLU、GSM8K)测试的是模型的知识掌握程度,而不是它在真实、混乱、不完美输入下的表现。

CL-bench 填补了这个空白——它测试的是模型能否在信息不完整、规则不明确、上下文冗长的情况下,仍然给出有用的输出。这正是 Agent 场景中最核心的能力。

本站观点:CL-bench 的设计理念代表了评估范式的转变——从"模型知道什么"到"模型在真实场景中能做什么"。这种评估方式的普及,将推动整个行业从"刷榜竞争"走向"实用导向"。

图表加载中…

💡 一句话理解

如果你在评估不同模型的 Agent 能力,不要只看 SWE-Bench 分数。关注模型在长上下文、复杂指令、多步工具调用等场景中的实际表现,这些才是决定 Agent 可用性的关键指标。'

⚠️ 常见踩坑

CL-bench 和 CL-bench-Life 是腾讯自建的内部评测,未公开发布详细评测数据和测试用例。虽然设计理念优秀,但缺乏第三方复现验证。在参考其结果时,建议结合独立评测进行交叉验证。

六、与同类开源模型的对比分析

Hy3 preview 发布时,开源模型市场竞争激烈。以下是与主要竞品的对比:

6.1 架构对比

维度 Hy3 preview Qwen 2.5 DeepSeek V3 Llama 3.3
总参数 295B (MoE) 72B (稠密) 671B (MoE) 70B (稠密)
激活参数 21B 72B 37B 70B
上下文窗口 256K 128K 128K 128K
开源协议 可商用开源 Apache 2.0 MIT Llama 3.3
推理模式 快慢思考三档 标准 深度思考 标准

6.2 定价对比(腾讯云 TokenHub)

Hy3 preview 的定价策略极具竞争力:

-输入价格:最低1.2 元/百万 tokens
-缓存命中价格:最低0.4 元/百万 tokens
-输出价格:最低4 元/百万 tokens
-Token Plan 个人版:最低28 元/月

相比 Hy2 代,成本大幅下降。推理效率提升 40% 意味着在相同任务量下,Hy3 preview 消耗的算力和时间更少。

6.3 Agent 生态集成

Hy3 preview 支持接入主流开源智能体框架:

-OpenClaw:已支持
-OpenCode:已支持
-KiloCode:已支持

在 OpenRouter 上线后,Hy3 preview 限时两周免费,并在 4 月 29 日登顶 OpenRouter 全球 API 调用量总榜第一。上线两周 Token 调用量较 Hy2 增长超 10 倍,代码与智能体场景增幅突破 16.5 倍。

💡 一句话理解

如果你的主要场景是 Agent 开发,Hy3 preview 的 21B 激活参数意味着它可以在较小的 GPU 集群上部署,同时保持 295B 级别的知识容量。性价比可能是当前开源模型中最高的之一。'

⚠️ 常见踩坑

256K 上下文窗口虽然大,但实际有效上下文长度可能短于理论值。在处理超长文档时,建议分段处理或使用检索增强(RAG),而不是依赖模型的原始上下文窗口

七、生态整合:混元与腾讯产品的深度 Co-Design

Hy3 preview 不是孤立发布的模型,而是与腾讯众多产品线深度协同设计(Co-Design)的成果。

7.1 已接入的产品线

首批上线(2026年4月23日):

  • 腾讯云
  • 元宝(腾讯 AI 助手)
  • ima(腾讯知识库工具)
  • CodeBuddy(AI 编程助手)
  • WorkBuddy(AI 办公助手)
  • QQ
  • QQ 浏览器
  • 腾讯文档
  • 腾讯乐享

陆续上线

  • 微信公众号
  • 和平精英(AI NPC)
  • 腾讯新闻
  • 腾讯自选股
  • 腾讯客服
  • 微信读书

7.2 Co-Design 的意义

"深度协同设计"意味着模型不是简单地"接入"产品,而是在训练阶段就考虑了产品需求

-元宝:针对性提升意图理解、文本创作、深度搜索
-CodeBuddy/WorkBuddy:优化首字延迟和端到端响应时间
-腾讯文档 AI PPT:优化 PPT 生成流程的模板选择、色彩匹配、大纲生成
-和平精英 AI NPC:优化角色扮演和人设一致性
-QQ 小Q 助手:优化长文本响应速度和数学推理

来源:产品集成数据来自腾讯官方公告;Co-Design 细节来自腾讯混元技术博客和上观新闻报道。

💡 一句话理解

如果你正在为产品选型 AI 模型,优先考虑已经在你目标生态中深度集成的模型。模型与产品的 Co-Design 能显著减少你的适配成本和调试时间。'

⚠️ 常见踩坑

腾讯产品线的深度集成是 Hy3 preview 的优势,但如果你不在腾讯生态内,可能需要额外的适配工作。建议在采用前评估模型在你的技术栈中的兼容性(如 vLLMSGLang 部署、API 格式等)。

八、开源与部署指南

Hy3 preview 已作为开源模型发布,支持多种部署方式。

8.1 开源平台

Hy3 preview 已上线:
-GitHub:tencent/Hunyuan
-Hugging Face:Tencent-Hunyuan/Hy3-preview
-ModelScope(魔搭):Tencent-Hunyuan/Hy3-preview
-GitCode

8.2 推理框架支持

支持主流推理框架:

vLLM 部署(推荐启用 MTP 多 token 预测):

SGLang 部署

8.3 Python 调用示例

以下是一个使用 OpenAI 兼容 API 调用 Hy3 preview 的完整示例(见下方代码块)。

来源:API 格式来自 Hugging Face 模型卡片和 ModelScope 官方部署指南。

8.4 微调支持

  • 支持全量微调LoRA 微调
  • 集成DeepSpeed ZeROLLaMA-Factory
  • 提供检查点转换工具(convert_ckpt_to_outer.py)

8.5 推荐推理参数

  • temperature=0.9
  • top_p=1.0
  • reasoning_effort:复杂任务设为 "high",直接响应设为 "no_think"(默认)

来源:部署命令来自 ModelScope 官方页面和 Hugging Face 模型卡片。

python
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY"
)

# 简单对话模式
response = client.chat.completions.create(
    model="Tencent-Hunyuan/Hy3-preview",
    messages=[
        {"role": "system", "content": "你是一个专业的AI助手。"},
        {"role": "user", "content": "解释什么是MoE架构"}
    ],
    temperature=0.9,
    top_p=1.0
)
print(response.choices[0].message.content)
python
# 高强度推理模式(适用于数学、编程等复杂任务)
response = client.chat.completions.create(
    model="Tencent-Hunyuan/Hy3-preview",
    messages=[
        {"role": "user", "content": "证明勾股定理"}
    ],
    extra_body={"reasoning_effort": "high"},
    temperature=0.7,
    top_p=0.95
)
print(response.choices[0].message.content)
bash
git clone https://github.com/vllm-project/vllm.git
VLLM_USE_MODELSCOPE=true vllm serve tencent/Hy3-preview \\
  --enable-auto-tool-choice --tool-call-parser hy3 \\
  --enable-reasoning --reasoning-parser hy3
bash
git clone https://github.com/sgl-project/sglang
pip3 install "transformers>=5.6.0"
SGLANG_USE_MODELSCOPE=true python3 -m sglang.launch_server \\
  --model-path tencent/Hy3-preview

💡 一句话理解

部署 Hy3 preview 时,推荐使用 vLLM 并启用 MTP(Multi-Token Prediction)。MTP 可以显著提升吞吐量,在相同硬件下处理更多并发请求。对于 Agent 场景,建议同时启用 --enable-auto-tool-choice--tool-call-parser。'

⚠️ 常见踩坑

295B 总参数的 MoE 模型需要足够的 GPU 显存来加载权重。FP16 精度下约需 590GB 显存(需要多 GPU 分布式部署)。如果使用量化(如 INT4/GPTQ),显存需求可以大幅降低,但可能影响模型质量。

九、总结与展望:混元重建的**第一步**

Hy3 preview 是腾讯混元重建后的第一步,而非终点。腾讯首席 AI 科学家姚顺雨明确表示:"Hy3 preview 是混元大模型重建的第一步。我们希望通过这次开源和发布,获得来自开源社区和用户的真实反馈,帮助我们提升 Hy3 正式版的实用性。"

9.1 Hy3 preview 的核心价值

1.不是"更强",而是"更可用"——在真实场景中稳定工作,比在基准上刷高分更有价值
2.快慢思考融合——在相同成本下实现更高的智能密度
3.Agent 场景优先——代码和智能体能力提升最为显著
4.极致性价比——推理效率提升 40%,成本大幅下降
5.开源与生态共建——通过开源收集社区反馈,加速正式版迭代

9.2 未来展望

腾讯混元将继续在以下方向推进:

-扩大预训练和强化学习规模——提升模型的智能上限
-Hy3 正式版——基于 preview 的社区反馈进行全面升级
-特色模型能力——探索差异化的模型特性
-全球开发者服务——通过 OpenRouter 等渠道以高性价比服务全球开发者

本站观点:腾讯混元的重建策略代表了中国 AI 企业从"追赶者"到"体系化建设者"的转变。不追求在单个基准上超越对手,而是通过全栈重建确保每个环节都有竞争力。这种策略的长期效果值得持续关注。

图表加载中…

💡 一句话理解

关注 Hy3 preview 的社区反馈和迭代节奏。作为一个 preview 版本,它的更新频率可能很高。如果你的团队计划在生产环境中使用,建议设置版本锁定策略,避免频繁的版本更新导致的行为变化。'

⚠️ 常见踩坑

Hy3 preview 的 preview 状态意味着它可能存在稳定性问题。在生产环境中使用前,建议进行充分的压力测试和边界条件测试,特别是 Agent 工作流中的错误处理路径。