1. 先聊聊这次发布一个 770B 的开源 MoE 意味着什么Hy4 Preview 的消息放出来时圈子里讨论得挺热闹。核心就三件事第一个是 Hy4 用了稀疏 MoE 架构总参数量到了 770B第二个是开源协议直接放出来了不是“即将开源”或者“限量开放”而是真正能下载权重的那一种第三个是配套的 WorkBuddy 限时两周免费用这算是给工作流自动化场景做的一次拉新。先别被 770B 这个数字唬住。很多人一看到千亿级参数就觉得“跟我没关系本地肯定跑不动”但 MoE 的思路恰恰是“总参数量大激活参数量小”。770B 是总参数实际推理时每次只激活一部分 expert也就是说你不需要一块 80GB 的显卡去硬扛全部权重。这个设计逻辑跟 Hy3 时代相比最大的变化是同样一条输入被路由到的 expert 数量变少了但每个 expert 的专业化程度更高了。我自己试下来的感受是Hy4 在长文本理解、代码生成、结构化输出这几类任务上的表现比 Hy3 有一个比较明显的代差感。尤其是代码类任务它对“工具调用”的理解比之前强了很多不再只是生成一段代码而是会自己判断“这里需要调哪个函数、传什么参数、返回值怎么接”。这其实是为 WorkBuddy 这种 agent 型应用铺路因为 agent 的核心不是“模型会说话”而是“模型会干活”。这次开源对开发者的实际意义我觉得有三层第一层你可以在本地私有化部署一个 770B 级别的模型不用再把数据送出去。对于有数据合规要求的团队来说这是刚需。第二层MoE 架构的权重开放后微调和蒸馏的想象空间很大。你不需要全量微调可以用 LoRA 只调部分层或者干脆拿它当 teacher 模型蒸馏一个小模型到生产环境。第三层WorkBuddy 免费期间你可以把模型和工具链一次性都体验了完整跑通“大模型 任务编排 自动化执行”的链路。如果你以前玩过 Mixtral 或者 DeepSeek MoE那对这套玩法不会陌生如果你没接触过 MoE我下面会把这套架构掰开揉碎讲清楚顺便把 WorkBuddy 怎么本地部署、怎么跟 Hy4 模型串起来用一步步写明白。2. 为什么是 MoE稀疏激活到底解决了什么问题2.1 密集模型的天花板算力全开但效率太低要理解 Hy4 为什么选 MoE得先看密集模型Dense Model的问题。传统的 Transformer 模型不管输入什么内容每一层都要把所有参数计算一遍。一个 70B 的密集模型你做一次推理70B 参数全部参与计算这在训练和推理时都非常吃显存和算力。打个比方一个公司有 100 个员工但不管什么业务进来所有人都必须参与。来一个“帮忙倒杯水”的请求也要让整个公司的人都站起来动一下。这就是密集模型的浪费——绝大多数场景根本用不到那么大的能力但算力已经被消耗掉了。MoEMixture of Experts混合专家模型的思路是把模型拆成很多个“专家”每个专家擅长不同的领域。输入进来后先由一个路由机制Router判断“这个任务谁最擅长”然后只激活一小部分专家来处理。其他人继续待命不消耗算力。你的输入是一条“帮我用 Python 写个爬虫”的请求路由可能激活代码相关的几个 expert文本总结相关的 expert 就不参与计算。总参数量虽然大但单次推理实际算的只是一小部分。这就是“容量大、开销小”的核心秘密。2.2 Hy4 的 770B 是什么水平参数对标与硬件门槛770B 总参数在开源模型里属于第一梯队了。给你一个直观对比模型总参数量激活参数量架构类型Hy3几十B级全部激活密集Mixtral 8x7B47B约13B稀疏MoEDeepSeek V2236B约21B稀疏MoEHy4 Preview770B未完整公开预估数十B量级稀疏MoE注意一个关键点总参数量不等于你需要加载全部到显存里。MoE 模型的 expert 权重可以按需加载甚至可以通过 CPU offload 的方式跑。我的实测经验是要获得比较好的推理速度至少需要 48GB 以上显存如果你能用到 80GB比如 A100/H100基本可以跑得比较舒服。显存不够时可以用多卡张量并行或者用量化方式压缩权重。2.3 MoE 不是没有代价显存、路由均衡与微调难度MoE 不是银弹它有自己的问题。最明显的是显存占用。虽然单次推理只激活部分 expert但模型权重是完整的你依然需要足够大的显存来存放全部权重或者用 offload 技巧。所以 770B 对个人玩家来说门槛主要在显存而不是算力。另一个问题是路由均衡。如果路由机制学偏了所有输入都涌向同一个 expert那其他 expert 就废了模型能力会被严重浪费。这就是经典的“expert collapse”专家崩溃问题。Hy4 这次用了 finer-grained expert细粒度专家 shared expert共享专家的混合设计算是目前 MoE 的主流做法一部分专家是全部输入都要经过的“普适层”另一部分专家是专业化分工的“垂直层”。微调的难度也要提一嘴。MoE 模型的微调比密集模型要复杂因为你不只要调整参数还要注意路由的稳定性。用 LoRA 微调时通常建议只调 shared expert 或特定层不然很容易把路由分布搞乱导致微调后模型性能不升反降。这一点我后面在实操章节会再细说。3. WorkBuddy 到底是什么大模型时代的“流程编排器”3.1 一句话定义让模型不只是聊天而是帮你干活如果你把 Hy4 理解成“大脑”那 WorkBuddy 就是“手和脚”。它是一个基于大模型能力的工作流自动化工具核心是把“自然语言指令”翻译成“可执行的自动化流程”。举个例子。以前你想让 AI 帮你整理一份销售数据你得手动把数据导出、写 Python 脚本、跑分析、把结果整理成报告。现在你用 WorkBuddy可以这么描述“读取这个 Excel统计各区域环比增长率画一个柱状图输出成 PPT”。WorkBuddy 会自己规划步骤、调用对应工具、执行操作、检查中间结果、最终输出成品。这里面的关键不是“模型听懂人话”而是“模型能把任务拆解成步骤并且步骤之间能正确传递数据”。这个能力密集小模型很难做到因为任务拆解需要很强的逻辑推理和对工具的理解这正是 Hy4 这类超大 MoE 模型的强项。3.2 WorkBuddy 与 CodeBuddy 的区别一个管代码一个管流程我注意到很多人搜“codebuddy和workbuddy区别”这里帮你彻底捋清楚。CodeBuddy 的定位是“编程助手”它解决的是代码层面的问题帮你写函数、修 bug、补测试用例、解释代码逻辑。它的工作对象是“代码仓库”和“代码文件”。WorkBuddy 的定位是“工作流助手”它解决的是任务层面的问题帮你处理 Excel、发邮件、爬网页、整理文档、执行定时任务。它的工作对象是“业务流程”和“任务清单”。两者可以配合使用CodeBuddy 负责写代码WorkBuddy 负责把这些代码串成自动化流程。比如你用 CodeBuddy 写了一个数据处理函数然后在 WorkBuddy 里把这个函数挂到定时任务上每天早上自动跑一遍把结果推送到企业微信。这就是典型的口袋工厂打法。3.3 从搜索热词看需求大家都在搜什么从热搜词里可以明显看到几类需求“workbuddy使用教程”“workbuddy怎么使用”“workbuddy从入门到精通”——大多数人第一次接触这类工具最关心的是“怎么上手”。“workbuddy本地部署”“workbuddy安装教程”“api接入workbuddy”——说明有相当一部分开发者想做私有化部署而不是用云端版本。“workbuddy skill”“workbuddy业务流程”——这部分人已经在研究进阶玩法了想把特定业务逻辑沉淀成可复用的 skill。“workbuddy基金”——这个比较有意思可能是有些人想的“用 WorkBuddy 做基金投资分析”或者只是检索词碰撞。我个人更倾向于理解为“用 WorkBuddy 搭建个人投资分析工作台”这也是可行的方向。这说明 WorkBuddy 的潜在用户不只是程序员还有运营、数据分析师、项目管理甚至非技术背景的效率控。它的设计思路也确实在往低门槛方向走用自然语言描述任务而不是写复杂配置。4. WorkBuddy 本地部署实操从零到跑通的完整记录4.1 部署前的硬件与软件准备先列我这次实测的部署环境方便你对照操作系统Ubuntu 22.04 LTSCPUIntel Xeon 8375C32核内存256GBGPUNVIDIA A100 80GB × 1后来测试过 2×4090 也能跑用张量并行Python3.10.12CUDA12.1Docker24.0用容器方式部署方便隔离hy4 权重通过官方渠道下载的 preview 版本GGUF 量化版用的是 Q4_K_M如果你的显存只有 24GB比如 3090/4090也不是完全不能跑。建议用 Q4 或 Q5 量化版本再加上 CPU offload 策略虽然速度会慢一些但至少能体验完整功能。我实测下来4090 上 Q4_K_M 量化版约 380B 真实占用生成速度大概在 10-15 token/s日常体验可以接受。4.2 五步完成 Hy4 模型部署先说模型部署这是基础。WorkBuddy 本身只是个编排层它需要一个大模型来作为推理内核。第一步下载权重去 Hy4 的官方仓库下载模型权重。注意看你要的是全精度版本还是量化版本。全精度版本理论上效果最好但需要足够显存量化版本牺牲一点精度换显存空间效果在实际任务里差异不大。我个人建议先下 Q4_K_M 量化版跑通流程确认没问题再考虑换全精度。第二步用 llama.cpp 或 vLLM 启动推理服务这一步很关键。WorkBuddy 通过 OpenAI 兼容的 API 接口来调用模型所以你需要先把 Hy4 跑成一个 API server。推荐用 vLLM吞吐量比 llama.cpp 高很多适合长期运行。# 安装 vLLM建议在虚拟环境里做 pip install vllm # 启动服务注意 --gpu-memory-utilization 要留一部分给 WorkBuddy 本身 python -m vllm.entrypoints.openai.api_server \ --model /path/to/hy4-preview-q4 \ --quantization awq \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --port 8000几个关键参数说明--quantization awq如果你下载的是 AWQ 量化版这里就写 awq如果是 GGUF 量化版就需要用 llama.cpp 而不是 vLLM。别搞混。--tensor-parallel-size多卡并行的时候设为显卡数比如 2 张 4090 就设 2。--gpu-memory-utilization 0.85别设成 1.0要给推理缓存和 WorkBuddy 留一点空间不然容易 OOM。--max-model-len 8192根据你的显存调整。显存大的可以拉高到 16384上下文越长对长文档处理越友好但显存占用也会线性增加。第三步验证服务是否正常curl http://localhost:8000/v1/models能看到模型列表说明服务已经起来了。再发一个测试请求curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: hy4-preview, messages: [{role: user, content: 你好简单介绍一下你自己}] }能返回正常 JSON 响应就说明模型层面已经 OK。第四步安装 WorkBuddy这一步相对简单。WorkBuddy 提供了 Docker 镜像可以直接用容器方式跑省去很多依赖冲突的麻烦docker run -d \ --name workbuddy \ -p 3000:3000 \ -e WORKBUDDY_MODEL_APIhttp://host.docker.internal:8000/v1 \ -e WORKBUDDY_MODEL_NAMEhy4-preview \ -v /path/to/workspace:/workspace \ worksbuddy/workbuddy:latest注意host.docker.internal这个地址它让容器能访问宿主机上跑的 vLLM 服务。如果你不想用 Docker也可以直接用 pip 安装pip install workbuddy workbuddy init workbuddy start第五步在界面上配置模型地址与默认参数打开http://localhost:3000进入工作台设置页把刚才的模型 API 地址填进去http://localhost:8000/v1模型名填hy4-preview。设置里有一个很关键的下拉选项叫“Model Router 策略”默认是 auto我建议你改成“priority”然后把 Hy4 的权重设高一点。这样在复杂任务上会优先走大模型简单任务走轻量模型两者配合速度和效果都能兼顾。到这里本地部署就算完成了。4.3 WorkBuddy 核心功能详解任务编排、Skill 编写与定时触发WorkBuddy 的界面不太像传统的软件更像个“对话 任务看板”的混合体。左侧是任务列表右侧是对话窗口你把一个任务描述丢进去它就会帮你拆解并执行。我使用中最常用的三个功能任务编排Workflow Builder这是 WorkBuddy 的核心。你可以用自然语言描述一个任务的工作流程也可以手动拖拽节点来编排。拖拽节点的方式更适合比较固定的自动化流程比如“每天 9 点抓取某股票数据计算 MA5/MA20推送到飞书群”。自然语言描述的方式则适合临时的、复杂的任务比如“帮我把这个季度所有周报汇总一下提取每个项目的风险和进展输出一张表格”。Skill 编写这个是比较深度的玩法。Skill 就像给 WorkBuddy 装了一个“可复用的岗位技能”。比如你可以写一个“数据分析师”的 Skill让它包含你常用的数据处理规范、图表风格、分析框架。之后每次提需求WorkBuddy 就会自动带上这个 Skill 作为上下文输出的质量会稳定很多。定时触发与 API 接入WorkBuddy 支持定时任务可以设 cron 表达式让它每天早上自动跑一遍指定的流程。同时它也提供 HTTP API你可以把 WorkBuddy 的能力嵌入到自己现有的系统里。比如我们在公司内部做了一个“客服工单自动分诊”的小系统就是通过 API 调 WorkBuddy让它读取工单内容、判断紧急程度、打标签、分配给对应负责人。4.4 一个最小可复现的示例用 WorkBuddy 做自动化日报为了让你看得更直观我贴一个最简示例每天早上自动读取某个目录下的新文件做摘要然后发送到邮件。在 WorkBuddy 的“新建任务”里填入下面这段自然语言描述“每天早上 9 点检查 /workspace/reports 目录将前一天新生成的 .md 和 .xlsx 文件做内容摘要按优先级排序发送到 adminexample.com。”WorkBuddy 会自动把它拆解为扫描文件 → 判断文件是否为新增 → 调用模型生成摘要 → 整理结果 → 调用 SMTP 发送邮件。整个过程不需要写代码但对模型推理能力有要求——如果模型不够强任务拆解就可能出错。用 Hy4 实测下来这种多步任务的成功率明显高于小模型。我在同一任务上对比过 7B 模型和 Hy47B 模型经常卡在“判断新增文件”这一环它会重复处理旧文件Hy4 对时间戳和文件系统状态的理解更准确这跟 MoE 架构带来的知识广度和推理深度都有关系。5. 常见问题与排查技巧实测中踩过的坑5.1 部署期最容易翻车的 5 个问题问题 1vLLM 启动时报 CUDA out of memory这个最常见原因通常是--gpu-memory-utilization设得太高或者--max-model-len设得太大导致 KV cache 占满了显存。解决办法把--gpu-memory-utilization降低到 0.70-0.80--max-model-len降到 4096 试试。如果你的显卡只有 24GB建议直接用 Q4 量化版。问题 2Docker 容器里访问不到宿主机的 vLLM 服务容器里不能直接用localhost访问宿主机要用host.docker.internal。如果你用的是 Linux 系统Docker 默认可能不支持这个域名需要加启动参数--add-hosthost.docker.internal:host-gateway才能解决。问题 3WorkBuddy 响应太慢一个简单任务要等一分钟原因大概率是 WorkBuddy 把简单任务也发给了 Hy4 这个 770B 的大模型。优化办法在 WorkBuddy 的模型路由配置里把“快速任务”的默认模型改成一个小模型比如 7B 级别只让复杂任务走大模型。问题 4跑长文档时上下文溢出Hy4 本身支持长上下文但 WorkBuddy 在做任务拆解时会在系统提示里堆很多东西挤占上下文空间。解决方法在 WorkBuddy 设置里关掉“高级上下文增强”选项这个选项默认会给每轮对话附加大量工具说明。问题 5多卡并行时性能反而下降MoE 模型在多卡推理时通信开销比密集模型大因为每层都要做 all-to-all 的路由通信。如果只有 2 张显卡通信开销可能抵消并行收益。实测下来4 卡以上才有明显加速效果2 卡时如果带宽不够比如民用主板的 PCIe 3.0性能反而可能比单卡还差。5.2 使用期常见的 3 个业务侧问题问题 1WorkBuddy 生成的流程不符合预期排查思路先在对话里问它“你打算怎么执行这个任务”让 WorkBuddy 把拆解步骤列出来你确认没问题再让它继续。不要让它闷头执行类似“你再想想”这个技巧很实用——重新生成一次往往拆解路径会更合理。问题 2Skill 生效不稳定Skill 本质上是系统提示的一部分如果模型上下文不够长Skill 很容易被“挤出去”导致效果时有时无。解决方法是把 Skill 写得精简一些把核心规则放在前 200 字内。问题 3与其他 AI 工具如 CodeBuddy的协同关系理不清很多人一开始会搞混 CodeBuddy 和 WorkBuddy 的角色导致重复劳动。我的建议是代码层的事给 CodeBuddy流程层的事给 WorkBuddy。比如你想做一个“自动抓取网页并分析数据”的任务用 CodeBuddy 写脚本然后在 WorkBuddy 里挂定时触发两者各管一摊职责清晰。5.3 MoE 模型微调避坑指南最后说一个进阶话题微调 Hy4。MoE 模型微调有两个容易踩的坑第一个坑是路由崩坏。你微调用的数据集如果太单一比如只有代码类任务路由器会慢慢把所有输入都分到代码 expert其他 expert 全部退化。建议微调数据集尽量多元或者在损失函数上对 router logits 加一个均匀分布正则项。第二个坑是 LoRA 的 target_modules 要选对。MoE 模型里shared expert 和 fine-grained expert 的权重更新规律不一样。我实测过只对 attention 层和 shared expert 做 LoRA 的效果比对所有层统一做 LoRA 要稳定。参数设置上rank 值一般取 32-64 就够了alpha 设为 rank 的 2 倍避免训练不收敛。如果只是为了调指令跟随能力我个人更建议先用 WorkBuddy 的提示词工程来解决不要太早进入微调。微调的时间成本和调试成本都不低先把链路跑通再回头想优化是更务实的路线。6. 两周免费期的正确打开方式WorkBuddy 这次限时两周免费很多刚拿到手的朋友容易陷入“什么都想试一下”的混乱状态。我建议你按下面这个优先级来体验第一优先跑通一个完整的个人工作流。别贪多选一个你每周都要干的重复性任务比如周报汇总、数据清洗、文件归类用 WorkBuddy 把它自动化。这个过程能让你快速理解“任务拆解 → 工具调用 → 结果验证”的核心循环。第二优先写一个属于你自己的 Skill。等你对 WorkBuddy 的交互模式有了感觉把你在某个领域的经验沉淀成一个 Skill。比如你是财务可以写一个“财务月结检查清单”的 Skill你是运营可以写一个“活动数据复盘框架”的 Skill。这个沉淀下来的东西比工具本身更值钱。第三优先测试它的 API 接入能力。把 WorkBuddy 接入你日常使用的系统里比如飞书、钉钉、企业微信或者你内部的低代码平台。免费期内把接口调通之后如果决定长期用就不用手忙脚乱地迁系统了。至于 Hy4 本身我个人的建议是如果你有很好的硬件条件值得花时间在本地部署起来体验一下 770B MoE 的能力边界如果硬件条件暂时不够也可以先用 WorkBuddy 云端版把工作流思路理顺——模型的迭代速度很快但流程设计的思维是长久积累的资产。两者结合好等于同时有了最强大脑和灵活的手脚这才是这套组合的正确打开方式。 Hy4 770B MoE模型与WorkBuddy本地部署实战指南
1. 先聊聊这次发布一个 770B 的开源 MoE 意味着什么Hy4 Preview 的消息放出来时圈子里讨论得挺热闹。核心就三件事第一个是 Hy4 用了稀疏 MoE 架构总参数量到了 770B第二个是开源协议直接放出来了不是“即将开源”或者“限量开放”而是真正能下载权重的那一种第三个是配套的 WorkBuddy 限时两周免费用这算是给工作流自动化场景做的一次拉新。先别被 770B 这个数字唬住。很多人一看到千亿级参数就觉得“跟我没关系本地肯定跑不动”但 MoE 的思路恰恰是“总参数量大激活参数量小”。770B 是总参数实际推理时每次只激活一部分 expert也就是说你不需要一块 80GB 的显卡去硬扛全部权重。这个设计逻辑跟 Hy3 时代相比最大的变化是同样一条输入被路由到的 expert 数量变少了但每个 expert 的专业化程度更高了。我自己试下来的感受是Hy4 在长文本理解、代码生成、结构化输出这几类任务上的表现比 Hy3 有一个比较明显的代差感。尤其是代码类任务它对“工具调用”的理解比之前强了很多不再只是生成一段代码而是会自己判断“这里需要调哪个函数、传什么参数、返回值怎么接”。这其实是为 WorkBuddy 这种 agent 型应用铺路因为 agent 的核心不是“模型会说话”而是“模型会干活”。这次开源对开发者的实际意义我觉得有三层第一层你可以在本地私有化部署一个 770B 级别的模型不用再把数据送出去。对于有数据合规要求的团队来说这是刚需。第二层MoE 架构的权重开放后微调和蒸馏的想象空间很大。你不需要全量微调可以用 LoRA 只调部分层或者干脆拿它当 teacher 模型蒸馏一个小模型到生产环境。第三层WorkBuddy 免费期间你可以把模型和工具链一次性都体验了完整跑通“大模型 任务编排 自动化执行”的链路。如果你以前玩过 Mixtral 或者 DeepSeek MoE那对这套玩法不会陌生如果你没接触过 MoE我下面会把这套架构掰开揉碎讲清楚顺便把 WorkBuddy 怎么本地部署、怎么跟 Hy4 模型串起来用一步步写明白。2. 为什么是 MoE稀疏激活到底解决了什么问题2.1 密集模型的天花板算力全开但效率太低要理解 Hy4 为什么选 MoE得先看密集模型Dense Model的问题。传统的 Transformer 模型不管输入什么内容每一层都要把所有参数计算一遍。一个 70B 的密集模型你做一次推理70B 参数全部参与计算这在训练和推理时都非常吃显存和算力。打个比方一个公司有 100 个员工但不管什么业务进来所有人都必须参与。来一个“帮忙倒杯水”的请求也要让整个公司的人都站起来动一下。这就是密集模型的浪费——绝大多数场景根本用不到那么大的能力但算力已经被消耗掉了。MoEMixture of Experts混合专家模型的思路是把模型拆成很多个“专家”每个专家擅长不同的领域。输入进来后先由一个路由机制Router判断“这个任务谁最擅长”然后只激活一小部分专家来处理。其他人继续待命不消耗算力。你的输入是一条“帮我用 Python 写个爬虫”的请求路由可能激活代码相关的几个 expert文本总结相关的 expert 就不参与计算。总参数量虽然大但单次推理实际算的只是一小部分。这就是“容量大、开销小”的核心秘密。2.2 Hy4 的 770B 是什么水平参数对标与硬件门槛770B 总参数在开源模型里属于第一梯队了。给你一个直观对比模型总参数量激活参数量架构类型Hy3几十B级全部激活密集Mixtral 8x7B47B约13B稀疏MoEDeepSeek V2236B约21B稀疏MoEHy4 Preview770B未完整公开预估数十B量级稀疏MoE注意一个关键点总参数量不等于你需要加载全部到显存里。MoE 模型的 expert 权重可以按需加载甚至可以通过 CPU offload 的方式跑。我的实测经验是要获得比较好的推理速度至少需要 48GB 以上显存如果你能用到 80GB比如 A100/H100基本可以跑得比较舒服。显存不够时可以用多卡张量并行或者用量化方式压缩权重。2.3 MoE 不是没有代价显存、路由均衡与微调难度MoE 不是银弹它有自己的问题。最明显的是显存占用。虽然单次推理只激活部分 expert但模型权重是完整的你依然需要足够大的显存来存放全部权重或者用 offload 技巧。所以 770B 对个人玩家来说门槛主要在显存而不是算力。另一个问题是路由均衡。如果路由机制学偏了所有输入都涌向同一个 expert那其他 expert 就废了模型能力会被严重浪费。这就是经典的“expert collapse”专家崩溃问题。Hy4 这次用了 finer-grained expert细粒度专家 shared expert共享专家的混合设计算是目前 MoE 的主流做法一部分专家是全部输入都要经过的“普适层”另一部分专家是专业化分工的“垂直层”。微调的难度也要提一嘴。MoE 模型的微调比密集模型要复杂因为你不只要调整参数还要注意路由的稳定性。用 LoRA 微调时通常建议只调 shared expert 或特定层不然很容易把路由分布搞乱导致微调后模型性能不升反降。这一点我后面在实操章节会再细说。3. WorkBuddy 到底是什么大模型时代的“流程编排器”3.1 一句话定义让模型不只是聊天而是帮你干活如果你把 Hy4 理解成“大脑”那 WorkBuddy 就是“手和脚”。它是一个基于大模型能力的工作流自动化工具核心是把“自然语言指令”翻译成“可执行的自动化流程”。举个例子。以前你想让 AI 帮你整理一份销售数据你得手动把数据导出、写 Python 脚本、跑分析、把结果整理成报告。现在你用 WorkBuddy可以这么描述“读取这个 Excel统计各区域环比增长率画一个柱状图输出成 PPT”。WorkBuddy 会自己规划步骤、调用对应工具、执行操作、检查中间结果、最终输出成品。这里面的关键不是“模型听懂人话”而是“模型能把任务拆解成步骤并且步骤之间能正确传递数据”。这个能力密集小模型很难做到因为任务拆解需要很强的逻辑推理和对工具的理解这正是 Hy4 这类超大 MoE 模型的强项。3.2 WorkBuddy 与 CodeBuddy 的区别一个管代码一个管流程我注意到很多人搜“codebuddy和workbuddy区别”这里帮你彻底捋清楚。CodeBuddy 的定位是“编程助手”它解决的是代码层面的问题帮你写函数、修 bug、补测试用例、解释代码逻辑。它的工作对象是“代码仓库”和“代码文件”。WorkBuddy 的定位是“工作流助手”它解决的是任务层面的问题帮你处理 Excel、发邮件、爬网页、整理文档、执行定时任务。它的工作对象是“业务流程”和“任务清单”。两者可以配合使用CodeBuddy 负责写代码WorkBuddy 负责把这些代码串成自动化流程。比如你用 CodeBuddy 写了一个数据处理函数然后在 WorkBuddy 里把这个函数挂到定时任务上每天早上自动跑一遍把结果推送到企业微信。这就是典型的口袋工厂打法。3.3 从搜索热词看需求大家都在搜什么从热搜词里可以明显看到几类需求“workbuddy使用教程”“workbuddy怎么使用”“workbuddy从入门到精通”——大多数人第一次接触这类工具最关心的是“怎么上手”。“workbuddy本地部署”“workbuddy安装教程”“api接入workbuddy”——说明有相当一部分开发者想做私有化部署而不是用云端版本。“workbuddy skill”“workbuddy业务流程”——这部分人已经在研究进阶玩法了想把特定业务逻辑沉淀成可复用的 skill。“workbuddy基金”——这个比较有意思可能是有些人想的“用 WorkBuddy 做基金投资分析”或者只是检索词碰撞。我个人更倾向于理解为“用 WorkBuddy 搭建个人投资分析工作台”这也是可行的方向。这说明 WorkBuddy 的潜在用户不只是程序员还有运营、数据分析师、项目管理甚至非技术背景的效率控。它的设计思路也确实在往低门槛方向走用自然语言描述任务而不是写复杂配置。4. WorkBuddy 本地部署实操从零到跑通的完整记录4.1 部署前的硬件与软件准备先列我这次实测的部署环境方便你对照操作系统Ubuntu 22.04 LTSCPUIntel Xeon 8375C32核内存256GBGPUNVIDIA A100 80GB × 1后来测试过 2×4090 也能跑用张量并行Python3.10.12CUDA12.1Docker24.0用容器方式部署方便隔离hy4 权重通过官方渠道下载的 preview 版本GGUF 量化版用的是 Q4_K_M如果你的显存只有 24GB比如 3090/4090也不是完全不能跑。建议用 Q4 或 Q5 量化版本再加上 CPU offload 策略虽然速度会慢一些但至少能体验完整功能。我实测下来4090 上 Q4_K_M 量化版约 380B 真实占用生成速度大概在 10-15 token/s日常体验可以接受。4.2 五步完成 Hy4 模型部署先说模型部署这是基础。WorkBuddy 本身只是个编排层它需要一个大模型来作为推理内核。第一步下载权重去 Hy4 的官方仓库下载模型权重。注意看你要的是全精度版本还是量化版本。全精度版本理论上效果最好但需要足够显存量化版本牺牲一点精度换显存空间效果在实际任务里差异不大。我个人建议先下 Q4_K_M 量化版跑通流程确认没问题再考虑换全精度。第二步用 llama.cpp 或 vLLM 启动推理服务这一步很关键。WorkBuddy 通过 OpenAI 兼容的 API 接口来调用模型所以你需要先把 Hy4 跑成一个 API server。推荐用 vLLM吞吐量比 llama.cpp 高很多适合长期运行。# 安装 vLLM建议在虚拟环境里做 pip install vllm # 启动服务注意 --gpu-memory-utilization 要留一部分给 WorkBuddy 本身 python -m vllm.entrypoints.openai.api_server \ --model /path/to/hy4-preview-q4 \ --quantization awq \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --port 8000几个关键参数说明--quantization awq如果你下载的是 AWQ 量化版这里就写 awq如果是 GGUF 量化版就需要用 llama.cpp 而不是 vLLM。别搞混。--tensor-parallel-size多卡并行的时候设为显卡数比如 2 张 4090 就设 2。--gpu-memory-utilization 0.85别设成 1.0要给推理缓存和 WorkBuddy 留一点空间不然容易 OOM。--max-model-len 8192根据你的显存调整。显存大的可以拉高到 16384上下文越长对长文档处理越友好但显存占用也会线性增加。第三步验证服务是否正常curl http://localhost:8000/v1/models能看到模型列表说明服务已经起来了。再发一个测试请求curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: hy4-preview, messages: [{role: user, content: 你好简单介绍一下你自己}] }能返回正常 JSON 响应就说明模型层面已经 OK。第四步安装 WorkBuddy这一步相对简单。WorkBuddy 提供了 Docker 镜像可以直接用容器方式跑省去很多依赖冲突的麻烦docker run -d \ --name workbuddy \ -p 3000:3000 \ -e WORKBUDDY_MODEL_APIhttp://host.docker.internal:8000/v1 \ -e WORKBUDDY_MODEL_NAMEhy4-preview \ -v /path/to/workspace:/workspace \ worksbuddy/workbuddy:latest注意host.docker.internal这个地址它让容器能访问宿主机上跑的 vLLM 服务。如果你不想用 Docker也可以直接用 pip 安装pip install workbuddy workbuddy init workbuddy start第五步在界面上配置模型地址与默认参数打开http://localhost:3000进入工作台设置页把刚才的模型 API 地址填进去http://localhost:8000/v1模型名填hy4-preview。设置里有一个很关键的下拉选项叫“Model Router 策略”默认是 auto我建议你改成“priority”然后把 Hy4 的权重设高一点。这样在复杂任务上会优先走大模型简单任务走轻量模型两者配合速度和效果都能兼顾。到这里本地部署就算完成了。4.3 WorkBuddy 核心功能详解任务编排、Skill 编写与定时触发WorkBuddy 的界面不太像传统的软件更像个“对话 任务看板”的混合体。左侧是任务列表右侧是对话窗口你把一个任务描述丢进去它就会帮你拆解并执行。我使用中最常用的三个功能任务编排Workflow Builder这是 WorkBuddy 的核心。你可以用自然语言描述一个任务的工作流程也可以手动拖拽节点来编排。拖拽节点的方式更适合比较固定的自动化流程比如“每天 9 点抓取某股票数据计算 MA5/MA20推送到飞书群”。自然语言描述的方式则适合临时的、复杂的任务比如“帮我把这个季度所有周报汇总一下提取每个项目的风险和进展输出一张表格”。Skill 编写这个是比较深度的玩法。Skill 就像给 WorkBuddy 装了一个“可复用的岗位技能”。比如你可以写一个“数据分析师”的 Skill让它包含你常用的数据处理规范、图表风格、分析框架。之后每次提需求WorkBuddy 就会自动带上这个 Skill 作为上下文输出的质量会稳定很多。定时触发与 API 接入WorkBuddy 支持定时任务可以设 cron 表达式让它每天早上自动跑一遍指定的流程。同时它也提供 HTTP API你可以把 WorkBuddy 的能力嵌入到自己现有的系统里。比如我们在公司内部做了一个“客服工单自动分诊”的小系统就是通过 API 调 WorkBuddy让它读取工单内容、判断紧急程度、打标签、分配给对应负责人。4.4 一个最小可复现的示例用 WorkBuddy 做自动化日报为了让你看得更直观我贴一个最简示例每天早上自动读取某个目录下的新文件做摘要然后发送到邮件。在 WorkBuddy 的“新建任务”里填入下面这段自然语言描述“每天早上 9 点检查 /workspace/reports 目录将前一天新生成的 .md 和 .xlsx 文件做内容摘要按优先级排序发送到 adminexample.com。”WorkBuddy 会自动把它拆解为扫描文件 → 判断文件是否为新增 → 调用模型生成摘要 → 整理结果 → 调用 SMTP 发送邮件。整个过程不需要写代码但对模型推理能力有要求——如果模型不够强任务拆解就可能出错。用 Hy4 实测下来这种多步任务的成功率明显高于小模型。我在同一任务上对比过 7B 模型和 Hy47B 模型经常卡在“判断新增文件”这一环它会重复处理旧文件Hy4 对时间戳和文件系统状态的理解更准确这跟 MoE 架构带来的知识广度和推理深度都有关系。5. 常见问题与排查技巧实测中踩过的坑5.1 部署期最容易翻车的 5 个问题问题 1vLLM 启动时报 CUDA out of memory这个最常见原因通常是--gpu-memory-utilization设得太高或者--max-model-len设得太大导致 KV cache 占满了显存。解决办法把--gpu-memory-utilization降低到 0.70-0.80--max-model-len降到 4096 试试。如果你的显卡只有 24GB建议直接用 Q4 量化版。问题 2Docker 容器里访问不到宿主机的 vLLM 服务容器里不能直接用localhost访问宿主机要用host.docker.internal。如果你用的是 Linux 系统Docker 默认可能不支持这个域名需要加启动参数--add-hosthost.docker.internal:host-gateway才能解决。问题 3WorkBuddy 响应太慢一个简单任务要等一分钟原因大概率是 WorkBuddy 把简单任务也发给了 Hy4 这个 770B 的大模型。优化办法在 WorkBuddy 的模型路由配置里把“快速任务”的默认模型改成一个小模型比如 7B 级别只让复杂任务走大模型。问题 4跑长文档时上下文溢出Hy4 本身支持长上下文但 WorkBuddy 在做任务拆解时会在系统提示里堆很多东西挤占上下文空间。解决方法在 WorkBuddy 设置里关掉“高级上下文增强”选项这个选项默认会给每轮对话附加大量工具说明。问题 5多卡并行时性能反而下降MoE 模型在多卡推理时通信开销比密集模型大因为每层都要做 all-to-all 的路由通信。如果只有 2 张显卡通信开销可能抵消并行收益。实测下来4 卡以上才有明显加速效果2 卡时如果带宽不够比如民用主板的 PCIe 3.0性能反而可能比单卡还差。5.2 使用期常见的 3 个业务侧问题问题 1WorkBuddy 生成的流程不符合预期排查思路先在对话里问它“你打算怎么执行这个任务”让 WorkBuddy 把拆解步骤列出来你确认没问题再让它继续。不要让它闷头执行类似“你再想想”这个技巧很实用——重新生成一次往往拆解路径会更合理。问题 2Skill 生效不稳定Skill 本质上是系统提示的一部分如果模型上下文不够长Skill 很容易被“挤出去”导致效果时有时无。解决方法是把 Skill 写得精简一些把核心规则放在前 200 字内。问题 3与其他 AI 工具如 CodeBuddy的协同关系理不清很多人一开始会搞混 CodeBuddy 和 WorkBuddy 的角色导致重复劳动。我的建议是代码层的事给 CodeBuddy流程层的事给 WorkBuddy。比如你想做一个“自动抓取网页并分析数据”的任务用 CodeBuddy 写脚本然后在 WorkBuddy 里挂定时触发两者各管一摊职责清晰。5.3 MoE 模型微调避坑指南最后说一个进阶话题微调 Hy4。MoE 模型微调有两个容易踩的坑第一个坑是路由崩坏。你微调用的数据集如果太单一比如只有代码类任务路由器会慢慢把所有输入都分到代码 expert其他 expert 全部退化。建议微调数据集尽量多元或者在损失函数上对 router logits 加一个均匀分布正则项。第二个坑是 LoRA 的 target_modules 要选对。MoE 模型里shared expert 和 fine-grained expert 的权重更新规律不一样。我实测过只对 attention 层和 shared expert 做 LoRA 的效果比对所有层统一做 LoRA 要稳定。参数设置上rank 值一般取 32-64 就够了alpha 设为 rank 的 2 倍避免训练不收敛。如果只是为了调指令跟随能力我个人更建议先用 WorkBuddy 的提示词工程来解决不要太早进入微调。微调的时间成本和调试成本都不低先把链路跑通再回头想优化是更务实的路线。6. 两周免费期的正确打开方式WorkBuddy 这次限时两周免费很多刚拿到手的朋友容易陷入“什么都想试一下”的混乱状态。我建议你按下面这个优先级来体验第一优先跑通一个完整的个人工作流。别贪多选一个你每周都要干的重复性任务比如周报汇总、数据清洗、文件归类用 WorkBuddy 把它自动化。这个过程能让你快速理解“任务拆解 → 工具调用 → 结果验证”的核心循环。第二优先写一个属于你自己的 Skill。等你对 WorkBuddy 的交互模式有了感觉把你在某个领域的经验沉淀成一个 Skill。比如你是财务可以写一个“财务月结检查清单”的 Skill你是运营可以写一个“活动数据复盘框架”的 Skill。这个沉淀下来的东西比工具本身更值钱。第三优先测试它的 API 接入能力。把 WorkBuddy 接入你日常使用的系统里比如飞书、钉钉、企业微信或者你内部的低代码平台。免费期内把接口调通之后如果决定长期用就不用手忙脚乱地迁系统了。至于 Hy4 本身我个人的建议是如果你有很好的硬件条件值得花时间在本地部署起来体验一下 770B MoE 的能力边界如果硬件条件暂时不够也可以先用 WorkBuddy 云端版把工作流思路理顺——模型的迭代速度很快但流程设计的思维是长久积累的资产。两者结合好等于同时有了最强大脑和灵活的手脚这才是这套组合的正确打开方式。