今天中午看到 Hy4 preview 发布的消息时我正在折腾本地模型工作流到底该换哪套底座。770B 这个数字先让人一惊但紧接着“MoE 架构”和“开源”两个关键词又让人冷静下来——这意味着模型总参数虽然庞大推理时并不会把 770B 全部算一遍普通团队和个人玩家也有机会把它跑起来。同一天WorkBuddy 宣布限时两周免费正好可以把刚发布的开源模型接进一个集成工作台里边部署边用。这篇文章我不打算搬运官方新闻稿只想从一个老玩家的角度把 770B MoE 的部署逻辑、WorkBuddy 的接入方式以及我踩过的那些坑一次讲清楚。如果你最近在关注开源大模型或者正好需要一个能承载日常编程、文档整理、自动化任务的 AI 工作台这篇内容应该能帮你少走几步弯路。我会按“先懂原理再上手”的顺序来先拆解 MoE 和 770B 意味着什么再给出实际部署路线然后是 WorkBuddy 的安装配置和进阶玩法最后附上一份可以直接翻的排错清单。1. 这个 770B MoE 开源模型为什么值得关注1.1 开源大模型首次把“千亿总参数”放到社区手里在 Hy4 preview 之前开源圈子里能稳定下载的模型规模大多停在 7B、14B、70B 这个区间。哪怕后来出现了一些更大的 Dense 模型普通玩家也只能看着参数文档干瞪眼——不是不想跑而是包含全部参数的前向计算太吃算力一张 80GB 的 A100/H100 都未必放得下推理态。Hy4 preview 走的是 MoE 路线。MoE 全称 Mixture of Experts中文一般叫“混合专家”核心思想是把一个大模型拆成多个子网络每个子网络只处理部分任务或输入。真正跑推理时输入会给每个 token 分发给少数几个专家网络而不是把所有专家全部计算一遍。所以“770B”这个总参数量只是静态文件里存了多少参数动态执行时只激活其中一小部分这跟传统 Dense 模型的“参数即计算量”逻辑有本质区别。这里要特别说明一句我不会替官方假想准确的专家数量、激活参数之类细节因为不同 MoE 模型配置差异很大有的 8 个专家里选 2 个有的是 256 个专家里选 8 个。但你可以用已有的开源 MoE 模型做参照像 DeepSeek-V3 总参数 671B激活参数只有 37B 左右日常推理时用的显存和算力比同规模 Dense 模型少一个数量级效果却接近更大参数量的 Dense 模型。Hy4 preview 的 770B 应该也是这个思路具体以官方模型卡为准。1.2 “总参数大、激活参数小”带来的连锁反应MoE 设计的直接好处是效果和成本解耦。总参数变大意味着模型有能力在预训练阶段“记住”更多知识激活参数控制得住意味着每次推理的浮点运算量不会跟着总参数一起膨胀。用大白话讲就像一家公司总共有 770 名员工但处理一个具体任务时只有 30 到 40 人真正上手其他人在后台待命。前端看到的响应速度取决于上手的人数而不是全公司人数。这个特性让 770B 这样的模型具备两个看起来很矛盾的优势一是“能打的参数天花板足够高”在复杂推理、长文本理解、代码生成这类任务上更容易逼近闭源头部模型二是“实际消耗可控”只要推理框架和量化方案选得合适4 到 8 卡的服务器就能把这套模型架起来不必上到 H100 集群。这也是为什么我在看到 770B 时没有直接关掉页面而是愿意花时间研究部署路线。当然总参数量大也不是没代价。哪怕推理时只激活一部分专家模型文件本身仍然要完整加载到显存或内存里。这是 MoE 模型部署时最值得先算清楚的一笔账后面我会专门用一章节讲显存估算。为了帮助理解我把 Dense 和 MoE 的特征差异整理成了一个对比表这也是我做技术选型时最常用的一张表维度Dense 模型MoE 模型参数使用方式所有参数参与每次推理只有被 Router 选中的专家参与算力需求随参数量线性增长主要随激活参数量增长模型文件体积大更大总参数量通常远超 Dense推理框架要求几乎所有框架都支持需要支持稀疏专家调度的框架效果上限提升密集在同样激活参数下更容易做大规模1.3 谁适合第一时间上手如果你符合下面任意一种情况我建议你把 Hy4 preview 列入试用清单你在做开源模型选型想比较 770B 级 MoE 和 70B 级 Dense 模型的效果差距。你手头有多张消费级显卡或一台中高端服务器想跑一个“能打”的本地大模型。你在用 WorkBuddy 这类 AI 工作台希望把背后的模型换成自己可控的开源模型降低单次调用成本。你想学习 MoE 架构的推理、量化和服务化部署需要一个按真实项目练手的素材。对单纯聊天场景770B 可能有点大材小用对生产级任务比如代码仓库分析、长文档总结、自动化流程调度这类大参数模型反而值得认真测一轮。2. MoE 架构白话拆解大模型的“分工合作”2.1 什么是 MoE路由机制怎么工作要理解 MoE可以先忘掉“神经网络”这几个字。你只要想象一家公司公司有 770 名员工不同员工擅长不同领域有人擅长写文案有人擅长写代码有人擅长财务分析。公司前台Router路由器收到一个新任务时先快速判断任务属于什么类型然后只把任务派给最合适的 20 名员工其他员工继续休息或者干别的活。这 20 名员工处理完后把结果汇总给前台前台再返回出去。在 MoE 模型里这些“员工”就是专家网络Expert大模型中的前馈网络层被复制成多份每份参数不同、职责偏向也不同。Router 是一个轻量级网络会针对 token 的输出向量计算一个分数分布然后选出分数最高的 Top-K 个专家参与这次前向计算。所有被选中的专家输出会加权求和得到一个统一的层输出。这里有个容易误解的点token 和专家不是一对一关系。一个 token 可能被分给 2 到 8 个专家同一句话里的不同 token 也会被分给不同专家。这也是 MoE 模型训练中最考验工程的地方——如果 Router 分配不均衡某些专家会被疯狂调用而其他专家被闲置训练效率和最终效果都会变差。所以现代 MoE 模型在训练时都会加入负载均衡损失load balancing loss之类的约束。2.2 稀疏激活为什么能省钱传统 Dense 模型每一层都要对所有参数做矩阵乘法所以“计算量约等于参数量”。MoE 模型虽然也把所有专家参数加载到显存里但每个 token 只经过少数专家所以真正参与的矩阵乘法的参数量大幅下降。通常我们用激活参数量activated parameters来衡量每次推理的算力需求。举例来说一个总参数 770B、激活参数约 40B 的 MoE 模型单 token 推理的计算量大概相当于一个 40B 的 Dense 模型。与此同时这个 MoE 模型的“知识容量”却接近总参数 770B 的 Dense 模型。也就是说你用一个中型模型的算力成本拿到了大型模型的效果上限。这就是“稀疏激活”的价值所在。稀疏激活和 Dropout 那种训练期随机丢弃不同MoE 的结构性稀疏是写在网络结构里的专家参数是独立的路由选择是动态的。每次前向计算只有一部分参数路径被真正走过。2.3 MoE 落地的三个关键门槛不过MoE 也不是完全没有代价。我自己在部署其他 MoE 模型时总结出三个绕不开的门槛第一是显存。总参数再大也依然要全部放进显存或内存不像 Dense 模型可以抠抠搜搜地把一层层加载到 CPU。想跑 770B一张卡就别想了要么多卡并行要么量化到 INT4 甚至更低位宽并接受一定的效果折损。第二是推理框架的适配。MoE 的专家分发逻辑和 Dense 模型不同不是所有推理框架都支持。老牌的 Transformers 库虽然能加载但速度不理想。更推荐 vLLM、SGLang、TensorRT-LLM 这类对 MoE 做过专项优化的框架。第三是显存带宽瓶颈。MoE 模型每次推理只需要少量算力但要把相关专家参数从显存里搬到计算单元这个过程非常吃显存带宽。多卡并行时还要考虑跨卡通信开销。这也是为什么 MoE 模型的吞吐不一定比同激活参数的 Dense 模型高很多但它的优势在于同样的模型容量下模型质量更高。3. 开源模型拿到手怎么部署才不翻车3.1 先算清这笔显存账避免下完模型才发现跑不动部署一个 770B MoE 模型第一件事不是敲命令是算显存。我通常用一个非常简单的公式模型文件大小约等于参数量 × 每个参数占用的字节数。如果加载成 FP16/BF16每个参数占 2 字节770B 需要 1.54TB 存储空间。如果量化成 INT8每个参数占 1 字节需要大约 770GB。如果量化成 INT4每个参数占 0.5 字节需要大约 385GB。如果继续压低到 3bit、2bit会进一步减小但效果损失和部署复杂度也会上升。这还只是权重本身的静态占用。推理时还要算上 KV Cache、激活值、临时缓冲等动态占用通常会在权重基础上再加 10% 到 30%。如果你用 8 张 80GB 的显卡BF16 加动态占用应该能塞进去如果用 4 张 80GB 的显卡大概率只能跑 INT4 量化版本而且上下文长度不能开太大。这里我强烈建议你在动手下载之前先做一个估算先把显卡总显存写下来再减掉系统预留然后对照模型格式的每字节占用看差多少。如果差距很大就先走 API 或者云端推理不要硬刚本地。3.2 不同硬件条件下的部署路线对比我把常见的部署路线整理成一张表方便你对号入座硬件条件推荐方案优点局限无显卡或显存低于 16GB直接使用官方 API 或第三方云服务零门槛、稳定有调用成本数据出本机单张 24GB 显卡选用较小 MoE 模型或等待社区量化版配合 CPU offload能跑起来成本低速度较慢上下文受限4× 80GB 显卡INT4/AWQ 量化版 vLLM 多卡推理本地运行效果接近完整版量化带来少量效果损失8× 80GB 显卡BF16 全精度 vLLM效果最好长上下文也能开硬件门槛高表里说的“社区量化版”是指后续可能出现的 GGUF/AWQ/GPTQ 等格式。新模型刚开源时官方一般先放完整的 BF16 权重量化版本需要等社区做校准和验证通常几天内就会有。如果你等不及也可以自己用 AutoAWQ 或 llama.cpp 的量化工具做转换但量化后一定要跑一遍验证集确认输出没有明显劣化。3.3 本地部署实操示例下面给一份通用到“换掉模型名就能用”的部署示例。我先按 vLLM 来因为 vLLM 对 MoE 和长并发的支持最稳定也能开出 OpenAI 兼容 API方便后面 WorkBuddy 直接接入。第一步下载权重。建议先设好镜像环境变量不然 700 多 GB 的文件下载能拖到天荒地老。这里不展开讲具体镜像用法但原则是模型文件越大越要先解决好网络问题。# 安装依赖 pip install -U vllm huggingface_hub # 下载模型MODEL_ID 需要替换为官方仓库 ID huggingface-cli download MODEL_ID --local-dir ./models/hy4-preview第二步用 vLLM 启动一个 OpenAI 兼容服务。下面是简化示例# serve_hy4.py from vllm import LLM, SamplingParams model_path ./models/hy4-preview llm LLM( modelmodel_path, tensor_parallel_size4, # 用几块卡就填几 gpu_memory_utilization0.9, max_model_len8192, quantizationawq, # 如果是量化版在这里声明格式BF16 权重要去掉这行 ) params SamplingParams(temperature0.7, top_p0.9, max_tokens1024) outputs llm.generate([请用一段话解释什么是 MoE 模型], params) print(outputs[0].outputs[0].text)如果走命令行可以直接用 vLLM 的服务入口vllm serve MODEL_ID \ --tensor-parallel-size 4 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9服务起来后会监听 8000 端口并提供一个/v1/chat/completions接口。接下来无论你是写 Python 代码调用还是在 WorkBuddy 里配一个自定义模型都把它当成一个本地的 OpenAI 兼容服务来使用就行。如果显存实在紧张也可以等社区放出 GGUF 量化版然后用 Ollama 或 llama.cpp 跑。Ollama 的好处是一条命令就能拉起服务缺点是长上下文和并发性能比不上 vLLM。我个人的倾向是先看社区是否出了成熟量化版没有就用 vLLM 自己转尽量避免拿 Transformers 硬扛。4. WorkBuddy 是什么这两周免费怎么用4.1 它和你平时用的聊天机器人不是一回事聊完模型部署回到 WorkBuddy。从目前公开的信息和热词来看WorkBuddy 更像一个“AI 工作台”而不是单纯的聊天窗口。它的定位是把你日常会用到的大模型能力收纳到一个能做编程协作、任务管理、文档处理的集成环境里并且支持自定义指令和技能包扩展。你可以把它理解成“带装修的 AI 前台”模型是后台的大脑WorkBuddy 是前台的工作台。它本身不产出智能但它负责把模型能力接到你的工作流里——比如你选中一段代码让它解释或者补 bug你丢进去一个文件夹让它做技术方案你把一段零散笔记扔进去让它整理成结构化文档。这类操作如果直接在终端里用脚本调 API也不是不行但 WorkBuddy 把交互界面、上下文管理和技能调度都做进了产品里效率高不少。关于免费这两周我的建议是别只把它当试用要直接当主力用。两周时间足够你把一个真实项目里的几个核心场景跑顺也能逼你把自定义指令调教到顺手。4.2 下载、安装和首次配置WorkBuddy 的安装包一般会提供 Windows、macOS 和 Linux 三个版本。Windows 和 macOS 用户下载后正常安装即可如果你平时用 Linux 服务器需要在无图形界面环境下跑记得选择服务端模式。首次启动后它会引导你完成三件事登录账号。如果有限时免费活动注册本身应该就能领到额度具体规则要看官网说明我这里不代替官方确认。配置模型。WorkBuddy 一般支持云厂商 API 和自定义模型两种接入方式。云厂商 API 适合不想折腾的用户自定义模型适合接本地部署的开源模型。创建工作区。选择一个文件夹或者项目作为工作目录WorkBuddy 就能读取项目上下文这也是它和普通聊天窗口拉开差距的地方。配置模型这一块我重点说一下自定义模型怎么填。如果你已经用 vLLM 把 Hy4 的推理服务跑起来了那 WorkBuddy 里只需要设置API Base URLhttp://127.0.0.1:8000/v1API Key本地服务一般不做校验随便填一个占位符就行模型名称填写你启动服务时用的模型名或路径别名保存后WorkBuddy 里的对话就会走你本地的开源模型。这样既不产生 API 费用数据也不用出本机。4.3 两周免费的正确打开方式免费期最怕的就是“到处点点看看然后时间就没了”。我建议你按这三步来安排第一步先把基础链路跑通。注册、接入一个模型、在一个真实的项目目录里发起一次带上下文的对话确保整个链路没有断点。第二步做一次真实任务。比如把你手头一个不太紧急但很耗时的任务交给 WorkBuddy整理一份接口文档、批量改写一段脚本、生成一堆测试用例。真实任务才能暴露问题比如上下文不够长、输出长度限制、自定义指令没生效等等。第三步逐个打磨技能包。下一篇我会专门讲 Skill 玩法这里先记住一个原则技能包是把“模型会做”变成“我的工作台真的会做”的关键。免费期过了哪怕 WorkBuddy 需要付费你调试好的技能包和工作流也可以迁移到其他工具上并不吃亏。5. WorkBuddy 进阶玩法自定义指令、Skill 与本地模型接入5.1 自定义指令把你的需求变成模板WorkBuddy 的自定义指令本质上就是系统提示词system prompt的产物式管理。对普通用户来说最大的价值是“一次设定反复使用”。我举一个真实场景你经常让 AI 评审代码每次都要重新解释项目背景、编码规范、输出格式又累又容易漏。你可以写一个“代码评审员”指令模板你是一名资深代码评审员。项目背景Java 微服务项目团队遵循 Clean Code 原则。 请按以下要求评审我发来的代码 1. 先指出逻辑错误和安全隐患。 2. 再提出可读性和性能改进建议。 3. 每条建议标注优先级高/中/低。 4. 最后给出重构后的示例代码。保存成自定义指令后每次需要评审代码直接选中代码并调用这条指令即可。它会自动把这段模板拼到对话上下文中节省大量重复描述时间。自定义指令的另一个用途是控制输出风格。如果你需要让 AI 输出中文技术文档、Markdown 格式、带表格可以在指令里声明清楚。我见过很多用户抱怨“模型输出格式总不对”其实往往不是模型不行而是没有把约束写进指令里。5.2 Skill 技能包把单次能力变成可复用工具Skill 可以理解为一个“带输入输出约定的完整技能包”它比自定义指令更进一步Skill 不仅包含提示词还可以附带脚本、工具调用方式、参数定义等相当于把一个小型自动化任务封装起来。比如你可以做一个“周报生成器”技能输入是这一周的 git 提交记录或日志文件输出是一份结构化的周报。技能内部会先调用命令读取日志再调用模型总结最后按模板生成 Markdown 周报。这种能力从本质上说是“工作流自动化”而 WorkBuddy 只是把这些环节组合在了一起。在当前热词里反复出现的 “WorkBuddy skill”我猜测官方后续会提供技能市场或者示例库。哪怕目前还没有太多成品技能你也完全可以自己写。写 Skill 的时候我建议从频率高、步骤固定的任务入手不要一上来就做很复杂的编排。一个简单的 Skill 配置大概长这样{ name: weekly-report, description: 根据 git 提交记录生成周报, inputs: [ { name: since, description: 起始日期例如 2025-01-01, required: false } ], steps: [ git log --since{since} --prettyformat:%s, 将提交记录按模块分组总结为结构化周报, 输出 Markdown 格式包含本周完成、待推进、风险三部分 ] }这个配置只是示例真实 Skill 的字段名要看 WorkBuddy 的文档规范但思路是通用的先定义输入参数再定义执行步骤最后固定输出格式。把常用任务沉淀成 Skill 之后你相当于给自己搭了一个“重复劳动自动机”这才是 WorkBuddy 这类工作台真正的效率来源。5.3 把本地模型和云端模型混着用真正用起来之后你会发现本地模型和云端模型各有优势。本地模型的优势是隐私、可控、无调用费云端模型的优势是性能更强、上下文更长、维护成本低。WorkBuddy 一般支持同时配置多家模型。我的推荐用法是常规聊天、代码补全、轻度总结走本地 MoE 模型长文档分析、复杂推理、一次性需要高质量输出的任务走云端模型。切换模型不需要重新部署只需要在会话里换一个模型选项即可。如果你是 Linux 服务端部署还需要注意两点一是确保本地模型服务的防火墙只对可信网段开放不要暴露到公网二是如果 WorkBuddy 和模型服务不在同一台机器API Base URL 里的 127.0.0.1 要改成模型服务所在机器的内网 IP。这两个细节看似不起眼但能省掉不少排查时间。6. 常见问题与排查技巧实录6.1 模型下载和显存相关的坑问题一模型文件下载太慢甚至中断。上千 GB 的文件用单线程下载是非常不明智的。建议用支持断点续传的工具下载前配置好镜像环境变量下载完成后计算一下文件哈希防止文件损坏。问题二推理启动时报 CUDA out of memory。先检查有没有把其他模型或者进程占用的显存清掉然后看gpu_memory_utilization是否设置得过高一般 0.85 到 0.9 比较稳妥最后还是不行只能降级到更低位宽的量化版或者减小max_model_len。上下文长度对显存的影响非常大从 8192 降到 4096 往往能救回来。问题三量化后输出质量明显下降。如果量化版本效果太差可以换一种量化方法试试比如把 GPTQ 换成 AWQ或者从 4bit 改回 8bit也可以只量化部分层保留某些关键层为高精度。这些都需要花时间做验证不能只看困惑度指标。6.2 WorkBuddy 连接不上本地模型这是我在实践中遇到最多的问题。WorkBuddy 侧报错但curl直接请求模型服务又正常九成是 base URL 填错了。注意 OpenAI 兼容服务的地址一般要写全包括/v1这个路径有些模型服务还要求 API Key 不能为空随便填一个即可。另一个常见原因是模型名称对不上。WorkBuddy 里填写的模型名必须和推理服务返回的模型 ID 一致否则模型服务会返回 404。可以在浏览器里访问/v1/models接口查一下服务端实际注册的模型 ID再照抄到 WorkBuddy 里。6.3 自定义指令“不生效”怎么办自定义指令不生效绝大多数情况不是软件 bug而是上下文被后续聊天覆盖了。你可以试试这几个办法把指令写在项目级配置里确保每次会话都加载指令本身不要太长关键要求放在前面在对话框里明确说一句“请遵守我的代码评审指令”之类的触发词帮助模型把注意力拉回指令上。另外不同的模型对指令的遵循能力差异很大。某些小模型可能把指令当普通文本忽略掉这时你应该优先检查模型选择而不是改指令内容。770B 级别的 MoE 模型在指令遵循上通常会有明显优势这也是我建议把 Hy4 这类大模型接进 WorkBuddy 的原因之一。6.4 安全和隐私别把敏感数据随便暴露本地部署最大的价值之一就是数据不出本机。但如果你把本地模型服务端口暴露在公网或者把 API Key 写进了日志那“本地”也就失去了意义。给三个最基础的建议本地模型服务只监听内网地址不要设置为 0.0.0.0除非你有明确的外网访问需求。WorkBuddy 的配置文件和会话记录里可能包含 API Key定期检查.gitignore不要把配置文件提交到公开仓库。涉及个人隐私、公司内部数据或未公开代码的任务尽量走本地模型云端模型虽然方便但要留意服务商的隐私协议。我在实际部署中还有一个小习惯新模型起来后先用一组完全无敏感的测试问题跑一遍确认输出格式和速度都正常再开始接正式任务。这个习惯能避免在排查问题时把真实业务数据送去未知接口也算是一种基本的风险管理。最后说点个人的体会。很多人看到 770B 的第一反应是“这么大怎么跑”但 MoE 让我重新认识了一件事在开源模型世界参数数量不再是唯一的门槛部署策略和工具链的成熟度反而更重要。Hy4 preview 的意义不只是又多了一个大模型而是把“千亿总参数、可控激活参数”的组合第一次摆到了普通开发者的桌面上。WorkBuddy 这两周免费期恰好是一场低成本的压力测试——你可以用真实项目去验证一个可本地部署的 MoE 模型能不能替代部分云端主力模型。我的建议是别只看测评报告自己上手跑一圈跑通之后再决定要不要长期用。这种“先干活再评判”的方式往往比刷各种数据更可靠。