企业官网建设流程全解析

朋友圈从昨天开始就被 Hy4 preview 的消息刷屏了。770B 参数的 MoE 开源模型，叠加 WorkBuddy 限时两周免费，这两个动作放在一起，做 AI 应用和 Agent 开发的人应该能立刻闻到味道：这不仅仅是发了个模型，而是把“模型底座”和“落地工具”一起递到了用户手里。

我先说结论：如果你是重度模型玩家，手里有四张以上 80GB 显存的卡，或者愿意上量化方案，Hy4 preview 值得立刻上手测；如果你平时主要靠 AI 写代码、整理资料、跑业务流程，那 WorkBuddy 这两周免费期就是送上门的机会，先把账号开了，再慢慢研究怎么用透。这篇文章我会把 MoE 架构、开源价值、部署门槛、WorkBuddy 的实际用法一次讲清楚。

1. 770B MoE 开源，Hy4 Preview 这波操作该怎么看

1.1 MoE 架构拆解：770B 总参数不等于你要装的 770B

很多人一看到“770B”就会被吓到，觉得这玩意得几百万预算才能跑。其实 MoE（Mixture of Experts，专家混合）架构最核心的逻辑就是：模型总参数量很大，但推理时只激活其中一小部分。

我拿一个大家都能理解的类比：一家公司有 770 名员工，但处理日常业务时，不需要这 770 人全部到场，而是根据任务类型调度对应部门的几十个人。总人数是 770 人，但真正干活的可能只有 30 到 50 人。

Hy4 preview 走的就是这个路线。770B 总参数，按照同类开源 MoE 模型的常见设计惯例（比如 DeepSeek-V3 的 671B 总参数、37B 激活参数），我推测 Hy4 的激活参数量大概率在 40B 到 60B 这个区间。这带来的直接好处是：推理成本、显存占用、响应速度都接近一个 40B 到 60B 的稠密模型，但知识容量和表达上限却享受着 770B 的规模红利。

这也是为什么近两年 MoE 架构成了大模型军备竞赛的主流答案。稠密模型想要变强，只能硬堆参数，但堆到 400B 之后的训练成本和推理成本都让人头皮发麻。MoE 则是在同样的算力预算里，塞进更多的专业“车间”，让每个 token 只走其中几条生产线，省下来的算力全变成了模型宽度。

1.2 开源发布的意义：权重、代码与生态，一次给齐

Hy4 preview 选择开源，这步棋本身就很值得聊。现在的开源模型，已经卷到了一个相当高的水位：权重开放、训练代码开放、技术报告公开，甚至有的团队连数据清洗方案、评测集构建方法都一并放出来。

开源和闭源最大的差别，不是“免费”这两个字，而是“可控”和“可变”。闭源 API 你只能等厂商更新，业务被别人的模型版本和定价策略牵制；开源权重之后，你可以自己微调、量化、蒸馏、私有化部署，数据不用出内网，这对很多企业的合规要求来说是决定性的。

按当下开源社区的惯例，我估计 Hy4 preview 至少会放出权重文件、推理示例脚本、评测基准结果，大概率还会给出基于 vLLM 或 SGLang 的部署配置。这种“权重+代码+文档”一起给的模式，已经成了开源模型的基本操作。真正值得关注的是它有没有附带指令微调版本、对齐后的 chat 版本，以及是否支持 OpenAI 兼容的 API 格式。如果这些都齐了，那从下载到接入业务系统，一天就能跑通。

1.3 硬件门槛先算清楚：你手里的卡到底够不够

这里我不绕弯子，直接算账。假设 Hy4 preview 的激活参数在 50B 左右，总参数 770B。你要跑全精度推理，先看权重文件大小：

如果你只有 8 张 80GB 的 A100/H100，那 4bit 量化版会比较稳。如果只有两张 80GB 卡，那建议等官方或社区出更激进的量化版本，或者干脆用 API 方式试水。注意，上面的权重体积只是模型的参数占用，实际部署还要加上 KV Cache、中间激活值、CUDA 运行时开销，通常要在纯权重基础上多留 20% 到 30% 显存，很多人的机器就是这么被“隐性显存”压垮的。

2. WorkBuddy 限免两周：真正该第一时间上手的功能

2.1 WorkBuddy 到底是什么：从聊天框到工作台

说完了模型，再聊 WorkBuddy。这个产品名字听起来像个“智能助手”，但你如果只把它当聊天框用，那就亏大了。

从目前公开的信息和社区反馈来看，WorkBuddy 的定位更像是一个“Agent 工作台”。它把模型能力拆成了几个模块：核心对话、Skill（技能包）、CodeBuddy（代码协作）、自定义指令、插件系统。核心对话就是常规的聊天交互；CodeBuddy 是面向代码场景的辅助能力；最值得研究的其实是 Skill 体系。

我的理解，Skill 就是把一个复杂的任务流程固化成“可复用的技能”。比如你每周要整理行业报告，与其每次手动给 AI 写一大段指令，不如把“搜索资料-提取要点-生成摘要-排版输出”这一整套流程封装成一个 Skill。下次你只需要说“跑一下周报”，WorkBuddy 就会自动执行整个流程。

这和“提示词模板”的区别在于，Skill 可以带工具调用、带参数、带条件分支。它不是一段文字，而是一小段可执行的工作流。如果你之前用过 Coze、Dify 这类 Agent 平台，会很容易理解。WorkBuddy 做的事情，是把这些能力做得更轻、更贴近个人桌面端工作场景。

2.2 两周免费期的最优使用顺序

免费期最忌讳的就是漫无目的地到处点，结果两周过去了什么都没沉淀下来。我给你一个我实践下来比较高效的使用顺序。

第一天到第三天：先跑通基础流程。注册账号、配置模型服务（如果有本地模型，可以把 API 地址接进去）、把常用的对话场景都试一遍。重点测它的代码能力，让 CodeBuddy 看一段你项目里的真实代码，看看理解能力如何。

第四天到第七天：把精力集中在 Skill 上。挑选 2 到 3 个你每周都会做的重复性任务，拆解成流程，做成 Skill。不会写 Skill 也没关系，先看看官方内置的 Skill 是怎么设计的，很多时候你只需要把参数改一改。

第八天到第十四天：做扩展和沉淀。配置自定义指令、整理插件、导出备份。如果你打算付费续用，最好用一个专门的“工作流文档”记录你所有配置项，包括 Skill 的 prompt、参数、插件依赖，这样一旦账号配置丢失，可以快速恢复。

2.3 Skill 和自定义指令：把个人工作流固化下来

我特别想强调一下自定义指令和 Skill 的组合用法。很多人不知道，自定义指令本质上是全局的 System Prompt，它会作用于你所有的会话；而 Skill 是局部能力，只在被调用时才生效。

举个例子。我给自己设了一条全局指令：在回答技术问题时，先给结论，再给推导过程，代码示例必须带注释。这条指令保证了我每次对话都能得到适合自己阅读习惯的回答。然后我再为具体任务建 Skill，比如“代码审查”：指定 CodeBuddy 关注变量命名、异常处理、边界条件、安全风险四个方面，输出时按严重程度分级，并给出建议修改代码。

这样组合的好处是，全局指令管“说话风格”，Skill 管“干什么事”，两者互不干扰。WorkBuddy 这类产品如果设计得足够好，会让这两层配置的优先级非常清晰：全局指令作为兜底，Skill 中的指令覆盖全局指令。你有没有用好这套机制，直接决定了它是“高级聊天框”还是“生产力工具”。

3. 从 Hy4 到 WorkBuddy：一套可落地的部署与接入方案

3.1 模型权重获取与推理服务部署

既然 Hy4 preview 是开源模型，那就绕不开本地部署。下面我按最常见的 vLLM 方案走一遍完整流程，这些命令你根据实际环境微调就能用。

第一步，下载模型权重。权重库的路径以官方发布为准，常见方式是直接用 Hugging Face 下载，或者从国内镜像站拉取。我习惯先建一个专门的目录来放模型：

mkdir -p /models/hy4-preview cd /models/hy4-preview # 拉取权重，仓库名以官方发布为准 git clone https://huggingface.co/hy4/Hy4-770B-MoE

第二步，安装推理框架。vLLM 是目前开源社区支持度最高的框架，性能好，OpenAI 兼容 API 也是内置的。装之前确认 CUDA 版本和显卡驱动：

pip install vllm

如果网络环境不好，或者想省时间，直接用 Docker 镜像也是常见选择，官方镜像一般会带好匹配版本的 CUDA 环境，省去很多编译的坑。

第三步，启动服务。这里有两个关键参数要提前想清楚：--tensor-parallel-size表示用几张卡并行切分模型，--max-model-len控制最大上下文长度，建议先设成 8192，跑稳了再往上加。

cd /models/hy4-preview python -m vllm.entrypoints.openai.api_server \ --model Hy4-770B-MoE \ --tensor-parallel-size 8 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --port 8000

启动成功后，你会看到终端打印出模型加载日志，然后监听在 8000 端口。

3.2 与 WorkBuddy 对接的关键步骤

模型服务跑起来之后，接入 WorkBuddy 就只是配置问题。WorkBuddy 支持接入自定义模型服务，我印象中只要填三个东西就行：API 地址、API Key（本地服务一般随便填）、模型名称。

API 地址填你运行 vLLM 那台机器的地址。如果 WorkBuddy 和模型不在同一台机器，需要把 8000 端口通过局域网暴露给 WorkBuddy 所在的主机。配置好之后，直接在 WorkBuddy 模型配置里测试连通性，能看到模型列表就说明对接成功了。

这里我踩过一个很典型的坑：本地 vLLM 服务使用的上下文长度如果是 8192，但 WorkBuddy 端把上下文设置了 32K，两边配置不一致，会出现调用报错或者输出被截断。解决方案是两边统一设置，或者在你不太确定的情况下一律取较小值。

另一个细节是并发设置。单张 80GB 卡跑 50B 激活参数的模型，并发通常只能支持 4 到 8 个请求，多了就会排队或者 OOM。如果你在 WorkBuddy 里同时挂多个自动流程，记得把并发数调低一点，否则会出现响应时间暴涨的现象。

3.3 本地化部署的取舍与成本估算

本地部署不是免费的，只是把成本从“按 token 付费”变成了“按硬件折旧付费”。我按两年折旧算一笔账：

我的建议是，如果你的需求是“持续跑业务”，并且数据比较敏感，本地部署是值得的；如果只是想尝鲜，或者任务量不大，用官方 API 加外部托管更划算。开源模型的价值不在于“每个人都自己跑一遍”，而在于“想跑的人随时有能力跑”。

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

4.1 部署与推理问题速查

下面这些排障经验，是我在不同开源模型部署中反复遇到过的，Hy4 preview 大概率也会碰到同样的问题。

OOM 是我见过最多的问题。很多人只看参数总量，不把 KV Cache 算进去。KV Cache 的大小受上下文长度和并发数影响非常大，8K 上下文可能只多占 10GB，但 32K 上下文加高并发，可能多占 30GB 甚至更多。部署前先按最坏情况估算显存，永远比跑崩了再排查省时。

4.2 使用与效果问题速查

模型部署好之后，实际使用中的问题往往不是“跑不起来”，而是“效果不对”。我把高频问题整理成一个清单。

第一类是回答过于泛泛，缺少深度。这种情况通常不是模型问题，而是没有给足够的角色和约束。在 WorkBuddy 里用自定义指令，或者在 Skill 里把输出格式、语气、思考路径写死，效果会立刻改善。

第二类是代码生成质量时好时坏。我的经验是，把上下文配好很重要：让 CodeBuddy 先读项目里的关键文件，再让它给出修改建议，而不是直接问一个宏大的问题。让模型先“理解项目背景”再“动手写码”，比反复调整 prompt 参数更管用。

第三类是 Skill 执行到一半中断。这通常是工具调用出错或者流程超时。你可以把 Skill 拆成更小的子流程，每个子流程单独测试通过后再组合。别指望一个 Skill 一次就能写出完美流程，它是需要逐步调优的“工作脚本”。

4.3 关于开源许可和免费期的几个提醒

最后聊几个容易忽略的合规和实际细节。

开源模型虽然“开源”，但不是没有约束。不同模型用的许可协议不一样，有的允许商用毫无限制，有的要求衍生模型同样开源，有的对月活用户数量有门槛。在把 Hy4 preview 接入任何商业项目之前，一定要去官方仓库把 LICENSE 文件读一遍，这个文件通常很短，花五分钟就能看完，但能避免后续一堆麻烦。

WorkBuddy 免费期也一样。限时两周免费，意味着时间是硬约束。我建议你开通当天就在手机日历里设一个到期提醒，提前两天做数据备份和导出。免费期结束之后，如果你决定不用，至少把你配置过的 Skill、自定义指令、插件列表都导出来，这些才是你真正沉淀下来的资产。

还有一点，如果你的业务涉及敏感数据，哪怕 WorkBuddy 免费，也要先确认数据是不是会经过云端、日志会不会被留存、配置里能不能关掉不必要的上传。我在这方面吃过亏：有一次给客户演示，一个自动流程把客户内部文件的摘要发到了云端去处理，最后花了半天解释和清理。数据合规这件事，免费只代表价格为零，不代表风险为零。

最后说一个我自己的小习惯。每次拿到这种“模型+工具”的组合，我都会先让它们在同一个具体场景里跑一遍，而不是分开试。比如我这次的做法是：用 Hy4 preview 搭一个本地代码知识库，然后在 WorkBuddy 里建一个“代码问答”Skill，指向这个本地服务。结果一次就打通了模型到底适不适合这个场景、工具链是否顺畅、中间有哪些环节会卡壳，全部一遍测出来。

这种验证方式，不管是面对新模型还是新工具，都值得保留。开源模型和 Agent 工作台，单拎出来都是好玩具，真正能成为生产力工具的关键，是你有没有把它们拧成一股绳。这两周，花点时间把“模型+WorkBuddy”这个组合在自己熟悉的场景里跑通，比看谁刷了多少评测分数都实在。