最近 AI 圈的消息密度是真的高。前脚还有人问gemma4 26b a4b moe 怎么部署后脚 Hy4 preview 直接放了个大招总参数 770B 的 MoE 开源模型发布同时配套的 WorkBuddy 限时两周免费。这两个信息绑在一起看对做 AI 应用、搞 agent 的人来说是个不小的信号——超大杯开源模型的赛道又热闹了而模型 工具打包打法的节奏也越来越快。这篇文章不打算复述发布会而是把这几个关键词拆开聊770B 到底什么水平、MoE 是怎么回事、本地部署现不现实、WorkBuddy 值不值得在免费期内上手。1. 先把770B MoE 开源这几个词拆明白1.1 preview 版本到底意味着什么preview在模型圈里通常意味着这不是最终版本而是先放出来给社区试用的预览版。选择以 preview 形式发布一般有几个目的一是提前收集真实场景下的反馈二是验证新架构或新训练方案在大规模参数下的稳定性三是在正式版到来之前先占据开发者的注意力。对开发者来说preview 阶段反而是最有价值的观察窗口。新模型的 benchmark 数据往往是发布方自己选的评测集也是公开的很容易被刷得很漂亮。但 preview 意味着大量真实使用者会用各种奇怪的任务去轰炸它这时候暴露出来的短板才是真短板。开源权重 preview 的组合等于你可以不看宣传稿自己拉权重、自己跑任务、自己下结论。这一点比看任何发布会都要实在。1.2 770B 是总参数不等于推理时全部激活很多朋友看到 770B 第一反应是这么大的模型怎么跑得动这里其实有一个常见误区——770B 说的是模型总参数量而 MoEMixture of Experts混合专家架构下每一个 token 实际只会激活其中一小部分专家网络。举个例子你就懂了。DeepSeek-V3 总参数 671B但因为它是 MoE 架构实际推理时只激活约 37B 参数。Hy4 preview 的 770B 如果采用类似的稀疏激活思路推理时的活跃参数量大概率远小于 770B 这个数字。也就是说770B代表的是这个模型的知识容量和组织规模而真正每次计算的开销看的是激活参数。这就好比你是一家大公司的行政公司档案柜里存着全体员工的花名册总参数但每天真正在项目上干活的人只是其中一部分激活参数。花名册再厚日常运营成本也不会按全员规模计算。对本地部署来说这个区别直接决定了你是需要一整个机柜还是一台工作站就能跑起来。1.3 开源的意义不只是免费下载开源权重这件事对普通用户来说是可以白嫖一个超级模型但对做工程的团队来说意义完全不同。权重在手意味着你可以做微调、做量化、做蒸馏、做私有化部署。数据不出内网这在很多行业是刚需尤其是金融、医疗、政企这类对数据合规极其敏感的场景。另外开源模型的可复现性也是优势。你把同样的权重部署到自己的服务器上产出的结果是确定的、可控的不会因为云端服务接口升级就突然变了行为。这一点在做 agent 或自动化流程的时候特别重要——你的业务流程不应该建立在一个随时可能改动的黑盒上面。Hy4 preview 选择开源等于给了大家一个可以把工作流钉在某个具体版本上的机会。2. MoE 架构到底好在哪里为什么大家都在卷2.1 用专科医院来理解 MoE 的运作方式MoE 这个概念听起来高深其实特别像专科医院。普通综合医院里每个医生都具备全面的基础知识来了什么病都能看一点但遇到特别专的疑难杂症就得转诊。而专科医院的做法是挂一个总台路由器根据你的症状token 的特征把你分诊给对应的专科医生专家网络。在 MoE 模型里这个分诊动作就是路由网络router做 top-k 选择。比如一个 770B 的模型内部可能被拆成了上百个专家模块每一个 token 进来路由器只挑选最擅长处理这类信息的几个专家去计算。你不用让全医院所有科室都来会诊几个关键科室就够了。这样带来的好处是直接的模型的知识储备可以做得很大但每次推理的计算开销却能压住。这在训练和推理成本上都占优势也让更大的模型 更高的质量这条路可以继续走而不会被算力成本彻底卡死。2.2 MoE 没那么简单负载均衡、路由坍塌、专家利用率不过 MoE 也不是白拿好处的。训练阶段最头疼的问题之一就是路由坍塌——如果路由器学偏了所有 token 都往同一个专家那里涌其他专家就闲置了模型容量被浪费训练效果不升反降。所以现在主流做法是给路由加负载均衡损失鼓励 token 尽量均匀地分到各个专家。推理侧也有隐患。MoE 模型如果专家之间的利用率差异很大那么部署时容易出现有些 GPU 忙死、有些 GPU 闲死的现象。做推理优化的人会专门去分析专家路由的分布调整切分策略尽量让负载均衡。这也是为什么同样是 770B 的模型有人部署出来又快又稳有人部署出来时不时卡顿——很多问题不在模型本身而在调度策略。还有一个工程上的小细节MoE 模型在显存占用上除了权重本身还要多出一份路由计算的中间开销。这意味着即使激活参数不大部署时也不能只按激活参数去配显存权重还是要全部加载进来的。这一点到了第 3 部分算账的时候你就知道有多关键了。2.3 开源大模型集体转向 MoE不是偶然回看最近一年发布的开源大模型从 DeepSeek-V3、Qwen 系列后续版本到 MiniMax H3 开源MoE 架构几乎成了标配。原因很简单训练成本更可控推理成本也更可控。大模型公司既要拼参数规模、拼 benchmark又要控制单位成本MoE 是当前平衡这两者的最优解。对普通开发者来说这个趋势是实打实的好事。MoE 模型意味着更强的能力不必等价于更贵的 API。同样是 770B 的容量如果激活参数控制得当API 定价理论上可以比同规模的 dense 模型低很多。如果你正在做 agent 类产品token 消耗是主要成本项那关注 MoE 模型的性价比就非常有必要。这也是为什么这次 Hy4 preview 发布大家除了看模型跑分更关心它的实际推理价格和部署难度。3. 本地部署 770B先把账算明白再动手3.1 显存账三种精度下的硬性需求先说结论770B 参数的模型无论是不是 MoE权重都是要整包加载进显存或者内存的。区别只在精度。我在实际项目里的习惯是先按这个表粗算再决定走哪条路精度权重占用约推理时实际占用含 KV cache 等部署难度FP16 / BF16约 1540 GB轻松超过 2 TB企业级多机多卡FP8约 770 GB约 1 TB 上下需要 8 卡 A100/H100 级别INT4 / AWQ / GPTQ约 385 GB约 500 GB4~8 张 80GB 显卡可试换算方式很简单1 个参数在 FP16 下占 2 字节在 INT4 下占 0.5 字节。770B × 2 字节 1540GB770B × 0.5 字节 385GB。这只是权重本身还没算 KV cache、激活值和路由计算的额外开销。所以如果你手头是几张 RTX 409024GB想本地跑 770B 的完整模型基本不现实。但别急着放弃后面我会说量化之后怎么在有限资源下够一够。3.2 量化方案怎么选AWQ、GPTQ、FP8 还是 GGUF量化这个词这两年已经被聊烂了但真正上手时很多人还是懵。我按自己的经验给你一个选型思路FP8精度损失最小适合有 H100/H200 等原生支持 FP8 计算的卡。如果硬件支持优先选它几乎没有肉眼可见的效果下降。AWQ / GPTQINT4 级别的权重量化显存占用能降到三分之一甚至四分之一。AWQ 对激活值的处理更细致实际效果普遍比 GPTQ 稳一点尤其是在数学和代码任务上。个人更推荐 AWQ。GGUF主要给 Ollama、llama.cpp 这类工具用的格式。好处是 CPU GPU 混合跑也行内存够大就能启动适合没有高端显卡的玩家先跑起来看效果。代价是速度慢而且大模型在 CPU 推理的吞吐量比较感人。有个小提醒770B 这种体量量化完成后一定要做效果验收。拿一组你业务里有代表性的 prompt在量化前和量化后各跑一遍人工对比输出质量。别只看显存降了多少模型变笨了才是最大的坑。3.3 用 vLLM 起服务的一次完整实操记录如果你手头确实有 A100/H100 这种级别的资源努努力部署 770B MoE 是可行的。下面是我自己部署类似规模 MoE 模型的标准流程Hy4 preview 的权重公开后基本可以照搬第一步安装 vLLM。新版本对 MoE 的支持已经很成熟直接pip install -U vllm第二步下载权重。国内网络环境优先走 ModelScope速度比 Hugging Face 稳太多pip install modelscope modelscope download --model your_namespace/Hy4-preview-770B-AWQ --local_dir ./Hy4-preview-770B-AWQ第三步启动推理服务。量化版参考命令vllm serve ./Hy4-preview-770B-AWQ \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --quantization awq--tensor-parallel-size要跟你实际的 GPU 数量一致8 就是 8 张卡并行切分模型。--gpu-memory-utilization建议不要拉满到 0.99留一点余量给 KV cache 和系统开销0.9~0.93 是我习惯的区间。第四步测试服务是否正常curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: ./Hy4-preview-770B-AWQ, messages: [{role: user, content: 用一句话解释 MoE 架构}], max_tokens: 512 }能正常返回内容说明服务起来了。接下来就可以接 API 客户端或者 WorkBuddy 这类工具了。3.4 跑不动的人还有两条路API 和镜像站如果你看完上面的部署流程觉得门槛太高也不用沮丧。770B 这个体量本来就不是给个人玩家本地跑的绝大多数人会走 API。发布方限免 WorkBuddy 两周目的就是让更多人先通过云端把模型用起来降低上手门槛。另外国内几个开源镜像站在这种时候作用非常大。清华、阿里、ModelScope 都有模型加速下载的方式如果你只是想下载权重做离线分析、做评测或者在你的服务器上二次分发务必优先走这些镜像别傻乎乎地去 Hugging Face 硬拉。几百 GB 的文件走对渠道和走错渠道体验差出十倍不止。4. WorkBuddy 上手先搞清它和 CodeBuddy 的区别4.1 WorkBuddy 不是 CodeBuddy别弄混了很多人看到Buddy就默认它和 CodeBuddy 是一回事其实两个定位差别还挺明显的。我直接用一张表说清楚对比项CodeBuddyWorkBuddy核心定位代码补全、代码生成、研发辅助通用工作台 / Agent 任务编排目标场景IDE 内写代码、改 bug、写单测跨工具任务处理、流程自动化典型用户开发者开发者 运营 知识工作者核心卖点代码上下文理解、补全准确率Skill 体系、业务流程串联、多工具接入有重叠吗部分重叠但深度不同更偏个人工作台而非编辑器助手从名称和目前公开信息来看WorkBuddy 更像是一个干活的台子而不是写代码的助手。它把任务拆解、工具调用、流程编排这些能力打包在一起然后接上一个或多个大模型。Hy4 preview 负责想WorkBuddy 负责做。4.2 安装、配置与接入模型的完整步骤WorkBuddy 的安装方式按这类工具的一般做法通常是客户端安装 模型配置两步走。实际发布后以官方文档为准但基础套路可以提前熟悉第一步下载安装包完成安装。安装时注意选择数据目录建议放在剩余空间大的盘因为工作台会缓存模型上下文、技能包和日志。第二步进入设置界面配置模型服务。如果你已经按第 3 节部署好了 vLLM 服务那地址就是http://localhost:8000/v1填上对应的模型名即可。如果你想直接走云端也可以填入 Hy4 preview 云端 API 的 Key。第三步配置 Skill技能。这类工具的 Skill 类似插件是预定义好的提示词模板 工具调用流程。比如资料整理技能会触发搜索、摘要、归档一整套动作。免费期内建议把官方 Skill 全装一遍看看哪几个真正用得上别贪多。第四步跑一个最简单的任务验证链路。让它整理一篇文档并输出要点确认从模型调用到结果输出是通的再开始搭复杂流程。4.3 用 WorkBuddy 搭建个人工作台的三个可复现场景场景一信息收集与整理。把日报、周报、会议纪要这类重复性工作扔给它。我实测这类工具的通用做法是把最近的资料扔进一个文件夹让它自动生成摘要和待办事项。省下的时间比你想象的要多。场景二业务流程串联。比如监控某个页面变化 → 提取新增内容 → 生成摘要 → 推送到群聊。这类任务以前要用爬虫 API 拼半天现在 WorkBuddy 的 Skill 体系可以直接组合。免费期内很适合做这种 PoC 验证。场景三作为一个模型前端统一调度。如果你的团队同时有 Hy4 preview 和几个小模型WorkBuddy 这类工具可以做成统一入口不同任务路由到不同模型。这样既能用大模型保证质量又能用小模型控制成本日常运维也方便。4.4 两周免费期到底应该测什么免费的东西最容易让人乱用最后两周过去了啥也没得出结论。我建议你按下面的清单有目的地测稳定性连续跑 50 个任务记录失败率、超时次数、报错信息。效果挑 5~10 个你实际业务里的高频任务跑完保存结果和现有方案对比。成本用 API 的情况下统计每天 token 消耗估算正式运营的成本。协作如果团队多人使用测试账号权限、任务分配、记录共享这些协作功能。边界故意喂一些边界输入看它的兜底能力和报错机制是否友好。免费期不是用来玩的是用来决定要不要掏钱的。带着这个心态去测两周时间完全够你做一个初步评估报告了。5. 实操中踩过的坑和排查思路5.1 模型部署环节的典型问题速查现象原因处理思路启动时报显存不足OOM并发数设太高或权重整包超预算调低--max-model-len和并发或换 INT4 量化版输出速度极慢CPU 参与推理或张量并行配置不对检查--tensor-parallel-size是否与显卡数一致确认 no CPU offload请求超时首个 token 延迟太高加大前端超时时间MoE 大模型冷启动就是慢不要用普通模型的标准去要求效果明显变差量化精度损失对比 FP8 / INT4 效果或对业务 prompt 做针对性验收下载速度龟速走了不合适的下载渠道换 ModelScope 或国内镜像我自己踩过最疼的一次是部署时把--gpu-memory-utilization设到了 0.99结果服务起来一跑长文本就 OOM查了半天才发现是没给 KV cache 留余量。这种问题往往是看起来是显存不够其实是参数不合理的配置问题。5.2 WorkBuddy 使用环节的典型问题现象原因处理思路Skill 执行到一半卡住某个子任务依赖的模型或工具超时把大任务拆小给每个子步骤设置单步超时结果和预期差很多预设的提示词模板不适合你的任务修改 Skill 里的 prompt加入你领域的术语和格式要求本地模型接入后很慢本地推理吞吐量低改用云端 API或换更小的量化模型做简单任务任务日志找不到没设置好日志级别或数据目录优先打开详细日志模式排查问题全靠它用这类 agent 工具最大的经验是别指望它一次就完美执行复杂任务。正确姿势是先小步验证——一个 Skill 一个 Skill 地测每一步跑通了再组合。出了问题先看日志再看模型返回大多数问题其实都出在任务描述不够具体上。6. 最后说几句实在话Hy4 preview 这次发布的节奏很有意思770B MoE 开源把技术和声量都拉起来了WorkBuddy 限时免费又把新用户导入成本降到了零。对开发者来说这是一次低成本验证超大模型 智能工作台这套组合适不适合自己业务的窗口期。我的建议是分两步走。第一步先花一晚上把 WorkBuddy 装好接上 Hy4 preview 的云端版本挑三个你日常工作里最烦、最重复的任务跑一遍感受一下流程是否真的顺。第二步如果效果让你动心了再评估本地部署的 GPU 成本和量化方案别一上来就买显卡。最后再分享一个小技巧这类工具的 Skill 其实是可以自己改的。免费期别光用官方预设试着把你自己的业务规则、输出格式、检查清单写进 Skill 里。工具的能力边界远远不止官方文档那几条真正拉开差距的是你愿不愿意花时间去调教它。
