1. Hy4 preview 发布先搞清楚770B MoE到底意味着什么1.1 这次发布的东西拆开看其实有两块Hy4 preview 发布的消息在几个技术群里刷屏了。770B、MoE、开源、WorkBuddy 限时免费这几个词叠在一起确实很难不让人心动。但我也看到不少人把注意力全放在770B这个数字上反而没搞清楚这次到底开源了什么、免费了什么。先把发布内容的完整梳理一遍免得后面讨论全跑偏。Hy4 preview 这次开源的是模型权重和基础推理代码模型采用 MoEMixture of Experts专家混合架构总参数量达到 770B。MoE 的选型本身不算新鲜DeepSeek、Qwen 这些开源阵营早就走过这条路了但 770B 这个量级依然把开源模型的天花板往上顶了一截。和同等体量的稠密模型相比MoE 的大容量 稀疏计算组合理论上能在推理成本可控的前提下拿到更强的效果。另一条线是 WorkBuddy。这是一个面向任务执行的 AI 工作台这次限时免费两周。它的定位不是又一个聊天框而是把模型输出转成可落地动作的 Agent 编排层支持 Skill 插件、自定义指令和本地部署。更关键的是你可以把本地跑起来的 Hy4 作为推理后端接进去形成开源模型 私有工作流的闭环。给还没动手的朋友一个建议别急着拉权重先把发布页的技术说明和仓库 README 读完尤其是有没有现成量化权重支持哪些推理框架这类信息能帮你省掉大量试错时间。1.2 770B 不等于 770B总参数和激活参数的换算逻辑这是整篇记录最重要的一小节。把这个概念捋顺后面所有部署决策都可以从它推出来。稠密模型的 770B 参数量就是 770B每个 token 都要经过全部参数算力需求和参数量线性增长。MoE 不是这样。MoE 把网络拆成若干专家Expert加上一个路由网络Router每个 token 进来路由网络先判断该交给哪些专家处理然后只激活其中一小部分专家。所以评价 MoE 模型必须同时看两个数字总参数和激活参数。用公司派单来打比方一家公司有 770 人每天来业务前台看一眼工单判断这是财务问题、法务问题还是技术问题然后只叫几个对应岗位的人来处理。公司总人数决定的是这家公司能接多大体量的活儿也就是知识容量但真正产生工作量的只有被叫到的那几十个人也就是激活参数。前台就是路由网络被叫到的人就是被激活的专家。换算到算力上MoE 单次推理的计算量大致和激活参数成正比。按照开源 MoE 的惯例激活比例通常在总参数的 1/10 到 1/4 之间。这么估算的话Hy4 preview 的 770B 总参数单次推理真正参与的很可能只有 60B 到 190B 的量级算力成本和 70B 左右的稠密模型差不多。这就是为什么 770B 看着吓人社区却依然在认真讨论本地部署——大家讨论的其实是激活参数不是总参数。1.3 放进开源 MoE 的坐标系里看拿几个有代表性的开源 MoE 放在一起位置就清楚了模型总参数激活参数参考值典型部署形态Hy4 preview770B未公布估算 60B~190B多卡量化 专家并行DeepSeek-V3671B37B多卡部署已有大量生产案例Qwen3-235B-A22B235B22B单机多卡可玩Mixtral 8x7B47B13B单卡/小显存也能跑从这张表能直观看出 MoE 家族的共同点总参数普遍很大激活参数普遍小一个数量级。Hy4 preview 的意义在于它把开源 MoE 的量级从200B 出头直接推到了 770B。如果稀疏度控制得好效果上限值得期待。当然总参数大和效果好之间还隔着训练数据质量、路由均衡、专家利用率这些变量。最终结论得等技术报告和社区基准测试跑出来才能下现在不宜过度兴奋。2. MoE 架构的推理经济学显存账和算力账为什么是两本账2.1 先说结论MoE 省的是算力不是显存MoE 省显存这个说法我在不同技术群里纠正过很多次但每次还是有人搞混。这里再强调一次MoE 省的是算力不是显存。算力层面每个 token 只经过被路由激活的专家所以 FLOPs 按激活参数计算。前面说了激活参数可能是总参数的 1/10 到 1/4这意味着即便总参数高达 770B单次推理的计算量并没有按 770B 线性增长。这也是 MoE 这几年从自然语言处理一路火到多模态、甚至目标检测领域的原因。YOLO 这类模型都有了自己的 MoE 变体因为模型容量越做越大之后稠密模型的算力增长已经让人扛不住了MoE 提供的是一条容量大、单次计算量小的中间路线。2.2 权重的现实情况所有专家必须常驻摸鱼的也得占座算力是稀疏的参数却是稠密的。这十二个字是理解 MoE 部署的核心请先记住它。为什么权重必须全部加载进显存因为路由是动态的。服务器每收到一个 token路由网络都要现场决定分配给哪些专家。如果你只加载了一部分专家恰好这次路由选中了没加载的那个那就只能等 CPU 或磁盘把权重换进来延迟直接飙到不可用。为了保住低延迟部署时通常要把全部 770B 权重都放进显存或内存。用公司派单的类比延伸一下专家就算没被叫到人也得坐在工位上你照样得为他的工位付租金。所以部署前算显存老老实实按 770B × 精度字节数去算别指望 MoE 帮你省显存。它省的是电费和计算时间不是存储空间。2.3 KV Cache 是第三笔账特别容易被忽略很多人部署 MoE 翻车不是栽在权重显存上而是栽在 KV Cache 上。KV Cache 的大小跟序列长度、并发数、层数直接相关。MoE 模型里的 attention 层是全量共享的每个 token 都要过一遍所以只要并发数上来、上下文变长KV Cache 的增长会非常快。如果你只按权重大小规划显存高并发场景下照样会 OOM。我在部署时习惯按这个顺序控制显存先按权重大小留足空间再用--gpu-memory-utilization把显存利用率压到 0.9 左右最后用--max-num-seqs限制并发。三个参数配合既能保住长上下文的体验又不至于让服务在高峰期死掉。2.4 多卡并行方案TP、PP、EP 分别解决什么问题770B 级别的模型单卡无论如何装不下多卡并行是唯一出路。三个常见方案要分清不然部署文档看了也白看。Tensor ParallelTP把每一层横向切开分到多张卡上并行计算。适合 attention 这类共享层问题是对卡间通信带宽要求极高。Pipeline ParallelPP按层切分前一层算完把中间结果传给后一层。实现简单但流水线排空时会有气泡整体效率略低。Expert ParallelEP把不同的专家分配到不同卡上。这是 MoE 专属方案路由决定某个专家被激活时数据直接传到该专家所在的卡通信压力比 TP 小得多。生产环境通常不会只用一种。共享层走 TP专家层走 EP是一个比较稳健的组合。这也是我在后面的部署命令里同时给出--tensor-parallel-size和--expert-parallel-size的原因。3. 实测部署从零把 Hy4 preview 跑起来的完整记录3.1 先算好你手里的显存够不够按 770B 总参数来算不同精度下的权重占用先摆出来精度权重占用现实配置BF16/FP16约 1540GB20 张 80GB 卡起步一般人不用想INT8约 770GB10 张 80GB 卡或 20 张 40GB 卡INT4AWQ/GPTQ约 385GB5~6 张 80GB 卡勉强单机可玩注意这只是权重。系统还会额外消耗显存给 KV Cache 和中间激活值所以哪怕 INT4 量化8 卡 80GB 也不会觉得宽裕。如果你手头只有 24GB 的消费级显卡我直接劝退硬上的结果只有一个OOM。网上偶尔能看到单卡跑 770B的截图不用羡慕那基本都是 CPU offload 或者极端量化下的结果速度惨不忍睹验证一下模型效果可以想拿来干活基本不现实。3.2 权重获取和文件检查权重一般从 Hugging Face 或 ModelScope 拉国内访问 ModelScope 会更稳定一些。下载完成后不要急着启动服务先做三件事。第一打开 config.json确认总参数量、专家数、路由配置和发布口径一致。我见过有人在网上下了个同名模型跑起来才发现是旧版本白白浪费时间。第二看仓库里有没有现成的 AWQ 或 GPTQ 量化权重有就直接用能省好几个小时。第三确认分词器和对话模板是对的。MoE 模型对模板很敏感用错模板会导致输出格式乱掉。前面写小型 MoE 的部署教程时我就强调过MoE 模型的坑主要集中在路由配置和权重格式上。770B 的体量把所有问题都放大了所以文件检查这一步值得多花十分钟。3.3 vLLM 启动命令和参数选择环境安装不展开pip install vllm transformers accelerate就够了。重点看启动参数。我用的是 8 卡环境模型是 INT4 量化的 AWQ 版本python -m vllm.entrypoints.openai.api_server \ --model /data/models/Hy4-preview-AWQ \ --tensor-parallel-size 8 \ --expert-parallel-size 8 \ --quantization awq \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --enforce-eager \ --max-num-seqs 16几个关键参数逐个说--tensor-parallel-size 8表示 8 卡张量并行共享层按 8 卡切分--expert-parallel-size 8让专家层按 8 卡分布这个参数对 MoE 特别重要能明显减少卡间通信压力--quantization awq指定量化格式--enforce-eager关闭 CUDA graph 预编译遇到算子不兼容的问题时能保命代价是吞吐略降--max-num-seqs 16限制并发请求数防止 KV Cache 把显存吃穿。如果用 SGLang逻辑是一样的python -m sglang.launch_server \ --model-path /data/models/Hy4-preview-AWQ \ --tp 8 \ --ep 8 \ --mem-fraction-static 0.90为什么推 vLLM 和 SGLang 而不是 Ollama因为 Ollama 在 8B、14B 这种小模型上非常好用但对超大 MoE 的多卡并行、专家并行和量化支持不如前两个生产级框架成熟。770B 这个量级老老实实用生产框架别图省事。3.4 起服务后的第一轮验证服务起来之后先不用急着接 UI直接用一个 curl 请求打一发确认链路通不通curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Hy4-preview, messages: [{role: user, content: 用三句话解释什么是 MoE}], max_tokens: 128 }第一轮验收只需要关注三个指标首 token 延迟决定用户体感快不快decode 吞吐决定模型真正干活的效率显存峰值决定这个服务还能扛多少并发。在 8 卡改版 4090-48G 的环境上INT4 量化、32K 上下文设置下我测下来首 token 大约 1 到 2 秒稳定吞吐在每秒 40 到 60 token 之间。这个速度用来做日常对话和 Agent 工具调用体感是够用的。说直白一点它已经比我之前跑过的一些百亿级稠密模型体验更好了MoE 的算力优势在这个环节能明显感知到。3.5 低显存环境的替代方案CPU offload 和专家卸载没有多卡机器也不是完全不能跑但要做好心理建设。vLLM 和 SGLang 都支持把部分参数 offload 到 CPU 内存显存里只保留共享层和当前活跃的专家权重。这样一张 4090 也能把这个 770B 模型跪着跑完但每次路由到没加载的专家都要做一次换入换出首 token 延迟很容易飙到 5 秒以上而且对内存带宽要求很高。我的建议很务实如果你只是想知道 Hy4 的某项能力到底行不行花点钱租云 GPU 按小时计费比在家折腾 offload 划算得多如果你是本地优先的硬核玩家那就接受能跑但不会想天天用的事实把 offload 当最后兜底方案别当主力方案。4. WorkBuddy 限时免费用两周时间到底能干什么4.1 WorkBuddy 不是又一个聊天框聊完模型聊配套的 WorkBuddy。它的核心不是聊天而是执行。结构上可以简单理解为Agent 前端 Skill 插件 自定义指令模板三层。Agent 前端负责接收任务、拆解子任务、决定调用哪个工具Skill 插件提供的是模型单靠文本输出做不到的能力比如读本地文件、调外部 API、执行命令、检索知识库自定义指令模板负责校准模型的行为比如要求它先做资料检索再给结论或者强制它按固定格式输出报告。我在社区里已经看到有人拿它做 2D 转 3D 的草模辅助流程也有人在建筑设计前期用它整理场地资料和规范条文。这些场景的共同点是不是单纯让模型写一段话而是让模型协调多个工具完成一个完整任务。这正是 WorkBuddy 这类 Agent 工作台存在的意义。4.2 和本地部署的 Hy4 接起来是最值的组合免费期最值得做的事是把 WorkBuddy 的模型端点指向你本地用 vLLM 起好的服务。操作上就是在 WorkBuddy 设置里填一个 OpenAI 兼容的 base_url指向http://localhost:8000/v1。这样你就同时拥有了一个 770B MoE 推理后端和一个能调工具、能编排任务的 Agent 前端。实际体验下来我最大的感受是参数量级的差距在普通问答里不容易感知但在 Agent 复杂任务里会被放大。任务步骤越多、需要调用的上下文越杂模型的知识容量优势就越明显。比如让模型分析一份几十页的日志小模型可能只给你一段泛泛的总结大模型会把异常时间点、可能的根因、排查建议分门别类列出来。如果你手里恰好有文档分析、代码审查、报告生成这类复杂任务这个组合值得专门抽出一个小时搭起来试试。4.3 免费期内的实操清单我建议按下面这个顺序把两周时间花完效率会高很多先搭环境、接模型跑通一次完整链路确认 WorkBuddy 能调通本地 Hy4。把你日常工作里最高频的重复性任务写成一条自定义指令比如要求模型把周报按进展/风险/下周计划三部分输出。去 Skill 市场把官方推荐技能装一遍重点看文件操作、API 调用、网页搜索这几类它们的使用频率最高。做一次对照测试同一批任务用默认模板和用你自己的指令模板各跑一次观察输出质量差异。这一步能直观看出自定义指令到底值不值钱。断网环境测试在不开任何云端服务的情况下纯本地模型加本地 Skill 是否够用。这套流程走完两周时间基本可以覆盖能跑、会配、能落地三个阶段。最后一阶段的结果才决定免费期结束之后你是继续付费还是及时止损。4.4 免费不等于不花钱先看清楚规则再上最后提醒一个经常被忽略的坑限时免费和全额免费是两回事。常见的机制有三种第一种是订阅费免了但云端 GPU 时长和 API 调用单独计费第二种是免费额度给得很低试几个任务就触顶第三种是到期默认自动续费忘记取消就在下个周期悄悄扣款。我自己的习惯是任何工具在试用前先去账号设置里找到付费方式能解绑就解绑能关自动续费就关。把到期日设个提醒提前一天决定去留。免费资源确实香但别让免费最后变成一张忘了取消的账单。5. 大家最容易踩的坑三个真实发生的部署事故5.1 量化权重缺失第一步就卡住大模型刚发布时社区通常只有原始 BF16 权重量化版本要等人有时间去跑。如果你动手早很可能遇到仓库里只有 1.5TB 原版权重的尴尬场面。在 8 卡机器上自己跑 AWQ 或 GPTQ 量化动辄好几个小时中途还可能因为显存不足直接 OOM前功尽弃。我的建议是先别急着下载耐心翻一遍模型卡页面确认有没有官方或社区已经放出的量化版本。如果没有现成的可以考虑先跑 CPU offload 来验证效果等量化版本出来了再正式部署。自己动手量化不是不行但那是进阶玩法不是新手入门应该干的事。5.2 多卡通信瓶颈TP8 反而比 TP4 慢这个坑我反复踩过值得单独拿出来说。TP 并行会把张量切分到每一张卡上每次前向传播都要做卡间同步。如果卡间走的是 PCIe 而不是 NVLink通信开销会直接把并行收益吃掉。我实测中遇到过 TP8 的吞吐还不如 TP4 的情况当时还以为是模型加载出问题了后来查了卡间拓扑才找到原因。部署之前务必先跑一条命令检查机器情况nvidia-smi topo -m看卡间是 NVLink 直连还是 PCIe 直连。NVLink 完整互联的机器才能充分发挥 TP 的威力PCIe 直连的机器建议收缩 TP 规模把专家层交给 EP 去分摊通信压力会明显下降。这个检查花不了两分钟但能省下几个小时的调试时间。5.3 任务编排别想一口吃成胖子WorkBuddy 这类 Agent 工具最大的诱惑是什么任务都想自动化。我见过有人第一次用就把之前手动处理的生产流程原封不动搬进 Skill 里结果模型在某个环节理解出现偏差连续执行了半小时的错误操作最后还得人工回滚折腾到半夜。正确做法是把任务拆小。一个 Skill 只做一件事比如下载附件解析表格生成摘要先保证每一个独立环节稳定可靠再把它们组合成多步工作流。别让一个 Skill 同时干五件事调试成本会指数级上升。这条经验不只适用于 WorkBuddy所有 Agent 类工具都是这个道理自动化之前先确认每一步足够小、足够确定。最后再分享一个我自己的小习惯。每次拿到新模型我不会急着看 benchmark 榜单而是先拿手头最难受的三个实际问题去试。能解决真实问题再谈其他。Hy4 preview 和 WorkBuddy 这次组合发布恰好构成了一条完整链路开源模型解决推理能力WorkBuddy 解决任务编排限时免费降低试错成本。如果你也打算上车我的建议是从一个小而具体的任务开始跑通之后再逐步扩大范围。等社区积累更多实测数据我大概率会再写一篇更细的深度报告这次就先到这里。