这两天模型圈子里讨论最多的，应该就是 Hy4 preview 的发布：770B MoE 权重直接开源，配套的 WorkBuddy 也放出了限时两周免费。说实话，上一波开源 MoE 大模型刚让人消化完，这一波节奏确实快。我第一时间把权重拉下来、把服务跑起来、又接上 WorkBuddy 试了几天，这篇就把自己的完整过程、踩坑记录和能直接抄作业的部署方案都整理出来。
这不是那种只报参数不教操作的“发布会复读”，而是一个普通开发者从下载到跑通再到实际接入使用的全流程实战笔记。无论你是刚接触 MoE 架构的新手，还是已经在本地部署过开源模型的老手，这篇都尽量做到既讲清楚原理，又给出能直接复现的命令和配置，少走弯路。
1. Hy4 preview 发布：770B MoE 为什么值得关注
1.1 770B 参数是什么概念：先分清“总参数”和“激活参数”
看到 770B 这个数字，第一次接触的朋友可能直接会被吓到：7700 亿参数，这要多大显存才能跑得动？
这里必须先把一个关键概念说清楚：在 MoE（Mixture of Experts，专家混合）架构里，总参数和实际参与计算的激活参数是两回事。总参数指的是模型文件里存储的全部权重，包括共享注意力参数、路由器参数、以及所有专家网络的参数；而激活参数指的是模型在处理每一个 token 时真正参与计算的那部分参数。
举个例子，如果一个 MoE 模型是 770B 总参数、激活参数只有 4B，那它运行时只需要加载全部权重用于推理（因为专家权重是动态路由选择的，无法提前裁剪），但真正做矩阵乘法的计算量只相当于一个 4B 级别的稠密模型。这就是“参数规模大但推理成本可控”的核心原因。Hy4 preview 这类大 MoE 模型的思路，本质上和 Mixtral 8x7B、DeepSeekMoE 一脉相承：用稀疏激活换来更强的知识容量，同时不把推理成本推到无法接受的高度。
对普通开发者来说，这意味着两件事：第一，你确实需要足够大的显存或集群来装下这套权重；第二，一旦权重装下之后，实际推理速度并不会像参数量看起来那么吓人，因为计算量不等于总参数量。我在下面的部署章节会详细算一笔账，告诉大家 770B 的 MoE 到底需要什么样的硬件。
1.2 MoE 架构怎么工作：路由器加专家，像一家“专科医院”
MoE 的直觉理解非常重要。想象一个大型综合医院，病人来了不是每个科室都去一遍，而是先到大厅分诊台做一次快速评估，然后由分诊台把病人分给几个最对口的科室。这里的分诊台就是路由器（Router），科室就是专家（Expert）。
对于每个输入的 token，路由器会计算它与各专家之间的匹配分数，然后选 Top-2 或 Top-4 个专家来实际处理。未被选中的专家这一轮就“休息”，不参与计算。这样既保留了各专家的专业分工能力，又避免了全部参数同时参与计算带来的巨大开销。
但 MoE 也带来一个特有痛点：负载均衡。如果路由器学偏了，所有 token 都被分到同几个热门专家身上，其他专家长期“闲置”，模型效果和训练效率都会打折扣。所以开源 MoE 模型通常会在训练时加入负载均衡损失，推理时也可以通过路由偏置参数（router bias）来调整分配策略。这是我实际调模型时最常碰到的概念之一，后面排查性能问题时会用到。
1.3 开源的意义：从“看榜”到“动手改”的距离被拉到了零
过去很长一段时间，模型发布就等于看一篇技术报告和几张榜单截图。现在开源权重发布之后，普通开发者可以把模型下载到本地，修改采样参数、尝试量化、定制后处理逻辑，甚至针对自己的业务场景做微调。这种“什么都可查、什么都可改”的透明度，是闭源 API 永远给不了的。
开源版本的另一个隐性价值是社区生态。权重一放出来，马上会有人做好量化版、有人写各种推理框架的适配、有人做 WorkBuddy 插件、有人整理多语言常见问题集。这些资源会反过来降低更多人的上手门槛。我在准备这篇博文的时候，已经看到社区里有不少人在讨论如何把 Hy4 preview 同时接入多个推理框架，也有人开始分享自己的显存优化方案了。
2. WorkBuddy 限时免费：一个能落地的智能体工作台
2.1 WorkBuddy 到底是什么：不是又一个聊天框
WorkBuddy 这个名字听起来像是个效率工具，但把它理解成“对话机器人”就太可惜了。从目前公开的信息和我的实际体验看，WorkBuddy 更像是一个面向开发者的智能体工作台：你可以让它接管复杂的多步骤任务，比如分析代码仓库、生成变更方案、执行测试、整理日志、辅助代码审查。它背后可以接入不同的模型，而 Hy4 preview 正好就是官方默认推荐的模型之一。
这一点和 CodeBuddy 有些关联，但定位不完全一样。CodeBuddy 更偏代码补全和 IDE 内的即时交互，WorkBuddy 则是把任务拆解、工具调用、上下文管理这一套整合到一起。我理解它的定位是“一个人工智能工程师”，而不是“一个自动补全插件”。
WorkBuddy 的优势在于它允许你自定义 skill。所谓 skill，可以理解为一个带描述、带参数定义、带执行逻辑的“能力包”。你写一个新的 skill，告诉 WorkBuddy 什么时候该用、该怎么用，它就可以在执行任务时自动调用。这个机制对重复性高的工程场景特别有用，比如自动按团队规范生成 commit message、自动把报错日志转成可检索的问题单等。
2.2 限时两周免费：这个窗口期该怎么用
限时免费两周，如果只是进去玩一下聊天，那确实没什么意思。我的建议是，把这两周当成一次集中验证期：
- 第一梯队：先跑通本地部署或云上部署的完整链路，确认 Hy4 preview 能不能正常响应，吞吐量是否满足日常使用。
- 第二梯队：把你日常最耗时、最重复的 2 到 3 个工程场景做成 skill，比如代码重构建议、测试用例生成、故障日志预处理。
- 第三梯队：做一次工作量估算，看如果免费期结束后转为付费，值不值。如果只是偶尔用，那不如直接用免费的本地推理；如果每周都要用它处理大量工程任务，订阅也许反而划算。
免费窗口的另一个价值是“低风险试错”。不用先付费就你能把模型、工作流、工具链全部验证一遍，心里有底之后再做采购决策。别等到最后两天才开始动手，真到那时候遇到部署问题，连查文档的时间都不够。
2.3 WorkBuddy 的典型使用流程：从指令到 skill
WorkBuddy 的基本交互方式有两种：临时指令和持久 skill。临时指令适合一次性需求，比如“把项目里所有 TODO 注释汇总成一份列表”；持久 skill 则适合那些你希望反复使用的工作流。
我实际的使用流程大致是这样：
- 在项目根目录初始化 WorkBuddy（一条命令即可）。
- 通过自然语言描述手头的需求，比如“检查 src/ 目录下的 Python 文件，找出潜在的空指针风险”。
- WorkBuddy 会根据上下文决定是否需要调用工具（读取文件、执行搜索、运行测试等）。
- 如果某个流程很好用，我会把它固化成一个 skill，之后下次直接输入一句话就能复用。
这种“先临时后固化”的用法，是我认为 WorkBuddy 效率最高的打开方式。
3. 本地部署 Hy4 preview 的完整实操
3.1 硬件评估：先算显存再买卡，别上来就下权重
部署开源大模型，第一步永远不是拉代码，而是算账。770B MoE 假设激活参数 A4B 左右，权重存储需求按不同精度来算：
- BF16（2 字节）：770B × 2 ≈ 1540 GB
- FP8（1 字节）：770B × 1 ≈ 770 GB
- INT4 量化（0.5 字节）：770B × 0.5 ≈ 385 GB
这里还没有算 KV Cache 和激活中间状态。以 8 张 H20（每张 96GB）为例，FP8 精度下权重刚好能放进去，但 KV Cache 的余量就比较紧张了；如果选 INT4 量化，8 张 48GB 的显卡也有机会，但推理吞吐会有所折损。
我实际测试时的硬件配置是 8 张 80GB GPU 的整机，选择 FP8 量化，max-model-len 设置为 32768。算下来权重占用约 770GB，留给 KV Cache 和调度的余量在 300GB 左右，跑 32K 上下文时压力明显比 128K 要小得多。如果是个人开发者没这么多卡的，建议优先考虑 4bit 量化版本，或者直接使用云 GPU 按需租用。
3.2 环境准备：依赖、驱动、模型下载源一个都不能少
环境准备这一步看似基础，但踩坑率最高。我建议按下面的顺序来：
- 确认显卡驱动支持 CUDA 12.1 或更高版本。
- 创建 Python 虚拟环境，Python 版本 3.10 或 3.11 会比较稳。
- 安装 PyTorch、vLLM 或 SGLang。两个推理框架我都会在后面给出启动命令，但首次跑通建议选一个即可。
- 下载模型权重。这一步是很多人的痛点，Hugging Face 路径如果下载不稳定，可以考虑从国内可正常访问的 ModelScope 魔搭社区拉取，它们的下载速度和断点续传体验都要好很多。注意，这里说的都是正规下载渠道，不需要任何额外工具。
下载权重时有个小技巧：先单独下载模型的配置文件（config.json、tokenizer 相关文件），确认模型结构被当前推理框架支持，再拉取全部权重。否则全量下载到一半才发现框架不支持，白白浪费时间。
3.3 推理服务启动：vLLM 与 SGLang 两种路线
这里给出我实际跑通的 vLLM 启动命令。以 FP8 量化版本为例：
vllm serve Hy4-org/Hy4-Preview-770B-A4B-FP8 \ --tensor-parallel-size 8 \ --dtype bfloat16 \ --quantization fp8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --enable-prefix-caching几个参数的解释：
--tensor-parallel-size 8：把模型切到 8 张卡上并行推理。770B 这种规模，单卡装不下，必须走张量并行。--quantization fp8：指定权重的量化格式。如果下载的是非量化版本，想去掉这个参数或改为其他量化方式。--max-model-len 32768：限制最大序列长度。长度设置越大，KV Cache 占用越高，实际使用时要结合显存余量做取舍。--gpu-memory-utilization 0.92：允许框架使用 92% 的显存，剩下留给驱动和连接缓冲。--enable-prefix-caching：开启前缀缓存。多个请求共享相同系统提示词时，可以大幅降低重复计算，后续并发测试里特别明显。
如果你用 SGLang，命令风格略有不同：
python -m sglang.launch_server \ --model-path Hy4-org/Hy4-Preview-770B-A4B-FP8 \ --tp 8 \ --quantization fp8 \ --context-length 32768 \ --mem-fraction-static 0.88SGLang 的路由缓存（radix cache）在长 Prompt 重复场景下表现很出色，如果你主要面向对话类服务，建议两个框架都试一下，再选吞吐更合适的那一个。
3.4 量化与精度：FP8 还是 INT4，别只看省显存
量化是开源大模型部署绕不开的环节。FP8 的优点是精度损失小，推理质量几乎与 BF16 无异，推荐的优先选择。INT4 能省一半显存，但某些任务上会明显变“笨”，比如复杂代码生成或长文档归纳，所以除非显存实在不够，否则我不建议直接上 INT4。
如果非要 INT4 不可，务必选择带校准过程的 AWQ 或 GPTQ 量化模型。一些在线量化工具直接拿权重做 4bit 截断，没有做激活值校准，会导致质量急剧下降。我测过几种情况，同样的 Prompt，FP8 版本能生成完整可执行的代码，未经校准的 INT4 版本偶尔会出现重复输出和逻辑断裂。这里的选择逻辑很清晰：显存足够就 FP8，不够就找校准过的 INT4 模型。
4. WorkBuddy 接入核心实操：把模型和工具链串起来
4.1 本地推理服务接入 WorkBuddy：一个 OpenAI 兼容接口就够了
vLLM 和 SGLang 都提供了 OpenAI 兼容的接口。这意味着 WorkBuddy 的接入并不需要做特殊开发，只需要把它指向本地服务的地址和端口。我的配置示例如下：
provider: openai model: hy4-preview-770b-a4b-fp8 base_url: http://127.0.0.1:8000/v1 api_key: local-test需要注意base_url一定要带/v1后缀，否则很多客户端会去请求路径下不存在的接口，导致连接失败。这个看似低级的问题，其实是我第一次接入时卡得最久的地方。api_key填任意字符串即可，本地服务一般不做鉴权校验。
接入完成之后，先在 WorkBuddy 里跑一条简单指令，比如“用三句话介绍这个项目”，确认能拿到正常回答，再进行复杂任务。
4.2 自定义指令与 skill 开发的取舍
WorkBuddy 的价值上限其实在 skill。我来分享一个自己写过的 skill 示例，JSON 结构大概是这样的：
{ "name": "commit-message-generator", "description": "根据 git diff 生成符合团队规范的 commit message", "parameters": { "language": "中文", "style": "conventional_commits" }, "steps": [ "读取当前 git diff", "分析变更类型和影响范围", "生成标题和正文", "输出到终端" ] }这个 skill 我用了快一周，最大的感受是：真正好用的 skill 不需要追求“万能”，而是要把边界划清楚。你告诉它什么时候不该用，比告诉它什么时候该用更重要。如果让一个 skill 大包大揽，它反而容易在边界场景中给出离谱结果。
另一个心得是：skill 的名字和描述要足够具体。MoE 模型的意图理解能力虽然强，但歧义仍然是最大的坑。描述里写“处理代码问题”就远不如“检查代码中潜在的空指针和越界访问风险”来得可靠。
4.3 一个完整的项目落地场景：代码评审流程
我用一个实际场景来说明整条链路怎么配合。
项目组之前做代码评审，靠人肉看 diff，费时且容易漏。接入 Hy4 preview + WorkBuddy 之后，我的做法是：
- 写好一个“代码评审” skill，定义检查维度：复杂度、潜在异常、安全隐患、可测试性。
- 在 Merge Request 准备阶段，把改动的 diff 交给 WorkBuddy。
- WorkBuddy 调用本地 Hy4 preview 服务，分多个子任务完成分析，最后汇总成带严重级别的评审意见。
- 人工只负责复核那些被标记为 High 级别的问题，其他直接参考。
实测下来，一个 500 行以内的 diff 分析，通常 2 到 3 分钟就能出完整报告。相比之前完全人工，效率提升非常明显。
5. 常见问题与排查技巧实录
5.1 显存不够的三种解法：从改参数到换量化
这是问得最多的问题。显存不够的表现通常是启动时报CUDA out of memory，或者在推理过程中崩掉。我的排查顺序是：
先降低--max-model-len到 8192 甚至 4096。很多人默认满血跑 32K 上下文，但实际业务未必需要。序列长度是 KV Cache 占用的决定性因素，把 32768 降到 8192，KV Cache 直接减少到四分之一。
再考虑开启 CPU offload。vLLM 和 SGLang 都支持把部分权重或 KV Cache 放到 CPU 内存，但代价是推理变慢。适合那些显存差一点但又不是天天跑的场景。
最后才是换量化精度。FP8 切到 INT4，权重占用从 770GB 降到 385GB，但精度损失不可忽略，建议先在目标任务上做一轮效果对比再决定。
5.2 WorkBuddy 连不上本地模型的快速排查
我把实际遇到的情况整理成了速查表：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 连接被拒绝 | base_url 少了 /v1 | 确认配置为 http://127.0.0.1:8000/v1 |
| 请求超时 | 模型还没加载完成 | 查看服务日志，确认 ready |
| 返回 404 | 路径不对 | 用 curl 直接测 /v1/models 接口 |
| 反复重试 | 并发过高 | 调整 vLLM 的 max-num-seqs 参数 |
| 输出乱码 | 温度参数太高 | 将 temperature 降到 0.3 以下 |
我自己的习惯是：先不管 WorkBuddy，直接 curl 一下服务接口，如果 curl 能通，问题就一定出在客户端配置上。
5.3 性能调优：Token 速度、并发、前缀缓存一个都不能少
性能调优方面，我实测的心得如下：
- 前缀缓存一定要开。无论是 vLLM 的
prefix-caching还是 SGLang 的 radix cache，在系统提示词固定的场景下，吞吐能提升 30% 以上。 max-num-seqs不要盲目调大。并发过高会导致单请求延迟飙升。对于 770B 这种规模，我建议从 32 开始试，逐步加大观察效果。- 采样参数不要频繁改。如果业务对随机性要求不高，固定住
temperature和top_p，可以让框架更好地缓存和复用公共前缀。
5.4 模型下载慢或失败怎么办
大模型一个文件动辄几十 GB，下载中断真的很让人崩溃。我的经验是用支持断点续传的工具下载。从 ModelScope 拉取时，它有比较成熟的客户端，断点续传做得比较稳。下载完成后记得核对文件完整性，很多框架加载失败其实是因为权重文件损坏，而不是模型本身的问题。
6. 从 Hy4 preview 看开源 MoE 模型的落地节奏
6.1 个人开发者值得现在就动手吗
我的回答是值得，但要有心理预期。770B MoE 不是那种你在一台游戏机上就能玩转的模型，它需要多卡或云资源。但换个角度想，开源社区一定会快速跟进小参数变体、量化版本和各种部署优化。别光盯着最大的那个模型，先用现有的 FP8 版本把推理链路跑通，真正的价值在于掌握这套“部署开源 MoE + 连接智能体工具”的完整技术栈。
6.2 三个值得关注的插件方向
从 WorkBuddy 的扩展生态来看，我比较看好几个方向：
一是面向特定行业的 skill 包，比如医疗病历结构化、金融研报摘要、法律文书审查，这类场景天然需要大模型理解能力加上行业规范约束。二是面向私有化部署的“模型+工作流”一体包，把模型、推理配置、skill 和文档捆绑在一起，降低企业落地门槛。三是面向性能调优的经验库，比如不同硬件下 MoE 模型的最佳并行策略、最佳量化方案，这些经验目前还很稀缺。
6.3 结合我的实际体验，最后再分享一个小技巧
如果你准备在这两周里试 WorkBuddy，建议从“高频小任务”开始，而不是一上来就挑战那种“重构整个代码仓库”的宏大指令。我踩过几次坑之后发现，把一个大任务拆成若干个小任务，每个任务都配上清晰的上下文和验收标准，效果远好于一次复杂提示。这个经验不仅适用于 WorkBuddy，其实也适用于大多数基于大模型的智能体工具。
开源模型和智能体工具的结合，会催生出很多新的工作方式。Hy4 preview 只是一个开始，后面还会有一波接一波的新模型和新工具。最后我想说的是：不要怕硬件不够，也不要怕上手难，先跑通一个最小的闭环，再慢慢往里加场景，这比什么都有用。
