模型圈最近有点热闹Hy4 preview 一发布就带起了一波讨论。核心就三件事770B 参数的 MoE 架构、开源权重、以及 WorkBuddy 限时免费两周。很多人看到“770B”就下意识觉得“这玩意我跑不动”看到“开源”又觉得“可以白嫖了”但实际情况比这两句话要复杂得多。这篇文章就围绕这三个关键词展开聊聊 MoE 架构到底解决了什么问题、开源之后普通人能用什么、以及 WorkBuddy 这波免费活动怎么薅才划算。想搞清楚自己该不该跟风、以及跟风之后怎么上手的人建议完整看一遍。1. Hy4 preview 到底是什么770B MoE 的底层逻辑1.1 参数数量不是算力消耗MoE 才是关键先拆一下“770B MoE”。770B 是模型的总参数量也就是把模型里所有权重加在一起有 7700 亿个参数。“MoE”即混合专家架构Mixture of Experts这种设计最核心的一点是所有参数不会在每一次推理时全部参与计算。可以这么理解一个 770B 的稠密模型做任何一次回答都要读完整本百科全书而一个 MoE 模型相当于把知识拆进了几千个“部门”每次收到问题时先由一个路由器判断该找哪些部门再只调用其中一小部分。Hy4 preview 虽然总参数是 770B但实际每次推理只用其中一小部分参数通常称为“激活参数”。这个设计最大的好处是模型的知识容量很大但推理成本没有跟着失控。所以在判断“这个模型我能不能跑”的时候别一看到 770B 就绝望。需要先确认两个数据一是总参数二是激活参数。总参数决定的是模型文件的体积和部署时的显存下限激活参数才决定单次请求的算力开销。Hy4 preview 这种量级的模型总权重文件在 FP16 精度下就已经超过 1.4TB单卡基本别想分布式部署才是正经路子。1.2 Preview 版本到底能不能用“Preview”这个词容易被忽略但它是这次发布里非常重要的一个限定。官方把版本标成 preview说明这不是最终稳定版。通常意味着能力核心已经定下来了但边角功能有可能调整后续大概率会发正式版或者小版本迭代来修复问题。对普通用户来说preview 版本的实用价值在于“提前布局”。比如你是做 Agent 应用开发的提前把 Hy4 preview 接入到自己的流程里跑一跑评估集看看它在你业务场景里的表现等正式版出来时你的技术方案已经验证完了。如果等正式版发布再去测试大概率会落后别人一步。但 preview 版本也有坑。最常见的就是兼容问题。比如某些量化工具、推理框架对它支持不到位或者模型对某些 prompt 格式特别敏感换一个模板效果就差很多。这些问题在正式版里通常会解决但在 preview 阶段就需要你多折腾一下。所以我的建议是生产环境可以先观望测试环境必须玩起来。2. 开源不等于啥都能干许可证和部署门槛要看清2.1 开源模型的“开”到底开了什么很多人一提“开源模型”就默认可以随便跑、随便改、随便商用。这个认知需要纠正。开源通常指的是模型权重开放下载源代码比如推理代码、部分训练脚本也放出来。但这不意味着训练数据、完整训练流程、内部实验记录也全都公开。更需要注意的是许可证。不同模型的许可证差异很大有的严格禁止商用有的允许商用但要求保留版权声明有的对生成内容的归属有额外要求。Hy4 preview 在发布公告里明确说是开源但具体能用到什么程度必须去翻许可证原文。下载权重之前先花十分钟把许可证里“允许、禁止、必须”这几段看明白能省掉后面一大堆麻烦。我见过不少团队模型用得好好的结果因为没看许可证把模型接进了商业产品后来被发函要求下架或补签协议。这种事在开源 AI 领域已经出现过多次。一句话开源是别人释放善意不是你乱来的许可。2.2 本地部署的硬件账本假如你决定在本地跑 Hy4 preview先算一笔硬件账。770B 总参数FP16 精度下光权重就要 1.4TB 显存。即使是 INT4 量化也要 400GB 左右显存。这是什么概念单张 80GB 显存的 GPU得凑 5 张才勉强放得下。这还没算 KV Cache、中间激活值、多卡通信的开销。所以对于绝大多数个人开发者来说本地部署 Hy4 preview 的现实路线只有两条一是使用 CPU 大内存 量化的组合跑慢速推理适合做离线测试二是干脆别本地跑直接走官方 API 或者第三方托管的推理服务。现在很多平台都提供了大模型的按量付费 API对于想评估模型能力的人来说API 是性价比最高的方式。我自己测试大模型从来不上手就部署全套先写一堆 prompt 跑 API确认模型能力符合预期再决定要不要花时间部署。顺序反过来大概率浪费时间。2.3 开源生态能玩出什么花开源真正值钱的是生态。模型权重本身只是起点围绕它可以做的方向包括微调拿领域数据对模型做 SFT让它更懂你的业务术语。蒸馏把 770B 模型的能力蒸馏到小模型上部署成本骤降。评测拿你自己的任务集去测看它比现有模型强在哪、弱在哪。工具链适配做推理框架、量化工具、Agent 中间层的适配提早占坑。这些方向里的每一个都能单独撑起一个开源项目。不要只盯着“模型能不能跑”更要看“围绕这个模型能做些什么”。3. WorkBuddy 限时免费两周时间够做什么3.1 WorkBuddy 到底是什么正文消息里提到 WorkBuddy 限时两周免费很多人第一反应是“又一个 AI 聊天机器人”。实际上 WorkBuddy 是一个偏“任务执行”方向的 AI 工具定位更接近“带工作记忆的智能助手”。它可以帮你拆解一个复杂任务、管理多步骤流程、调用外部工具并且把上下文记住不用每次重复交代背景。通俗点说普通聊天 AI 是你问一句它答一句WorkBuddy 更像一个“开始干活”的助手。你说“把这几份文档整理成一份汇报然后发给项目群”它能把整个流程拆成读取文档、提取要点、生成汇报、对接发送工具逐步执行。跟 CodeBuddy 那种聚焦代码场景的助手相比WorkBuddy 覆盖的是更宽的工作场景包括文字处理、信息整理、日程安排、简单数据分析等。如果把它当作 Agent 的入门工具来理解会更准确。3.2 两周免费期能薅到什么限时免费重点不是“白嫖”而是“在限定时间内评估”。两周时间足够你判断这个工具适不适合自己的工作流。我的建议是拿到免费使用权之后别干两件事一是别只拿它聊天二是别一上来就提特别复杂的任务。正确的姿势是分三步走先跑通最简单的工作流。比如让它整理一份会议纪要、生成一个待办清单、把一段杂乱信息结构化。手动创建一个多步骤任务观察它是怎么拆解和执行的。这是评估 Agent 能力的关键。把你的高频工作场景做成自定义指令或模板试着复现日常工作的完整链路。免费期结束后要不要付费取决于它能不能帮你省下每天一小时以上的时间。如果每次用还得花十分钟调 prompt、改步骤那就不值得续费。3.3 自定义指令和 Skill 的配置技巧WorkBuddy 里有两个经常被忽略但非常实用的功能自定义指令和 Skill技能。自定义指令是全局性的行为约束告诉它你偏好如何输出、用什么语气、关注什么重点。Skill 则更像是可复用的“操作脚本”把某类任务的完整处理流程写进去下次直接调用。举个例子我经常需要整理各类调研材料。我会写一个 Skill里面包含标题提取规则、摘要格式、信息来源标注方式、最终输出的 Markdown 模板。每次调研的时候只输入原始材料WorkBuddy 会自动套用这套流程产出的结果格式统一基本不用再改。写 Skill 的时候有一个核心原则把你能想到的边界情况全部写进去。比如“如果材料里没有日期就标注未知日期不要猜测”“如果两份材料冲突就单独列出冲突点不要擅自合并”。因为 AI 最擅长在不确定性面前自作主张你把规则定得越细输出质量越高。4. 实测体验与常见问题排查实录4.1 我这几天的实际使用感受这几天我把 Hy4 preview 和 WorkBuddy 都做了一轮实操说说真实体感。先谈模型方面的感受Hy4 preview 在长文本理解和多步骤推理上表现突出。举例来说我扔给它一大段包含多个子任务的指令模型能正确拆分优先级、逐项输出且不会在过程中忘掉前面的约束条件。相比之下不少小模型很容易在长对话中“记忆漂移”最后给出的内容跟初始要求已经没什么关系了。但也必须承认preview 版本在生成稳定性上还不是特别好。有些 prompt 写法和格式要求模型偶尔会忽视。这种情况下我通常会尝试修改 prompt 的结构比如明确输出章节、规定语气甚至给一个具体示例。把 prompt 调整成“填空题 限制条件”的形式失误率会明显下降。WorkBuddy 的体验则不一样。它的核心优势不在单次答复质量而在整个过程的“托底能力”。比如说任务执行到一半模型崩了或者断网了WorkBuddy 能把已有的中间结果保留下来重启之后接着干。这一点对于实际工作流来说特别重要因为真实世界里哪有那么多一次性顺利跑完的任务。我实测下来最烦的反而是多个工具之间切换时偶尔会卡一下需要手动确认下一步操作。4.2 常见问题速查表下面这些问题是这几天在社群里看到大家问得最多的我整理成一个速查表问题可能原因解决思路Hugging Face 下载权重速度慢网络原因使用国内开源镜像站如清华镜像、阿里云模型服务加速下载直接把地址前缀换成镜像域名即可显存不足模型加载失败权重精度太高或设备不够改用 4bit/8bit 量化或者放弃本地部署改用官方 API 或第三方推理服务生成结果不稳定、前后矛盾对话历史过长或 prompt 约束不足缩短上下文长度、增加输出格式限制、必要时拆成多个子任务WorkBuddy 执行任务卡住多步骤流程中某些环节需要外部确认检查工具调用日志手动确认后让它继续不要直接重启会话免费额度用尽后想继续用白嫖结束判断是否值回票价或者转而使用其他免费方案这个表里的内容基本涵盖了新手可能会遇到的 80% 的问题。剩下的 20%通常跟具体环境配置有关需要结合报错信息去搜。4.3 几个踩坑之后的独家心得第一不要迷信“官方推荐配置”。很多开源模型的 README 里写着推荐 GPU 型号但那是训练或者大规模并发的场景。你只是个人测试配置可以大幅压缩用量化版本在小显存设备上慢慢跑也能得到有价值的结果。第二尽量把任务拆小。在大模型时代我们习惯了把长 prompt 一次性扔出去。但面对 Hy4 preview 这种超大规模模型单次生成太长反而容易失控。我习惯让它先给大纲再看细节最后整合。虽然多花了几次请求但输出稳定得多。第三WorkBuddy 这类工具的免费期其实是一个很好的“工作流审计”机会。你为了适配它而写出来的那些自定义指令、流程模板即使以后不用它了也照样能迁移到其他 AI 工具上。我这次就把一套调研模板沉淀了下来以后哪怕换个工具这套模板依然有用。第四关于网上流传的各种“WorkBuddy 大学清单”之类的教程不要盲信。市面上很多内容只是个人经验不一定适合你的场景。最好的方式是把它们当作灵感自己动手调整成适配自己工作的版本。工具是死的工作流是活的。