Hy4 preview 发布：770B MoE 开源，WorkBuddy 限时两周免费用
最近开源圈又炸了一波：Hy4 preview 正式发布，770B 参数的 MoE 大模型，直接开源。与此同时，配套的智能工作台 WorkBuddy 也开启了限时两周的免费体验。这个消息我在好几个技术社群里都看到了讨论，但不少人其实没搞清楚几个关键点：770B 到底意味着什么？MoE 架构为什么能撑起这么大规模？WorkBuddy 又是做什么用的，跟普通聊天工具有什么区别？
这篇文章我就把这几个问题掰开揉碎讲清楚，顺便把部署和接入的实战路径也整理一遍。不管你是刚入门的大模型爱好者，还是已经在做本地部署的开发者，这篇内容应该都能给你一些参考。
1. Hy4 preview 的核心看点：770B 参数与 MoE 架构
1.1 770B 是什么概念
先说结论：770B 指的是模型总参数量达到 7700 亿。这个数字放在开源模型里，属于目前天花板级别的存在。用个更直观的类比，如果你把每个参数想象成一张便利贴，7700 亿张便利贴平铺开来，大概能绕地球好几圈。
但参数多不代表一切，关键要看这些参数是怎么用的。Hy4 preview 采用的是 MoE（Mixture of Experts，混合专家）架构，这一点比参数量本身更值得关注。
MoE 架构的核心思路是“分工合作”。它把模型内部拆分成多个“专家”子网络，每个专家擅长处理不同类型的任务。当输入一段文本时，模型不是让所有专家都参与计算，而是通过一个路由机制，挑选最合适的几个专家来处理。这样做的好处非常明显：总参数量可以做得很大，但每次推理时真正被激活的参数只有一小部分。
这种方式相当于一个大型咨询公司，表面上有几千名顾问（总参数），但接到具体项目时，只派出最对口的四五个人去干活（激活参数）。公司规模撑住了，单个项目的响应速度却不会因为公司人多而变慢。
1.2 MoE 架构到底解决了什么问题
要理解 MoE 的价值，得先看传统稠密模型的瓶颈。一个常规的大模型，所有参数在每次推理时都会被激活。参数越多，推理需要的算力和显存就越高，而且这个增长是线性的。这也是为什么很多团队在模型规模到 70B、100B 之后就很难继续往上堆参数——不是模型效果不行，是硬件实在扛不住。
MoE 打破了这种线性关系。Hy4 preview 虽然总参数 770B，但从目前公开的资料来看，它的激活参数应该控制在合理范围内。具体激活了多少还没看到官方精确数字，但按照同类 MoE 模型的惯例，激活参数通常在总参数的 10% 到 20% 之间。也就是说，实际推理时可能只需要加载百亿级别的参数，显存压力比同规模的稠密模型小一个数量级。
这意味着什么？意味着一个拥有 770B 总参数的模型，理论上可以在比预期低得多的硬件配置上跑起来。对于想要本地部署尝鲜的开发者来说，这是一个非常现实的利好。
1.3 MoE 的短板和需要注意的地方
当然，MoE 不是银弹。我实际用过几个 MoE 模型，说几个常见的坑：
首先是显存占用仍然不可小觑。激活参数少不等于模型文件小，加载模型时还是要加载全部权重，只是推理计算时部分专家不参与运算。比如 Hy4 preview 的权重文件，即使在量化之后，体积依然相当可观。想要本地跑，至少得准备好大容量显存的显卡，或者用多卡方案。
其次是路由机制对推理延迟的影响。MoE 模型在推理时多了一步“路由判断”，遇到某些复杂任务时，如果专家分配不合理，响应速度可能会比预期慢。实测下来，短文本任务感觉不明显，但长上下文生成时会有一些延迟波动。
第三个问题是生态兼容性。MoE 模型虽然架构先进，但一些推理框架和工具链对它的支持还不够成熟。比如某些早期的量化工具，直接套用到 MoE 模型上会报错，需要手动做一些兼容设置。
2. WorkBuddy 是什么：不只是聊天助手
2.1 WorkBuddy 的定位与核心功能
说完了模型，再看看这次同步推出的 WorkBuddy。从名字上看，这就是一个面向工作场景的智能助手平台，但实际用下来，它跟那种“你问我答”的聊天机器人完全不是一个物种。
WorkBuddy 更像是一个搭在 Hy4 preview 上面的“工作台”。它把模型能力封装成了各种可调用的工具和流程，让用户可以直接用它来处理实际工作流里的任务。我目前体验到的主要功能包括：
- 文档理解与摘要：上传长篇技术文档，它可以快速提炼核心要点，还能针对特定章节追问细节。
- 多轮任务规划：不是简单的一问一答，而是能把一个复杂任务拆解成多个步骤，逐步推进并自动调整方案。
- 代码辅助：支持代码生成、调试建议、重构思路，跟模型底层的代码能力是对齐的。
- 工作流编排：可以把多个任务串成一个流程，比如“读取数据 -> 生成分析报告 -> 提炼结论 -> 整理成PPT大纲”，一次配置，后续反复使用。
这里面最有价值的是工作流编排。说实话，市面上能做单轮对话的 AI 工具太多了，但能把多个能力串成业务流程的，目前仍然不算多。WorkBuddy 这条路算是踩对了方向。
2.2 “限时两周免费”怎么理解
这次 WorkBuddy 推出限时两周免费策略，内部逻辑并不复杂：先让一批用户深度使用，收集真实反馈，同时形成口碑传播。对用户来说，这当然是个好消息，等于两周时间可以零成本体验完整功能。
我的建议是不要浪费这两周。拿到免费资格之后，先把自己的日常工作梳理一遍，找出那些重复性高、流程固定的任务，把它们在 WorkBuddy 里跑通。两周时间足够你判断这个东西到底能不能提升效率，也足够你积累一套自己的使用模板。
需要注意，免费期结束后是怎么收费、会不会保留免费额度，目前官方还没有明确的说法。如果你在体验过程中配置了比较复杂的流程，建议及时把配置导出备份，免得权限变化之后还要重新搭建。
2.3 WorkBuddy 与类似工具的差异点
现在市面上类似的“AI 工作台”不少，但 WorkBuddy 有一个比较独特的点：它跟 Hy4 preview 是深度绑定的。这不是简单的 API 调用关系，而是在模型能力之上做了定制化的任务封装，比如模型擅长的领域知识被预置到了各种 Skill 里，用户直接用就行，不需要自己去写 Prompt。
之前有人问过 CodeBuddy 和 WorkBuddy 的区别。我理解是这样：CodeBuddy 更专注于代码场景，面向的是程序员；WorkBuddy 覆盖的范围更广，适合做文档处理、信息汇总、流程自动化这类通用办公任务。两者定位不同，面向的用户群体也不完全重叠。
当然，WorkBuddy 目前的 Skill 机制还在完善中，跟一些老牌工具的插件生态比还有差距。但考虑到它刚推出，功能迭代的速度应该会很快，现在入手算是比较早的窗口期。
3. 部署与实战：从想法到落地
3.1 硬件选型的底层逻辑
如果你想把 Hy4 preview 跑起来，第一步是解决硬件问题。我个人的建议是：先别急着买显卡，根据你的实际需求倒推。
先搞清楚你要用模型做什么。如果是个人玩一玩、跑跑推理测试，那么量化之后的模型配合大显存单卡是最经济的方案；如果是团队级应用，需要高并发、低延迟，那就要考虑多卡推理集群。
内存方面多说一句，除了显存，系统内存和交换分区也要提前规划好。加载超大模型时，如果显存不够，系统会动用内存做交换，速度会明显下降。我见过不少人在这上面栽跟头，显卡买得很猛，系统内存却只有 16G，结果模型加载到一半直接崩溃。
3.2 本地部署 Hy4 preview 的完整流程
假定你已经有一张 48G 显存的显卡（如果显存小一些，就选择量化程度更高的版本），我来梳理一下部署的整体思路。具体的命令不贴了，每个环境差异很大，写死命令反而容易误导人。
第一步，准备环境。建议使用 Linux 系统，NVIDIA 驱动和 CUDA 版本要匹配。举个例子，如果你用的是较新的显卡，驱动版本至少要到 535 以上，CUDA 建议 12.1 以上，否则后面运行大模型时会报各种奇怪错误。
第二步，拉取模型。HuggingFace 上有社区的镜像仓库，下载之前先看清楚模型文件的格式。fp16 格式的体积最大，int8 其次，int4 最小。显存不够的时候优先选 int4，但要注意量化后的效果会打折扣，尤其是在逻辑推理类任务上。
第三步，选择推理框架。目前主流的方案是 vLLM 或 TGI，两者都针对大模型推理做了优化。我推荐先用 vLLM，它对 MoE 模型的支持在持续迭代，社区也比较活跃。启动服务的时候记得设置好--max-model-len，这个参数控制上下文长度，设置太小影响使用体验，设置太大可能爆显存。
参数计算这里我展开一下。一般来说，模型加载占用的显存可以用这个公式粗略估算：权重字节数加上 KV Cache 开销。比如 fp16 格式下，每个参数占 2 字节，770B 总参数的理论权重就是 1.54TB，这个数字显然单卡跑不了。但因为你用的是量化版本，比如 int4 的话每个参数 0.5 字节，权重 385GB，依然很大。所以务必要看实际下载的模型文件大小，以那个为准来做硬件规划。我见过有人只看参数不看文件大小，结果下载了 600 多 G 的模型才发现一张卡根本装不下，白白浪费时间。
3.3 把 WorkBuddy 接入本地模型的流程
如果你想用 WorkBuddy 来接本地部署的 Hy4 preview，而不是直接用官方云端版本，流程也不复杂。关键是要在本地启动一个兼容 OpenAI API 格式的服务端点，然后在 WorkBuddy 里配置自定义模型地址。
具体来说，本地起好 vLLM 之后，会生成一个类似http://localhost:8000/v1的接口地址。在 WorkBuddy 的设置里找到“模型配置”或者“自定义模型”，填入这个地址，再设置好对应的模型名称和密钥（本地服务一般随手填一个就行），就可以完成接入。
这里分享一个实测小技巧：接入之后先用简单的任务做个验证，比如让它总结一段 200 字左右的文本。确认能正常返回之后，再去跑更复杂的任务。很多人一上来就扔一个大任务，结果响应超时，又不知道问题出在模型配置还是网络设置上，排查起来非常头疼。
3.4 性能调优的三个实操方向
第一次跑通之后，性能很可能是“能用但不够快”，这很常见。我梳理了三个调优方向：
第一个方向是并发优化。vLLM 支持 Continuous Batching，可以在等待显存分配的过程中处理新请求，大幅提升吞吐。你可以通过压测工具对比一下调整前后的每秒请求数变化，找到最合适的并发数值。
第二个方向是上下文窗口调优。Hy4 preview 支持长文本输入，但上下文越长，KV Cache 占用的显存就越多。你需要根据业务场景平衡上下文长度和并发数。如果大多数任务是处理较短文本，就没有必要把max-model-len设得特别大。
第三个方向是量化策略选择。很多人直接选 int4，但实测下来，int8 在特定任务上的表现比 int4 提升明显，而显存占用并没有成倍增加。如果你的显存刚好卡在边界，优先选 int8，宁可稍微调低一点并发。
4. 常见问题与排查技巧实录
4.1 模型加载失败的三大原因
我自己在部署其他模型时遇到过不少问题，这几类是最常见的：
第一类是 CUDA 版本不匹配。很多框架对 CUDA 版本很敏感，哪怕是小版本差异，也会导致加载时直接失败。排查方法很简单，跑一下 PyTorch 的 tensor 操作，看 GPU 是否能正常调用。如果这一步出问题，大概率是驱动和 CUDA 的问题。
第二类是模型文件损坏。下载大模型时网络波动可能导致文件不完整。这种情况在加载时会提示 mismatch 或 CRC 错误。解决办法是下载时核对校验值，或者重新下载问题文件。
第三类是显存不足导致 OOM。遇到 OOM 不要慌，先看报错信息是在加载阶段还是推理阶段。加载阶段 OOM，说明模型文件超过显存容量，需要换更小一点的量化版本，或者用多卡分流；推理阶段 OOM，则要检查是否上下文设置过长，适当降低max-model-len。
4.2 WorkBuddy 使用中的几个高频问题
根据我试用的体验和社区里的反馈，WorkBuddy 使用中比较常见的问题集中在几个方面。
一个是 API 接入后响应慢。这种情况先确认是不是在走本地模型。很多人配置了自定义模型地址，但实际请求还是打到了默认的云端服务上，两者混用导致行为异常。检查方式是在 WorkBuddy 的日志或者监控面板里看看请求去向。
另一个是 Skill 执行失败。出现这个问题，优先排查输入数据格式是否合规。WorkBuddy 的 Skill 对输入有隐性要求，比如某些 Skill 要求输入是纯文本或特定格式的表格数据，如果你传了不符合要求的内容，Skill 内部处理时就会异常。
还有一个是免费版的功能限制。限时免费不代表所有功能都完全放开，部分高消耗能力可能还有配额限制。如果你在操作中发现点某个功能没反应，先看看是不是触发了配额上限，而不是急着怀疑服务出问题了。
4.3 排查问题的方法论
最后分享一个排查思路，这个做法帮我解决过不少疑难问题，也推荐给你。
不要一上来就猜原因，先按照这个顺序检查：网络链路 -> 中间件配置 -> 模型服务状态 -> 前端/工具配置。
举个例子，WorkBuddy 连不上本地模型服务，很多人第一反应是模型配置写错了，改来改去都没用。其实先用curl命令直接访问本地服务的 API 地址，看看能不能正常返回结果。如果 curl 通，说明模型服务是正常的，问题大概率出在 WorkBuddy 的配置上；如果 curl 都不通，那就要检查服务有没有启动、端口有没有监听、防火墙有没有拦截。这个排查路径基本能覆盖绝大多数情况。
5. 两周免费期怎么玩出最大价值
5.1 第一周：建场景
刚拿到 WorkBuddy 免费资格的时候，不要东点一下西点一下，先选一个你最常做的工作场景，认真把它跑通。
我推荐从文档处理入手，因为这类任务反馈快、效果明显。比如你每周要花半天时间整理技术周报，就可以把周报模板和往期内容喂给 WorkBuddy，让它自动生成初稿，你只需要在初稿上做一些修订。这样试个几次，你对这个工具的边界就有感觉了。
过程中建议记录两样东西：一是哪些任务它做得又快又好，二是哪些任务总在某个环节卡壳。这个记录在免费期结束后非常有用，可以帮你决定要不要付费继续用。
5.2 第二周：建流程
第二周开始，就不只是单个任务了，可以尝试把一个完整的业务流程交给它。
比如你是一个项目经理，每周需要完成项目进度同步、风险识别、周报撰写、会议纪要整理等一系列任务。这些任务单独看都不复杂，但串在一起就很花时间。你可以利用 WorkBuddy 的工作流功能，把它们串联成一个自动化流程，数据输入之后，中间的过程全部由它来处理，你只需要审核最终产出。
这里我建议做一个 A/B 对比：挑一个具体任务，分别用手工方式和 WorkBuddy 流程执行，记录下各自耗用的时间。用真实数据来判断这个工具是否值得你在免费期结束后继续使用。
5.3 一些实打实的心得
最后说几条从实际使用中总结的经验。
不要把所有敏感数据都放进去。虽然是免费体验，但涉及公司机密、个人隐私的内容，还是要注意规避风险。工具虽好，安全第一。
模板化的任务最划算。越是重复性高、格式固定的任务，用 AI 提效越明显。那些创造性强、没有固定套路的工作，现阶段 AI 的帮助有限，不值得花太多时间去调。
官方文档和社区资料记得看。我试用过程中遇到的不少问题，其实官方文档里都有说明，只是需要花点时间去找。除了官方渠道，也建议留意一下技术社区里的实践分享，有些问题别人早就遇到过并且给出了解决方案，你只需要搜索就能找到，完全不用自己从头踩坑。
这次 Hy4 preview 和 WorkBuddy 的组合，算是开源大模型与落地工具协同的一次尝试。770B 的规模证明了 MoE 路线的潜力，而 WorkBuddy 的定位也踩中了“大模型要落地、必须走向工作流”这个趋势。开源只是第一步，真正考验生态的是工具链和应用场景。接下来的两周，是低成本试错的好窗口期，值得好好利用。
