770B MoE模型本地部署：vLLM与WorkBuddy自动化工作流实战

1. 发布信息拆解：别被“770B”吓得直接关掉页面

我在朋友圈和几个技术群里连续看到同一条消息时，第一反应其实是有点矛盾的：一个总参数量做到 770B 的 MoE 开源模型，再加一个叫 WorkBuddy 的工具限时免费两周，这两件事看起来完全不在一个频道上。等我把模型本身的参数卡和配套工具的实际用法都完全看完，才确定这种“奇怪的组合”恰恰是这次发布最有意思的地方——你想在本地体验这个体量的模型，光有能跑大模型的框架还不够，还得有能够把任务编排起来的工具层；而 WorkBuddy 扮演的就是这个编排层的角色。

先说第一个关键事实：770B 不是你在推理时每次都要占满的计算量。MoE，也就是 Mixture of Experts，核心思路是把一个大模型拆成很多个“专家子网络”，每个 token 进来之后不是让所有神经元都参与计算，而是通过一个路由门控只激活其中一小部分专家。市面上常见的 MoE 开源模型，比如某些 230B 或 671B 量级的模型，实际激活参数往往只有 20B 到 40B 上下，这也是为什么很多 4090 用户敢去碰几百亿参数模型的根本原因。

Hy4 preview 给我的第一感觉也是这样。从公开参数来看，它走的是典型的大而稀疏路线：总参数量 770B，但推理时激活参数被控制在几十 B 的规模。这意味着它的知识容量和记忆范围会比同代稠密模型大不少，但单次推理的算力需求并没有按 770B 去线性放大。

我自己整理了一份“第一眼参数表”，方便还没细看官方仓库的朋友快速建立概念：

这个参数组合带来的第一个直接好处是：即便你手头没有动辄 8 卡 80G 的专业服务器，只要走合理的量化方案，还是有机会把模型塞进自己已有的 GPU 里跑一跑。第二个好处则是生态层面的，既然权重开放，那 vLLM、SGLang、llama.cpp 这些主流推理框架大概率都会快速跟进，部署起来不会像某些闭源接口那样被限制得死死的。

当然，“开源”这个词有时候会被误读成“所有人都能白嫖大集群算力”。实际体验下来，770B 总参数的模型哪怕只激活几十 B，权重本身就是个不小的存储挑战。如果你用 fp16 精度把所有权重完整加载，光权重文件就奔着 1.5TB 去了，这绝不是一块民用显卡能扛下来的量级。所以接下来要聊的部署链路，核心问题只有一个：怎么在硬件预算和模型效果之间找到一个可以接受的折中点。

2. 先从“能不能跑动”聊起：硬件边界、量化取舍和我的最终配置

2.1 不同硬件下的三种落地姿势

我见过太多人看完参数表直接放弃，觉得本地部署这种事只属于大公司。但其实 770B MoE 的部署难度取决于你对手里硬件的预期管理。我把常见的情况分成了三种：

• 第一种，只有单张 24GB 显卡，比如 RTX 3090 / 4090。此时你想跑完整模型基本不现实，但可以走 4bit 或更低 bit 的量化，用 CPU offload 或小批次推理勉强跑起来，适合做测试和小规模实验。
• 第二种，有两到四张 24GB 显卡，或者有 48GB 以上的专业卡。这种情况下用 AWQ/GPTQ 量化或者 FP8 方案会比较顺，推理速度能到能用的水平。
• 第三种，有 A100/H100 级别的多卡集群。那就不需要我多说什么了，直接上 FP16/BF16 全精度加载，追求最佳效果。

我自己是两卡 4090 的配置，所以选择了“4bit 量化 + vLLM 多卡部署”的路线。实测下来，模型能稳定加载并生成完整回复，速度比我想象中好很多，基本达到了“可交互”的程度。如果你也用 Ollama 或者 LM Studio 这类偏向普通用户的工具，还可以考虑直接拉 GGUF 格式的量化文件，一条命令就能跑起来，门槛更低。

2.2 部署时最容易忽视的显存陷阱：KV Cache

很多人把模型权重量化之后，以为显存就万事大吉了，结果一跑长文本就 OOM。这里真正的隐藏大户是 KV Cache。尤其是 MoE 模型，虽然激活参数少，但是 KV Cache 的占用和你的上下文长度、层数、注意力头数直接挂钩，并不会因为稀疏而自动变小。

我当时犯过一个典型错误：第一次启动时贪心地把 max-model-len 设置成 128K，再叠加较大的 batch，结果两张 24GB 卡的显存直接被权重和 Cache 一起压满，服务进程在加载阶段就崩了。后来我老老实实把 max-model-len 调到 32K，再配合 vLLM 的 automatic prefix caching 功能，跑真实业务场景才稳定下来。

这里分享一个我建议的计算顺序：

1. 先确认量化后权重大小，给权重预留不低于 110% 的空间。
2. 根据自己实际要用到的文本长度反推 KV Cache 需求，而不是盲目要上限。
3. 先跑一次不超过 4K 的短文本测试，确认服务正常后再逐步加长。
4. 加长上下文时，用真实任务去测试，而不是简单做一个连续拼接的“假长文本”。

2.3 我的最终启动命令，可直接参考

如果你也想在本地用 vLLM 托管这个模型，我把自己验证过的启动参数贴出来。需要说明的是，不同版本的 vLLM 对 MoE 模型的支持程度有差异，建议用较新的版本。

python -m vllm.entrypoints.openai.api_server \ --model /path/to/hy4-preview-4bit \ --served-model-name hy4-preview \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --quantization awq \ --trust-remote-code \ --port 8000

如果你是拿着两卡 4090 照着跑，有一点要特别注意：两张卡之间需要通过 PCIe 交换数据，如果你的主板只支持 PCIe 4.0 x8，数据传输会成为瓶颈，实际吞吐会打折。如果条件允许，尽量插在离 CPU 最近的直连槽位上。

2.4 为什么我最后没有用 Ollama

很多朋友问我，既然 Ollama 能一键拉起 GGUF 模型，为什么我还绕一圈去用 vLLM。原因主要有两个：第一，vLLM 的 OpenAI 兼容接口可以直接对接后续要讲的 WorkBuddy，不用再做一层协议转换；第二，vLLM 在长上下文和并发请求上的调度能力更稳，我接下来要测试的是连续多轮任务场景，而不仅仅是一问一答。

说到这里就自然引出了 WorkBuddy 的定位。它并不是另一个“聊天窗口”式的模型前端，更像是一个把任务拆解、编排、执行、结果复核串起来的工作流工具。你在 WorkBuddy 里给它一个目标，它会自己去规划步骤、调用模型能力、生成中间结果、再根据反馈调整下一步动作。它和本地模型之间是标准的接口关系，这也是我优先把它部署成 OpenAI 兼容服务的原因。

3. 实测 WorkBuddy 本地部署：从下载到接入自建模型的完整链路

3.1 WorkBuddy 到底解决什么问题

为了不误导读者，我先说清楚我和 WorkBuddy 第一次配合后的理解。单有模型时，你需要自己写提示词、自己管理多轮上下文、自己把结果整理成可用文件，这些重复性劳动会吃掉大量时间。而 WorkBuddy 做的事情是提供一个“任务台”：你把需求描述进去，它会生成执行计划，然后按计划调用模型、生成代码或文档，像带了一个比较听话的实习生。

在标题里提到“限时两周免费用”，我见到的是官网上登记之后会给一个试用期。真正重要的是：它支持本地模型地址作为后端，也就是你可以把它和自建的 Hy4 preview 推理服务接起来，而不必依赖云端接口。隐私敏感的数据可以在本地闭环处理，这也是我最终愿意花时间折腾整套链路的核心原因。

3.2 部署步骤：走一遍完整流程

整个本地方案，我把它拆成四个部分：

第一部分是模型服务。按上一节的 vLLM 命令启动，确认http://localhost:8000/v1/chat/completions能正常返回结果。

第二部分是 WorkBuddy 本体安装。由于不同时期提供的安装包形态可能不同，我这里不多写死命令。整体思路是：从官方渠道拿到安装包，按默认设置装好，启动后进入设置界面。

第三部分是接口对接。在 WorkBuddy 的设置页面里找到“模型服务 / Model Provider”相关配置，把 Base URL 填成http://localhost:8000/v1，模型名称填成hy4-preview，API Key 随意填一个占位符即可，因为本地服务一般不校验密钥。

第四部分是权限与路径配置。WorkBuddy 执行任务时可能需要读写本地文件、运行脚本，所以需要给工作目录设置好读写权限。这里我强烈建议单独建一个工作沙盒目录，比如~/workspaces/workbuddy-sandbox，不要直接让它去读写系统关键目录，不然某个任务写坏配置会很麻烦。

mkdir -p ~/workspaces/workbuddy-sandbox chmod 755 ~/workspaces/workbuddy-sandbox

3.3 第一次跑真实任务：写一个小网页

配置好之后，我给 WorkBuddy 布置了一个很小但完整度很高的任务：让它基于“一个团队介绍页面”的需求，生成一份带样式的静态网页。我的观察是，它会先把任务拆成“收集需求、生成 HTML、写内联样式、预览检查”几个子任务，然后逐步执行，最后真的在沙盒目录里生成了网页文件。

这一连串动作如果全靠我自己在终端里手动做，至少需要几步，但 WorkBuddy 把它归纳成可复用的工作流。第二天再做类似任务时，它明显会主动沿用上次的目录结构和命名习惯。对经常要做重复产出的场景来说，这种“工作记忆”带来的效率提升是肉眼可见的。

对于还没接触过 WorkBuddy 习惯术语的读者，可以把它理解成“本地模型前的调度员”。它不是模型本身，而是把模型的底层能力翻译成一个个可以落地执行的动作。

4. 和 770B 模型配合时的性能实测与三个容易翻车的地方

4.1 我把哪些任务丢给了它

我这一周做了几个比较有代表性的测试：

• 从几十页产品文档里提炼关键参数并生成对比表。
• 基于给定需求生成一段包含增删改查接口的后端代码。
• 对一段会议记录做结构化总结，输出待办事项清单。
• 连续写五篇风格相近的营销文案。
• 在长对话中追问同一个业务问题，观察上下文是否漂移。

最终结论比较清晰：在短文本和中等长度文本任务上，这套量化后的本地模型表现非常稳定，编码和表格类任务完成度很高。但在超长文本任务上，一旦超过我自己设定的 16K token 阈值，推理速度会明显下降，而且偶尔会出现前后细节不一致的情况。这不是模型能力不行，而是当前硬件配置下的自然瓶颈。

4.2 排错现场一：上下文长度一上去就报错

最常见的问题就是 OOM。很多从 API 时代转过来的用户习惯把 128K 甚至 200K 上下文视为默认配置，但本地部署时这件事必须谨慎。

我的解决方案，除了前文提到的降低 max-model-len，还有两个辅助手段：第一是使用 KV Cache 量化，比如 vLLM 的 kv_cache_dtype 设置为 fp8；第二是尽量把长文档切块后再做分段总结，而不是一次性全塞进上下文。MoE 模型在短 token 上的推理优势很明显，但上下文一旦拉长，访问延迟会逐渐趋近于同等级稠密模型，这一点需要平常心看待。

4.3 排错现场二：WorkBuddy 调用模型时提示格式错误

这个问题的根源通常不在 WorkBuddy，而在模型服务的接口协议不匹配。比如 vLLM 的--served-model-name设置和客户端请求里的 model 名称不一致，或者模型模板配置不对，都会返回奇怪的报错。

排查思路是先用 curl 直接测试接口，确认服务本身是通的，再去查 WorkBuddy 配置：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "hy4-preview", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 64 }'

如果 curl 正常而 WorkBuddy 仍然报错，优先检查模型名称和 Base URL 末尾的/v1是否写对。这类低级错误占据了我调试时间的四成，却最不容易被注意到。

4.4 排错现场三：多卡推理速度反而变慢

单张 4090 能跑，两张 4090 反而更慢，这听起来反直觉，但确实会发生在小模型或小并发场景下。原因是多卡并行需要拆分张量并在卡间同步，如果单批次请求很小，通信开销可能大过并行收益。

解决思路是增大并发请求数，或者把更多用户任务合并到同一个 batch 中。如果你只是自己一个人对话式使用，量级太轻，一张卡也许反而更高效；只有当你有多个任务或多人同时访问时，两卡的价值才真正体现出来。

以下是我实测不同配置的大致相对感受：

这个表格只能代表我所在环境的情况，不同量化精度和推理框架版本会有差异。但你可以记住一个判断思路：多卡部署是为了并发和长文本，不是为了单体速度。

5. 两周免费期怎么用才不亏：我的任务优先级清单

5.1 先做“能长期复用”的事

拿到了限时免费的机会，如果只是拿它来聊几次天，那确实有些浪费。我的建议是优先把它用在能沉淀成模板或工作流的任务上。WorkBuddy 可以保存技能、记忆和执行流程，趁免费期多跑几次，相当于把一个新员工的“熟悉期”免费度过了。

我自己在免费期内做的最有价值的一件事，是把常见的“需求转网页”任务整理成了一个固定流程。之后每次只要填需求文案，它就能按相同路径生成草稿，我再做微调即可直接交付。这套流程即使免费期结束，如果后续选择继续付费，还能持续复用；就算不付费，我也已经学会了整套拆解任务的方法，可以换到其他工具上复制。

5.2 拿它跑完一条完整的业务流程

很多人在试用新工具时只测试单个点，比如让模型写一段代码，或者让它总结一篇文章。但工作流工具的强项在于全链路：从接受模糊需求开始，到中间多轮纠偏，到最后生成完整交付物，这个过程才最考验工具的产品设计能力。

我在第二周专门挑了一个以往需要四个小时才能完成的脏活：把十几份零散资料整理成结构统一的周报，再按不同汇报对象生成两个版本。整个流程跑下来，中途只需要我介入两三次，大部分调整它都能自己完成。从投入产出比看，这种“完整闭环型”的试用才是最有价值的。

5.3 别忘了本地模型才是底座

工作流工具再强，它也需要底层模型来直接干活。所以我额外的建议是：把免费期看作是你“压测本地模型”的窗口期，而不是单纯地试用一个新软件。你可以在 WorkBuddy 里设置不同的底层模型，比如切换到较小的量化版本来提速，或切换到完整版来追求复杂任务质量，观察它们之间在真实业务里的效果差别。

我做了一个简单的配速对照实验，记录同一任务分别在 4bit 量化和 8bit 量化下的耗时与质量差异。结论是：日常短任务，4bit 完全够用，速度快，体验更好；只有在复杂推理或长文档任务中，8bit 的优势才体现出来。如果你没有专业卡，也不必焦虑，用 4bit 已经能做大量真实工作。

5.4 设置好提醒，别让免费期悄悄转成扣费

关于 WorkBuddy 的限时免费，“两周”这个期限我从一开始就在系统日历上标记了到期时间。很多在线服务在试用期结束后会自动转为付费订阅，为了避免麻烦，我建议你在开始试用当天就把到期提醒设好，并且在最后两天集中完成剩余验证任务。这不算什么高级技巧，但确实能帮你减少很多后续沟通成本。

这一周我得到的几个真体会

最后分享一点比较主观但可能对你有用的感受。

第一，MoE 模型的开源和本地部署确实已经到了一个很实用的阶段。过去我想在本地跑通一个千亿级参数的模型，光环境配置就能折腾一个周末，而现在量化工具链、推理框架和客户端工具已经相当成熟，大半天就能从零跑到出结果。

第二，工具层的重要性越来越高于模型本身。单纯的模型对话体验已经拉不开太大差距，真正难的是怎么把模型安插进你的工作流里。像 WorkBuddy 这样能把任务拆解、执行、复核串起来的工具，和裸模型之间的体验差距，比不同模型之间的差距更明显。

第三，免费期是很好的探索窗口。不管最后是否决定继续用，两周时间足够让你判断这个工具适不适合自己的使用习惯。比起纠结广告怎么写，拿几个真实工作场景去测试才是更务实的做法。

我现在还留着一个习惯：每次跑新任务之前，会先在 WorkBuddy 里看一遍它生成的执行计划，如果计划合理再放行，如果不合理就直接改掉。这样既保留了人的决策权，又能把重复劳动都交给工具去处理，算是这段时间试下来最顺手的一套协作节奏。