1. 这次发布到底值不值得关注：Hy4 preview、770B MoE 与 WorkBuddy 的核心定位
1.1 从名字拆解：preview、770B、MoE 分别意味着什么
先说结论：Hy4 preview 不是一个“又一个新模型”，它是一次把超大参数规模模型开源出来的动作，同时配套了一个叫 WorkBuddy 的智能体工作流工具，限时两周免费。如果你是做 AI 应用落地、做 Agent 开发、或者纯粹想在本地跑一个大模型玩一玩的开发者，这个组合值得花时间弄清楚。
拆开看名字。“preview”说明这是预览版本，不是正式版。预览版意味着功能基本完整、主干能力已经可用，但在推理速度、边界情况、工具调用的稳定性上，可能还有调整空间。所以如果你打算直接上生产环境，建议先做一轮压力测试，不要盲目替换现有方案。
“770B”是总参数量，也就是 7700 亿参数。这个数字听起来很大，很多人第一反应是“这得多少张卡才能跑起来”。这里就牵出第二个关键词“MoE”——在这类架构下，770B 的总参数量并不是每一次推理都要全部参与运算，而是通过路由机制按需激活其中一部分专家模块。换句通俗的话说：公司养了 770 个员工，但每接一个活，只需要其中几十个相关的人干活，其他人待命。所以 MoE 模型的实际计算成本，远低于同体量的稠密模型。
“开源”则是最有价值的信号。这次发布把模型权重放了出来，意味着你可以自己下载、自己部署、自己微调，甚至在遵守开源协议的前提下做商用。这和只开放 API 的闭源模型有本质区别：API 你只能“租”，开源权重你才能“拥有”。
1.2 为什么选 MoE 而不是稠密模型：算力与效果的博弈
在 Hy4 preview 出来之前，业内其实已经见过不少选择 MoE 路线的大模型。最典型的就是 Mixtral 系列和 DeepSeek 系列的部分版本。MoE 路线之所以被越来越多人接受，根本原因是稠密模型在参数规模上已经撞上了成本天花板。
我举一个直观的例子。假设你要做一个 770B 参数的稠密模型，推理时所有参数都必须加载到显存里。按 FP16 精度算，770B 参数光权重就需要约 1.5TB 显存。这是什么概念？一张目前主流的 80GB 显存显卡，需要将近 19 张才能塞下权重，这还没算 KV Cache 和中间激活值。这个硬件门槛大多数团队根本跨不过去。
换成 MoE 架构就不一样了。770B 是总参数，但推理时激活的只有几十 B 到一百多 B。以常见的 26B A4B 这种配置为例，总参数 260 亿，每次激活 40 亿，部署成本远低于同等总参数量的稠密模型。Hy4 preview 的 MoE 配置虽然具体细节还需要看官方技术报告，但大方向是一致的：用稀疏激活换低推理成本，同时靠大总参数量保证知识容量和效果上限。
这个选择对于社区开发者来说是友好的。你不需要为了跑一个顶级效果模型去凑几百万的硬件，几块消费级显卡或者一张高端专业卡就有机会跑起来（后面我会展开讲量化方案和显存估算）。
1.3 WorkBuddy 在这次发布里扮演什么角色
如果 Hy4 preview 是发动机，WorkBuddy 就是整车。WorkBuddy 是围绕这类模型打造的智能体工作流工具，你可以把它理解成一个“Agent 调度中心”：模型负责生成和理解，WorkBuddy 负责把模型能力编排成可执行的任务流。
具体来说，WorkBuddy 支持定义技能（Skill）、串联多步任务、调用外部工具。比如你可以给它配置一个“资料整理”技能：让它读取一批文档，自动总结要点，生成结构化清单，再按指定格式导出。整个过程不需要你写代码去拼接 API，而是在 WorkBuddy 里通过配置和指令完成。
限时两周免费这个动作，是典型的用户习惯培育策略。团队希望通过免费窗口让更多开发者、研究员、自媒体内容创作者把 WorkBuddy 用起来，形成使用习惯，同时收集真实场景下的反馈来迭代。如果你是重度 AI 用户，哪怕只是冲着这两周免费去体验一下 Agent 工作流的编排方式，都是值得的。
2. 核心细节拆解：MoE 架构的关键设计、开源范围与 WorkBuddy 的玩法
2.1 MoE 架构的核心：门控路由、专家分配、稀疏激活
要理解 Hy4 preview 这类 MoE 模型，不需要啃完整的论文，抓住三个概念就够：门控路由、专家模块、稀疏激活。
门控路由是 MoE 的“调度员”。输入一个 Token 后，门控网络会计算它与各个专家模块的匹配度，然后决定把它分给哪几个专家处理。你可以把它想象成医院的分诊台：患者来了先分诊，判断是去内科还是外科，而不是每个科室都跑一遍。
专家模块则是不同的“专科医生”。在 MoE 模型里，专家是一组前馈神经网络（FFN），每个专家可能擅长不同的模式。有的专家对代码敏感，有的专家对数学推理更在行，有的则擅长处理长文本。训练过程中，模型会自动让不同专家“专精”不同领域，这种分工不是人为指定的，而是通过反向传播自然涌现的。
稀疏激活是说每个 Token 只激活少数专家。假设一个 MoE 层有 64 个专家，每次只激活 4 个，那这个层的计算量就大约是稠密的 1/16。但要强调一点：虽然计算量降下来了，显存占用并没有等比例下降——因为所有专家的权重都要常驻显存，只是某一时刻只有一部分在参与计算。这也是部署 MoE 模型时最容易踩的坑：你算显存的时候不能只按激活参数量算，得按总参数量算权重加载，再按激活参数量估 KV Cache。
2.2 开源的范围和边界：权重、代码、协议怎么看
开源模型这件事，很多人以为“开源=随便用”，这个理解太粗糙了。实际要看开源的范围和协议。
从范围上说，Hy4 preview 开源至少应该包含模型权重和推理示例代码。权重是核心，没有权重你没法本地部署。推理示例代码则是帮你快速跑通的脚手架。有些团队还会额外放出微调脚本、数据预处理工具，这些属于加分项，但不算标配。
从协议上说，不同团队的授权差异很大。常见的有三类：Apache 2.0 这种宽松协议，基本可以随意商用、修改、再分发；MIT 类似但更简单；还有一种是对商用有附加条件的协议，比如月活用户超过一定规模就需要额外申请商业授权。Hy4 preview 具体用的哪一种，拿到模型页面后第一件事就是看 LICENSE 文件。如果是商用项目，这一步千万别省。
我自己的习惯是下载后先做三件事：第一，读 LICENSE，确认商用边界；第二，跑通官方的推理示例，确认环境没问题；第三，用自己准备的一小批测试集跑一遍效果对比，而不是直接上生产。这三步走完，再判断要不要接入业务。
2.3 WorkBuddy 能做什么：从技能编排到任务自动化
WorkBuddy 的核心玩法可以总结成一句话：用自然语言定义任务，用技能封装能力，用流程串联步骤。
先看技能（Skill）。一个技能就是一组指令和配置的组合，相当于给模型一个“角色说明书”。比如你可以创建一个“周报生成技能”，告诉它：读取本周工作记录，提取关键成果，按问题、进展、计划三个维度输出周报。创建好之后，每次只需要给它喂数据，它就会按统一格式输出，不会再出现每次生成风格不一致的问题。
再看工作流。WorkBuddy 支持多步骤任务编排。比如“竞品分析”这个任务，可以拆成四步：收集竞品公开资料、提取核心功能点、对比差异、生成分析报告。每一步可以调用不同的技能，也可以穿插人工确认环节。这种编排方式特别适合需要周期性执行的复杂任务，设置一次，后续反复使用。
限时免费的两周里，我建议你把高频任务都梳理一遍，挑三四个最常做的建好技能。即使后面收费了，你已经沉淀了一套自己的技能库，这些资产不会消失，只是恢复为付费配置。免费期内攒下的模板，才是你真正赚到的东西。
3. 实操过程与核心环节实现：从拿到权重到跑通推理，再到 WorkBuddy 上手
3.1 部署前的环境准备与硬件需求评估
关于 Hy4 preview 的部署，先泼一盆冷水：别幻想 770B 总参数的模型能随随便便跑起来。虽然 MoE 稀疏激活降低了计算量，但权重本身依然庞大。你需要做的是先算清楚账，再动手。
我们按常见的量化方案来估算。如果使用 FP8 量化，770B 参数权重大约需要 770GB 显存。如果压到 INT4，权重大约 385GB。前者你需要一台搭载 8 张 H100/H200 级别显卡的服务器；后者用 8 张 48GB 显存的专业卡（比如 L40S 48GB，单卡 48GB，8 卡共 384GB）勉强装得下。
这里必须强调一个容易被忽略的点：量化后的权重精度损失。INT4 量化对于 MoE 模型来说，效果损失通常比稠密模型更明显，因为专家之间的权重分布差异大，低位量化容易把某些专家的关键参数压坏。如果条件允许，优先用 FP8，实在不行再用 INT4，并且要做一次效果抽检。
那普通开发者怎么办？两条路：一是用 API，模型方通常会在开放权重的同时提供付费或免费额度的 API 服务，这是最省事的方式；二是等社区出蒸馏版或者小参数微调版，这类衍生模型往往更适合个人开发者实验。先别急着追求“本地跑 770B”，先把手头的业务跑通，比什么都强。
3.2 模型下载与推理框架选型
如果确认硬件可行，或者说你就是想在自己机器上跑一个量化版做实验，步骤大概是这样的。
第一步是获取权重。主流渠道就是从 Hugging Face 或 ModelScope 这些模型仓库搜索 Hy4 preview 的官方仓库，检查文件列表是否包含模型权重、配置文件、分词器等。下载前记得看仓库的 README 和 LICENSE，官方通常会给出推荐的推理框架和最低配置要求。
第二步是选择推理框架。目前对大模型支持比较好的开源框架主要是 vLLM 和 SGLang。vLLM 对 MoE 模型的支持相对成熟，支持张量并行、量化加载、连续批处理，吞吐量表现不错。如果你的应用偏向高并发服务，vLLM 是优先选择。SGLang 在多轮对话和复杂提示词场景下有一定优势，但你需要在两个框架之间做一次实测对比，因为具体性能因模型和硬件而异。
第三步是配置启动参数。以 vLLM 为例，启动服务时的几个关键参数是：--tensor-parallel-size表示张量并行度，一般设置为 GPU 卡数；--quantization指定量化方式；--max-model-len控制最大上下文长度。如果你是第一次跑，建议先设一个较短的上下文长度（比如 8192），等服务稳定了再往上涨。直接上长上下文很容易触发显存溢出。
3.3 WorkBuddy 的安装与一个完整的工作流搭建实例
WorkBuddy 的安装本身不复杂。如果它提供的是桌面版，通常就是下载安装包，注册账号，然后在设置里配置模型后端——可以选择官方 API，也可以填一个你自己部署的模型服务地址。如果你想体验完整的“模型+工具”闭环，把本地模型服务地址填进去，用 WorkBuddy 作为前端交互层，这是最接近生产环境的一种用法。
下面用一个我实际搭建过的“行业情报日报”工作流来演示。任务需求是：每天早上自动整理前一天某几个方向的公开信息，生成一份摘要日报。
第一步，创建工作流，命名“行业情报日报”。第二步，添加第一个节点“抓取信息”，配置数据源关键词，这一步需要填入你关注的领域词，WorkBuddy 会调用搜索工具取回相关条目。第三步，添加第二个节点“内容过滤”，指令设置为“去掉重复内容，只保留与关键词强相关的条目”。第四步，添加第三个节点“生成日报”，指定输出模板：标题、日期、摘要、原文链接。第五步，设置触发方式，让我每天上午 9 点收到结果。
这样一套流程搭下来，大概二十分钟。关键不在操作本身，而在于你要学会把任务拆成节点。节点拆得越细，中间的调整空间越大。比如发现某个数据源的噪音太大，你只需要修改“内容过滤”那个节点，而不需要推翻整个流程。
4. 常见问题与排查技巧实录：跑 MoE 模型和用 WorkBuddy 遇到的坑
4.1 部署与推理过程中的典型问题
先说一个我踩过好几次的坑：显存算对了，但还是 OOM。原因是很多人只算了权重占用的显存，忘了 KV Cache 也在涨。上下文越长，KV Cache 占用越大，而且 MoE 模型的 KV Cache 计算方式和稠密模型没有本质区别，同样要预留空间。解决办法是启动时把max-model-len调小一点，或者用--gpu-memory-utilization参数限制显存利用率，给 KV Cache 流出余量。
第二个常见问题是推理速度“慢得离谱”。MoE 模型因为需要加载多个专家权重，在某些硬件上会因为频繁换入换出权重导致延迟变高。如果你用的是消费级显卡，组内专家数量多的时候，每个 Token 都可能触发权重加载，速度自然上不来。这种情况不是模型的问题，是硬件规格撑不起 MoE 的调度开销。建议下调批量大小，减少并发请求，优先保证单请求延迟。
第三个问题是权重文件损坏或下载不完整。大模型的权重文件动辄几十 GB，下载中断是常态。解决方法是核对 SHA256 校验值，或者使用支持断点续传的下载工具从模型仓库拉取。千万不要图省事跳过校验，等到推理时出现莫名其妙的乱码，排查起来更痛苦。
4.2 WorkBuddy 使用中的典型坑与处理建议
WorkBuddy 使用中第一个容易踩的坑，是把技能定义得太宽泛。比如“帮我整理文档”这个指令，看起来很自然，但模型不知道它应该总结、还是翻译、还是提取关键数据。我的建议是每一个技能都要明确三个要素：输入格式、处理规则、输出模板。缺一个，结果质量就会飘。
第二个坑是工具调用失败。WorkBuddy 在编排过程中会调用外部工具，比如搜索、读取网页、操作本地文件。很多时候任务中断并不是模型理解出了问题，而是工具返回了异常结果没有被正确捕获。排查时可以打开运行日志，定位到具体是哪个节点执行异常，再针对那个节点的输入做调整。不要一上来就推翻整个工作流，先做局部修正。
第三个坑和免费期有关。限时免费的逻辑是“时间窗口”，不是“永久免费额度”。两周之后如果你没有付费，技能和工作流可能会被冻结或受限。建议在免费期内把关键配置导出备份，尤其是你自己写的技能模板。免费窗口结束如果觉得好用，可以直接导入继续用；觉得一般，也不损失什么。
4.3 关于这次发布，我个人的几条实操心得
我实际把这次发布的几个关键词串起来看，最大的感受是：MoE 开源模型的密度正在快速提升，而工具的成熟度决定了这些模型能不能真正被用起来。Hy4 preview 解决的是“模型能力从哪来”，WorkBuddy 解决的是“模型能力怎么用”。这两件事放一起，才是一个完整的落地闭环。
另外提醒一下，preview 版本的模型在生产环境要谨慎。正式版发布前，接口、权重、配置都可能有变化。如果你已经用 preview 版本做了业务对接，记得留意官方公告，尽早规划升级路径。现在 Hy4 preview 刚发布，社区的量化脚本、部署教程、微调经验还在陆续沉淀中，过一两周再去搜索，能找到的现成资料会多很多。这个节奏，比第一时间冲上去当小白鼠要舒服得多。
我个人后续会重点观察两个方向：一是社区能不能把 Hy4 preview 的 INT4 量化做稳，这直接决定小规模硬件团队能不能吃得下；二是 WorkBuddy 免费期结束后，技能生态能不能沉淀下来。这两点如果都成立，那这次发布就不只是“多了一个大模型”，而是做实了一条“超大模型+编排工具”的落地路径。
