上午在信息流里刷到 Hy4 preview 发布的消息第一反应是先去翻技术参数和开源许可证结果还没看完群里已经因为 770B MoE 和 WorkBuddy 免费期吵起来了。说实话这两件事放在一起挺有意思一边是七百多亿参数级别的稀疏 MoE 模型开源把“你到底能不能跑起来”的问题直接抛给开发者另一边是办公型智能体工具限时两周免费用把“模型到底能帮你干点啥”的体验门槛打了下来。对普通用户来说后者显然比前者更容易先摸到。这篇我不打算做新闻复读更想站在一个平时既写代码、又带着团队折腾 Agent 落地的人的角度把 Hy4 preview 发布里值得拆的几个技术点、以及 WorkBuddy 免限期的使用策略一起聊聊。适合三类人看正在纠结要不要本地跑 MoE 大模型的技术同学、想给团队引入 AI 工作流的产品或业务负责人、以及单纯想趁两周免费期实际感受一下智能办公工具的路人用户。如果对底座模型不太熟也没关系下面我会先把 770B、MoE、开源这几个概念翻译成人话再进入部署和实操环节。1. Hy4 preview 发布信息拆解770B、MoE、开源三件事要分着看1.1 MoE 不是“更小的大模型”是“更聪明的大公司”很多人一看到 MoE 就默认这模型体积小、跑得快其实这个理解不太准确。MoE 的全称是 Mixture of Experts混合专家。它跟传统 Dense 模型最大的区别在于把一个大而全的神经网络拆成了一堆相对独立的“专家子模块”再由一个路由网络决定每次输入让哪些专家发言。我习惯用公司顾问团来类比。假设你开了一家公司想请一个全能顾问这个顾问懂法律、懂财务、懂技术、懂营销你把所有知识都塞进他一个人脑子里。结果就是这个人脑容量巨大每次咨询都得把整个大脑跑一遍成本极高。Dense 模型就是这种“全能超人”。MoE 的做法是换成 100 个专精顾问有人专攻法律有人专攻财务有人专攻营销。每次来一个问题先由前台秘书判断这个问题该找谁然后只请最相关的两三位顾问进来开会。这样公司装下了 100 个人的知识总量但每次实际支出的咨询费只按两三个人算。所以当你看到“770B MoE”的时候要分清两个概念总参数量 770B意味着这个模型的知识“仓库”非常大但真正参与单次推理的通常只会激活其中一部分参数。很多开源模型的命名会直接体现这一点比如总参数 30B 但激活参数只有 3B、4B 的模型推理成本和显存需求完全不是一个量级。Hy4 preview 具体激活多少参数、路由策略怎么配置要看官方模型卡的详细说明但既然标了 MoE你就不能简单拿“770B 等于 770B Dense”的心态去估算成本。1.2 Preview 版本开源意味着两件事机会和不确定性“Preview”这个词在软件圈很常见但在大模型开源里它有另一层含义模型可能还没到最后稳定发布的阶段能力边界可能还没被完全探明甚至权重本身也可能在后续几个月里继续更新。对团队来说敢在 preview 阶段就开源一个 770B MoE 模型说明他们对技术底座有自信同时也想通过社区反馈来加速迭代。对开发者来说这既是机会也是风险。机会在于你现在就可以拿到权重做私有化部署、做领域微调不需要等官方把所有能力打磨完美风险在于后续版本如果变了你可能需要跟着重新评估模型能力、重新跑评测、重新调 Prompt。我处理这种 preview 模型的态度是可以试但别把生产环境的命脉全押在第一个版本上。先做小流量验证、跑明白业务指标再决定要不要大规模接入。开源还涉及一个经常被忽略的问题协议。并不是所有开源模型都允许你随便商用、随便改、随便再分发。有些开放权重模型会限制月活用户数量或商用场景。所以在看完模型卡之后第一件事是去看 LICENSE 原文确认你的使用场景是否被覆盖。这一条对任何开源模型都适用尤其是“开源企业私有化部署”这个组合提前把授权看清楚比后面法务找上门要省心得多。1.3 “770B 开源”和“770B 人人可用”是两码事这里我必须泼一点冷水。看到开源二字很多人会下意识觉得免费模型来了以后不用再充 API 会员了。但开源模型的价值并不等于免费模型的便利。一个 770B 参数的 MoE哪怕激活参数只有一小部分加载完整权重所需要的显存和计算资源仍然远远超出个人电脑的承受范围。你需要几张显卡、多少内存、什么级别的带宽我下一章会详细算给你看。但先记住结论开源的意义更多在于让有资源的人可以自由部署、二次开发、做成服务没有资源的人其实更适合先用 WorkBuddy 这类工具去感受模型能力好钢用在刀刃上。这也解释了我为什么要把这则新闻拆成“底座模型”和“应用工具”两条线来看底座开源是开发者的事情WorkBuddy 免费是业务用户的机会两条线都值得抓住但姿势不一样。2. 770B MoE 部署门槛拆解显存、推理引擎与框架选型2.1 先算一笔账770B 到底需要多大的显存如果你真的想本地部署一个 770B MoE第一件事不是选推理框架而是看你的显卡够不够“装得下”。很遗憾MoE 模型在推理时不能只把“被激活的专家”加载进显存因为请求是动态路由的你永远不知道下一个 token 会走到哪个专家头上。所以哪怕单次计算量不大全量权重也得老老实实驻留在显存或内存里。先做一道简单的算术题。假设权重用 BF16 格式存储每个参数大约占 2 字节那么 770B 参数的总权重大小是770 × 2 1540GB。单张 80GB 显存的 H100/A100光放权重就需要 20 张左右。再加上推理时的 KV Cache、激活值、临时缓冲区实际占用还要再上浮 10% 到 20%。如果你有条件做量化估值会好看一些。我按常见的量化位宽列了一个粗算表方便你对硬件需求有体感。存储格式每个参数占用量770B 权重预估体积大致需要多少张 80GB 显卡BF16/FP162 字节约 1540 GB20 张以上INT81 字节约 770 GB10 张左右INT4 常见 GPTQ/AWQ约 0.5-0.6 字节约 400-460 GB5-6 张这里只是“把权重塞进显存”的下限估算。如果你还想有足够长的上下文、多路并发那显存还得继续往上加。所以如果你只是手里有一张消费级 24GB 显卡想跑 770B纯属巧妇难为无米之炊但如果你能租到多卡机器或者使用 4bit、8bit 量化版本那还是有机会在 5 到 10 张卡的集群里把它跑起来的。2.2 多卡并行和内存带宽比显存更难解决的问题显存只是第一关。770B MoE 一上多卡第二个坑就是卡间通信和内存带宽。你可能觉得“20 张 80GB 显卡总能跑了吧”实际还要看显卡之间怎么连接。单机多卡如果走的是 NVLink通信延迟和带宽都比较理想如果是多机通过网络连接或者用 PCIe 连接那专家并行的通信开销可能直接把推理速度拖垮。MoE 模型对带宽尤其敏感因为每次生成一个 token都可能触发不同专家之间的数据搬运。路由越分散通信越频繁。这也是为什么很多 MoE 模型在单机多卡环境下的性能表现并没有参数大小看起来那么吓人——瓶颈往往在通信而不在算力。我一般建议先做一次小规模压测观察两个指标首个 token 的延迟TTFT和每次生成 token 的间隔TPOT。如果 TPOT 特别高优先检查卡间带宽利用率而不是盲目调大 batch。2.3 推理引擎选型和启动配置参考跑这类大模型社区主流的推理引擎有几套vLLM 的 PagedAttention 对显存利用优化非常明显吞吐高SGLang 在 MoE 模型上有专门优化长上下文表现不错TensorRT-LLM 适合追求极致性能、愿意花时间做模型编译的团队。具体用哪个最好先看模型发布方有没有给出官方推荐配置没有的话就用你熟悉且社区活跃度高的一套vLLM 通常是比较稳妥的起点。下面是 vLLM 启动 OpenAI 兼容服务的一个通用模板。注意里面的模型路径要替换成你实际下载并转换好的权重目录tensor-parallel-size 要跟显卡数量匹配否则会出现显存不够或者通信配置错误pip install vllm python -m vllm.entrypoints.openai.api_server \ --model /data/models/hy4-770b-moe \ --dtype bfloat16 \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --port 8000如果你拿到的是量化版本--dtype和量化参数要跟着权重格式调整。max-model-len也不是越大越好长度翻一倍KV Cache 占用很可能翻好几倍在不爆显存的前提下量力而行。开始跑之前记得先用几条脏数据测试输入输出是否正常再上正式业务流量。3. WorkBuddy 限时免费两周资源有限别把时间浪费在注册上3.1 WorkBuddy 到底是干嘛的先搞清楚入口再动手先说清楚我这里看到的信息也只是公开预告没有拿到 WorkBuddy 内部完整操作手册。所以下面讲的入口和流程是按目前市面上主流办公 Agent 产品的通用形态来梳理的如果你打开之后发现菜单名称或交互方式不一样以产品内的真实引导为准。从名字和社区讨论看WorkBuddy 摆明了是“办公场景的智能助理/智能体工作台”不是又一个聊天机器人。大家搜得最多的几个词一是 WorkBuddy 怎么用二是 WorkBuddy 业务流程怎么写三是 WorkBuddy 能否写网页、做任务流。这说明它的核心卖点大概率不在“陪聊”而在于把大模型嵌入到工作流里帮你处理文档、表格、PPT、邮件、会议纪要和各类重复性事务。很多人喜欢拿它跟 CodeBuddy 比。我的理解是CodeBuddy 面向的是写代码、调程序、修 bug 的研发场景使用门槛天然较高而 WorkBuddy 更像是给非技术背景的业务人员使用的可以在里面配置一个“整理周报的机器人”或者“把会议纪要自动转成任务清单”的工作流。两者的底层都可能接大模型但面向的对象和使用路径完全不同不能混为一谈。3.2 免费期的正确打开方式先梳理任务再试模型限时两周免费最错误的使用方式就是注册后随便聊两句“帮我写首诗”“介绍一下你自己”然后关掉页面。等下次想起来免费期已经过了一半。真正该做的是拿这段时间做一次完整的业务流程测试。我建议你先花半小时把日常工作里最耗时间、最有规律、又不涉及核心机密的重复性任务列出来。比如整理每日销售数据并生成简报、把客户会议录音转成文字摘要、将项目群的聊天记录提炼成行动项、把周报素材自动排版成 PPT 大纲、批量改写一段常见客服回复。列完之后挑三个最有代表性的场景逐个去 WorkBuddy 里试。从通用经验来看这类工具通常会有几个模块知识库配置把历史文档上传给 AI 学习、技能或 Skill 配置用自然语言或简单表单定义一个业务流程、以及与办公软件/日历/云盘的连接入口。你先试着把一个任务拆成“输入-处理-输出”三段再套到工具里去配置会顺畅很多。举一个例子如果你经常要把会议纪要变成任务清单那工作流大致是这样的。第一步把会议录音或文字稿导入第二步设定规则要求 AI 提取出决策项、负责人和截止时间第三步把输出结果发送到目标群聊或生成表格。在 WorkBuddy 里第二步可能用一个叫“技能”或“自动化规则”的配置来实现你只要把规则描述清楚AI 一般能自动理解并调用合适的模型能力。3.3 两周内值得重点测试的几个能力方向不同的办公角色测试重点应该不同不能只测一个摘要功能就觉得“挺好”。我做了一张简单的角色建议表你可以对照自己的岗位去选测试场景。角色类型建议测试场景重点观察指标行政/运营会议纪要多长文归纳、周报自动生成摘要准确性、格式是否符合要求销售/市场销售数据整理、客户邮件草拟、素材改写数据是否能对齐、语气是否自然产品/项目需求文档摘要、任务拆解、进度同步是否真能形成可执行的行动项研发/技术技术方案初稿、代码审查说明、故障复盘术语是否准确、逻辑是否有明显遗漏我特别提醒一点测试的时候要保留数据样本。也就是说同一个输入你可以用不同 Prompt 多跑几次比较一下哪个描述更适合你的业务。免费期结束之前把这些好用的 Prompt 或配置模板单独存下来。即便后面不付费你也能拿着这套经验去其他 AI 工具里复用这才是免费期最值钱的产出。4. 开源底座 WorkBuddy 应用实操中的通用避坑心得4.1 权重下载与硬盘空间很多人第一步就翻车了如果你决定走本地部署路线第一关不是显存而是存储和网络。770B 权重就算用 4bit 量化下来也有 400GB 左右BF16 版本更是可能超过 1.5TB。很多朋友租了云服务器结果发现系统盘只有 200GB数据盘还没挂载那基本就白折腾了。开始下载之前先确认三件事磁盘剩余空间是否足够、目录是否有写权限、是否有断点续传工具。大文件下载不建议直接用浏览器。浏览器一旦断线可能要从头再来而模型权重文件通常会按 shard 分成多个小块你可以用带断点续传和多线程的下载工具把任务挂起来慢慢跑。下载完成后也别急着解压或加载先核对官方给出的校验值。不要小看这一步模型文件如果中间少了一两个 shard或者被第三方平台改过推理时会出现各种莫名其妙的错误排查起来非常痛苦。另外尽量不要从不明的网盘或第三方分享里拿权重包。开源模型的正确获取路径应该是官方 GitHub 仓库、官方模型站或者信誉良好的学术/商业镜像平台。任何让你先付钱、再私发下载链接的“转存服务”安全性都要打个问号。4.2 模型能装进显存但跑不动先检查这几项配置按照我上面那套估算你凑齐了足够显存模型也加载成功了但首次调用可能慢到让你怀疑人生。这种情况十有八九不是模型本身的问题而是配置或环境问题。我踩过的坑大概有这几类整理成清单供你排查。第一冷启动问题。大型 MoE 模型首次加载权重本来就很慢哪怕加载完成第一次推理也要做 kernel 预热。你要先发几条请求让它“热起来”再做性能判断别拿第一轮的慢当成真实速度。第二共享内存不够。如果你把模型跑在 Docker 容器里容器默认的 /dev/shm 可能只有 64MB数据处理时很容易报错。启动容器时记得加上--shm-size参数比如--shm-size32g能省去很多麻烦。第三API 服务地址和端口不对。vLLM 启动的 OpenAI 兼容服务默认监听 0.0.0.0但有些时候你可能要显式绑定地址否则外部客户端根本连不上。客户端连接时还要看清楚 IP 和端口别把本机调试地址直接放到其他机器上用。第四上下文长度和 batch size 的失衡。很多人为了追求长上下文把 max-model-len 顶得特别高结果稍微来几个并发请求就 OOM。实际使用时要根据你的业务平均长度来设定不是越长越好。4.3 WorkBuddy 使用中常见的几个业务问题说回 WorkBuddy 这类办公 Agent免费期用户最容易遇到的坑反而不是技术问题而是“不知道该怎么描述自己的需求”。很多人会直接输入一句“帮我生成周报”然后抱怨结果太泛。其实工作流工具跟搜索引擎一样输入质量直接决定输出质量。想要更好的结果可以试着给工具提供三样东西当前输入的原始素材比如数据、聊天记录、文档草稿、你想要输出的格式模板比如表格列名、段落结构、语气风格、以及不能出错的关键约束比如“金额单位是万元不要四舍五入省略”。把这些说清楚AI 的生成质量会提升一个台阶。我还要提示一个隐私和数据安全问题。如果你在企业环境里使用第三方办公 Agent尽量不要把客户手机号、合同金额、研发核心代码等敏感信息直接喂给云端大模型。可以先做脱敏处理或者只用那些明确支持私有化部署的版本。免费期只是体验不要把防线也一起免费送了。5. 常见问题排查与避坑速查照着做能少走很多弯路我把从模型部署到 WorkBuddy 使用的常见问题汇总成一张速查表方便你按图索骥。问题现象可能原因优先排查方向模型加载到一半就退出显存不足或磁盘空间不足用nvidia-smi看显存用df -h看磁盘推理速度极慢未预热、卡间通信差、配置不当先多发几次请求预热再测卡间带宽请求报连接失败API 监听地址、端口、防火墙问题确认服务监听 0.0.0.0端口可访问WorkBuddy 生成结果泛泛Prompt 中缺少素材、模板和约束补充业务上下文给出输出格式要求文档导入后 AI 记不住内容知识库未正确切分或索引未生成检查文档格式是否受支持重新索引生成内容包含明显事实错误模型幻觉或上下文超限缩小输入范围关键数据要求模型引用出处免费期结束前还想再体验没有提前梳理核心场景优先把最有价值的业务流程录成模板这张表不可能覆盖所有场景但覆盖了八成新手最先遇到的问题。遇到 bug 不要急着怪模型或工具先按“输入、环境、配置、使用姿势”四层去拆基本都能找到方向。6. 如果你只有两周时间我的取舍建议我不打算在结尾给你灌“AI 改变未来”的鸡汤那没什么营养。我就说一个很实际的取舍如果你是一个人、又没有多卡服务器那就别在这个节骨眼上折腾 770B MoE 的本地部署了时间成本太高。现在的开源模型社区很大但你的时间比显存更贵。先用 WorkBuddy 免费期把业务场景跑明白等确认某个环节真有稳定需求再考虑是租卡部署开源模型还是继续用现成服务。如果你所在的企业有算力资源那就完全值得投入人力去测一版 Hy4 preview 的私有化部署。把它接到现有业务里先跑非核心场景记录下效果、成本和坑两周内基本能得出一个“要不要继续投入”的结论。我个人的习惯是看到新模型发布先用小工具和 API 把能力边界摸清楚等模型进入稳定版本后再决定要不要纳入生产。开源社区的好处就是永远有新鲜东西可以试但真正能落地产生价值的永远是你对业务问题的理解而不是参数数字本身。希望这篇能帮你把信息差补上少走点弯路。