昨天在技术群里看到有人转了一条消息：Hy4 preview 发布了，770B 参数、MoE 架构、权重开源，同时配套的 WorkBuddy 给了一个限时两周免费期。说实话，我第一反应不是“又多了一个模型”，而是“这波组合拳很有策略”——开源权重把技术人群吸引过来，WorkBuddy 再把非技术用户接住，两边都照顾到了。结合 770B MoE 和限时免费这两个点，能聊的东西相当多。
这篇文章我打算拆成四个层面来讲：先拆解 Hy4 preview 和 WorkBuddy 各自是什么，接着用“大白话+算账”的方式解释 770B MoE 到底强在哪、跑起来需要什么条件，再把开源模型的落地场景和许可证问题说清楚，最后给出一份可以直接照着做的本地部署和 WorkBuddy 接入教程。看完之后，你不仅能判断这波发布适不适合自己，还能在免费期内把工具真正用起来。
1. 组合发布拆解：Hy4 preview 与 WorkBuddy 各自扮演什么角色
1.1 标题里的三个关键词：770B、MoE、开源
先拆一下标题本身。Hy4 preview 是模型代号，preview 意味着这是预览版本，后续大概率还会有正式版；770B 表示参数量达到 7700 亿级别；MoE 是 Mixture of Experts 的缩写，中文叫混合专家架构，它和传统的稠密网络（Dense Model）有本质区别。至于 WorkBuddy，则是配套的智能体工具，主打低门槛、场景化，这次借着模型发布给了两周免费体验窗口。
这里有个容易忽略的点：770B 指的是模型的总参数量，而不是每一次推理都会用到的参数量。MoE 模型的一大特点就是“总盘子很大，但每次干活只动用其中一部分专家模块”。这和稠密模型完全不同——稠密模型无论输入什么内容，所有参数都会参与计算，一旦模型上到几百 B 级别，推理成本会直接爆炸。这也是为什么这两年各家都在转向 MoE 架构，不是因为它听起来高级，而是因为它在成本和能力之间找到了一个相对合理的平衡点。
1.2 模型发布加工具免费，这个策略背后的逻辑
如果把这次发布只看成“一个新模型开放下载”，视野就太窄了。Hy4 preview 开源模型解决的是“顶配能力怎么分发下去”的问题，而 WorkBuddy 解决的是“普通用户怎么把这股能力用起来”的问题。两个产品叠加，覆盖的人群一下就从工程师扩展到了产品、运营、市场甚至学生群体。
我做技术选型这么多年，一个特别深的感受是：开源模型再强，如果配套工具链不够顺滑，普通用户根本走不到最后一步。很多人下载了权重、部署了服务，结果卡在“我不知道该拿它做什么”这一步。WorkBuddy 这种工具的意义，就是把“模型”包装成“能直接干活的助理”，用户不需要关心端口、显存、推理框架，只要正常对话、配置几个技能，就能完成周报生成、代码审查、需求梳理这类高频任务。这其实是很多 AI 产品一直想做的事，只不过这次它跟一个 770B 的 MoE 开源模型绑在了一起，冲击力就更强了。
2. 770B MoE 的技术账：架构优势、门槛和部署可行性
2.1 MoE 架构的核心思想：总参数大，但脑子只动一小部分
很多人第一次听到 MoE 会觉得玄乎，我用一个比较生活化的类比来解释。假设你是一家大型咨询公司的老板，公司名册上有几百位行业专家，但你接到的每个项目并不会让所有专家一起上，而是根据项目特点，从中挑出最合适的五六个人组成临时小组。这个“挑选专家”的环节，在 MoE 架构里叫路由（Router），每个被挑中的专家模块负责处理输入的一部分特征，最后把大家的结论汇总起来输出。
这样做的好处非常明显：模型总参数可以做得很大，理论上“知识储备”更多，但每次推理实际激活的参数量远小于总量，计算成本和显存需求也因此变得可控。Hy4 preview 是 770B 的总参数，如果按常见的 MoE 设计，每次推理激活的参数量很可能在几十 B 量级，和纯稠密 70B 模型的单次开销差不多，但整体能力天花板高出一截。这也是 MoE 这几年能成为大模型主流方向的核心原因。
当然，MoE 也不是没有代价。路由机制本身会带来额外的通信开销，多卡部署时如果卡间带宽不够，性能会明显打折；同时，训练难度也比稠密模型高很多，需要更精细的负载均衡设计，否则容易出现“某些专家忙死、另一些专家闲死”的情况。这些属于模型设计的范畴，对于普通用户来说，只需要记住一句话：MoE 是“用更少的钱，买更大的模型能力”的工程化方案。
2.2 硬件门槛的真实账本：从全精度到量化
聊到部署，绕不开硬件。很多人一听到 770B 就以为“没戏”，其实没那么绝对，关键在于你用哪种精度去加载它。我把几种常见情况列出来，方便你对照手上机器评估。
| 加载精度 | 权重占用估算 | 最低硬件参考 | 适用情况 |
|---|---|---|---|
| BF16/FP16 | 约 1540GB | 16 卡 80GB 起步，或 8 卡 200GB | 追求高精度，适合企业级离线推理或研究用途 |
| INT8/FP8 | 约 770GB | 10 卡 80GB 左右，或用 CPU Offload 分摊 | 精度损失较小，多数生产环境可以考虑 |
| INT4 | 约 385GB 至 450GB | 8 卡 80GB 可以跑，但需要控制上下文长度 | 个人开发者、预算有限的最优选 |
这里的数字不是精确值，因为除了权重本身，推理时还要留出 KV Cache、激活值以及其他中间缓冲区的空间，实际操作建议至少按权重的 1.2 到 1.5 倍来预留。比如 INT4 量化后权重约 385GB，加上 Cache 和激活，8 张 80GB 的 A100/H100 会比较稳妥。
坦率地讲，个人开发者想一遍跑通本地部署，硬件确实是第一道坎。如果手头没有多卡服务器，我更推荐先走官方 API 或者云主机按时租用，把流程跑熟了再决定要不要上本地。硬件焦虑没有必要，毕竟大多数人的业务规模根本用不满本地算力。
2.3 横向对比：Hy4 preview 在开源生态里的位置
我不太喜欢做那种单纯比分的评测，因为不同模型的训练数据、对齐方式和擅长场景都不一样，同一道题可能 A 模型答得好、B 模型答得差，换了题目结果可能反转。但从架构思路和生态定位上，还是可以聊几句。
近两年开源市场上比较有代表性的 MoE 模型，有 DeepSeek-V3 这种总参数 671B、激活参数 37B 的设计，也有 Qwen 系列在开源和性能之间做的各种尝试。Hy4 preview 选择 770B 总参数，说明它想走的是“大底座、高上限”的路线，不是靠一个紧凑模型打天下，而是先把知识容量拉满，后续再通过蒸馏、量化得出更小尺寸的版本。这个节奏其实很常见：先发大模型立标杆，紧接着发小模型吃市场份额。WorkBuddy 的免费期大概率也是为了尽快聚拢用户，为后续商业化铺路。
还有个小知识点，MoE 这个缩写在不同行业有完全不同的含义。在人工智能领域它是专家混合，在化学领域它可能指药物分子片段库（MOE 软件里的 MCS 分子片段模块），在计算机视觉领域还有 YOLO 系列结合 MoE 的探索。如果你是因为搜“MoE”误打误撞进来了，先确认自己到底想找的是哪个方向的资料，别把分子库和模型架构混为一谈。
3. 开源权重能拿来干什么：场景、许可证与避坑
3.1 开源模型的三大落地场景
每次有开源大模型出来，总会有人问“我能用它做什么”。根据我自己这些年跑开源模型的经验，真正适合开源权重落地的场景大致可以分成三类。
第一类是数据敏感和企业内部工具。很多公司不允许员工把内部代码、客户资料、财务数据传到外部 API，这时候本地部署开源模型几乎是唯一解。你可以把模型接到内部的工单系统、客服系统或者知识库上，数据全程不出内网，安全部门也比较放心。第二类是定制化微调。开源权重意味着你可以拿到底层参数，用业务数据做 LoRA 或者全参数微调，把模型的“说话风格”和“知识边界”往自己需要的方向掰。这一点闭源 API 基本做不到，或者说做一次的成本非常高。第三类是成本敏感的高频调用场景。如果业务量大，每天几十万次请求走商业 API 的费用非常吓人，自建推理服务一次性投入硬件，长期边际成本反而更低。
我看到不少团队犯过一个共同错误：一上来就追求“把开源模型完全替代商业 API”，结果折腾了一个月部署、调优、维护，最后发现总成本比直接买 API 还贵。开源部署不是银弹，它适合的是那些有明确需求、有技术人力、有长期调用量的场景，而不是单纯为了“省钱”去自我折腾。
3.2 开源不等于随便商用：许可证和合规细节
这一点必须强调，因为它实在太容易被忽略了。开源和“免费商用”是两个概念，不同模型采用的许可证差别很大。有的允许任意商用且没有附加限制，有的要求你必须开源衍生品，有的只允许个人研究、明确禁止商用。
如果你打算把 Hy4 preview 接入到自己的产品里，第一步不是跑模型，而是去读它的许可证。重点看几个地方：是否允许商用、是否要求保留版权声明、是否限制特定行业用途、是否要求开放你的衍生代码。如果拿不准，建议直接咨询懂开源许可证的律师或者法务，别等产品上线了再被版权方找上门。
另外，部署开源模型时还要注意训练数据的合规性。如果模型在训练时使用了你不清楚来源的语料，你用它生成的内容又恰好涉及敏感信息，风险就会层层叠加。我的习惯是：凡是商用，先做一轮生成内容抽检，确认输出里不会意外泄露个人隐私、商标或者第三方版权内容。这听起来很繁琐，但真出事的时候，你就能明白这一步有多值钱。
4. WorkBuddy 手把手使用记录：下载、配置到本地接入
4.1 安装与首次启动：先跑通官方默认配置
WorkBuddy 的定位是智能体工具，很多人第一反应是“又要写代码”，其实它的安装比想象中简单。关于下载渠道，我以常见的分发方式为例：一种是从官网下载桌面客户端，另一种是从 Git 仓库获取安装包。下载后直接双击按提示安装，Windows、macOS、Linux 都有对应的包，装完打开通常会进入一个引导界面。
第一次启动时，WorkBuddy 一般会让你选择模型来源。我建议你先别急着搞本地部署，直接用它的默认云端配置跑一遍，感受一下对话、技能调用和插件安装的完整流程。这一步是为了确定两件事：一是工具本身能不能在你机器上正常跑，二是你觉得它的交互方式顺不顺手。如果默认配置都还没跑通，就直接跳到本地接入，很容易把“环境问题”和“配置问题”混在一起，排查起来非常痛苦。
第一次对话可以简单点，让它帮你写一段周报，或者总结一篇长文章。重点观察响应速度、回答质量以及界面布局，心里有个底，后面做自定义配置时才知道往哪个方向调。
4.2 Skill、插件与自定义指令：把工具变成“私人定制”
WorkBuddy 最有价值的地方，其实是它的 Skill 机制和自定义指令。Skill 你可以理解成“预置的工作流模板”，每个 Skill 相当于一套针对特定任务封装好的提示词、参数和工具调用流程。比如你装一个“周报生成”的 Skill，它会自动按固定结构问你几个问题，然后生成一份符合团队格式的周报；装一个“代码审查”的 Skill，你只要把 PR 的 diff 贴进去，它就会按安全、性能、可读性几个维度输出问题清单。
插件则进一步扩展了工具边界，有些插件可以读取本地文件，有些可以调用外部 API，有些能访问数据库。这里的核心逻辑是：插件负责“连接外部世界”，Skill 负责“定义干活方式”，二者叠加之后，WorkBuddy 就不再是一个简单聊天窗口，而是一个可以执行复杂任务的数字助理。
自定义指令是另一个被很多人忽略的功能。你可以把团队规范、输出偏好、常用话术固化到指令里，让模型每次回复都按你的要求来。演示一个简单配置：
[角色] 你是一位资深技术负责人； [风格] 先给结论，再给理由，每个观点控制在三句话内； [输出] 使用 Markdown，行动项统一放在最后； [禁忌] 不要使用模板化开场白。这类指令看起来简单，实际效果非常明显。我自己的习惯是准备五六个“场景指令”，分别对应日常周报、会议纪要、需求分析、代码 review 和个人知识整理，用的时候直接选中对应指令，效率和一致性都会高很多。
4.3 接入本地开源模型的完整步骤
如果你手头已经有能跑 Hy4 preview 的硬件，把 WorkBuddy 接到本地推理服务不算复杂。整体思路是：先在本地启动一个兼容 OpenAI 协议的服务，再在 WorkBuddy 的模型设置里把接口地址指过去。
首先是启动推理服务。我习惯用 vLLM，它吞吐量高，对 MoE 模型的支持也比较成熟。命令大致是这样：
vllm serve /path/to/Hy4-preview-770B-MoE \ --tensor-parallel-size 8 \ --dtype bfloat16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --served-model-name hy4-preview需要注意几个参数：tensor-parallel-size要改成你实际的 GPU 数量；max-model-len控制上下文长度，如果显存紧张可以从 8192 开始试；gpu-memory-utilization可以根据剩余显存调整。如果你的硬件只够跑 INT4 量化，可以先把权重用 GPTQ 或 AWQ 量化好，再通过对应的加载方式启动，具体命令不同框架略有差异。
服务起来之后，先验证一下接口是否正常。在浏览器里访问 http://127.0.0.1:8000/v1/models，如果能看到模型信息，说明服务已就绪。接着打开 WorkBuddy 的设置页面，在模型配置里选择“自定义/本地接口”，填入：
接口地址: http://127.0.0.1:8000/v1 API Key: 随便填一个本地占位符（如 local-key） 模型名称: hy4-preview保存后重新发起一段对话，正常情况下 WorkBuddy 就会把请求转发到本地模型上了。整个流程最常出问题的点就是接口地址多了或少了/v1，以及端口号对不上，我建议启动服务后先用浏览器或者 curl 验证一次，再回 WorkBuddy 里配置。
5. 常见问题与两周免费期的实操心得
5.1 部署和接入典型问题速查
我在本地部署这类开源模型、接入第三方工具时，踩过不少坑，这里整理成一张速查表，方便你在遇到问题时快速定位。
| 问题现象 | 可能原因 | 排查和解决思路 |
|---|---|---|
| 启动推理服务时提示显存不足（OOM） | max-model-len 过长或加载精度过高 | 降低上下文长度；换成 INT4 量化；减少gpu-memory-utilization的预估值；或启用 CPU Offload |
| 推理速度非常慢 | 张量并行数不足、跨卡通信带宽低 | 增加tensor-parallel-size；确认服务器内使用 NVLink 等高速互联；避免频繁触发跨节点通信 |
| WorkBuddy 连不上本地服务 | base_url 少了/v1；端口写错；服务没起来 | 先访问 http://127.0.0.1:8000/v1/models 确认服务；检查 WorkBuddy 里的接口地址 |
| 模型回复质量忽高忽低 | 温度参数偏高；没加载官方提示模板 | 把 temperature 调到 0.6 左右；参考模型文档加上系统提示词；检查是否误用了过短的上下文截断 |
| API 显示认证失败 | 自定义服务仍需填写 API Key | 随便填一个占位符；部分服务端需要关闭鉴权或配置--api-key参数 |
| 首包响应正常，后续对话逐渐卡顿 | KV Cache 被占满 | 降低max-model-len；减少并发请求数；使用支持 PagedAttention 的推理框架 |
排查这些问题时有个很实用的思路：先确认“链路是否通”，再考虑“性能好不好”。比如 WorkBuddy 接不上，就先用浏览器访问接口；接口通了但很慢，再去看显存、并行数和通信；都正常但回答质量差，最后再调提示词和采样参数。从头到尾保持这个顺序，能少走很多弯路。
5.2 免费期值得做的三件事
WorkBuddy 限时两周免费，这段时间最不应该浪费在“到处提问、看热闹”上。根据我以往参与各种 AI 工具免费活动的经验，真正能沉淀出价值的做法是这三件事。
第一，建立你自己的技能包。把日常工作里重复率最高的三到五个任务，分别固化成 Skill 或自定义指令。比如写周报、整理会议纪要、生成项目复盘、写产品需求文档，每个都花半小时调试提示词，调好之后这些技能就是长期资产，免费期结束后还能继续用。第二，用真实业务数据做边界测试。别总拿“苹果是什么颜色”这种问题去测模型，没意义。把你过去一个月真实处理过的文档、代码、邮件脱敏后丢进去，看模型能帮你完成到什么程度。你会更清楚哪些环节可以放心交给它，哪些还得自己把关。第三，做好工具链的替代方案备案。免费期总会结束，提前想清楚：到期之后是续费、用本地模型，还是切换到其他工具。这个决策不要拖到最后一刻，否则容易在仓促中选错方案。
5.3 最后分享几个我的实践经验
聊到这儿，我想把最后一段留给我个人的真实感受。开源 MoE 模型和 WorkBuddy 这种工具的组合，最让我兴奋的其实不是“性能参数有多高”，而是它把“模型选择”和“工作流落地”这两件事彻底解耦了。以前我想让模型按特定流程干活，得自己写代码调接口、维护提示词；现在用 WorkBuddy 这类工具，很多工作流可以通过配置完成，改动起来也灵活很多。
如果你准备在免费期内深度使用，我建议你从一开始就维护一份自己的提示词和技能清单，每成功调好一个场景就记录下来，包括设计思路、迭代过程、踩过的坑。这样即使工具换了、模型换了，你沉淀下来的方法论依然值钱。另外，部署开源大模型这件事，别指望一次性完美，我的经验是先跑通、再调优，先用小上下文把链路跑顺，再逐步增加上下文长度和并发，这样每一步出问题都能定位到具体环节。最后再提醒一句：商用之前，一定先确认开源许可证的具体条款，别在这上面翻车。
