今天凌晨刷 Hugging Face 的时候看到 Hy4 preview 的权重挂出来了，770B 总参数、MoE 架构，点进去确认了两遍许可证，确实是开源。说实话过去一年我部署过的开源大模型不少，从 7B 到 671B 的 MoE 都摸过，对“开源”这两个字已经有点脱敏，但 770B 这个数字摆在面前，还是忍不住把手边几台机器重新盘了一遍。再往下翻，发现配套的 WorkBuddy 工作台也放出了限时两周免费的公告，也就是说模型和工具链在同一天更新了。这篇文章就把我这几天从头到尾的体验整理一下，包括架构怎么看、权重怎么部署、WorkBuddy 怎么接，以及我在这个过程中踩过的坑。
1. 770B MoE 开源，为什么说这次不一样
1.1 先弄清总参数和激活参数的区别
很多人在看到“770B”的第一反应是“这得多少张卡才能跑”，但 MoE 恰恰是来解决这个矛盾的。混合专家（Mixture of Experts）架构的基本思路，是把一个大模型拆成多个“专家”子网络，输入一个 token 的时候，不是让所有专家都参与计算，而是通过一个路由机制选出一小部分专家来干活。这个机制最早在学术圈里被反复讨论，这两年才真正大规模走进工程落地，靠的就是它在“模型变大”和“推理成本不能跟着疯涨”之间找到了平衡点。
这也是为什么 MoE 模型的“总参数量”和“激活参数量”是两个完全不同的概念。总参数是权重文件占用的体量，决定模型的知识容量；激活参数是每个 token 实际参与计算的参数，决定推理时需要的算力和显存。打个比方：770B 是这家公司的全部在编员工，激活参数是今天真正到岗干活的那些人。公司规模看前者，办公室租金看后者。对外宣传时厂商习惯报总参数，因为它数字大、听起来猛，但你真正为推理掏钱的时候，算的是激活参数。
结合目前公开的 MoE 设计惯例，770B 总参数对应的激活参数大概率落在 30B-50B 这个区间。也就是说，单 token 的推理计算量大约相当于一个 40B 左右的 Dense 模型，单机 8 卡 A100/H100 级别就能承载。这才是 770B 能开源、而且普通人真正玩得起的根本原因。如果它是一个 770B 的 Dense 模型，那今天这篇文章的主题就不是“怎么部署”，而是“看看就好”。
1.2 这个体量在开源模型里是什么位置
要把 770B 放到坐标系里看，得看几个参照物。目前开源阵营里能稳定下载到权重的大尺寸模型，一类是 70B 左右的 Dense 模型，一类是 300B-700B 区间的 MoE 模型。Hy4 preview 的 770B 总参数，直接把这个梯队的天花板又往上顶了一截，逼近顶级闭源模型的规模。参数体量当然不等于能力上限，但在大模型领域，规模仍然是很多能力的基础，尤其是知识密度、长上下文建模、复杂推理这类对容量要求高的任务，体量不够就是不够。
更值得关注的是“开源模型质变”这个大趋势。前两年说开源模型，默认的叙事是“在闭源后面追”，追的是推理能力、代码能力、Agent 工具调用这些硬指标。但最近几个大尺寸开源模型的发布节奏明显在加快，这次直接拿出 770B 级别的大家伙，等于是把竞争拉到了参数体量的层面。对于做应用层开发的我来说，最直接的影响是：以前有些任务不敢用开源模型做底座，现在可以认真评估了。成本账很简单，闭源 API 按 token 计费，长期跑批量任务是一笔不小的开销；开源权重一次投入硬件成本，边际成本趋近于零。当开源模型的能力逼近那个临界点，迁移的动力就会自然出现。
1.3 preview 阶段意味着什么
标题里有个词容易被人忽略——preview。它不是正式版，这意味着三件事。第一，权重后续可能还会更新，你现在看到的评测结果未必是最终版本的成绩。所以我建议不管用它做什么，都先跑一轮自己的测试集，留存数据，等正式版出来再对比一遍，看看官方到底改了什么。第二，API 和接口规范可能变动。如果用 preview 版做开发，代码里尽量把模型名、参数名这类东西收敛成配置项，别写死在业务代码里，否则正式版一发布，你就要经历一轮无意义的返工。第三，部分能力可能是灰度的，官方文档里标了“coming soon”的功能，别在生产环境押注。
我的建议很明确：生产环境先观望，测试环境和内部工具大胆上。preview 版最适合干的事，就是验证效果、攒部署经验和跑评测基线。这就像买期房之前先去工地转一圈，你不需要等它完全交付才知道户型合不合适。
2. 拿到开源权重之后：本地部署的算力账和实操链路
2.1 先算清楚显存账，再决定下不下权重
这是整个部署过程中最容易被低估的一步。770B 全量权重，如果用 bf16 精度存储，一个参数占 2 字节，770 × 2 = 1540GB，也就是 1.5TB 显存。单张 A100 80G 至少要 20 张才能装下，而且这还没算 KV Cache、激活值和推理框架本身的开销。KV Cache 是推理时为加速生成而缓存的历史键值对，它的大小会随着上下文长度和并发请求数线性增长，长上下文场景下这块开销甚至能占到总显存的三分之一。
所以部署 770B 级模型，核心策略就两条：降精度、上多卡。我整理了一张表，方便你对着自己的硬件做判断：
| 方案 | 显存需求（约） | 硬件门槛 | 适用场景 |
|---|---|---|---|
| bf16 全精度 | 1.5TB+ | 20×A100 80G 起 | 基准测试、权重复核 |
| FP8 | 约 800GB | 10×A100/H100 80G | 追求精度的高性能服务 |
| 4bit AWQ/GPTQ | 约 420GB | 8×A100 80G / 4×H100 | 小团队自用、内部工具 |
提示：显存估算只是第一步，实际部署时 KV Cache、推理框架自身开销、并发缓冲都要另外预留，建议按表格数字的 120%-130% 做硬件规划，否则一上量就 OOM。
2.2 从下载到拉起服务：ModelScope + vLLM 完整步骤
权重在哪下、怎么下，是有讲究的。国内网络环境下直连 Hugging Face 经常抽风，ModelScope 的镜像速度要稳得多。下载用 modelscope 的命令行工具，一条命令就能把整个仓库拉下来：
pip install -U modelscope vllm modelscope download --model <org>/Hy4-770B-preview --local_dir ./Hy4-770B-preview权重落盘后，用 vLLM 起一个 OpenAI 兼容的服务，方便后续接各种工具和客户端。这是我最常用的启动命令：
python -m vllm.entrypoints.openai.api_server \ --model ./Hy4-770B-preview \ --tensor-parallel-size 8 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --quantization awq两个最容易踩的参数说一下。--tensor-parallel-size必须和实际卡数一致，写错了 vLLM 启动阶段就会直接报错；--max-model-len不要一上来就拉满，MoE 模型的 KV Cache 开销不小，建议从 16K 开始，确认显存够用再往上调。另外注意--served-model-name这个参数，如果不单独指定，vLLM 默认用权重目录名当模型名，后面接 WorkBuddy 或者其他客户端时，模型名必须跟它保持一致，否则请求会 404，这个坑我后面细说。
2.3 量化方案怎么选：FP8、AWQ 还是 GPTQ
如果硬件能撑住，我的排序是 FP8 > AWQ > GPTQ。理由很朴素：MoE 模型对量化比 Dense 模型更敏感。AWQ（Activation-aware Weight Quantization，激活感知权重量化）是目前 4bit 量化里成熟度比较高的方案，它根据激活分布来选择需要保留高精度的权重通道，理论效果比普通 GPTQ 更稳。但在超大规模 MoE 上，真正的问题出在路由机制：MoE 的每个 token 都要经过路由层决定去哪些专家，这部分对数值精度非常敏感。量化误差会干扰路由判断，极端情况下模型会频繁选错专家，表现就是“回答质量突然掉档”。
我在 4bit 下实测确实遇到过这种情况：同样的 prompt 连续跑两次，一次输出完整，一次明显偏题，而且没有任何规律可循。所以我的建议是：显存够就优先 FP8，质量损失最小；显存不够再考虑 AWQ 4bit，但要接受偶发的不稳定。GPTQ 在这类超大规模 MoE 上的工具链成熟度目前还不如 AWQ，如果你不太熟悉量化流程，先别急着试。
2.4 部署完成后的冒烟测试清单
服务起来以后，别急着上业务流量，先跑一组冒烟用例。我固定用这几个：一个 2000 字的技术文档摘要、一个连续 10 轮的多轮对话（中间穿插改需求）、一个带约束条件的代码生成（要求用特定库、特定风格）、一个长文档问答（长度压到接近上下文上限）。跑完看三件事：响应延迟是否稳定、有没有 OOM、长上下文段的输出质量是不是明显下降。
这一步看着简单，但能过滤掉绝大多数“部署成功但实际不可用”的情况。特别是长上下文，很多模型部署完短文本一切正常，一上长文本就原形毕露——要么直接报错，要么上下文中间位置的信息被模型忽略。770B 级别的模型大家冲的就是它的大容量，如果长文本这关过不了，那部署的意义就少了一大半。
3. WorkBuddy 限时免费两周：它到底解决什么问题
3.1 先把 WorkBuddy 和 CodeBuddy 分清楚
好多人分不清 WorkBuddy 和 CodeBuddy。我的理解是这样的：CodeBuddy 面向的是编程场景，重心在代码补全、代码生成、仓库理解这些开发者日常；WorkBuddy 是更通用的智能体工作台，重心是把 AI 能力编排进完整的工作流程，不设领域限制。换句话说，CodeBuddy 是给程序员写的代码搭子，WorkBuddy 是给所有知识工作者用的人工智能操作台。前者回答“这段代码怎么写”，后者回答“我这摊事怎么让 AI 帮我从头到尾跑完”。
这个定位差异决定了它们的用法完全不同。CodeBuddy 的价值藏在编辑器里，你写代码的时候它默默补全；WorkBuddy 的价值藏在流程里，你得主动把业务场景抽象成流程，它才能帮你跑起来。如果你只是想要一个“能聊天的 AI”，这两个都不适合你，直接用网页版对话产品就行。
这也解释了为什么 WorkBuddy 要在这时候推出限时免费：Hy4 这种 770B 级别的开源模型发布后，真正缺的不是模型本身，而是把模型变成生产力的那一层工具。工作台类产品，就是在补这一环。模型是发动机，工作台是变速箱和方向盘，光有发动机你哪也去不了。
3.2 从零搭建个人工作台：模型配置到 skill 串联
WorkBuddy 的核心抽象是三个：工作台（workbench）、技能（skill）、流程（workflow）。第一次用，按这个顺序走。
第一步，安装客户端，在设置里添加模型服务。WorkBuddy 支持 OpenAI 兼容接口，我本地用 vLLM 起的 Hy4 preview 服务，直接填http://localhost:8000/v1和对应的 api key 就通了，不需要额外插件。如果你不想折腾本地部署，直接用官方托管的模型服务也行，但说实话，自己的权重 + 自己的工作台这个组合自由度最大，数据也不出内网。
第二步，创建 skill。skill 就是把高频动作固化成可复用技能，比如“周报生成”“会议纪要转待办”。写 skill 描述的时候有个技巧：描述越具体，触发率越高。只写“生成周报”远不如“根据本周工作日志生成结构化周报，包含完成事项、风险、下周计划三部分”好用。这跟写 prompt 是一个道理，AI 工具说明书式的输入，它才会给你说明书式的输出。
第三步，把 skill 串成 workflow。典型的例子：拉取邮件 → 生成摘要 → 提取待办 → 写入项目管理工具。这一步是把“AI 问答”升级成“AI 干活”的关键，也是 WorkBuddy 这类工具的核心价值所在。单点调用 AI 能力谁都会做，但把多个 AI 步骤和业务系统串起来，才是真正省时间的地方。
3.3 API 接入与业务流程编排的实际用法
热词里“workbuddy api接入”“workbuddy业务流程”的搜索量很高，说明这是不少人的刚需。实际用下来，API 接入分两个方向。
一个方向是 WorkBuddy 作为客户端，接入外部 API。比如在 workflow 里调用你们内部的审批系统、CRM、工单系统，把 AI 生成的结果写回业务系统。另一个方向是把 WorkBuddy 本身的能力开放成 API，被业务系统反向调用。比如客服系统收到工单后，调 WorkBuddy 的接口做自动分类、提取关键信息、生成处理建议，然后再回流到工单系统。
我目前用得最多的是第一种。举一个真实案例：我这边有个需求流转的流程，以前是人工把需求文档里的关键字段摘出来填到表格里，再通知相关人。现在用 WorkBuddy 串了一条 workflow，文档传进来之后自动提取、自动填表、自动发通知，整个过程不到一分钟，之前人工做至少要十分钟，而且容易漏字段。这种“AI 编排”比单点调用模型 API 价值大得多，因为中间的状态管理、工具调用、人审环节，工作台都帮你兜住了。
3.4 两周免费期最值得做的几件事
限时免费意味着这两周内你不需要为工具买单，但时间窗口很短，别浪费在“玩”上。我建议按这个节奏来：第一周，把模型接好，把 2-3 个自己最高频的工作场景固化成 skill。别贪多，先跑通一个端到端的 workflow，比建十个半成品 skill 强。第二周，上真实业务验证。把 workflow 接到真实数据上，记录效果和失败案例，形成一份自己的评测样本。到期之前做付费决策，同时把免费期配好的 skill、workflow、模型配置全部导出备份，免得切换账号时丢失。
两周时间说长不长，但足够验证一个核心问题：这个工作台在你自己的业务场景里，到底是真提效还是伪需求。这个答案，只有你自己跑过才知道。
4. 一周实测记录：能力边界和踩坑清单
4.1 我的测试环境和方法
先交代环境：8×A100 80G，4bit AWQ 量化，vLLM 部署，max-model-len 设的 32K。我用的是自己的业务样本，没有跑通用榜单，因为我想验证的是“能不能用在自己的实际业务里”。测试集分三组：代码生成（Python、SQL、Shell 混合）、文档处理（长文档结构化提取、字段级信息抽取）、Agent 场景（工具调用、多轮指令跟随、格式约束）。这样测出来的结果，比任何公开榜单都更贴近我的真实使用情况。
4.2 实测结果：强在哪里，弱在哪里
先说强的部分。长上下文照应能力是我最意外的，丢了一个 8 万字的技术文档进去，让它按预先定义的 schema 提取十几个字段，几乎没漏。这个能力值回票价，因为很多场景（合同审阅、技术文档归档、日志分析）卡的就是长文本处理。复杂指令跟随表现也不错，“先做 A 再做 B，输出格式为 C，不要出现 D”这种多步约束基本能全程遵守，没有中途跑偏。代码生成质量接近我常用的闭源模型，常见的工程问题一次写对的概率很高。
再说弱的部分。4bit 量化下的偶发“掉档”问题确实存在，路由层对量化敏感，表现就是偶尔输出离题。中文表达在某些正式文档场景下有点生硬，特别是需要写公告、汇报材料这类文本时，措辞偶有 AI 味。多轮工具调用偶尔会重复调用同一个函数，需要人工打断。
| 测试场景 | 表现 | 说明 |
|---|---|---|
| 长文档字段提取 | 优秀 | 8 万字文档提取十几个字段，几乎无遗漏 |
| 复杂指令跟随 | 良好 | 多步约束基本全程遵守 |
| 代码生成 | 良好 | 接近常用闭源模型 |
| 4bit 量化稳定性 | 一般 | 偶发输出掉档 |
| 多轮工具调用 | 一般 | 偶尔重复调用同一函数 |
整体评价：如果只拿它当问答引擎，有点浪费；拿它做长文档处理和 Agent 编排，是目前开源阵营里性价比很高的选择。只要不是在生产环境直接裸奔 4bit，它的稳定性问题完全可以通过工程手段兜住。
4.3 部署侧踩坑记录
部署这一周我踩了几个实实在在的坑，写出来给大家省时间。
坑一：max-model-len 拉满导致 OOM。一开始图省事直接设 128K，结果启动没报错，一跑长文本进程直接崩。最后不断往下调，在 32K 附近才稳定。长上下文的代价是显存，这是物理规律，没有捷径。
坑二：tensor-parallel-size 和实际卡数不一致。有一次机器上只有 6 张卡空闲，命令里还写的 8，vLLM 启动阶段直接抛错，提示找不到足够的 device。这个参数写错基本是秒报错，反而好排查，但服务器上如果有其他任务占着 GPU，你启动时就要特别留意空闲卡数。
坑三：模型名写错导致 404。接 WorkBuddy 的时候，base_url 对了、key 对了，但模型名填的跟 vLLM 启动时的--served-model-name不一致，请求全部 404。vLLM 默认会用权重目录名当模型名，对接时一定确认两边一致。这个错很隐蔽，因为报错信息看起来像是网络问题，实际上就是模型名不匹配。
坑四：并发上来之后首 token 延迟明显变大。770B 模型的 prefill（预填充）阶段计算量很大，并发拉高后首 token 时间会被明显拉长。如果业务对响应时间敏感，建议加一层请求队列来控制并发，而不是让请求直接打到模型上。实测下来，把并发控制在硬件承载能力的 60%-70%，首 token 延迟能稳定不少。
4.4 WorkBuddy 使用中的问题
WorkBuddy 整体完成度不错，但免费体验这一周也遇到几个问题。一个是 skill 描述写得不好会直接影响触发率。最开始我写“整理会议纪要”，结果时灵时不灵，改成“根据会议转录文本，输出参会人、决议、待办事项三部分的结构化纪要”之后，触发率明显提升。这个锅一半在产品，一半在我，工具本身就要求你用结构化的方式描述任务，这其实是件好事，逼着你想清楚自己的流程到底是什么。
另一个问题是切换模型后历史会话的上下文会串。我中途换过一次模型源，旧会话再打开时行为有点不正常。建议正式用的时候，每个模型配独立的工作区，别混着用。好在这种切换成本不高，重新建一个工作区、把 skill 复制过去就行。
5. 一点个人体会
这几天玩下来，我最深的感受是：开源大模型已经进入了“规模即底气”的阶段，770B 这个量级的模型开源，意味着以前只有少数大厂才有的能力，现在小团队花几万块钱硬件成本也能摸到。但规模不是终点，真正决定落地效果的，一个是部署链路是不是足够顺，另一个是模型之上有没有好用的工作台。部署这件事，大家拼的是工程经验和算力规划；但工具链这件事，拼的是谁先把“模型能力”变成“业务价值”。
WorkBuddy 这次限时免费，给的其实是同一个机会：让更多人用最低成本把“模型→工作流→业务价值”这条链路完整跑一遍。我建议有条件的读者都去试这两周，不要只当个聊天玩具玩，拿出一两个真实工作场景，认认真真把它接进去跑几天。你会发现，工具的意义从来不在工具本身，而在它帮你省下的时间和改掉的流程。
最后再提一句，preview 版权重和工具都还在快速迭代期，现在踩过的坑、攒下的评测数据，等正式版出来都会变成你比别人早一步的优势。动手吧。
