770B MoE开源大模型Hy4 preview发布，WorkBuddy免费开放如何部署与落地？

过去这一周AI圈子里讨论密度最高的消息应该就是Hy4 preview发布。一个770B MoE的模型权重直接开源同时官方把整套智能体工具WorkBuddy拿出来限时两周免费消息一出技术群、办公软件群、甚至一些做企业内部自动化的朋友都在转发。很多人来问我第一句话都是同一个这个770B到底代表什么是不是我的电脑也跑得动以及WorkBuddy免费期到底够不够用、值不值得花两周去试。我先把结论放在前面如果你以为770B MoE就是普通大模型再放大一点那你很可能低估了这次开源的意义但如果你以为模型开源了就等于人人都能本地跑那你大概率又要踩部署的坑。这篇文章不打算复述新闻稿而是把架构信息、部署思路以及WorkBuddy实际接入时的关键步骤拆开讲清楚。想弄明白MoE模型量级怎么判断的想自己动手把开源权重跑起来的朋友或者只是想搞清楚免费期该怎么规划的人都可以直接跳到对应部分看。1. 从“770B MoE”这个数字看新闻里的真正信号先说一个可能被不少人忽略的点这年头开源一个大模型并不稀奇 MoE架构也不算新鲜Hy4 preview真正值得关注的是它把三个东西同时推出来了。第一个是重量级权重本身。770B的总参数量放在开源模型里属于第一梯队不管是通用知识、复杂指令跟随还是多轮对话能力基础底子是有的。第二个是MoE架构带来的成本结构变化这个直接影响后续部署和使用价格。第三个则是WorkBuddy这个工具它并不是传统意义上的聊天客户端而是一套强调任务执行的智能体工作台并且把它限时免费开放。换句话说官方想推的不只是一个模型而是开源权重 推理工具 应用落地的组合方案。1.1 “总参数量”不是“每次推理都全量计算”很多人一听到770B就下意识想7700亿参数这得多少张显卡才能跑起来先别急MoEMixture of Experts混合专家架构和传统Dense模型最大的区别就在这里。Dense模型是每次推理都会把全部参数激活一遍相当于一个拥有1000名员工的传统公司无论你问谁问题整个公司都得运转一遍。而MoE模型则是把一个庞大的网络拆分成多个专家子网络每次输入只通过路由机制激活其中的一小部分专家。所以讨论770B MoE时一定要把两个数字分开来看一个是总参数量也就是模型文件在磁盘上占多大、加载时需要多少显存一个是激活参数量也就是每次推理时真正参与计算的参数规模。对于典型的MoE模型激活参数量可能只有总参数量的十分之一甚至更低。官方目前没有把所有专家配置细节都公开但按照同类模型的经验推测这么大的总参数量激活参数量大概率落在几十B到一百多B的区间具体要看每一层路由几个专家、专家FFN维度怎么设计。这也是为什么行业里会说MoE用更低的推理成本换取更高的模型容量。同样的算力预算下Dense模型只能做到几十B参数MoE却可以把知识容量做到几百B而单次生成速度并不会等比例变慢。1.2 为什么开源社区一看到MoE就这么兴奋如果只是追求参数数字好看那没有意义开源社区看重的是可复现性和二次开发空间。MoE权重开源以后大家第一反应是可以去做微调继续训练专家层第二反应是可以把主干模型和工具Agent解耦第三反应才是考虑怎么本地量化部署。Hy4 preview走的就是这个路子。它在开源的同时还配套了推理服务端代码和一份模型卡模型卡里会写明训练数据构成、评测结果、推荐上下文长度、特殊token设计等信息。这些信息对做应用的人来说特别重要。比如我想基于它做一个企业内部知识库问答系统那我需要知道它的上下文窗口到底适合放多长的文档需不需要在输入前做摘要我想做代码补全那我需要知道它对代码数据做过多少专门的训练中英文混合场景表现怎么样。这些信息如果不公开模型权重再强也像是黑盒。1.3 这次发布真正带火的是“模型工具”组合为什么热搜词里会同时出现Hy4 preview、开源、WorkBuddy因为它们其实是同一件事的两个面。模型权重负责的是智商但AI应用要落地到真实场景里光有智商远远不够。举个例子模型可以告诉你帮我整理本周所有未完成任务并发送周报这句话该怎么做但如果没有人替它打开任务系统、调用表格工具、填写页面、点击发送按钮它就只能把步骤写给你看然后停在聊天窗口里。WorkBuddy解决的就是后半段——让模型从一个答题者变成执行者。所以这一波热点本质上不是单纯的技术发布而是在提示一个趋势开源模型已经开始走向能干活的阶段了。以前大家在开源社区里秀的是跑分、刷榜现在更看重的是模型能否对接真实工具、在业务流程里真正把活干完。2. 想搞清楚能不能部署先把770B MoE的三本账算明白我见到最多的误读是把MoE激活参数小等同于部署门槛低。这句话对一半、错一半。MoE确实让单次推理的计算量下降了但模型权重加载到内存/显存时依然需要把所有专家都加载进来。你可以把专家想象成一栋楼里的各个科室虽然看一个病人只用得到两三个科室但医院不能为了接待某一位病人就把其他科室拆掉——它们必须一直存在随时待命。2.1 权重、激活、KV Cache三本账不能混着算要判断一台机器能不能跑某个模型至少要考虑三类资源消耗。第一类是权重占用模型所有参数乘以其精度对应的字节数。第二类是推理过程中的激活值内存虽然MoE只在专家间做稀疏激活但attention层、路由层、LayerNorm这些部分依然有稠密计算这部分激活显存也不小。第三类是KV Cache对话越长、并发越高KV Cache占用的显存越大。社区里常见的误区是只看到权重完全忽略KV Cache结果模型确实加载进去了一跑长对话就OOM。我列一张参考表方便你快速建立量级概念。这里不考虑框架优化纯粹按常见精度估算精度单参数占用770B权重总占用大约需要多少张80GB显卡BF16/FP162 Bytes约1540 GB约20张FP81 Byte约770 GB约10张INT4量化0.5 Bytes约385-450 GB约5-6张需要说明的是这只是权重部分还没算激活值和KV Cache。如果是8卡80G的常见单机想跑BF16原始权重基本不可能拆成INT4量化再配合一些CPU offload倒是有机会但性能会打折想要跑完整的FP8或BF16通常需要多机多卡或者更大的单卡显存。2.2 为什么“26B A4B能跑”不能直接推导到770B最近网上流行一些20多B总参数、激活4B左右的小型MoE模型部署教程很多人用单张消费级显卡就能跑起来于是产生一种感觉MoE嘛内存占用应该不大。这种推导放到770B上是会翻车的。26B总参数和770B总参数之间的权重差距是接近30倍。即便两者的激活参数量差距没有比例那么大但模型的物理大小决定了你必须先解决能不能装下的问题再谈跑得快不快。换句话说小MoE模型的部署经验可以帮你理解路由、专家并行这些概念但不能帮你绕开物理显存的上限。这时可能会有人问既然如此770B开源图什么图的是云服务方和头部企业能够以较低的单token成本提供高质量推理能力而不是图普通个人开发者用一张4090跑起来。如果你只是想体验个人用户实际可选的路径一般是调用官方或云厂商提供的推理API而不是本地全量部署。2.3 MoE模型的部署难点不在“大”而在“路由怎么放”稠密模型做分布式部署相对直接把网络层切到不同显卡上即可。MoE模型不一样它的专家数量很多而且不同token会被路由到不同专家专家之间的负载天然不均衡。如果你使用张量并行把所有层切开那通信量会非常大如果使用专家并行把不同专家放在不同机器上又需要处理跨机路由和负载均衡。所以在部署770B级别的MoE时光靠大不能解释所有问题真正决定推理性能的往往是路由计算放在哪里、专家并行度设多少、有没有使用流水线并行来降低卡间通信压力。这些参数不是越大越好需要结合具体硬件拓扑来调。如果只是拿一张网卡几根线拼出来的多机集群通信带宽不够模型再大也会被卡在卡间传输上整体吞吐可能还不如一个更小但并行策略合理的模型。3. 开源之后本地部署770B的实际路线图看到这里如果还有朋友想自己动手部署那我默认你的场景至少是公司内部有GPU服务器或者你正在做技术选型预研。下面给的是一套常见的开源大模型部署路线适用于Hy4 preview这类发布权重并兼容标准推理框架的MoE模型。具体命令要以官方仓库当时的文档为准但整体思路是通用的。3.1 第一步下载权重前先定好“精度策略”不要一上来就下BF16原始权重。先看自己的显存总量再决定精度。假设你手上是8张80G显卡总共640G显存理论上FP8权重约770G放不下。这时要么改用INT4量化版本要么减少同时加载的专家数量做CPU offload要么上多机。比较理智的做法是先下载一个INT4或者FP8量化版本做功能验证确认模型的输出质量满足业务需求再投入资源部署完整精度版本。很多踩坑的人都是反着来的辛辛苦苦把BF16权重传出几个T最后发现显存不够又得重新规划、重新下载白白浪费一整天。权重下载时可以看一下官方是不是同时发布了多个精度的分支。通常HF格式权重目录下面会有不同子目录量化版本的文件会小很多。如果网络条件一般也可以优先考虑从高校公共镜像站或国内模型加速服务拉取比直连海外源稳定得多。3.2 第二步用vLLM拉起一个兼容OpenAI的服务现在开源自部署的主流推理方式基本是vLLM或SGLang这类带高性能优化和OpenAI兼容接口的推理引擎。使用vLLM的好处是部署完成之后模型对外暴露的是一个标准的/v1/chat/completions接口WorkBuddy、Dify这类上层应用可以直接通过配置模型端点接进去不需要为每个模型写专门适配代码。启动命令大致长这样python -m vllm.entrypoints.openai.api_server \ --model /data/models/Hy4-preview/ \ --tensor-parallel-size 8 \ --max-model-len 65536 \ --gpu-memory-utilization 0.92 \ --trust-remote-code \ --served-model-name hy4-preview命令里几个参数先解释一下。--tensor-parallel-size表示用几张卡做张量并行切分这里设成8意味着假设你在单机8卡环境运行如果你的机器是4卡或者需要跨节点就要相应调整甚至要配合流水线并行参数使用。--max-model-len控制最大上下文长度我示例里写的65536等于64K token设置太大会让KV Cache占用急剧膨胀设置太小又浪费模型本身的上下文能力需要根据业务折中。--gpu-memory-utilization一般设置到0.9左右预留一部分显存给CUDA上下文和碎片。启动之后不要急着接上层应用先验证一下模型服务本身是否正常curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: hy4-preview, messages: [{role: user, content: 请用一句话介绍你自己}], max_tokens: 256 }能正常返回内容说明推理链路已经通了。这一步看起来简单但经常出现的问题是模型名没对上明明启动参数里写的模型名是hy4-preview请求里却填了权重目录名接口就会报错。切记保持两个名字一致。3.3 第三步把WorkBuddy指向本地模型端点本地推理服务跑起来之后WorkBuddy这类Agent工具就需要配置一个自定义模型。在WorkBuddy的设置里一般会有一个模型管理界面填入服务地址http://你的服务器IP:8000/v1然后填模型名测试连接通过之后就可以开始使用了。这里有一个很实操的建议如果你是在内网服务器上部署先确认WorkBuddy运行的那台机器能不能直接访问推理服务的IP和端口。很多人卡在最后一步往往不是模型没部署好而是端口没放行、服务绑定在localhost上不能从外部访问或者证书问题导致HTTP接口被浏览器拦掉。使用vLLM时默认监听0.0.0.0:8000还算友好但如果是通过Docker映射端口要记得把宿主机的端口正确暴露出来。3.4 本地部署里最容易被忽略的几个坑我在部署开源大模型时踩过不少坑有几个可以提前写出来提醒大家。第一个坑是多卡并行时的卡间通信。如果你用的是PCIe连接的多卡而不是NVLink全互联张量并行规模过大会导致通信开销猛增甚至出现显卡越多速度越慢的反常现象。因此不要盲目追求把模型切到所有卡上有时候4卡张量并行、另外几张卡用流水线并行或者干脆留空性能反而更好。第二个坑是量化后的输出质量变化。有些MoE模型对量化精度比稠密模型更敏感因为专家路由的结果会和注意力输出叠加小的精度损失可能在多专家场景里被放大。建议部署INT4版本之后拿你业务里最难的那一批问题进行对比测试如果出现明显的逻辑断裂或重复生成再考虑换FP8或增加一些量化校准数据。第三个坑是上下文长度设置。MoE模型如果支持长上下文不代表你应该默认把max-model-len拉满。长上下文场景下KV Cache增长很快可能直接把并发能力压到只有一两路。实际业务里还是按“够用就好”的原则来配宁愿把长度控制在32K或64K把多余显存留给更高的并发。4. WorkBuddy免费开放的是什么它补足了模型的哪块短板模型能跑起来是一回事能不能在现实工作流里干活是另一回事。如果你只是在网页聊天框里问问题那用不用WorkBuddy都无所谓但如果你想让它自己调用浏览器、写文件、操作表格、完成多步骤业务流程就需要一个执行框架。WorkBuddy带火的正是这个方向。4.1 它不是一个竞品而是一个“执行层”有些朋友会拿WorkBuddy和其他编码助手对比问我CodeBuddy和WorkBuddy到底有什么区别。从我目前了解的信息来看这个对比本身有点错位。编码助手更像一个坐在终端旁边的结对程序员主要工作场景在IDE和命令行里帮你补全代码、解释报错、生成单元测试WorkBuddy的定位则更偏向工作流Agent它关注的不是某一行的代码质量而是“一个任务从输入到产出是否有完整的执行路径”。举个例子你的任务是“把竞品官网上的产品价格下载下来整理成表格再生成一份对比摘要发给市场部”。传统的编码助手会帮它写一个爬虫脚本但写完就结束了WorkBuddy会尝试自己打开浏览器访问页面、读取表格、生成文件、调用IM工具发送消息。也就是说前者提高的是“写代码”的效率后者提高的是“让一件事从零到一被完成”的效率。4.2 Skill机制是怎么让业务流程落地的WorkBuddy比较受关注的一个设计是Skill技能机制。简单说用户可以把高频复用的业务流程封装成一个可被Agent调用的技能文件里面包含了任务的触发条件、执行步骤、输入参数、输出格式。这样下次只要一句话触发Agent就知道该按什么顺序去执行而不是每次都要临时理解一遍。比如我做一个“每日销售播报”技能可以定义这样的流程读取数据源里的销售明细、按区域聚合、计算环比、将结果生成为一段摘要、发送到指定群聊。这个流程如果不封装模型每次执行时都可能把步骤搞乱今天可能先汇总再算环比明天可能忘了发摘要。封装成Skill之后执行路径固定下来Agent只需要处理每步里的具体数据差异稳定性和可维护性都会好很多。对普通用户来说这个机制最大的价值在于“经验可以被固化”。以前你用AI需要把业务背景一遍又一遍告诉模型现在相关指令、背景信息、执行步骤都写进Skill文件里团队其他人也能直接复用。这一层能力单纯靠大模型API是无法天然提供的。4.3 为什么“限时两周免费”是一步很有策略的棋官方选择在Hy4 preview发布时同步放开WorkBuddy免费使用逻辑很清楚一个开源MoE模型需要一个能充分展示其能力的落地载体而一个Agent工具也需要一个足够强的模型来做推理底座。对用户来说免费期其实是一个很好的窗口可以完整评估三件事。第一模型本身的输出质量是否满足你的业务需求第二Agent在真实工作流里的执行成功率到底如何第三整个方案如果按量付费未来的成本是否可控。两周时间说长不长但足够跑几轮真实业务验证前提是你别光拿去聊天。5. 如果你只有两周免费我建议这样规划和验收既然是限时福利就不要把时间浪费在“试玩”上。我的建议是用一个周末先把基础功能跑通第二周集中做业务场景的实测。下面是一份可以直接抄的验收清单。5.1 第一天到第三天做三种基础能力测试第一天先做长文本理解测试。把一份至少50页的资料或一份很长的工作周报喂给它让它总结、提问、提炼关键结论。这一步主要验证模型在长上下文下的注意力会不会丢失、会不会出现前后矛盾。第二天做工具调用测试。让WorkBuddy执行一个包含多个步骤的简单任务比如“查一下当前日期新建一个本地文件在文件里写一段本周计划并把文件路径返回给我”。这类任务看着简单但能快速暴露出工具调用链路是否稳定。第三天做代码生成与网页开发测试。如果你有前端需求可以试试用一个自然语言描述让WorkBuddy生成一个完整网页比如“做一个带筛选功能的任务管理页面”。这里重点验证的不只是页面能不能打开而是生成结果能否被进一步修改、迭代以及对中英文混合需求的理解程度。5.2 第二周只测你自己真正要用的业务第二周开始就别再泛泛测试了。把目前工作中最高频、最重复、最消耗人力的任务挑一个出来完整地让WorkBuddy去执行。如果你做数据处理就让它跑一次分析并生成图表如果你做内容运营就让它根据素材批量生成初稿。两周结束之后你需要回答一个核心问题这套流程每个月愿意付多少钱来替代人工重复劳动这里有一个经验判断一个Agent工具是否值得长期使用不能只看“它是否完成了任务”还要看“它完成任务时需要的辅助程度”。如果每个任务都需要你中途介入三五次去纠正那它目前更适合作为效率辅助而不是全自动流程的一部分如果大部分任务能一条链路自动走完只有少数异常需要人工兜底那这钱花得就值。5.3 免费期里容易踩的几个使用误区第一个误区是把WorkBuddy当成普通的聊天机器人。有些人完全不用Skill、不做任何配置只把它当成一个带界面的模型对话窗口。这样用当然也能体验到模型的部分能力但完全没有触及这款工具的核心价值两周后大概率会得出“也就那样”的结论。第二个误区是任务设计得太重太复杂。第一次用就直接让它执行一个涉及七八个系统的跨部门流程结果大概率是失败因为Agent对你们企业内部系统的结构完全不了解需要先通过Skill或文档教它。建议从单个系统内的小任务开始逐步增加复杂度。第三个误区是忽略错误日志。WorkBuddy执行失败时通常会给出任务链路里具体哪一步出了问题。认真看日志比反复重试更有用很多问题是工具权限没开、文件路径不对、模型没有正确理解预设格式导致的属于一次性配置问题调好之后就不会再犯。5.4 免费期结束之后怎么接着用如果测试效果好团队决定继续用那通常有两个方向。一个方向是直接用云端的托管版本省运维成本适合团队规模不大、不想碰GPU服务器的场景另一个方向是回到我们在第3节讲的内容把开源权重部署到自己的GPU集群上再在WorkBuddy里配置自定义模型这样模型调用不给外部付费推理成本主要变成硬件折旧和电费。两条路线没有绝对好坏。前者胜在稳定省心适合追求快速落地后者胜在数据安全和长期边际成本递减适合对数据敏感、有内部IT基础设施的团队。如果预算和人力都紧张建议先走云端托管把业务流程跑顺再逐步迁移到本地推理。6. 关于Hy4 preview和WorkBuddy免费期我的一点个人建议文章写到这里最后再分享几个我自己的判断不一定对但全是真实想法。第一不要把开源770B MoE单纯看成“又一个可以下载的大文件”。它更大的意义在于开源社区首次有了一批可以真正支撑复杂Agent任务的重量级底座。过去做本地化Agent方案通常面对的是7B、13B、32B级别的模型能力强但天花板明显现在有了770B级别的可选权重很多以前觉得“本地模型干不了”的企业级场景开始有了解法。第二WorkBuddy这类工具和开源模型之间的关系会越来越像“操作系统”和“CPU”。操作系统的好坏决定了CPU性能能否充分发挥Agent执行框架的好坏决定了开源模型的推理能力能否转化成实际产出。所以免费期就算不打算继续付费我也建议至少完整走一遍“创建Skill—执行任务—排查失败—调整流程”这个闭环体验一次“模型真正把活干完”是什么感觉。第三也是最重要的所有数字和免费活动都会过期但你的业务流程梳理不会。趁这两周把一个高频业务流程拆解清楚测试一下哪些环节可以被Agent替代哪些环节还需要人来做判断。我发现很多人使用这类工具之所以效果不好问题恰恰出在对自己业务的流程梳理不够细上——不是AI不行而是你自己没想明白“什么算干完”。这次开源发布到底能走多远还要看社区能长出多少基于770B MoE的实用项目以及WorkBuddy能不能在免费期结束前留住足够的忠实用户。但从目前的信息看方向是对的。模型开源 任务执行工具免费开放这意味着AI能力的门槛正在从“能不能用到”变成“会不会用”。真正值得多花时间的不是后台的参数量和框架参数而是拿着这套工具把你手里的业务先跑通一遍。