腾讯混元Hy3：首个工程可用的国产MoE大模型

1. 这不是又一个“能发”的模型，而是第一个让我愿意 daily drive 的国产大模型

我用过不下二十个国产大模型的公开 API 和网页端，从最早一批需要手动拼 prompt、调 temperature、反复 retry 才能勉强写完一封邮件的版本，到后来能生成 PPT 大纲但细节错漏百出的“半成品”，再到最近几个月各家堆参数刷榜、分数看着漂亮、一上手就卡壳的“高分低能”选手——说实话，我已经快对“国产大模型可用性”这个词失去耐心了。直到上周拿到腾讯混元 Hy3 preview 的内测权限，在元宝 App 里随手输入“帮我把上周会议纪要里关于客户反馈的三点问题，整理成给技术团队的修复任务清单，每条带优先级和预期交付时间”，它三秒内返回的不是一段泛泛而谈的套话，而是一张带编号、带状态栏、带时间节点的可直接复制进 Jira 的表格；更关键的是，它没把“客户反馈”误读成“客服反馈”，也没把“修复任务”自动降级成“优化建议”。那一刻我意识到：这次真不一样了。

Hy3 preview 不是又一个“能发”的模型，它是第一个让我愿意把它设为手机默认 AI 助手、在腾讯文档里全程开着、甚至主动把它嵌进自己工作流里的国产大模型。它不主打“单点碾压”，不靠某个 benchmark 分数博眼球，而是把力气花在刀刃上：让模型真正理解你模糊的意图、稳稳接住你没说全的上下文、在长链条任务里不掉链子、在真实产品里不拖后腿。它背后是 MoE 架构下 295B 总参数、仅 21B 激活参数的精巧设计，是 256K 上下文带来的“记忆纵深”，更是腾讯把模型塞进 CodeBuddy、WorkBuddy、AIPPT 等十多个真实业务场景里，用千万级用户行为数据反向打磨出来的工程化成果。如果你还在找一个“能写周报、能改简历、能聊两句”的玩具模型，Hy3 preview 可能有点“杀鸡用牛刀”；但如果你需要一个能帮你跑通完整工作流、能和你一起写代码、能驱动复杂 Agent、能在业务系统里稳定扛压的“数字同事”，那它就是目前国产阵营里最接近这个定义的选项。它不完美，但它的“不完美”是可控的、可预期的、可绕过的——这才是工程可用性的真正门槛。

2. 核心能力拆解：为什么这次“能用”不是营销话术，而是有硬指标支撑的工程事实

2.1 架构与性能：MoE 不是噱头，是实打实的“省力+提速”组合拳

很多人看到“MoE（Mixture of Experts）”第一反应是“哦，又是堆参数”，但 Hy3 preview 的 MoE 设计恰恰反其道而行之。它的总参数量高达 295B，但每次推理时，只有约 21B 参数被激活——这相当于一个拥有 295 个专家教授的智库，但每次只请其中 7-8 位最对口的专家来开会。这种设计带来的不是虚高的参数数字，而是三个可量化的工程收益：

第一是显存占用大幅降低。我在本地部署测试时，用 A100 40G 显卡跑 Hy3 preview 的 32K 上下文推理，显存峰值稳定在 32GB 左右；而同尺寸的 dense 架构模型（如某些 200B+ 的纯 dense 模型）在同样配置下，显存直接爆到 45GB 以上，根本无法启动。这意味着什么？意味着在腾讯内部，他们能把 Hy3 preview 部署在成本更低、更普及的 A10 显卡集群上，而不是必须依赖昂贵的 H100。成本降下来，服务稳定性才能提上去——这直接解释了为什么 CodeBuddy 里首 token 延迟能砍掉 54%。

第二是推理速度显著提升。MoE 的稀疏激活特性让计算集中在最相关的专家路径上。我在测试 SWE-Bench Verified 的一个中等难度任务（修复 Python 脚本中的并发 bug）时，Hy3 preview 平均 token 生成速度是 128 tokens/sec，而 Hy2.0 同样硬件下只有 63 tokens/sec。这不是小修小补，这是翻倍的吞吐效率。当 WorkBuddy 需要驱动 495 步的 Agent 工作流时，每一步的延迟节省下来，就是整个流程耗时缩短近一半（官方数据 47%）的底层原因。

第三是长上下文稳定性增强。MoE 的专家分工天然适合处理不同模态、不同粒度的信息。256K 上下文不是为了炫技，而是让模型在处理一份 50 页的产品需求文档 + 30 页的历史会议纪要 + 10 个相关 PR 链接时，能准确区分“当前需求变更点”、“历史已实现功能”、“待规避的技术坑”。我在测试 AIPPT 场景时，给它喂入一份含 127 张图表的 PDF 技术白皮书，让它生成 15 页 PPT，它不仅没丢掉关键数据点，连图表下方的脚注说明都准确复现到了对应幻灯片的备注区——这种对长文本结构的“空间感”，是 dense 模型靠简单扩大 context window 难以企及的。

提示：MoE 的优势不是无条件的。它对 prompt 的“路由引导”更敏感。比如问“Python 中如何用 asyncio 处理 HTTP 请求”，Hy3 preview 会精准激活“编程语言+异步IO”专家；但如果问“怎么让程序跑得快一点”，它可能调用“通用优化”专家，结果不如前者具体。所以，越明确的任务描述，越能激发 MoE 的优势——这其实是对使用者提出了更成熟的 prompt 工程要求，而非模型缺陷。

2.2 Agent 能力：从“能动”到“敢托付”的质变

当前所有大模型都在谈 Agent，但绝大多数还停留在“Demo 层面”：能调用一个天气 API，能搜索一次维基百科，就算完成任务。Hy3 preview 的 Agent 能力，核心突破在于任务链路的鲁棒性和失败恢复的智能性。它不是“做完就完”，而是“做不完就换路子”。

以我实测的“微旅程”网站生成任务为例（Q3），它需要完成：1）联网搜索小众旅行地图片；2）筛选符合“冷门+高质感”标准的图；3）撰写匹配的短故事；4）用 HTML/CSS/JS 搭建可访问的静态页面；5）确保页面在主流浏览器兼容。Hy2.0 在第 2 步就常因图片版权信息模糊而卡死，或在第 4 步生成一堆无法运行的 JS 错误代码。而 Hy3 preview 的处理逻辑是：

• 当图片搜索返回结果质量不高时，它不会硬着头皮选一张，而是主动发起二次搜索，关键词从“冰岛火山口”细化为“冰岛 Fjaðrárgljúfur 峡谷 无人机视角 无游客”；
• 当生成的 JS 代码在本地测试报错时，它不重写整段，而是定位到具体哪一行 DOM 操作失败，然后针对性修改事件绑定方式（比如把onclick改为addEventListener）；
• 最关键的是，它会在最终交付物里自动生成一份 README.md，清晰列出：“已测试浏览器：Chrome 124, Edge 124, Safari 17.5；未测试：Firefox（因 WebKit 兼容性策略）；已知限制：图片懒加载在 Safari 下需手动触发”。

这种“知道边界、懂得妥协、留好退路”的能力，正是工程化 Agent 的灵魂。它让模型从“执行者”升级为“项目协作者”。腾讯在 CodeBuddy 里宣称的“成功率 99.99%+”，不是指单次 API 调用成功，而是指一个包含 10+ 步骤、涉及 3+ 外部工具调用、持续 5 分钟以上的完整开发任务流，99.99% 的概率能交付一个可运行的最小可行产物。这个数字背后，是无数次失败 case 的回溯分析、是针对每个工具 API 的容错封装、是预设的 fallback 策略库——这些，才是 Hy3 preview 真正的“护城河”，远比一个 SWE-Bench 分数实在得多。

2.3 内容生成：从“语法正确”到“语境精准”的跃迁

Hy3 preview 在写作类任务上的提升，最直观的感受是“它开始懂人话了”。以前的模型，哪怕参数再大，也像一个刚毕业、背了一肚子范文但没进过职场的实习生：语法满分，但写的邮件让老板皱眉，写的方案让技术同事看不懂，写的文案让市场部觉得“不够味儿”。

Hy3 preview 的突破，在于它对语境颗粒度的把握。我们来看几个实测对比：

这种进步，源于腾讯对“人味儿”的刻意训练。他们在训练数据中，大量注入了真实职场沟通语料（脱敏后的内部会议记录、PR 评论、跨部门协作邮件）、中文互联网优质创作（豆瓣高分影评、知乎深度回答、公众号爆款长文），并用强化学习（RLHF）让模型学会判断：“这句话说出来，对方是会觉得被尊重，还是被敷衍？”、“这个比喻，是让人秒懂，还是更迷糊？”。它不再追求“字数多”，而是追求“信息密度高”；不再追求“词汇华丽”，而是追求“情绪传递准”。当你让它写“给咖啡烘焙坊官网的首页文案”，它输出的不是“精选全球优质生豆”，而是“每一颗豆子，都带着埃塞俄比亚古吉森林的晨露，和我们烘焙师凌晨四点的守候”——这就是“触感与手工美学”的具象化，不是设计师的指令，而是模型自己的理解。

3. 实操过程：四个典型任务的完整复现与关键参数解析

3.1 Q1：知识卡片网页生成——如何让模型“读懂”一个技术网页并结构化输出

任务目标：总结 https://hy.tencent.com/research/hy3 页面，生成可交互的知识卡片网页。

我的操作步骤与 Hy3 preview 的响应逻辑：

1. 初始 Prompt 设计：我没有直接粘贴 URL，而是先给模型一个清晰的“角色设定”和“输出契约”：

   “你是一个资深前端架构师，正在为技术团队制作一份混元 Hy3 的快速入门知识卡片。请访问 https://hy.tencent.com/research/hy3 ，提取以下核心信息：a) 模型核心架构（MoE 相关参数、激活机制）；b) 关键性能指标（上下文长度、推理延迟、Agent 成功率）；c) 已接入的 5 个重点产品（需写明具体场景，如‘腾讯文档-AIPPT’）；d) 三个最具代表性的 Benchmark 测试结果（SWE-Bench、Terminal-Bench、BrowseComp）。输出格式：一个完整的 HTML 文件，包含 CSS 样式（使用 Tailwind CSS CDN），卡片采用网格布局，每个信息块可点击展开详情，鼠标悬停有平滑缩放动画。”

2. Hy3 preview 的执行过程：

   • 它首先调用内置的网页抓取模块，获取页面 HTML（注意：它不依赖外部浏览器，而是有专用的轻量级渲染引擎）；
   • 对抓取内容进行 DOM 解析，跳过所有导航栏、页脚、广告位等非主体内容，聚焦于<main>和<article>区域；
   • 识别出关键数据点：在“Technical Specifications”章节找到“295B total parameters, 21B activated”，在“Performance”章节定位到“256K context”，在“Product Integration”列表中提取出“CodeBuddy (code generation), WorkBuddy (task automation), AIPPT (presentation creation)”等；
   • 最关键的一步：它没有机械复制原文，而是进行信息蒸馏。例如，原文写“SWE-Bench Verified score: 42.7%”，它会补充说明“较 Hy2.0 提升 18.3%，在开源模型中位列前三”（这个对比数据是它从训练时注入的 benchmark 数据库中调取的）；
   • 最后，它生成的 HTML 不是静态的，而是嵌入了 JavaScript：点击“架构”卡片，动态加载 MoE 原理的简明图解（SVG）；点击“Benchmark”，弹出一个可排序的表格，按“测试项/得分/对比模型”三列展示。

实测效果与参数选择依据：

• 生成耗时：8.2 秒（Hy2.0 同样任务平均 22 秒）；
• 信息准确率：100%（所有参数、产品名、测试名均与官网一致）；
• 交互体验：CSS 动画流畅，无 JS 报错，移动端适配良好；
• 为什么用 Tailwind CDN 而不是原生 CSS？因为 Hy3 preview 的前端模板库中，Tailwind 是预编译的“高频组件包”，调用它比手写 CSS 快 3 倍，且兼容性经过腾讯内部千款应用验证。这是它“工程思维”的体现——不追求技术炫技，只选最稳最快的路。

注意：此任务对网络权限有要求。Hy3 preview 默认开启安全沙箱，首次访问外网需在元宝 App 设置中手动授权“网页内容读取”。未授权时，它会明确提示：“检测到您未开启网页访问权限，我将基于您提供的文字摘要为您生成卡片”，并给出一个备用方案——这种“有备无患”的设计，正是可用性的基石。

3.2 Q2：3D 地球绘画——当模型开始理解“空间感”与“交互意图”

任务目标：用 Three.js 和 JavaScript 创建一个 3D 地球，标记“我去过的地方”，点击标记触发缩放动画并显示照片。

Hy3 preview 的独特处理方式：

与 Hy2.0 直接堆砌 Three.js 示例代码不同，Hy3 preview 的响应分为三个层次：

第一层：环境与依赖确认它没有一上来就写代码，而是先问：“请问您希望地球使用真实卫星纹理，还是风格化插画纹理？您是否有已准备好的地点坐标（经纬度）和对应照片 URL？如果没有，我可以为您生成一组示例数据。” —— 这是在确认任务的输入完备性，避免后续因数据缺失导致代码无法运行。

第二层：模块化代码生成它生成的不是一个 giant.js 文件，而是四个清晰分离的模块：

• earth-core.js：封装地球创建、光照、旋转控制（使用 OrbitControls）；
• marker-system.js：管理标记的添加、点击事件、动画（GSAP 驱动的缩放+位移）；
• >// 使用 Three.js 的 Vector3 计算相机目标点 const targetPoint = new THREE.Vector3(); targetPoint.fromArray([marker.position.x, marker.position.y, marker.position.z]); // 计算相机当前位置到目标点的向量 const cameraToTarget = new THREE.Vector3().subVectors(targetPoint, camera.position); // 平滑移动相机，同时调整 fov 实现“镜头推近”感 gsap.to(camera.position, { x: targetPoint.x, y: targetPoint.y, z: targetPoint.z, duration: 1.2, ease: "power2.inOut" }); gsap.to(camera, { fov: 45, // 从默认 60 度缩小，模拟长焦镜头 duration: 1.2, onUpdate: () => camera.updateProjectionMatrix() });

  这段代码体现了它对 Three.js 渲染管线的深度理解：不是单纯改变物体大小，而是模拟真实摄像机运动，让交互有“电影感”。我实测在 Chrome 和 Safari 上，动画丝滑无卡顿。

  实操心得：如果你想快速上手，直接复制它的>