770B MoE开源权重实测解读：Hy4 preview部署成本与WorkBuddy免费期用法

发布消息出来那天晚上，我群里其实没怎么炸，大家刷到“770B MoE 开源”第一反应都是：又一个堆参数的大模型。隔了几个小时，等有人真的把权重仓库打开、跑通下载，又看到 WorkBuddy 跟着放了两周免费用窗口，讨论才慢慢变多。我前两天把公开资料和技术文档认真翻了一遍，也在本地环境里做了一些可行性验证，这篇想把重点从“770B这个数字大不大”移到更值得想的问题上：Hy4 preview 这次开源到底把什么门槛拉下来了，MoE 架构的部署账怎么算，以及 WorkBuddy 这种工具在限时免费期究竟该怎么用才算没白薅这个羊毛。

1. Hy4 preview 这次发布，真正该被注意的不是那串参数

坦白讲，如果只看“770B MoE 开源”这七个字，我会把它归类到“年度大模型日常发布”那一档，信息量是不够的。真正耐看的是配套动作：权重第一时间给到了开源方向，不再只是 API 灰度开放一个外壳；模型版本又带了 preview 后缀，说明发布方自己很清楚能力边界还需要社区测试来补充；旁边还挂着一个限时两周免费的 WorkBuddy，让工具、模型和工作流一口气打通。这种发布结构比单一模型开源要复杂得多。

1.1 开源权重和“开放使用”是两码事

行业里聊“开源模型”时经常有个口误，把能用 API 调一个模型说成“这个模型开源了”。实际上很多厂商只是开放服务入口，用户拿不到权重，也就谈不上私有化部署、二次微调和离线推理。Hy4 preview 这次放出来的应该是真正的模型权重，这意味着三件以往 API 模式给不了的事情发生了。

第一是数据隐私的边界重置。走 API 时，所有 Prompt 和生成结果都要经过远端服务链路，企业内部数据出不出网是一个硬问题；拿到权重之后，至少可以在自己可管控的算力环境里运行，哪些日志该留、哪些该清，规则由自己定。第二是成本结构变了。API 按 Token 计费，用多了是持续性的运营成本；自托管则变成一次性硬件投入加电费，适合长期高频、单次请求量很大的场景。第三是社区可以介入模型本身做适配，甚至能对推理栈做针对性优化，不再只能等在官方接口后面。

但也要冷静一点：权重开放不等于零门槛把模型跑起来，尤其是这种级别的参数规模，硬件账单会立刻告诉你什么叫“开源不等于免费”。这一点我在后文会专门算一笔账。

1.2 preview 后缀藏着模型迭代的节奏感

“preview”不是随便贴的标签。很多团队习惯把做了一半的模型包装成完整版，拿用户当测试员还不发测试工资。Hy4 preview 的表述算比较诚实：它承认现阶段模型存在已知盲区，希望社区在真实场景里跑，然后把这些行为反馈带回下一代训练迭代里。

这种发布节奏其实是被开发者和企业用户反向逼出来的。过去大家只关心榜单分数，真正把模型嵌到业务流程里之后才发现，评测集里的高光时刻远不如真实场景里的稳定输出重要。preview 版本的定位就是让那批愿意尝鲜、也愿意写反馈的用户先跑起来，把模型的可控性、指令理解边界和长文本处理短板暴露清楚。模型的完整形态可能要等后续版本，现在这版更像是官方和社区一起校准方向的中间态。

1.3 WorkBuddy 限时免费放在同一张公告里，是产品逻辑不是营销彩蛋

如果 WorkBuddy 是独立团队做的独立产品，大概率不会选择在模型发布当天悄悄挂两周免费，这种动作一般是配合一个大事件去推的。所以在我的理解里，WorkBuddy 和 Hy4 preview 的关系是：大模型负责底层智能，WorkBuddy 负责把智能编排成可以被办公场景直接调用的工作流。

对普通用户来说，模型开源的信息价值再大，也得先解决“我拿它来干嘛”的问题。WorkBuddy 在这个时候免费，给的就是一个低成本的验证通道：你不需要先搭建一套大模型部署环境，也不需要会写代码调用接口，直接在图形界面里验证“这个能力组合到底能不能帮我办事”。两周时间刚好够完成一轮真实试用，判断要不要在正式版上投入，这就是它比三天试用有价值的地方。

2. 770B MoE 到底是怎么算账的：聊清楚总参数与激活参数

很多人对“770B MoE”的理解是“一个 7700 亿参数的大模型，肯定需要天文数字级别的算力”。这个判断一半对一半错，主要错在没用 MoE（混合专家）的算账方式去思考问题。MoE 这个架构的精髓从来不是把模型做大，而是在参数总量和单次推理算力之间做一个聪明的解耦。

2.1 总参数不是每次计算都要全部激活的

传统的稠密（Dense）模型，比如大家熟悉的常规 Transformer，每一次生成 Token，理论上模型的全部参数都得参与计算。也就是说你拉一个 70B 的稠密模型做推理，70B 个参数每一层都要跑一遍，算力开销和参数量是严格正比的。

MoE 的设计思路完全不同。它把传统 Transformer 里单一的 Feed-Forward Network 拆成很多个“专家”子网络，每个 Token 进来之后，先经过一个路由判断模块，决定由哪几个专家来处理。所以 MoE 模型虽然有 770B 总参数，但单个 Token 推理时只激活其中一小部分专家。这里就引出了两个关键概念：

• 总参数（Total Parameters）：模型文件里所有权重加起来有多少，决定存储空间和加载时的显存下限。
• 激活参数（Active Parameters）：生成每个 Token 时实际参与计算的参数量，决定推理速度和计算成本。

打个比方，稠密模型像一个餐厅里只有一位全能大厨，不管什么菜都得他一个人做；MoE 则像一个后厨有几十位专职厨师，红烧肉来了叫负责荤菜的两位师傅，蔬菜沙拉来了叫负责素菜的那几位。后厨的团队规模很大、人力成本很高，但做一道菜只需要其中几个人上手。这个“做一道菜要几个人”就是激活参数。

一般 MoE 模型会在 FFN 层做专家路由，比如采用 Top-2 路由策略，每个 Token 只激活两个专家。为了让问题容易理解，我做一个极简的示意计算：假设某个 MoE 层的 FFN 里共有 128 位专家，每位专家参数量是 1B，路由选取 2 位，那么这层 FFN 的激活参数量就从 128B 降到了 2B。真实模型的细节会更复杂，还会有共享专家和 attention 部分，但核心逻辑大致相同。所以 770B 总参数模型的推理算力消耗远达不到 770B 稠密模型的级别，这也是稀疏化方向这几年快速发展的原因。

2.2 路由策略不是装饰模块，它决定模型能力的上限

MoE 最容易被低估的模块是路由网络（Router）。很多人以为它只是做个简单分类，实际上训练一个 770B 级别的 MoE，60% 以上的训练难度都集中在路由的把控上。

路由要解决的核心问题有两个。第一是负载均衡。如果大部分 Token 都涌向同一个专家，其他专家长期闲置，那 MoE 架构就退化成局部稠密模型，算力优势消失殆尽。训练时通常要加辅助损失函数，鼓励 Token 在各个专家间尽量均匀分布，避免“几个专家累死、几十个专家闲死”。第二是专家分化。我们希望不同专家能自然形成不同的能力侧重，而不是大家学得都一样。如果路由最终学出来的结果是随机分配，那 MoE 还不如一个等参数量的稠密模型。

关于专家分化，经常有人问一个很业余的问题：是不是有一个“数学专家”和一个“代码专家”？现实中没有这么贴标签式的分工。专家的分化是在高维语义空间里的自然聚类，往往是隐性的，可能一个专家特别擅长处理某种句法结构，另一个专家更适应某些推理链条。不能用人的视角去预期它。

理解了路由，你也就理解了为什么 MoE 模型在低并发场景下的表现会打折扣。如果服务端同时只有一个请求，路由再聪明，每次激活的专家数就那么多，很多专家依然处于闲置状态；当服务端同时处理几十个请求，不同 Token 来自不同上下文，路由可以把请求分散到不同专家上，硬件利用率才会真正上来。这也是为什么很多 MoE 模型部署上线时会强调高并发和连续批处理的重要性。

2.3 显存账单与计算账单要分开看

我刚才说 MoE 能降低单 Token 的计算成本，但这里必须说清楚一个大多数人踩过认知坑的地方：MoE 模型加载时依然需要把全部专家权重放进显存或内存，不能因为这个 Token 只用了两个专家，就只加载两个专家的权重。权重是静态存储的，推理时段的计算是动态调度的，两者维度不同。

算一笔最简单的存储账。770B 总参数如果用 bf16 精度存储，每个参数占 2 字节，那么光权重文件就是 770 × 2 = 1540GB，约 1.5TB；如果用 4bit 量化，每个参数约 0.5 字节，权重总量降到 385GB 左右，但这只是让模型塞进显存的下限，还没算 KV Cache、中间激活值和路由计算的开销。

这说明什么？对一个动辄几十 GB 显存的 MoE 模型，个人开发者手里一张 24GB 的消费级显卡基本没有招架之力。即便量化后勉强放入内存，推理速度也会慢到没法实际使用。770B MoE 的“单 Token 推理省算力”优势，必须在集群级别的并行部署里才能充分体现；它降低的是单次推理的 GPU 计算时长，不是整个推理服务的硬件门槛。所以真正适合这种模型的用户，是本来就有多卡集群或者计划采购推理服务器的人，而不是想在笔记本上跑个 demo 的尝鲜者。

3. 想实际部署这种 MoE，哪些步骤值得参考

既然权重开源了，接下来大家最关心的通常都是怎么跑起来。我在本地和云端都做过一些 MoE 模型的部署验证，这一节把思路整理成一个更通用的路线，不只针对某个工具，而是帮你避掉部署中的常见坑。

3.1 动手前先清理一下自己的期望值

先把问题摆到桌面上：你没有足够的显存，就别说“部署 770B”。按照前面的大致估算，不量化的情况下需要 1.5TB 左右的存储容量，常见做法是至少准备 8 张 80GB 显存的加速卡，或者用多机方案把模型切到多台机器上。如果你手里只有单张消费级显卡，我只能很直白地说，这条路在本地玩不通，理性的方式是通过云端托管 API 直接把模型用起来。

另一种折中思路是用较高倍数的量化大幅压缩权重，比如 2bit 级别的量化可以把总量压到 200GB 以下，再配合 CPU Offload，让显存不足的机器也能勉强运行。但这种方案的生成速度会明显受影响，而且 MoE 模型的低比特量化对路由专家分布更敏感，量化后模型输出质量可能出现肉眼可见的下降。我个人的看法是：如果你只是想验证业务效果，不要一开始就上低比特量化，先用完整精度版本去评估模型上限，再考虑为了成本能牺牲多少质量。

3.2 给具备集群条件用户的一套基础启动方法

这里分享一个比较通用的部署思路。拿到下载好的原始权重之后，通常会先用对应工具链把权重转换成推理框架能识别的格式，然后选择合适的并行策略。

一个典型的启动思路是这样的：

# 假设你已经把权重放到本地目录 /models/hy4-preview-moe # 启动一个兼容 OpenAI 接口的服务，使上层应用能够通过 HTTP 调用 python -m vllm.entrypoints.openai.api_server \ --model /models/hy4-preview-moe \ --tensor-parallel-size 8 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

几个参数含义拆开看：

• --tensor-parallel-size 8：指定 8 卡张量并行。对 MoE 模型来说，专家的权重会被切分到不同卡上，路由模块则需要在多卡之间做通信，这一步很关键，特别是批量请求里的每个 Token 可能路由到不同专家，跨卡通信开销直接影响吞吐。
• --max-model-len 8192：先不要急着把上下文长度拉到最大。MoE 模型的参数量大，上下文变长后 KV Cache 和调度复杂度都会上升。先用小上下文验证服务链路通了，再逐步放大，容易排查到底是模型问题、并行问题还是显存溢出问题。
• --gpu-memory-utilization 0.9：让框架尽量用完可用显存而不是预留太多。不过这个值不宜调到 0.98 以上，预留一点空间给推理框架自身的管理结构会更稳妥。

如果你用的是其他推理框架，流程也差不多：先转权重格式，再设置并行数，最后调上下文长度和显存利用率。关键在于，不要拿跑小模型的思路直接套，MoE 模型对批处理大小更敏感，小批量请求很难体现出多专家并行的优势，在压测时要刻意把并发请求数加大再观察吞吐曲线。

3.3 用“场景任务清单”代替榜单评测

模型部署好之后，怎么判断它到底行不行？我的建议是放弃盲目的跑分，改用跟你工作流强相关的任务清单。很多大模型评测基准已经出现饱和现象，排名差别很小，对真实业务指导意义有限。

建一套自己的评测清单其实不难，选十几个任务，每个任务写清输入、预期输出和评分点就行。我常用的任务分类如下表所示：

每一类任务跑三遍，观察输出的一致性。模型能力高低不是看它一次答得多惊艳，而是看它面对同一道题的三次不同表达里，关键逻辑是否始终一致。这一步耗时不长，但对后续是否要深入使用这个模型会有一个非常直观的判断。

3.4 部署过程中出现的高频问题

部署 MoE 模型最容易遇到的是显存溢出和速度远低于预期。显存溢出相对好排查，按我前面的估算先把权重压到合理范围，再逐步调上下文长度就能定位。生成速度慢则需要检查三个地方：第一，并发批处理是不是真正的多用户并发，而不是单请求压测；第二，张量并行切分是否合理，是否存在某张卡显存占用过高、其他卡闲置的情况；第三，量化精度是否过低导致 GPU 在做大量反量化计算，反而拖慢了速度。

还有一个容易被忽略的问题：低并发时的单 Token 延迟会比稠密模型高。原因在于 MoE 模型每生成一个 Token，路由模块要做一次专家选择，对应的专家权重要被激活，如果批量不够大，这些调度和通信开销没法被均摊，单位 Token 延迟自然显得高。缓解出路是把请求攒起来、做大动态批处理，而不是只发一个测试请求去判断模型快不快。

4. WorkBuddy 限时免费窗口期，重点试什么

从模型侧回到应用侧。标题里 WorkBuddy 限时两周免费，这个信息很多人的第一反应是“注册个账号再说”，然后就没有然后了。这种薅羊毛方式其实浪费了最关键的机会，因为你没有把工具真正放到自己的任务流里去检验。真正有效的做法是先想清楚：这个工具和普通聊天机器人有什么不同，我该在两周内试完哪些场景。

4.1 CodeBuddy 和 WorkBuddy 到底怎么分工

聊 WorkBuddy 前，不得不先扯一下 CodeBuddy。从热门讨论里能看到，“codebuddy和workbuddy区别”是很多人搜索的高频问题。我看了各种使用心得之后，逐渐形成一个比较清晰的理解：两者不是同一个工具的改名关系，而是针对不同任务形态做的两种产品。

CodeBuddy 的主场在开发流程。它更贴合已经写了很多代码的项目现场，能理解仓库结构、处理编译报错、做代码补全和重构建议，面向的是写代码的人。你给它一个需求，它可能直接改文件、跑测试、报结果，产出物是代码和在代码库上完成的操作。

WorkBuddy 则更靠近办公自动化和业务流程，面向的是“把事办完”的场景。它不一定只操作代码库，而是把模型能力编排进日常任务处理里，比如从零散材料里整理出结构化表格、按照既定模板生成网页页面、把多步操作固化成 Skill 以便后续反复复用。你可以把 CodeBuddy 想象成工地上的专业施工队，把 WorkBuddy 想象成能同时协调物料、排期、验收的项目经理，二者的工作重心不同。

我画一个不是特别严谨但便于理解的对照：

4.2 WorkBuddy Skill 机制是关键体验点

根据目前热词里反复出现的“workbuddy skill”和“workbuddy使用教程”，我判断 Skill 是 WorkBuddy 这套产品里最有深度的功能，也是评测它值不值得付费的核心观察点。

Skill 可以理解为一套写好的操作剧本。普通对话模式下，你每次都要从头把需求和背景说一遍；Skill 模式下，你把一个复杂任务拆成步骤，写清楚每个步骤的参数和判断条件，保存成技能，之后每次调用只需要给少量任务参数，工具会自动沿既定流程执行。

举例来说，如果你每周都要把一堆报销单照片按时间、金额、类别整理成表格，可以把“读取图片信息、识别金额、按类别归档、生成汇总表”固化成一条 Skill。第一次搭建 Skill 可能需要一些试错，但一旦跑通，后续每个星期就只是丢一批文件进去的事。免费期内试这个功能的思路，就是把那些平时重复做三次以上的工作挑出来，看 WorkBuddy 能不能帮你沉淀成可复用流程。如果它做不到，说明这个工具对你价值有限；如果它做到了，那省下的时间会非常直接。

4.3 两周时间我建议这样排布

两周听起来不短，但如果漫无目的地用，很可能到最后只是聊了几次天，完全没有触及 WorkBuddy 的核心能力。我的建议是按阶段做有目的的测试。

先花前三天熟悉基本操作。把工作里最高频的 3 个小任务放进去跑，比如整理一篇访谈记录、把一段数据描述转成 Markdown 表格、根据大纲生成一个静态页面原型。这时不要急着做复杂流程，先把工具的操作边界摸清楚。

第四天到第八天是核心测试期。挑选一个你真正每周都要做的完整任务，尝试把它拆解成 WorkBuddy Skill。记录三件事：搭建 Skill 花了多久、每次执行需要人工修正多少、相同产出此前人工做要多久。这三个数字直接决定免费期结束后你要不要付费。

最后三天不要做新实验，用来复盘。把前两周跑过的所有任务整理成一份报告，区分哪些是工具自带模板能做到的，哪些是你额外写 Prompt 或 Skill 才能完成的，哪些是根本做不了的。不管结果如何，这份报告本身就是你判断产品价值的依据。

4.4 使用边界要有意识

试用工具类产品时，还有一个常见风险是过度信任。我在实际使用这类工作流工具时，见过不少翻车案例：工具把报销表格金额搞错一位小数点、把网页文案里的关键产品名写错还一键输出，人在旁边根本没细看。免费期内测试的正好是工具的边界，不要拿高容错的娱乐任务去试，要拿真正会出问题的任务去试，才能看清它的校对机制和错误率。

另外要提醒一点：在不确定服务条款的情况下，不要把高度敏感的公司内部数据、个人隐私信息直接喂给云端工具。尤其是限时免费阶段，服务背后的数据留存规则未必像正式版那样清楚，做好数据脱敏、用虚构样例去测试会稳妥很多。

5. 从这次发布延伸出去：我的几条实操判断

文章写到后面，分享几个我在试完这轮模型和工具组合之后的直观感受，不一定全对，但应该能帮你少走一些弯路。

这次发布最值得肯定的不是“770B 开源”这个动作本身，而是它把发布节奏改成了“模型 + 工具 + 限免验证”的三段式。只放模型权重，是给开发者看的；只放 WorkBuddy，是给办公用户看的；把两者放在一起，才是给真正想用 AI 改造工作流程的人看的。模型的通用智能再好，如果只有资深程序员能通过 API 调用，绝大多数人还是享受不到红利；WorkBuddy 这类工具承担的就是把智能从技术底层捞上来，翻译成“能帮我整理文档、写页面、跑流程”的具体能力。

关于是否要在 770B 开源模型上投入技术资源，我的判断是看团队的实际需求。如果你只是短期好奇，用 API 跑一下足够了；如果你有长期私有化需求，这个方向值得跟，但不用急着在生产环境里大规模切换，建议先搭建小规模评估环境，验证模型在你业务数据上的表现。对 WorkBuddy 这类限时免费的工具，我一直以来的态度是：把免费期当实验期，别当游戏期。实验的目的不是省两个月的会员费，而是搞清这个工具能否嵌入你的工作习惯。

我在实际使用中还有一个体会，趁免费期最该积累的不是聊天记录，而是一套属于你自己的 Skill 和 Prompt 模板。就算两周后 WorkBuddy 的定价超出预算，你在试错过程中总结出来的任务拆解方法、提示词写法、流程设计思路，换成任何同类工具都仍然有效。工具会过期，方法论不会。这大概也是这次 Hy4 preview 和 WorkBuddy 组合发布给我的最大提醒：模型会越来越强，工具会越来越顺，最终拉开差距的，还是你有没有把自己要做的事拆成一套可复用的操作流程。