说出来你们可能不信Hy4 preview 的消息我是在本地把模型跑起来之后才认认真真看完整篇公告的。770B、MoE、开源这三个词放在半年前任何一个都够行业聊上一整周现在大家反而淡定不少。倒是 WorkBuddy 限时两周免费这个点我觉得非常值得拿出来聊一聊尤其是还没把大模型真正用进日常工作的团队这两周窗口基本够你把完整流程跑通、跑透顺便想清楚到底值不值得长期付费。这篇文章我打算从三个层面展开先拆 Hy4 preview 背后的 MoE 架构把 770B 到底是怎么“省着用”的掰扯清楚再讲 WorkBuddy 这两周免费额度怎么用最值避免领了权益只拿来聊天浪费掉最后给一套本地部署的实操路径从环境准备到 vLLM 启动再到常见问题排查。整体偏落地不讲虚的。1. Hy4 preview 发布770B 开源 MoE 到底意味着什么1.1 770B 参数是一个什么量级我平时跟朋友解释模型参数量喜欢打一个比方参数量类似一个人的长期记忆容量参数越多理论上能装下的知识细节和复杂逻辑就越多。770B也就是 7700 亿个参数放在稠密模型里训练和推理都极其奢侈。作为对比大家熟悉的 7B、13B、70B 模型70B 就已经需要多卡推理了770B 单卡想都不用想。但 Hy4 preview 选的是 MoE 架构也就是混合专家模型。这意味着总参数 770B 并不等于每次推理都要把全部参数跑一遍。它的核心思路是把模型内部拆成很多个“专家”每次来一个请求由一个路由模块判断该让哪些专家处理只让少数专家真正参与计算。总容量依然是 770B但单次推理的计算量能够大幅降下来。这个路线在开源社区已经被反复验证过了。从早一点的 Mixtral到后来的 DeepSeek、Qwen 的 MoE 版本大方向都一致。这背后其实反映了一个共识大模型拼参数规模不一定要硬扛稠密架构的成本MoE 是更聪明的“堆料”方式。Hy4 preview 这次直接把 770B 的 MoE 开源等于把开源模型的容量天花板又往上顶了一截。1.2 开源对这些模型的实际价值我一直觉得开源对于大模型的价值从来不是仓库里多了几个权重文件那么简单。开源的核心意义在于它把“使用权”和“二次开发权”真正交到开发者手里。闭源模型只能走 API数据要过服务商的服务器这对很多对数据敏感的团队来说是一道跨不过去的坎。开源模型不一样你可以部署到自己的私有环境数据不出内网也能针对自己的业务做微调、做量化、做定制。Hy4 preview 开源以后最直接的受益者有两类。一类是喜欢折腾部署的工程师可以完整走一遍拉权重、量化、本地部署、压测调优的流程。另一类是做 AI 应用的团队可以基于它去构建私有化产品不依赖外部 API成本结构和数据安全都能自己掌握。再加上 MoE 架构天然适合并发场景服务化部署以后多用户使用的硬件成本摊薄效应非常明显。当然开源也不是没有代价。最大的门槛就是部署。770B 的模型再怎么说也不是一台普通电脑能跑的你至少得解决显存、量化、推理框架选型这一整套问题。这也是我这篇文章花大量篇幅写部署实操的原因。好消息是MoE 架构加上量化技术让这个门槛比想象中低不少。2. MoE 架构原理拆解770B 是怎么被“省着用”的2.1 稀疏激活和路由机制想理解 MoE先得知道传统 Transformer 模型怎么工作。每个 Transformer 层里都有一块前馈网络FFN处理每个 token 时这块 FFN 都得完整跑一遍。稠密模型之所以贵就是因为每个 token 都要经过全部参数不管这个问题是简单还是复杂。MoE 的做法是把每层原来那个大 FFN替换成很多个小的“专家 FFN”。每个 token 进来以后路由器会根据 token 的特征从所有专家里挑出 top-k 个最对口的只让这几个专家参与计算再把结果合并。以常见的设计为例如果一层里有 64 个专家每次只激活 2 个那么这一层实际参与计算的只有 1/32剩下的专家只是待命状态没有真正在算。这就是“稀疏激活”。打个现实的比方一个大型咨询公司有 770 个专家但接到一个项目时项目经理只会挑几个最对口的专家进场其他人该干嘛干嘛。公司总人力是 770 人但单个项目的人工成本只和进场人数挂钩。MoE 模型同理总参数量很大因为它要存下所有专家权重但推理时的计算开销由激活参数决定。Hy4 preview 没有公开太细的专家数量配置但从同类模型的惯例来看大概率也是类似结构总参数 770B实际激活参数可能只有几十 B。这也是为什么 770B 模型听起来吓人部署起来并没有想象中那么绝望。2.2 显存与算力的真实账本不过这里有个特别容易被忽略的点MoE 省的是计算量不是显存。模型在推理时不管激活哪些专家所有专家的权重都得完整加载到显存里。打个比方公司可以把大多数专家留在家里不用干活但你不能把他们辞退工资照发。我们来算一笔账。假设权重用 BF16 精度存储每个参数占 2 字节那么 770B 参数就需要 770 × 2 1540 GB 显存也就是大约 1.5 TB。这个数字对单卡来说完全是天文数字哪怕是 8 张 80GB 的 H100加起来也只有 640GBBF16 全量根本装不下。所以实际部署基本绕不开量化。如果把权重压到 4bit每个参数约 0.5 字节那么 770B 参数大约只需要 385GB 显存。这个量级用 8 张 80GB 的 A100/H100 可以跑或者用 4 张 100GB 以上显存的卡也有机会。如果再配合 CPU offload、KV cache 优化门槛还能继续降。算力方面因为 MoE 只计算激活参数单次推理的算力需求接近一个几十 B 量级的稠密模型而不是 770B 的稠密模型。这也是大家常说“MoE 是用显存换算力”的原因模型确实很大但跑起来不一定慢瓶颈更多在显存容量而不是计算芯片。2.3 不同预算下的三条部署路线根据我这两天的实测和一群同行的交流部署 Hy4 preview 这种规模大致有三条路线。第一条豪华路线。8 卡 H100 或 A100 80G直接上 BF16 或 FP8 精度效果最好部署最省心基本把权重拉下来然后用 vLLM 加载就能跑。适合预算充足的团队。第二条均衡路线。8 卡 A100 或者 4 卡大显存卡配合 4bit 量化AWQ 或 GPTQ显存占用大约 385GB 上下。推理质量和全精度相比会有轻微损失但整体可用性很高是目前性价比最平衡的选择。第三条入门路线。手上只有一两张消费级显卡比如 4090 或者 48G 的大显存卡那就得用 GGUF 量化加 llama.cpp 这类推理框架再配合 CPU offload。速度会慢一些但至少能跑起来。如果连这个条件都没有那就老老实实走 API 或者用 WorkBuddy 这类工具体验别硬撑。3. WorkBuddy 限时免费这两周窗口我建议你这样用3.1 WorkBuddy 到底是个什么工具WorkBuddy 是这次和 Hy4 preview 一起出现在公众视野里的工作台工具。你可以把它理解成一个基于大模型构建的智能体平台定位偏“干活”而不是单纯聊天。也就是说它能把你日常工作里重复性高、流程固定的事情真正接管过去。从我的实际体验来看WorkBuddy 的核心能力大概围几个方向代码辅助能做多文件仓库的问题定位和修改建议虽然不能完全替代程序员但查调用关系、找 bug 切入点很顺手文档处理能做长文本摘要、合同对比、格式转换数据分析能做表格字段解读、异常值查找还可以通过自定义 Skill 把你自己沉淀的工作流封装起来实现一键触发。值得留意的是WorkBuddy 并不是一个绑定 Hy4 preview 的封闭工具它支持对接多种模型后端既可以用官方云端 API也可以接本地部署的模型。这一点对很多团队来说非常实用先用云端跑通流程后面再把模型后端切到本地整个过程可以无缝过渡。3.2 申请接入的完整流程既然有免费窗口第一步肯定是注册。流程比较常规进入 WorkBuddy 官网或下载客户端邮箱注册然后在试用申请入口领取两周免费权益。这里提醒一句免费权益是按自然日计算还是按实际使用时长计算建议在申请页面看清楚别因为理解偏差浪费额度。注册完以后接下来的重点是配置模型后端。用官方云端 API 的话直接把 API Key 填进去就行。想接本地部署的模型需要在设置里添加自定义模型接口填上本地服务的 Base URL 和模型名称。因为本地推理框架暴露的通常是 OpenAI 兼容接口所以只要服务起来了WorkBuddy 这边配置好地址就能连上。接着就可以创建第一个任务了。WorkBuddy 的界面逻辑基本是“对话 任务 Skill”。你可以新建对话直接提需求也可以把流程封装成 Skill 反复调用。我个人建议先别急着写复杂流程找一件真实的工作任务完整跑一遍感受整个链路通不通、模型回答质量怎么样再逐步加复杂度。3.3 免费周期内值得重点尝试的三个场景两周时间说长不长但足够验证三件有价值的事。第一个场景是长文本处理。找一份你手头最头疼的合同、论文或者规范文档扔给 WorkBuddy 做摘要然后针对关键条款提问。这种任务对模型上下文理解能力要求很高正好可以检验 770B 这个量级的实际效果。我以前用 7B、13B 模型处理长文档经常出现前后矛盾、细节丢失换成大模型以后明显稳定很多。第二个场景是代码仓库问答。如果你的团队有存量代码库接入 WorkBuddy 以后可以用自然语言问它某个功能模块的调用关系、某个 bug 可能出在哪个文件、某个接口的入参格式是什么。这种能力对新人熟悉项目特别有帮助。但要注意需要提前让工具完成仓库索引第一次扫描比较耗时建议选一个非工作时间窗口做。第三个场景是自动化任务。比如每天早上生成项目进展摘要定期整理指定目录下的文件把邮件内容自动分类。这些任务一旦封装成 Skill免费期内验证通过后面就算要付费你心里也有底知道这笔预算花得值不值。4. Hy4 preview 本地部署实操从权重到可调用接口4.1 环境准备与工具选型接下来是最硬核的本地部署部分。先说结论部署 MoE 大模型优先考虑 vLLM 或 SGLang。这两个框架专门为大模型推理优化支持连续批处理和 PagedAttention吞吐量比直接用 Transformers 高一个量级。尤其你打算把模型做成服务接口给多个业务方调用时vLLM 基本是首选。环境方面操作系统建议 Ubuntu 22.04 或更新版本提前装好 NVIDIA 驱动和 CUDA。Python 环境推荐 3.10 以上用 conda 建独立环境避免和系统环境冲突。然后装 PyTorch、transformers、flash-attn 这些核心依赖。flash-attn 在部分显卡上编译很慢如果嫌麻烦可以直接装预编译版本别自己硬编译浪费时间。权重获取一般走两个渠道Hugging Face 和 ModelScope。国内网络环境下ModelScope 的下载速度通常更友好建议优先用 ModelScope。下载之前先看清楚仓库文件结构权重通常分多个分片用官方下载脚本一次性拉全不要手动一个个点非常容易漏。4.2 量化与加载方式选择权重拿到手以后下一步是决定精度。如果你的显存足够装下全量权重直接用 BF16 原始权重省去量化步骤效果也最好。比如你有 8 张 80GB 显存可以直接走这一步。如果显存不够就得量化。目前主流路线分两种一种是 AWQ/GPTQ适合配合 vLLM 这种服务化框架使用部署方便显存占用低是多数团队的首选。另一种是 GGUF搭配 llama.cpp 或者 Ollama 使用适合小显存机器也方便做 CPU/GPU 混合加载。我的建议是目标是搭服务接口就选 AWQ/GPTQ只想本机跑跑看效果就选 GGUF。这里有一个非常容易踩的坑量化版本和推理框架必须严格对应。比如用 vLLM 加载 GPTQ 模型启动命令里必须加 --quantization gptq用错了量化参数加载过程可能不报错但推理结果全是乱码。GGUF 同理要用 llama.cpp 的工具链不要把不同生态的工具混着用。4.3 vLLM 启动与关键参数说明假设你已经选好量化模型下面进入启动环节。以 vLLM 为例核心启动命令大概是这样的python -m vllm.entrypoints.openai.api_server \ --model /path/to/hy4-preview-awq \ --quantization awq \ --tensor-parallel-size 8 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --served-model-name hy4-preview逐个解释一下参数。--model 指向权重目录--quantization 指定量化类型--tensor-parallel-size 表示张量并行的显卡数量一般等于你实际可用的 GPU 数量。--gpu-memory-utilization 是显存利用率上限建议设 0.9 左右不要拉满留一点给 KV cache 和进程开销。--max-model-len 是最大上下文长度设太大会吃掉大量显存导致模型本体装不下设太小又影响长文档处理需要平衡。启动成功的标志是日志出现类似“Application startup complete”的信息服务默认监听 8000 端口。然后用一行 curl 验证接口curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: hy4-preview, messages: [{role: user, content: 用一句话介绍你自己}] }如果返回正常的 JSON说明服务已经通了。接下来你可以接 Open WebUI 这类前端工具或者直接在 WorkBuddy 里配置这个本地服务地址把后端切到本地。4.4 性能调优与效果验证模型跑起来以后还需要验证两件事性能和效果。性能方面先看吞吐量token/s和显存占用。用一段长文本反复请求观察单并发和并发情况下的差异。vLLM 的连续批处理可以让并发请求的吞吐量显著提升如果线上有多个用户同时访问这个优势特别明显。如果发现显存占用过高或出现 OOM优先检查 --max-model-len 是不是设太大或者把 --gpu-memory-utilization 调低一点。效果方面建议准备一组标准测试集包括代码题、逻辑题、中文知识问答、长文本摘要多问几轮。MoE 模型整体效果和同体量稠密模型相当但个别场景可能因为路由选择不稳定出现输出波动。遇到这种情况先调 temperature 和 top_p把温度降到 0.6 附近再观察。如果还不行检查是否真的加载了正确的量化版本这个原因特别隐蔽。5. 常见问题排查与避坑指南5.1 显存不足、加载慢、OOM 怎么办这是我在测试群里被问得最多的问题。先说判断思路加载慢一般不是硬件算力问题而是磁盘 IO 问题。权重文件动辄几百 GB如果磁盘是机械硬盘或者网络带宽偏低加载过程几个小时都很正常。解决办法是换 NVMe 固态盘并优先用国内镜像源下载。OOM 问题需要逐层排查。先看模型权重本身占了多少显存比如 4bit 量化大约 385GB如果你的显卡总显存凑不够这个数就得换更低精度或者缩小上下文窗口。其次看 KV cache 占了多少显存上下文越长KV cache 越大。最后看有没有其他程序占显存用 nvidia-smi 检查把不相关进程清掉。如果这些都不行只能妥协。方案一是 CPU offload把一部分层放到内存速度会慢但至少不 OOM。方案二是直接用 WorkBuddy 或云端 API别折磨自己的小显卡。我这两天的体会是硬件不够的时候学会选工具比硬扛更重要。5.2 输出质量不稳定、跑偏怎么办MoE 模型偶尔会出现输出“漂移”同一个问题多问几次答案差异很大。这种情况很多不是模型坏了而是采样参数和系统提示词的问题。建议的基准参数temperature 设在 0.6-0.8 之间top_p 设在 0.9 附近。做代码生成的话temperature 可以再低一点0.2 到 0.4 更稳。系统提示词要写清楚角色边界和输出格式比如“你是一个代码审查助手只输出问题和修改建议不要输出完整代码”这样能明显减少跑偏概率。如果你的场景对确定性要求极高比如金融、法务、医疗建议再加一层业务规则校验。大模型再强也是概率模型不可能保证每次输出都完全正确重要场景不要完全依赖模型裸跑。5.3 WorkBuddy 连不上本地模型怎么办WorkBuddy 接本地模型最常见的报错是连接失败或模型返回 404。第一步先确认本地服务是不是真的起来了用刚才的 curl 测试一下。如果 curl 正常但 WorkBuddy 连不上大概率是 Base URL 或者模型名称填错了。Base URL 要填到 /v1 这一层比如 http://127.0.0.1:8000/v1不要只填到 IP 和端口。模型名称必须和 --served-model-name 设置的一致。如果模型部署在远程服务器WorkBuddy 所在机器必须能访问到对应端口必要时检查防火墙和安全组配置。另外提醒一下免费周期是有限制的。如果到了免费窗口后期任务突然报错先检查是不是权益到期。按这个顺序排查基本几分钟就能定位。5.4 开源协议与数据合规提醒最后说一个容易被忽视但很重要的问题开源不等于可以随意使用。拿到 Hy4 preview 权重以后先看开源协议确认是否允许商用、是否对分发有额外要求、是否需要保留版权声明。不同模型的开源条款差别很大有的可以随便用有的必须在产品里明确标注模型来源。如果部署到企业环境还要考虑数据合规。本地部署的一个优势是数据不出内网但模型本身是在别的数据集上训练的输出内容如果包含来源不明的信息责任由使用者承担。涉及敏感业务的场景建议在系统提示词和调用链路上加一层审核过滤。这些落地细节提前规划好后面能省很多麻烦。这次 Hy4 preview 发布加上 WorkBuddy 免费两周我个人的真实体会是大模型的竞争重点正在从“谁的参数大”转向“谁能把大模型真正用起来”。770B 的 MoE 开源让不少团队第一次摸到了千亿级模型的边而 WorkBuddy 的限时免费又恰好补上了“部署完不知道拿来干什么”的短板。如果你手头还有免费额度别只拿来聊天找一件真实的工作任务完整跑一遍流程。等免费期结束你会很清楚自己要不要为它买单。