企业官网建设流程全解析

Hy4 preview 发布的消息出来时，我刚从一场部署排障里脱身，群里已经有人把“770B”“MoE”“开源”几个词反复刷屏。说实话，这两年开源大模型发布越来越密，能让我停下来多看两眼的，通常不是参数数字本身，而是参数结构和发布节奏背后透出的产品意图。这次 Hy4 preview 和 WorkBuddy 限时免费几乎是前后脚出现的：一个在模型层做了新的开源尺度，一个在应用层用免费窗口把门槛降到最低。对正在做 AI 落地、或者还在犹豫要不要接大模型的团队来说，这算是一次值得拆解的典型事件。

接下来的内容我会按自己的习惯拆成五块：先看这次发布释放的信号，再讲清 MoE 架构的核心原理，接着给出我从显存计算到部署工具的实操路线，然后走一遍 WorkBuddy 的安装和使用流程，最后把最容易踩的坑整理成清单。无论是单纯想了解大模型技术趋势的读者，还是想趁免费窗口实际跑通一个业务场景的开发者，应该都能在里面找到能直接用的内容。

1. 拆解发布信号：770B MoE“开源”和 WorkBuddy“限免”组合在一起，到底意味着什么

1.1 先定个性：这轮比拼的主战场已经变了

如果你从 2023 年开始关注开源大模型，应该能感觉到一个明显变化。早期大家的关注点是“模型能答对多少题”，后来是“能不能跑在消费级显卡上”，再到近一年，话题重心逐渐变成“每处理 100 万 token 要花多少钱”“部署一套服务需要多少显存”“能不能稳定支撑 Agent 类应用”。

这次“770B MoE 开源”如果只看参数规模，确实很容易让人产生“普通用户跑不起来”的第一印象。但结合同一批发布的 WorkBuddy 来看，发布的逻辑就很清楚了：模型负责提供更强的底座能力，应用工具负责把底座能力变成普通办公用户能直接操作的界面。对厂商来说，这是一种典型的“模型+应用”组合打法，先用超大模型立技术标杆，再用免费 Agent 获取真实使用数据。

我自己判断，这个发布放在整个开源社区里，背后真正值得关注的是三件事：很大体量的 MoE 权重愿意公开，说明开源大模型的能力上限正在被持续抬高；随之而来的部署问题会让工具链的重要性凸显出来；限时免费的工具类产品会带动一批新用户从“听说”转向“上手”。

1.2 770B 不是只看总量，要看总参数与激活参数的比值

很多非技术背景的朋友看到 770B，第一反应是“这个模型是不是大到没法用”。这里需要先理清楚一个非常重要的概念：MoE 架构下，一个模型有两个数字，一个是总参数，一个是激活参数。

总参数 770B，意味着模型权重文件里确实有 7700 亿左右个参数。激活参数则是指在处理每一个 token 时，实际参与计算的参数数量。如果用 Dense 模型来处理，770B 总参几乎意味着每次推理都要把 7700 亿参数全部算一遍，这个计算成本对绝大多数团队都不现实。而 MoE 的设计恰恰就是为了解决这个问题，它可以把总参数做得非常大，但每次只激活其中一小撮专家。

以已经开源的几个 MoE 模型为例，Mixtral 8x7B 的总参数约 47B，激活参数约 13B；DeepSeek-V3 的总参数是 671B，激活参数只有约 37B。你看，总参数和激活参数之间可以相差一个数量级。Hy4 preview 具体采用多少专家数、每个 token 激活多少参数，需要等官方公布 config 才能确定，但这类模型通常都会延续“总参超大、激活相对可控”的设计思路。所以对使用方来说，真正影响推理延迟和单卡是否能跑的关键，不是 770B 这个总数字，而是活跃参数那一部分。

如果官方后续公开的激活参数在几十 B 这个量级，配合量化手段，中小团队通过 API 或者多卡推理服务来使用是完全可行的。如果激活参数也接近百 B 甚至更高，那就主要靠大批量 GPU 集群或者厂商提供的云 API 来支撑。这也是为什么这次发布对普通用户最有价值的入口其实不一定是权重本身，而可能是配套应用。

1.3 WorkBuddy 限时免费，本质是把低门槛入口送到用户面前

“模型开源了”和“我能用上”之间还隔着一条巨大的工程鸿沟。你不仅要准备足够的硬件资源，还要处理权重下载、推理服务搭建、prompt 调试、上下文管理、工具调用等一系列问题。对于做 AI 应用的个人或团队来说，这些都是基本功，但对大多数文职、运营、产品、数据分析岗的普通用户来说，他们根本不会去看模型文件长什么样。

WorkBuddy 这类工具要解决的就是最后这一公里。它把模型能力封装成了可以自然语言对话、可以调用内部工具、可以编排任务流的办公入口。这次限时两周免费用，如果解读得直白一点，就是厂商愿意用免费额度换取用户的使用反馈和场景验证。站在用户角度，这两周时间非常适合做两件事：第一，判断这个工具是否真的能提升自己的日常工作流效率；第二，把自己手头最有价值的业务场景放进去试跑，看模型理解能力和工具执行能力到底如何。

从博主的角度看，模型发布热闹归热闹，真正值得我们投入时间研究的其实是“这个模型能跑什么业务”“用什么方式接入成本最低”以及“限免窗口内如何快速验证效果”。后面几个章节就是奔着这三个问题去的。

2. MoE 架构核心原理：为什么“专家混合”能同时兼顾大参数与合理成本

2.1 从“全科医生”到“专家会诊”

理解 MoE，最简单的方式是拿医疗体系来类比。Dense 模型就像是全科医生，不管是感冒发烧、摔伤骨折还是疑难杂症，都靠同一个医生从头到尾处理，知识面广，但每次处理一个问题都要调动他的全部知识储备。MoE 模型则像是一个专家会诊中心，外面坐着一个分诊台，患者进来之后，分诊台会根据病情把患者导诊到对应的专科医生那里，只有相关科室的专家参与诊断。

在 MoE 模型里，这个“分诊台”叫 Router（路由网络或门控网络），“专科医生”叫 Expert。模型结构里并列着很多专家模块，每个专家负责处理某类模式或知识。输入给到模型的每一个 token，并不会经过所有专家，而是由 Router 先对所有专家打分，选出分数最高的 top-k 个专家，真正参与这一轮计算。

所以，你可以把一个 MoE 模型理解为“一个大模型壳子里装了很多个小模型”，而那个门控网络负责调度。知识存储量取决于所有专家的参数总和，计算成本则取决于被选中专家的参数数量。

2.2 Router 与 Expert 的配合：Top-k 路由如何决定一次推理

具体再看细一点。典型 MoE 层包含三部分：一个共享的输入投影、多个 Expert 前馈网络、一个 Router 打分器。token 进入 MoE 层后，Router 会为这个 token 生成一个在所有专家上的概率分布，然后选出得分最高或采样得到的 k 个专家。选中的专家会分别处理输入，最后按 Router 给出的权重加权融合，输出结果。

举两个已经落地的设计例子：Mixtral 8x7B 每层有 8 个专家，每个 token 激活 2 个专家；很多近年来的模型会把 top-k 保持在 2 到 8 之间。这里有一个容易被忽略的问题：如果 Router 总是把流量集中到少数几个专家，其他专家就浪费了。所以工程师通常会在训练时加入负载均衡损失，目标就是让各个专家的使用率尽量均匀，防止训练和推理的时候出现“热门专家堵车、冷门专家闲置”的局面。

在推理阶段，由于每个 token 只需激活少量专家，单次前向传播的浮点运算量会明显低于相同总参数量下的 Dense 模型。这对服务端来说是实打实的成本优势，因为 GPU 的算力消耗更多取决于激活计算量，而显存容量更多取决于总参数。

2.3 为什么 MoE 的“便宜”主要体现在算力，而不是内存

很多人误以为激活参数少就等于模型对机器要求低。实际用过一遍就会明白，MoE 模型对显存的要求依然很高，甚至在多卡部署时比同规模的 Dense 模型更麻烦，因为它必须把所有专家的权重全部放进内存或显存里，只是每次用到的部分少。

更直白地算一笔账：推理模型权重需要先加载到显卡显存，否则只能退到 CPU 内存与 GPU 显存之间反复换入换出，速度会非常慢。770B 参数如果按 FP16 存储，光权重就是 770B × 2 字节，约 1.54TB 显存。哪怕你只激活其中的 30B 参数，这 1.54TB 的权重也必须准备够。所以 MoE 适合的场景是：你已经有足够的多卡集群资源，想用同样的算力换取更大的知识容量和更强的能力表现。

这也是我在评估一个开源 MoE 时一定会做“显存预算”的原因。模型再强，装不进显存就等于零。

2.4 MoE 的短板也需要提前知道

MoE 并不是包治百病的银弹。我实际用下来，它的明显短板集中在四个方面：

第一，显存占用高，单卡部署困难。前面说过，权重必须全部驻留，所以对个人开发者特别不友好。第二，通信开销大，在多卡甚至多机部署时，专家可能需要被切分到不同 GPU 上，token 需要把中间结果发送到对应显卡，跨卡通信会成为新的性能瓶颈。第三，训练和微调难度更大，负载均衡容易失衡，微调时如果数据分布太偏，模型可能过度依赖某几个专家，引发性能下降。第四，量化难度比 Dense 模型更高，因为不同专家对量化的敏感度不一致，简单的全局量化容易精度损失。

所以，如果你只是想在自己的电脑上跑一个小助手或者做个人知识库，一个 7B 到 14B 的 Dense 模型往往比一堆参数的 MoE 更合适。MoE 更适合的场景是底层服务、API 形态的多用户支持，以及需要处理非常多样化任务的 Agent 系统。这也是为什么 Hy4 preview 这种大 MoE 更适合配套 WorkBuddy 这类产品，而不是让每个普通用户自己部署。

3. 开源 MoE 模型的部署实操路线：从显存计算到工具选型

3.1 先算显存账，再谈部署方案

任何部署工作的第一步都不是敲命令，而是算清当前硬件能不能扛住模型。我通常用一个简单公式做初步估算：

模型权重所需显存 = 参数量 × 每个参数所需字节数

如果使用 FP16（半精度浮点数），一个参数占 2 字节；FP32 为 4 字节；INT8 量化约为 1 字节；INT4/GGUF Q4 量化则更低，约为 0.5 到 0.6 字节。实际部署时还需要为 KV Cache、CUDA context、中间激活值等预留额外空间，通常我会在权重显存基础上再乘 1.2 到 1.3。

以不同体量模型为例，只看权重部分，情况如下：

看到上表，你应该就明白了：770B 级模型即使是 INT4 量化，也至少需要 420GB 左右的显存才能完整装下权重，这远超消费级单卡的容量。即便不考虑 KV Cache，也需要多张 80GB 显存的企业级显卡同时工作。这意味着绝大多数团队如果想用 Hy4 这档模型，真正合理的路径有两种，要么使用官方或第三方提供的 API，要么在自己的机房或云上搭建一套多卡推理服务。

3.2 个人或小团队体验 MoE：从 Ollama 拉起轻量级模型开始

如果你只是想在本地体验 MoE 的推理效果，或者想快速跑通 Agent 流程，没有必要一上来就挑战几百 B 的大模型。可以先从那些总参在 20B 到 50B 之间的开源 MoE 模型入手，它们更贴近个人单卡或双卡能承载的范围。

Ollama 是目前最简单的本地模型运行工具。安装完成后，你可以直接搜索并拉取支持 MoE 架构的开源模型镜像。这里以一条通用命令为例，实际模型名要以你选择的仓库为准：

ollama pull mixtral:8x7b-instruct-q4_K_M ollama run mixtral:8x7b-instruct-q4_K_M

下载完成后，Ollama 会默认启动一个本地 API 服务，监听在 11434 端口。你可以用下面的命令验证模型是否正常回复：

curl http://localhost:11434/api/generate -d '{ "model": "mixtral:8x7b-instruct-q4_K_M", "prompt": "你好，请用一句话介绍什么是MoE模型。", "stream": false }'

Ollama 对硬件的配置比较省心，它会自动利用本机 GPU 并将溢出的层加载到 CPU 内存。但我要提醒一点：如果你只有一个 8GB 显存的显卡，跑 47B 或 26B 的 MoE 模型依然会非常吃力，因为权重要么放不下，要么只能以极慢的 CPU 推理速度运行。个人玩家最优先考虑的还是量化后的 7B 到 14B 模型。

3.3 生产级部署：用 vLLM 加载并启动一个 MoE 模型的完整命令

如果你的目标是为团队或线上环境提供一个稳定的 MoE 推理服务，我建议直接使用 vLLM 或 SGLang。vLLM 对 MoE 的支持相对成熟，内置了 PagedAttention 做 KV Cache 管理，也能通过张量并行把模型切到多张显卡上。

当你从社区或官方渠道下载好模型权重之后，如果目录结构包含 config.json 和 safetensors 文件，就可以编写启动命令。通常我的做法是先建一个干净的 Python 环境：

conda create -n vllm python=3.11 -y conda activate vllm pip install vllm

然后执行推理服务启动命令。以我的一个部署脚本为例，假设权重目录在 /data/models/hy4-preview-moe：

python -m vllm.entrypoints.openai.api_server \ --model /data/models/hy4-preview-moe \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --trust-remote-code \ --served-model-name hy4-preview

每个参数我都解释一下。--tensor-parallel-size 8 表示用 8 张 GPU 并行切分模型。如果你的显卡数量不够，需要根据模型大小调整这个值。--max-model-len 指定单条请求支持的最大上下文长度，太长会显著增加 KV Cache 占用，应该按业务实际需求来设。--gpu-memory-utilization 0.9 表示每个 GPU 最多使用 90% 显存，避免把显存完全占满导致 CUDA 申请失败。--trust-remote-code 是给那些配置里包含自定义 Python 代码的模型用的，如果模型不需要就不要加，执行未经确认的远程代码有安全风险。

服务启动后，会暴露一个与 OpenAI API 兼容的接口，可以用下面的命令测试：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "hy4-preview", "messages": [{"role": "user", "content": "帮我做一份7月第一周的周报提纲"}], "temperature": 0.7 }'

如果你发现多卡扩展后性能没有线性提升，先不要急着换显卡，重点检查跨卡通信带宽和 KV Cache 的分配策略，这两个地方通常是瓶颈所在。

3.4 更务实的接入方式：不自建服务，直接走 OpenAI 兼容 API

对大多数中小团队来说，自己搭一套 770B MoE 服务在成本上并不划算。每周的 GPU 租赁费、运维成本、弹性伸缩策略，这些都是开销。与其把时间花在底层部署上，我更建议初期直接使用厂商提供的 API 服务。你只需要拿到 API Key，然后通过 OpenAI SDK 或任何兼容接口来调用：

pip install openai

from openai import OpenAI client = OpenAI( api_key="你的API Key", base_url="https://api.example.com/v1" ) resp = client.chat.completions.create( model="hy4-preview", messages=[ {"role": "system", "content": "你是企业知识库助手，请根据给定资料回答。"}, {"role": "user", "content": "总结这份项目复盘文档的核心结论。"} ], temperature=0.3 ) print(resp.choices[0].message.content)

用 API 接入的优势不仅是省去了部署成本，更重要的是你可以在正式投入重资产之前，先小成本验证模型在你业务场景上的效果。我给不少团队做技术评估时都建议过同一套流程：先拿真实业务数据跑一周 API 测试，记录成功率、响应速度、成本、失败类型，如果结果理想，再决定要不要采购专用 GPU 做私有化部署。

4. WorkBuddy 安装、免费领取与日常使用实操

4.1 安装前需要确认的基础信息

WorkBuddy 的具体入口和安装包形态可能会随官网更新有所调整，但作为同类 AI 办公 Agent 产品，安装前有几个共同问题需要先确认：支持的操作系统是 Windows、macOS 还是 Web 端；是否需要企业管理员权限；是否要求必须登录企业账号才能在内部环境使用；免费体验是否要求绑定支付方式。

我个人的经验是，这类工具的账号体系一般分为个人版和企业版。个人版注册门槛低，适合先试用；企业版通常能接入统一登录、权限管理、审计日志等能力，但需要管理员开通。先把自己当前的使用身份确认好，后面就会顺利很多。

4.2 安装与登录流程

打开官方页面后，通常会有明显的下载入口。根据你的系统选择对应的安装包，双击安装，然后打开客户端。首次注册基本是手机号或邮箱验证码登录，也可能支持第三方企业办公账号。登录后，产品会引导你选择工作区或团队，建议先建一个个人测试工作区，不要在正式企业空间里直接上传敏感数据。

如果你遇到“限时免费用”的活动入口，一般会弹窗提示领取。领取前务必看清楚活动规则，包括免费周期的起止时间、额度上限、是否包含 API 调用量、到期后是自动转为付费还是停止服务。不要只凭感觉点，很多免费活动到期后如不主动取消，可能会自动续费。

4.3 第一次跑通一个任务：以“整理多份文档并输出周报”为例

WorkBuddy 的使用逻辑和我们操作传统 Office 软件不同，它更像是一种“任务编排式”的智能助手。你可以直接告诉它目标是什么，它会自主拆解步骤并决定调用哪些能力。

我这里用一个高频办公场景演示完整流程：假设你需要把分散在多个文档里的项目信息汇总成一份周报。第一步，在对话窗口里选择“新建任务”，上传或导入五到十份相关文档。第二步，用自然语言描述需求，比如“整理这些文档的要点，比较项目进度、风险，按照周报格式输出，附上负责人信息”。第三步，点击发送后，WorkBuddy 通常会展示任务分解过程，包括读取了哪些文件、拆成了几个子任务、正在执行哪一步。第四步，等它输出初稿后，你要做的是逐一核对数据和结论，再加入人工调整并导出 Word 或 Markdown。

这里有一个容易被忽略的关键点：AI 办公工具最怕的任务描述是“帮我写个周报”这种极简指令。因为没有上下文，它只能凭空猜测，输出大概率不贴合实际需求。正确的做法是给足约束条件：输入来源是哪些文件、输出格式是什么、是否需要包含风险预警、要不要区分事实与推测。提示词写具体，结果质量会直线上升。

4.4 Skill 工具与业务系统接入：把 WorkBuddy 变成流程引擎

热词里反复出现 WorkBuddy Skill，这其实是同类 Agent 产品普遍很重视的一个扩展点。Skill 可以理解成把“特定行业的一套标准动作”固化成可复用的插件。比如财务团队可以做一个“月度预算核对”的 Skill，它内置了取数逻辑、异常规则、报告模板，后续每次只需上传新数据并选择这个 Skill，就能自动跑完整个流程。

在团队内部，如果产品支持连接飞书、钉钉、企业微信、Notion、数据库、内部 API 等，就可以把 WorkBuddy 从独立工具变成流程中间件。比如在文档应用里新增一个按钮，选中一段文本转成待办发送给项目管理系统，这类自动化场景往往比单纯对话更有长期价值。

还要注意，接入内部系统前要评估数据安全边界。哪些数据可以发给 AI 模型、是否需要脱敏、离线版是否比 SaaS 版更合适，这些都应该由团队的信息安全负责人提前做出决策，而不是等功能上线后再补救。

4.5 WorkBuddy 与 CodeBuddy 的边界区分

热词里有不少人同时关心 CodeBuddy 和 WorkBuddy 的关系。从产品定位来看，两者服务的场景有明显差异。为方便对比，我整理了一张简单的表：

如果是一个研发团队，可以两类产品同时用：CodeBuddy 负责研发侧的代码生成与问题排查，WorkBuddy 负责项目管理侧的会议纪要、需求拆解、周报整理。这样模型能力和工具各自落在最擅长的地方，产研协作的整体效率会更容易提上来。

5. 最容易踩的坑：实测中的问题排查与避坑清单

5.1 MoE 模型部署中的常见问题

我在部署 MoE 模型时遇到的问题，集中在这几个方面，整理成一个速查表供你参考：

MoE 模型在 FP16 和不同量化级别下的输出表现，差值会比 Dense 模型更大。如果做生产服务，我建议至少准备 INT8 或可接受的量化精度，先用业务评测集回归一遍，不要盲目追求低比特。

5.2 WorkBuddy 使用中的注意点

再列几条 WorkBuddy 使用时比较实用的经验：

第一，免费活动开始前先读活动说明文档，搞清楚“两周”是按自然日还是工作日计算，免费用是否包含全部 Skill 与 API。第二，不要把含敏感隐私的文件直接上传到公网版工具，先用脱敏数据验证流程，再评估是否需要私有化版本。第三，它生成的周报、数据总结只适合当草稿，涉及对外发送前必须人工核对关键数字和结论。第四，如果你的业务经常需要处理固定格式的数据，建议把标准流程沉淀为 Skill，而不是每天重新写一遍长提示词。

我在实际测试 Agent 类工具时还有一个习惯：同一个任务会换三种不同方式去描述，看看输出差异。如果工具对提示词的表达方式极其敏感，说明它的稳定指令理解还不一定足够，那就需要在团队内部建立一套标准模板，把可用 prompt 固化下来。

5.3 关于这次限免窗口，我的使用策略建议

限时两周的免费窗口从第一天开始就不应该只用来“体验新奇”，而是要按项目节奏来推进。我的建议是把时间分成三段：前两天完成安装、权限申请、示例场景跑通，顺便验证工具对常见文档和任务的兼容性；中间一周把团队真实业务场景带进去测试，重点记录成功率和不足；最后三天整理结论，决定是否付费、是否需要私有化部署、是否需要将某些操作流程沉淀为 Skill。

不要等到窗口快结束才想起来试用，那时候你不仅没有充足时间验证，还会因为赶进度跳过安全评估和数据合规审查，反而更容易出问题。这是一个真实的经验教训，我在多个 AI 办公工具试点项目里都见过类似情况。

对我个人来说，Hy4 preview 真正确认的发布细节可能要等更完整的模型卡出来才做最终评估，但整个事件已经提示一个趋势：超大 MoE 开源模型会越来越像“水电基础设施”，普通用户不再需要关心变压器怎么铺设，而是要更关注水表上的流量、App 里的开关，以及接水之后能烧出什么样的菜。如果你也想验证 WorkBuddy 这类工具在自己的工作流里是否真的有用，我建议列一个“高频重复劳动”的清单，从里面挑出最耗时的一项，趁免费期内先跑通再说。