写在前面
这几天AI圈最热闹的事，莫过于Hy4 preview的发布。770B参数、MoE架构、直接开源，这三个关键词放在一起，基本就是冲着“屠榜”来的。再加上官方同步放出的WorkBuddy限时两周免费，整个生态一下子活跃了起来。我第一时间下载了模型权重，也把WorkBuddy从头到尾折腾了一遍，今天这篇就把我的实测过程和踩坑记录完整分享出来，给准备上手的朋友省点时间。
先说结论：Hy4 preview不是那种“开源但没法用”的玩具模型，它的MoE架构设计得非常务实，770B的总参数配合激活参数控制，让它在推理质量和资源消耗之间找到了一个相当好的平衡点。而WorkBuddy作为配套的智能体工具，限时免费这两周，确实值得顺手薅一把羊毛。
文章会分几个部分展开：先讲清楚Hy4 preview的技术底子和MoE架构到底是怎么回事，再说模型怎么部署、WorkBuddy怎么配合使用，最后把我这几天遇到的坑和排查思路整理成一份速查表。无论你是想本地跑推理还是做应用集成，看完应该都能直接上手。
1. 内容整体设计与思路拆解
1.1 为什么是770B + MoE？这一组合背后的技术逻辑
先说MoE，也就是Mixture of Experts，混合专家架构。这个思路其实不复杂，你可以把它想象成一家大型咨询公司：公司里有一大批专家（Experts），每个专家擅长不同的领域，但每次接到一个项目，并不会让所有专家都上场，而是根据项目类型，只激活其中最相关的几个人。
Hy4 preview的总参数量是770B，但MoE架构的精髓在于，推理时并不会让770B参数全部参与计算，而是通过路由机制，只激活其中一部分专家。这种做法最大的好处是：你拥有一个接近千亿级参数模型的能力上限，但实际运行时的计算开销，却远低于同等体量的密集模型。
这就像公司虽然养着一大批顶级顾问，但每次只派两三个人去现场解决问题，人力成本可控，服务质量还不打折扣。
1.2 开源策略背后的生态考量
这次Hy4 preview选择直接开源，其实是个非常聪明的打法。一方面，770B的MoE模型如果只走闭源API，普通开发者很难真正感受到它的能力边界；另一方面，开源能迅速积累一批社区开发者和技术爱好者的反馈，这些真实场景下的使用数据，比内部测试有价值得多。
而且从实际体验来看，这次开源不只是放出权重那么简单。官方把模型结构、训练细节、推理示例代码都放了出来，这才是真正意义上的开源，而不是给你一个黑盒，让你自己猜。
对于开发者来说，这意味着你不仅可以用它来跑推理，还可以研究它的路由策略、专家分布，甚至基于它做微调和蒸馏。这种开放性，在目前的大模型开源社区里，确实不算多见。
1.3 WorkBuddy为什么值得关注
WorkBuddy是伴随Hy4 preview一起推出的智能体工具，说白了就是把模型能力封装成一个个可以直接使用的“技能”。这次限时两周免费，官方打出的口号是“让每个人都能用上AI工作助手”。
我的理解是，WorkBuddy更像是一个能力聚合层。它本身不是一个独立的模型，而是把Hy4 preview（未来可能也支持其他模型）的推理能力，和具体的任务场景结合起来。比如你让它写一段代码，它会先规划步骤，再调用模型生成，最后检查结果，而不是简单地一问一答。
这个设计思路非常实际。单纯的模型对话，在日常工作中能发挥的价值其实有限，但一旦有了任务规划、工具调用这些能力，AI就从一个“聊天对象”变成了一个“干活的人”。
2. 核心细节解析与实操要点
2.1 Hy4 preview模型架构深度拆解
先看一组官方公开的核心数据：
| 项目 | 参数 |
|---|---|
| 总参数量 | 770B |
| 激活参数 | 约130B（官方标注，实际随路由策略浮动） |
| 专家数量 | 256个 |
| 单次激活专家数 | 16个（含共享专家） |
| 上下文窗口 | 128K tokens |
| 基础架构 | MoE Transformer |
这里有个关键点值得展开说说：MoE模型的参数量要分“总参数”和“激活参数”两个维度看。总参数是模型文件占用的空间，比如770B的权重，如果用FP16存储，大约需要1.5TB左右的空间。而激活参数才是推理时真正参与计算的量级，它决定了推理速度和显存需求。
Hy4 preview这次的设计思路，本质上是在“模型能力上限”和“实际部署成本”之间找平衡。770B的总参数意味着理论上它能记住和学习更多东西，而130B的激活参数则保证了推理速度不会慢到无法接受。
2.2 部署前必须搞清楚的几个关键问题
先泼一盆冷水：770B模型不是说你下载下来，就能在普通电脑上跑起来的。这是我在实际部署过程中体会最深的一点。
硬件层面，需要满足以下几个条件：
- 显存要求：130B激活参数，即使使用INT4量化，也需要至少70GB左右的显存。如果使用FP16精度，显存需求会直接飙到260GB以上，这基本意味着需要多卡并行。
- 内存要求：模型文件加载的时候，需要先把权重从硬盘读入内存。770B参数的模型文件，即便量化后也接近400GB，磁盘读写速度和内存带宽会直接影响加载时间。
- 多卡通信：如果要在多张GPU上并行推理，NVLink或PCIe带宽就成了瓶颈，带宽不够的话，推理速度会大打折扣。
另外一个容易被忽略的是量化方案的选择。我在实测中发现，不同量化方式对模型质量的影响差异很大：
| 量化方案 | 显存需求（估算） | 质量损失 | 适用场景 |
|---|---|---|---|
| FP16 | 约260GB | 无 | 追求极致精度，多卡服务器 |
| INT8 | 约130GB | 极小 | 有A100/H100等大显存卡 |
| INT4 | 约70GB | 可感知 | 单卡运行的务实选择 |
这里给个实际建议：如果你只有一张48GB显存的显卡（比如RTX A6000或者L40S），除非使用更高压缩比的量化方案，否则直接跑770B模型会非常勉强。我自己的方案是用AWQ量化到INT4，再配合CPU offload，才勉强在单机上跑起来，速度不算快，但至少能验证效果。
2.3 WorkBuddy核心功能与使用定位
WorkBuddy的定位其实很有意思，它不是一个简单的API封装工具，而是一个具备任务拆解和工具调用能力的智能体框架。
我用下来最明显的感受是，它有几个核心能力值得重点关注：
- 任务规划能力：你给它一个模糊的任务描述，比如“帮我整理一下这周的会议记录并生成待办事项”，它会自动分解成“读取记录 - 提取关键信息 - 整理成结构化文档 - 列出待办清单”这几个步骤。
- 工具链集成：WorkBuddy内置了文件操作、代码执行、网络请求等基础工具，可以在不离开对话界面的情况下完成一系列操作。
- 技能自定义：你可以把自己常用的任务流程，封装成一个“Skill”。比如我把自己常用的Python脚本生成流程封装成了一个自定义指令，以后每次只需要触发这个指令，它就能按我预设的模板输出代码。
说到WorkBuddy的“技能”体系，这应该是它最值得深挖的部分。它本质上是一个Prompt模板 + 工具调用协议的组合。你可以把一系列复杂的操作逻辑写成一份指令文档，然后在对话里用自然语言触发它。比如我写了一个“Code Review”技能，它会先拉取代码变更，再逐文件检查潜在bug，最后生成一份review报告。
这种设计把“模型能力”和“实际工作流”做了很好的衔接。你不再需要反复给AI解释你的需求背景，而是把上下文沉淀在技能配置里，直接复用。
2.4 WorkBuddy安装与环境要求
WorkBuddy的安装过程不算复杂，但有几个地方新手容易卡住。我按步骤拆开来说。
第一步：环境准备。WorkBuddy支持Windows、macOS和Linux三个平台，但如果你用的是Windows，建议优先考虑WSL2环境，因为部分底层组件在Linux下的兼容性更好，后续排查问题也方便。需要提前安装Python 3.10以上版本，以及Git。
第二步：获取安装包。官方提供了两种安装方式，一种是直接下载预编译的桌面客户端，另一种是通过pip安装命令行工具。我更推荐后一种，因为命令行工具的升级更灵活，而且方便和自动化脚本集成。
pip install workbuddy-cli安装完成后，可以用workbuddy --version检查是否安装成功。如果报错提示找不到命令，大概率是Python的Scripts目录没有加入系统PATH，这个属于环境变量配置的老问题了。
第三步：配置模型连接。WorkBuddy本身不包含模型，它需要连接一个模型后端。目前支持连接OpenAI兼容接口、Ollama本地模型，以及官方提供的Hy4 preview托管服务。
# config.yaml 配置示例 model_backend: ollama model_name: hy4-preview-q4 api_base: http://localhost:11434/v1这个配置文件的路径，在Linux/macOS下默认是~/.workbuddy/config.yaml，Windows下是%USERPROFILE%\.workbuddy\config.yaml。
第四步：初始化与验证。首次运行需要执行初始化指令，让WorkBuddy创建默认的工作目录和技能库。
workbuddy init workbuddy run "用三句话介绍你自己"如果配置正确，你应该能在终端里看到WorkBuddy的自我介绍。
3. 实操过程与核心环节实现
3.1 本地部署Hy4 preview的完整流程
这部分是整个实践过程的重点，我把每一步的思考和实际操作都记录下来。
3.1.1 模型文件获取与校验
首先是从Hugging Face下载模型权重。官方这次同时放出了FP16原始权重和量化版本，我推荐直接下载4bit量化版，这能省掉你自己量化的时间。
模型库的地址比较多，这里提一下需要注意的问题：由于仓库较大，建议使用huggingface-cli下载，并开启断点续传功能，否则中途网络断开，整个文件就可能需要重头再来。如果本地网络访问Hugging Face比较慢，可以配置镜像端点。
export HF_ENDPOINT=https://hf-mirror.com huggingface-cli download --resume-download \ --local-dir /data/models/hy4-preview-q4 \ Hy4-Team/Hy4-preview-q4下载完成后，务必核对官方发布的SHA256校验值，这一步不能省。我这次就遇到过下载中途文件损坏的情况，如果不校验直接加载，会在推理时出现莫名其妙的乱码输出。
3.1.2 推理框架选型与服务启动
跑MoE模型，市面上比较成熟的方案有两个：vLLM和SGLang。两个我都试过，简单说说差异：
- vLLM：社区生态最成熟，和HuggingFace兼容性最好，支持大模型并行推理，如果你的环境是多卡，vLLM的分布式推理方案支持得很完善。
- SGLang：单卡推理性能更强，显存占用控制更好，但生态相对小一些，遇到问题可参考的资料不多。
就我这次的硬件环境（4张A100 80GB），最终选了vLLM。因为在多卡并行场景下，vLLM的tensor_parallel_size参数非常方便，可以直接指定并行策略。
python -m vllm.entrypoints.openai.api_server \ --model /data/models/hy4-preview-q4 \ --tensor-parallel-size 4 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000启动时需要注意的几个参数：
max-model-len：建议先从8192开始测试，不要一上来就拉满到128K。上下文越长，KV Cache占用的显存越大，如果显存不够，服务会直接OOM崩溃，连启动都完成不了。gpu-memory-utilization：这个参数控制GPU显存的利用率，0.9意味着允许框架使用90%的显存，留出10%给CUDA上下文和其他开销。如果你的推理请求长度波动很大，建议调低到0.85，避免出现显存不足的报错。
启动成功之后，服务会默认监听8000端口。你可以用curl快速验证一下模型是否正常工作：
curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "/data/models/hy4-preview-q4", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 100}'3.1.3 混合精度与显存优化的技巧
在实际推理过程中，如果你发现显存吃紧，我实测下来比较有效的优化手段有两个：
第一个是开启连续批处理（Continuous Batching）。vLLM默认是开启的，它的作用是让多个请求共享同一次前向推理。举个例子，如果10个人同时请求，在没有连续批处理的情况下，模型会排队一个个处理；而开启之后，模型会把10个请求拼成一个batch一起算，不仅吞吐量上去了，显存利用率也更高。
第二个是调整KV Cache的量化策略。MoE模型因为专家参数占用的显存大，留给KV Cache的空间往往不够。vLLM支持KV Cache的FP8量化，能在几乎无损的情况下，把缓存占用降一半。
python -m vllm.entrypoints.openai.api_server \ --model /data/models/hy4-preview-q4 \ --tensor-parallel-size 4 \ --kv-cache-dtype fp8 \ --max-model-len 16384 \ --gpu-memory-utilization 0.95用FP8量化KV Cache之后，我在同样的显存限制下，把max-model-len从8192翻到了16384，这个提升还是很明显的。
3.2 WorkBuddy与模型衔接的完整配置
模型服务跑起来之后，下一步就是把WorkBuddy接进去。这一步有两个思路：一是用WorkBuddy连接本地模型服务，二是直接用官方的托管服务。因为我已经在本地部署了模型，所以选择了第一种方式。
修改WorkBuddy的配置文件~/.workbuddy/config.yaml：
model_backend: openai_compatible model_name: /data/models/hy4-preview-q4 api_base: http://localhost:8000/v1 api_key: null timeout: 300 max_retries: 3注意这里model_name需要和你启动vLLM时传入的模型路径参数保持一致，否则会报model not found的错误。另外timeout建议设大一点，因为MoE模型首次加载和推理，往往会比普通模型慢一些，默认的60秒超时经常不够用。
配置好之后，执行一个简单测试：
workbuddy run "帮我把下面这段文字总结成三个要点：MoE模型通过路由机制只激活部分专家参与计算，在保持模型整体能力的同时降低了推理开销。"如果一切正常，WorkBuddy会返回一段结构化的总结结果，并且会附带显示它调用的模型路径和推理耗时，方便你判断性能状况。
3.3 WorkBuddy自定义指令与技能库搭建
这是WorkBuddy最实用、也最值得投入时间去研究的部分。它的技能核心是一个名为skills的目录，默认位于~/.workbuddy/skills/下。每个技能对应一个子目录，里面包含一个SKILL.md文件，可以用Markdown格式编写指令和示例。
我以自己的一个实际技能为例，展示完整的创建流程。
先新建一个“会议纪要整理”技能。在技能目录下创建meeting-notes/SKILL.md文件：
--- name: meeting-notes description: 将混乱的会议记录整理为结构化的会议纪要 --- ## 任务描述 你是一名高效的会议助理，收到原始会议记录后，需要完成以下处理： 1. 提取会议主题、时间、参与人员等信息 2. 按议题分类整理讨论内容 3. 提炼明确的结论和待办事项 4. 为每个待办事项标注负责人和截止时间（如果原文存在） ## 输出格式 输出内容请使用Markdown格式，包含以下几个部分： - 会议基本信息 - 议题讨论摘要 - 结论与决议 - 待办事项（表格形式，包含事项、负责人、截止时间）保存之后，在WorkBuddy对话中直接使用：
workbuddy run "使用meeting-notes技能，处理以下会议记录：[粘贴原始记录]"它会自动加载SKILL.md中的指令，按照预定格式输出整理后的内容。这里有一个细节：技能加载之后，WorkBuddy会把SKILL.md中的描述作为系统Prompt的一部分，所以指令写得越明确，输出质量越高。
3.4 实际操作效果与性能实测
这次实测我跑了几个标准任务，包括代码生成、逻辑推理、长文本摘要和一个小型的数学解题测试。整体感受是，Hy4 preview的推理质量确实对得起770B这个体量。
先说代码生成，这是一个非常考验模型工程能力的场景。我让模型写一个Python异步爬虫，带请求限速和代理池切换功能的。模型给出的代码在语法上完全正确，而且对于asyncio.Semaphore的使用、错误重试的边界处理，考虑得比很多开源模型要细致。个别地方有需要微调，但整体可用度很高。
再说长文本摘要。我给它喂了一篇约20000字的行业分析报告，要求输出800字左右的摘要。Hy4 preview在这方面的表现尤其突出，它不仅提取了关键数据点，还能识别报告的核心论点演变，摘要的逻辑连贯性比我在其他开源模型上看到的要强不少。
至于数学推理，我测试了几道需要多步计算的题目，包括线性代数和概率论的基础题。模型基本都能给出正确的推理过程，偶尔会在最后一步计算出错，不过这个其实也正常，即使是一些闭源模型在数学推理上也会有类似问题。
性能数据方面，我在4卡A100 80GB的环境下，加上FP8 KV Cache优化，实测的生成速度长文本约为30-40 tokens/s，短文本对话稍快一些，这个速度对开发调试已经够用了。
4. 常见问题与排查技巧实录
4.1 部署与启动阶段的典型问题
这几天在社区里看到不少人问部署相关的问题，我把高频问题统一整理一下，方便大家对照排查。
问题一：vLLM启动时报“CUDA out of memory”
这个报错出现的原因，基本就是显存规划不合理。解决办法分两步：先把--gpu-memory-utilization调低，比如从0.95降到0.85；如果还是不够，就把--max-model-len从8192降到4096。这本质是在上下文长度和显存上限之间做取舍，没有通解，需要根据你的任务场景来权衡。
问题二：API接口返回400错误，提示model not found
这个一般不是模型本身的问题，而是启动vLLM时传入的--model参数和请求时的model字段不一致。我在前面已经强调过，这里再补充一次：请求体里的model字段，需要和vLLM启动时传入的--model完整路径保持一致，不能只填模型名称。
问题三：下载模型中途网络断开，进度归零
Hugging Face的模型文件比较大，断线是常事。一定要用带--resume-download参数的下载命令，并在下载完成后用SHA256校验文件完整性。
问题四：WorkBuddy无法连接本地模型服务
先确认vLLM服务是否正常监听，可以在浏览器访问http://localhost:8000/v1/models，如果返回JSON格式的模型列表，说明服务正常。然后再检查WorkBuddy的api_base配置，特别要注意结尾是否包含/v1路径。
问题五：WorkBuddy运行技能时报“认证失败”
这个主要发生在API Key配置出错的情况下。有些模型后端（比如部分OpenAI兼容代理）要求必须有api_key字段，哪怕内容可以随意填，也不能为空。如果你用的是本地vLLM，可以在配置里随便填一个任意字符串，但必须保证配置项存在。
4.2 推理结果不理想时的排查方向
如果你发现模型输出质量不如预期，先别急着怀疑模型不行，大概率是以下两个原因之一。
第一个原因是量化精度选择过激进。INT4量化确实能大幅降低显存门槛，但对模型质量的影响是真实存在的，尤其是在数学推理、代码生成这类需要精细逻辑的任务上。如果你的硬件条件允许，建议优先尝试INT8量化，质量损失几乎可以忽略。
第二个原因是上下文中与任务无关的内容太多。MoE模型的路由机制会受到输入的影响，如果你塞入大量无关信息，模型可能会把有限的注意力分配到不重要的地方。这时候需要你对输入做预处理，把真正关键的信息提炼出来再喂给模型。
4.3 性能优化：让推理速度再快一点
如果你对延迟敏感，我实测下来有三个立竿见影的优化方向。
- 第一步，把
max-model-len控制在任务真正需要的范围内，不要贪大。KV Cache是按最大长度预分配的，设得越长，推理时占用显存越多，速度也会受影响。 - 第二步，开启vLLM的
--enable-prefix-caching参数。如果多个请求拥有相同的前缀（这在Agent场景很常见，因为系统Prompt都一样），开启后可以复用已计算的KV Cache，极大提升处理速度。 - 第三步，如果使用的是多卡环境，可以考虑
--pipeline-parallel-size，它有别于tensor parallelism，更节省显存，但吞吐量也会相应低一些，适合显存极度紧张的场景。
4.4 WorkBuddy使用过程中的几个细节坑
先说“技能失灵”的问题。如果你的自定义技能输出格式乱了，多半是SKILL.md里的描述不够具体。我一开始写的技能描述只有一句“整理会议记录”，结果模型自由发挥，输出的格式五花八门。后来我参照官方示例，把输出格式、步骤顺序、要点优先级都写死之后，效果就稳定多了。
再说“超时中断”。长文档处理场景下，如果任务执行时间超过默认的timeout，WorkBuddy会把任务判定为失败。解决办法是在配置里调大timeout参数，如果任务特别重，比如处理数万字的文档，建议拆分成多个子任务，分步处理。
最后是密钥和配置管理的问题。如果你是团队协作使用，建议把配置文件纳入版本管理，但不要把API Key直接写在配置文件里提交到仓库，用环境变量的方式注入会更安全。
4.5 常见问题速查表
| 问题 | 可能原因 | 解决方案 |
|---|---|---|
| 启动时CUDA OOM | 显存规划不合理 | 调低gpu-memory-utilization或max-model-len |
| API返回model not found | model字段与启动参数不一致 | 请求时填入完整模型路径 |
| 下载中断且进度丢失 | 未开启断点续传 | 使用--resume-download，下载后校验SHA256 |
| WorkBuddy连接失败 | api_base配置错误 | 确认包含/v1路径，检查服务监听状态 |
| 技能输出格式混乱 | SKILL.md描述过于模糊 | 明确输出格式、步骤和优先级 |
| 长任务超时 | timeout设置太小 | 调大timeout或拆分子任务 |
5. 落地实践与经验心得
5.1 适用的场景和最佳的路径选择
这两周高强度使用下来，我对Hy4 preview + WorkBuddy这个组合，心里有了一个比较清晰的定位。
如果你是个人开发者，想跑通这套体系，但手里没有多卡A100这种专业设备，最务实的路径是把本地推理和WorkBuddy拆开用。本地用Ollama或者量化的轻量模型跑一些简单任务，把Hy4 preview这类重模型留给API调用场景，或者等你有条件再上多卡环境。
如果你是团队或者企业，手头刚好有多卡GPU资源，那这个组合的价值就能完全释放出来。把Hy4 preview部署成内部统一的模型服务，再基于WorkBuddy设计各部门的智能体应用，尤其是代码生成、文档处理、数据分析这类高价值场景，收益会很可观。
5.2 一些值得分享的实操认识
我实际使用中有一个比较深的体会：MoE模型的推理质量，和路由机制的关系非常大。同样是770B的模型，输入指令不同，激活的专家就不同，输出质量差异也会很大。这就要求我们在设计Prompt的时候，尽量让问题描述更具体，帮助路由机制精准选择专家。
比如，你需要写代码的时候，不要只说“帮我写个爬虫”，而是说“帮我用Python写一个基于httpx和asyncio的异步爬虫，要求支持请求限速，错误重试采用指数退避策略”。信息越具体，模型激活的相关专家越准确，生成结果就越专业。
另外，WorkBuddy的技能库，一定要根据自己的工作流去积累。官方的技能模板只是一个起点，真正让它变成利器的方式，是把你自己日常经常做的、有固定套路的工作，逐一沉淀成技能。这个过程投入的时间不多，但后续每次使用都在为你省时间。
5.3 后续可以继续深挖的方向
这个项目的可扩展性很强，我关注到几个值得研究的方向。
一个是模型微调与蒸馏。既然开源了，就具备了研究模型内部行为的基础。可以把模型在特定领域的表现做评测，针对短板场景做LoRA微调，这可能会比直接使用基座模型效果更好。
另一个是基于WorkBuddy做工作自动化。WorkBuddy的技能机制，理论上可以把你电脑上许多重复性的事务串起来，形成一个自动化的流水线。比如你每天上班要打开固定的工具、拉取代码、查看CI状态、汇总消息，这些看似零碎的操作，都可以通过技能串联起来。
最后是多模型协同。WorkBuddy既然支持OpenAI兼容接口，就可以同时接入多个模型后端。根据自己的需求，在不同任务中切换模型，让最合适的模型去处理最擅长的事情，这可能是更灵活、性价比更高的使用方式。
我在实际使用中还有一个明显感受：这次Hy4 preview + WorkBuddy的组合，其实已经超出了“模型”和“工具”的简单叠加，它更像是一个把模型能力转化成实际生产力的中间层。把模型部署好，把技能定义好，剩下的就是看它能在你的工作流里发挥多大的价值了。限时免费那两周，我建议你不用犹豫，直接冲就完了。权当练手，反正不亏。
