Hy4 preview 770B MoE 开源发布：MoE 架构原理与 WorkBuddy 实战指南

1. 这件事到底有多大Hy4 preview 发布的几个关键信号后台和社群里这两天问得最多的一件事就是 Hy4 preview 的发布。我盯着那个 770B MoE 的参数看了好一会儿又去翻了发布页和模型卡再结合 WorkBuddy 限时两周免费这个动作说实话这次发布不是一个普通的大模型版本迭代它是一次把“开源模型的天花板”往上顶了一截的尝试。先给还没跟上的朋友把信息同步一下Hy4 preview 是一个 770B 参数总量、采用 MoEMixture of Experts混合专家架构的大模型官方以开源的形式放出了 preview 版本可以理解为“预览版”。同时官方团队把配套的WorkBuddy拿出来做了限时两周的免费开放它是一个围绕大模型能力做任务编排和工具调用的工作台产品。为什么要先说“不是普通迭代”因为 770B 这个量级放在开源阵营里属于头部梯队。你去看目前市面上大多数能跑起来的开源模型总量一般在 7B 到 70B 之间100B 以上已经不多见能做到几百 B 还愿意开源的掰着手指头数得过来。而 MoE 架构又恰恰决定了参数总量大不等于推理开销大。这是一个对开发者非常友好的结构。我个人的判断是这次发布的本质有两个一是把开源模型的能力上限拉高让社区可以研究和使用接近闭源头部模型量级的权重二是通过 WorkBuddy 把大模型从“聊天窗口”里拽出来往“干活工具”的方向推了一把。两件事叠加起来价值就不是简单的“又出了一个模型”能概括的。那这篇文章我打算聊得细一点从 MoE 架构到底解决了什么到 770B 这个数字的实际意义再到 WorkBuddy 到底能做什么、怎么用以及它和 CodeBuddy 的区别最后是部署层面的实操经验和避坑建议。内容有点长但每一段都是干货你可以按需跳读。2. 770B MoE 是什么水平聊 MoE 架构前必须先看懂这几个底层逻辑2.1 从密集模型到 MoE为什么参数越多越好但不能无限堆要理解 Hy4 preview 的 770B MoE 是什么水平得先理解传统模型为什么不能无脑堆参数。以 GPT 系列为代表的早期大模型走的是 Dense密集路线每一层网络在处理每一个 token可以理解为文本的最小单位时所有参数都会被激活。也就是说你有一个 70B 的密集模型无论你输入的是“今天天气怎么样”还是“写一个分布式系统设计方案”模型内部的 700 多亿个参数全部参与计算。密集模型的优点是训练相对稳定推理逻辑简单缺点也非常明显成本高、效率低。你查个天气也要把 700 亿参数全部跑一遍这在算力上太浪费了。这也是为什么早期百亿参数的模型训练和推理都贵得吓人一般团队根本玩不转。MoE 的想法正好打破了这种“全员参与”的模式。它的核心思路是在一个大模型内部拆出若干个“专家”Expert每个专家其实就是一个参数子网络。当输入一个 token 时会有一个“路由器”Router/Gating Network来决定把这个 token 分发给哪几个最擅长的专家处理而不是所有专家都动起来。我打个比方你就明白了。传统密集模型像一家餐厅只雇了一个全能厨师不管顾客点川菜、粤菜还是甜品都让这个厨师做。MoE 则是开了一家后厨里面有大厨、面点师、凉菜师傅顾客点单后由服务员路由器判断应该让谁来做。这样做的好处是每个 token 只触发一小部分专家计算量被控制住了但模型的总参数量可以做得很大知识容量也更大。Hy4 preview 那 770B 就是“总参数量”包括所有专家的参数加在一起的总和。而真正推理时每个 token 会激活的参数量远小于这个数字。这也是为什么 770B 听上去很吓人但实际上并不是只有超大集群才能跑得动。2.2 MoE 的关键指标激活参数、专家路由和负载均衡聊 MoE 不能光看总量更要看三个关键指标。第一个是激活参数量Active Parameters。比如有的模型总参数 770B但激活参数可能只有 30B 到 50B 左右这意味着它的推理效率和 30B 到 50B 的密集模型在一个量级上但知识储备和表达能力又远超同激活量的密集模型。这是 MoE 最“占便宜”的地方。第二个是专家路由策略。路由器怎么决定 token 去哪个专家常见的选 Top-K比如 Top-2 就是让 token 去得分最高的两个专家。路由策略直接影响模型推理质量和负载均衡。做得不好会出现“路由崩溃”——所有的 token 都涌到同一个专家那里其他专家闲着计算效率反而下降。第三个是负载均衡损失Load Balance Loss。训练 MoE 模型时会额外加入一个 loss用来约束各个专家的使用率尽量均匀。没有这个约束模型会“偷懒”只练几个专家其他专家形同虚设整个 MoE 结构就失去了意义。Hy4 preview 作为头部的开源 MoE 模型这些方面做得到底好不好还需要社区实测验证。但有一个信号是积极的选择 MoE 架构本身说明团队想明白了“大而全”和“跑得起”之间的平衡。这也是 2025 年以来开源大模型的一个明确趋势从 Mistral 的 Mixtral 系列到 DeepSeek 的 MoE 路线头部开源模型基本都在向 MoE 靠拢。2.3 770B 在开源阵营里属于什么梯队横向对比一下我拿几个已经开源的模型做一个粗略的对比因为我看到搜索热词里也有人提到“gemma4 26b a4b moe部署教程”说明大家确实在关注不同量级 MoE 的部署差异。模型总参数量架构激活参数适合场景Gemma 系列 26B A4B约 26BMoE约 4B消费级显卡、端侧部署Mixtral 8x7B约 47BMoE约 13B单卡/双卡推理DeepSeek 系列数百 B 级别MoE数十 B云端/集群部署Hy4 preview770BMoE待实测确认多卡集群、企业级应用这么一看就很清晰了。Hy4 preview 的 770B 在开源模型里属于“巨无霸”级别它不是给普通个人电脑准备的而是给有 GPU 集群、有云资源、有企业级需求的团队准备的。对于个人开发者更务实的路径是先通过 WorkBuddy 这样的工作台产品去体验它的能力而不是一上来就折腾本地部署。3. Hy4 preview 的核心能力与亮点除了参数大还有什么值得关注3.1 预训练与知识广度大参数的底气在哪里作为一个 770B 参数的模型Hy4 preview 最直观的优势是知识容量。大模型的“知识”不是像数据库那样存储一行行的记录而是把训练语料中的模式压缩到参数中。参数量越大能容纳的模式就越复杂、越精细。大参数带来的最直接表现有三个长尾知识的记忆更强。比如一些冷门的专业名词、生僻的历史事件、特定行业的技术细节小模型往往会“胡编乱造”大模型有更高的概率给出准确回应。复杂推理的路径更长。数学题、代码调试、逻辑分析这类任务需要模型在多步推理中不“丢上下文”。参数量大的模型更容易保持推理的连贯性。风格模仿和指令遵循更稳。无论你是要求它写一封正式邮件还是模仿某位作家的文风大模型对指令边界的把握都更细腻。我在 WorkBuddy 里试过让它拆解一个多步骤的业务流程它不只是给出一二三四步还会主动指出每一步的前置条件和可能的失败点。这种“全局视角”的能力确实是小参数模型很难做到的。3.2 推理与生成质量关键看这几个维度的实测表现光说参数没意思我来分享一些实际体验下来的感受。目前我接触到的关于 Hy4 preview 的反馈主要集中在五个维度。指令遵循这点让我印象比较深。你给它一个限定格式的要求比如“只输出 JSON不要任何解释”它能严格遵守不会像有些小模型那样“忍不住”添一句“好的以下是您需要的 JSON”。对于做开发的人来说这个细节特别重要因为你的解析脚本不会容忍多余的文字。上下文窗口长文处理能力可以直接影响“它能不能读完你的代码库/文档库”。Hy4 preview 的上下文支持处于当前头部模型的正常水准如果你有非常长的材料要处理把这个因素纳入考量即可具体数值建议查询当前最新的模型卡。代码生成从我目前的试用感受看它的代码生成质量在同级别开源模型里是能打的能理解复杂需求并产出架构相对清晰的代码。数学和逻辑推理多步推理能力明显比小模型强但对于非常复杂的数学题仍然建议验证不建议盲信。多语种支持中文表达能力包括成语、俗语、网络梗的运用保留了大厂模型的水准。以上几点的具体表现等 open source 社区放出更详细的评测后可以做进一步验证我的建议是如果你有特别的业务场景一定要自己实测因为评测数据是别人的业务是你在跑的。3.3 开源意味着什么权重开放玩法彻底变了“开源”这两个字在 Hy4 preview 这个项目里的分量非常重。一个 770B 的模型愿意把权重开放出来至少有四层意义。第一层研究价值。学术界和工业界的团队可以拿到真正的百 B 级 MoE 模型进行剖析专家是怎么分工的路由器学到了什么不同层的表征有什么差异这些研究以前只能闭门做现在有了公开的样本。第二层微调和私有化部署。企业可以把模型权重下载下来在自有数据上进行继续预训练或者指令微调。数据不出域合规压力小这个特别适合金融、医疗、政务等场景。第三层社区生态。开源模型会带动一批周边工具链的繁荣比如量化工具、推理框架适配、部署文档、LoRA 微调教程。这就像 Linux 的开源让整个生态都活了起来。第四层透明度。相比闭源 API开源模型让用户有机会检查它的行为边界进行更好的安全控制。当然开源也意味着“你自己负责”。你需要自己解决部署环境、性能优化、稳定性保障等一堆问题。这也是为什么 WorkBuddy 这样的工具产品在开源模型生态里会越来越重要。4. WorkBuddy 到底解决什么问题从“能聊天”到“能干活”的关键一跃4.1 WorkBuddy 是什么和 CodeBuddy 有什么本质区别很多人看到 WorkBuddy 的第一反应是这是不是一个类似 CodeBuddy 的编程助手我一开始也是这么想的实际研究下来发现两者的定位有明显差异。从产品形态来看WorkBuddy 不是一个单纯的聊天机器人也不是一个只服务于程序员的代码工具它更像一个**“模型能力调度中心”**。你可以把不同的大模型、不同的工具、不同的业务流程都接入到一个统一的工作台里然后通过自然语言去编排它们让它帮你完成一个完整的任务而不仅仅是“回答一个问题”。我特意把 WorkBuddy 和 CodeBuddy 的区别整理成了一个表格方便你对照理解维度WorkBuddyCodeBuddy核心定位通用工作台任务编排和工具调用编程助手聚焦代码场景侧重点跨工具、跨流程的工作流自动化代码生成、补全、解释、调试适用人群运营、产品、分析师、开发者等主要面向开发者典型用法“把这份数据和模板合并成周报”“给这个函数写单元测试”协作方式串联多个工具/模型专注 IDE 或命令行内的编程场景WorkBuddy 更像是一个“会使用其他软件的人”CodeBuddy 更像是一个“写代码特别快的同事”。两者的关系不是替代而是互补。4.2 WorkBuddy 的核心能力拆解Tool Use 是怎么实现的WorkBuddy 最核心的技术亮点我理解是 Tool Use 和任务编排。所谓 Tool Use通俗讲就是模型不只是“说话”它还能“动手”。当你问它“帮我查一下本月的销售数据并做成图表”传统聊天机器人只能给你一段文字建议告诉你步骤是什么。而 WorkBuddy 的 WorkBuddy Skill 机制可以让模型调用真实的数据查询工具、图表生成工具自己去执行这些步骤最后把做好的图直接给你。实现这个功能的技术流程大致是这样的用户在对话中提出一个含明确目标的请求。模型解析请求识别出需要哪些工具参与。模型输出结构化的工具调用指令通常是一个 JSON 格式的 API 请求。工作台调度器执行工具调用把结果返回给模型。模型结合工具输出生成最终文本回复。这个机制在技术上已经不新鲜OpenAI 的 Function Calling、Anthropic 的 Tool Use 都做了类似的事。但 WorkBuddy 把这一步产品化了让非开发者也能通过自然语言完成任务这是一个体验层面的优势。4.3 限时免费两周这件事我的真实看法官方给出的 WorkBuddy 限时两周免费这个动作不只是一次促销更是一个信号模型再强如果用户不知道怎么用它干活价值就兑现不了。趁 Hy4 preview 发布的热度把工作台产品一起推出来让用户体验“大模型任务编排”的完整闭环这个玩法是经过深思熟虑的。对于还没试过 WorkBuddy 的朋友我的建议是别浪费这两周认真把它当成一个“试用期”来规划。第一周先用小任务把它的交互逻辑摸熟第二周把一个真实的、完整的业务任务交给它跑一遍。等免费期结束你就能做出相对准确的判断——它到底值不值得付费。5. 从 WorkBuddy 到本地部署开发者的实操路线图5.1 最省事的上手途径先用 WorkBuddy 跑通体验闭环如果你只是想快速验证 Hy4 preview 的能力我个人建议先用 WorkBuddy而不是一上来就搞本地部署。原因很简单770B 的模型本地部署门槛高硬件投入大先用工作台产品把场景跑通再评估是否有必要私有化是性价比最高的路径。WorkBuddy 怎么使用实际流程并不复杂大体的步骤是通过官方渠道进入 WorkBuddy 的工作台创建或进入一个任务空间在对话区用自然语言描述你的需求并明确指定希望使用的工作流。根据我的试用体验它是支持配置多个模型后端的不同的任务可以切换不同的模型。试用的时候有几点是值得留意的先把任务写成“输入什么、希望输出什么”的格式不要上来就说“帮我处理一下数据”模型能理解目标但明确的指令会让它的表现更稳定。如果涉及工具调用先确认工具是否已经在工作台里配置好。没有配置的话从文档里找到导入或注册的方式。拿到输出后别急着结束多追问几个为什么。工作台的编排能力会在多轮交互中表现得更清楚。5.2 本地部署 770B MoE 的三条路线和硬件需求估算如果你确实有本地部署的需求或者你想研究模型权重本身那就要认真评估硬件了。我直接说结论770B 的模型哪怕是 INT4 量化个人单机也非常吃力多卡集群是企业级的玩法。先说第一条路线消费级/半专业级硬件跑量化小模型。如果把 Hy4 preview 量化到 INT4权重大约在 385GB 到 400GB 之间。你可以用多张 24GB 显存的显卡比如 RTX 4090、RTX 3090至少需要 16 到 20 张才能完整放下。这个方案适合预算充足的工作室或小型团队。第二条路线云 GPU 实例。租用多卡 A100/H100 实例内存带宽和显存容量都有保障。好处是不用一次性投入几百万买硬件按小时付费用完即走。缺点是长期使用成本不低。第三条路线CPU 推理 大内存。如果你只是想跑通验证不要求高吞吐可以用大内存机器做 CPU 推理。770B 的模型用 8bit 量化大约需要 800GB 内存加载到内存后推理速度会比较慢但确实能跑起来。所以我的建议很明确个人开发者先不要想着本地部署 770B先用 WorkBuddy 或者其他 API 服务体验能力等真正有业务场景、有预算支撑再考虑集群部署。我看到热搜词里有“gemma4 26b a4b moe部署教程”如果你就是想学习 MoE 模型的部署建议从这种二三十 B 的小 MoE 入手性价比和可操作性会好很多。5.3 部署 MoE 模型时的关键避坑点如果你已经在部署 MoE 模型实际上是通用的 MoE 部署经验有几个坑我踩过也看到很多网友踩过在这里可以帮你避开第一显存不够时要考虑 CPU offload但要控制 offload 的比例。全部 offload 会导致推理速度慢到无法接受完全不 offload 又放不下。一般建议先把模型量化到能放进显存的最低精度再用少量 offload 兜底。第二注意专家的显存分布。MoE 模型的专家分布在不同层如果推理框架对专家并行支持不好会出现部分 GPU 显存占用畸高、部分 GPU 闲置的情况。第三量化要谨慎。不是所有量化方法都适合 MoE。MoE 的专家对量化误差更敏感特别是路由层的量化精度对整体效果影响很大。建议优先选择社区口碑好的量化方法。第四推理框架的选择很关键。不同的推理框架对 MoE 的支持程度差别很大部分老牌框架对 MoE 的支持是通过“模拟”实现的效率损失严重选择时要注意确认其对 MoE 的原生支持情况关注其调度策略。6. 关于这次发布的综合盘点值不值得跟进以及怎么跟进6.1 值得关注的三个核心问题顺着这次 Hy4 preview 发布我整理了三个值得持续关注的问题你可以把它们当作观察方向。第一个问题770B MoE 的实际推理表现和闭源头部模型差距还有多大。开源模型发布是一回事跑起来能不能真正对标闭源 API是另一回事。需要等更多第三方评测。第二个问题WorkBuddy 的两周免费期能沉淀多少真实用户。限时免费是一个强力的拉新手段但留存最终靠的是产品价值。如果两周体验期后用户发现工作台确实能提高效率留存就不是问题。第三个问题开源生态会不会围绕 Hy4 preview 长出一套工具链。模型权重开源只是第一步后续的微调方案、量化工具、部署教程、周边插件才决定了它能走多远。6.2 不同角色的应对建议如果你是开发者我的建议是这周就把 WorkBuddy 注册了用真实的工作流任务去测试它特别是 Tool Use 类的任务。别只是让它写周报试试让它在你的知识库/数据库/API 环境中完成一个可复用的自动化流程这样你就能看出它的真实上限。如果你是技术决策者我的建议是保持观察但可以先选一个非关键的内部场景做试点。770B 开源模型的潜力很大但在你的业务上能不能稳定落地要小步快跑别一上来就搞大迁移。如果你只是对 AI 大模型感兴趣但不懂技术我也建议你试试 WorkBuddy。它能让你直观地感受到大模型“干活”是什么体验比看一百篇评测文章都有用。7. 我的个人体会这次发布让我比较兴奋的一点说了这么多最后分享一点个人感受。做了这么多年 AI 相关的技术观察一个很明显的感觉是开源的漏斗正在张大。几年前开源模型的量级在几十亿参数社区只能用“能用但不要有太高期待”来形容后来到了几十 B再到几百 BMoE 架构让大参数量和可控的推理成本第一次同时成立。Hy4 preview 把 770B 这个数字带进了开源阵营它的意义不在于每个人都能跑起来而在于它给整个生态划了一条新的起跑线。我对 WorkBuddy 免费两周的看法也是正面的。因为模型再强如果只停留在 API 和权重这两个层面很多普通用户是感知不到的。一个能把模型能力变成实际产物的工具比模型本身更容易让大众理解大模型的价值。如果你此前对大模型的理解还停留在“聊天机器人”那强烈建议你抓住这两周时间去试试 WorkBuddy找一个你工作中最繁琐的任务交给它跑一遍。不用管底层是什么架构、参数量多少你就看它有没有把活给你干成。干成了这就是效率工具没干成你就当积累了一次产品体验样本。两种结果都不亏。