企业官网建设流程全解析

今天中午看到 Hy4 preview 发布的消息时，我正在折腾本地模型工作流到底该换哪套底座。770B 这个数字先让人一惊，但紧接着“MoE 架构”和“开源”两个关键词又让人冷静下来——这意味着模型总参数虽然庞大，推理时并不会把 770B 全部算一遍，普通团队和个人玩家也有机会把它跑起来。同一天，WorkBuddy 宣布限时两周免费，正好可以把刚发布的开源模型接进一个集成工作台里，边部署边用。这篇文章我不打算搬运官方新闻稿，只想从一个老玩家的角度，把 770B MoE 的部署逻辑、WorkBuddy 的接入方式，以及我踩过的那些坑一次讲清楚。

如果你最近在关注开源大模型，或者正好需要一个能承载日常编程、文档整理、自动化任务的 AI 工作台，这篇内容应该能帮你少走几步弯路。我会按“先懂原理再上手”的顺序来，先拆解 MoE 和 770B 意味着什么，再给出实际部署路线，然后是 WorkBuddy 的安装配置和进阶玩法，最后附上一份可以直接翻的排错清单。

1. 这个 770B MoE 开源模型，为什么值得关注

1.1 开源大模型首次把“千亿总参数”放到社区手里

在 Hy4 preview 之前，开源圈子里能稳定下载的模型，规模大多停在 7B、14B、70B 这个区间。哪怕后来出现了一些更大的 Dense 模型，普通玩家也只能看着参数文档干瞪眼——不是不想跑，而是包含全部参数的前向计算太吃算力，一张 80GB 的 A100/H100 都未必放得下推理态。

Hy4 preview 走的是 MoE 路线。MoE 全称 Mixture of Experts，中文一般叫“混合专家”，核心思想是把一个大模型拆成多个子网络，每个子网络只处理部分任务或输入。真正跑推理时，输入会给每个 token 分发给少数几个专家网络，而不是把所有专家全部计算一遍。所以“770B”这个总参数量只是静态文件里存了多少参数，动态执行时只激活其中一小部分，这跟传统 Dense 模型的“参数即计算量”逻辑有本质区别。

这里要特别说明一句：我不会替官方假想准确的专家数量、激活参数之类细节，因为不同 MoE 模型配置差异很大，有的 8 个专家里选 2 个，有的是 256 个专家里选 8 个。但你可以用已有的开源 MoE 模型做参照：像 DeepSeek-V3 总参数 671B，激活参数只有 37B 左右，日常推理时用的显存和算力比同规模 Dense 模型少一个数量级，效果却接近更大参数量的 Dense 模型。Hy4 preview 的 770B 应该也是这个思路，具体以官方模型卡为准。

1.2 “总参数大、激活参数小”带来的连锁反应

MoE 设计的直接好处，是效果和成本解耦。总参数变大，意味着模型有能力在预训练阶段“记住”更多知识；激活参数控制得住，意味着每次推理的浮点运算量不会跟着总参数一起膨胀。用大白话讲，就像一家公司总共有 770 名员工，但处理一个具体任务时，只有 30 到 40 人真正上手，其他人在后台待命。前端看到的响应速度取决于上手的人数，而不是全公司人数。

这个特性让 770B 这样的模型具备两个看起来很矛盾的优势：一是“能打的参数天花板足够高”，在复杂推理、长文本理解、代码生成这类任务上更容易逼近闭源头部模型；二是“实际消耗可控”，只要推理框架和量化方案选得合适，4 到 8 卡的服务器就能把这套模型架起来，不必上到 H100 集群。这也是为什么我在看到 770B 时没有直接关掉页面，而是愿意花时间研究部署路线。

当然，总参数量大也不是没代价。哪怕推理时只激活一部分专家，模型文件本身仍然要完整加载到显存或内存里。这是 MoE 模型部署时最值得先算清楚的一笔账，后面我会专门用一章节讲显存估算。

为了帮助理解，我把 Dense 和 MoE 的特征差异整理成了一个对比表，这也是我做技术选型时最常用的一张表：

1.3 谁适合第一时间上手

如果你符合下面任意一种情况，我建议你把 Hy4 preview 列入试用清单：

• 你在做开源模型选型，想比较 770B 级 MoE 和 70B 级 Dense 模型的效果差距。
• 你手头有多张消费级显卡或一台中高端服务器，想跑一个“能打”的本地大模型。
• 你在用 WorkBuddy 这类 AI 工作台，希望把背后的模型换成自己可控的开源模型，降低单次调用成本。
• 你想学习 MoE 架构的推理、量化和服务化部署，需要一个按真实项目练手的素材。

对单纯聊天场景，770B 可能有点大材小用；对生产级任务，比如代码仓库分析、长文档总结、自动化流程调度，这类大参数模型反而值得认真测一轮。

2. MoE 架构：白话拆解大模型的“分工合作”

2.1 什么是 MoE，路由机制怎么工作

要理解 MoE，可以先忘掉“神经网络”这几个字。你只要想象一家公司：

公司有 770 名员工，不同员工擅长不同领域：有人擅长写文案，有人擅长写代码，有人擅长财务分析。公司前台（Router，路由器）收到一个新任务时，先快速判断任务属于什么类型，然后只把任务派给最合适的 20 名员工，其他员工继续休息或者干别的活。这 20 名员工处理完后，把结果汇总给前台，前台再返回出去。

在 MoE 模型里，这些“员工”就是专家网络（Expert），大模型中的前馈网络层被复制成多份，每份参数不同、职责偏向也不同。Router 是一个轻量级网络，会针对 token 的输出向量计算一个分数分布，然后选出分数最高的 Top-K 个专家参与这次前向计算。所有被选中的专家输出会加权求和，得到一个统一的层输出。

这里有个容易误解的点：token 和专家不是一对一关系。一个 token 可能被分给 2 到 8 个专家，同一句话里的不同 token 也会被分给不同专家。这也是 MoE 模型训练中最考验工程的地方——如果 Router 分配不均衡，某些专家会被疯狂调用而其他专家被闲置，训练效率和最终效果都会变差。所以现代 MoE 模型在训练时都会加入负载均衡损失（load balancing loss）之类的约束。

2.2 稀疏激活为什么能省钱

传统 Dense 模型每一层都要对所有参数做矩阵乘法，所以“计算量约等于参数量”。MoE 模型虽然也把所有专家参数加载到显存里，但每个 token 只经过少数专家，所以真正参与的矩阵乘法的参数量大幅下降。

通常我们用激活参数量（activated parameters）来衡量每次推理的算力需求。举例来说，一个总参数 770B、激活参数约 40B 的 MoE 模型，单 token 推理的计算量大概相当于一个 40B 的 Dense 模型。与此同时，这个 MoE 模型的“知识容量”却接近总参数 770B 的 Dense 模型。也就是说，你用一个中型模型的算力成本，拿到了大型模型的效果上限。

这就是“稀疏激活”的价值所在。稀疏激活和 Dropout 那种训练期随机丢弃不同，MoE 的结构性稀疏是写在网络结构里的：专家参数是独立的，路由选择是动态的。每次前向计算，只有一部分参数路径被真正走过。

2.3 MoE 落地的三个关键门槛

不过，MoE 也不是完全没有代价。我自己在部署其他 MoE 模型时总结出三个绕不开的门槛：

第一是显存。总参数再大也依然要全部放进显存或内存，不像 Dense 模型可以抠抠搜搜地把一层层加载到 CPU。想跑 770B，一张卡就别想了，要么多卡并行，要么量化到 INT4 甚至更低位宽，并接受一定的效果折损。

第二是推理框架的适配。MoE 的专家分发逻辑和 Dense 模型不同，不是所有推理框架都支持。老牌的 Transformers 库虽然能加载，但速度不理想。更推荐 vLLM、SGLang、TensorRT-LLM 这类对 MoE 做过专项优化的框架。

第三是显存带宽瓶颈。MoE 模型每次推理只需要少量算力，但要把相关专家参数从显存里搬到计算单元，这个过程非常吃显存带宽。多卡并行时，还要考虑跨卡通信开销。这也是为什么 MoE 模型的吞吐不一定比同激活参数的 Dense 模型高很多，但它的优势在于同样的模型容量下模型质量更高。

3. 开源模型拿到手，怎么部署才不翻车

3.1 先算清这笔显存账，避免下完模型才发现跑不动

部署一个 770B MoE 模型，第一件事不是敲命令，是算显存。我通常用一个非常简单的公式：

模型文件大小约等于：参数量 × 每个参数占用的字节数。

• 如果加载成 FP16/BF16，每个参数占 2 字节，770B 需要 1.54TB 存储空间。
• 如果量化成 INT8，每个参数占 1 字节，需要大约 770GB。
• 如果量化成 INT4，每个参数占 0.5 字节，需要大约 385GB。
• 如果继续压低到 3bit、2bit，会进一步减小，但效果损失和部署复杂度也会上升。

这还只是权重本身的静态占用。推理时还要算上 KV Cache、激活值、临时缓冲等动态占用，通常会在权重基础上再加 10% 到 30%。如果你用 8 张 80GB 的显卡，BF16 加动态占用应该能塞进去；如果用 4 张 80GB 的显卡，大概率只能跑 INT4 量化版本，而且上下文长度不能开太大。

这里我强烈建议你在动手下载之前先做一个估算：先把显卡总显存写下来，再减掉系统预留，然后对照模型格式的每字节占用，看差多少。如果差距很大，就先走 API 或者云端推理，不要硬刚本地。

3.2 不同硬件条件下的部署路线对比

我把常见的部署路线整理成一张表，方便你对号入座：

表里说的“社区量化版”是指后续可能出现的 GGUF/AWQ/GPTQ 等格式。新模型刚开源时官方一般先放完整的 BF16 权重，量化版本需要等社区做校准和验证，通常几天内就会有。如果你等不及，也可以自己用 AutoAWQ 或 llama.cpp 的量化工具做转换，但量化后一定要跑一遍验证集，确认输出没有明显劣化。

3.3 本地部署实操示例

下面给一份通用到“换掉模型名就能用”的部署示例。我先按 vLLM 来，因为 vLLM 对 MoE 和长并发的支持最稳定，也能开出 OpenAI 兼容 API，方便后面 WorkBuddy 直接接入。

第一步，下载权重。建议先设好镜像环境变量，不然 700 多 GB 的文件下载能拖到天荒地老。这里不展开讲具体镜像用法，但原则是：模型文件越大，越要先解决好网络问题。

# 安装依赖 pip install -U vllm huggingface_hub # 下载模型，MODEL_ID 需要替换为官方仓库 ID huggingface-cli download <MODEL_ID> --local-dir ./models/hy4-preview

第二步，用 vLLM 启动一个 OpenAI 兼容服务。下面是简化示例：

# serve_hy4.py from vllm import LLM, SamplingParams model_path = "./models/hy4-preview" llm = LLM( model=model_path, tensor_parallel_size=4, # 用几块卡就填几 gpu_memory_utilization=0.9, max_model_len=8192, quantization="awq", # 如果是量化版，在这里声明格式；BF16 权重要去掉这行 ) params = SamplingParams(temperature=0.7, top_p=0.9, max_tokens=1024) outputs = llm.generate(["请用一段话解释什么是 MoE 模型"], params) print(outputs[0].outputs[0].text)

如果走命令行，可以直接用 vLLM 的服务入口：

vllm serve <MODEL_ID> \ --tensor-parallel-size 4 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

服务起来后会监听 8000 端口，并提供一个/v1/chat/completions接口。接下来无论你是写 Python 代码调用，还是在 WorkBuddy 里配一个自定义模型，都把它当成一个本地的 OpenAI 兼容服务来使用就行。

如果显存实在紧张，也可以等社区放出 GGUF 量化版，然后用 Ollama 或 llama.cpp 跑。Ollama 的好处是一条命令就能拉起服务，缺点是长上下文和并发性能比不上 vLLM。我个人的倾向是：先看社区是否出了成熟量化版，没有就用 vLLM 自己转，尽量避免拿 Transformers 硬扛。

4. WorkBuddy 是什么，这两周免费怎么用

4.1 它和你平时用的聊天机器人不是一回事

聊完模型部署，回到 WorkBuddy。从目前公开的信息和热词来看，WorkBuddy 更像一个“AI 工作台”而不是单纯的聊天窗口。它的定位是把你日常会用到的大模型能力，收纳到一个能做编程协作、任务管理、文档处理的集成环境里，并且支持自定义指令和技能包扩展。

你可以把它理解成“带装修的 AI 前台”：模型是后台的大脑，WorkBuddy 是前台的工作台。它本身不产出智能，但它负责把模型能力接到你的工作流里——比如你选中一段代码，让它解释或者补 bug；你丢进去一个文件夹，让它做技术方案；你把一段零散笔记扔进去，让它整理成结构化文档。这类操作如果直接在终端里用脚本调 API，也不是不行，但 WorkBuddy 把交互界面、上下文管理和技能调度都做进了产品里，效率高不少。

关于免费这两周，我的建议是：别只把它当试用，要直接当主力用。两周时间足够你把一个真实项目里的几个核心场景跑顺，也能逼你把自定义指令调教到顺手。

4.2 下载、安装和首次配置

WorkBuddy 的安装包一般会提供 Windows、macOS 和 Linux 三个版本。Windows 和 macOS 用户下载后正常安装即可；如果你平时用 Linux 服务器，需要在无图形界面环境下跑，记得选择服务端模式。

首次启动后，它会引导你完成三件事：

1. 登录账号。如果有限时免费活动，注册本身应该就能领到额度；具体规则要看官网说明，我这里不代替官方确认。
2. 配置模型。WorkBuddy 一般支持云厂商 API 和自定义模型两种接入方式。云厂商 API 适合不想折腾的用户，自定义模型适合接本地部署的开源模型。
3. 创建工作区。选择一个文件夹或者项目作为工作目录，WorkBuddy 就能读取项目上下文，这也是它和普通聊天窗口拉开差距的地方。

配置模型这一块，我重点说一下自定义模型怎么填。如果你已经用 vLLM 把 Hy4 的推理服务跑起来了，那 WorkBuddy 里只需要设置：

• API Base URL：http://127.0.0.1:8000/v1
• API Key：本地服务一般不做校验，随便填一个占位符就行
• 模型名称：填写你启动服务时用的模型名或路径别名

保存后，WorkBuddy 里的对话就会走你本地的开源模型。这样既不产生 API 费用，数据也不用出本机。

4.3 两周免费的正确打开方式

免费期最怕的就是“到处点点看看，然后时间就没了”。我建议你按这三步来安排：

第一步，先把基础链路跑通。注册、接入一个模型、在一个真实的项目目录里发起一次带上下文的对话，确保整个链路没有断点。

第二步，做一次真实任务。比如把你手头一个不太紧急但很耗时的任务交给 WorkBuddy：整理一份接口文档、批量改写一段脚本、生成一堆测试用例。真实任务才能暴露问题，比如上下文不够长、输出长度限制、自定义指令没生效等等。

第三步，逐个打磨技能包。下一篇我会专门讲 Skill 玩法，这里先记住一个原则：技能包是把“模型会做”变成“我的工作台真的会做”的关键。免费期过了，哪怕 WorkBuddy 需要付费，你调试好的技能包和工作流也可以迁移到其他工具上，并不吃亏。

5. WorkBuddy 进阶玩法：自定义指令、Skill 与本地模型接入

5.1 自定义指令：把你的需求变成模板

WorkBuddy 的自定义指令，本质上就是系统提示词（system prompt）的产物式管理。对普通用户来说，最大的价值是“一次设定，反复使用”。

我举一个真实场景：你经常让 AI 评审代码，每次都要重新解释项目背景、编码规范、输出格式，又累又容易漏。你可以写一个“代码评审员”指令模板：

你是一名资深代码评审员。项目背景：Java 微服务项目，团队遵循 Clean Code 原则。 请按以下要求评审我发来的代码： 1. 先指出逻辑错误和安全隐患。 2. 再提出可读性和性能改进建议。 3. 每条建议标注优先级（高/中/低）。 4. 最后给出重构后的示例代码。

保存成自定义指令后，每次需要评审代码，直接选中代码并调用这条指令即可。它会自动把这段模板拼到对话上下文中，节省大量重复描述时间。

自定义指令的另一个用途是控制输出风格。如果你需要让 AI 输出中文技术文档、Markdown 格式、带表格，可以在指令里声明清楚。我见过很多用户抱怨“模型输出格式总不对”，其实往往不是模型不行，而是没有把约束写进指令里。

5.2 Skill 技能包：把单次能力变成可复用工具

Skill 可以理解为一个“带输入输出约定的完整技能包”，它比自定义指令更进一步：Skill 不仅包含提示词，还可以附带脚本、工具调用方式、参数定义等，相当于把一个小型自动化任务封装起来。

比如你可以做一个“周报生成器”技能：输入是这一周的 git 提交记录或日志文件，输出是一份结构化的周报。技能内部会先调用命令读取日志，再调用模型总结，最后按模板生成 Markdown 周报。这种能力从本质上说是“工作流自动化”，而 WorkBuddy 只是把这些环节组合在了一起。

在当前热词里反复出现的 “WorkBuddy skill”，我猜测官方后续会提供技能市场或者示例库。哪怕目前还没有太多成品技能，你也完全可以自己写。写 Skill 的时候，我建议从频率高、步骤固定的任务入手，不要一上来就做很复杂的编排。

一个简单的 Skill 配置大概长这样：

{ "name": "weekly-report", "description": "根据 git 提交记录生成周报", "inputs": [ { "name": "since", "description": "起始日期，例如 2025-01-01", "required": false } ], "steps": [ "git log --since={since} --pretty=format:%s", "将提交记录按模块分组，总结为结构化周报", "输出 Markdown 格式，包含本周完成、待推进、风险三部分" ] }

这个配置只是示例，真实 Skill 的字段名要看 WorkBuddy 的文档规范，但思路是通用的：先定义输入参数，再定义执行步骤，最后固定输出格式。把常用任务沉淀成 Skill 之后，你相当于给自己搭了一个“重复劳动自动机”，这才是 WorkBuddy 这类工作台真正的效率来源。

5.3 把本地模型和云端模型混着用

真正用起来之后，你会发现本地模型和云端模型各有优势。本地模型的优势是隐私、可控、无调用费；云端模型的优势是性能更强、上下文更长、维护成本低。

WorkBuddy 一般支持同时配置多家模型。我的推荐用法是：常规聊天、代码补全、轻度总结，走本地 MoE 模型；长文档分析、复杂推理、一次性需要高质量输出的任务，走云端模型。切换模型不需要重新部署，只需要在会话里换一个模型选项即可。

如果你是 Linux 服务端部署，还需要注意两点：一是确保本地模型服务的防火墙只对可信网段开放，不要暴露到公网；二是如果 WorkBuddy 和模型服务不在同一台机器，API Base URL 里的 127.0.0.1 要改成模型服务所在机器的内网 IP。这两个细节看似不起眼，但能省掉不少排查时间。

6. 常见问题与排查技巧实录

6.1 模型下载和显存相关的坑

问题一：模型文件下载太慢，甚至中断。上千 GB 的文件用单线程下载是非常不明智的。建议用支持断点续传的工具，下载前配置好镜像环境变量；下载完成后计算一下文件哈希，防止文件损坏。

问题二：推理启动时报 CUDA out of memory。先检查有没有把其他模型或者进程占用的显存清掉；然后看gpu_memory_utilization是否设置得过高，一般 0.85 到 0.9 比较稳妥；最后还是不行，只能降级到更低位宽的量化版，或者减小max_model_len。上下文长度对显存的影响非常大，从 8192 降到 4096 往往能救回来。

问题三：量化后输出质量明显下降。如果量化版本效果太差，可以换一种量化方法试试，比如把 GPTQ 换成 AWQ，或者从 4bit 改回 8bit；也可以只量化部分层，保留某些关键层为高精度。这些都需要花时间做验证，不能只看困惑度指标。

6.2 WorkBuddy 连接不上本地模型

这是我在实践中遇到最多的问题。WorkBuddy 侧报错，但curl直接请求模型服务又正常，九成是 base URL 填错了。注意 OpenAI 兼容服务的地址一般要写全，包括/v1这个路径；有些模型服务还要求 API Key 不能为空，随便填一个即可。

另一个常见原因是模型名称对不上。WorkBuddy 里填写的模型名必须和推理服务返回的模型 ID 一致，否则模型服务会返回 404。可以在浏览器里访问/v1/models接口，查一下服务端实际注册的模型 ID，再照抄到 WorkBuddy 里。

6.3 自定义指令“不生效”怎么办

自定义指令不生效，绝大多数情况不是软件 bug，而是上下文被后续聊天覆盖了。你可以试试这几个办法：把指令写在项目级配置里，确保每次会话都加载；指令本身不要太长，关键要求放在前面；在对话框里明确说一句“请遵守我的代码评审指令”之类的触发词，帮助模型把注意力拉回指令上。

另外，不同的模型对指令的遵循能力差异很大。某些小模型可能把指令当普通文本忽略掉，这时你应该优先检查模型选择，而不是改指令内容。770B 级别的 MoE 模型在指令遵循上通常会有明显优势，这也是我建议把 Hy4 这类大模型接进 WorkBuddy 的原因之一。

6.4 安全和隐私：别把敏感数据随便暴露

本地部署最大的价值之一就是数据不出本机。但如果你把本地模型服务端口暴露在公网，或者把 API Key 写进了日志，那“本地”也就失去了意义。给三个最基础的建议：

• 本地模型服务只监听内网地址，不要设置为 0.0.0.0，除非你有明确的外网访问需求。
• WorkBuddy 的配置文件和会话记录里可能包含 API Key，定期检查.gitignore，不要把配置文件提交到公开仓库。
• 涉及个人隐私、公司内部数据或未公开代码的任务，尽量走本地模型；云端模型虽然方便，但要留意服务商的隐私协议。

我在实际部署中还有一个小习惯：新模型起来后，先用一组完全无敏感的测试问题跑一遍，确认输出格式和速度都正常，再开始接正式任务。这个习惯能避免在排查问题时把真实业务数据送去未知接口，也算是一种基本的风险管理。

最后说点个人的体会。很多人看到 770B 的第一反应是“这么大怎么跑”，但 MoE 让我重新认识了一件事：在开源模型世界，参数数量不再是唯一的门槛，部署策略和工具链的成熟度反而更重要。Hy4 preview 的意义，不只是又多了一个大模型，而是把“千亿总参数、可控激活参数”的组合第一次摆到了普通开发者的桌面上。WorkBuddy 这两周免费期，恰好是一场低成本的压力测试——你可以用真实项目去验证，一个可本地部署的 MoE 模型，能不能替代部分云端主力模型。我的建议是别只看测评报告，自己上手跑一圈，跑通之后再决定要不要长期用。这种“先干活，再评判”的方式，往往比刷各种数据更可靠。