模型圈的消息传播速度一直比想象中快。我这边刚在群里看到有人转发 Hy4 preview 的发布信息讨论很快就分成了两拨一拨在研究 770B MoE 开源权重到底意味着什么另一拨已经在问 WorkBuddy 的免费期怎么注册、去哪里下载。其实两拨人关心的核心是同一件事在这波大模型发布里普通用户能不能用上、怎么用最划算。Hy4 preview 这次发布可以从三个关键词拆开看770B、MoE、开源。后面还跟了一个配套消息WorkBuddy 限时两周免费。这篇文章我打算把这几件事逐条拆开讲清楚 770B 到底是多大、MoE 为什么能改变推理成本结构、真想本地部署要过哪几关以及不想折腾显卡的人怎么把 WorkBuddy 的免费期利用起来。如果你是开发者、技术爱好者或者只是天天在办公软件里被重复劳动折磨的普通用户这篇都应该能给你一个相对完整的使用地图。补充一句以下内容基于公开发布信息和技术原理推演部分细节在预览版本阶段还可能调整具体以官方正式文档为准。1. 一次发布三个信号770B、MoE、开源分别意味着什么1.1 770B牌面参数和实际干活参数不是一回事看到770B第一反应肯定是这模型真大。770B 如果写成完整数字就是 7700 亿个参数。放在两年前这种规模的模型几乎不会出现在公众讨论里只属于极少数头部实验室的内部实验。但这里有个关键区别传统 Dense 模型也就是大家最早熟悉的 GPT 系列那种结构做一次推理所有参数都要参与计算。770B 个参数每个参数都要乘一遍权重那就真的是硬算 770B。这样的模型别说是普通电脑就算一卡难求的数据中心也得掂量下成本。而 MoE 模型不一样。MoE 是 Mixture of Experts 的缩写翻译过来是专家混合。它把模型拆成很多个专注不同特征的专家子网络。每次来一个输入并不是所有专家都上场而是由路由机制挑出其中一小部分专家来干活。所以 770B 代表的是模型的总参数量是纸面上的规模实际一次推理调用的参数量往往只有总参数的十分之一到二十分之一。Hy4 preview 如果延续目前主流 MoE 模型的设计思路激活参数很可能落在几十 B 到一百多 B 的区间。这个数字才是真正决定单次推理成本和速度的指标。这一点会直接影响后文的部署思考你先记住。1.2 MoE 的核心价值让大和省同时成立过去做模型普遍觉得参数越多能力越强代价是推理越慢、越贵。MoE 设计的聪明之处在于它在知识存储和单次计算之间做了拆分。你可以把 MoE 模型想象成一家大型综合医院。医院里挂了数百个科室的牌子也有几百位专科医生坐诊这就是总知识量。但一个病人进来不可能所有科室都围着病人转一遍。分诊台路由机制根据症状判断该去心内科还是消化科然后只叫相关科室的少数医生来处理。这样的好处很明显医院的科室规模可以做得很庞大知识覆盖面广但每位病人的就诊链条依然很短费用可控。MoE 模型追求的正是这个效果——我确实存了很多知识但是每个 token 的推理不需要把全部知识都过一遍。这也是 Hy4 preview 把开源和770B MoE放在一起发布的原因之一。如果这是一个同样规模的 Dense 模型就算开源了绝大多数人也只能看着权重文件发愁不是不想用是真的喂不饱它。而 MoE 结构至少让大模型开源这件事在工程上具有现实讨论价值。1.3 开源是一个范围词权重开放不等于全链路透明聊到开源很多人的概念是源代码都给出去了。但在大模型语境下开源通常要分清几个层次开放权重模型训练好的参数文件公开可下载你可以拿去部署、微调。开放代码训练代码、推理代码、数据处理流水线全部公开。开放数据训练数据也公开这是最彻底但最少见的情况。目前行业内大量号称开源的模型实际做到的是开放权重这一层。Hy4 preview 既然标注为开源我最期待先确认两件事一是权重文件是否真的能自由下载二是许可证允许什么范围的使用比如商用是否需要申请、衍生模型要不要继承同样的许可证。现在很多企业选择开源模型看的不是单纯的技术情怀而是许可证的清晰度。一个 770B MoE 模型如果许可证允许商用对创业团队来说吸引力非常大——因为你要从零训练一个这种规模的模型成本通常是千万级而基于开源权重做微调和产品化成本直接低几个数量级。1.4 WorkBuddy 免费期模型和工具的组合拳很多人容易忽略一个细节这次发布不只是模型还配套了 WorkBuddy 限时两周免费的消息。在模型圈这种安排越来越常见。原因也不难理解模型本身是一个引擎但对绝大多数用户来说引擎不能直接开。你需要仪表盘、方向盘和导航也就是 Agent 工具。Hyper 这次的思路很直接——如果你不想被 770B 的部署门槛劝退可以用 WorkBuddy 直接体验模型能力如果你想深入做二次开发再去研究开源权重。两层用户都照顾到了。所以 WorkBuddy 的出现不是发布信息的附属品它是官方为了让开源大模型能力转化为普通用户可感知效率提升而搭的桥。两周免费期更像是一个体验窗口官方想让你在窗口期内把真实工作流搬上去试试用效果说话。2. MoE 不是并行跑 1000 个模型路由、专家与负载均衡2.1 FFN 层拆分MoE 到底把什么拆开了如果你想真正理解 MoE得先看一眼 Transformer 的组成。Transformer 模型里除了注意力机制还有一层很关键的前馈神经网络FFN。领域知识、语言规律的大量计算都发生在这个 FFN 层里。MoE 的改造动作就是把一个完整的大 FFN 层拆成多个并行的 FFN 子网络每个子网络就是一个专家。拆分的数量可以很夸张几十个、上百个甚至上千个都行。Hy4 preview 的总专家数目前还没有太多公开细节但从 770B 的总参数规模来推断专家数量大概率在百级别以上每个专家本身的体量也不小。专家与专家之间并不是互不通信的孤岛。Attention 层仍然会把整个输入序列的信息做全局交互MoE 只替换其中 FFN 这一段。这样既保留了 Transformer 处理长程依赖的能力又让 FFN 阶段的计算成本从全部参数降成部分专家。2.2 路由机制每次推理只有少数专家出场路由机制Router是 MoE 模型的大脑。每个 token 进入 FFN 层时路由器会计算它和每个专家的匹配分数然后选出得分最高的 Top-K 个专家来激活通常 K 取 1 到 8 之间的数。举个例子。如果模型有 64 个专家K 取 4那么每个 token 在这个 FFN 层只会激活 4 个专家剩下 60 个专家处于休眠状态。这 4 个被激活的专家并行处理同一份数据再把结果合并作为这一层的输出。这种稀疏激活的设计让模型的总参数量可以堆得很大但单次推理的 FLOPs浮点运算量不会线性上升。网络热词里总有人问MoE 模型为什么比同样参数的 Dense 快答案就在这个机制里。它并不是并行跑全部专家而是让每个 token 只走少数几条专家路径。2.3 负载均衡专家也会出现冷热不均MoE 模型真正难搞的地方不在结构而在训练稳定性。如果路由机制放任自流很可能会出现头部专家累死、尾部专家饿死的情况少数几个专家总是被选中大量参数得不到充分训练模型能力反而退化。所以绝大多数 MoE 模型都会在训练目标里加一个负载均衡损失Load Balance Loss强制路由器的选择尽量均匀。这个损失项权重通常不会太高否则会牺牲模型效果但也不能没有否则专家退化是迟早的事。这个点对普通用户的意义在于当你测试一个 MoE 模型时如果不问场景只测几个泛化问题很难看出真实水平。因为不同类型的问题会被路由到不同专家你需要覆盖足够多样的任务才能验证专家是否都称职。2.4 分数与实际体感之间的差距看 MoE 模型的跑分要比看 Dense 模型更谨慎。基准测试集通常覆盖数学、代码、常识问答等维度如果这些任务恰好在模型的专家覆盖范围里分数会很漂亮。但如果你实际使用场景比较偏门比如处理某种特殊格式的合同、某垂直行业行话路由可能选不到合适专家效果就会明显下降。所以我在评估 MoE 模型时有个习惯不看总分先把任务类型拆开分别测试它处理长文档、代码生成、结构化数据提取、创意写作的差异。很多时候你会在拆开之后发现同一个模型在这些任务上的表现差距很大这恰恰是 MoE 的路由偏好导致的。3. 想本地部署先算账770B MoE 的显存、量化与框架选择3.1 显存账本精度决定你能不能睡个好觉既然权重开源了肯定会有人想本地跑。我理解这种冲动但先别急着下载权重动动笔算一下显存需求。模型参数占用的显存主要取决于精度格式精度每个参数占用770B 模型理论显存FP324 字节约 3080 GBBF16/FP162 字节约 1540 GBINT81 字节约 770 GBINT4约 0.5 字节约 385 GB这还只是模型权重本身。推理过程中还要算上 KV Cache、激活值、路由计算等临时显存开销。上下文越长、并发数越高KV Cache 占用的显存越夸张。也就是说即便是 INT4 量化你也需要至少 400GB 到 500GB 级别的显存总量才能比较舒服地把模型跑起来。我见过不少朋友拿着 48GB 的显卡兴冲冲地问能不能跑答案很残酷连权重的门槛都摸不到。770B 这种规模意味着你的硬件方案只能是多卡并行或者直接考虑 API 服务。3.2 量化格式和推理框架的取舍如果你已经准备好了多卡服务器接下来的问题是选量化格式和推理框架。目前社区里主流的选项大概有这几类GGUF由 llama.cpp 生态主导量化级别细支持 CPU 和 GPU 混合推理对新手友好。GPTQ针对 GPU 推理优化适合用 vLLM 这类高吞吐推理框架。AWQ也是 GPU 推理方案据说是基于激活值分布做量化精度保留比普通 GPTQ 好一些。FP8/BF16 原生精度需要 A100/H100 这类支持更高效低精度计算的显卡。框架方面llama.cpp 适合个人折腾和低并发场景vLLM 适合服务化部署和高并发 APITensorRT-LLM 适合追求极致吞吐的商用场景。如果你想在本地快速调通可以优先考虑 llama.cpp 系工具如果想给团队提供内部服务直接用 vLLM 更省事。3.3 显存不够时的替代路线谁说开源模型只能自己部署这里想多说一句开源模型的价值不等于必须本地部署。很多人被开源这个词带偏了觉得不把权重下载到自己电脑上就亏了。实际上开源模型可以通过多种方式使用先到开源社区或模型托管平台查看官方是否开放了 API。Hy4 preview 发布时既然配了 WorkBuddy 免费期说明官方更希望你先从服务化的入口体验而不是一上来就挑战 770B 的本地部署。我的建议是分人群处理如果你是想研究模型结构的算法工程师本地部署值得折腾如果你是做应用开发的优先接 API把精力放在产品逻辑上如果你只是办公场景提效连 API 都可以不关心直接用 WorkBuddy 这类 Agent 产品就行。把每个环节交给最合适的工具而不是为了用上开源模型而强行本地跑。4. WorkBuddy 两周免费期怎么用才不浪费4.1 先搞清楚 WorkBuddy 和模型的定位差异很多人在搜索 WorkBuddy 教程时会把它和 Hy4 preview 混在一起其实这是两个层次的产品。Hy4 preview 是底层的语言模型解决的是理解和生成文本的问题WorkBuddy 是构建在模型之上的智能体工具解决的是帮你把任务拆解并执行的问题。可以类比一下模型是发动机WorkBuddy 是整车。发动机的马力参数很重要但普通人真正需要的是一辆能开上路、能载货的车。WorkBuddy 做的事情就是把模型、工具调用、任务流程整合到一起让你用自然语言描述需求它去完成实际的工作。这也是为什么 WorkBuddy 的教程热词里会出现WorkBuddy 写网页WorkBuddy 业务流程这类搜索——它不是单纯陪你聊天的对话机器人而是一个任务执行入口。理解了这层定位你才不会用错它。4.2 下载安装的完整路径要体验 WorkBuddy 的两周免费期第一步自然是找到官方入口。我建议直接去发布方官网寻找 WorkBuddy 下载链接或者留意官方给出的渠道。搜索时也要注意辨别尽量点开标了官方认证、来源清晰的页面。下载安装时有几个容易忽略的细节确认你的系统版本是否满足要求尤其是 Windows 和 macOS 版本过老的话某些功能可能不兼容。如果有桌面端和 Web 端两种形态建议电脑配置一般的话先用 Web 端省资源。安装完成后先用手机号或邮箱注册登录多数 Agent 工具需要在云端保存会话数据本地端只是入口。WorkBuddy 如果同时提供网页版和本地客户端我的建议是先用网页版跑通流程因为涉及文件读写、浏览器自动化等能力时本地客户端反而需要额外授权Web 端体验更轻快。4.3 核心概念会话、任务、Skill我第一次打开 WorkBuddy 时界面并不复杂但想把它用好先要理解三个核心概念。会话Session是当前所有的交互记录。它不只是一来一回的聊天而是包含了你给 Agent 的任务、Agent 拆解出的步骤、调用的工具和输出结果。任务Task是工作流的基本单位。你可以把任务理解为一个要解决的问题比如帮我整理这份会议纪要的待办事项或者用 HTML 写一个带样式的个人主页。一个好的任务描述应该包含目标背景、约束条件和期望产出。Skill 是这套工具里最有价值的扩展机制。它就像给 Agent 装上的专用技能包让 Agent 可以调用特定流程或工具。比如处理文档的技能、写代码的技能、做信息检索的技能。理解这三者的关系你会少走很多弯路会话是容器任务是目标Skill 是方法。WorkBuddy 真正比普通聊天机器人强的就是多了 Skill 这层能力。4.4 实测任务让 WorkBuddy 帮你写一个网页纸上谈兵没什么意思我实际操作了一把让 WorkBuddy 写一个简单的个人展示网页流程整理如下。我在新建会话里输入的任务是帮我写一个个人品牌展示网页包含首页、作品集、联系我三个板块风格偏好简洁明亮配色建议以蓝白为主使用 HTML CSS不需要 JavaScript 复杂交互。接下来 WorkBuddy 会做几件事先把任务拆成页面结构设计、配色方案、内容区块规划这样的子任务然后调取写代码相关 Skill生成 HTML 文件和对应的 CSS 样式。产物出来之后还可以让它提供一个可以在浏览器里直接运行的预览方式。整个过程里我学到的第一个技巧是任务描述越具体产物质量越高。如果我只说帮我做个网页它也能做但大概率只是一个非常基础的页面。而当我明确给出页面板块、风格提案和技术限制时输出明显贴合需求。这不光是 WorkBuddy 的特点所有 Agent 类工具都一样。4.5 免费期常见的坑和应对在体验过程中我也踩了几个小问题比较典型的如下一是任务执行太久没有反馈。遇到这种情况先别急着重开看看是不是任务里包含了需要外部授权或联网的操作。可以在任务里加一句如果遇到需要额外授权的步骤先停下来问我能省很多不必要的等待。二是 Agent 产出的内容自己理解不了。比如生成的代码报错了直接把报错信息贴回会话让它自己修。不要自己傻乎乎地去翻代码Agent 能拿到完整上下文修起来比自己快。三是把隐私数据直接丢进去。不管模型能力多强涉及公司机密或个人信息时都要谨慎。WorkBuddy 免费体验阶段建议先处理一些脱敏后的测试任务真正稳定了再上生产数据。5. 开源 MoE 模型的不同使用姿势别被参数带节奏5.1 有卡开发者的混合方案API 快速验证 本地针对性调试如果你手上有 A100、H100 或者多张 4090 这样的硬件又想深入玩 Hy4 preview我的建议是不要一上来就本地部署全套模型。先用官方 API 跑通功能验证等确认项目里确实需要私有化部署了再考虑下载权重。原因很实际770B MoE 的本地部署涉及模型切分、推理框架调优、显存优化不是一天两天能磨完的。先用 API 做功能验证相当于花少量成本确认方向避免在基础设施上浪费大量时间。如果真的到了私有化部署阶段优先关注几个工程指标吞吐量每秒能处理多少 token、首 token 延迟、并发能力、长上下文下的显存增长曲线。这些指标决定了模型上线后的实际体验比单纯看跑分有价值得多。5.2 普通办公用户为什么我更推荐先抓住免费窗口对于不上代码的普通用户我的建议非常直接把 WorkBuddy 两周免费期当作一次正经的效率实验来做不要只拿来聊天。这句话怎么理解很多用户拿到类似工具后只是随口聊几句帮我写个周报就关了。这种用法浪费了 Agent 工具的核心能力。更有效的做法是回顾你上周工作中最费时间的三件事可能是整理客户反馈、可能是汇总多个表格、可能是写一段固定格式的文案然后把这些真实任务交给 WorkBuddy 跑一遍。用真实工作流测试的好处是你能立刻判断它是否真的帮你省了时间。如果在免费期内发现某些工作流可以被替代那这两周就是你把新工具嵌入日常工作节奏的最佳练习期。等免费期结束你再决定是否要付费手里的判断依据是真实任务效果而不是宣传页上的功能列表。5.3 企业和创业团队算清楚私有化部署的 ROI企业用户看到开源大模型最常见的冲动是要不要基于它做私有化部署把数据留在自己手里。这个想法本身没错但需要算一笔更完整的账。私有化部署的成本不只是显卡采购还包括机房电费、网络带宽、运维人力、推理框架调优、模型更新迭代。770B 这种规模的模型如果只是企业内部小范围使用实际利用率可能很低单次推理的摊销成本会非常贵。我见过一些团队的做法是双轨制大部分日常任务用 API 完成只有涉及敏感数据的核心任务走本地模型。这样既控制了成本又规避了数据合规风险。开源模型的真正价值不是让你把一切都搬回本地而是给了你选择权——可以做得起的地方自己做做不起的地方用服务。5.4 不要为了用而用选模型先看场景开源模型越来越多之后很多人陷入了一个误区把大量时间花在评测哪个模型更强上却没有认真想过自己的场景需要什么。如果你的任务是高频、短文本、对隐私要求不高一个中等规模的模型加好的 Agent 工具完全够用没必要追 770B。如果你的任务是长文档理解、复杂代码生成、多步推理那么大模型的上限确实重要但在开源里选了 770B MoE最好也确认下它的激活参数和上下文能力是否匹配任务类型。工具选型从来不是参数越大越好而是最合适的那个。开源生态最大的好处是它提供了足够丰富的选项让不同预算、不同场景、不同技术能力的人都能找到适合自己的组合。6. preview 阶段值得盯的四个观察点6.1 上下文窗口纸面长度和真实可用长度不是一回事模型发布时通常会标一个上下文窗口比如 128K 或 256K。但实际使用时你会发现长上下文场景下模型很容易在中间部分迷失早期输入的内容会被后续信息冲淡。尤其是 MoE 结构路由机制要在超长序列里做准确决策难度比短文本大不少。我建议你在 WorkBuddy 免费期里专门做一次长文档测试丢一份几万字的资料进去然后问它位于文档中段的一个细节问题。如果表现稳定说明这个模型的上下文管理做得不错如果答非所问那就意味着你实际使用时需要主动把文档切分成小块别让上下文一眼看不到头。6.2 高并发下的路由表现与服务稳定性MoE 模型在单条请求上的推理速度再快都要面对高并发时的服务稳定性问题。路由机制本身有额外计算开销当大量 token 同时涌入时如果专家选择不够均衡很可能会出现部分专家所在的计算设备率先过载而其他设备空闲的木桶效应。对于想要接入 WorkBuddy 或 API 做开发的团队这一点尤其要留意。免费体验期间你感受不到并发压力因为它们只是单用户任务等到你正式接生产环境并发一上来模型对外表现的速度和稳定性可能跟你测试时完全不同。建议前期就设计好限流和降级方案。6.3 生态兼容和许可证细节开源模型的生态兼容性直接影响集成成本。至少要看三块一是是否兼容 OpenAI 风格的 API 协议这决定了你现有的代码能不能无缝切换二是是否能微调以及微调工具链是否成熟三是许可证对商用场景的具体约束。之前有不少团队吃过许可证的亏项目已经上线了才想起来仔细翻条款最后不得不返工换模型。Hy4 preview 作为新发布的模型许可证细节一定要在动手之前确认完毕尤其是衍生模型的开放义务和商用范围的边界。6.4 版本迭代节奏preview 只是起点叫 preview 意味着这大概率不是最终版本。从模型产线节奏来看官方很可能会根据社区反馈修正一些问题再推出正式版甚至继续迭代更大或更快的版本。所以如果你在 preview 阶段发现某些场景表现一般先别急着下结论也值得留意社区反馈。特别是专门针对 MoE 模型的评测、路由行为分析和量化测试这些内容往往比官方发布稿提供的技术细节更真实。技术选型的决定可以参考 preview 的表现但不用把话说死后面版本迭代可能很快改变性价比判断。拿我自己来说每次遇到新模型发布最让我兴奋的并不是参数数字而是这次普通人能接触到的能力门槛又降低了多少。Hy4 preview 的 770B MoE 开源给的是技术探索的空间WorkBuddy 的两周免费给的是业务效率变好的窗口。我会做的一件事是把平时积压的几个重复性任务整理成清晰的任务描述在免费期内全都交给 WorkBuddy 跑一遍。跑不跑得通、效果怎么样直接决定了我接下来是否要把这个工具放进日常链路的常驻位置。真实任务永远是最好的评测集你也值得在自己的工作流里找一两个最痛的场景趁这两周窗口亲自测一次。