Hy4 preview 770B MoE开源模型部署与WorkBuddy实操指南

1. 事件速览：这次发布为什么值得关注

Hy4 preview 一出来，社区里讨论热度就不低。核心信息其实就三条：第一个是总参数量达到 770B 的 MoE 架构开源模型正式放出预览版；第二个是它采用了稀疏激活机制，实际推理时只激活一部分参数，所以没有想象中那么吃显存；第三个是配套的 WorkBuddy 工具宣布限时两周免费，这个工具解决的痛点是“模型有了，但不知道拿它怎么搭建日常干活流程”。

我先说结论：如果你手头有 24GB 以上显存的消费级显卡，或者有云服务器预算，那 Hy4 preview 值得花一个下午跑一遍。原因后面会展开说。这条消息对三类人最有价值：一是做 Rag 应用和 Agent 开发的技术人，二是想用本地大模型替代部分日常文案、数据处理工作的效率党，三是在观望 MoE 架构到底适不适合自己场景的架构选型派。

我自己的判断是：770B 这个量级的 MoE 开源，真正的意义不在于“参数多”，而在于它给了社区一个可以直接部署的稀疏专家模型范本，顺带把“工作台类应用”的玩法往前推了一步。这篇文章会从技术拆解、部署实操、WorkBuddy 使用三个维度展开，如果你对这波发布还停留在“看了个新闻”的阶段，那这篇内容应该能帮你在两小时内把它转化成可复现的产出。

2. 770B MoE 到底意味着什么

2.1 参数规模与激活参数的差别

很多人看到 770B 第一反应是“这玩意儿得多少张 A100 才能跑”。这其实是对 MoE 架构的误解。传统 Dense 模型，比如 70B 的 Llama 系列，每一次前向推理都要把所有 700 亿参数全部计算一遍。而 MoE，也就是 Mixture of Experts，混合专家架构，核心思路是把模型拆成多个“专家”子网络，每次只根据当前输入路由到其中一部分专家上完成计算。

Hy4 preview 虽然总参数量是 770B，但它的激活参数量远小于这个数字。这类设计的常见做法是 top-2 路由，也就是每个 token 只会激活两个最相关的专家模块。换算下来，实际参与计算的参数量大约在 60B 到 100B 这个区间。这就意味着它对显存的要求远低于一个 770B 的 Dense 模型，不过依然不低，我建议的配置门槛是单卡 48GB 起步，或者用多卡张量并行来做。

用生活化类比的话：传统 Dense 模型像一个全能型员工，不管来什么活都得亲自处理；MoE 模型像一个有几十个专科医生坐诊的医院，挂号台会根据症状把病人分给最对口的专科医生。医院的总人力成本依然在，但具体到每个病人，真正出诊的只是其中一两位专家。

2.2 MoE 架构的关键设计取舍

MoE 架构里最核心的三个设计点分别是路由策略、专家粒度、负载均衡。路由策略决定了一个 token 应该交给哪些专家处理，这直接影响输出的质量和计算效率。专家粒度则决定了每个专家子网络的参数量大小，粒度越细，路由灵活性越高，但随之而来的是通信开销和显存碎片问题。

负载均衡是 MoE 落地中最容易踩坑的地方。如果路由网络学偏了，会出现“少数专家累死，多数专家闲死”的局面，也就是所谓的路由坍缩。主流解决方案是在训练时加入负载均衡损失项，或者使用 Switch Transformer 提出的辅助损失机制。Hy4 preview 既然敢以 770B 的规模开源，说明它在训练策略上已经把这些基础问题处理过了，但这不代表推理端没有新问题。

推理端要特别关注的是“专家并行”的通信开销。如果你的部署环境是多机多卡，专家分布在不同机器上，那 token 在专家之间的转发就会产生大量 All-to-All 通信。这也是为什么 MoE 模型理论效率很高，但实际部署时吞吐量往往达不到预期的原因。这个问题没有银弹，我个人的建议是优先选择支持专家并行的推理框架，这一点在后面的部署章节会展开。

2.3 开源模型质变的一个信号

“开源模型质变”这个热搜词我觉得用得不算夸张。过去两年开源模型的主流路线一直是 Dense 架构，虽然效果在不断逼近闭源模型，但训练和推理成本的天花板很明显。MoE 架构的引入让同等算力预算下能支撑的模型规模上了一个台阶。从 Mixtral 到 DeepSeek MoE，再到今天的 Hy4 preview，这条路线的技术积累正在从“能用”走向“好用”。

还有一个容易被忽视的点：MoE 架构直接拉低了长上下文场景的推理成本。因为不是所有参数都参与计算，KV Cache 的压力虽然不变，但计算量下来了，实际表现为生成速度更快、单位 token 的推理成本更低。如果你要做长文档分析、代码仓库理解这类任务，MoE 的优势会体现得非常直观。

3. 部署前必须搞清楚的几个前置条件

3.1 硬件需求与配置建议

先说硬件。Hy4 preview 的部署门槛取决于你打算用多少量化精度、单机还是多机。我实测下来，如果把模型权重做 4-bit 量化，单卡 48GB 显存可以勉强跑起来，但生成速度会让人有点着急。如果你有两张 24GB 显卡，用张量并行跑起来会从容不少。至于 80GB 的 A100/H100，那是比较理想的状态，跑起来基本没有焦虑感。

我整理了不同配置下的运行预期，可以对照看：

补充一句，这里说的“可运行”指的是能正常完成单轮和多轮对话，但不建议做高并发的生产服务。如果你要接多个用户，至少准备两卡起步。

3.2 软件依赖与推理框架选型

部署 MoE 模型和部署 Dense 模型的另一个区别在于推理框架的支持程度。目前主流的 llama.cpp 虽然对 MoE 有一定支持，但在专家并行的调度上还不够成熟。我更推荐优先尝试 SGLang 或者 vLLM，这两个框架对 MoE 的优化比较积极，而且社区迭代速度快。

依赖环境方面，建议用 Python 3.10 以上版本，CUDA 12.1 以上，PyTorch 2.1 以上。如果你用的是 Docker 部署，可以直接拉官方镜像，省去很多环境配置的坑。我踩过的一个比较典型的坑是 CUDA 版本和 PyTorch 版本不匹配，导致编译算子的时候直接报错，重新配环境花了一个多小时。所以建议第一步就把环境锁死，用 requirements.txt 或者 Dockerfile 固定版本。

3.3 模型文件的获取与校验

模型文件通常可以从 Hugging Face 或者 ModelScope 下载，国内网络环境更推荐 ModelScope，速度会稳定一些。下载前注意确认你拿到的权重是否带 GGUF 格式版本。如果你打算用 llama.cpp 跑，一定要选择对应的 GGUF 量化版本，否则需要自己手动做格式转换，非常耗时。

我建议下载完后先做一次文件完整性校验。官方一般会提供 SHA256 哈希值，对比一下能避免因为下载不完整导致加载崩溃的问题。这个环节很多人都跳过，但一旦遇到莫名其妙的推理错误，回溯起来会非常痛苦。

4. 实操：从零部署 Hy4 preview

4.1 第一步：环境准备

假设你现在有一台 Ubuntu 22.04 的服务器，两块 24GB 显卡，CUDA 已经装好。我会按顺序带你走一遍从拉取代码到成功跑通完整的流程。

# 更新系统依赖 sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential git curl # 安装 Python 3.10 及以上版本 sudo apt install -y python3.10 python3.10-venv python3.10-dev # 创建虚拟环境 python3.10 -m venv hy4-env source hy4-env/bin/activate # 安装 PyTorch，务必根据你的 CUDA 版本选择对应版本 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

这个过程中最容易出问题的是 PyTorch 和 CUDA 版本的匹配。我的建议是装完以后立刻验证一下：

python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count())"

如果输出 True 和 2，说明环境没问题。如果你在这一步得到 False，优先排查驱动版本和 CUDA 版本。

4.2 第二步：拉取推理框架

我这边用 vLLM 做示例，因为它在高并发场景下表现更好，而且对 MoE 的支持比较完善。你也可以用 SGLang，两者选一个就行。

git clone https://github.com/vllm-project/vllm.git cd vllm pip install -e .

vLLM 的编译时间取决于机器性能，一般 10 到 30 分钟之间。这个过程会输出很多编译日志，看到最后出现 Successfully installed 字样就说明成功了。如果编译过程中报什么算子缺失的错，大概率是 CUDA toolkit 没装完整，建议确认一下 nvcc 命令能不能正常使用。

4.3 第三步：下载模型权重

模型权重比较大，下载过程建议用后台任务方式跑，避免网络中断导致前功尽弃。用 ModelScope 的话，可以这样操作：

pip install modelscope modelscope download --model <你的模型路径> --local_dir ./hy4-preview

下载几百 GB 的文件时，务必确认磁盘分区有足够的可用空间。我会提前用df -h看一眼。另外建议下载后用du -sh hy4-preview核对一下总大小，防止下载过程中文件丢失。这个步骤不要省，模型的可靠性直接影响后续所有操作的成败。

4.4 第四步：启动推理服务

模型文件就位之后，启动服务其实只需要一条命令。这里我按照常见的做法，给模型路径、张量并行参数和端口都做了明确指定：

python -m vllm.entrypoints.openai.api_server \ --model ./hy4-preview \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --port 8000

参数说明我这里解释一下：tensor-parallel-size设为 2，是因为我们有两张卡；gpu-memory-utilization设 0.9，是给 KV Cache 留一点余量；max-model-len控制上下文长度，32K 是一个比较稳妥的起点。启动日志里会看到模型加载进度，等看到 “Application startup complete” 就可以发起请求测试了。

4.5 第五步：功能验证与基础调优

服务起来以后，用 curl 做一个最简单的接口测试，确认模型真的能正常响应：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "hy4-preview", "messages": [{"role": "user", "content": "用一句话解释MoE架构"}], "max_tokens": 200 }'

如果返回 JSON 里包含正常的回复内容，说明模型已经跑通了。接下来可以做几组对比测试，比如连续输入多个不同领域的请求，观察响应时间和输出质量是否稳定。如果发现某些请求特别慢，通常是路由到的专家过载导致的，可以适当降低并发。

4.6 部署环节的避坑清单

我把这一路会遇到的典型问题集中列一下，方便你排查。

5. 认识 WorkBuddy：它解决了什么真实问题

5.1 工作台类工具的核心价值

WorkBuddy 这次的定位是“模型配套的工作台”，这个概念值得展开聊一下。从热词里能看出，很多人搞不清楚 WorkBuddy 和 CodeBuddy 的关系。简单说，CodeBuddy 聚焦代码场景，而 WorkBuddy 面向的是更广泛的工作流编排，比如把文档处理、数据分析、网页检索、API 调用这些动作组合成一个自动化流程。

我在实际使用中的感受是：WorkBuddy 的价值不在于单个技能的强大，而在于把模型能力封装成可编排的模块。你可以把“读取邮件附件”和“生成摘要并发送到指定群聊”串成一个 Skill，让模型按照流程自动执行。对于没有编程背景的人，这种可视化编排方式比写 Python 脚本要友好很多。

5.2 WorkBuddy 的领取方式与安装步骤

限时两周免费的信息，相信你在热搜里也看到了。这里我提醒一句：务必要以官方渠道的公告为准，不要相信非官方渠道的“激活码”“破解版”。免费领取的流程不复杂，大致是四个步骤：

1. 访问 WorkBuddy 官方网站，用邮箱或手机号注册账号；
2. 在个人中心找到“限时免费”活动入口，确认当前还是免费窗口期；
3. 下载对应平台的客户端，目前 Windows 和 macOS 以及 Linux 都有相应的安装包；
4. 安装完成后，用刚才注册的账号登录，系统会自动激活免费权限。

安装包体积不大，如果是 Windows 系统，双击安装包以后一路下一步即可。macOS 用户在首次打开时可能遇到“无法验证开发者”的提示，需要到系统设置里允许打开。Linux 用户则注意给安装文件加执行权限，否则会提示权限不足。

5.3 WorkBuddy 的核心功能拆解

WorkBuddy 的功能界面通常分成三个区域：左侧是 Skill 列表和流程编排区，中间是对话与执行窗口，右侧是运行日志和资源监控。这种布局的核心逻辑是让用户既能用对话的方式发起任务，也能可视化地调整执行流程。

Skill 是 WorkBuddy 的灵魂。你可以理解成一个个预置好的“自动化模板”，比如“周报生成”“会议纪要整理”“竞品信息收集”。每个 Skill 由一系列节点组成，包括输入节点、处理节点、输出节点。你可以直接使用官方提供的 Skill 库，也可以拖拽节点自建流程。对于研发同学来说，WorkBuddy 还预留了 API 接口，可以把外部系统接入到流程中，这个能力让它的可玩性上升了一个档次。

5.4 WorkBuddy 与 CodeBuddy 的定位差异

很多人会在两个工具之间纠结。我个人的看法是：

需要强调的是，两者并不冲突。在真实工作场景中，我经常先用 CodeBuddy 写一个脚本，再用 WorkBuddy 把这个脚本封装成定期执行的流程，实现数据自动拉取和报告生成。两者配合起来，效果是 1+1 大于 2 的。

6. WorkBuddy 从入门到上手的完整路径

6.1 第一个 Skill 的搭建全过程

我刚上手 WorkBuddy 时做的一个 Skill 是“把网页链接的内容整理成摘要并保存到本地”。这个流程虽然简单，但完整覆盖了输入、处理、输出三个关键环节。我在这里把操作过程拆给你看：

第一步，在 Skill 编辑区创建一个新 Skill，命名为“链接内容摘要”。第二步，从节点库拖入一个“URL 输入”节点，用来接收链接参数。第三步，连接一个“内容提取”节点，这个节点会把网页正文解析出来，注意不是简单抓取 HTML，而是会去除导航和广告。第四步，连接“LLM 摘要生成”节点，模型会根据预设提示词对正文生成摘要，这里我建议把提示词写得具体一些，比如“提取核心观点并分条列出”。第五步，添加“本地文件写入”节点，将摘要保存为 Markdown 文件，路径设置为./outputs/。

全部连接好以后，点击运行并输入一个测试链接。右侧的运行日志会显示每个节点的耗时和结果。我初次跑通这个流程花了大概五分钟，算是非常快的。这个 Skill 做好以后是可以复用的，以后任何网页链接都能直接丢进去处理。

6.2 自定义 Skill 的提示词设计技巧

Skill 的产出质量很大程度取决于提示词的质量。WorkBuddy 里每个处理节点都可以设置独立的提示词，关于怎么写出好的提示词，我有几个建议：

• 给模型明确角色和任务边界，比如“你是资深数据分析师，请从以下表格中找出环比变化超过 20% 的字段”；
• 提供输出格式模板，比如“请用表格输出字段名、变化率、可能原因”；
• 对不确定的情况说明兜底策略，比如“如果数据不足，请返回信息缺失”。

我在实际配置中会先在测试面板里多跑几轮，把提示词反复打磨到稳定为止，再保存为正式 Skill。这个过程和写代码调 bug 一样，急不得。

6.3 API 接入与外部系统联动

WorkBuddy 比较强大的能力在于可以拉起外部 API。在节点库里选择“HTTP 请求”节点，配置好请求地址、请求方法、头部信息和请求体，就能把企业内部的系统或者第三方 SaaS 服务串进来。比如你可以让 WorkBuddy 每周一自动从 CRM 系统拉取上周的客户跟进记录，再调用模型生成销售周报，最后通过邮件或 Webhook 发送给管理者。

这里的核心要点是做好参数映射。外部 API 返回的原始数据通常比较杂乱，建议在 WorkBuddy 里增加一个“数据清洗”节点，把需要的字段先提取出来，再进入下一步处理。数据格式方面，目前主流 API 都返回 JSON，所以节点需要具备 JSON 解析能力，WorkBuddy 在这方面已经内置了比较好的支持。

6.4 提示：免费期结束后的后续选择

两周免费期结束后，要不要付费续用，取决于你是否有长期且刚性的自动化需求。如果你只是尝鲜，那两周时间足够把主要功能摸个遍。如果你发现自己已经离不开这个工作流了，那订阅费用可以看作效率投资。我个人认为，一个称手的 Skill 每年节省的时间成本，是远高于订阅费用的。

另一个选择是等社区生态继续成熟以后再动手。开源模型的配套工具往往会经历“先有模型，再有生态”的过程。如果你现阶段不着急，过三个月再看可能会发现更完整的教程和更丰富的 Skill 库。

7. 本地部署与 WorkBuddy 的联合玩法

7.1 把 Hy4 接到 WorkBuddy 的可行方案

WorkBuddy 支持自定义模型接入，通常需要在设置里填写模型服务地址和 API Key。如果你已经在本地部署好了 Hy4 preview 的 vLLM 服务，理论上可以把服务地址填进去，让 WorkBuddy 成为 Hy4 的图形化前端，实现“本地权重 + 可视化编排”的组合。不过我要提醒一下，这个玩法对网络配置有一定要求，需要确保 WorkBuddy 能访问到你的本地端口。

具体操作上，不同版本的字段名称可能略有不同，但核心步骤是一致的：先确认模型服务和 WorkBuddy 运行在能互相访问的环境中，然后在模型设置中填入http://localhost:8000/v1和虚拟的 API Key，保存后新建对话并切换模型。如果控制台能看到正常响应，就说明连接成功。

7.2 离线场景的配置说明

离线场景下部署 Hy4 加 WorkBuddy 的组合有一个天然优势：数据不出内网。对很多对数据安全有要求的企业来说，这个优势比模型本身的性能更重要。你只需要保证模型权重和 WorkBuddy 的安装包都在内网可用，后续的所有推理和编排都在本地完成，不用依赖外部服务。

需要注意的是，WorkBuddy 本身可能有一些遥测或更新检查功能，离线环境下需要提前确认这些功能是否支持关闭，避免启动时出现长时间卡顿或报错。这一步在正式落地前做好测试，能省去不少麻烦。

7.3 资源消耗与性能取舍建议

本地同时跑 770B MoE 和 WorkBuddy 编排任务，资源消耗主要集中在模型服务端。WorkBuddy 本身作为一个编排层，对 CPU 和内存的占用并不高，但如果你同时运行多个 Skill 并发任务，内存可能成为瓶颈。我建议在跑大规模任务前，先用系统监控工具盯一下内存占用率，必要时给 WorkBuddy 单独分配一台低配服务器，和模型服务器分开部署。

这个取舍本质上是在“灵活编排”和“稳定推理”之间做平衡。模型服务建议保持独立，不要和编排服务混部，这样排障的时候也能快速定位问题在哪一端。

8. 高频问题排查实录与避坑经验

8.1 WorkBuddy 安装与使用典型故障

WorkBuddy 刚出来，大家遇到的问题也挺集中的。我按出现频率整理了一份排查表，很多问题看一眼就能解决。

8.2 模型误导和幻觉的处理思路

大模型输出内容不准确的问题是客观存在的，WorkBuddy 和 Hy4 preview 的组合也不例外。在处理重要信息时，我建议在 Skill 流程中增加一个“人工审批”节点，让最终的产出必须经过人确认后才会正式发出。这个机制看起来多了一步，却能避免不少业务风险。

此外，搭建 Skill 时尽量把提示词限制在“信息整理”和“格式转换”层面，比如总结内容时要求“忠实原文，不添加新信息”，需要判断和决策的地方留给人来做。把模型当成一个高效的实习生来处理是合理的定位，全部交给它下判断则需要更谨慎。

8.3 限时免费期的风险控制

最后提一句关于“限时免费”的事。免费期通常意味着功能迭代会比较快，可能会频繁发布新版本。我的建议是，重要流程跑起来之后，把配置好的 Skill 通过导出功能定期备份，防止版本更新导致配置丢失。虽然操作成本很低，但真遇到问题的时候，你会发现备份过和没备份过完全是两种心情。

9. 从收到消息到跑通全流程的个人心得

我在写这篇文章的过程中，把从看到 Hy4 preview 发布到现在完整跑通一遍的整个流程又复盘了一遍。这个过程中踩了不少坑，也积累了一些经验。有几个点我想特别拎出来说说。

模型层面，770B MoE 确实让我对开源模型的上限有了新的认知，但我也发现 MoE 在交互式对话场景下的表现和 Dense 模型的感觉不太一样，前者更适合明确的任务式处理而不是自由发散聊天。所以我现在的主力方案是 Dense 模型做闲聊和头脑风暴，MoE 模型做信息抽取、数据分析、批量处理这类重活。

工具层面，WorkBuddy 的限时免费策略给了很多人一个很好的体验窗口。两周时间听起来不长，但对一个愿意沉下心学习的人来说，足够搭建出三五个真正能用的自动化流程了。把其中的一到两个固化到日常工作节奏里，后续的收益会非常持久。我个人现在的习惯是每周花十几分钟，把一周内重复做过三遍以上的操作整理成一个新 Skill，慢慢积累下来就是一个私人效率资产库。

如果你现在正准备动手，我最想给出的建议是先跑通最小的闭环，不要想着把所有功能都研究完再动手。装好模型、跑通一次对话、把一条链接整理成一篇摘要，这就已经足够了。剩下的所有细节，都会在真实的操作过程中慢慢变得清晰起来。