企业官网建设流程全解析

Hy4 preview 发布那晚，我正在整理一个开源项目的依赖，微信群里突然有人丢来消息：“770B 参数的 MoE 开源了，你敢信？”我点开链接确认之后，又看到 WorkBuddy 同步放出限时两周免费的消息。说实话，这两个消息放在一起，比单纯一个模型发布更让我在意——模型开源是给了你一台发动机，WorkBuddy 免费是给了你一套上路的机会。作为一个经常折腾本地大模型的开发者，我用了三天时间做了一次比较完整的实测：下载权重、部署推理服务、接入 WorkBuddy、跑真实任务。这篇文章不聊官方通稿里的漂亮话，只把我验证过的东西、踩过的坑、以及限时免费期里最值得做的事，完整写出来。

1. 770B MoE 不是“更大的模型”，而是另一种路由思路

1.1 先搞清总参数和激活参数的区别

MoE 全称 Mixture of Experts，翻译过来是“混合专家”。很多人第一次接触这个概念时，会被“770B 总参数”吓到，第一反应是“这得多少张 80G 显卡才能跑起来”。实际上这里藏着一个很关键的区别：总参数和激活参数是两回事。

你可以把 MoE 模型想象成一家大型综合医院。普通任务进来时，前台会根据症状分诊，只让对应科室的少数专家处理；而不是把全院的医生都叫到一个病房里会诊。具体到模型上，总参数 770B 指的是所有专家网络加起来的规模，这些权重在加载时一个都不能少。但在生成每个 token 的过程中，真正参与计算的往往只是被路由机制选中的少数专家，激活参数远小于总参数。

所以一个 770B 总参数的 MoE 模型，在推理时并不会真的让你承担 770B 稠密模型那么夸张的计算量，但存储体积依然是 770B 的体量。这个区别非常重要，因为它直接影响你后面怎么做量化、选什么框架、买多少显存。我见过不少人在这一步搞混，以为 MoE 参数大但省内存，结果下载完发现自己根本加载不了。

1.2 路由机制是怎么工作的

MoE 的每一次前向计算都依赖路由器。模型内部的 FFN 层不再是一个整体，而是被拆成多个并行的专家子网络。每个 token 进来之后，路由器会对所有专家计算一个匹配分数，然后选出得分最高的 k 个专家来加工这个 token，常见设置是 Top-2。

这里的“分诊”过程本身也会消耗计算资源。尤其是当专家数量比较多、路由判断复杂时，前期的 prefill 阶段会产生额外开销。这也是为什么 MoE 模型的首 token 延迟通常会比同体量的稠密模型略高一些。路由质量直接决定了模型能不能把合适的知识分配给合适的专家，训练时通常还会加入负载均衡约束，防止少数专家被反复调用、其他专家一直闲置。

我在实测 Hy4 preview 时能明显感觉到这种“分诊”带来的特性：面对复杂代码任务时，它像是一个科室齐全的大医院，能给出很完整的分析链；但如果只是问一句“今天天气怎么样”，它会显得有点“兴师动众”，基础语义模型往往都能秒回的问题，在 MoE 上反而多了一些延迟。这不是缺陷，而是这类架构本身的特点。

1.3 这种架构适合处理什么任务

我把 Hy4 preview 放在几类真实任务上跑了一遍，结论还是比较清晰的。代码生成和补全这类需要较强上下文理解的任务，它表现明显比同参数量级的稠密模型更稳定，尤其是面对跨文件、长依赖的项目代码时，能保持较长上下文的连贯性。

多步推理任务也是它的强项。我试过让它分析一份包含多组数据的业务报表，再根据多个条件推导结论，它在中间步骤上的出错率比普通模型低不少。相比之下，简单问答、闲聊、翻译这类轻量任务，用 770B 级别的 MoE 有点浪费，不管是响应速度还是资源消耗都不划算。

所以如果你打算尝试 Hy4 preview，最好优先把它放到“重任务”上，比如复杂文档归纳、代码审查、工程方案设计。它适合做团队里的“专家型助手”，而不是所有请求都往这里丢。

2. 开源的意义：你可以把 Hy4 preview 当成“发动机”而不是“整车”

2.1 拿权重的第一件事是看授权

标题里写着“开源”，不代表你拿到权重后就能随便用。不同项目的开源力度差别很大，有的允许商用，有的只能做学术研究，有的要求分发时保留版权说明，有的对衍生模型的命名和再发布有额外限制。

所以不管你从哪个渠道下载 Hy4 preview，第一步永远是打开授权文件，把允许范围看清楚。尤其要注意企业场景，别因为模型权重可以下载就默认没问题。如果你所在的公司有法务，最好让法务过一遍再决定能不能接入生产环境。开源不等于无限制，这是所有大模型项目都需要重视的地方。

我自己下载权重之后做的第一件事，就是把授权里的关键词都扫了一遍，确认允许本地部署和二次开发之后，才开始配置环境。这一步看似繁琐，但能避免后续很多麻烦。

2.2 开源能带来什么：私有化、量化、微调、社区生态

开源最直接的价值是你有了自主权。数据可以不出内网，模型可以在自己的服务器上运行，你可以针对垂直领域做微调，可以把权重量化到更小的体积，还可以把它接入 WorkBuddy 这类工作流工具，变成团队内部的智能体后端。这些都是纯 API 方案给不了的。

另一个容易被忽略的价值是社区生态。模型开源之后，会有人持续修 bug、做框架适配、写教程，甚至有人训练出更高质量的量化版本。这次 WorkBuddy 限时免费和 Hy4 preview 发布放在一起，本质上也是在为这个生态加温。发动机再强，没有传动轴、车架和方向盘，也只是一台裸机。模型权重是发动机，WorkBuddy 这类工具就是车架和方向盘。

2.3 开源与调用 API 的取舍

如果你只是想快速看看这个模型效果怎么样，不一定非要下载权重自己部署。直接调用 API 往往是最快的路径，不需要准备多卡服务器，也不用折腾推理框架。

但 API 的问题也很明显：数据要过外网，长上下文场景下费用会比较高，而且你无法对模型做定制化修改。开源+本地部署则适合以下情况：你的数据敏感，必须在私有环境处理；你需要高频调用，长期算下来 API 费用不划算；你想在模型基础上做微调或量化实验。

我的建议是两条腿走路：先用 API 或者云租卡快速验证效果，确认这个模型确实适合你的任务之后，再决定要不要投入资源本地部署。不要一上来就跑到线下服务器上折腾，那样试错成本太高。

3. WorkBuddy 限时免费用：从功能到白嫖的完整操作

3.1 先弄清楚 WorkBuddy 是什么

WorkBuddy 不是一个模型，而是一个智能体工作平台。你可以把它理解成“会调用工具的个人助理”：给它一个目标，它会拆解任务、调用代码解释器、读写文件、执行命令，最后把结果整理成可交付的内容。

它和模型的关系是上游和下游的关系。模型负责“想”，WorkBuddy 负责“做”。比如你可以让 WorkBuddy 去扫描一个代码仓库，找出所有 TODO 注释并归类，再生成一份整改清单。这个过程里，底层推理可以交给 Hy4 preview 这类模型，任务拆解和工具调用则由 WorkBuddy 完成。

WorkBuddy 支持自定义 skill、自定义指令和插件机制，也能接入本地模型后端。这意味着你可以用 Hy4 preview 当“大脑”，用 WorkBuddy 当“手和脚”，组合出一套适合自己工作流的自动化工具链。这也是这次限时免费活动最值得玩的地方。

3.2 免费期内应该立刻做掉的几件事

官方限免时间是发布日起两周，如果你看到这篇文章时发布已经过去好几天，那剩余时间可能不多了。按优先级来看，我建议先做这六件事：

1. 注册账号并确认免费额度已经生效，别用了半天才发现还在游客模式。
2. 把 WorkBuddy 装到本地环境，特别是 Linux 服务器，这样可以不受网页版限制。
3. 创建一个自定义 skill。不要用官方示例，写一个和你工作相关的，比如“自动生成项目周报”或“检查依赖版本冲突”。
4. 接入本地模型后端。不一定非得上 Hy4，先接一个 OpenAI 兼容接口，确认调用链路是通的。
5. 跑一个真实任务。尽量选有实际产出的活，比如整理一份接口文档、重构一段业务代码，而不是只跑 hello world。
6. 把插件和自定义指令的配置整理成文件备份，方便免费期结束后迁移。

这几件事做完，你才算真正体验到了 WorkBuddy 的核心能力，而不是停留在功能浏览层面。

3.3 免费期结束前要做的准备

限时免费最容易被忽略的是“结束时”的处理。我建议大家提前两天检查一下账号的订阅状态，确认是否有自动续费设置。如果免费期结束后你不想付费，就提前把自动续费关掉，避免产生意外扣费。

另外，像 skill、自定义指令、环境配置这些内容，尽量导出保存。有些平台免费账号和付费账号的导出权限不同，等账号降级之后再导出可能反而麻烦。把常用配置备份好，之后即使不续费，也能用开源工具自己搭一套类似流程。

4. 本地部署 Hy4 的可复现路径

4.1 显存估算：MoE 省计算，但不省存储

很多人以为 MoE 模型激活参数少，所以显存需求也不会太高。这是最大的误解。你要清楚一点：虽然推理时只有少数专家被激活，但所有专家的权重都必须加载到内存里，否则路由器就没法在它们之间做选择。

以一个 770B 总参数的模型为例，如果做 4bit 量化，每个参数大约占 0.5 字节，那么权重体积大约是 770 * 0.5 = 385GB。这里还没算 KV cache、激活值和推理框架的额外开销。如果想跑得舒服，单机 8 卡 80GB 显存是起步配置。如果做 8bit 量化，体积会接近 770GB，8 卡 80GB 也不够装。

所以我的建议是：想本地跑 Hy4 preview，优先考虑 4bit 量化，并且用多卡方案。个人电脑上想跑完整版几乎不现实，但如果你是 Mac 用户，可以试试大统一内存设备，配合 Metal 系列框架，也能获得不错的体验。如果只是短期尝鲜，直接租一个 8 卡节点按小时付费更划算。

4.2 推理框架选择：不同阶段用不同工具

本地部署大模型，选框架是个关键决策。我在跑 Hy4 preview 的过程中对比了几个主流框架，各自的优缺点都很明显。如果你要长期做生产级服务，vLLM 是最稳妥的选择，它的吞吐量高，对 PagedAttention 的优化比较成熟，但配置相对复杂，显存占用也偏高。

如果你更看重长上下文场景下的前缀复用，SGLang 值得关注。它用 RadixAttention 处理多轮对话和 Agent 类任务时优势比较大，但版本更新快，切换版本时容易遇到兼容问题。

如果你想先在单机环境快速看效果，llama.cpp 或者基于它的工具最容易上手。量化支持好，单机友好，但面对 770B 这种体量的大模型，加载速度和并发吞吐都跟不上专用框架。我的选择是：快速验证用 llama.cpp，正式跑任务用 vLLM。

4.3 一个可用的部署命令示例

这里给出一份我实际用过的 vLLM 启动命令，方便你快速起一个 OpenAI 兼容服务：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/hy4-preview \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --quantization awq

参数含义说一下：--tensor-parallel-size 8表示在 8 卡之间做张量并行；--max-model-len控制最大上下文长度，如果显存紧张可以适当调小；--gpu-memory-utilization 0.92给每张卡留出一点余量，避免碎片导致 OOM；--quantization awq表示加载 AWQ 量化权重，如果官方权重是 BF16，就不用加这个参数。

服务起来之后，先用 curl 确认接口可用：

curl http://localhost:8000/v1/models

然后 WorkBuddy 里的模型后端配置直接填http://localhost:8000/v1就行。这里有个小坑：有些本地服务的 model 名默认是hy4，有些是hy4-preview，而 WorkBuddy 里填错了名字就会 404。先 curl 确认模型 id，再填入配置，能省去很多排查时间。

5. 我实测之后最想提醒的四个坑

5.1 首 token 慢不要先怪模型

用 MoE 模型做问答时，首 token 延迟高是很正常的事。因为 prefill 阶段不仅要处理长上下文，还要让路由器对每个 token 做专家选择，计算量比稠密模型更大。尤其当你开着 WorkBuddy 这类工具做多轮 Agent 任务时，每一轮都要重新处理很长的一段历史消息，首 token 延迟会被放大。

想优化这个问题，最有效的办法是开启 vLLM 的 prefix caching，让重复的前缀不再重复计算。另外不要为了“保险”把 max-model-len 设得过大，预留过大的 KV cache 反而会挤压其他计算资源，让首 token 更慢。先调小，再按需求逐步往上加。

5.2 显存碎片比想象中严重

多卡跑大模型时，即使理论显存算下来够用，跑一段时间后也可能突然报显存不足。这个问题很多时候不是模型太大，而是 KV cache 碎片化。vLLM 虽然有 PagedAttention 管理显存，但长时间运行、多轮对话、长序列请求交替出现时，碎片依然会积累。

我的经验是：先把gpu-memory-utilization调低一点，比如从 0.95 调到 0.90，给显存管理留出缓冲。如果服务是长跑的，可以设置定时重启，或者用监控脚本在显存占用超过阈值时自动重启服务。别等到 OOM 了再救，那是典型的被动挨打。

5.3 本地模型接 WorkBuddy 时，先确认接口字段兼容

WorkBuddy 通常走 OpenAI 兼容接口，所以大多数接入问题不是协议问题，而是字段问题。最常踩的坑是模型名对不上。本地服务可能注册了hy4-preview，但 WorkBuddy 配置里默认填的是hy4，调用时一直 404。

所以接入前，一定要先请求一下/v1/models接口，看看实际返回的模型 id 是什么。这比你在配置界面里反复试错要快得多。另外，如果本地服务做了速率限制或并发限制，WorkBuddy 可能会报超时，这时候你需要检查的是服务端日志，而不是 WorkBuddy 配置。

5.4 别为了“本地”而本地

最后一个坑，也是我最想强调的：不要为了满足“本地部署”的执念，而把一个好好的模型压到 2bit 甚至更低精度。量化越低，模型能力损失越大，尤其是复杂推理和代码生成任务，效果可能变得没法看。

如果本地硬件条件不够，不如直接用官方 API 或者租云端 GPU。开源的真正价值在于给你选择权，而不是逼你把所有事情都扛在自己机器上。WorkBuddy 支持混合后端，你完全可以本地跑一个 70B 量级的小模型处理日常轻量任务，把 Hy4 这种 770B 级别的大家伙留给云端 API。这样既省钱，又能保证复杂任务的输出质量。

6. 如果你只有一周时间，我建议这样做

6.1 前三天：先把模型跑通

第一天用来下载权重、确认授权、准备环境。第二天部署推理框架，优先用 vLLM 加载 4bit 量化权重，把服务跑起来。第三天用 curl 和几个典型任务测试接口，确认基础调用没问题。

这段时间不要急着接 WorkBuddy，也不要调优化参数。先把最核心的通路打通，后面所有问题都好定位。模型服务起不来，其他工具都是空转。

6.2 中间两天：把 WorkBuddy 接入真实任务

第四天安装 WorkBuddy，配置 OpenAI 兼容后端，确认模型名、接口地址、API Key 都对得上。第五天创建一个自定义 skill，用你自己项目的真实需求来写。比如让 WorkBuddy 自动扫描仓库里未使用的 import，或者根据 commit 记录自动生成发布说明。

真实任务才能暴露问题。官方示例再怎么跑通，都不如一个带业务细节的需求来得有价值。

6.3 最后两天：总结经验并做备份

第六天把这几天的配置、命令、踩坑记录整理成文档。第七天导出 WorkBuddy 的自定义指令、skill 和插件配置，同时确认账号免费期之后的订阅状态，避免产生意外费用。

最后说一句实在话：Hy4 preview 的发布和 WorkBuddy 的限免，本质上是把“大模型能力”和“落地工具”拼到了一起。技术圈年年有热点，但真正能留下价值的，是你在这段时间跑通了哪些真实任务、沉淀了哪些可复用流程。免费期会结束，模型会更新，但你亲手搭起来的这套工作流，才是这次经历里最值得带走的东西。