这一周 AI 社区的牌桌上Hy4 preview 算是一张久违的大牌。770B 参数、MoE 架构、直接开源旁边还挂着一个限时免费的 WorkBuddy这几个关键词凑在一起很难不让人多刷两遍。尤其是对跑过开源大模型的人来说“770B 总参数”这六个字含金量和分量一样重。这篇文章不打算替官方念新闻稿我想从一名做模型落地和 Agent 应用的开发者的角度聊聊 Hy4 这次发布到底动了什么格局、WorkBuddy 值不值得马上上手以及“想要真正用起来”需要跨过哪些门槛。1. 770B 总参数、几十 B 激活参数Hy4 的 MoE 架构到底意味着什么1.1 先拆开 MoE 这几个字母MoE 全称 Mixture of Experts翻译过来是“混合专家”。很多人第一次听到这个词以为就是“把好几个模型缝在一起”这个理解不能算错但至少是不完整的。更准确的描述是一个模型内部装了几十个甚至上百个相对独立的“专家”每次处理 token 的时候由一个路由网络去判断“这个问题该请哪几位专家出来干活”。拿一个生活里的例子类比。一家公司有法务、财务、技术、市场四个部门但并不是每件事都要把四个部门的人全叫来开会。报销走财务合同走法务遇到跨部门项目才拉上技术和市场。MoE 里的路由机制就是那个“叫人的项目经理”它按 token 分派任务只激活少数专家其余专家保持休息状态。关键就在“少数”两个字上。传统的稠密模型 Dense好比公司全员大会无论问题多简单所有参数都得参与计算。而 MoE 模型总参数虽然大真正参与计算的部分却小得多。社区里有个搜索热词是“gemma4 26b a4b moe”这类写法描述的就是这种结构26B 是总参数4B 是激活参数也就是说单次推理真正消耗计算资源的只有 4B。回到 Hy4 这边770B 是总量具体激活多少要看官方技术报告里的专家数和 Top-K 策略但按目前开源 MoE 产品的通行设计比如常见的 64 专家选 8 个激活参数应该落在几十 B 这个档位。这也是为什么“770B”这个数字听起来吓人但社区反馈的共识是“这个规模在还未被账面数字劝退之前先别急着退”。它和同参数量的稠密模型完全是两种生物。1.2 总参数和激活参数把算这笔账当成基本功做模型部署的人心里必须常年挂着两个数字总参数和激活参数。前者决定你“需要多少显存”后者决定“推理有多快”。大多数人以为模型越大越慢在 MoE 上这个直觉是错的。推理速度取决于激活参数。因为每次 token 进来只有被路由选中的专家真正做了矩阵乘法专家间的计算可以并行单个 token 的计算量约等于“共享层 激活专家”的量级。也就是说Hy4 如果激活参数在 30B 到 60B 之间即使总参数高达 770B单 token 推理的理论计算量也远低于一个 200B 的稠密模型。但显存就没有这么幸运了。推理时权重必须全部加载到显存里所有专家一个都不能少因为路由随时可能点到任何一个专家。这意味着只看推理时延Hy4 可能并不比某些小模型慢多少一看显存需求770B 的体量就原形毕露了。后面第 4 章我会专门算这笔账。对开发者来说理解总参数和激活参数的区别直接决定了你会不会犯“显存规划错误”。我见过太多人看到 770B 直接放弃也见过另一批人以为 MoE 省显存兴冲冲买了 4 张 80G 显卡回来发现根本装不下。这两种误判本质上都是没把总参数和激活参数分开算。1.3 从“hy4 2d转3d”热搜看模型的形态变化这次热搜词里有一个很有意思的词条“hy4 2d转3d”。一个看起来是纯语言大模型的发布怎么和一个视觉生成任务挂上钩了从行业趋势推断Hy4 应该不是单纯的文本模型大概率带有多模态能力或者是围绕它的生态里已经有视觉生成相关的组件。2D 转 3D 这种任务成长的背景是空间智能和具身智能的兴起大模型不再只吞文字和代码也开始吞图像、点云和 3D 表情。MoE 架构在这种场景下的优势尤其明显视觉 token 和文本 token 的分布差异很大用路由机制可以训练出“偏科”的专家有的专家擅长处理视觉特征有的专家擅长推代码逻辑路由自动分流。不过这里多说一句2D 转 3D 目前更多是应用层的能力判读它考验的是模型的几何理解、跨模态对齐和生成稳定性不是单靠参数规模就能解决的事情。Hy4 在这块的实际表现要等更多人跑完实测才有结论。我的建议是看到“2D 转 3D”这个词别急着脑补太多产品形态先把它当作“模型具备跨模态潜力”的信号具体能不能打跑业务场景才知道。2. 开源不是一句口号从模型权重到生态落地Hy4 动的是哪块蛋糕2.1 开源的门槛已经从“有没有”变成“跑不跑得动”如果说两年前开源模型的问题是“公开的权重太少、选择太少”那现在的问题已经变成“权重多得下不完但真正跑得起、调得动、用得好的是少数”。Hy4 宣布开源第一批受益者的画像其实很清晰有 GPU 资源的研究机构、有私有化部署需求的企业、以及愿意折腾的独立开发者。开源的第一步是拿到权重但从搜索引擎里这些密集的“部署教程”“安装教程”“本地部署”热搜词能看出来普通用户最大的痛点不是“去哪下载”而是“下完怎么用”。开源模型的学习成本正在从获取端转移到工程端。一个模型发布后社区能不能快速提供部署脚本、量化版本、前后端封装直接决定这个模型是“躺在 Hugging Face 上的文件”还是“跑在业务里的引擎”。所以我看 Hy4 的开源不只看那份权重更看它配套的工具链和社区接不接得住。开源从来不是把文件丢出来就算完事而是要有一批人愿意替它做镜像、做量化、做文档、做问答。这也是为什么“开源实现”“开源项目”能成为热搜常客——大家真正在找的是能直接抄作业的落地路径。2.2 拿到权重之后普通开发者应该先做的三件事如果你已经准备好了机器拿到 Hy4 权重后的第一步我建议按下面这个顺序推进不要跳过。第一件事跑通推理。用官方推荐的推理框架起一个最小的推理服务传一句话进去确认输出正常。这一步通常最耗时的是依赖安装和模型下载卡住也不要慌大部分问题都是版本不匹配先检查 CUDA、PyTorch 和框架版本。跑通后记录一下“单请求首 token 时延”和“吞吐量”这是后面所有评测的基线。第二件事跑评测。不是让你一个榜单一个榜单过先跑和你业务最相关的那几项就够了。工具上可以直接用 lm-evaluation-harness 或者 OpenCompass把代码生成、数学推理、中文理解这几个维度各跑一组。评测数据会比“聊几句看感觉”可靠得多尤其是你要向团队汇报“值不值得接入”的时候没有评测数据的结论不具备说服力。第三件事做适配。如果你的业务需要私有化部署马上试量化如果需要模型按照特定格式输出先写约束 prompt 测稳定性如果接 Agent 流程重点测 function calling 和指令遵循。早发现问题比晚发现问题强十倍因为开源模型前期暴露出来的短板通常能通过工程手段弥补越晚发现返工成本越高。2.3 开源模型的“配套基建”比想象中更值钱这次热搜词里出现了“清华大学开源软件镜像站”“阿里巴巴开源镜像”“gitee开源许可证选什么”“开源文档贡献”这些词条。看着零散其实它们拼出了开源模型落地的完整拼图镜像站解决下载问题许可证解决合规问题文档贡献解决可持续问题。先说说许可证。开源不等于免费商用这句话已经老生常谈但每次新模型发布总有人忽略。Gitee 上创建开源项目时要选许可证不同的许可证对商用、修改、署名、开放源码的要求完全不同。如果你打算基于 Hy4 做商业产品发布前一定要确认它的开源协议是否允许商用、是否要求衍生作品也开源。写进法务流程比事后补救稳妥得多。再说说文档贡献。很多抱怨“开源项目看不懂”的人没意识到自己也可以成为文档的贡献者。你安装时踩过的每一个坑补进 README 或者 wiki就能帮后面一百个人省时间。开源生态发育得越成熟文档质量就越重要它不亚于模型权重本身。3. WorkBuddy 不是聊天框Skill 插件化的 Agent 工作台怎么用3.1 WorkBuddy 到底解决什么问题围绕 WorkBuddy 的热搜词密度高得惊人“workbuddy教程”“workbuddy本地部署”“workbuddy插件”“workbuddy自定义指令推荐”“workbuddy从入门到精通”。一个刚发布没多久的工具能在社区里引发这种规模的搜索说明它的定位戳中了不少人的需求。从产品形态推断WorkBuddy 应该不是一个简单的对话应用而是一个 Agent 工作台——它把“模型调用”“工具编排”“技能沉淀”整合在一起。再加上热搜里那个“workbuddy codebuddy”的词条合理猜测 WorkBuddy 和 CodeBuddy 属于同一生态或者互补关系一个人如果既写代码又做通用任务CodeBuddy 管工程侧WorkBuddy 管工作流侧两边打通后能省掉大量上下文切换的成本。我对这类 Agent 工作台的理解是它的核心价值不是“多一个地方聊天”而是“把重复的工作变成可复用的流程”。你不需要每次从头写 prompt把套路固化成 Skill下次一句话就能调用整套流程。这才是它值得花时间研究的点。3.2 装好之后的第一步不是问问题而是建环境搜索“workbuddy安装教程”“workbuddy安装”的人这么多我猜大多数人在安装阶段就卡住了因为 Agent 工作台通常不是一个纯客户端软件它的安装链路里至少包含三块应用本体、模型接入、插件目录。我按通用的 Agent 工作台部署逻辑给你排一个大概率适用的安装检查清单环境预检确认系统里 Python 或 Node 版本符合要求Docker 如果有需要先装好。很多安装失败都是因为这一步没做好后面报错看都看不懂。拉取安装包从官方渠道下载 WorkBuddy建议优先选稳定发行版不要一上来就尝鲜 nightly 版本。配置模型接入这是最关键的一步。WorkBuddy 如果支持本地模型你要填本地的推理服务地址如果走云端 API就填 Key。两者选哪种取决于你对数据隐私的要求和预算。检查插件目录确认插件能被正确扫描到否则后面装 Skill 会一直不生效。启动并用最小用例验证让它执行一个“把下面文本总结成三点”的简单任务走通全链路再继续深入。这五步走完你才算真正“装上”了 WorkBuddy而不是把图标拖进应用程序文件夹。3.3 Skill 机制把重复工作变成一句话WorkBuddy 这类工具最值得花时间经营的部分是它的 Skill技能机制有些产品也叫自定义指令或工作流模板。它本质上是“一段结构化 prompt 若干工具调用规则”的封装你定义一次以后随手就能复用。拿一个最常用的场景举例会议纪要整理。你可以在 WorkBuddy 里新建一个 Skill输入“整理会议纪要”的触发条件并约定输出格式——会议要求、时间节点、负责人、风险项。之后每次开会把原始录音转文字丢给它一句话就能产出规范纪要而不是每次重新把格式要求粘贴一遍。热搜里还有个有意思的词条“workbuddy大学清单”。据说是一位用户分享的、非官方的自制模板合集把大学期间要办的琐事整理成了清单模板。这类现象恰恰说明了 Skill 机制的生态潜力用户自制的模板比官方文档更容易传播。如果你用 WorkBuddy 做的是某个垂直行业的事完全可以去搜一搜别人分享的模板再改成适合自己的版本。我的实操建议是不要一开始就追求复杂的自动化流程。先用一周时间记录你每天都在重复做哪些事挑出一件最烦、最机械的事把它做成一个 Skill。等你对机制熟练了再去叠加多工具编排、条件分支这些高级玩法。4. 本地跑 Hy4 的真实成本显存估算、量化选型与推理框架取舍4.1 先算账770B 模型本地部署到底需要什么硬件这是我觉得整篇最该认真看的部分。很多人被“770B”吓退也有人低估它的显存需求我要把账算清楚。大模型权重的显存占用公式很简单权重显存 参数数量 × 每个参数占用的字节数。不同精度下770B 参数的量级是这样精度每参数字节770B 权重显存估算实际部署参考BF16 / FP162 字节约 1540 GB1.5 TB8 卡 H100 80G 也远远不够FP81 字节约 770 GB10 卡 80G 勉强8 卡需配合 offloadINT81 字节约 770 GB同上INT4 / AWQ / GPTQ约 0.5 字节约 385 至 450 GB5 到 6 卡 80G 可以放下注意这只是权重的静态占用。运行时还必须考虑 KV Cache、中间激活值、临时张量这些都会额外吃显存。长上下文场景下 KV Cache 的增长尤其凶猛。所以即便 INT4 量化后理论权重只要 400GB 左右实际部署时留出 20% 到 30% 的余量才算安全。结论很直接Hy4 本地部署的底线是单机多卡个人单卡基本不用想。对于绝大多数团队最现实的路径是云上租 GPU 实例而不是自购硬件。在决策之前先用公式估算清楚避免买错配置。4.2 量化怎么选FP8 起步还是直接 INT4量化方案的选择本质上是在显存、推理速度和输出质量之间做三角取舍。方案适合场景优点注意事项FP8显存相对充裕多卡服务器精度损失小部署简单需要较新显卡支持INT8显存中等精度损失可控市面支持度略低于 FP8INT4AWQ/GPTQ显存紧张追求单机多卡跑起来显存压到最低质量有损某些任务影响明显我的建议是分两步走。第一步先用 FP8 跑通完整链路确认模型的真实能力。FP8 是目前工程支持最成熟、踩坑最少的高压缩方案很多推理框架对它做了优化。如果你的硬件不支持 FP8再退到 INT8。第二步是如果显存实在紧张再上 INT4但要特别留意 MoE 模型在低比特量化下的不稳定表现。这里有个 MoE 特有的坑不同专家对量化的敏感度不一样。有的专家处理简单 token量化后几乎无感有的专家专门处理复杂推理压缩后掉点非常明显。所以对 MoE 模型做 INT4 量化不能只看整体的困惑度指标最好分任务测一遍代码生成、数学推理、长文本理解看具体哪个方向损伤最大。实测中常见的情况是整体指标掉了一点但某个细分场景崩得没法用这种问题在评测阶段就要抓住。4.3 推理框架vLLM 与 SGLang 的取舍权重到位、量化定好之后选推理框架是最后一道坎。目前开源社区对 MoE 支持最成熟的集中在 vLLM 和 SGLang 两个框架。vLLM 的优势是生态成熟连续批处理对吞吐量的提升非常明显适合并发请求多的线上服务。它在多卡并行上支持张量并行TP和流水线并行PP部署 770B 这种规模的模型基本必须上多卡并行所以并行策略的配置要认真对待。SGLang 的优势在于 RadixAttention 等调度优化在“多轮对话”“前缀复用”这类场景下有更高效率。如果你做的产品是大量的 Agent 会话上下文里共享系统提示词和技能定义SGLang 的优化可能更贴合你的实际负载。不管选哪个框架我都有几点经验提醒第一优先用官方建议的版本和参数。大模型推理框架迭代极快新模型的兼容性往往依赖某些特定 commit自己乱升级版本很容易跑出诡异结果。第二高度关注 MoE 的负载均衡。专家的热门程度不同路由可能让少数专家过载导致显存和算力分配不均。框架一般会提供负载均衡相关的配置和监控日志部署完先跑一批真实请求看看路由器分布再做针对性调整。第三动态体验和吞吐指标要分开看。我实测过一些 MoE 模型高并发下整体吞吐很漂亮但单个请求的延迟波动比稠密模型大。原因是不同 token 命中的专家组合不同有的请求撞上热门专家排队时间就长。如果你的产品对单请求时延敏感压测时要特意盯 P95 延迟不要被平均吞吐蒙蔽。5. 两周免费窗口期可以专注做的几件事5.1 免费不等于随便用先明确你要带走什么Hy4 发布叠加 WorkBuddy 限时两周免费这是一段非常典型的评估窗口期。我个人最反对的做法是因为免费就这测一下那点一下两周过去什么结论都没沉淀下来。免费额度的价值不在于“白嫖”而在于用最短时间验证它对你是否真的有用。动手之前先列一张“想要带走的东西”清单。对开发者来说至少包括三类Hy4 在真实业务任务上的评测分数、WorkBuddy 在团队工作流里的匹配度、整套部署方案的踩坑记录和性能基线。等到免费期结束时你手里应该有一份可复用的结论而不是一堆零散的试用印象。5.2 一套我沿用了很久的模型试用路线我评估一个新模型通常分成三层递进窗口期里照这个走效率会高很多。第一层能力摸底。用同一组测试题覆盖代码生成、逻辑推理、数学、长文本理解、中文表达这几个维度每个维度 5 到 10 个用例。这套题必须是固定的否则你没法横向对比不同模型。不用追求用什么权威榜单你的业务场景就是你的榜单。第二层场景复现。拿一个你做过的真实业务 case原封不动地丢给模型看它在你最关心的任务上表现如何。这里的关键词是“原封不动”不要为了让它表现更好而临时改 prompt你要测的是它在你现有工作流里的真实水平。如果结果不理想再去尝试优化 prompt 和参数把“优化后的结果”和“开箱即用的结果”分开记录。第三层Agent 链路验证。如果你打算把模型接进 Agent 工作台还要专门测工具调用能力给它一个需要多步工具调用的任务比如“查询并整理本周天气再根据天气推荐通勤方式”观察它在工具选择、参数填充、错误恢复这三个环节的表现。很多模型单看问答很聪明一进 Agent 链路就露馅这个测试不能省。5.3 把试用结果沉淀成团队的评估清单如果你的团队不止你一个人我建议在免费期内把评估结果整理成一张共享表格长期有用。表格里至少要有这几列评估维度测试用例通过标准实测结论备注代码生成5 个真实业务函数可直接运行率 ≥ 80%待测关注边界条件处理数学推理10 道题准确率 ≥ 70%待测对比量化前后差异Agent 工具调用3 条完整链路成功率 ≥ 60%待测记录错误恢复表现部署成本量化 多卡时延符合预算与 SLA待测记录峰值显存填完这张表你对 Hy4 和 WorkBuddy 到底是“值得深度集成”还是“持续观望”心里就有数了。评估结论要落到“是否进入下一阶段”这个决策上否则表格填了也是白填。最后再分享一个我多年总结的习惯任何新工具免费期结束前一定要把你踩过的所有坑和对应的解决方案写下来存到团队知识库里。这次记录可能看着没什么但三个月后你团队里新同事入职这份文档能帮他省下至少两天的摸索时间。开源模型和 Agent 工具的节奏越来越快真正拉开差距的往往就是谁先把新东西搞明白、沉淀下来。