最近两天技术社群里被同一件事刷屏Hy4 preview 发布770B MoE 参数开源同时官方把 WorkBuddy 拿出来做限时两周免费。我第一反应不是“又一个巨无霸来了”而是赶紧确认两件事这次开源到底是开了权重还是把可商用也算进去了WorkBuddy 的免费期是新用户专享还是所有功能都放开。逐条看完之后我觉得这次发布值得单独写一篇因为它的操作路径已经和上一代开源模型明显不一样了——不再只给一个模型文件让你回去自己折腾而是连着工具链、工作台一起往外推。这篇文章我想从一个普通开发者的视角把这次发布里最值得关注的几个点拆开聊Hy4 这个 770B MoE 是什么水平、本地部署到底要多少显卡、WorkBuddy 这两周免费期应该怎么用以及我在实际测试里踩到的那些和宣传口径不一样的地方。读完你至少能判断自己要不要立刻上手如果要第一步该干什么。1. 先别急着下载Hy4 preview 这次开源的价值到底在哪1.1 为什么“770B MoE”这个数字组合值得关注看到 770B 这个数懂行的人第一反应往往是这是 Dense 还是 MoE如果是 Dense那基本和我们普通人没关系纯纯的算力玩具如果是 MoE那就完全是另一回事了。Hy4 preview 走的是后者Mixture of Experts混合专家架构。我们可以把它理解成一个大型公司770B 是公司总员工数但处理具体某一件任务时系统不会让所有员工一起上而是根据任务类型从中挑选几个最擅长的专家小组来干活。这个“挑选出来真正干活”的部分就是激活参数。官方技术材料里虽然没有把所有架构细节都摊开但社区从命名字段和部署配置推断Hy4 preview 的激活参数应该在 40B 量级。也就是说虽然总参数量高达 770B但每次推理真正走计算图的只有大约 5% 左右的参数。这个设计思路这几年已经被反复验证过了。同等计算成本下MoE 可以用更多的总参数来“记住”更多模式同时推理开销又不会像总参数那么恐怖。如果说 Dense 模型是让一个全科医生从头到尾处理你的所有症状那 MoE 就是分诊台根据你的情况只叫对应的专科医生进来。所以 770B 这个数字真正的意义不在于“大”而在于它在总参数规模上已经摸到了上一代闭源顶级模型的水平同时又用自己的开源权重把门槛压到了一个普通技术团队可以规划的范围内。这不是一个秀肌肉的吉祥物而是一个可以真正拿去做事的底座。1.2 MoE 不是新鲜事Hy4 的差异点在哪如果你这两年一直在关注开源模型会发现 MoE 早就不是什么新鲜词了。很多知名模型都是 MoE 路线大家也都很清楚 MoE 的几个老大难问题路由不稳定专家选择偶尔会抖动同一个问题换个问法走的专家不同输出风格可能就变了。微调难度高全参数微调对显存和样本量的要求比 Dense 更苛刻LoRA 又要额外处理“该把 adapter 挂到哪些层”的问题。量化工具链不成熟部分量化方案会破坏路由层的判断导致量化后模型智商断崖式下跌。Hy4 preview 这次发布在我看来比较聪明的地方是它没有回避这些质疑而是在发布材料里专门给了几个针对性的说明路由层支持负载均衡约束分布式场景下专家调度做了通信优化以及官方推理栈对量化做了适配。当然宣传归宣传我在后面的实测里也验证了一部分有些确实做到了有些则和想象中不太一样。但单从“开源”这个动作本身来说这轮发布的诚意是够的。权重文件、推理代码、推荐部署参数都一起放了出来不是那种“开源了个寂寞”的营销式开源。这也是我愿意腾出时间写这篇文章的原因——人家确实给了可以跑起来的东西那我们就可以用跑出来的结果来评判而不是隔着屏幕猜。2. 一张卡跑不了十张卡不够用770B MoE 的真实部署账2.1 先算显存BF16 全精度下精确到 GB很多人看到“开源”两个字就热血沸腾觉得自己下载下来就能本地跑。770B 这个规模我们必须先把账算明白。大模型推理时的显存占用大头是权重本身。BF16 精度下每个参数占 2 字节770B 参数就是 770 × 1e9 × 2 bytes算出来约等于 1.54TB。注意这只是权重还没算 KV Cache、激活内存和运行时开销。对照一下市面上常见的卡一张 H100 80G显存 80GB一台 8 卡 H100 服务器显存总量 640GB。也就是说BF16 全精度下光权重就需要 1.54TB单机 8 卡连权重都塞不下。你需要至少 20 张 H100 才算安全那基本就是一个小型算力集群的概念了。这时候有人会说那我用 CPU 内存行不行几十张卡不行我搞个 2TB 内存的大机器总可以吧。技术上确实可以用 llama.cpp 之类的方案把权重放在系统内存里做混合推理速度会慢到你怀疑人生——每秒可能就吐几个 token。作为验证可行性可以作为日常使用完全不行。所以如果你是一个普通开发者或者小团队看到 770B MoE 的第一反应不应该是“我要本地部署”而应该是“我该用哪种方式调用它”。关于调用的选择下一节继续算。2.2 想跑起来必须走量化不同精度下的显存需求表既然 BF16 跑不动那就量化。量化说白了就是把参数从 2 字节缩减到 1 字节甚至 0.5 字节牺牲一部分精度换取能塞进显存。我按不同精度算了一笔账把权重占用、推荐显存和适合的人群整理成了一张表精度权重占用约单实例最低显存建议适合场景BF161.54TB20 张 H100 80G企业级生产集群追求最佳输出质量FP8770GB12 张 H100 80G小集群保留大部分质量INT4385GB6 张 H100 80G 或 8 张 A100 80G有卡团队成本优先混合量化500GB 左右8 张 H100 80G折中方案推荐认真评估注意上表的“最低显存建议”不是光看着权重算的我已经把 KV Cache、激活内存和并发余量粗略加了进去。实际部署时如果你还要跑长上下文或者同一时间有多个请求显存需求还要往上走。以 INT4 为例385GB 的权重加上几十 GB 的 KV Cache6 张 H100 80G 是可以住的。但 INT4 量化对 MoE 模型的伤害主要体现在生成流畅度和复杂推理上我在实测里明显感觉到量化后的模型虽然也有 770B 的“架子”但细节处理比 BF16 版本粗糙不少。所以如果没有硬性的数据合规要求普通人用 API 拿到的往往是最优精度的版本比自己量化折腾半天要划算得多。2.3 别忽视 KV Cache 和激活内存权重算完了很多人就以为部署方案定了。实际上在真实业务中KV Cache 往往比权重更容易让你翻车。KV Cache 是推理时用来缓存历史注意力键值对的内存。它的计算公式大致是2Key 和 Value 两份× 层数 × 注意力头维度 × 序列长度 × 精度字节。Hy4 preview 这种级别的模型在支持长上下文的前提下如果你真的把上下文拉到 32K一个实例的 KV Cache 随随便便就是 20GB 到 30GB。如果你开 4 个并发请求那就是 80GB 到 120GB一碗饭变四碗饭。激活内存虽然在推理时通常比训练小得多但 batch size 一旦起来同样不可忽视。我见过不少团队兴致勃勃地照着权重表买了机器结果配好环境一压测OOM 直接报出来然后一脸茫然地到处问。这里我给一个实战建议规划显存时权重只按 70% 分配剩 30% 留给 KV Cache 和激活。保守一点后面能少掉很多头发。3. 开源的“开源”有很多种Hy4 属于哪一种3.1 权重、代码、协议三样东西要分开看“开源模型”这四个字其实是个被过度简化的大箩筐。我见过太多人看到“开源”就把模型拉到本地用了一阵之后才发现协议里写了“仅限研究用途禁止商用”或者要求月活超过一定数量就必须买商业授权。到那一步再改方案成本早就付了。判断一次开源到底有没有诚意要把三样东西拆开看第一权重是否完整开放第二推理和训练相关代码是否公开第三许可证是否允许商用、是否带附加条件。第一样决定你能不能跑第二样决定你能不能改第三样决定你能不能拿它赚钱。从目前 Hy4 preview 放出的仓库内容来看权重文件和推理栈代码是齐全的许可证也明确允许商用没有看到类似“月活超过 XX 万需另行授权”的限制条款。不过我必须提醒一句开源许可证的坑往往藏在细节里比如权重和代码可能采用不同的许可证比如“允许商用”和“允许用商用了但不允许用它来训练竞品模型”是完全两码事。真打算把 Hy4 preview 放到生产环境里的人务必去仓库把 LICENSE 文件从头到尾读一遍不要看二手消息。3.2 生态适配比模型本身更重要权重放出来只是第一步。一个开源模型真正能不能用起来取决于它周围的生态有没有跟上。我判断 Hy4 preview 能否快速落地的标准很简单主流推理框架是不是已经支持、量化工具是不是已经适配、社区里有没有现成的部署经验和踩坑记录。目前 vLLM、SGLang 这类主流推理框架都对新模型的支持响应得很快Hy4 preview 发布后当天就已经有不完整但能跑的适配分支。llama.cpp 那边的进度稍慢毕竟 MoE 的底层调度和内存管理在 CPU 推理场景下要处理更多细节。如果你是一个需要在多平台部署的人我的建议是先用 vLLM 跑通等 llama.cpp 的支持稳定了再考虑边缘设备上的轻量化方案。另一个生态问题是微调。LoRA 微调 MoE 模型时一种常见做法是只微调 attention 部分或者只调整 router 参数之外的模块但这种策略的效果因模型而异。社区里已经有人放出 Hy4 的 LoRA 训练笔记显存需求比预期低不少这和它激活参数只有 40B 级别有直接关系——训练时真正参与反向传播的也主要是被激活的那部分参数。所以我的判断是Hy4 preview 在微调友好度上会比同规模的 Dense 模型高很多。4. WorkBuddy 免费两周这不是又一个聊天框而是一个可以带 Skill 的工作台4.1 先搞清 WorkBuddy 和 CodeBuddy 的区别这次发布里和 Hy4 preview 一起出现的产品叫 WorkBuddy限时两周免费。很多人的第一反应是这玩意儿是不是和 CodeBuddy 一样就是个 AI 编程助手说实话我第一次看到也这么怀疑因为名字太像了。但实际体验下来这两个东西的定位差异很大。CodeBuddy 更偏向代码助手解决的是“写代码”这件事自动补全、生成函数、解释报错、改 bug使用场景基本都集中在 IDE 和代码编辑器里。而 WorkBuddy 是一个工作流编排平台解决的是“把一堆重复步骤串起来自动做掉”这件事。我画个最直观的区别维度CodeBuddyWorkBuddy核心定位编程辅助工作流自动化典型场景写函数、修 bug、审查代码拉取数据、生成报表、发送通知、批量处理扩展方式依赖 IDE 插件生态Skill 机制 API 接入与模型的关系调用模型来辅助写代码把模型编排进业务流程的一个环节理解了这个区别你就会明白为什么热词里会出现一堆“workbuddy 业务流程”“workbuddy 搭建个人工作台”之类的搜索。大家真正想知道的不是它能不能写代码而是它能不能替自己把那些固定的、重复的、耗时的办公室杂活扛下来。WorkBuddy 想抢的其实是这个位置。4.2 Skill 机制它凭什么值得在这两周里折腾WorkBuddy 最吸引我的是它的 Skill 机制。你可以把 Skill 理解为“给 Agent 写一份可复用的操作手册”——用自然语言描述清楚目标再配合少量脚本和参数模板让 WorkBuddy 每次都能按同样的方式处理某一类任务。举个例子。你每周五下午都要做一件事把销售系统导出的 CSV 数据整理成 Markdown 周报分部门统计销售额再发给群里。过去你可能是手动打开 Excel 做透视表再复制到聊天窗口一套操作下来花十几分钟。在 WorkBuddy 里你可以把整个过程写成一个 Skill输入是 CSV 文件路径输出是排版好的 Markdown 周报中间的数据清洗和统计逻辑都写在 Skill 步骤里。下次只需要说一句“跑一下周报 Skill用最新的文件”剩下的事它自己完成。这个机制的聪明之处在于它把“Prompt 工程”从一个模糊的技巧变成了一个可沉淀的模块。你调好的流程可以保存下来以后反复使用也可以直接套用别人分享的 Skill 模板改一改不需要从零开始。在免费期里最值得投入时间的事情就是把你手头最高频的几件重复劳动逐个写成 Skill。4.3 免费期放大招先把这三件事做完两周免费期看着不长但足够说明问题。我的建议是别把时间浪费在把所有功能都点一遍这种操作上就盯紧三件事第一把你最重复的一到三个工作流写成 Skill哪怕一开始很粗糙先跑通再说。第二把 Hy4 preview 的 API 接入 WorkBuddy用真实场景的任务去测它看它处理你的业务数据时靠不靠谱。第三搞清楚你的数据是怎么流转的上传的文件存在哪、调用外部 API 时会不会把数据发给第三方、输出结果能不能自动归档。免费期结束之后你留下的不应该是一堆截图而是一个已经跑起来的自动化流程以及你对这个产品是否值得付费的明确判断。5. 实操记录从零把 Hy4 API 接到 WorkBuddy 并跑通一个自动化任务5.1 准备工作账号、密钥和环境演示一下我这两天的实际操作。我在 WorkBuddy 官网用企业邮箱注册了一个账号顺利领取了两周免费权限。付费信息方面WorkBuddy 目前是按工作台席位和功能模块收费免费期不需要绑卡这一点比较良心也减少了我对“到期忘记取消被扣款”的焦虑。Hy4 preview 这边因为我手头没有 20 张 H100 的集群所以我选择的是官方提供的托管 API 服务。申请流程很常规注册开发者账号创建应用拿到 API Key。这里有个容易踩的小坑API Key 只在创建时完整展示一次生成之后一定要立刻复制保存我第一天就因为忘了复制又重新创建了一次白耽误十分钟。模型服务的地址格式是 OpenAI 兼容的也就是说你不需要装任何特殊 SDK直接用 requests 或者 OpenAI 官方 Python 包改一下 base_url 就能调。对已经习惯用 GPT 系 API 的人来说学习成本几乎为零。5.2 在 WorkBuddy 里配置模型节点WorkBuddy 没有把外部模型能力焊死它允许你在工作流里配置自定义模型节点。配置界面里需要填四个东西模型供应商名称、base_url、API Key、模型名。我填的示例配置长这样provider: hy4 base_url: https://api.example.com/v1 api_key: sk-xxxxxxxxxxxxxxxxxxxx model: hy4-preview填完之后WorkBuddy 会自动发一个测试请求来验证连通性。我第一次测试时报了 401排查了半天才发现是 API Key 复制的时候多带了一个空格。这种低级错误在本地开发时很容易被忽视因为 IDE 的自动补全可能帮你处理了但在网页配置界面里它会原封不动地发出去。连通之后你还可以设置模型的工作参数包括 temperature、max_tokens、超时时间。我建议把超时时间设长一点因为我在实测中发现 Hy4 preview 的首 token 延迟会比小模型明显更高这个现象后面会展开说。如果你把超时设成默认的 30 秒很可能在大任务上直接判定超时造成一个“模型卡死”的错觉。5.3 写一个最小可用的 Skill 并跑通模型接好之后我写了一个最简单的 Skill把一段杂乱的销售流水数据整理成一份按产品线分组的 Markdown 周报。Skill 的定义结构大概是这样name: sales_weekly_report description: 根据原始销售流水生成按产品线分组的 Markdown 周报 inputs: - data_path: 原始 CSV 文件路径 steps: - 读取 data_path 指定文件 - 按产品线字段分组汇总销售额 - 计算各产品线占比 - 生成 Markdown 表格附一句话总结定义好之后我给了它一个真实 CSV 文件里面有 3000 多条销售记录。第一次运行花了大概 40 秒比我自己用 Python 脚本处理慢不少但它输出的周报格式非常完整除了表格之外还自动写了一段分析总结指出哪个产品线增长最明显。这个总结能力是我原本脚本做不到的需要理解和组织语言这正是它价值所在。中途也遇到一个报错提示输出超长。原因是 WorkBuddy 默认的输出令牌上限不太够而 Hy4 preview 在生成完整 Markdown 时如果没做约束它会写得很啰嗦标题下面先来一段铺垫表格后面又有几句总结结果就超了。解决办法是在 Skill 的指令里明确加上“直接输出表格不要额外解释”。这个细节值得记住——给模型定输出的格式约束是降低出错率最有效的手段之一。6. 实测印象和几个不太容易被宣传稿提到的点6.1 MoE 模型的“首 token 慢之后快”现象用 Hy4 preview 跑了几天的 API我最直观的感受是它的首 token 延迟明显比我常用的 70B 左右模型要高就可能你发一句话过去要等两三秒才有第一个字出来。但一旦开始生成后续 token 的速度就非常丝滑甚至比一些小的 dense 模型还快。这个现象和 MoE 架构直接相关。请求进来之后系统要做路由计算、确定专家选择、把对应专家权重加载到计算图上这些准备工作都在首 token 时间里发生。等到专家真正跑起来由于激活参数只有 40B 级别每一步计算的负担反而不重。所以如果你要把 Hy4 preview 放到交互式聊天场景里用户可能会觉得“反应慢”体验会有落差。但如果你是做批量离线任务比如生成报告、结构化抽取、批量改写那首 token 的延迟完全可以接受换来的是后段的高吞吐。选型的时候要想清楚场景不是所有任务都适合它。6.2 长上下文下的注意力漂移Hy4 preview 官宣的上下文长度很可观但我实测下来上下文长到一定程度后模型对前面内容的注意力会明显漂移。具体表现是对话到中后段时它偶尔会遗忘早期给过的一些关键指令或者在总结时漏掉细节。这不是 Hy4 独有的问题长上下文模型的通病而已。大模型不是真的在“读”全部历史它是通过注意力机制在历史内容里做检索匹配当历史长度超出注意力能够有效覆盖的范围早期的信息就会被稀释。MoE 架构下的路由机制有时还会加剧这个现象因为不同专家对不同位置的注意力侧重不同。实操层面的应对办法有两个一是任务拆短一个复杂任务拆成多次短对话每个会话只做一件事二是在每次关键输入时显式回顾之前的重点让模型重新“注意”到早期信息。我见过不少人上来就怼两万字上下文结果质量不稳定其实不是模型不行是使用方法不对。6.3 免费期最容易踩的“隐藏约定”最后说几个我观察到的、容易被忽略的细节。第一WorkBuddy 的免费两周是按“账号注册激活日”起算的不是按自然月的头尾。如果你周五注册免费期很可能在两周后的周五结束而不是月底所以要把重要的尝试安排在前面几天别拖到最后才想起来。第二免费额度不等于无限量调用。我的理解是免费期主要免除的是平台订阅费用但如果你在 Skill 里大量调用外部模型 API模型侧的费用还是要根据你的模型服务商计费。换句话说WorkBuddy 免费但 Token 不一定免费这两笔账要分开算。第三数据合规问题。你把公司数据接入外部 API 之前先看协议里怎么约定数据使用和存储。尤其是一些敏感业务数据走外部模型服务之前必须经过脱敏或者走私有化部署方案。别因为一个“免费”头脑发热把不该发出去的数据发出去了。这不是产品的问题是使用的人需要保持的边界感。如果让我说这两周免费期最值得做的事我的答案不是去研究 770B 模型是怎么训练的而是把手边最重复的那件日常工作用 WorkBuddy 的 Skill 拆成一个真正能自动跑的流程。模型再强最终真正省时间的还是流程本身。等免费期结束你留下的不是一堆截图而是一套已经能跑的自动化步骤那这两周就没白折腾。