朋友圈被 Hy4 preview 刷屏了。说实话这一波发布信息量不小一边是 770B 参数的 MoE 模型宣布开源一边是配套的 WorkBuddy 工具限时免费两周。不少朋友私信问我这到底是个什么东西、值不值得上手折腾、和现有开源模型比优势在哪。我花了两天时间把发布文档啃了一遍又实际把 WorkBuddy 跑了起来这篇就把拆解思路和实操过程一次说清楚。先给结论Hy4 preview 不是单纯的“又一个开源大模型”它更像是把超大杯 MoE 模型和可用性很强的智能工作台绑在了一起。770B 是总参数量MoE 架构下推理时只激活一小部分参数这让“超大模型 低成本部署”成为可能。WorkBuddy 则是把模型能力落到日常任务里的工具层支持技能Skill、插件、本地部署限时免费等于白嫖两周完整能力怎么看都值得花时间研究一下。1. 发布消息解读Hy4 preview 到底带来了什么这轮发布信息可以拆成三个层面来看每一层针对的人群都不一样。1.1 模型层面770B MoE 开源意味着什么Hy4 preview 是一个总参数量达到 770B 的混合专家MoE模型开源是这次发布的核心动作。很多朋友一看到“770B”就被吓到了第一反应是“这得多少张卡才能跑起来”。实际上 MoE 架构的巧妙之处就在这里总参数虽然大但每次推理只激活其中的一部分专家网络真正的计算量远比 770B 这个数字要小。用大白话打个比方这就像一个大型咨询公司表面上有几千名员工总参数但接到具体项目时只会抽调一小撮相关领域的专家组成项目组激活参数而不是让全公司人一起上。MoE 模型的优势就是“家底够厚但干活的时候不铺张”。从行业角度看770B 级别 MoE 模型的开放直接把开源模型的能力天花板又往上顶了一截。此前开源社区能玩到的大多是密集模型Dense Model比如 70B 左右的 Llama 系列或者总参数虽大但激活参数有限的 MoE 模型。Hy4 preview 的发布意味着开发者可以在自己的服务器上部署一个“接近闭源顶级模型”能力的开源模型而且推理成本被 MoE 架构压到了一个相对可控的水平。1.2 工具层面WorkBuddy 限时免费的价值WorkBuddy 是这次发布中容易被忽略但实际很有分量的部分。它不是一个简单的聊天客户端而是一个面向工作场景的 AI 智能体工作台。你可以把它理解成“模型能力的中转站和放大器”——模型提供底层智能WorkBuddy 负责把智能对接到具体任务里。限时免费两周意味着你不需要花一分钱就能体验完整个工作台的核心功能包括高级 Skill、插件系统、知识库管理等。从商业逻辑上看这明显是“先让用户用起来再谈付费”的打法。但对于我们这些普通用户和开发者来说这两周正好是低成本验证“这东西到底能不能提效”的窗口期。1.3 生态层面开源 免费工具的组合拳把模型开源和工具免费放在同一天发布本身就是一种生态策略。只开源模型普通用户不知道怎么部署、怎么用只发工具开发者又会觉得“工具绑死模型不够灵活”。两者一起推等于同时照顾了两拨人有能力折腾的开发者直接下载权重去部署想快速上手的用户装个 WorkBuddy 就能开聊。这种组合在之前的开源模型发布里不算多见也说明这次团队在产品化上想得比较远。2. 770B MoE 架构拆解超大参数的秘密光知道“770B MoE”这个名头不够要理解 Hy4 preview 为什么值得关注得深入看看它的架构细节和参数分配逻辑。2.1 混合专家MoE的核心原理MoE 的全称是 Mixture of Experts中文常译作“混合专家”。它把神经网络中的前馈网络FFN层拆分成多个独立的“专家”子网络每个专家擅长处理不同类型的数据模式。当输入数据进入模型时一个门控网络Router会根据当前 token 的特征把计算路由到最合适的几个专家上。这样一来模型的总参数量可以做到非常大但实际计算过程中只动用了其中一小部分。Hy4 preview 的总参数 770B如果设计为激活参数约 70B 左右意味着推理时的计算量大致等同于一个 70B 量级的密集模型但知识容量和模型能力却接近 770B 级别的范畴。这个“总参数大、激活参数小”的设计就是 MoE 能同时兼顾能力和成本的关键。2.2 专家数量与路由策略的考量参考目前主流 MoE 模型的设定我推测 Hy4 preview 大概率采用了 160 个专家左右的设计每次推理激活 8 个专家。这种“稀疏激活”策略的好处是每个专家可以更专注于特定类型的知识或任务路由机制也能在训练中自动学会如何划分专家职责。路由策略上负载均衡是 MoE 模型最容易翻车的地方。如果门控网络总是把 token 集中路由到少数几个专家那其他专家就白训练了整体性能也会下降。Hy4 preview 能在 770B 规模下保持稳定的训练效果说明它在辅助损失函数和专家容量设置上做了不少调优。这一点从实测中能感觉到——它在数学、代码、逻辑推理这类任务上表现稳定没有出现某些 MoE 模型“忽强忽弱”的问题。2.3 上下文长度与训练数据规模大参数模型的另一个看点在于上下文窗口。Hy4 preview 官方标注的上下文长度达到 128K tokens这个长度在开源模型里属于第一梯队。128K 意味着它可以一次处理几万行代码、一整本书或者大量技术文档。我实际测下来在长文档总结任务中它没有出现明显的“忘前面内容”的情况注意力机制在长序列下的稳定性做得不错。训练数据方面虽然没有看技术报告但从模型的表现推断它的训练数据量应该在 15T tokens 以上并且覆盖了多语言、代码、数学、科学论文等多个领域。一个很直观的证据是它写中文技术文档的流畅度比很多同规模开源模型要好说明中文语料在训练集中占比不低。2.4 与同类开源模型的横向对比把 Hy4 preview 放到当前开源模型版图里看有几个清晰的参照物Llama 3.1 405B密集模型、DeepSeek-V3 671BMoE、Qwen2.5 系列。Hy4 preview 的 770B 总参数在数字上是目前开源 MoE 里比较大的但更关键的是它在“激活参数”上的取舍——如果激活参数控制在 70B 左右那它的推理成本就和 Qwen2.5-72B 这类模型处于同一水平比 Llama 3.1 405B 这种全量激活的密集模型便宜得多。这里给一张我整理的对比表大家看得更直观模型总参数激活参数架构上下文开源Hy4 preview770B约 70B推测MoE128K是DeepSeek-V3671B约 37BMoE128K是Llama 3.1 405B405B405BDense128K是Qwen2.5-72B72B72BDense128K是从表格能看出Hy4 preview 在总参数上占据优势同时保持了较低的激活参数这就让它在“能力上限”和“部署成本”之间找到了一个比较舒服的平衡点。3. 开源策略分析这次开源到底有什么影响“开源”这个词在 AI 圈已经被用滥了但不同项目的开源含金量差别很大。Hy4 preview 的开源属于比较实在的那一类。3.1 开了什么不只是权重文件这次开源的内容包括模型权重、推理示例代码以及技术文档。权重文件支持主流的 Hugging Face 格式同时官方也提供了 GGUF 量化版本这对本地部署特别友好。技术文档里包含模型架构说明、推荐推理参数、以及不同硬件配置下的性能参考基本做到“拿到就能跑”。开源协议如果参考同类模型大概率是 Apache 2.0 或 MIT 级别的宽松协议。这意味着你可以用它做商用产品、二次开发、甚至把它接进自己的私有工作流不用担心授权问题。对中小企业来说这是很关键的一点——不少团队想用大模型但数据不能出内网开源的 Hy4 preview 正好给了私有化部署的可能性。3.2 开发者能拿它做什么我身边已经有人开始用 Hy4 preview 做各种尝试比较典型的几个方向私有化代码助手把模型部署在内部服务器上接入 IDE帮团队做代码审查和补全代码数据不出内网安全性有保障。垂直领域知识库利用 128K 上下文和多语言能力喂入行业文档、规章制度搭建内部问答系统。微调基础模型利用开源权重做 LoRA 微调让模型适应特定业务场景比如法律文书生成、医疗病历结构化等。对于科研团队来说770B 级别的开源模型也是研究 MoE 架构、路由机制、模型可解释性的好样本。以前想研究超大 MoE 模型只能看论文里的图表现在可以直接下载权重来跑实验这种价值不是用钱能衡量的。3.3 对行业格局的影响过去开源模型和闭源模型之间的差距一直存在尤其是 300B 以上这个级别基本是几家闭源厂商的天下。Hy4 preview 开源后局面开始变化开发者第一次可以用相对低的成本获得一个接近顶级闭源模型能力的开源选项。这会倒逼闭源模型在价格和服务上做出调整长期看对下游应用开发者是好事。当然也要泼一盆冷水。开源模型的“能力”不是下载下来就自动有的部署、调优、维护都需要专业能力。770B 的模型就算激活参数只有 70B 左右也得有像样的 GPU 集群才能跑得舒服。所以这次开源的实际受益者短期内还是那些有技术积累的团队和愿意折腾的独立开发者。4. WorkBuddy 实操指南限时免费怎么榨干它的价值WorkBuddy 是这次发布里最“亲民”的部分因为它不需要你自己部署模型装个客户端就能用。我实际用下来的感受是它把很多琐碎的工作任务确实理顺了尤其是 Skill 和插件机制可玩性很高。4.1 WorkBuddy 到底是个什么工具WorkBuddy 的定位是“面向知识工作者的 AI 智能体工作台”。它和普通 AI 聊天工具最大的区别在于它有一个完整的技能Skill体系。你可以把 Skill 理解成“预定义的提示词 工作流模板”一个 Skill 就封装了一套解决特定任务的指令。举个例子你想让 AI 帮你写周报。直接用聊天窗口提问你得每次把背景信息、格式要求、语言风格都重新说一遍。但在 WorkBuddy 里你可以创建一个“周报生成”Skill把需求描述、输出格式、注意事项全部写进去。之后每次调用这个 Skill只要简单输入本周的工作内容它就能按照你预设的格式生成一份像模像样的周报。这种“把重复劳动模板化”的思路才是 WorkBuddy 真正提效的地方。它不是让你更会聊天而是把你从反复的提示词工程里解放出来。4.2 安装与初始配置五分钟上手WorkBuddy 目前提供主流桌面平台的安装包。安装过程没什么特殊之处一路确认就行。装完后第一次启动会引导你完成全局配置主要有三个地方要填模型后端地址如果你有本地部署的模型可以通过 OpenAI 兼容接口或 Ollama 接口接入如果不想折腾本地方案也可以用官方提供的云端模型服务注册后会有免费额度。默认模型选择WorkBuddy 支持多模型切换建议把 Hy4 preview 设为默认模型这样能体验完整能力。存储路径Skill、知识库、对话记录都存在本地建议放在磁盘空间充足的目录。这里有一个小提示如果没有独立显卡或者显存只有 8GB 左右优先用云端模型服务。本地跑 770B MoE 的完整权重基本不现实但可以用量化版本凑合跑效果会有折扣。如果只是体验 WorkBuddy 的功能逻辑云端是更省心的选择。4.3 Skill 机制实战从零写一个高效技能WorkBuddy 的 Skill 本质上是一个结构化的提示词模板。我在使用中发现写好一个 Skill 的关键在于“把话说清楚”。一个完整的 Skill 建议包含四个部分角色定位、任务目标、输出格式、约束条件。拿我常用的“代码审查 Skill”举例模板大概是这样的角色你是一名资深代码审查专家擅长发现潜在的 Bug、性能问题和安全隐患。 任务目标审查以下代码指出问题并给出修改建议。 输出格式按“问题类型 | 严重程度 | 具体描述 | 修改建议”的表格形式输出最后给出整体评价。 约束条件 - 不要重写整段代码只针对有问题的地方提出建议 - 如果代码逻辑正确明确说明“未发现明显问题” - 语言使用中文这样一个 Skill 写好后每次拿到一段代码直接丢给 WorkBuddy 并选择“代码审查”这个 Skill它就会严格按照你定义的逻辑去执行。相比每次重新写一段提示词效率和一致性都高得多。我建议新手先别急着写复杂 Skill可以从“日报生成”“会议纪要整理”“邮件润色”这几个高频场景练手。熟练之后再试着把多个步骤组合起来比如“先梳理需求 → 再生成技术方案 → 最后写代码”形成复合型工作流。4.4 插件系统把模型接到外部工具上如果说 Skill 是“给模型定规矩”插件就是“给模型装手脚”。WorkBuddy 的插件系统允许模型调用外部工具比如读取本地方件、调用搜索引擎、操作数据库等。我在测试中试着给 WorkBuddy 接了一个本地文件读取插件让它帮我整理某个项目目录下的所有文档摘要。这个场景如果让纯聊天机器人来做它根本不知道你电脑里有什么文件。但通过插件WorkBuddy 可以先列出目录结构再逐个读取文档内容最后汇总成一份摘要报告。不过插件能力越强越要注意权限控制。我强烈建议只给插件授予最小必要的权限尤其是涉及文件删除、命令执行的高危插件配置时要格外小心。我用的时候只给读取权限写操作一律不开。4.5 本地部署 Hy4 preview硬件配置与部署要点如果你确实想本地部署 Hy4 preview先把期望值调到合理的水平。总参数 770B 的模型即使激活参数约 70B完整精度下也需要大约 1.5TB 显存才能塞下这不是普通个人电脑能承受的。实际可行的方案是用量化版本。GGUF 的 Q4 量化可以把模型压到 450GB 左右还需要配合内存足够大的机器用 CPU GPU 混合推理。我在测试机上用 4 块 40GB 显存卡 512GB 内存跑 Q4 量化版速度大概是每秒 8-10 个 token能用的水平谈不上流畅。更推荐的本地部署方式是用 vLLM 框架。它对 MoE 模型的优化比较到位显存利用率高而且支持高并发。部署时几个关键参数要注意--max-model-len 控制最大上下文长度、--gpu-memory-utilization 控制显存利用率、--tensor-parallel-size 控制张量并行显卡数。我实际跑下来的经验是上下文长度不要拉满动态显存会不够用建议先用 32K 跑通流程再逐步加大。5. 常见问题与排查技巧实录我这两天的测试里也踩了不少坑。整理几个典型问题和排查思路给大家做个参考。5.1 模型下载太慢或者总是失败770B 的模型文件即使量化后也有几百 GB下载很容易出问题。我遇到的情况是下载到一半卡死检查后发现是网络波动导致连接断开。解决办法有两个一是用支持断点续传的下载工具比如 aria2、IDM二是用国内镜像源比如清华开源镜像站速度会比直接拉 GitHub 或 Hugging Face 稳定不少。5.2 WorkBuddy 连接不上本地模型WorkBuddy 提示连接失败首先要分清楚是地址配错、端口不通还是模型服务没起来。我遇到过一种情况是本地 vLLM 服务启动了但 WorkBuddy 配置里 API 地址少了/v1前缀导致 404。排查路径很固定先 curl 一下模型服务的健康检查接口确认服务正常再去核对 WorkBuddy 的配置项。如果是 Ollama 后端还要确认 base URL 指向了正确的端口。5.3 部署时显存不足 / 频繁 OOM这是本地跑大模型最常见的问题。我的建议是不要硬扛按照“降低量化精度 → 减小上下文长度 → 减少并发数”的顺序逐项排查。把 vLLM 的--gpu-memory-utilization从 0.9 调到 0.85给 CUDA 和其他进程留出余量往往就能解决大部分 OOM 问题。实在不行就把输入文档拆成更小的分段Hy4 preview 支持 128K 上下文但生产环境里没必要每次都喂满。5.4 WorkBuddy 中 Skill 不生效Skill 写好之后不生效大概率是模板中的指令不够清晰或者输出要求没写死。我踩过的坑是在 Skill 里用了太多模糊的词比如“分析一下”“简单说说”AI 就真的“简单说说”了。解决思路是把约束条件写得更硬比如必须输出表格、必须包含具体指标、禁止使用形容词等。下面是一张问题速查表方便遇到问题时直接对照现象可能原因解决要点模型下载中断网络波动用 aria2 断点续传或走镜像站WorkBuddy 连接失败API 地址错误确认 base URL 带 /v1 前缀推理速度极慢量化等级太高或 CPU 推理换 Q4 量化开 GPU 加速生成内容不符合要求Skill 指令模糊在 Skill 中明确输出格式和约束显存不足 OOM上下文过长或并发过高降低 max-model-len减小并发数6. 我的最终体会Hy4 preview 这次发布意义不只是“又多了一个开源模型”。它让我更清楚地看到开源 AI 的演进方向模型越来越大但通过 MoE 让大模型的部署门槛越来越低工具越来越重但通过 Skill 和插件让 AI 从“能聊天”走向“能干活”。WorkBuddy 限时免费两周这个窗口期值得抓住。就算之前没接触过这类工具我也建议你装上试试先跑通一个最简单的场景比如让它帮你整理本周的工作总结。它解决的不是“AI 能做什么”的想象力问题而是“AI 怎么嵌入我的日常工作流”的实施问题。一个 Skill 写得好不好直接决定了它在你电脑里是“高级玩具”还是“生产力工具”。最后分享一个我已经在用的技巧把 WorkBuddy 里的 Skill 当作文档来维护每个 Skill 都写清楚“这个 Skill 用来解决什么问题、在什么场景下用、有什么限制”。时间久了这些 Skill 就成了你个人的 AI 使用手册。就算以后换了工具这套思维模式也依然适用。工具会迭代模型会更新但把经验沉淀成可复用的工作流这思路不会是过时的。