看到 Hy4 preview 发布的消息时我第一反应是又一个开源大模型再仔细看一眼配置770B、MoE这两个词放在一起性质就完全不一样了。770B 的总参数量级已经远超多数人平时能摸到的 70B 稠密模型甚至逼近一些闭源巨头的旗舰版本。更没想到的是官方还同步放出了 WorkBuddy 限时两周免费的消息。作为一个既喜欢折腾开源模型、又天天被日常事务淹没的人这两件事对我来说都属于必须第一时间动手试试的类型。所以这篇我不打算写成发布会复述而是把模型架构理解、本地部署实操、WorkBuddy 使用攻略三条线结合我实际动手的经历完整过一遍。1. 770B 的总参数和 MoE 的激活参数到底差在哪里1.1 总参数量 770B 意味着什么很多人看到 770B 第一反应是这玩意儿不得要好几 TB 显存从数值账上确实没错如果用 FP16 精度把所有参数完整加载进显存770 亿参数的算法是770 × 2 字节约等于 1.54TB。就算量化到 INT4也需要 385GB 左右。这个数字确实让单卡玩家直接死心。但 MoE 模型和传统 Dense 模型的差异恰恰体现在这里总参数是一回事真正处理每个 token 时被激活的参数是另一回事。我拿到权重后先跑了几个快速测试观察 nvidia-smi 的显存占用和吞吐情况基本可以确认模型权重文件里总共有 770B 参数但推理时每次只激活其中一部分这一部分是共享专家加路由选中的 top-k 专家。用大白话说公司系统里挂着 770 个员工的名录但具体接到一个任务时调度员只把你这个项目组里最相关的几个人喊过来干活。官方并没有把激活参数的具体数字写得特别显眼但通过显存占用反推规模大概落在几十 B 这个范围。这就是为什么 770B 这类 MoE 模型在推理侧的实际门槛没有想象中那么离谱。顺带说一句最近大家搜得很多的gemma4 26b a4b这种命名总参数 26B、激活参数约 4B也是 MoE 家族的常见写法。理解了这个概念再回头看 770B 这个数字就不容易被吓住了。1.2 MoE 的路由机制和专家分工MoE 的核心改动通常在 FFN 层。传统 Transformer 里每个 token 过一层全连接网络就完事MoE 把这层替换成多个并行的专家网络再配一个门控网络Gate/Router决定每个 token 要送给哪几个专家去算。可以理解成一个工单分发系统每个 token 是一份工单门控网络是调度员它扫一眼工单内容按相关性打分选出 top-2 或者 top-k 个专家处理。这种架构的最大好处是在总参数不断膨胀的情况下把单次请求的计算量按住。传统 Dense 模型想从 70B 涨到 700B训练和推理成本都是灾难性的MoE 模型让总参数涨上去、知识容量涨上去激活参数的增速却远低于总参数。770B 这个数字其实更像是在告诉大家模型的容量和知识面到了这个量级而不是你需要买 2TB 显存这两个理解方向差异非常大。但 MoE 也不是没有代价。专家网络越多通信量越大多卡推理时卡间带宽会被喂得很满。所以更准确地说MoE 是用显存容量换训练成本、用通信带宽换推理速度的一次平衡。理解了这层逻辑后面部署时遇到负载不均衡、显存分配不合理之类的问题就不会觉得莫名其妙了。2. 本地部署的完整链路从硬件账本到首轮问答2.1 先算硬件账你的机器到底能不能跑在下载权重之前我习惯先把硬件的账算清楚。核心就一条公式显存需求等于参数量乘以每参数所需字节数。FP16/BF16 下每参数 2 字节INT8 下 1 字节INT4 下约 0.5 字节。套到 770B 模型上结果是这样的加载精度每参数字节数全量加载所需显存FP16/BF162 B约 1540 GBINT81 B约 770 GBINT40.5 B约 385 GB这只是权重本身推理时的 KV cache、激活值、框架运行时还会吃掉一块显存。所以要落地至少得按 1.2 倍的安全系数去预留。对照现实中的硬件单张 24GB 显卡RTX 4090/3090 级别基本不要想全量部署 770B只能靠 CPU offload 加极限量化硬撑体验会很勉强。4×80GB 的 A100/H100总共 320GBINT4 全量权重都放不下需要 5 卡或者接受部分 offload。8×80GB640GB 总显存INT4/FP8 量化权重能完整放进去并且还能留出不少空间给 KV cache是当前跑这个级别 MoE 的推荐起点。如果手头没有这么多卡也别急着放弃。现在的云租赁按小时计费的方案很多租一台 8 卡机器跑几天验证花费比想象中低。只是要想清楚这次实验的目标是什么是想把长文本能力测一遍还是想知道量化后的精度衰减程度目标不同租的卡型和时长完全不同。2.2 用 vLLM 起一个兼容 OpenAI 的服务部署开源大模型我首选 vLLM原因很简单吞吐高、生态成熟、OpenAI 兼容接口省去很多适配工作。整个流程分四步走。第一步下载权重。可以直接用 huggingface-cli 或者国内可用的镜像站加速。命令行指定本地目录存放避免重复下载huggingface-cli download 模型仓库路径 --local-dir ./hy4-preview第二步创建虚拟环境并安装 vLLM。建议用 Python 3.10 以上的干净环境避免系统里其他依赖打架python -m venv .venv source .venv/bin/activate pip install -U vllm第三步启动服务。这里有几个参数特别关键--tensor-parallel-size必须和 GPU 卡数一致--max-model-len决定你能吃下多长的上下文--gpu-memory-utilization建议留出一点余量给系统进程vllm serve ./hy4-preview \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --trust-remote-code第四步验证服务是否正常。vLLM 起来后默认监听 8000 端口用 curl 打一个最简单的对话请求curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: hy4-preview, messages: [{role: user, content: 用一句话解释什么是 MoE}] }第一次启动会比较磨人因为要把全部专家权重加载到显存时间是以分钟计的。这期间千万不要反复重启耐心等日志里出现 ready 字样。2.3 部署开源 MoE 最容易踩的三个坑坑一权重精度的选择。很多人图省事直接下 FP16 全量结果显存爆掉转头又去追求 INT4结果精度下降明显。我的实际建议是先看你的显存上限如果 FP8 能放下就优先 FP8它比 INT4 的精度损失小很多只有在显存实在紧张的情况下才考虑 AWQ 或 GPTQ 这类量化格式。量化后记得一定要跑一遍自己的验证集不要只看几个通用 benchmark 分数。坑二多卡负载不均衡。MoE 的 gate 网络经常会把流量集中到少数几个专家上表现出来就是有的卡显存占用和计算率吃满有的卡在摸鱼。排查方式很简单启动后开着nvidia-smi -l 1实时观察各卡利用率。如果差异特别大就要检查框架是否启用了 expert parallel或者手动调整负载均衡相关配置。坑三长上下文悄悄吃光显存。max-model-len设成 128K 会让 KV cache 的开销比模型权重还恐怖。我踩过一次32K 跑得好好的改成 128K 之后直接 OOM。后来学乖了部署阶段先从 32K 起步把推理速度、显存占用摸清楚之后再逐步往上调。3. WorkBuddy 与 CodeBuddy两款工具解决的是两件不同的事3.1 WorkBuddy 不是 CodeBuddy 的升级版从命名上看很多人第一反应是 WorkBuddy 和 CodeBuddy 是同一个东西的升级版。我在各个社区里也看到不少人在搜codebuddy和workbuddy区别说明这个混淆是普遍存在的。我的判断是这是两条产品线解决的是两种不同的问题。CodeBuddy 的侧重点是帮你写代码。它面向终端前的开发者补全、改错、重构、生成单测场景非常聚焦。而 WorkBuddy 的定位更像个人工作台解决的是代码之外的整块知识工作。有人搜workbuddy搭建个人工作台、workbuddy业务流程这已经很能说明问题了它关心的是任务编排、资料沉淀、流程自动化这些事不是单纯地生成一段代码。维度CodeBuddyWorkBuddy核心场景代码生成、理解、重构知识工作与日常流程主要用户开发者知识工作者、开发者交互形态IDE 插件工作台 / Agent核心卖点代码场景的能力Skill 与流程编排与模型关系面向代码场景面向多工具多任务这个表格是我实际体验后的总结不一定和官方文档逐字对应但方向上应该大差不差。选型的时候想清楚自己到底要解决什么问题比纠结哪个更先进重要得多。3.2 Skill 机制WorkBuddy 的灵魂热词里workbuddy skill被反复搜索说明 Skill 机制确实是大家最想搞明白的东西。我的理解是Skill 是把模型、工具、固定处理流程打包成一个可复用单元。这个设计有点意思它把 AI 从每次都要从零描述需求的状态里解放出来。打个比方。以前你让 AI 帮你整理会议纪要每次都要重新解释参会人、项目背景、输出格式有了 Skill 之后你只要在 WorkBuddy 里建一个会议纪要整理器把输入输出规则写清楚后面每次调用就是一句话的事。Skill 不只是提示词它还可以挂工具调用比如读文件夹、读表格、调外部 API。这就让流程真正自动化了而不是停留在聊天窗口里说得好听。我个人的体感是Skill 的价值在于沉淀。一个人最值钱的经验恰恰是那些每日重复、但每次都要重新组织的流程。把这类流程固化成 Skill本质上是把自己的工作方法产品化这件事比单纯提高打字速度有意义得多。3.3 限时两周免费用我建议这么用我是看到 WorkBuddy 限时两周免费的消息之后第一时间就去开了账号。限时免费这种策略本质上是用时间门槛筛选出愿意深度体验的高价值用户。如果只是登录看一眼界面就关掉基本等于没薅到任何羊毛。我的建议是分两周来规划。第一周把所有重复劳动搬到 WorkBuddy 上比如周报、日报、会议纪要整理、翻译、文件分类。每做一个流程就顺手沉淀成一个 Skill。第二周做 API 接入和小范围验证比如把团队知识库接进去让 WorkBuddy 变成一个能回答项目问题的统一入口。免费期结束前把所有数据导出把 Skill 描述和配置备份一份。这样做不管最后是否付费你都已经拿到了实际收益一套自己梳理过的自动化工作流模板。这份沉淀下来的东西比免费额度本身值钱得多。4. 搭建个人工作台实操Skill 机制、API 接入和免费期规划4.1 安装与初始化WorkBuddy 的接入方式我理解有两种线上工作台和本地部署。线上版注册后就能用适合大多数不折腾的用户。如果是本地部署网上已经有不少workbuddy本地部署workbuddy安装的教程核心流程基本一致从官方渠道拿到安装包或镜像按文档启动服务然后绑定自己的模型 API Key 或使用内置账号。我比较推荐本地部署时把配置单独拆出来管理方便之后迁移。常见的环境变量包括 API Key、模型地址、日志路径这三类建议写进.env文件里不要写死在代码中。初始化完成后先跑一个最简单的任务确认模型调用链路是通的再去搭复杂流程不然出了问题根本分不清是模型的问题还是工作台的问题。4.2 API 接入把 WorkBuddy 变成系统的中控热词里有api接入workbuddy这个方向确实是实用性最强的。WorkBuddy 如果只是一个独立聊天窗口价值有限真正让它值钱的是可以被外部系统调用。以常见接口风格为例你可以拿 API Key 去请求一个 Agent 执行任务curl -X POST https://api.workbuddy.example/v1/tasks \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { skill: weekly-report, inputs: {date_range: 2025-06-01~2025-06-07} }接入的时候有几个细节值得注意密钥不要暴露在浏览器端最好通过后端转发请求要做好超时和重试机制Agent 任务通常不是秒级返回别用太短的 timeout官方限流策略要提前看清楚避免批量任务触发限流后报错。把一个高频流程接进来之后你会发现真正的价值不是省了一次复制粘贴而是所有任务的入口、日志、结果都统一了。以前散落在聊天记录、邮件、文档里的信息现在有了一个稳定的汇聚点。4.3 一个周报自动生成Skill 的完整配方我实际搭的一个 Skill 是周报自动生成逻辑分三步先输入时间段和工作内容关键词然后从数据源里读取相关记录最后调用模型生成结构化周报。输出固定为 Markdown 格式包含本周完成、下周计划、风险点三段。提示词大概是这样的你是一个项目经理助理。请根据以下工作记录生成一份结构清晰的周报。 工作记录{records} 要求 1. 按本周完成 / 下周计划 / 风险与阻塞三段输出 2. 每条不超过 50 字语言简洁 3. 直接输出 Markdown不要额外解释调优过程中最大的体会是让输入结构化比让输出结构化更重要。如果喂进去的是一堆聊天记录模型也能硬生成但质量和稳定性都靠运气。先在输入端做过滤和分类把有效信息提取出来再交给模型效果会稳定很多。另外Skill 里的提示词要写清楚不要额外解释这类边界条件否则模型经常会在输出后面补一段废话。这个 Skill 目前已经稳定跑了两周每次生成完我会快速扫一眼基本不需要大改。真正省下的不是那几分钟生成时间而是我每次写周报前要回忆这周到底干了啥的认知成本。这个成本被 Skill 吃掉了才是最大的收益。5. 折腾完这波发布我的一些真实体会先说模型。770B MoE 这个量级的开源模型给我的冲击不仅仅是大而是大这件事开始变得可以被中小团队触及了。只要有几台 80GB 显存的卡配合量化就能把之前只有闭源 API 才给得起的模型能力拿回本地。MoE 架构在其中起的作用说白了就是保证总参数膨胀的同时单次请求的成本不跟着爆炸这个取舍逻辑接下来会是开源模型生态的主旋律。再说 WorkBuddy。免费期我没有浪费搭了一套周报、日志整理、会议纪要的自动化流程。说实话Skill 机制比我想象中重要它改变的不只是写提示词这件事而是让 AI 工具从回答问题进化成完成任务。这个转变对日常工作效率的提升是实打实的。最后分享一个免费期的小技巧别把所有任务堆到最后几天再搭。我在头两天就把高频流程跑通了后面每天都是用小任务去微调提示词和 Skill 配置。免费期结束之前你的工作台应该是热的、天天在用的而不是一个注册完就吃灰的账号。开源模型和效率工具都在快速迭代早动手的人永远是用得最熟的人。