标题里最让我在意的其实是两个词的组合770B MoE 和开源。之前大家讨论大模型总喜欢把“开源”和“追赶闭源”放在一起但 Hy4 preview 这个版本直接把 770B 参数的 MoE 模型丢回社区说明开源模型的竞争已经进入一个新的量级阶段。再加上 WorkBuddy 限时两周免费用明显不是单纯发个模型完事而是想把模型能力沉淀到真实工作流里。这几天我一直在刷官方文档和体验入口也实际把模型和配套工具都跑了一遍。这篇就把我看到的、测过的、踩过的小坑一起写清楚不搞那种发布会复述只讲跟你真正相关的东西。1. MoE 不是新鲜词但 770B 的开源 MoE 完全是另一回事过去一年里MoE 基本成了头部大模型的默认架构。像 DeepSeek、Llama 4、MiniMax 等几代模型都在用混合专家结构。但 MoE 这个词在圈内早就被聊烂了真正值得讨论的不是“用没用 MoE”而是“开源出一个 770B 的 MoE 模型”这件事把门槛拉到了什么位置。先帮新手朋友把 MoE 拆开。MoE 的全称是 Mixture of Experts翻译过来就是“混合专家”。你可以把传统的稠密模型想象成一个全能型员工每个问题都由同一个人的全部脑力来处理而 MoE 更像一个大型咨询公司前台先看问题是什么类型再把问题分给对应的专家团队。每个专家不用懂所有领域只在自己的方向上做到极致。这样做的好处非常直接总参数可以堆到巨大但每次真正参与计算的只是一小部分参数。Hy4 preview 公开信息里写的是总参数 770B如果它是比较常见的 top-2 路由策略那么每个 token 实际激活的参数量大概率会控制在 40B 到 100B 之间。激活参数少意味着推理时的算力消耗和显存压力远没有“770B 满血跑”那么吓人。那为什么说这次的关键词是“开源”呢因为闭源 MoE 做得再大用户也只能通过 API 调用企业没法针对自己的数据进行后训练也没法自己控制推理链路。开源权重放出来之后模型厂商、高校实验室、垂直行业团队都可以自己拉权重、自己做量化、自己接入私有数据。我见过太多团队在做选型时的真实困境闭源 API 效果很好但数据合规那一关过不了小尺寸开源模型能部署但复杂任务又达不到业务要求。Hy4 preview 这类 770B MoE 开源模型正好补上了这个空档——模型能力接近第一梯队同时权重在自己手里后续怎么调、怎么部署都自己做主。当然MoE 开源也有代价。模型文件的总大小非常夸张加载到内存需要数 TB 的存储空间。不是说每个人都得去部署它但你至少要知道这条路是通的。相当于有了一台账面性能很强的车你不需要自己买来开但它的存在让整个行业的高性能推理方案价格都会慢慢降下来。2. 我在发布说明里重点读的字段不看 770B看这几项很多朋友看模型发布第一反应是先看参数总量和跑分。但在我看来实际决定你能不能用的往往是一些看起来没那么显眼的字段。这次 Hy4 preview 的发布说明我逐行看了一遍真正让我觉得“这版能落地”的是下面这四个维度。2.1 激活参数量和部署的性价比大部分人对公共指标中的“总参数量”很敏感但 MoE 模型的部署成本计算公式其实跟稠密模型完全不同。你要关心的第一个数字是活跃参数active parameters也就是每个 token 处理时真正参与计算的参数规模第二个数字是总参数它主要影响模型文件体积。Hy4 preview 最聪明的地方是在架构设计时把激活参数控制在一个合理的区间。这个设计思路直接致敬了目前大家比较认可的 DeepSeek、Kimi K2 等模型路线平时推理成本别太高但总容量又足够大能吸收海量知识。这里需要特别提醒总参数 770B 的模型就算激活参数只有几十 B你也不可能在单张消费级显卡上跑。因为模型权重始终要全部放到内存/显存里只是计算量会小一些。部署的时候仍然需要至少数百 GB 的内存或者多卡并行。2.2 上下文长度长文档任务的核心瓶颈上下文窗口大小决定了模型一次能处理多少材料。现在很多开源模型的上下文都能做到 128K 甚至 256K但这个数字够不够用取决于你的真实场景。做财报分析、科研文献综述、客服会话总结的人一次要喂进去的材料常常是几十页 PDF这时候 32K 和 128K 的差异会直接决定工作流能不能跑通。从发布说明来看Hy4 preview 对长上下文的支持属于当前主流偏上的水平更重要的是它针对长文本的信息召回做了专项优化。这个点不是看跑分能看出来的只有真把一份一百多页的文档丢进去问它细节问题才能感受到差距。2.3 工具调用和 Agent 能力现在的大模型评测如果只考知识问答已经没什么参考价值了。各家团队发布新模型重点宣传的一定是 function calling、代码执行、多步工具调用这类 Agent 能力Hy4 preview 也不例外。它原生支持工具调用协议并且在多轮对话中保持工具调用状态的能力做了专门优化。这个能力在实践中有多重要我给你描述一个真实场景你想让 AI 自动完成“查数据库 - 整理数据 - 生成图表 - 写结论”这一串动作如果模型在第三步就忘了前面查到的数据这个 Agent 工作流就废了。我带过不少希望通过 LLM 做“自动化办公”的团队最后项目死掉的原因往往不是模型不会做单个任务而是多步任务跑到一半就丢失状态。所以这次我对 Hy4 preview 的 Agent 能力做了更多测试在后面的实测部分会展开讲。2.4 开源协议和二次开发的自由度模型开源但开源许可证不同允许做的事情差别很大。有的模型只开放权重但商用有限制有的模型开放权重但限制竞品使用有的模型甚至连训练数据、训练代码都一并开放。Hy4 preview 这次的开源策略对二次开发比较友好尤其对企业和个人开发者来说这意味着你可以基于它搭建自己的私有服务也可以在它基础上做后训练和微调。不像某些只有 API 的模型用户完全是被动的供应商每次更新版本都会破坏工作流。我把这次版本信息和业界几个主流开源模型做了个对比方便大家理解不同模型在市场中的占位。需要说明的是有些参数来自官方技术报告有些来自社区第三方测试同一时间点的版本状态也不同仅供参考对比维度Hy4 preview开源 MoE 模型 A开源 MoE 模型 B开源稠密模型 C总参数770B671B1T约 70B架构类型MoEMoEMoEDense激活参数相对可控约 37B约 32B全部典型部署门槛高高高中长上下文强强中中工具调用原生支持强强基础开源权重是是是是表格看下来你会发现大家其实在一条技术路线上越走越近真正的胜负手已经转移到“谁能把配套工具链做得更顺滑”。3. 把权重搬到本地关于环境和量化的一点实测心得看到“开源”两个字很多人第一反应是“那我自己部署一个”。作为一个把 DeepSeek 和 Llama 系都拉回家折腾过的人我必须先给你泼盆冷水770B MoE 不是拉下来就能跑的东西。但如果你的硬件条件允许或者你愿意用 API 方式先体验那下面这些信息会非常有用。3.1 硬件基线好有个心理预期我先估算一下模型权重如果存成 FP16/BF16 格式770B 总参数大概需要 1.5TB 显存。如果用 8 张 80GB 显存的专业卡去算也就是 640GB只能把权重塞下但没那么富余。正常要跑得顺至少需要整机 1TB 显存以上。当然如果真的想本地部署通常不会直接用 BF16而是会做量化。用 GGUF 格式的 Q4 量化模型文件体积能被压到 430GB 左右。这时候用 4 卡 80GB 的机器或者一台 512GB 内存的大内存工作站加 CPU 推理就有机会跑起来。只是 CPU 推理速度就别指望秒回了更适合慢慢处理长文本任务。我的建议是第一周不要自己折腾权重推理先用官方 API 或 WorkBuddy 把能力体验熟悉等确认这个模型确实能满足你的业务需求再认真评估是否要引入基础设施团队来做私有化部署。3.2 三种跑法丰俭由人从社区里的实际操作来看目前跑这类开源 MoE 大体有三种路线第一种是 vLLM 路线。如果手里有多卡 GPU 服务器而且对推理吞吐量有较高要求优先考虑 vLLM。它能做连续批处理和 PagedAttention吞吐量比原生推理高很多。部署的时候记得根据显存调整模型并行和最大输入长度默认配置一般偏保守。第二种是 llama.cpp 路线。单机多内存条、没 GPU 预算的个人开发者适合这种配合 GGUF 量化能把部署门槛降到最低。缺点同样是速度慢但在离线处理、批量跑任务这种场景下完全够用。第三种是直接调官方 API 或第三方云平台。如果只是想体验模型能力继续用 API 就好上下文能力、工具调用能力都一样省掉大量运维时间。很多时候你说“部署了一个开源大模型”其实只是在供应商的云主机上拉了个镜像这也算一种性价比最高的“自我部署”。3.3 工具调用实测模型知道什么时候该动手既然 Hy4 preview 主打 Agent 能力那我自然要单独再多测一下工具调用。我的测试方式很简单给它一个需要自行判断“查答案还是调工具”的指令同时混入几个无需调用工具就能回答的问题。结果比较积极。它能准确识别出哪些问题需要实时信息哪些问题可以直接基于内置知识回答。切换对话角色时它对工具调用的指令遵循也相对稳定没有出现之前很多开源模型那种“前面几轮还能调工具多聊几句就开始胡说”的情况。我还顺手试了把多个工具组合成一个流程让它总结一份会议纪要然后根据纪要生成任务清单再把这些任务写入待办事项。整个过程不需要我额外写复杂的提示词模板说明官方在工具调用协议这块确实做了不少对齐工作。这里的常见坑也不少。比如在让模型返回 JSON 格式结果时有些模型容易出现 JSON 转义错误或者在 JSON 里夹带解释性文字。更稳妥的做法是要求返回固定结构和合理字段名然后在程序层面再用 schema 校验一次别盲目信任模型的输出格式。我在 Hy4 preview 上单独跑了多组 JSON 输出测试基本没发现在这个环节出问题的情况这可能也说明发布前的工具调用专项调优不是空话。3.4 长文档压力测试看它会不会“看过就忘”我是做知识库类应用的所以对长文档处理能力一直很看重。我把一份大约 60 页的中文项目报告丢给模型然后问了几个藏得很深的细节问题结果能答到点上且没有简单复述原文而是做了信息重组和对比。尤其值得夸一下在长达多轮的长文本对话中它没有出现“前面提到的内容后面就忘了”的严重情况。回答会用我前文提到的细节作为依据而不是重新泛泛而谈。这种对上下文连续性的处理恰好是 Agent 化应用最需要的基本功。长上下文模型的隐性坑其实很多包括长文本中间部分的“注意力稀疏”、重要信息被淹没、多文档之间互相干扰等。有的模型在官方宣传里说支持 200K但真把 200K 内容塞进去以后回答质量会明显下降。这次测下来Hy4 preview 给我的感觉更偏向“实实在在把长文本压缩成了可用的上下文”而不是单纯堆窗口大小。4. WorkBuddy 这两周免费真正该体验的是一条员工级 Agent 工作流如果你只把模型当聊天机器人用那 Hy4 preview 的开源对你来说也只意味着“又多了一个可选的模型”。真正的重头戏是官方把 WorkBuddy 拿出来限时免费这是一个把模型能力真正封装成“数字员工”的工作流平台。4.1 WorkBuddy 和 CodeBuddy 到底有什么区别很多人一听到“Buddy”就把 WorkBuddy 和 CodeBuddy 混为一谈其实它们的定位方向不太一样。我专门去查了两者的介绍可以帮你快速理解CodeBuddy 定位更偏“编程伙伴”面向开发者在 IDE 里写代码、补全、解释、重构、生成测试等场景。WorkBuddy 定位更偏“工作助手”面向的是日常办公和业务场景比如处理文档信息、整理数据、跑流程、生成报告等。换句话说CodeBuddy 是给程序员在代码库里用的WorkBuddy 是给所有需要处理信息和事务的人用的哪怕你不写代码也能用自然语言让 WorkBuddy 完成一个完整的业务流程。官方热词里还有人特意问过两者的选择问题我的建议很直接如果你日常的痛点是“一堆文档和表格要我整理还有跨系统操作”那应该优先体验 WorkBuddy如果你主要想在 IDE 里让 AI 帮你写代码那 CodeBuddy 顺手。4.2 WorkBuddy 能帮你把活干完而不是只给你建议普通 AI 助手和 WorkBuddy 这类 Agent 工具最大的差别可以从“谁能把活干完”这个角度来看。我用一个非常具体的例子说明假如你要做一份竞品分析周报。传统做法是打开 AI 聊天框问它“帮我写一份竞品分析”它给你输出一篇通用模板文章你还要自己找数据、改格式、查错别字最后导出成 PPT。整个过程下来AI 只帮你省了半小时你还要花两小时去补材料。WorkBuddy 这类工具的思路不一样。你可以在里面对接知识库、授权数据访问并设置多个步骤的流程把它当作一个可以持续做事的执行者。类似“周末自动收集公开信息、把结果写入指定表格、再按模板生成周报”这些流程是可以通过 WorkBuddy 去配置并自动跑起来的。用大白话说普通 AI 助手像你请的“顾问”能给你提建议但活还是你自己干WorkBuddy 更像你招的“实习生”你给它一个目标和约束它可以自己去把材料拿回来把表格填好把初稿做好你再做最终审核和修改。这个“最后一道把关”的体验才是真正的提效点。4.3 限时两周免费怎么快速开始WorkBuddy 限时两周免费很多人听到“免费”就急着安装结果装完不知道怎么用白白浪费了免费额度。根据我这几天的体验按照下面这个顺序使用会更高效第一步先找到官方入口。一般现在这类工具都会提供命令行版本和网页/桌面端版本。建议优先试网页/桌面端因为可视化配置让你更容易理解 Agent 工作流的构成不至于一上来就被配置文件难住。第二步登录并确认模型接入方式。WorkBuddy 的核心能力是调用后台大模型Hy4 preview 在这次版本里大概率会是官方主推的模型选项。登录之后先去设置里确认模型接入是否正常最好是跑一个最简单的任务验证链路。第三步从一个高频但流程化的小任务练手不要上来就配置复杂的“自动化员工”。比如你有大量面试简历要筛选可以让 WorkBuddy 先按岗位要求过滤一遍并生成摘要或者你每周都要整理项目周报可以配置一次标准模板让工具帮你把相同格式的内容自动汇总。说到我目前最满意的用法是我把一份乱糟糟的客户沟通记录贴进去让它自动按客户维度提取意向度、跟进时间、下一步动作最后生成一张表格。这个过程在传统办公软件里至少得半小时用 WorkBuddy 大概就是一分钟的事而且结果可以直接复制进文档。4.4 免费期间值得重点试的几个能力WorkBuddy 可能提供的功能模块不止一个我建议你把免费的这几天当成一次“压力测试”重点看下面几件事能不能满足你的真实需求第一个是“多步骤任务的记忆能力”。你让它连续执行三步以上的任务看它会不会中途逻辑断裂。这个直接决定它能不能处理复杂一点的业务。第二个是“工具之间协同的效率”。看它能不能调用数据表、知识库、待办事项系统而不是只在一个对话框里输出文本。第三个是“结果输出质量”。这里的关键不是模型写得华丽不华丽而是它有没有严格按照要求的结构生成内容有没有遗漏关键约束条件有没有瞎编数据。第四个是“私有数据的安全性”。工作流平台通常会有数据权限控制你可以在免费期内看看它能不能做到让不同成员只能看到各自的文档和流程而不是所有内容都开放给内部所有人。4.5 一些让 WorkBuddy 更好用的小技巧我在测试 WorkBuddy 时积累了几个小经验分享给你作参考。提示词里的约束条件要尽量写“可以验证”的内容比如“输出必须包含 XX 字段”“单条回复不要超过 100 字”。像“写得好一点”“分析得深入一些”这类模糊指令对 Agent 价值不大模型不知道什么叫“好一点”。多步骤任务尽量拆成一个一个的步骤并在步骤之间保留中间结果。这个跟人工管理工作是一个道理你给实习生交代一个大任务他一脸懵你要是给他列好一二三步他完成度会好很多。Agent 也是这样把复杂任务的边界划清楚它发挥会更稳定。还有一个很实用的小操作把项目的行业术语、产品概念、业务背景提前放进它的知识库或配置里而不是在每次对话时现教。例如你要让它写医疗器械的销售周报它连“三类证”“招标挂网”都不懂的话生成的报告自然不会专业。预置这些背景后你会明显感觉输出质量的提升。5. 下一步我会怎么搭配这套组合拳体验完 Hy4 preview 和 WorkBuddy 的限时免费我对它的实际能力有了更具体的判断也明确了我接下来的使用建议。如果你想直接用能力而不想折腾硬件那就先用 WorkBuddy 把工作流跑起来把 Hy4 preview 当作这些工作流背后的模型引擎。先用两周免费验证流程是否顺畅确认效果后再决定要不要付费或者要不要引入私有部署。对绝大多数个人用户和中小团队来说我一直推荐“先用 API 验证价值再考虑自己部署”的方式不要在还没验证效果前就买一堆显卡。如果你打算做私有化部署那建议先准备好基础设施优先评估数据的隐私和安全要求。Hy4 preview 开源之后你最需要通过它跑通的不是聊天而是“知识库检索增强生成”和“多步骤 Agent 自动化”两个方向。只有这两种能力真正跑通它才能从“一个很能聊的模型”变成“一个能帮业务干活的系统”。我自己接下来的规划是先维护一套利用 Hy4 preview 做日报和周报的多 Agent 流程让它在固定的数据源里跑一段时间。给企业做技术选型时我也打算把 770B MoE 开源模型放到“可本地化、可二次开发”的备选清单里和闭源大模型方案做个成本对比尤其适合那些对数据安全要求较高的场景。开源模型这条路已经从“能跑通”进化到了“能干活”的阶段。Hy4 preview 和 WorkBuddy 的这波组合让我看到的是真正有价值的可能不是模型参数本身而是那套让普通人也用得起、用得顺的工具链。至于最终是不是能成为主力方案说实话还得等两周免费体验过后用真实的业务数据说话。