Hy4 preview开源：770B MoE部署评估与WorkBuddy工作流实践

Hy4 preview 发布那晚，我所在的几个技术群最热闹的话题反而不是 770B 这个参数数字，而是“开源”两个字。紧接着第二条刷屏消息就是 WorkBuddy 限时两周免费。这种“大模型开源 + 配套工具免费体验”的组合拳，对很多想把手头重复工作交给 AI 的人来说，确实是个值得停下来算账的时间点。所以我第一时间去翻了发布说明，也整理了一套自己的评估方法：先搞清楚 770B MoE 到底意味着什么，再决定是下载权重自己部署，还是先用 WorkBuddy 把业务流程跑通，最后看开源模型能和工作台怎么配合。

这篇文章没有打算把发布会内容复述一遍，我更想分享的是：看到一个超大 MoE 模型开源后，真正想用它的人应该关注哪些环节、部署上要提前准备什么、两周免费期里最值得测试哪些任务，以及免费期结束前怎么判断要不要继续用。

1. Hy4 preview 的开源消息，我为什么先聊算力账单

很多人看到“770B MoE”第一反应就是“大”，第二反应是“我的机器能不能跑”。这个方向问对了，因为部署方式决定了你是把开源当宣传看，还是当生产力看。

1.1 MoE 不是 770B 个参数同时干活

MoE 的全称是 Mixture of Experts，也就是混合专家。早期我对它的理解也有偏差，以为是 770B 参数的超级大模型，每个 token 都会动用全部 770B 参数算一遍。后来自己部署过开源 MoE 模型才明白，这个理解会让预算和实际需求差出一个数量级。

更准确的理解是：模型把网络划分成若干专家模块，每次处理一个 token 时，路由器只选择其中部分专家参与计算。我常用一个咨询公司来打比方：770B 相当于公司总共有 770 名顾问，但具体接一个项目时，项目经理会根据项目类型抽调财务、法务、技术等多个领域的少数顾问进场。你不能说公司没有这 770 人，但也不是每个项目都要让 770 人同时坐在会议室里。

所以 MoE 的真实成本要拆成两部分看：一是权重文件本身，所有专家参数都得放在显存或内存里，这部分按总参数量算；二是单个 token 的计算量，只和激活参数量有关，这部分通常远小于总参数。也就是说，MoE 用大量存储换来了相对可控的推理计算量，但“想在自己的机器上跑起来”时，存储压力一点都不会少。

1.2 一张表算清权重和显存需求

开源模型下载下来后，第一步要面对的就是模型文件多大。权重文件大小有一个通用估算公式：参数量乘上每个参数占用的字节数。BF16/FP16 格式下每个参数占 2 字节，8bit 量化约 1 字节，4bit 量化约 0.5 字节左右。

以 770B 为例，我按这个公式做了个粗略估算：

这张表只是权重占用的下限。实际推理时还要算上 KV Cache、激活值、临时张量，所以如果真用 BF16 全量部署，20 块 80GB 的卡只能做到“勉强放下权重”，跑长上下文或并发请求时会把显存撑爆。把 20% 到 30% 的显存留给缓存才比较稳妥，也就是说需要 24 到 32 块卡。

个人开发者看到这个量级基本可以放弃自建大型多卡集群的想法。先用官方 API 或托管服务跑效果，等确认工作流确实有价值，再考虑租用或购买算力做私有化部署。这是绕开硬件门槛最务实的路径，我在之前的开源大模型项目里也一直是这么做的。

1.3 不同角色面对这个开源消息，关注点完全不同

开源模型的消息很容易被一锅端地讨论，但实际上一家企业、一个独立开发者和一个只想提高写文档效率的人，面对“770B MoE 开源”的决策路径完全不一样。

企业在意的通常是私有化部署的合规性和持久性。权重如果能本地部署，意味着数据不出域、接口不依赖第三方、也不会因为外部服务停服而突然失去模型能力。这类用户拿到发布消息后最该看的是权重许可证和依赖组件，而不仅是模型效果榜单。独立开发者更关心 API 的兼容性和模型在处理多轮指令时的稳定性，能不能把自己现有链路里的旧模型平滑替换掉才是关键。而只想要一个“AI 工作助手”的普通用户，其实完全不需要理解 MoE 路由是什么，直接在 WorkBuddy 这类工具上体验才是最高效的做法。

我对不同基础读者的建议很简单：能看懂权重量级的看权重量级，看不懂的直接跳到 WorkBuddy 那段。模型部署是手段，把事做完才是目的。

2. 下载权重只是刚开始：部署落地要看的三件事

如果只把开源模型文件下载到服务器就算部署，那后面会遇到一堆措手不及的问题。公开权重是一个非常基础的文件集合，真正要让它跑成稳定的服务，还需要检查几个关键点。我把它们总结成“三查”：查许可证、查推理框架兼容性、查对话模板。

2.1 开源不等于可商用，先看清楚许可证边界

看到 GitHub 仓库里写着“open source”就默认可以拿去商用，是我见过最常见的翻车原因。有些项目标榜开源，实际只是把权重公开了，但附属的代码、数据或对话模板可能受额外条款限制。

我拿到 Hy4 preview 权重后，第一件事就是去仓库翻 LICENSE 文件，同时会看两个细节。第一个是权重许可证里是否明确写了“允许商用”，尤其涉及模型输出用于 SaaS 服务时，很多限制条款要仔细阅读；第二个是分词器和对话模板的许可证是否与权重一致，有些模型权重本身开放，但 tokenizer 文件因为训练数据的缘故不能随意再分发。这一点很容易被忽略，等到要把模型打进镜像或大规模分发时才发现法律风险。

2.2 推理框架不是越新越好，先确认对 MoE 的支持情况

部署大型 MoE 模型时，推理框架的选择优先级很高。常用的 vLLM、SGLang、TensorRT-LLM 都各自有优势，但它们对某个具体模型架构的适配进度不一样。尤其是模型刚发布时，官方推理代码可能还没有合并进主流框架，直接照搬旧框架的命令行很可能报错。

我建议选定模型前先用官方仓库推荐的推理路径，再看框架的 release notes 里有没有提到该模型架构的名字。如果官方还没给兼容方案，可以先等一到两周，通常社区适配会很快跟上。自行修改框架代码不是不能做，但维护成本极高，而且后来官方发布了优化版本，你要重新跟进，性价比很低。

如果框架已经支持，启动命令大体类似这样：

python -m vllm.entrypoints.openai.api_server \ --model /data/hy4-preview \ --tensor-parallel-size 32 \ --gpu-memory-utilization 0.9

其中--tensor-parallel-size要根据实际 GPU 数量来填，--gpu-memory-utilization 0.9表示给 KV Cache 预留了 10% 的余量。这看起来没什么，但实际操作中“留给缓存的余量太少”是显存溢出最常见的直接原因。

2.3 对话模板和工具调用格式不一致，结果会离大谱

很多人在用开源模型时遇到过一种诡异情况：单条 prompt 回答得挺好，但一放到 Agent 或 CodeBuddy 这类工具里就输出乱套，然后怀疑是模型能力不够。其实大多数时候问题出在对话模板没有设置对。

不同的开源大模型会使用不同的 system prompt 格式、角色标记、工具调用格式。比如有些模型的函数调用需要特定 JSON Schema，如果你只用了通用 OpenAI 格式而不做转换，模型很可能会在“该调工具”的轮次里生成对话文本，而不是直接输出工具参数。我在部署开源 MoE 模型时吃过这个亏，当时日志里没有抛错，但结果就是工具调用永远解析不出来。

排查这个问题的方法很简单：先用原仓库提供的chat_template做一次最小验证，确认多轮对话和函数调用都正常，再接入自己写的工作流。不要一上来就调业务逻辑，基础协议都还没通，后面所有结果都没有参考价值。

部署完成后还需要做一轮“探针测试”，我会分别用小批量短上下文和长上下文请求去打同一个服务，记录首 token 延迟和显存峰值。长上下文场景下 KV Cache 的占用增长非常快，不压一遍根本不知道服务能支撑多少并发，这一环在 WorkBuddy 这类工具接入自建模型时尤其重要。

3. WorkBuddy 限时免费，我更看重它的技能编排能力

“WorkBuddy”“CodeBuddy”这两个名字放在一起，很多人的第一反应是问它们到底有什么区别。我自己的理解是：CodeBuddy 更偏代码生成与开发助手，面向写代码的工程场景；WorkBuddy 更像一个智能工作台，把大模型能力封装成可复用的技能和业务流程，然后让这些技能为你处理文档、接口、数据整理这类日常任务。标题里 WorkBuddy 限时两周免费，实际上给了一个很低成本的试错入口。

3.1 先把工作台理解为“模型能力的包装层”

如果只把大模型当聊天框用，那不需要 WorkBuddy 也能完成不少事。但真正的价值在于把重复性的工作固化成流程。比如你要做接口自动化测试，一个聊天框每次都要重新交代背景、贴接口文档、定义输入输出，而 WorkBuddy 这样的平台可以把“读取 OpenAPI 文档 → 生成测试用例 → 调用接口 → 输出断言建议”封装成一个技能，以后每次只需提供新接口文档就能执行。

这就像请了一位什么都会的顾问，聊天框是你随时问问题，而工作台是给这位顾问配了一套标准作业流程：先做什么、后做什么、做完输出什么格式的结果。开源模型本身再聪明，如果不给它固定的流程和检查项，很难稳定复现高质量结果。

3.2 免费期内先做“任务清单”，而不是漫无目的地闲聊

两周时间说长不长，说短也确实能测出东西。我见过不少人领了免费额度后，只在第一天试了试简单问答，等过了一周才想起来，结果有效期已经过半，又急匆匆拿真实任务去压测，效果自然不好。

更合理的做法是注册后先看免费套餐的边界：是一次性赠送多少额度，还是每天有固定次数？是否包含大模型 API 调用，还是只能使用平台内置模型？以及任务执行是否受并发限制。我建议头两天集中做最简单的“连接性测试”，确认模型输出能正常回流到文档、表格或代码仓库；中间十天全力跑真实任务；最后两天留出时间整理测试记录并决定要不要续费。

3.3 首批测试建议覆盖三类任务

根据我过去用各种 AI 工作台的经验，一周内只测一类任务很容易产生误判。我会至少覆盖三类不同性质的任务。

第一类是接口自动化类。给 WorkBuddy 喂一份接口文档，让它生成一批带断言的测试请求，观察代码生成的正确率和调试成本。这类任务能反映模型对结构化内容的把握能力。第二类是文档总结与格式转换。比如丢进去一次长会议记录，要求按指定模板输出待办事项、责任人和截止时间。这类任务的重点不是“总结得对不对”，而是输出格式是否每次都稳定。第三类是技能封装，把多步骤工作流固化成一个可随时调用的 skill。比如“读取 CSV 文件 → 做数据清洗 → 输出统计摘要”，观察它能不能处理异常数据而不中断。

这三类任务分别对应代码能力、文本结构化能力和流程稳定性，评估表可以做成：完成率、人工修正次数、单次耗时、输出格式偏差。不要只看一次成功，要看同样任务重复执行三次的结果是否一致。

关于接入外部模型，我还会额外关注平台的“自定义模型”入口。如果 WorkBuddy 支持配置自定义 Base URL 和 API Key，那思路就完全打开了：可以用官方 API，也可以指向自己部署的本地模型服务，还可以在 Hy4 preview 之外切换其他开源模型。配置方式通常与 OpenAI 兼容接口的结构类似：

Base URL: http://your-llm-service.example.com/v1 API Key: sk-xxxxxx 模型名称: hy4-preview

模型名称必须和服务端注册的名字完全相同，少个后缀或多了个空格都会导致请求 404。这个小问题看起来低级，却是团队里其他人接入时最常卡住的地方。

4. 模型到工作台的全链路自测，我总结了四个容易翻车的位置

把开源模型和 WorkBuddy 串起来只看静态能力远远不够，真正的链路至少包含数据输入、模型服务、技能执行和结果回写几个环节。我在自测这类链路时遇到过不少意外，有四个位置特别值得专门检查。

4.1 技能描述写得太宽，任务开启就跑偏

很多人在创建技能时会把描述写成“帮我处理文档”“帮我总结一下”，这会导致模型在真正执行时不知道该调用哪些具体子步骤、输出格式是否符合要求。

更稳妥的技能描述我会写成：触发的任务类型、允许读取的输入、必须执行的步骤、输出字段模板和失败处理方式。例如“当收到一份网页源码或文章内容时，提取正文段落，过滤导航和广告，按标题、发布时间、正文总结三个字段输出结构化 Markdown，原文超过 5000 字时分段处理并保留关键结论”。描述越具体，模型的执行稳定性越高，这不是玄学，而是把判断成本从模型端转移到了规则端。

4.2 自定义 API 配置细节错了，表面看是“模型答不了”

接入自建推理服务时最容易踩的一个坑是 Base URL 多写或少写了/v1。如果服务本身挂载在/v1路径下，配置里却只写了根地址，客户端会 404；反过来，如果服务已经兼容 OpenAI 路径，又在地址后面重复加了一次/v1，也会导致请求打到不存在的路由上。

另一个容易疏忽的细节是认证方式。有些推理服务默认不开启 API Key 校验，有些则要求 Bearer Token，还有的通过网关转发时会校验额外的 Header。先用curl手动发一条最小请求确认接口通了，再填到 WorkBuddy 配置里，能节省大量排查时间。我在接入自建 vLLM 服务时就习惯先跑curl，确认返回了正常 completion 结果才继续做 UI 配置。

4.3 长文本任务被静默截断，结果中后段逻辑断裂

长文档处理类任务很容易出现一种隐蔽问题：模型没有报错，但回答的中后段开始变得碎片化。这通常不是模型能力问题，而是上下文长度超限后被推理框架或平台层静默截断。

遇到这种症状，先看配置里设定的最大上下文长度和实际输入 token 数。解决思路通常有两种：第一是把长文档拆成若干块，先分别总结，再按目录结构汇总；第二是把文档作为检索源而不是一次性全部塞进上下文。对 WorkBuddy 这类工作台，我更推荐把“长文档分段处理”作为一个标准前置步骤写进技能流程，而不是依赖模型一次性消化完整个文档。

4.4 自动化任务的权限边界和人工复核机制不能省

让模型自动生成和让模型自动执行，是两码事。尤其在接口自动化、OA 办公这类场景里，给工作台配置的账号权限如果过大，一旦模型生成的操作指令有误，可能直接影响真实业务数据。

我在设计自动化任务时会强制加一道人工确认闸门：模型生成操作建议并进入待执行状态，由我或项目成员点击执行后再生效；只有在确认输出稳定的低风险任务上，才会放开自动执行。限时免费期内做这类权限测试尤其重要，因为这能暴露出工具在“审批流”环节是否灵活，如果一款工作台连基本的暂存和人工确认都做不了，那免费期结束后我不太可能放心把核心任务交出去。

5. 免费窗口期结束前，用两笔账判断要不要续费

两周时间足够产生真实任务数据，但很多人免费期一结束就会冲动付费，理由往往是“体验下来挺聪明的”。我对这种决策方式一直比较警惕，聪明不是购买依据，稳定和可控才是。所以在免费期结束前，我更建议拿出半天时间梳理下面两笔账。

5.1 体验台账：不要用“感觉好用”代替执行数据

从注册第一天开始，我会在一张表里记录每次任务的关键数据：日期、任务类型、输入规模、模型是否一次通过、人工修正次数、单次耗时、输出格式是否稳定。这张表最终要回答的核心问题是：原本需要 20 分钟的重复工作，用了 WorkBuddy 后是否稳定缩短到 5 分钟，还是只有第一次演示时节省了时间，后面反而因为纠错和调试花了更多时间。

免费期内发现某个任务成功率始终不稳定，那就不要因为“大体可用”就付费。真正的可用标准不是十次里能成功一次，而是十次里有九次能直接出可用结果，剩下一次也知道怎么快速修正。

5.2 迁出成本：如果两周后不续费，现有配置能带走吗

很多人忽视的第二笔账是迁出成本。WorkBuddy 再好用，如果我把所有技能流程都写在里面，数据也存进了它的云端存储，一旦免费期结束后不续费，这些配置能不能导出来？

试用期间可以刻意测试一下平台的导出能力：技能描述、环境变量、自定义模型接入配置是否能通过文件或 API 备份。如果平台完全不提供配置导出，那用了半年后再想迁移，所有流程都要在别的地方重建一遍，这个隐性成本往往比订阅费更值得考虑。

我会把评估维度分成四类来看：

5.3 把“两周免费”当成一张测试门票，而不是绑定契约

我现在看这类限时免费活动的角度已经变了：它更像一张实验室门票，用来验证一个业务假设，而不是让我在所有细节还没跑通前就做出支付决定。Hy4 preview 开源这件事最大的价值，其实是给了 WorkBuddy 一个“可替换”的底座。即使未来 WorkBuddy 不能一直免费使用，或者我对它的技能编排方式不满意，模型权重已经公开，我可以随时把工作流转移到其他支持 OpenAI 兼容接口的工具上，也可以把自己部署的本地服务接入新的工作台。开源模型降低了模型层面的锁定风险，免费工具降低了流程验证的前期成本，两者配合起来，才是这套组合里真正值得花两周去试的东西。

我在自己的体验记录表里加了一条“是否愿意为这个工作流付费”的判断项，填下这个选项之前，我唯一遵循的原则是：如果现在不能把一个任务从开始跑到结束并获得稳定输出，那无论免费期还剩多少天，都不应该急着写结论。等你记录的数据足够多时，答案自然会浮现，不需要依赖别人对某个模型或工具的“好评”来做决定。