昨晚十一点多久不说话的模型交流群突然被一张发布截图刷了屏Hy4 preview 发布770B MoE 参数开源紧跟着的下一条是 WorkBuddy 限时两周免费。我盯着那几个关键词看了几秒第一反应不是激动而是想把这几个词拆开算账——770B 到底意味着多大的存量和算力需求MoE 模型和 Dense 模型用起来差别在哪里开源的是权重还是完整服务WorkBuddy 这两周免费用到底能用来干什么这些事不搞清楚跟风下载、跟风注册最后多半是吃灰。下面这篇东西就是把公开信息和我在类似模型、类似办公 Agent 工具上的实测经验整理出来给同样正在观望的人做个参考。1. 发布消息背后的三层信息别只盯着 770B 三个数字1.1 Hy4 preview 到底是个什么模型先看名字。Hy4 preview 带了preview后缀意味着这大概率还不是稳定正式版后续可能调整结构、补充能力甚至重写协议。按行业惯例厂商会把一个重要版本先以 preview 形态放出来让社区、开发者和客户提前试错收集反馈后再推正式版。所以第一件要做的事就是现在别急着把它接进核心生产链路先跑通小流量试点。模型本体则是一个非常标准的参数规模叙事770B 总参数、MoE 架构、开源。这三个标签放在一起说明这是一次面向社区的重磅发布。总参数推到 770B 的规模通常不是为了刷榜而是想要在推理成本可控的前提下把模型的知识密度和复杂任务处理能力再往上抬一截。MoE 架构正是这套叙事的核心支撑——如果这是 Dense 模型770B 的激活成本会高到几乎没法日常跑上了 MoE才有机会让这么大的模型变成现实中可用的工具。不过要提醒一句模型叫 Hy4不代表它是第四代什么模型就一定比第三代强三倍。跨代模型之间经常会在某些能力上升、在另一些能力上回调尤其不同 base 模型的训练数据、对齐方式和评测集差异很大。拿到权重或 API 之后最该做的是拿自己的数据去测而不是拿别人的榜单截图去想象。1.2 MoE 的省与费模型文件、激活参数和一次推理的真实成本MoE 全称 Mixture of Experts混合专家模型。这里可以用一个咨询公司的例子来理解如果一家公司接到任何项目都让全员参与这是 Dense 模型所有人出力答案质量高但开销极大如果接到需求后前台先根据项目类型把任务分给少数几个对口专家这就是 MoE 模型一次只激活一小部分专家去做事总员工数很多但单个项目的开销可控。落到模型上MoE 有两个关键数字一个是总参数量 770B指这张大网里所有专家的权重加在一起另一个是激活参数量指一个 token 实际经过的专家参数规模。Hy4 preview 的发布信息只写了总参数量没提激活参数但这恰恰是衡量单次推理成本最重要的数字。已知的几款 MoE 模型里Mixtral 8x7B 总参数约 47B、激活参数约 13BDeepSeek V3 总参数约 671B、激活参数约 37B。如果 Hy4 preview 的激活参数也在 30B 到 50B 这个区间那么单 token 的理论计算量并不是 770B 级别而是几十 B 级别这是它能在推理成本上看起来没那么吓人的根本原因。但这里有个核心误区激活参数少不意味着显存占用小。总参数 770B 决定了模型文件的体积和权重驻留成本因为 MoE 的路由机制无法预先知道下一个 token 会走哪些专家理论上任何一个专家都可能被触发所以部署时通常要把所有权重放进可见的存储里至少也要做成 CPU 内存加按需搬运。换句话说MoE 省的是每次算多少不省模型放哪。1.3 开源不等于免费用服务免费和权重开源是两码事每次看到开源两个字我都会提醒自己先确认三件事开源的是训练代码、模型权重还是整套服务如果开源的是权重用的是宽松许可证还是带有商用限制的许可证官方有没有提供托管 APIAPI 的计费模式是怎样的Hy4 preview 的发布稿明确写了开源WorkBuddy 则是限时两周免费。这两个动作放在一起很容易让用户以为模型免费 工具免费 以后都不花钱但实际是两个独立的商业动作权重开源意味着社区可以自行下载、部署和二次开发前提是遵守模型许可证WorkBuddy 限时免费通常只是产品推广期策略两周后大概率要回到订阅或按量付费。不要因为两周免费就直接把一套自动化流程搭在上面除非你已经做好了到期续费或者迁移的准备。2. 算力约束下的部署选择从显存算术到四条落地路径2.1 先算一笔账不同量化精度下 770B 要占多大空间我见过太多人看到一个开源模型发布转头就问我的 4090 能跑吗。对这种规模的模型这个问题的答案基本是不能。与其让读者到处碰壁不如先把显存算术做一遍。模型权重占用可以用一个简单公式近似占用空间约等于 参数量 × 每个参数的字节数。按这个基数把 770B 模型粗略估算如下精度格式每 10 亿参数占用770B 模型权重总占用说明BF16 / FP16约 2 GB约 1540 GB完整精度约 1.5 TBINT8约 1 GB约 770 GB需要数张 80 GB 显卡才塞得下INT4约 0.5 GB约 385 GB社区量化常用档位即使按最经济的 INT4 量化来算380 GB 多的权重也需要 8 张 80GB 的显卡才能完整驻留而且这只是权重还没算 KV Cache、推理框架的上下文缓冲和运行时开销。所以现实情况是想在本地方便地跑全量 Hy4 preview你需要的是一个 GPU 集群或高端云节点而不是一台个人电脑。把社区会出量化版理解成普通电脑也能玩是开源模型传播中最大的认知偏差。2.2 别被激活参数少误导MoE 在推理时的瓶颈在哪有人会问既然激活参数只有几十 B那是不是可以用很小的显存跑对不起不行。MoE 模型的每一次前向推理都要读取被路由到的专家权重而路由结果是由输入决定的。低并发、单请求的场景下实际读取的可能是其中几个专家但只要权重没有全部驻留在可访问的显存里每次遇到未驻留的专家就要做一次搬运延迟会被拉高到不可接受的程度。更关键的是大模型推理时存在一个显存带宽瓶颈权重要从显存搬到计算单元这个搬运速度往往比计算速度更慢。MoE 模型用稀疏激活省掉了一部分计算量却未必省掉所有带宽开销。这也是为什么 MoE 模型的推理框架适配如此重要——vLLM、SGLang 这类框架对 MoE 的调度、专家并行和量化支持直接决定了模型能不能发挥出理论效率。Hy4 preview 发布后我第一时间会去看官方推荐用什么推理框架、哪个版本开始支持而不是直接拿通用框架硬跑。2.3 不同预算、不同任务我建议的四种落地方式针对不同用户我建议先把落地路径想清楚不要一上来就奔着本地部署全量去。第一种只想体验能力。直接用官方 API 或线上 Demo。这类做法最快成本也最低适合产品经理、内容创作者和想快速评估的人。两周免费期也可以作为 API 评估窗口。第二种有一定开发经验想接进自己的应用。从量化权重加云 GPU 开始跑通后再根据响应速度和成本决定是否长期使用。起步阶段别追求多卡并行先把单节点的吞吐数据测出来。第三种企业内部有数据合规要求不能出内网。这种情况下可以评估私有化部署但前提是先把显存、卡数、机房电力、运维人力这几笔账算清。770B MoE 不是插上 U 盘就能跑的模型。第四种只是想用开源模型做垂直领域小工具。建议等社区出蒸馏版或小参数版本。以开源社区的速度通常很快会出现针对具体场景的精简权重没必要一上来就啃全量。顺带贴一个我在类似 MoE 模型上用 vLLM 启动服务时的常用命令可以当作理解参数量级和显存分配方式的参考# 以 vLLM 服务一个开源 MoE 模型为例参数按实际模型路径修改 python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --quantization awq \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90--gpu-memory-utilization设成 0.90是给 KV Cache 和推理过程留出运行余量如果直接设成 0.99启动时容易在长上下文场景下报显存不足。3. WorkBuddy 两周免费窗口我打算按这套方法验收3.1 它和 CodeBuddy 的分工一个是编程 Agent一个是办公 AgentWorkBuddy 这个名字出来后很快会有人问它和 CodeBuddy 有什么区别。看命名逻辑和同类产品布局就能猜个大概CodeBuddy 面向开发者帮你写代码、查问题、改 bug、补测试WorkBuddy 则更像是把理解任务—拆解步骤—调用工具—交付成果这一套 Agent 能力平移到了办公场景。两者分别承接写程序和做工作两类需求前者的交付物是代码和工程文档后者的交付物是表格、方案、网页、汇报素材之类的业务结果。用一个不那么严谨但好记的说法是CodeBuddy 帮程序员把代码写完WorkBuddy 帮业务人员把活干完。如果一家公司既有人在写代码又有一堆人在做重复性文档和数据处理这两个工具其实可以形成一个互补组合。我自己的判断是先别急着论谁取代谁真正要测的是 WorkBuddy 能不能稳定完成真实办公任务而不是它演示视频里那种精心设计过的单步操作。3.2 一份可以直接抄的验收清单两周时间听起来不短如果只是开个网页聊几句根本测不出一个办公 Agent 的真实水平。我建议把这两周当做一个正式项目来做按下面的清单逐项验收第一天准备一份脱敏的真实业务材料让 WorkBuddy 生成周报、总结或通知同一条任务跑三次记录输出是否一致判断稳定性。第二天测试它的文件处理能力比如从一堆散乱的表格里提取关键指标再让模型生成一张汇总表重点看数字对不对、格式能不能直接用。第三天测试它对复杂指令的拆解能力把一份包含多个环节需求的自然语言描述丢进去看它是先把步骤问清楚还是自作主张直接开始执行。第四天尝试自定义技能或工作流。如果产品支持 skill 配置就建立一个自己业务场景的技能模板把提示词、输入格式、验收规则固化下来看落地后的效果是否比每次口头描述更好。第五天对输出做交叉验证。让 WorkBuddy 给出结论时附上原始依据或者手动抽查几个关键数据。Agent 工具最怕的不是不会做而是很自信地做得不对。这套清单的核心思路不是测它能做什么而是测它在真实业务里可以用到什么程度。演示视频里的亮点任务通常经过了多轮打磨只有自己复跑过才知道平均水平。3.3 当心短视频包装出来的非官方玩法WorkBuddy 上了热搜之后网上出现了不少XX大学清单一键生成全套材料之类的说法。我在检索相关信息时留意到有短视频把它包装成大学清单类工具但这并不是官方应用的能力描述。对于这类说法我一向劝大家冷静凡是把某个工具包装成按一个按钮就能搞定人生大事的基本都要打一个问号。效率工具能帮你把已有材料的整理、重排、汇总做得更快但替代不了你自己的判断和原始信息的真实性。另外说到 WorkBuddy 就绕不开本地部署这个话题。很多团队想本地部署是担心办公数据传到云端不可控。这个诉求合理但本地部署一个办公 Agent 不只是装个软件那么简单——你需要考虑模型权重从哪来、知识库索引怎么建、执行任务时调用的工具链怎么隔离、权限和审计怎么设计。如果只是出于好奇建议先用官方免费渠道把能力边界搞清楚再评估是否值得投入本地化改造。下载任何第三方打包的安装包之前务必确认来源避免给数据和系统引入风险。4. 实测中的高频翻车点与排查思路4.1 模型服务这边显存、量化与上下文窗口拿这类大模型做实测我有一套固定动作先找二十条自己业务里的真实问题跑一遍输入输出再量三点——响应速度、长上下文稳定性、格式遵循度。不要一上来就聊AI 新模型好厉害把这三组数据拿到手判断比任何宣传文案都可靠。部署时最容易出问题的是显存。我见过不少人在服务器上用nvidia-smi一看没占满就以为显存够结果服务一到长对话就 OOM。原因通常是 KV Cache 是动态增长的上下文越长KV Cache 占用越大。排查链路一般是先看nvidia-smi确认有没有其他进程占显存再逐步降低--max-model-len还不行就换 INT4 量化最后才考虑增加显卡数量。不要一上来就买新卡很多时候是配置问题而不是容量问题。量化是另一个高频坑。AWQ、GPTQ、GGUF 这些方案各有适配场景并不是随便压个 INT4 就万事大吉。量化的校准数据如果跟实际业务分布差异太大模型在一些关键任务上会明显变笨。如果某个任务在量化后质量突变先回到 BF16 或 FP8 档位复测一次确认差异到底是量化损失还是模型本身能力不足再决定要不要为了省显存牺牲效果。4.2 Agent 工具这边方向跑偏、数字出错和任务中断WorkBuddy 这类办公 Agent 翻车的方式通常不是不会干活而是看起来在干活但实际上方向偏了。我试用任何 Agent 工具遇到的第一类问题几乎都是同一个任务描述不够具体时它会自己脑补出一个目标。比如你跟它说整理一下这个项目的资料它可能默认按时间线排也可能默认按优先级排而真实需求往往只存在于你的脑子里。后来我养成了一个习惯给 Agent 的任务指令里必须包含输入是什么、输出是什么、格式是什么、验收标准是什么四要素就像给实习生布置任务一样不写清楚就别怪执行偏。第二类问题是数字出错。模型生成的中文文本很流畅但一旦涉及计算、统计和数据引用就可能出现格式完美但数字对不上的情况。办公 Agent 往往会调用外部工具去读文件、算表格这比纯文本生成可靠但仍然要留一个人工抽查环节。我的经验是凡是影响决策的关键数字必须能回溯到原始文件的具体单元格或段落。做不到这一点的 Agent 输出只能当草稿不能当结论。第三类问题是长任务中断。一个需要跑十几分钟、涉及多文件读取和多步骤生成的任务经常会在中间某一步卡住。遇到这种情况别急着骂产品先看日志卡在哪一步是文件格式不支持还是外部服务超时还是权限不够。把这三种情况分开排查通常能解决一大半。我的原则是复杂任务拆成小任务小任务拆成单步操作中间加入进度检查点。Agent 工具本质上还是一个执行者它需要你给它铺好路。4.3 一套通用的验收流程这些坑踩多了我慢慢总结出一套通用验收流程现在分享出来供各位参考。第一步先复制一份脱敏的测试数据绝不在正式环境里跑第一个实验。第二步把同一个任务连续跑三遍记录成功率、输出质量和耗时不要用一次成功就下结论。第三步对关键输出做人工核对尤其是数字、人名、日期、金额这些容易被模型编造的内容。第四步把每一次成功和失败的过程截图存档两周免费期结束时这份记录就是你决定要不要付费续用、要不要做私有化部署的最有力依据。这套流程不挑具体产品Hy4 preview 的 API 评测可以用WorkBuddy 的免费试用也可以用。凡是吃不准的工具都先拿一周时间做最小化验证别在第一天就做大迁移。5. 两周以后怎么决策我给自己定的标准5.1 三条提问替代别人说好我就用免费期结束后要不要付费要不要把 WorkBuddy 推广到团队Hy4 preview 要不要接入业务这些问题没有一个标准答案但可以用三个提问来过滤。第一问这个工具能不能稳定复现我真实业务中 80% 以上的高频任务70% 以下只能当一个玩具不值得团队推广。第二问数据流是不是我能接受的办公文档、内部数据都传到了外部服务这个代价不是免费的只是藏在隐私条款里。第三问免费期结束后的总成本我算过没有续费价格、调用量、私有化部署的硬件和运维人力每一项都要有数字。三个问题都能给出让自己信服的答案再掏钱也不迟。5.2 免费期结束前我会做什么我给自己定的计划很简单两周时间只测真实任务不做演示任务。把 WorkBuddy 用在三件实际要交付的事上比如月度材料汇总、跨部门信息整理和个人知识库初建把 Hy4 preview 的 API 或开源版本用在一个具体的小应用上比如让模型从我自己的文档里抽取结构化字段。两周后翻一遍自己记录的实测日志数字会告诉我答案。我不打算在发布第一周就去找机器跑 770B 全量。先看社区的实测报告关注三个指标激活参数是多少、官方推荐推理框架什么时候适配、社区量化权重出来后实际效果打几折。这些信息通常发布后一个月内就会出来等一个月再动手不是错过窗口是避开风险。5.3 给团队负责人的一句实在话最后给那些正准备把开源模型和办公 Agent 推给团队的人一句实在话大模型发布是一个事件工具落地是一个项目。Hy4 preview 再强770B 不会自动变成你团队的生产力WorkBuddy 再方便两周免费也只是一个试用期。真正决定要不要用的是你愿不愿意花时间做验收、跑真实任务、算成本账。所有好的工具都是这么筛出来的而不是从热搜里捡出来的。