这几天 AI 圈子又炸了一次：Hy4 preview 正式发布，直接拥抱 770B MoE 大模型的开源路线，同时配套的 WorkBuddy 工具宣布限时两周免费用。很多人私信问我怎么看，我的第一反应是，这一次的开源内容可能不是让你在普通电脑上跑的，而是给真正有卡的团队准备的正经生产级模型。
作为长期在大模型应用落地一线折腾的人，我不打算只转述发布消息，而是结合实际操作经验把这事情拆开聊：770B MoE 到底什么概念、开源了意味着什么、WorkBuddy 到底能干什么、值不值得这两周去试用。如果你正在规划大模型私有化部署，或者在选一个 Agent 工作流工具，这篇的内容会比较对你的胃口。
1. 先理解 770B MoE：这次发的是什么
1.1 MoE 架构：用更少的算力跑更大的模型
MoE，全称 Mixture of Experts，也就是混合专家架构。它不是这两年才出现的新概念，但直到 DeepSeek、Llama 4 这一批模型把开源 MoE 的体验拉上来之后，大家才真正意识到：它是超大模型落地最现实的路线，没有之一。
传统 Dense 模型最大的问题在于“一视同仁”。不管用户输入的是“你好”还是五千字的长文，每一层、每一个参数都要参与计算。你可以把它想象成一家公司里所有员工处理每一份合同，人多力量大没错，但大量人力都消耗在跟自身无关的环节上。而 MoE 模型则像一家公司养了几百个专业团队，前台拿到任务后，只把相关的三五个团队叫进场，其他团队继续休息。最后输出的是“整个公司”的集体水平，但单次任务的实际耗时就少了一个量级。
标题里的 770B，指的就是总参数量大约 7700 亿。这个体量下，模型采用的必然是 MoE 架构，而且通常会设计很高的稀疏度：总参数听上去吓人，实际每个 token 真正激活的参数量可能只有总参数的十分之一，甚至二十分之一。参考最近开源圈子里的 MoE 模型，常见做法是总参数拉满、激活参数控制在十几 B 到几十 B。这样单个 token 的推理计算量才能被压到几台 GPU 能承受的范围里，否则光是权重同步就是一场灾难。
1.2 硬件账：想本地跑全精度要准备什么
很多人一听到“开源”就开始兴奋，以为下载权重就能在自己电脑上跑。这事我得先泼一盆冷水：770B 总参数的开源模型，绝不是消费级显卡能碰的东西。
模型显存需求可以近似用“总参数量 × 每个参数占用的字节数”来估算，再加上 KV Cache 和推理过程中的临时激活。我们先把权重的账算一下：
- BF16 半精度，每个参数 2 字节：770B × 2 = 1540GB，至少需要 20 张 80GB 显存的 A100/H800 才能把权重放进去，这还没算运行时的额外开销。
- FP8 或 INT8，每个参数 1 字节：770GB，大约需要 10 张 80GB 卡。
- INT4 或 4-bit 量化，每个参数 0.5 字节：385GB 左右，也要 5 张 80GB 级别显卡才有希望跑起来。
而且，这只是权重加载的基础量。推理时 KV Cache 会随着并发和上下文长度快速增长，最长上下文如果拉到几十 K，KV Cache 吃掉的内存可能比一个中型 Dense 模型还多。
所以结论很直接：如果你手上没有至少 4 卡 80GB 显存的集群，建议不要指望全量部署这件事。个人开发者老老实实走官方 API 或云厂商的托管服务，比自建硬件划算得多，也省心得多。
1.3 开源的是什么：权重、代码，还是训练全链路？
还有一个需要区分的地方：很多项目嘴上说“开源”，可能只是开源了权重和推理代码，而不是把训练数据、训练代码、实验日志全部公开。企业拿来商用私有化，只要开源协议允许，权重开源就足够用了；但如果想从零复现训练过程，基本不现实。
所以“770B MoE 开源”这句话真正的价值在于三件事：
- 可以在自己机房或云环境里私有化部署，业务数据不出域，这对金融、医疗、法律这些对数据合规要求极高的行业是刚需。
- 可以在开源权重之上做 SFT 微调、偏好对齐、领域适配，而不是在封闭 API 的框子里打转。
- 可以基于模型做二次开发，把它接进自己的工具链、Agent 体系里，不必担心哪天供应商突然改接口、涨价格。
这里也顺便聊聊开源协议。商用需求明确的情况下，优先选 Apache 2.0、MIT 这类宽松协议；如果是个人学习或非商用，什么协议都无所谓。像这种超大模型开源，一般还会配套发布技术报告，建议拿到模型后先花半小时读一下，再决定要不要投入资源部署，比你盲目刷卡有用得多。
2. 部署落地：770B MoE 在真实环境里怎么跑起来
2.1 第一步：明确场景，再决定量化档位
部署这种规模的模型，第一步不是装环境，也不是改什么参数，而是先明确你到底要拿它干什么。
如果你是个人开发者，想跑通一个 Demo，或者做 Agent 应用开发，我的建议是不要自己部署全量，直接用官方 API 把业务先跑通。等接口调通了、业务验证完了，再评估是否有必要自己上卡。如果你是一个小团队，需要做技术验证和 PoC，可以租用云上多卡实例，用量化版本跑，成本和效果之间能找到一个平衡点。只有真正数据隐私要求高、需要完全私有化的企业，才值得在这件事上投重金建集群。
量化档位的选择也是个老生常谈但必须讲清楚的话题：
第一档：BF16 全精度。效果最接近原始权重，但对显存要求最苛刻，只适合 A100/H100 集群。第二档：FP8 或 INT8。大多数场景效果损失可以接受，是目前性价比最高的折中方案。第三档：4-bit 量化（AWQ/GPTQ 这类）。能大幅省显存，但某些算子和量化策略不兼容，部署前必须做一轮基准测试。
我的实际操作习惯是，先在 Transformers 里加载模型做一轮快速校验，确认权重没有问题后，马上切到 vLLM 这类推理框架。原因是 Transformers 的吞吐太低，生产环境根本撑不住，vLLM 的连续批处理和 PagedAttention 能把资源利用率拉高不少。
2.2 用 vLLM 起一个 OpenAI 兼容服务
这是篇实践导向的文章，必须给一个可以直接上手的启动思路。假设推理框架已经支持该模型，最简的方式是用 vLLM 提供 OpenAI 兼容的接口，这样下游应用、WorkBuddy 这类工具都能通过base_url直接指向本地服务，业务代码一行都不用改。
参考命令如下，注意模型名和版本号以官方仓库为准，这里只演示用法：
pip install vllm # 启动 770B MoE 模型，这里以 8 卡张量并行为例 vllm serve Hy4/770B-MoE \ --tensor-parallel-size 8 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --quantization fp8几个关键参数给新手解释一下：
--tensor-parallel-size 8表示用 8 张 GPU 做张量并行，把模型权重切到多张卡上共同完成推理。MoE 模型很大，张量并行是最常用的扩展方式。--max-model-len 8192控制最大上下文长度，调大意味着 KV Cache 占用更多显存，如果你的任务不需要很长的上下文，不要盲目往上加。--gpu-memory-utilization 0.9表示单卡最多使用 90% 显存，留一点余量给 CUDA context 和临时变量，设成 1.0 看起来激进，实际上更容易触发 OOM。--quantization fp8要看硬件和框架支持情况，如果启动时报算子不支持，就换 AWQ 或去掉量化重试。
服务启动后，可以用一个 Python 脚本验证它是否正常工作：
from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="EMPTY" ) resp = client.chat.completions.create( model="Hy4/770B-MoE", messages=[{"role": "user", "content": "用一句话解释 MoE 架构"}], max_tokens=256 ) print(resp.choices[0].message.content)这里特别提醒一点：OpenAI 官方客户端默认请求地址是官方服务器，所以一定要把base_url指到本地，否则你会在毫不知情的情况下把所有请求发到别人的服务器上，既浪费钱，也容易泄露数据。
2.3 多卡通信：MoE 部署最容易翻车的地方
用多卡部署 MoE，最值得提前检查的不是 CUDA 版本，而是节点内部的通信链路。MoE 模型的专家分布在不同卡上，每个 token 可能被路由到多个专家，卡之间要反复交换中间结果。NCCL 通信效率直接决定你能跑多快，而不是 GPU 每秒能算多少亿次浮点运算。
我自己踩过的坑是这样的。有一台 4 卡 A100 的测试机，卡间只走 PCIe 而没有 NVLink，模型跑起来后跨卡通信在高负载下带宽瞬间打满，实际吞吐只有同配置但 NVLink 全互联机器的六成左右。后来换成支持 NVLink 的整机拓扑，更新了 NCCL 环境变量，情况才缓解。
在 Linux 上可以用nvidia-smi topo -m查看卡间拓扑。结果里如果出现NV，说明有 NVLink 高速互联；如果全是PIX或PHB，那说明卡和卡之间走的是 PCIe，跑大模型并行前一定要想清楚性能预期。云上租多卡实例时，优先选 NVLink 全互联的整机，而不是几台被网线拉在一起的裸金属。超大规模模型部署时，网络甚至比算力更值钱。
3. WorkBuddy 限时免费：该做什么、怎么做
3.1 WorkBuddy 到底解决什么问题
WorkBuddy 从名字就能看出定位：面向工作场景的智能助手加 Agent 工作台。在这次消息里，它和 Hy4 preview 是明显的组合拳。Hy4 负责底层的推理能力，WorkBuddy 负责把模型能力编排成实际可用的自动化工作流。模型是引擎，WorkBuddy 是方向盘和仪表盘。
它适合什么人用？先说个人场景：内容生产、资料整理、日程管理、邮件草拟，这些重复性工作都能交给它。再说团队场景：研发团队拿它做代码生成、日志分析、自动化运维；非技术团队也可以通过配置自定义工作流程，而不是人人都去写 Python 脚本。最近很多人在搜“workbuddy怎么使用”“workbuddy自定义指令推荐”，说明大家最关心的不是它有多少功能，而是怎么把它接进自己手头的工作流里。
3.2 安装与连接模型：两种典型路径
WorkBuddy 的部署方式通常分两种。一种是直接用官方提供的桌面端或网页端，注册后开箱即用，适合个人和小团队；另一种是本地部署 self-host，把配置和数据留在自己手里，适合对隐私敏感的团队。
限时免费阶段，我建议能试的地方都试一遍。安装本地版本时，比较常见的方式是用 Python 虚拟环境装包，或者直接从官方仓库拉服务端镜像。假设是 Python 工具链，安装和启动大概是这样的：
# 创建独立虚拟环境，避免污染系统环境 python -m venv workbuddy-env source workbuddy-env/bin/activate pip install workbuddy # 启动本地服务，默认端口 8080 workbuddy serve --host 127.0.0.1 --port 8080如果是连接你自己部署的 Hy4 MoE 模型，WorkBuddy 里通常需要配置模型服务地址。举个配置片段：
llm: provider: openai_compatible base_url: http://127.0.0.1:8000/v1 api_key: EMPTY model: Hy4/770B-MoE这里有个小经验：很多人在配置本地模型时习惯把api_key留空，但有些兼容层会强制要求这个字段非空，直接填EMPTY或sk-local这类占位符就能绕过校验。看似不起眼的细节，能省你半小时排查时间。
3.3 自定义指令：把 WorkBuddy 调教成你的工作流
WorkBuddy 真正的核心能力，是可自定义的 Skill 指令。你可以把频繁执行的任务固化成模板，之后每次直接调用，而不是反复手写提示词。这其实就是提示词工程的产品化，把该沉淀的经验用配置文件固定下来。
以周报整理为例，我一般会写一个 skill 配置，大概长这样：
name: weekly-report description: 根据原始工作记录生成结构化周报 trigger: 周报 prompt: | 你是我的工作助理。请把下面的原始工作记录整理成一份周报，要求： 1. 按项目/主题归类，每类先写完成情况，再写下一步计划 2. 用数据说话，尽量保留记录中的数字与时间点 3. 语气简洁，不超过 300 字 4. 遇到信息缺失时直接跳过，不要编造 原始记录： {input}配置完成后，在对话框里输入“周报”加一段工作流水，WorkBuddy 就会按模板生成。这种工作流一旦跑顺，省下的时间是非常可观的。不同平台对 Skill 目录和格式的定义会有差异，但核心思路一致：把团队里最擅长写提示词的人总结出来的方法，固化成大家都能复用的配置，而不是每次都从零开始脑内现编。
3.4 限时两周免费，这个打法怎么评价
从商业角度看，“限时免费”是典型的免费试用加口碑传播策略。两周时间足够一个认真的人把工具玩熟、把习惯培养起来，也足够一个团队做一个小型 PoC。对用户来说，最好的利用方式不是下载尝鲜放一边，而是把日常最花时间的工作流先固化成 skill，真的跑通一个闭环看看效果。
给一个非常实际的建议：限免期间，把配置、指令、流程都沉淀成文档。如果两周后不打算付费，这些工作方法和提示词模板也可以迁移到别的工具上，不算白干。如果体验确实好，团队采购预算也好谈，因为试用过程中的产出已经是现成的成果，你是在拿结果说话，而不是空口推荐。
4. 常见问题与避坑速查
4.1 模型部署阶段的典型报错
先聊显存不足，也就是最常见的CUDA out of memory。遇到这个报错，先别急着加卡，按顺序排查三件事：量化到底有没有生效。有时候你以为用了 FP8，结果模型加载方式不对，实际跑的还是 BF16，显存当然爆。然后是gpu-memory-utilization是不是设得过高，以及并发是不是开太大。排查方法很简单：把并发调到 1，只保留一两个请求，确认能正常推理后再逐步压测。
再一个是多卡通信问题，典型的报错是NCCL error或NCCL timeout。常见原因有三种：驱动版本不匹配、卡之间网络不通、NCCL 版本不一致。先用nvidia-smi topo -m看卡间拓扑，再用ibstatus看网卡状态，最后再考虑调整环境变量。很多人在这一步绕了很久，最后发现只是两台机器之间的防火墙没放行，这种低级错误反而最耗时间。
还有一个 MoE 特有的现象：日志里出现大段expert相关告警。如果发现某几个专家负载特别高，另一些几乎没流量，说明路由分配出现了明显不均衡。推理阶段我们改不了训练时留下的路由参数，但可以尝试调低 top-k，让每个 token 只参考少量专家，或者换更激进的 KV Cache 策略，能在一定程度上缓解负载不均带来的卡顿。
4.2 WorkBuddy 使用中的高频问题
连接不上模型，是我见过最多的问题。排查时先确认服务本身是通的：用curl http://127.0.0.1:8000/v1/models看一下能不能返回模型列表。能返回，说明模型服务正常，问题出在 WorkBuddy 配置里的base_url或model名称不匹配。特别注意，名称必须和 vLLM 启动时传入的模型名完全一致，比如Hy4/770B-MoE，多一个斜杠少一个版本号都会 404。
Skill 不生效，也很常见。大部分原因是 YAML 缩进错误、文件名没有按规范命名、或者改完配置后没有重启服务。经验做法是配置目录里只放当前需要的 skill，不要堆一堆没用的模板；改完一次优先去看日志，而不是反复重启服务盲试。
流式输出乱码，通常不是模型问题，而是终端或客户端编码问题。把终端环境改成 UTF-8 再试，九成以上乱码都会消失。剩下那一种是网络代理层做了字符转换，这时候检查反向代理配置就行。
4.3 快速排查速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 显存不足 | 量化未配置 / 并发过大 | 换 FP8/AWQ、降低 batch、关掉多余进程 |
| 推理极慢 | 跨卡通信带宽不足 | 检查 NVLink/NCCL，减少跨卡专家访问 |
| API 请求 404 | model 名称不对 | 访问 /v1/models 获取准确名称 |
| WorkBuddy 找不到模型 | base_url 写错 | 改成 http://127.0.0.1:8000/v1 |
| 自定义指令无效 | YAML 格式错误 | 用 yamllint 校验，检查缩进 |
| 流式输出乱码 | 终端编码不是 UTF-8 | 切换终端编码，检查代理 |
我实际操作下来最直观的感受是：这一次 Hy4 preview 发布，重点其实不只是“参数大”，而是“开源策略 + 应用工具”的打法开始成熟。我在限免开启后的第三天才抽出时间部署，第一周的时间几乎都花在显存规划和多卡通信调优上，真正把 WorkBuddy 的 skill 跑顺，反而只用了不到半天。如果让我给一个建议，那就是别一上来追求全量精度部署，先用量化版跑通完整流程，再逐步把效果提上去。还有一个小技巧：第一次启动时不要开太多并发，先压测单请求吞吐，摸清底牌后再上生产，否则第一个大请求就可能把整个服务打爆。剩下的试用时间里，值得把常用的几个工作流都固化成 skill，这比临时手写提示词高效得多。
