Hy4 preview 这个事我这两天在好几个技术社群里都看到有人聊。一边是 770B 参数量级的 MoE 开源模型另一边是配套的 WorkBuddy 工具直接限时两周免费两个消息叠在一起乍一看信息量有点杂。但如果你像我一样平时既要跟进开源大模型的动态又要给团队搭实际的工具链就会发现这其实是一条完整的产品组合拳模型负责把能力底座开源出来WorkBuddy 负责让这些能力真正落地到具体工作流里。这篇文章我就把这里面的门道拆开讲一遍770B 到底意味着什么MoE 架构为什么能撑起这么大的参数量普通人和小团队到底怎么上手以及 WorkBuddy 这两周免费期里值不值得花时间去折腾。1. Hy4 preview 发布这条消息里藏着哪些关键信息1.1 一次发布两个主角先别着急把目光全放在770B这个数字上这次发布其实是两个层面的东西同时落地Hy4 preview 属于模型层WorkBuddy 属于应用层。模型层解决的是有没有、强不强的问题。Hy4 preview 以 MoE 架构做到 770B 总参数这放在开源模型里属于第一梯队。但模型再强如果只是挂在模型卡上让你下载对大多数非算法岗的人其实是隔着一层的下载下来怎么跑、跑起来干什么、怎么接到自己的业务里每一步都有门槛。所以 WorkBuddy 紧跟着限时免费意义就很明显了它把模型能力包装成一个个可操作的任务流、技能插件、知识库入口。你不用自己搭部署环境也不用写复杂的调用代码直接在界面上把流程配出来AI 帮你干活。这一套组合下来信息就很完整了开源模型是给开发者做底座WorkBuddy 是让更多普通用户能直接用上这些能力。1.2 770B MoE不是简单的更大而是更聪明地更大很多人一看 770B 第一反应是又一个参数量怪物但实际上 770B 和 770B 是不一样的。关键在于它用的是 MoE 架构也就是混合专家架构。以前那种稠密模型比如 70B 的 Llama所有参数在每个 token 推理时都必须全部参与计算这是典型的人多力量大但成本也大。而 MoE 模型的做法是我确实养了一支 770 人的团队但每次来活儿我只挑最对口的几个人上场。其他人在后台待命不占现场资源也不领现场工资。这就是为什么 Hy4 preview 敢于用 770B 这个量级去做开源——如果它是稠密架构这个参数量几乎没法在常规条件下部署开源了也没几个人用得起。但 MoE 架构让总参数很大和单次推理成本可控这两件事可以同时成立。1.3 WorkBuddy 限时免费从模型到应用的拼图再说 WorkBuddy。坦白讲现在开源大模型那么多真正缺的从来不是模型而是应用层——怎么让一个不会写 prompt、不会调 API 的人也能借助大模型提高生产力。WorkBuddy 想做的是把大模型封装成一个能安排任务、能调用工具、能管理知识的工作台。限时两周免费与其说是福利不如说是一次低成本试错机会。你有两周时间把它跑起来、接到自己的真实场景里觉得值就继续用觉得不合适也不亏。我建议所有人都抓住这个窗口期毕竟白嫖一个智能体工作台的机会不常有而且你搭好的技能模板是在你自己账号里的后面即使转付费迁移成本也不高。2. MoE 架构原理解读为什么 770B 参数还能跑得动2.1 什么是 MoE把一个大模型拆成一支专家团队要理解 770B MoE 为什么能跑得动得先搞清楚 MoE 是怎么设计的。传统的 Transformer 模型里每个 Transformer 块包含一个自注意力层和一个前馈网络层FFN。这个 FFN 通常占了模型参数的大头我们一般叫它稠密 FFN——输入的所有信息都会完整穿过这一层所有参数都被激活。MoE 的改造思路很直接把一个大 FFN 拆成好几个小的 FFN每个小 FFN 就是一个专家。比如 8 个专家、16 个专家、甚至更多具体数量看模型设计。这样一来总参数确实被拉高了因为每个专家都有自己的权重。但推理的时候输入只会被送到其中的几个专家手里其他专家不参与计算。用一个我常打的比方普通 Dense 模型像是一家只有几个全科医生的小诊所不管什么病都得这几个医生从头看到尾MoE 模型则像一家大型综合医院科室很多每个科室一个专家但病人来了先分诊然后只有相关科室介入。2.2 门控路由怎么决定让谁干活分诊这个动作在 MoE 里由一个叫 Router路由的模块完成。它本质上是一个轻量级的线性层加 Softmax会对输入做一个打分然后选出得分最高的前几个专家来处理这个 token。这里有几个关键设计点Top-k 选择通常选 2 到 4 个专家。选太少专家可能学得不够细选太多计算量又上去了。Hy4 preview 这种超大 MoE 具体怎么配的要看技术报告但 top-2 是最常见的组合。负载均衡如果分诊老是倾向某几个专家其他专家就学不到东西等于白养。所以训练时通常会加一个负载均衡损失让 token 尽量均匀地分发到各个专家手里。专家容量每个专家在一个 batch 里能处理的 token 数量是有限的超出会丢 token 或者触发重组机制。这也是影响推理性能的一个隐藏因素。2.3 激活参数 vs 总参数算力账要这么算这里有一个我反复会跟人强调的概念总参数Total Parameters和激活参数Active Parameters。MoE 模型对外宣传的参数量一般是总参数也就是所有专家加在一起的大小。但实际推理时真正参与计算的只有被路由选中的几个专家加上共享层这部分叫激活参数。举个简化例子假设 Hy4 preview 总参数 770B如果它每次激活的专家参数量相当于 26B 的稠密模型水平那么单次推理的算力成本就接近一个 26B 的 Dense 模型而不是 770B 的 Dense 模型。当然这是粗算实际还有路由开销、Expert 并行通信开销等但思路就是这个思路。所以770B这个数字更多是代表模型的知识容量和学习上限而决定部署成本的是激活参数 硬件分配。你真正该关心的不是 770B 需要多少显存而是它的激活参数大概在什么量级、量化后是多少这直接决定了你能不能跑、跑多快。3. 770B 开源意味着什么硬件门槛与部署思路3.1 先算一笔硬件账推理到底需要多少显存回到最实际的问题770B 的模型我手上这些卡到底能不能跑先给出一个粗略的估算公式模型权重占用的显存 ≈ 参数量 × 每个权重参数占用的字节数。FP32 精度4 字节770B × 4 3080 GB基本是做梦。FP16/BF16 精度2 字节770B × 2 1540 GB。FP8 精度1 字节770B × 1 770 GB。INT4/AWQ 量化约 0.5 字节770B × 0.5 385 GB 左右。这还只是权重的裸大小实际跑推理还要算上 KV cache、CUDA context、临时激活值和碎片开销。所以你想本地跑完整的 FP16 版本得准备至少 1.5 TB 以上的显存总量。注意是总量不是单卡可以通过多卡张量并行凑出来。给你一个更直观的画面硬件条件能不能玩 770B 完整版建议路线单张消费级显卡24GB基本不行用 API 或 WorkBuddy 走云端双路 4090 48GB可能只能跑 INT4 量化分布式限额量化版体验有限8×A100/H10080GBFP8 勉强能上可以考虑 vLLM 多卡并行8×A800/A100-80GFP8 比较稳妥推荐部署路线所以要认清一个事实Hy4 preview 开源不等于每个人都能在本地跑起来。它的目标是给那些有集群、有私有化需求的团队用的。个人玩家更务实的做法是用 API 或者直接上手 WorkBuddy。3.2 量化方案FP8 / AWQ 怎么选如果你的团队已经决定要本地部署下一步就是选量化方案。主流选择集中在 FP8 和 AWQINT4之间。FP8 是目前大模型部署的甜点位。显存占用是 FP16 的一半精度损失很轻微很多模型的 FP8 推理效果和 FP16 几乎看不出差别。缺点是还是需要一定的显存规模适合那张 770 GB 的账能算得过来的团队。AWQ / INT4 能把权重压到四分之一以下意味着你可以在更小的显存里塞更大的模型。但精度损失会稍微明显一点尤其是在数学推理和代码生成这类对数值敏感的任务上。还有一个 MoE 特有的坑专家之间的权重分布差异很大有些专家对量化更敏感。那种单纯把整个模型按同一精度压缩的做法并不聪明。实际效果好一些的做法是在敏感层保留 FP16 或 FP8其他层用 INT4也就是混合精度量化。vLLM 这类框架已经开始支持不同层配置不同量化精度建议你部署的时候不要嫌麻烦分模块去测效果和显存。3.3 开源影响社区生态与二次开发空间开源带来的价值不只是免费拿到权重这么简单。一个 770B MoE 模型一旦开源围绕它的生态会迅速长出来有团队做微调版本、有社区做中文增强、有厂商做量化适配、有人出部署教程。这些外溢的成果会让所有使用它的人受益。企业端尤其关注私有化和数据安全。很多敏感数据不可能走公网 API开源模型让把所有能力搬进内网成为可能。这也是为什么每隔一段时间就有大厂开源一个大模型每次都有人问和闭源比怎么样但真正应该问的是你能不能合法、安全地用闭源 API 处理你的数据。Hy4 preview 这种体量的模型开源对政企、金融、医疗等需要数据合规的行业意义比个人用户大得多。4. WorkBuddy 是什么两周免费先抓住这几个核心能力4.1 WorkBuddy 能做什么不是又一个聊天机器人把 WorkBuddy 理解成聊天机器人就太浪费了。从产品形态来看它更像一个智能体工作台你把目标告诉它它负责拆解任务、选择合适的工具、调用模型能力、最终把结果整理交付给你。我看到网上已经有很多人拿它做具体的事情比如整理大学清单、分析基金持仓、汇总会议纪要、搭建周报流程。这恰恰说明它的定位就是通用型工作台不是只给程序员用的命令行工具而是一个能接办公、学习、投资、内容创作等各类场景的任务执行平台。几个核心能力值得一说技能包Skill把一段完整的做事方法封装成可复用的技能下次一键调用。业务流程编排把多个步骤串起来比如读取文件 → 摘要 → 翻译 → 输出报告。知识库挂载把团队文档喂进去回答问题或写东西的时候参考这些资料。第三方工具接入通过 API 连邮件、日历、网盘等外部服务。4.2 WorkBuddy 和 CodeBuddy 的区别很多人看到 WorkBuddy 都会问它和 CodeBuddy 有什么区别。简单讲CodeBuddy 是面向开发者的 AI 编程助手主战场在 IDE 里帮你写代码、补全、解释 bug、生成测试用例。它能提升的是程序员写代码这段流程的效率。WorkBuddy 覆盖面更宽是一个通用工作平台。它不一定关心你写的是什么代码而更关心你今天要交付什么结果。你可以让它去收集资料、整理信息、写文档、做分析、排日程这些事和写代码没有直接关系但每天都在消耗大量人力成本。换个类比CodeBuddy 像是你身边坐了个资深工程师帮你盯着代码质量WorkBuddy 更像是给你配了个整个项目组把打杂、整理、分析、汇报这些活儿都接走了。两者不是竞品是不同层级的工具。4.3 限时免费期间怎么薅到最大价值既然是限时两周就得想清楚怎么把这两周的价值榨干。我的建议是不要一上来就乱试功能而是列一张清单最近一个月里你团队或你个人重复做的最多的事情是什么把其中逻辑比较清晰、不需要太多临场发挥的事情找出来交给 WorkBuddy 配置成流程。举例来说如果你每周要向老板交一份竞品动态周报可以配置一个 Skill它自己去抓信息源、按固定结构整理、生成中英文摘要、最后落到你的文档里。这种可复用的流程一旦搭好两周后即使免费期结束你自己也知道它值多少钱。免费期里至少要跑通三件事建一个自己的技能包、接一个自己的知识库、用 API 对接一个自己的常用应用。这三件事做完你才算真正用过 WorkBuddy而不是只在界面上点了几下。5. WorkBuddy 实操指南从安装到跑通一个完整流程5.1 安装与登录Web 端还是客户端WorkBuddy 一般来说会提供 Web 端和桌面客户端两种入口。我的建议是先用 Web 端免安装、上手快适合前两天的功能探索。等你确认它确实能进你的日常工作流了再装桌面客户端配合文件操作和跨应用调用来用效率会更高。登录时注意很可能需要用企业邮箱或手机号注册不同渠道注册的账号权益不一定完全一样。限免活动通常需要在活动页面点击参与或者在个人中心看到限时免费的状态标识这一块建议花两分钟确认一下别用完了才发现自己账号没在免费名单里。桌面客户端安装的时候注意看它需不需要装额外的运行时环境比如 Python 或 Node。这类工具为了跑本地技能有时候会在后台拉一个轻量环境安装时间会比想象中长一点别中途关掉。5.2 用 Skill 搭建一个个人工作台下面以一个真实的场景为例演示怎么搭一个会议纪要整理的 Skill。先在 Skill 管理页新建一个技能然后依次配置触发词/指令填整理会议纪要。输入参数开会时间、参与人、原始录音转写文本或会议笔记。处理步骤第一步清洗文本去掉口头语和重复内容。第二步按议题—结论—待办事项—负责人结构自动分段。第三步提取所有待办生成任务清单。输出模板一份 Markdown 格式的会议纪要直接复制到飞书或 Notion。配置好之后以后每次开完会你只要把转写文本丢进去几秒钟就能得到结构化的纪要。看起来很简单但这就是典型的把重复性工作交给 AI的做法积少成多省下的时间非常可观。实操时一个小技巧第一次跑完流程后检查一下输出结果把不符合你需求的地方用自然语言直接告诉它下次按这个格式输出好多工具都支持基于反馈调整模板。多迭代几次这个 Skill 会越来越贴合你的习惯。5.3 通过 API 接入 WorkBuddy 的两种方式如果只会在界面里点来点去那 WorkBuddy 对你的价值是打折的。真正高效的做法是把它已有的能力暴露给其他系统调用主要有两种方式。方式一用 HTTP API 直接调用。在设置页生成一个 API Key然后把它当作一个普通的后端服务来请求。下面是一个简单的 Python 调用示例import requests url https://api.workbuddy.example.com/v1/run headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } payload { skill: weekly_report, inputs: { source_folder: s3://your-bucket/reports/, language: zh } } resp requests.post(url, jsonpayload, headersheaders, timeout120) print(resp.json())方式二用官方 SDK 嵌入自有应用。SDK 通常封装了鉴权、重试和流式响应适合集成到现有系统里。一般流程是安装 SDK 包 → 初始化客户端 → 调用对应方法。和方式一的区别是你可以把 WorkBuddy 的能力当作自己产品的一个模块来用而不是单独跳转到一个外部工具。不管哪种方式有两点提醒API Key 一定不要提交到公开仓库泄露了要第一时间作废重置另外调用频率有限额压测前先看清楚额度别把免费配额一口气跑完了。6. Hy4 preview 本地部署实战以 vLLM 为例6.1 部署前的环境准备如果你已经决定自己部署 Hy4 preview那大概率手头有至少一台多卡服务器。我下面的部署流程以 vLLM 为主因为它是目前开源社区对大模型推理支持最成熟的框架之一对 MoE 模型的适配也在快速完善。基础环境建议这样准备操作系统Ubuntu 22.04 或更新的 LTS 版本GPU 驱动建议 535 以上版本CUDA12.1 或 12.4Python3.10 或 3.11显存参考前文算的账至少 8×80GB 的配置试试 FP8安装 vLLM 很简单几行命令pip install vllm nvidia-smi # 确认驱动和 GPU 都正常可见如果是在内网离线环境记得先在有网环境把 vllm 和 torch 的安装包拉下来离线安装时一键装完省得现场解决依赖问题。6.2 模型下载与格式转换接下来就是模型权重的问题。Hy4 preview 如果走官方渠道一般会同步发布到 ModelScope 和 Hugging Face 这类模型社区。国内用户建议直接用 ModelScope下载速度友好很多。# 以 ModelScope 为例 pip install modelscope modelscope download --model your_namespace/Hy4-preview --local_dir /data/models/Hy4-preview下载完检查一下文件完整性重点是那几个 safetensors 分片文件的 sha256 是否与仓库一致。大模型文件容易在传输中损坏跑了一半才发现权重有问题非常耽误时间。一般情况下官方发布的权重就是 vLLM 可以直接加载的格式不需要额外转换。如果你拿到的是 PyTorch 原生态的 .bin 或 .pt 文件vLLM 可能不认需要先转成 safetensors。用转换脚本处理时注意保持原始目录结构千万别把 tokenizer 文件和权重文件放散了。6.3 启动推理服务的完整配置启动一个 OpenAI 兼容格式的 API 服务是最省事的方式因为接哪都能用。这里给一份参考命令python -m vllm.entrypoints.openai.api_server \ --model /data/models/Hy4-preview \ --tensor-parallel-size 8 \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --enforce-eager解释一下几个关键参数--tensor-parallel-size 8把模型切分到 8 张卡上做张量并行必须和 GPU 数量一致。--dtype float16默认精度如果用了 FP8 量化权重这里要换成对应的设置。--max-model-len 8192最大上下文长度MoE 模型 KV cache 开销不小不要盲目设很大。--gpu-memory-utilization 0.9最多用 90% 显存留一些余量给 CUDA context 和其他开销。--enforce-eager这个开关在显存紧张的环境下可以关掉 CUDA Graph能显著降低显存占用。代价是吞吐会低一些属于以兼容换性能。服务启动后用 curl 验证一下curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: your_namespace/Hy4-preview, messages: [{role: user, content: 用 MoE 架构给非技术背景的人做个通俗解释}], max_tokens: 512 }6.4 验证效果与性能调优服务通了之后别急着上线。先做一轮效果验证拿几道数学题、代码题和长文本理解题测一测看看输出质量是否符合预期。如果发现某些类型的任务效果明显变差优先怀疑量化精度问题切回 FP16 再对比一下。性能调优可以从这几个方向入手--max-num-seqs控制并发序列数调大能提高吞吐但显存压力也会上升。连续批处理Continuous BatchingvLLM 默认开启不用额外配置。前缀缓存如果有很多带长系统提示词的业务请求开启前缀缓存能明显降低首 token 延迟。MoE 的专家并行官方 vLLM 对某些大模型支持专家并行可以试一下把专家分配到不同卡上减少单卡显存压力。但这个配置依赖框架版本和模型结构不是所有模型都能直接开。一个实际经验MoE 模型部署时最容易出现的问题是各专家利用率不均导致某几张卡负载高、其他卡闲着。如果发现吞吐上不去把负载监控打开看看必要时通过路由设置做调整。7. 常见问题与避坑记录7.1 热门前置问题速查表我把这段时间在各处看到的高频问题汇总成一张表方便你快速定位。问题结论Hy4 preview 从哪里下载官方仓库推荐 ModelScope 或 Hugging Face770B 消费级显卡能跑吗基本不行建议走 API 或 WorkBuddy量化后效果损失大吗FP8 很小INT4 在数学/代码任务上有感WorkBuddy 免费期多久两周进产品页面确认当前活动状态WorkBuddy 和 CodeBuddy 什么关系一个通用工作台一个编程助手WorkBuddy 能私有化部署吗通常提供企业版/私有化方案API 接入 WorkBuddy 要什么准备注册账号 → 生成 API Key → 看接口文档vLLM 启动报显存不足怎么处理开 enforce-eager、降 max-model-len、换量化7.2 部署和使用中的几个典型坑第一个坑模型下载不完整。大模型动辄几百 GB内网中断、磁盘空间不够都会导致文件缺失。加载时挺常见的是报一些莫名其妙的safetensors读取错误。处理办法是在下载完成后强制校验一遍哈希不要省这几分钟。第二个坑显存碎片导致能启动但跑一会儿就 OOM。这种情况往往不是总量不够而是显存分配不连续。调整--gpu-memory-utilization到 0.85 左右先让加载稳定再考虑拉高。还有一个偏方是加--swap-space把一部分 KV cache 放到 CPU 内存里虽然会慢一点但至少不崩。第三个坑量化后输出质量波动特别大。MoE 模型对量化更敏感有的专家还好、有的专家崩得离谱。建议做量化前先跑一版 FP16 的基线测试量化后逐项对比。对代码生成和数学计算这类任务如果差距超过可接受范围就退回 FP8 而不要强行 INT4。第四个坑WorkBuddy 里配置业务流程时输入参数没有校验。比如接口要求 JSON结果传了一个普通字符串到中间步骤才发现错误整个流程白跑。配置复杂流程时每加一个步骤就做一次局部验证不要攒到最后一起跑。第五个坑API Key 泄漏。GitHub 上专门有机器人扫描公开仓库里的密钥一旦把你的 WorkBuddy API Key 提交到公开仓库几分钟就可能被薅走。我见过有人把 Key 硬编码在配置文件里直接推到 GitHub第二天收到账单才反应过来。密钥管理这件事再怎么强调都不为过。写到这里我自己的体会是Hy4 preview 这种 770B 级别的 MoE 开源模型叠加 WorkBuddy 这种智能体工作台的组合正在把大模型的使用门槛从专业算法工程师拉到愿意花一下午折腾工具的普通人。MoE 架构解决了大规模模型推理成本的结构性问题而工作台类应用解决了普通人使用大模型的最后一公里。最后再分享一个实操细节无论你是打算本地部署 Hy4 preview还是准备用 WorkBuddy 搭技能都建议先花一小时想清楚一个具体的、高重复度的业务场景围绕场景来选工具、配流程而不是反过来让工具牵着鼻子走。先有场景再上工具这比什么参数调优都管用。