最近社区热度最高的一个消息就是 Hy4 preview 正式发布770B 参数的 MoE 开源模型外加 WorkBuddy 限时两周免费用。以前这种体量的模型基本只活在论文和云 API 里普通开发者只能对着计量表算钱。现在权重直接放出来等于把“能不能自己部署”这个问题彻底抛回给了想用的人。这篇文章我打算从几个角度拆一下Hy4 用 MoE 架构到底解决了什么问题、开源之后真正能拿到什么、WorkBuddy 在这个链条里扮演什么角色以及如果我真要本地部署一套来配合 WorkBuddy 用到底该怎么操作、会踩哪些坑。适合想折腾大模型本地化、或者正在选型下一套 AI 工作流的开发者看。看完至少能对“770B 到底能不能自己跑”有个明确判断。1. Hy4 preview 是什么770B MoE 的核心看点1.1 总参数 770B但 MoE 改变了“参数决定门槛”的玩法先聊 MoE也就是 Mixture of Experts混合专家架构。很多人一听 770B 就吓到了觉得这不得要十几张甚至几十张卡才能跑。实际上 MoE 最大的特点就是“所有专家都注册在册但每次只让一部分人上班”。你可以把 MoE 想成一家大型咨询公司。770B 是公司里全部员工的数量但每个问题进来之后路由器会先判断这属于法律纠纷、财务审计还是技术方案然后只唤醒跟对应领域相关的一组专家。剩下的人继续待命。所以前向推理的计算量取决于每次唤醒多少人而不是公司总共有多少人。这也是为什么 Hy4 这类 MoE 模型在论文里经常强调“总参数”和“激活参数”的区别。总参数 770B 代表模型容量、知识覆盖面、可学习的模式足够多激活参数代表实际推理时动用的计算资源。稀疏激活的意思是模型变大不需要推理时间等比例变大这也是 MoE 能在超大参数量下保持可用性的核心原因。但这里必须提醒一句激活参数省的是计算不是内存。模型权重仍然需要全部加载到显存里因为路由器说不准下一秒需要哪一个专家。也就是说即便激活参数只有几十 B部署 770B 模型时对显存总量的需求依然摆在那。只是说推理速度不会像“同体量 Dense 模型”那么夸张地慢毕竟每次只算了很小一部分。1.2 一次开源发布为什么会引发连锁影响Hy4 preview 发布后社区最关注的不是“又多了一个大模型”而是“开源”和“WorkBuddy 免费用”这两个信号叠加。从模型侧看MoE 架构的开源影响面其实很高。以前想研究超大模型的路由策略、专家选择、负载均衡只能去翻论文看别人博客或者拿小参数模型模拟。现在有了 770B 的权重至少可以真实跑一跑推理观察不同 prompt 下路由器选择了哪些专家甚至做量化和稀疏化研究。这对做部署框架、模型压缩、agent 工具链的人来说是特别实在的物料。从应用侧看开源意味着数据可以不出本地。企业里很多场景不能把客户资料、财务数据、内部代码丢到外部 API 去但又想用大模型的能力。Hy4 开源后就多了一个选择在内部集群部署一套再通过 OpenAI 兼容接口接入现有系统。WorkBuddy 这类工具再把任务编排起来等于把“私有化大模型”这条链路打通了。所以这次发布的影响不只属于炼丹师也属于做工程、做产品的团队。770B 不再只是标题里的一个数字而是真正进入可选技术栈了。2. 开源不等于白嫖先看清许可证和能力边界2.1 开源模型到底开源了什么每次有大模型开源都会有人默认“权重有了代码有了那我啥都能干了”。实际差别很大。所谓的开源通常包括模型权重、tokenizer 配置、推理示例代码、评测结果有些还会附上微调脚本和训练数据说明。但训练数据、完整训练流程、数据清洗管线这类东西很多项目是不公开的。这一点对 Hy4 也一样。拿到权重只能说明你可以部署、可以做推理、可以在上面做微调实验但不代表你拥有了从零训练一个 770B 模型的能力。如果后续官方开放微调框架和评估脚本那才是更大的福利。另外一个容易踩坑的地方是许可证。开源模型不等于免费商用也不等于没有限制。有的模型允许商用但要求保留版权声明有的对月活用户数量有门槛有的明确禁止把它用来做某些高风险场景。Hy4 preview 作为 preview 版本许可证边界更值得仔细看一遍。尤其是打算接进企业项目的人别只盯着“770B”和“开源”两个词就默认可以全场景随便用。2.2 算清本地部署的收益和成本很多人拿到开源权重之后第一反应是部署但部署前最好先算账。我列一个对比表看完再决定是本地跑还是直接用托管 API对比项本地部署 Hy4直接使用云 API数据隐私数据不出自己的服务器依赖服务商的数据使用政策单次调用成本主要是硬件和电费按 token 计费长对话成本高延迟取决于自身机器和推理框架取决于网络和上游排队情况可定制性可量化、可改采样参数、可微调一般只能调 prompt 和少量参数运维成本需要自己管显存、模型更新、并发、监控服务商处理省心门槛至少需要多卡 GPU 加上大内存注册账号即可如果只是想在 WorkBuddy 里体验两周免费期没必要一上来就折腾本地部署先用官方接口把流程跑通再根据成本决定是否做私有化。但如果你想做数据敏感的自动化或者想把 WorkBuddy 长期绑到一个可控的模型后端上那本地部署 Hy4 就值得投入时间。3. WorkBuddy让 Hy4 从“会聊天”变成“会干活”3.1 它是做什么的光有 Hy4 这种模型你只能拿它做对话、续写、翻译、代码生成。但真正想让它替你处理“整理周报”“分析数据”“批量改写文档”这类任务就需要一个中间层把大模型和实际操作连起来。WorkBuddy 做的就是这件事。我在实际体验里把 WorkBuddy 理解成一个“任务调度员 工具管家”。你给它一个目标它帮你拆解成多个子任务然后决定什么时候调模型、什么时候执行代码、什么时候读写文件、什么时候调用外部 API。跟直接用 chat 窗口的差别在于WorkBuddy 会把任务流程沉淀成可复用的 skill技能第二次做同类任务就不用再一步步手把手教了。比如我让它“扫描当前项目的 todos按紧急程度生成明天的开发计划”它实际做的是先读取项目里的 todo 文件再用 Hy4 对任务做分类和排序最后输出一个 markdown 计划表。如果没有 WorkBuddy就只是一个文本生成器有了 WorkBuddy模型才真正有了执行闭环。3.2 两周免费期应该怎么规划和验证限时免费最忌讳的是“我先下载看看”。大模型工具的学习成本并不低两周时间如果只是随便点两下大概率什么都没验证出来。我的建议是先把你想让它做的事列成 3 到 5 个高频场景比如“会议纪要整理”“代码评审助手”“文案改写”然后集中在前三天把 WorkBuddy 跑通再拿剩下的时间测试稳定性和质量。WorkBuddy 的好处在哪它的模型后端是可以配置的不绑定某一个模型。所以在免费期内你可以先用官方托管服务测试效果等两周结束后如果不想续费直接把模型后端切到本地部署的 Hy4 preview 或者其他 OpenAI 兼容服务。也就是说WorkBuddy 使用习惯可以沉淀下来模型可以自由更换并不会因为限时免费结束就白忙活。这也是我看到这个发布时最看重的点模型负责能力WorkBuddy 负责流程两者解耦之后用户不用被任何一家绑死。4. 本地部署 Hy4 preview 的完整实操4.1 准备阶段显存、框架和权重先说实话770B MoE 模型不是一台普通工作站能玩的。想全精度 fp16 部署光权重就要 1.5TB 左右这已经超出绝大多数人的硬件范围。社区里比较现实的路线有两条一是用 GPTQ、AWQ 这类量化方案把权重压到 4bit然后在 8 卡 80G 或更多卡上张量并行推理二是直接接托管 API本地只做 WorkBuddy 调用。我的建议是如果你已经有 4 卡到 8 卡 A100/H100 这类环境可以一试如果只有单卡 24G还是不要硬来。MoE 的稀疏激活虽然让计算变省了但权重的存储需求依然按总参数量线性增长。硬要单机跑的结果就是反复 OOM浪费时间。部署框架我优先推荐 vLLM因为它对 OpenAI 兼容接口做得比较成熟WorkBuddy 这种工具可以直接把 base_url 指过来。SGLang 也可以但 vLLM 的社区文档和问题解决方案更多适合第一次上手。确认好硬件和框架之后先把权重下载下来。假设你已经把模型文件放到/models/hy4-preview目录下面就是标准流程。4.2 用 vLLM 启动本地 API 服务先建一个 Python 虚拟环境然后安装依赖python -m venv venv-hy4 source venv-hy4/bin/activate pip install -U vllm transformers accelerate这里强调一下尽量用虚拟环境不要直接往系统 Python 里装。vLLM 对 PyTorch、CUDA 的版本比较敏感一旦和系统里其他项目冲突排查起来很麻烦。依赖装好之后启动服务python -m vllm.entrypoints.openai.api_server \ --model /models/hy4-preview \ --tensor-parallel-size 8 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --enforce-eager几个参数解释一下--tensor-parallel-size把模型切到几张卡上并行推理。8 对应 8 卡如果只有 4 卡就改成 4。--max-model-len最大上下文长度。示例里设 8192足够大多数任务。如果显存紧张可以降到 4096。--gpu-memory-utilization允许使用的显存比例0.9 是给 KV cache 留一点弹性空间。--enforce-eager不启用 CUDA graph能减少启动时的显存占用但推理速度会有折损。启动日志里能看到模型加载耗时和显存占用情况。如果显示显存不够第一件事不是加并发而是把max-model-len降低或者换成更激进的量化版本。4.3 验证服务是否正常并处理并发服务起来之后用 curl 验证一下模型列表curl http://127.0.0.1:8000/v1/models如果能看到 Hy4 的模型 ID再测一个最简单的对话请求curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: hy4-preview, messages: [{role: user, content: 用一句话解释 MoE 架构}], temperature: 0.7 }返回内容里有choices和usage字段就说明服务正常。到这里WorkBuddy 已经可以把base_url指向http://127.0.0.1:8000/v1了。并发方面要提醒一句MoE 模型虽然单次推理只激活部分专家但多个并发请求同时进来时每个请求都需要独立的显存暂存 KV cache。不要因为“激活参数少”就拼命压并发实际压测时还是要盯显存余量。5. WorkBuddy 接入 Hy4 的配置方法5.1 安装与初始化配置WorkBuddy 的安装方式按官方推荐走一般就是一条命令pip install -U workbuddy-cli workbuddy --version第一次使用前先初始化配置目录。然后重点设置模型后端workbuddy config set model.backend openai workbuddy config set model.base_url http://127.0.0.1:8000/v1 workbuddy config set model.api_key local workbuddy config set model.name hy4-preview这里最容易被忽略的是api_key。vLLM 本地服务默认不校验 key但 WorkBuddy 这类工具为了保证兼容性一般还是会要求填一个占位符。填local或者not-needed都行但别不填否则某些版本会直接报 401。不同版本的 WorkBuddy 命令措辞可能有差异有的用workbuddy configure有的用wb config set。如果命令不对先跑一下workbuddy --help看本版本的提示别硬套网上的教程。5.2 创建第一个 skill从日常任务入手WorkBuddy 比较核心的功能是 skill。我平时最长用的是“会议纪要根据录音文本转成结构化周报”这个场景。你可以在 WorkBuddy 里创建一个 skill 文件夹里面放一个 YAML 描述文件大致长这样name: weekly-report description: 把零散的工作记录整理成结构化周报 inputs: - name: raw_text type: string steps: - use_model: hy4-preview prompt: | 请把下面的工作记录整理成三部分周报 1. 本周完成事项 2. 未完成事项及原因 3. 下周计划 工作记录 {{raw_text}}这只是最简化的写法实际 WorkBuddy skill 还可以加入文件读取、命令执行、API 调用等步骤。重点是理解它的设计思路把“模型生成”嵌进一个可复用的工作流里而不是每次从零写 prompt。创建好之后运行workbuddy run 根据本周群聊记录生成周报WorkBuddy 会拆解任务、找到合适的 skill、调用 Hy4 生成内容最后把结果写到输出目录。整个过程的日志在终端里能看到哪个步骤耗时多少调用模型花了多少 token都比较透明。我之前踩过一个坑在 skill 的 prompt 里写了一堆“你是一个优秀的助手”“请务必保证准确”这类话结果模型输出反而不稳定。后来我把 prompt 改成“抓重点、用项目符号、不超过 500 字”这样具体的格式约束效果立竿见影。对 Hy4 这种大参数量 MoE 模型它不缺知识和推理能力缺的是你对输出格式的明确指挥。6. 常见问题与排查技巧实录6.1 显存不够 OOM 怎么办如果你启动 vLLM 看到CUDA out of memory先别急着加卡。按下面顺序排查确认用的是量化版本。fp16 的 770B 权重几百 GB 起步普通多卡集群也不一定扛得住。降低--max-model-len。上下文长度直接影响 KV cache 占用从 8192 降到 4096 能省不少显存。调整--gpu-memory-utilization改成 0.85 或 0.8避免推理过程中的峰值溢出。检查是否还有其他进程占着 GPU。用nvidia-smi看看有时候不是模型太大而是别的服务把显存吃掉了。MoE 模型还有个特点虽然计算稀疏但显存占用是“全量”的。哪怕你这次只激活 20B 参数所有专家的权重也都在显存里候着。所以别用“激活参数量”来估算显存要用“总参数量 量化系数 KV cache”来算。6.2 WorkBuddy 连不上本地模型这个问题我遇到过很多次90% 不是 WorkBuddy 的问题而是base_url写错了。vLLM 的 OpenAI 兼容接口路径是/v1所以 WorkBuddy 里配置的要带上http://127.0.0.1:8000/v1不带/v1模型列表接口会 404。还有一种是 WorkBuddy 使用 HTTPS本地服务是 HTTP证书校验不过。如果强依赖本地服务看配置里有没有verify_ssl或allow_insecure这类开关。另外启动 vLLM 和启动 WorkBuddy 的机器如果是同一台用127.0.0.1就行如果是跨机器访问要确保 vLLM 启动时监听的是0.0.0.0默认的localhost只允许本机连接。排查时用一条 curl 命令先确认模型服务通不通再去看 WorkBuddy 日志能省掉很多瞎猜的时间。6.3 模型输出质量不稳定怎么办Hy4 preview 是 preview 版本推理质量不一定每次都稳定。我实际用的经验是降低采样温度temperature调到 0.3 到 0.5任务型输出明显更可控。在 system prompt 里写明输出格式比如“先给结论再给理由每条不超过 50 字”。尽量让 WorkBuddy 的 skill 把子任务切得更小。一次让模型干五件事不如拆成五个步骤每个步骤只做一件事。如果是代码任务把“生成代码”和“执行代码”分开。生成后先让模型自查一遍再执行能减少很多低级错误。注意别在 WorkBuddy 上层堆太多“反思”“批判”这类 meta prompt。MoE 模型本身已经有很强的推理能力过度的自问自答反而会让任务流程变长输出变得更啰嗦。简洁、明确的指令在这里比“花式 prompt”有用得多。6.4 许可证和后续升级问题最后再说一个容易忽略的点preview 版本往往意味着后续会有正式版、会有 API 变化、会有权重更新。你在 Hy4 preview 上做的量化配置、skill 兼容测试不要写死在系统里。尽量把模型名、路径、base_url 都做成配置项等正式版发布后只需要切换配置就能升级。WorkBuddy 的 skill 也是同理尽量让每个 skill 不要依赖特定模型。这样就算以后换更大的模型或者换成本地更小的模型工作流还能继续用。7. 实操后想多说几句Hy4 preview 真正让我兴奋的点不是“770B”这个数字而是 MoE 加开源的组合终于把超大模型从论文拉到了可以实操的层面。虽然部署门槛依然高但至少路径是清晰的权重下载、量化、张量并行、接入 WorkBuddy每一步都能验证。WorkBuddy 限时两周免费这个窗口最值得做的事不是研究它有多少功能而是把它塞进你真实的日常工作流里跑一遍。只有让工具处理真实数据、真实任务你才能知道哪些步骤需要调 prompt、哪些步骤需要建 skill、哪些场景根本不该用大模型。免费期结束后就算不续费你已经攒下一套能继续用的流程和配置再落到本地 Hy4 上等于把这次发布的全部价值都拿住了。最后分享一个小技巧我在 WorkBuddy 里给常用任务都建了 skill但每个 skill 的描述里都会写清楚“什么时候不要用”。比如周报 skill 会注明“数据缺失时不要硬编造”。这样当任务触发条件不足时WorkBuddy 会直接告诉我缺什么而不是让模型硬着头皮瞎编。这个小改动帮我省掉了大量人工核对的时间也是我建议你上手后第一个要做的事。