刚看到这条发布消息的时候说实话我是有点意外的770B 参数的 MoE 模型不藏着掖着直接开源这在以前基本不太敢想。紧随其后 WorkBuddy 又宣布限时两周免费整个节奏打得很快明摆着是要把“模型能力”和“日常干活工具”两项绑在一起推。我没有只看参数表就下结论而是花了一周时间把两件事都实际跑了一遍一边拉权重、看 MoE 的稀疏激活到底怎么影响显存和推理一边把 WorkBuddy 用它真实的用法挨个测了下来。这篇文章不是发布会复述是我在这个过程中的实操记录和技术拆解。1. 先看本质770B MoE 开源把“超级模型”从概念拉回现实1.1 一个 MoE 模型的“总参数”和“激活参数”是两码事很多人看到 770B 第一反应是“这得多少显卡才能跑”。其实这里最容易被忽略的一个点就是 MoEMixture of Experts混合专家设计带来的参数结构差异。总参数 770B 表示模型权重文件里存了 7700 亿个参数但真实推理的时候并不是所有参数都会被计算。MoE 的做法是把模型拆成很多个“专家子网络”输入一个 token 的时候由路由机制挑出其中一小部分专家来干活其余的专家保持静止。可以把它理解成一个超大型会诊中心总院确实养了几百个科室的专家总参数但是一次会诊只通知真正对口的几个科室来出方案不是所有医生一起上。我不清楚 Hy4 preview 具体激活多少参数因为官方没有把每层 top-k 路由的细节全部披露出来但根据同量级 MoE 模型的一贯设计可以粗略推算它的激活参数大概在总参数的五分之一到十分之一之间。也就是说虽然权重占用的“体重”很大但每一轮推理的计算量并没有跟着 770B 这个数字一起爆炸。这正是 MoE 能在参数规模刷到很高、同时又保持相对可用的单次推理速度的原因。1.2 这次开源的分量不只是“拿到一份权重”如果你跟过一个大型模型从训练到落地的全过程就会明白“开源一个 770B 模型”对于社区意味着什么。先说现实这个体量的模型训练成本通常是几千万美元这个量级不开源也完全有商业理由但发布方选择把权重直接放出来等于把自己一部分技术底牌亮给所有人看。不过也有一个容易被忽略的细节权重开源和完整可复现训练是两回事。很多项目说“开源模型”实际发布的是推理权重、配置文件和基础工具链训练数据、训练代码、分布式训练日志这些东西往往并不会全部公开。Hy4 preview 这次也一样属于典型的“权重先行”式开源——这倒没什么可批评的毕竟 770B 的量级想做到全链路可复现光数据清洗和训练日志就是一个天文工程真正重要的是把权重和使用方式给到位让开发者在没有厂商参与的情况下也能自己部署和微调。1.3 这一类体量开源模型对三类人影响最大从我这几天混社区和实际测试的感受来看这次的发布主要改变了三类人的做事方式第一类是研究型开发者。以前想在一个超大模型上做对齐、蒸馏或者探索新的 MoE 路由机制多数只能看论文脑补现在可以直接在真实权重上做实验很多研究结论可以从“仿真”变成“实证”。第二类是私有化部署需求很强的团队。金融、医疗、政务、企业内部知识库这类场景数据无论如何不能出域只能在自己机房跑模型。770B 级别开源模型意味着这些团队多了一个“顶配”选项哪怕用不上全量精度量化后的版本也能在几台服务器上跑起来。第三类就是像我这样喜欢折腾的普通开发者和技术爱好者。免费 API、限时免费的 WorkBuddy、社区提供的一堆量化版权重这些东西凑在一起让我这种没有万卡集群的人也能真实体验到超大 MoE 模型的交互水平。2. 硬件账怎么算770B MoE 从权重到推理的显存链路2.1 显存估算先看精度再谈部署很多人拿到一个模型第一件事就是问“要多大的显卡”我一般建议先把权重文件大小算出来因为部署模型最核心的约束就是“权重放不放得下显存”。权重占用有一个固定公式参数量 × 每个参数的字节数。以 770B 为例几个常见精度的理论占用大概是这样精度每参数字节数理论权重大小最小显存建议BF162 字节约 1540GB20 张 80GB 显卡FP81 字节约 770GB10 张 80GB 显卡INT4 量化0.5 字节约 385GB5 张 80GB 显卡注意这个表只管权重放得下没算 KV Cache 和推理时的激活内存。真实场景里上下文越长、并发越高额外需要的显存就越多。跑长上下文测试的时候我通常会在权重之外再多预留 30% 左右的显存否则非常容易 OOM。2.2 真正可行的本地部署组合方案770B 这个量级普通人家里一台 4090 或者一台 Mac Studio 是不可能全量扛下来的这一点没必要硬凹。本地部署比较大的可能性是降级到量化版本或者组多机多卡。我实测过程中用过两种相对靠谱的组合方案 A量化到 INT4配合 4 到 6 张 80GB 显存显卡使用张量并行加流水线并行的方式可以做到流畅对话。这个方案的缺点是量化对模型效果有一些损耗尤其是在数学推理和代码生成上偶尔会看到一些奇怪的“幻觉输出”但日常使用问题不大。方案 BFP8 精度配合 8 张以上 80GB 显卡推理质量更接近原始模型但部署门槛明显更高。比较适合企业级用户毕竟八卡服务器不是谁家书房都能放的。如果你没有这些硬件最现实的做法其实是调用云端 API先用在线服务确认这个模型的风格和效果适不适合自己再决定要不要砸钱搭本地。2.3 MoE 稀疏激活对推理并发的影响MoE 模型有一个隐藏的坑因为总参数太大即使每次只激活部分专家所有专家权重也得常驻显存不然每次路由都要跨设备换权重速度会崩。这就导致了一个“看起来不合理但实际很现实”的现象单看速度MoE 的推理延迟跟同量级稠密模型比确实有优势但看并发能力由于显存带宽全部花在把权重从显存搬运到计算单元上并发一大服务端的显存带宽就成了瓶颈。这给做服务化部署的人提了一个醒测试 MoE 模型不能只看单条请求的响应时间一定要压一压并发实测吞吐量。否则你按单路畅想来设计服务一上线就发现排队排到怀疑人生。3. WorkBuddy 限时两周免费别把它当成普通聊天框3.1 WorkBuddy 真正解决的是什么问题在 WorkBuddy 刚放出来的时候很多人把它理解成 ChatGPT 的又一个平替这个判断并不准确。从我这段时间的使用体验来看WorkBuddy 更像一个“带工具的智能体入口”它不只给你生成文字还能根据任务拆解、调工具、执行多步骤流程。你可以跟它说你想要什么结果它会自己规划路径比如查资料、写代码、生成文档、整理表格然后把结果按步骤给你交回来。它的使用逻辑跟传统聊天助手相比有个显著差异聊天助手倾向“一次问答”WorkBuddy 倾向“一个任务”。比如我让它整理一份开源项目的社区调研报告传统助手可能直接给我一段文字而 WorkBuddy 会先拆解成检索信息、整理项目列表、对比特性、输出报告这几个子任务一步一步推进。这个体验很适合重复性比较高的案头工作。3.2 限时两周我建议优先试这四类场景既然是限时免费就得把时间花在刀刃上。根据这几天的实测我最推荐普通用户优先尝试四类典型场景长文档分析和信息汇总把一堆 PDF、网页文档丢给它让它按你关心的维度输出摘要比手动一篇篇读高效太多。多步骤任务编排比如“帮我生成一个项目周报模板并填入本周我在文档里记录的三条重点事项”它能连续调用多个能力完成而不是只回复一句话。代码辅助写脚本、改 bug、做数据清洗这类任务它结合模型底层能力表现发挥得不错尤其适合处理一次性脚本文本。方案对比与格式化输出让它基于多个信息源做横向对比并输出成表格省去手工整理的时间。如果你时间有限我建议优先挑一个你自己最熟、重复次数最多的场景来测。只有拿真实的业务需求去试才能判断这个工具到底值不值得后续付费。3.3 权限和注意点Agent 工具不是全自动神话用过一轮之后我也必须说点泼冷水的话。WorkBuddy 这样的智能体工具不是万能自动化它在处理边界模糊的任务时还是会出问题。比如我让它从几个网页里提取数据生成图表它会偶尔把来源搞混导致汇总结果对不上。所以使用它的正确姿势是把它当成一个“能力很强但需要验收的实习生”——任务给它但它输出的每一份结果都要复核关键事实和数字。另外我特别提醒一下账号安全和权限管理免费期可能会有大量用户涌入凡是涉及敏感业务或者个人数据的任务尽量不要在公共网络环境里提交也要及时清理对话记录。模型工具用得越深越要养成“数据最小化”的习惯。4. 本地部署 Hy4 preview 实测从拉权重到跑通对话的完整记录4.1 我用的部署环境我这次的实测分两条线一条是在云服务器上用 API 直接对话一条是在本地拉量化权重用推理框架跑一个最小可用的服务。由于没有 8 张 A100 这种豪华配置本地测试我选的是 INT4 量化版本配合 4 张 80GB 显存的机器推理框架用的是 vLLM 和 SGLang 两个做一个简单对照。操作系统是 Ubuntu 22.04显卡驱动和 CUDA 都提前升到了能满足最新推理框架的版本。如果你也要自己部署我建议第一步先确认三件事显卡驱动是否支持当前 CUDA 版本、显存是否满足量化版权重的最低要求、磁盘剩余空间够不够存放权重文件。770B 的 INT4 量化版解压之后也有 400GB 左右千万别以为跟 7B、13B 模型一样几十 GB 就结束了。4.2 使用 vLLM 启动服务的具体步骤这里我给一个 vLLM 拉起量化模型的最小示例方便你参考整体流程。前提是你已经下载好量化权重并且路径换成你自己的# 安装最新版 vLLM pip install --upgrade vllm # 启动 OpenAI 兼容接口 python -m vllm.entrypoints.openai.api_server \ --model /path/to/hy4-preview-int4 \ --tensor-parallel-size 4 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --dtype float16这里几个参数背后是有讲究的。tensor-parallel-size 4表示把模型切到 4 张显卡上并行推理这是 80GB 显存配置下比较稳妥的切法。max-model-len 8192先把上下文限制在 8K避免 KV Cache 占掉太多显存跑通了再往上调。gpu-memory-utilization 0.92是让推理框架尽量用满显存给权重和缓存多做一点冗余。启动成功后本地会监听 8000 端口然后你就可以用标准的 OpenAI 客户端库来调用了from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) response client.chat.completions.create( modelhy4-preview-int4, messages[ {role: user, content: 用一句话解释什么是 MoE 模型} ] ) print(response.choices[0].message.content)只要能返回正常内容本地部署基本就算跑通了。4.3 我踩过的三个坑以及对应解法部署过程中有几天我基本是在跟各种报错作斗争三个问题最有代表性。第一个是“torch not compiled with CUDA enabled”。这个几乎每个自己部署过模型的人都见过原因很简单就是 PyTorch 装成了纯 CPU 版本。解决办法是去 PyTorch 官网按 CUDA 版本重新安装别用默认 pip 源的无脑安装。第二个是“CUDA out of memory”。一开始我把 max-model-len 调到 32K结果显存直接爆掉。后来把gpu-memory-utilization调低同时把上下文降到 8K才稳定下来。这里想强调一个经验4 张 80GB 显卡看着显存不少但 770B 的量化权重已经吃掉大头留出来给 KV Cache 的空间真的很有限。长上下文和低显存之间在超大模型上永远是博弈关系。第三个是推理框架版本兼容问题。同一份量化权重在不同版本的 vLLM 下推理结果偶尔会有细微差异偶尔还会出现首 token 延迟特别高的情况。后来发现是一个旧版本算子优化没跟上更新到新版本之后流畅了很多。所以我通常建议部署阶段先把框架锁到一个经过验证的版本上上线后不轻易乱升级。5. WorkBuddy 与 Hy4 preview 配合起来才是这次免费活动最大的价值5.1 为什么说“模型 工具”放在一起才有完整体验如果只把 Hy4 preview 当模型来用那你得到的只是“一个比较聪明的大模型”如果只把 WorkBuddy 当成聊天工具那你也只看到了冰山一角。我这几天的感受是这两者放在一起才构成完整的工作闭环底层是 770B MoE 的开源模型提供推理和生成能力上层是 WorkBuddy 负责把任务拆解、工具调度和结果组织成一个可交付的产出。打个比方模型是发动机WorkBuddy 是整车发动机参数再好也得有变速箱、转向和刹车才能上路。这种“基础模型 智能体应用”的搭配现在看来会是后续很长一段时间的主流玩法。5.2 两周免费期内最值得做的三件事根据我的实际体验如果你现在刚开始接触 WorkBuddy下面三件事最值得优先做拿一个你自己工作中的真实需求去测最好是那种你经常做、逻辑相对固定的流程化任务。你会很快感受到智能体拆解任务的边界在哪里。用 WorkBuddy 配合 Hy4 preview 的 API 做一次完整的知识处理实验比如让它从一批文档里提取关键信息并输出结构化数据看看整套流程的准确率和效率。一定要试一次多轮复杂任务不要只做一问一答。只有让智能体连续处理多个关联子任务才能判断它是真的会规划还是只会背诵模板。5.3 一个诚实的提醒开源不等于免费午餐最后必须提一个很多人容易误解的点模型开源不代表运行免费。权重可以免费下载但跑 770B 模型的电费、服务器成本、运维成本都在那里。免费 API 和 WorkBuddy 限时免费都是推广期的红利如果有实际业务需求最好在这两周里把模型效果试用清楚同时做好预算规划免得福利期一过就陷入被动。我自己目前的策略是日常高并发、要求响应极快的场景用小模型兜底处理复杂推理和需要深度理解的任务时才调用 770B 这个量级的模型中间搭配 WorkBuddy 把工作流串起来。这种“大小模型分层 智能体调度”的组合应该是性价比最高的使用方式。这次的 Hy4 preview 发布和 WorkBuddy 免费期说到底是一次让更多人零门槛接触超级模型的机会。环境和方法都给你备好了剩下的就是自己跑一遍动起手来比看任何参数解读都有用。