Hy4 preview 发布的消息刷屏那会儿我看了一眼时间线发现大多数讨论都停在“770B MoE 开源”和“WorkBuddy 限时免费用”这两句话上然后就没了。数字很唬人免费也很抓眼球但真正影响你能不能把它用起来的信息反而被最大字号的新闻盖住了。这篇文章我换一个角度来聊不替官方念通稿也不做云评测而是站在一个当天就下载、当天就接 API、第二天开始折腾本地部署的人的角度把“Hy4 preview 发布”这件新闻拆成几件可执行的小事再把 WorkBuddy 从安装到 Skill 实践的真实流程过一遍。适合三种人看想搞懂 MoE 为什么突然遍地开花的算法爱好者想搞清楚 WorkBuddy 和 CodeBuddy 到底有什么不一样的 AI 工具党以及这两周打算认真薅一下免费时长的业务和测试同学。1. 先把“Hy4 preview 发布”拆成三件不同的事1.1 preview 究竟意味着什么很多新闻标题直接把“Hy4 preview”和“Hy4 正式发布”混为一谈。其实 preview 是开发者预览版模型已经训练完推理链路基本稳定但后续还可能调整对话格式、微调细节甚至根据社区反馈修改部分能力表现。它适合尝鲜、适合做产品原型验证、适合在可控业务场景里小范围试跑但不建议直接把核心生产链路切过去除非你已经验证过边界情况。这也是我判断一款模型发布信息时第一个会看的词。如果官方把它叫 preview意味着你遇到问题的时候对方大概率不会承诺 100% 的兼容性或长期一致性。在开源生态里这倒不是坏事反而给社区留出了提前适配工具链的时间窗口。1.2 770B MoE 不是“超大号一模一样”的模型普通吃瓜群众最容易把“770B”理解成一个体积巨大的传统大模型。真正重要的是后面跟着的那三个字母MoE也就是 Mixture of Experts混合专家架构。在传统的稠密模型里一个 7B 模型读入任何 token都会让全部 70 亿参数参与计算。在 MoE 架构下一个 770B 总参数的模型内部被拆成了很多位“专家”每次只让其中一部分专家参与当前 token 的处理。你可以把它理解成一个顾问公司注册员工有七百多人但接到具体项目时不会让所有人一起上手而是由项目经理按需挑几位相关领域的顾问组成临时项目组。所以“770B”是这家公司的总名册人数不等于每个任务都会动用 770B。真正决定每轮推理计算量的是激活参数量。官方技术报告还没有完全放出所以不能替你断言具体激活规模但按照目前同类 MoE 模型的通用思路激活参数基本会被控制在总参数的十分之一到四分之一区间用户端感受到的生成速度会更接近一个小号模型的水平而不是传统意义的千亿稠密模型。1.3 开源解决的是“能不能自己掌控”的问题围绕这次发布社区搜索量排在前面的一直是“开源模型”“开源地址”“开源项目”。这其实反映了真实需求大家关心的不是那个模型在榜单上的位置而是我能不能拿到权重、能不能自己部署、能不能基于它改一套符合业务场景的版本。开源模型的价值要拆成三层看权重层你不再受 API 厂商的接口策略限制可以本地部署也可以搬到私有云。推理层开源出来的配套代码和社区适配工具决定了你能用多低的上手成本跑起来。生态层第三方 Agent、知识库、部署平台会不会主动适配往往比模型本身更影响实际体验。我问了一下身边关注这轮发布的人多数人的兴奋点其实集中在“开源模型 WorkBuddy 接入”这条组合上。说明一个趋势已经很明显模型本身正在变成基础设施真正拼的是谁能让这个模型更容易进入你的工作流。2. MoE 架构的思维模型为什么模型越大日常使用不一定越慢2.1 路由器和专家团要真正理解 MoE不需要啃完整个论文你先抓住两个机制就好。第一个机制是一个“路由器”。它负责看当前这个 token 适合谁来处理然后发出指令“这个数学问题请数学专家和推理专家回答这句法语翻译请语言专家和文化专家回答。”第二个机制是“只选最强的 K 位专家”。每个 token 在 FFN 层不会经过全部专家而是通过 Top-K 路由选择最匹配的几位。业内常见的做法是 Top-2也就是每个 token 只经过两位专家。如果专家数量是几十位甚至上百位每次只调两位计算量自然就降下来了。但这条路不是没有代价。路由器的判断质量直接影响模型能力如果路由不稳定回答质量就会时高时低。这也是为什么部署 MoE 模型时不能只看总参数量还得关注路由层的吞吐、负载均衡和长上下文表现。2.2 一次请求的真实成本推理服务商给 MoE 模型定价时通常比同参数量的稠密模型便宜核心原因就在于每个 token 的计算量远小于全量参数。但这是针对“云上共担成本”的情况你自己部署时就会碰上一个完全不同的现实MoE 省的是算力不是显存。为什么因为虽然每个 token 只激活一部分专家但模型权重文件是全部留在显存里的。就好比那家顾问公司虽然每次只请两位顾问上门但全公司的档案室必须一直开着你不能临时去仓库翻资料。所以当你看到“770B MoE”时第一个要做的不是感叹规模而是算一张显存账。2.3 本地部署前的显存估算拿权重精度算一个最简单的账。770B 参数在 bf16 精度下每个参数 2 字节裸权重就需要约 1540GB 显存如果做 8bit 量化压缩到 1 字节也需要约 770GB即便用比较激进的 4bit 量化还是需要 400GB 左右。这还没算 KV Cache。长上下文推理时KV Cache 会额外吃掉几十甚至上百 GB具体取决于层数、头数、序列长度和 batch 大小。看到这个结果你应该明白两件事个人单卡或者单机游戏卡跑这种规模的模型非常吃力。本地部署更适合团队级、有 A100/H100 级别多卡服务器的环境或者等待社区适配后的量化小体积版本。我不建议普通爱好者直接尝试 770B 的完整本地部署那属于拿工程时间换体验的行为。真正适合大多数人的姿势是本地部署一个小量级模型做日常把复杂任务交给云端 API 或大模型工作台。2.4 部署在不同硬件条件下的选择如果你确实有硬件条件想自己折腾我按设备分成三类建议单张 24GB 显卡优先等社区放出的 GGUF 量化版本用 llama.cpp 类工具跑模型精度损失能接受的话体验不错。不要试图加载完整版。4 到 8 张 80GB 显卡可以直接用 vLLM 或 SGLang 这类推理框架加载完整权重。启动命令参考如下具体路径按实际模型位置变化。vllm serve /path/to/hy4-preview \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9注意 tensor-parallel-size 必须不超过 GPU 数量和显存限制max-model-len 一开始别开太高先保证能稳定跑起来再逐步拉长上下文。纯云端调用直接选提供官方 API 的平台或者接 WorkBuddy 这类 Agent 工具省掉所有运维成本。部署时的另一个隐性成本是模型下载。大文件从海外源拖回来的速度可能不理想国内一般有镜像站可以加速用之前先确认模型协议是否允许分发别把下载行为变成违规操作。第一次跑通时建议先把 batch size 调小一点否则并发一高很容易 OOM然后把日志里的路由统计打开观察一下专家负载是否均匀这能帮你提前发现推理框架的配置问题。3. WorkBuddy 和 CodeBuddy 的区别以及免费期到底值不值得装3.1 用户最容易问错的第一个问题这两天的搜索热词里“codebuddy 和 workbuddy 区别”出现频率非常高。很多人以为它们只是同一种 AI 助手换了皮肤所以才会纠结选哪个。但从我目前看到的功能介绍和社区讨论来看这两个工具的定位差异其实相当明显一个主攻软件研发一个主攻业务工作流。把两者放在一起问就好比问“电钻和洗衣机有什么区别一样”。它们都用电但服务的地方完全不同。搞清楚这个前提你才不会在 WorkBuddy 里拼命问它 Python 语法而在 CodeBuddy 里要求它帮你走通报销流程。3.2 WorkBuddy 的定位更像“会听指令的虚拟业务助理”我不打算给 WorkBuddy 下一个容易被冲的官方定义就说说它实际能承载的几类活整理工作记录、生成周报、批量处理表格、把一段业务流程固化成可重复执行的技能包、写一个简单的网页、做接口自动化测试、对接知识库等。这些场景有个共同点不是让你写代码而是让你把想做的事情描述清楚由它调度模型和工具完成。WorkBuddy 真正的价值不在“它比某个模型聪明”而在它把自然语言、工具调用和流程编排拼成了一个能实际工作的整体。所以你评估 WorkBuddy 时不要只问“它大模型能力强不强”要问“我手上哪项重复劳动能够通过给它下指令节省下来”。如果你没有任何重复性业务动作那它对你就只是一个普通聊天框。3.3 两者的核心差异对比为了帮有选择困难症的朋友快速定位我按平时最容易观察到的维度做了个对照。对比维度CodeBuddyWorkBuddy核心场景代码生成、补全、重构、研发问题排查办公流程、业务自动化、网页/文档/API 操作主要用户程序员、研发团队运营、测试、产品、业务人员也覆盖部分开发场景交互方式编辑器内对话面向代码上下文工作台指令面向任务和业务流程典型输出代码 diff、解决方案、技术解释完成后的文档、网页、测试报告、整理好的数据扩展方式插件体系为主Skill 技能包 API 接入为主当然两者的边界不会永远清晰。很多工具做到后面都会互相延伸CodeBuddy 也可能做业务流程WorkBuddy 也可能帮你生成代码。关键是你在选工具时先想清楚你大部分时间在处理“代码问题”还是“业务问题”选那个能缩短你当前主链路时间的比什么都重要。3.4 两周免费到底应该怎么规划看到“限时两周免费”我的第一反应不是马上下载而是先看官方规则里免费的范围是什么是全功能免费、API 调用量免费还是只有内置模型免费不同口径对应的体验策略完全不一样。建议你按这三步来规划第一先花半小时装好客户端并注册账号确认可用模型和工具功能。第二明确你这两周要测试的重点不要东问一句西问一句把额度浪费在无效聊天上。第三每次测试后记录结果因为两周后如果没有保留方案你再想复盘当时的测试数据就要重来一遍。我的观点是如果 WorkBuddy 只是给你一个和普通 AI 聊天类似的体验那两周免费期的吸引力有限。但如果它能让你顺手把接口自动化、周报整理、知识库问答这些事接进日常操作那它值得你专门为它安排一次试用计划。4. WorkBuddy 从安装到跑通一个任务的完整过程4.1 环境准备与安装先说安装。WorkBuddy 一般会有对应的桌面端或客户端安装包直接去官网下载对应系统的版本就行。Windows 和 macOS 的安装过程都没有太多特殊动作下一步下一步即可。部分部署模式可能还提供命令行工具或本地服务版本适合已经有模型网关或 API 服务的人。我自己踩过的一个小坑是安装后第一次启动提示要登录但注册完成后的激活邮件被拦截了。不用急着反复重发先检查一下邮箱拦截目录。另外客户端的自动更新偶尔会被安全软件拦下来这类 AI 工具常常需要从远程加载技能或模型配置如果启动后出现异常空白界面优先检查安全软件有没有把它的相关目录隔离掉。4.2 模型接入内置模型与自定义 APIWorkBuddy 这类工具一般会给一个即开即用的默认模型配置。你在设置里能看到当前使用的模型名称和对话地址。如果是需要自己接模型的场景还需要配 API Key。配置入口通常长这样打开设置找到模型管理填入接口地址、API Key、模型名称再点一次测试连接。只要目标模型接口是兼容 OpenAI 格式的这段就能直接照抄思路接口地址填服务商提供的 Base URLAPI Key 填你的密钥模型名称必须跟服务商那边完全一致。比如你在某个云端服务平台开通了 Hy4 preview 的 API通常只需要把模型名改成官方公布的名字测试连接成功后再启动会话。这里要敲一下黑板API Key 属于敏感凭据不要随手贴到聊天记录、配置示例或团队共享文档里。如果担心泄露建议在 WorkBuddy 这类工具里使用环境变量方式注入或者至少用有权限隔离的 Key。4.3 用自然语言跑通第一个任务装好、接好模型之后不要急着问“你能做什么”直接给它一个足够具体的小任务。我的建议是从“写一个简单的活动报名页面”开始因为这类任务能同时检验它的文本能力、HTML 生成能力和工具调用能力。你可以这样描述“帮我生成一个活动报名页面包含活动名称、时间地点、报名表单风格清爽一点表单提交后需要有前端校验。”它会先拆解需求然后生成一段可用的 HTML/CSS/JavaScript 内容。你拿到结果后先别忙着夸它重点检查几个细节表单字段是否齐全、日期格式是不是你想用的格式、校验逻辑有没有明显漏洞。如果你发现它理解偏了直接补充约束条件让它重新生成例如“城市只允许选择三个其他城市展示但不可提交”。第一次跑通任务的经验会直接影响你后面要不要把它放进真实工作流。至少对我来说一个能稳定理解任务边界并正确输出可执行结果的工作台比一个偶尔能写出惊艳文案但不稳定的大模型对话窗更有用。4.4 用 Skill 固化一个接口自动化流程WorkBuddy 里有一个绕不开的概念叫 Skill。如果你不是程序员可以把它理解成给虚拟助理写了一份“作业标准程序”。完成了第一次自然语言任务后下一步建议尝试 Skill因为这才是 WorkBuddy 区别于普通聊天助手的关键。我做接口自动化时的思路是这样的先用自然语言让 WorkBuddy 执行一轮冒烟测试比如传入一个获取用户信息的接口让它发请求并核对状态码。如果它能按预期完成再把它整理成 Skill把常用参数变成变量下次直接调。创建 Skill 不需要一开始就做复杂的可视化流程图。我建议你先从最简单的三步开始第一步定义输入参数比如 URL、请求方式、Header、Body第二步在 Skill 描述里写清楚执行时的步骤例如“先发送请求再检查 HTTP 状态码然后校验返回结果中的业务错误码”第三步规定输出格式比如“把每个用例的执行结果汇成一张表格并额外生成一份 Markdown 测试报告”。这个做法虽然听起来朴素但它能把你和模型之间的默契沉淀下来。第二次再跑同一个业务流程时你不用重复解释只要填好参数就行。4.5 使用中的安全与隐私边界WorkBuddy 这类工具能访问你的文档、表格甚至接口这是好事也是风险点。我给自己立了几条规矩你可以参考不要把数据库密码、私钥、身份证号等敏感信息直接写进对话。在接内部系统前先确认指令发送的数据会去哪里尤其是免费额度阶段更要警惕。如果业务数据合规要求高优先选择本地部署或私有化接入方案。5. 免费期实测中的几个教训以及我给你的使用建议5.1 长文本任务需要主动拆解我在实测中发现无论接的是 MoE 大模型还是常规千亿模型只要任务涉及很长的上下文一步到位的结果往往不稳定。比如让它一次性总结一份几万字的访谈记录它可能在开头几个部分表现很好越到后面越容易出现信息遗漏甚至开始重复前面已经说过的内容。后来我调整了用法先按章节把文本切成几段让 WorkBuddy 逐段提取要点最后再让它合并成一篇总摘要。分而治之看起来多了一步但结果质量和稳定性都明显提升。这个习惯几乎适用于所有大模型工作台在任何模型上都值得保留。5.2 Skill 不要一次做得太复杂很多人第一次接触 Skill很容易把它当成万能工作流想把所有判断逻辑都塞进去。我试过一次失败的例子试图做一个“自动处理所有异常类型”的接口测试 Skill结果它在一次任务中反复调用工具甚至把无效用例的报错当成核心问题来处理导致输出报告长而无效。正确的思路是两个 Skill 各司其职一个是“正常流程执行”只按参数发请求、校验状态码另一个是“异常归因分析”专门接收失败的接口结果并给出排查建议。保持 Skill 单一职责后续维护和复用都会轻松很多。5.3 两周内可以重点测的五件事如果你决定认真试用这两周不要只停留在“聊天好玩”层面。我建议你把这五件事排进测试清单指令遵循能力给它一个包含多条限制条件的任务看它是否全部遵守。工具调用稳定性连续执行五次同样的接口自动化任务记录失败次数。长文摘要质量把同一篇长文档交给它和另一个模型对比信息颗粒度和遗漏率。数据格式兼容性让它处理你真实的 Excel、CSV 或工单格式看它会不会乱码或改结构。安全边界试探它是否会把不该外传的内部信息原样写入输出或是否容易被提示词绕过限制。5.4 免费期结束后怎么办两周的时间过得很快。免费期结束前我最建议做的一件事是把你在测试过程中沉淀的 Skill 和提示词模板单独导出来。工具可以换模型可以换但你的业务流程描述也就是那些已经验证过的指令和参数定义是真正可以带走的资产。如果接下来准备接开源模型思路也很明确选一个支持 OpenAI 兼容接口的推理服务把模型切换成 Hy4 preview 或其他开源权重如果你的硬件条件够也可以直接本地部署一个小型模型然后通过自定义 API 接入 WorkBuddy。这轮发布的组合拳真正值得留意的不是某个参数数字而是“开源模型 工具化封装”这件事已经走到普通用户面前了。我能给的唯一建议是趁免费期把真实业务场景跑一遍。不管最后你决定继续用 WorkBuddy还是回到原来的工具链这几天的测试结果都会比任何宣传页都更能告诉你答案。