企业官网建设流程全解析

最近 AI 圈有个消息挺提气：Hy4 preview 正式发布了，770B 的 MoE 架构，而且直接开源。同一天，WorkBuddy 也宣布限时两周免费使用。这两件事放在一起看，其实透露出一个信号：大模型已经从"我跑通了"进化到"我怎么用起来"的阶段了。

我拿到消息后第一时间翻完技术文档，又装了 WorkBuddy 上手试了两天，这里就把一手的体验和理解整理出来。不管你是做 AI 应用的开发者，还是琢磨着把模型能力接入自己业务的技术负责人，又或者只是对 MoE 架构好奇的爱好者，这篇内容应该都能给你一些参考。

1. Hy4 到底是什么水平：770B 和 MoE 拆开看

1.1 770B 不是"70B 加个0"这么简单

很多朋友看到 770B 第一反应是"参数真大"，但到底大到什么程度，可能需要一个参照系。之前大家熟悉的稠密模型，比如常见的 70B 模型，是 700 亿参数全部参与每一轮计算。而 Hy4 的 770B 是"总参数"的概念，底层是 Mixture of Experts 架构，也就是混合专家模型，让我换个方式说明白。

你可以把稠密模型想象成一个所有员工都坐在同一间办公室的公司，不管来什么需求，全公司的人都得参与响应。而 MoE 架构更像一家大集团，总部养着几百个专家团队，每个请求进来后只抽调最对口的几个团队处理，其他团队继续待命。Hy4 770B 的意思是这家集团总员工数是 7700 亿级别，但真正为某个具体任务出动的人数，只是其中一小部分。

这里就涉及到一个关键指标：激活参数。虽然 MoE 模型总参数很大，但推理时只激活部分专家。以目前主流 MoE 模型的经验来看，激活参数通常在总参数的 5% 到 10% 之间，Hy4 大概率把激活规模控制在 30B 到 50B 这个区间，虽然这只是我的推算，但符合行业近一两年的设计惯例。

1.2 MoE 架构凭什么又强又省

MoE 的核心设计就是"稀疏激活"。它把一个巨大的前馈网络拆成若干独立的专家子网络，然后通过一个路由器（Router）决定当前 token 需要哪些专家来处理。这个路由器其实就是一个分类器，它看一遍输入的 token 表示，然后给所有专家打分，选出得分最高的若干位参与计算。

这个设计的妙处在哪？首先是效果上限更高。总参数量越大，理论上能记住和建模的知识就越丰富。稠密模型想增加能力，只能无脑堆参数，但参数越多，推理成本越高，训练也越容易出问题。MoE 通过稀疏激活绕开了这个矛盾，模型容量变大，但计算量没有线性增长。

其次是推理成本可控。你部署一个 770B 的 MoE 模型，实际需要的显存并不需要装下所有参数吗？其实还是需要的，因为专家参数都存储在显存里，只是计算时只算一部分。所以它还是有部署门槛的，但相比同规模稠密模型，推理时的算力消耗会低很多，这也是 MoE 能在开源社区迅速流行的根本原因。

1.3 开源这件事的分量

很多大厂也发布过千亿级 MoE 模型，但那些大多是 API 形式，权重不开放。Hy4 选择直接开源权重，这就意味着几个非常实际的场景变成了可能。

第一，私有化部署。企业内部数据不能出域，这是很多行业比如金融、医疗的硬要求。开源权重模型可以直接部署在内网服务器上，数据完全自己掌控，这是 API 调用永远做不到的。

第二，微调和定制。基于开源模型做领域微调，或者用 LoRA 等参数高效微调手段做适配，已经是非常成熟的路线。开源意味着你可以把 770B 这个大底座变成自己业务的专属模型，这个想象空间比"调用一个黑盒 API"要大得多。

第三，生态工具的繁荣。开源模型一旦发布，量化、推理加速、部署框架、应用层工具都会快速跟上。不是每个团队都从零训练自己的大模型，但几乎每个团队都能从"如何更好部署开源模型"这件事里获益。

2. WorkBuddy 是什么：大模型落地的最后一公里

2.1 定位：不只是聊天框

WorkBuddy 如果只是一个聊天界面，那它没什么好说的。但从我这两天的使用体验看，它的定位更像是一个"大模型能力调度中心"，结合社区里大家关心的关键词来看，比如"workbuddy skill"、"workbuddy 插件"、"workbuddy 自定义指令推荐"，能看出它走的是"模型 + 技能 + 工作流"的路线。

打个比方，Hy4 这类开源模型相当于一台性能强劲的发动机，而 WorkBuddy 就是一辆组装好的车。发动机得装进车里，配上方向盘、仪表盘、导航系统，普通人才能真正开上路。WorkBuddy 承担的就是这个"整车"的角色，它负责把大模型的问答能力，拆解成可以执行的任务，再通过技能和插件体系接入不同场景。

它和 CodeBuddy 的关系也很有意思。CodeBuddy 定位在代码场景，WorkBuddy 更像是通用的工作助理，覆盖的范围不限于写代码。从用户反馈来看，有人拿它做文档整理，有人拿它做数据分析，甚至建筑行业的朋友都在用它做项目文档管理，说明底座模型的能力已经被 WorkBuddy 比较充分地暴露给了上层应用。

2.2 核心能力拆解

WorkBuddy 的能力，我梳理下来大概分四块。

第一，多模型接入。它不绑定某一个模型，而是可以对接本地部署的开源模型，比如这次发布的 Hy4，也可以对接各种在线 API。这个设计很聪明，用户不需要因为换模型而换工具，模型层可以灵活替换。

第二，技能机制。这是 WorkBuddy 最有特色的部分。你可以给 WorkBuddy 定义一套技能，比如"把技术文档翻译成英文"或者"提取合同里的关键条款"，每个技能包含指令模板和参数配置，使用时直接唤起，相当于给助理预置了一套 SOP。这个设计对于重复性高的任务非常友好。

第三，插件体系和自定义指令。插件解决的是"连接外部工具"的问题，比如接数据库、接办公软件、接自动化流程。自定义指令则解决"让模型更懂你"的问题，你可以通过指令设定角色、风格、输出格式等。这两者叠加，基本上可以把 WorkBuddy 调教成一个高度个人化的助理。

第四，本地部署支持。很多人搜"workbuddy 本地部署"和"workbuddy linux"，说明它提供了在 Linux 环境下自托管的方案。这意味着企业可以把 WorkBuddy 和私有化模型部署在一起，形成一套完全自主可控的 AI 工作平台。

2.3 限时免费背后的意义

WorkBuddy 限时两周免费，说白了就是获客策略。但作为用户，这个阶段反而是"薅羊毛 + 深度评估"的好时机。两周时间足够你把核心场景跑一遍，看它到底能不能解决你的实际问题。

我的建议是，如果你还在犹豫要不要引入一个 AI 工作助理，这种限时免费的机会一定要抓住。不要只是登录进去聊两句就完了，而是拿自己真实的业务场景去测试，把最繁琐、最耗时的任务丢给它，看它能帮你省多少时间。免费期间测出来的结论，才真正有决策参考价值。

3. 实操：从部署 Hy4 到用上 WorkBuddy

3.1 部署 Hy4 前先算好三笔账

想本地跑 Hy4，先掂量一下手里的硬件。770B 的总参数，即便是 4bit 量化，模型文件也有接近 400GB 的体积。这是什么概念？一张主流显卡的显存通常是 24GB 或 48GB，单卡肯定是装不下的。你需要一个多卡服务器，或者用 CPU + 大内存的方案来跑。我在实际部署中发现，比较务实的方案有两种。

一种是用多张 48GB 显存的显卡做张量并行推理，比如 8 张卡基本可以比较舒服地跑 4bit 量化版本。另一种是用 CPU 推理，内存配置到 512GB 以上，加上高效的推理框架，也能跑起来，但速度会慢很多，适合离线批处理场景，不适合在线服务。动手之前先把仓库里的技术文档里关于显存和内存的建议看一遍，避免买错配置。

部署流程本身，其实已经比较标准化了。主流推理框架比如 vLLM 和 SGLang 一般都会在模型发布后很快适配。基本步骤是：先下载模型权重，然后写一个启动脚本，配置模型路径和端口，最后调接口验证。如果你之前部署过其他开源大模型，套路是一样的，只是资源需求更大。如果你完全没接触过模型部署，我的建议是从小模型练手，直接上 770B 会非常痛苦。

3.2 WorkBuddy 安装与配置

WorkBuddy 的安装比我预想的简单，这可能是它团队在产品化上下了功夫的结果。

如果你用桌面版，直接到官网下载对应系统的安装包，Windows 和 macOS 都有。Linux 用户则可以走本地部署的路子，按文档里的步骤拉代码、装依赖、改配置，然后启动服务。整个过程大概有几步，但每一步文档里都有现成命令可以抄。

装好之后，第一件要做的事是配置模型来源。如果你本地已经跑起来了 Hy4，可以在 WorkBuddy 里把模型地址配置成http://localhost:xxxx/v1这样的 OpenAI 兼容接口地址，WorkBuddy 就能像调 API 一样访问你的本地模型了。如果你没有本地模型，也可以先接一个在线 API，把工具跑通，之后再升级到本地部署。

配置完成后，就可以开始用自然语言对话了。这里我强烈建议先创建一个测试技能，比如让 WorkBuddy 把一段长文改写成周报格式。你会发现，技能机制的强大之处在于：你调教一次之后，这个技能就被保存下来，之后每次调用都是一致的输出质量，不再需要重复描述需求。

3.3 一个完整的"会议纪要 + 待办提取"示例

我拿真实的使用场景来演示 WorkBuddy 的技能配置。假设你希望上传一篇会议记录，自动输出会议纪要和待办事项。

配置技能时，我给 WorkBuddy 定义了这几个参数：输入文本、输出格式、是否需要提取责任人。指令部分写的是："你是一名项目助理。请阅读会议记录，提取关键决策、待办事项和责任人，按 Markdown 表格输出。如果某条待办没有明确责任人，标注为未分配。"

实测下来，这个技能对 Hy4 的调用结果是相当稳定的。模型能识别出"会后跟进"、"张伟负责"这类口语化表达，并且准确映射到待办表格里。这背后就是 770B 大模型的语义理解能力在起作用，换成一个小参数模型，很可能就把责任人和任务搞混了。

这个案例说明一个道理：模型能力是基础，但工具编排决定了能力能不能被高效释放。Hy4 负责"懂"，WorkBuddy 负责"干"，两者配合，才是一个完整可用的工作流。

3.4 写代码场景：WorkBuddy 的另一种打开方式

除了文本处理，WorkBuddy 接上代码能力也是一把好手。社区里很多人同时关注 CodeBuddy，说明这类工具在代码场景确实被高频使用。WorkBuddy 里可以新建代码类技能，比如"解释这段代码"或者"生成单元测试"。

我会这样配置一个代码审查技能：指令要求模型阅读代码，找出潜在 bug、性能瓶颈和可读性问题，并且给出修改建议，按"问题 / 严重程度 / 建议"的格式输出。实测中，让 WorkBuddy 配合 Hy4 来分析一段 Python 数据处理代码，它不仅能指出列表推导式造成的内存问题，还建议改用生成器节省资源，这个建议的逻辑链条是比较完整的。

它的实际体验比单独开个网页聊天框好在哪里？我觉得在于上下文管理。你可以把项目背景、编码规范提前写进自定义指令里，这样模型每次分析代码时都自动带上这些约束条件，输出结果会更贴合你的团队风格。这个能力，是单纯聊天式交互做不到的。

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

4.1 本地部署 Hy4 时最容易踩的坑

部署大模型最典型的坑就是显存溢出。明明按文档算好了显存够用，一启动服务，进程运行到一半直接 OOM。我在排查这类问题时，通常先做两件事。

第一件事是确认量化位宽和显存公式。以 4bit 量化为例，一个比较粗略的估算是参数量乘 0.55 到 0.6 得到显存占用，单位是 GB。770B 算下来大概是 420GB 到 460GB 的显存需求，如果你的总显存在这个数字附近，空间会非常紧张。第二件事是调整 KV Cache 的大小。很多框架默认会给 KV Cache 留比较多显存，你可以通过启动参数限制它，给模型权重留足空间。如果你用的是 vLLM，通常有--max-model-len和--gpu-memory-utilization这两个参数可以调，前者控制上下文长度，后者控制显存利用率。

另一个坑是推理速度慢到怀疑人生。如果发现每秒只出几个 token，大概率是因为模型跑在 CPU 上了，或者在用 CPU 做算子。检查方法很简单，启动日志里一般会显示当前推理设备。CPU 推理不是不能用，但你要有心理准备，它适合异步任务，不适合实时交互。我之前用 CPU 跑一个几百亿参数的模型，每秒只有两三个 token，等一句话等半天，那种体验确实有点难受。

4.2 WorkBuddy 配置中的几个典型问题

我在这两天使用 WorkBuddy 的过程中，也遇到了一些问题，这里把排查思路分享出来。

问题一：WorkBuddy 连不上本地模型。这种情况九成是模型服务的地址配置错了。注意检查端口号，还有地址后面到底需不需要补/v1。很多 OpenAI 兼容服务要求完整路径是http://ip:port/v1，漏掉/v1就会报连接错误。另外确认模型服务监听的是0.0.0.0还是127.0.0.1，如果你想从另一台机器访问，必须监听在对外地址上。

问题二：技能不生效，回答还是默认风格。这种情况多半是技能配好了，但当前对话没有选择这个技能。WorkBuddy 的技能机制通常要求你在对话窗口手动指定，或者在创建会话时绑定技能。它不是全自动触发的，不然每个会话都自动调用所有技能，反而会乱。我一开始也踩了这个坑，以为配置好就全局生效，后来才发现要在对话里显式唤起。

4.3 模型选型的一个建议

最后给一个非常实际的选型建议。如果你已经准备玩 770B 这个级别的模型，我建议不要一上来就追求满血版，而是先跑一个量化程度高一点的版本，比如 4bit，把流程跑通，确认它能在你的硬件上稳定工作。等业务真的需要更高精度时，再上 8bit 或者更高精度版本。

另外，如果硬件资源确实紧张，也不必死磕 770B。MoE 架构的开源模型现在已经不少，选一个总参数在百亿级别、激活参数在 10B 上下的模型，在很多场景下已经足够用。我个人在实际操作中的体会是，模型不是越大越好，而是越适合你的场景越好。参数规模带来的收益，在任务复杂度较低时会边际递减，但部署成本和维护成本是实打实递增的。

这次 Hy4 的发布，加上 WorkBuddy 的免费期，确实是一个很合适的上手窗口。先用两周不要钱的时间把工具链摸熟，再慢慢规划自己的模型部署方案，这条路走下来是比较稳的。希望这篇能帮你少踩几个坑。