Hy4 preview 刚公布的时候我盯着“770B MoE”这几个字愣了一会儿。上周还在帮朋友调一个26B的MoE模型这周直接冒出来一个七百多亿总参数的大家伙而且官方说权重开源还顺手把WorkBuddy拿出来限时免费两周。这波动作放在大模型圈子里冲击力不亚于一次小型地震。今天这篇东西我想把它拆开来聊聊770B MoE到底意味着什么开源之后我们能拿它做什么以及WorkBuddy这个号称“帮你把模型用起来”的工作流助手在免费期内到底值不值得上手。如果你最近一直在关注开源模型应该能感觉到一个趋势模型不再单纯比拼“总参数量大”而是开始比“同样的显存下谁能跑得更快、更聪明”。Hy4 preview就是这种趋势下的典型产物。它对外挂出的招牌是770B总参数、MoE架构、开源权重这三点单拎出来任意一个都够写好几篇分析放到一起更值得好好聊。1. 770B MoE 到底是一个什么水平1.1 参数规模与激活参数的关系很多人一看到770B就被唬住了脑子里浮现的是“这得多少张卡才能跑起来”。实际上MoEMixture of Experts混合专家架构要分开看两个数字总参数量和激活参数量。Hy4 preview的总参数量是770B也就是7700亿左右。但MoE的核心思路是“不把所有专家都叫起来干活”而是根据当前输入token的内容由路由器Router动态选择一部分专家来处理。所以你真正在推理时占用的算力接近的是“激活参数”而不是“总参数”。假设Hy4 preview的激活参数在26B到30B这个量级那么它的单token推理成本大概相当于一个20多B的Dense稠密模型而不是770B。我用一个比较生活化的类比帮你理解770B像是一家大型咨询公司员工名册上挂了几千人但某个具体项目并不会让所有人都到场只会根据项目类型派出几位相关领域的专家。你为这次咨询付的钱取决于到场的人数而不是公司总人数。MoE推理时的计算开销就像“到场人数×工作时长”存储开销则像“公司需要租用的办公场地”——后者依然取决于总人数。这也是为什么Hy4 preview敢叫“开源可部署”因为它虽然总参数逼近千亿级别但激活参数控制得比较小理论上在合理硬件环境下是可以真正跑起来的。1.2 MoE 与 Dense 模型的对比要真正理解Hy4 preview的定位最好把它和传统的Dense模型放在一起看。Dense模型的特点是“每个token都要激活全部参数”比如一个70B的Dense模型跑任何一句话都需要完整走过700亿参数的计算路径。而MoE模型总参数可以做得很大但每次只激活其中一部分专家。对比维度Dense 70BMoE 770B激活约26B总参数量70B770B每token激活参数量70B约26B单token推理算力开销高相对低模型文件体积约140GBFP16约1.5TBFP16知识容量上限相对有限更高部署难度单卡/双卡可试需要较大内存或多卡这张表能看出一个关键矛盾MoE确实在“算力效率”上有优势但“存储开销”一点没省。770B的FP16权重就算不加载优化器状态也要1.5TB左右的空间。所以“能跑”和“好跑”是两个概念。很多人以为MoE小显存也能轻松带起来结果下载完才发现光把模型从硬盘读进内存就要等半天。这一点在后面部署部分我会详细展开。1.3 开源的意义Hy4 preview最让我在意的不是它性能有多强而是“开源”这两个字。这几年开源模型的路线基本分两种一种是模型权重完全开放允许商用和二次训练另一种是只开放API代码和权重都不给你。Hy4 preview既然敢把权重放出来说明官方对它的定位是“社区共创”。你可以把它接到自己的项目里也可以基于它做微调甚至蒸馏出一个更适合自己业务的小模型。开源对于技术人的价值不只是“省钱”更重要的是“可控”。API服务随时可能调整价格、下线版本或者因为数据合规问题被迫修改内容策略。而本地部署的开源模型数据完全留在自己的服务器里对于处理内部文档、代码仓库、隐私数据等场景安全边际要高得多。当然开源也意味着很多工作要自己做。比如你要处理模型格式转换、量化、推理加速、并发调优这些在调用API时根本不需要你操心。所以如果你是一个只想快速验证业务想法的人可能直接等官方出托管API更省事但如果你想深入理解大模型的工作机制或者想针对垂直场景做定制Hy4 preview这种开源权重就是很好的教材。2. 本地部署 Hy4 preview 的环境准备与实操2.1 硬件需求评估先泼一盆冷水虽然激活参数只有26B左右但部署Hy4 preview的官方权重依然不是普通电脑能搞定的事。因为MoE推理必须把全部专家权重都加载到内存/显存中以便路由到对应专家时能快速读取。也就是说你需要为“总参数”770B准备存储空间而不是为“激活参数”26B准备。我做了一个粗略的资源估算便于你对照自己的机器情况FP16 原始权重约 1540GB按1B参数≈2GB估算需要10张以上80GB A/H系列显卡才能完整放下。4-bit 量化权重约 385GB按1B参数≈0.5GB估算需要5张80GB显卡或者8张48GB显卡或者一台内存超过512GB的服务器用CPU offload。2-bit 超低比特量化约 192GB单张80GB显卡仍然放不下但可以通过CPUGPU混合方式运行速度会慢很多。所以如果你想体验完整效果最现实的路子是用云服务器租几张A100/H100跑完就释放。如果是个人玩家建议先等社区出4-bit量化版本或者使用苹果M系列大内存机器跑CPU推理——速度别抱太高期望但至少能跑通。注意别只看“激活参数低”就以为消费级显卡能硬扛。MoE的稀疏计算只省算力不省内存带宽和存储。很多MoE模型用起来卡瓶颈往往不在计算而在权重加载和内存换入换出。2.2 获取模型与配置国内镜像获取权重首选Hugging Face但国内网络环境下载大文件经常断流我一般会用ModelScope或者配置国内镜像。以ModelScope为例搜索模型id找到对应仓库按官方README的说明下载。# 安装依赖 pip install -U transformers accelerate vllm bitsandbytes modelscope # 从ModelScope下载权重示例 modelscope download --model YourOrg/Hy4-preview-770B-MoE --local_dir ./hy4-preview-770B-MoE如果你还是习惯用Hugging Face也可以配置环境变量走镜像站export HF_ENDPOINThttps://hf-mirror.com huggingface-cli download YourOrg/Hy4-preview-770B-MoE --local-dir ./hy4-preview-770B-MoE下载完成后建议先核对一下目录中的config.json确认模型架构和上下文长度等参数避免和推理框架版本不匹配。2.3 使用 vLLM 启动推理服务如果你想高效并发推理vLLM是目前最省心的选择它自带PagedAttention显存利用率比原生transformers高不少。我这边用一个8卡环境为例python -m vllm.entrypoints.openai.api_server \ --model /data/hy4-preview-770B-MoE \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --dtype bfloat16 \ --trust-remote-code几个参数我的个人建议--tensor-parallel-size必须设为显卡数量。MoE模型的专家矩阵通常分布在多张卡上路由时需要跨卡通信所以这个值别随意改。--max-model-len越长越吃显存。如果你只有8卡H80可以先设16K再逐步往上调。否则容易在跑长文档时直接OOM。--gpu-memory-utilization设成0.9可以给KV Cache留一点余量但如果你机器上还要跑其他任务建议降到0.8以下。--trust-remote-code如果模型仓库中带自定义代码必须要这个参数。但这也意味着你在执行第三方代码建议先从官方仓库拉取或者人工审一遍代码再跑。启动之后可以看到一个OpenAI兼容的HTTP接口默认跑在http://localhost:8000/v1。接着用Python脚本验证服务是否正常from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) resp client.chat.completions.create( modelhy4-preview-770B-MoE, messages[ {role: system, content: 你是一个严谨的编程助手回答问题时先给思路再给代码。}, {role: user, content: 用Python写一个能处理大文件的多线程下载器。}, ], max_tokens1024, temperature0.3, ) print(resp.choices[0].message.content)如果你的显存不足以跑vLLM也可以用transformers配合accelerate启用device_mapauto和load_in_4bitTrue来做CPU/GPU混合推理。但速度会下降一个数量级只适合做功能验证。2.4 量化与低资源运行我看到很多人在讨论4-bit量化这里多说一句。MoE模型量化比Dense模型更敏感尤其是路由器Router部分的精度不能掉太多否则专家选择会出现偏差生成质量会明显下滑。建议优先用GPTQ或AWQ这类专为推理优化的量化方案而不是直接无脑上NF4。如果用bitsandbytes做4-bit加载可以这样from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig quant_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypebfloat16, bnb_4bit_use_double_quantTrue, bnb_4bit_quant_typenf4, ) tokenizer AutoTokenizer.from_pretrained(YourOrg/Hy4-preview-770B-MoE) model AutoModelForCausalLM.from_pretrained( YourOrg/Hy4-preview-770B-MoE, quantization_configquant_config, device_mapauto, trust_remote_codeTrue, )这段代码在消费级显卡上也能跑前提是你的CPU内存足够大——量化后仍有几百GB的权重需要驻留内存慢是慢但至少能出结果。2.5 跑通后的第一手体验我在8卡A100环境上跑通之后第一感受是“生成质量确实对得起总参数量带来的知识密度”。很多在中等尺寸模型上容易混淆的常识问题Hy4 preview能给出更精准的解释。尤其是复杂逻辑推理和代码生成方面多专家协同的优势比较明显。但有几个能感知到的缺点第一是首token延迟偏高因为路由计算和专家加载需要额外时间第二是长对话时显存波动较大可能是不同专家被频繁激活导致的第三是社区生态还没起来很多工具链还在适配中。如果你打算直接用transformers跑大概率会遇到兼容性小问题建议优先用vLLM。3. WorkBuddy 是什么以及限时免费期怎么玩3.1 WorkBuddy 的核心定位WorkBuddy这个名字起得直白Work Buddy工作搭子。它不是单纯聊天机器人而是把大模型能力封装成“可执行任务流”的桌面端助手。你可以把WorkBuddy理解成一个中间层上游接模型包括云API或本地部署的Hy4 preview下游接你的日常办公流程比如文档处理、数据分析、代码仓库管理、周报生成等。从社区反馈来看WorkBuddy最受欢迎的功能是“Skill”机制。类似给语言模型装技能包每个技能包由一系列指令、上下文模板和工具调用逻辑组成。比如一个“周报生成”Skill可以自动从你的Git提交记录、飞书/钉钉消息、项目文档中提取信息再调用模型生成初稿。这样一个Skill跑通后你每周五下午就不用逐条复制粘贴信息了。3.2 安装、注册与领取免费权益WorkBuddy提供了Windows、macOS和Linux安装包下载之后常规安装。这里想提醒几个容易被忽略的点安装时留意是否有“命令行工具”选项勾选后可以直接在终端调用workbuddy方便后续脚本化使用。首次启动需要用账号登录建议提前注册。免费两周的权益一般会自动下发但也有可能需要手动点击“领取试用权益”按钮。部分版本默认会开启自动更新如果你在内网环境建议关掉自动更新避免每次启动都要检查新版本。安装完成后进入设置界面把模型服务配置指向你本地部署的Hy4 previewmodel_provider: openai_compatible model_base_url: http://localhost:8000/v1 model_name: hy4-preview-770B-MoE api_key: EMPTY # 本地服务不校验key但框架要求非空如果你没有本地部署的条件也可以先用WorkBuddy内置的云端模型额度体验完整功能。但我的建议是既然Hy4 preview都开原了最好把模型也接本地这样延迟和隐私都可控。3.3 核心功能实操用 WorkBuddy 搭一个自动周报我用一个实际跑通的案例来演示WorkBuddy能做什么。假设你每周需要花一小时整理项目周报用WorkBuddy可以压缩到15分钟以内。大致步骤创建一个新工作流命名“周报生成”。添加“数据源”选择一个文件夹或代码仓库让WorkBuddy读取本周的提交记录、文档变更等。添加“处理步骤”配置提示词模板要求模型总结本周完成事项、风险点、下周计划。添加“输出”生成Markdown文件并自动复制到剪贴板。实际写Prompt时我会先在WorkBuddy的“指令模板”里定义好输出格式而不是只在聊天窗口里随便问。比如请根据以下信息生成本周工作总结 - 项目A客户数据分析平台 - 本周提交{{git_log}} - 本周文档{{doc_changes}} 要求 1. 按“进展-风险-计划”三段结构输出 2. 每段不超过100字 3. 使用中性书面语不要使用“我们团队”这种模糊主语把这类指令保存成Skill后之后每次创建周报直接选中这个Skill就行。WorkBuddy会自动提取上下文并调用模型最终生成的内容质量相当稳定。3.4 免费期内建议优先做的三件事两周时间说长不长说短不短建议你不要只拿它聊聊天而是集中做三件事第一把自己日常最耗时、最机械的任务整理成一个Skill。哪怕只是一个自动给报销单分类的小脚本也能让你感受工作流助手的真正价值。第二测试WorkBuddy与本地模型的稳定性。用同一个问题重复跑10次观察响应时间波动和输出格式是否符合预期。很多问题会在连续调用后暴露比如上下文被污染、工具调用失败等。第三评估免费期过后的付费意愿。如果两周后价格高于你的预期或者在某些关键场景下并不能帮你省时间那就果断弃用。别因为“限时免费”产生一种“不用白不用”的心理结果浪费了大量学习成本。4. 常见问题与避坑指南4.1 部署与推理时的典型问题结合我这两天的折腾经历整理了几个高频问题你大概率也会遇到。现象可能原因解决建议启动vLLM时报CUDA OOM总权重太大显存放不下降低--gpu-memory-utilization或改用多卡并行模型下载速度极慢国外源网络不稳定用ModelScope或配置HF镜像生成时每隔几个token卡顿MoE专家权重在CPU/GPU间换入换出减少max-model-len或使用更高带宽的存储相同Prompt两次生成质量差异大温度过高或路由器随机性影响调低temperature设置随机种子WorkBuddy连接本地模型超时vLLM服务没有启动成功先访问http://localhost:8000/v1/models确认服务在线还有一个很容易踩的坑MoE模型对max-model-len非常敏感。长上下文会触发更多专家同时被路由显存占用非线性上升。如果你在跑长文档时不断OOM别急着加卡先把上下文长度砍半试试。4.2 WorkBuddy 使用中的常见坑WorkBuddy的交互界面做得不错但隐藏坑也不少。最值得提醒的是“自动续费”。限时免费通常意味着需要你绑定支付方式才能激活试用权益一旦两周到期系统可能默认按照月度订阅扣款。如果你不想继续用务必在免费期内取消订阅或解绑支付方式。我习惯在日历里设置一个提前一天的提醒专门处理这类“试用到期”事件。另一个坑是“Skill执行权限”过宽。部分Skill为了读文件、跑命令会申请很高的系统权限。如果你让它访问整个用户目录它可以把所有资料都纳入上下文轻则泄漏隐私重则造成数据混乱。我在测试一个“一键整理桌面”的Skill时它就误把几个临时文件移动到了归档目录。建议你为每个Skill指定可访问的最小路径范围而不是给一个超大目录。4.3 关于MoE模型和WorkBuddy配合的避坑建议有些朋友喜欢用本地模型跑WorkBuddy觉得这样可以完全离线。但从我自己的使用经验看完全离线状态下WorkBuddy的“联网搜索”和“网页抓取”技能会失效一些依赖在线知识库的Skill无法正常工作。所以你要想清楚是追求“绝对隐私”还是“完整功能”。如果只是日常办公让WorkBuddy连接内网文档库就够了不必一定断网。另外本地模型和WorkBuddy的协议兼容性也要注意。WorkBuddy使用的是OpenAI兼容接口如果你的vLLM版本比较旧可能不支持某些参数比如logprobs、response_format。遇到报错时先看后端日志很多问题只是某个字段不兼容调整一下配置即可。你也可以在WorkBuddy的模型配置里把“输出格式”改成纯文本减少JSON结构化输出带来的解析失败。5. 关于开源模型和工作流工具结合的后续想法写到这里我把这次Hy4 preview发布和WorkBuddy免费体验放到一起复盘发现一个有意思的信号模型开源越来越“重”但配套工具反而越来越“轻”。以前我们拿到一个大模型要自己写API封装、写Prompt管理、写任务调度现在WorkBuddy这类工具试图把这些事情统一处理掉让使用者把精力集中在“定义流程”而不是“写代码”。这种变化对于那些不想深入底层、但需要模型落地到业务的人来说门槛降低了一大截。我不确定Hy4 preview最终在社区里的口碑会不会比肩那些已经很成熟的MoE开源模型但至少它提供了一个方向大模型竞争不再只看榜单分数还要看生态系统够不够完整。WorkBuddy限时免费很大程度上也是在为这个生态引流。如果你正好有业务痛点需要大模型来解决真心建议趁这两周把“模型部署 工作流设计”整条链路跑一遍。跑通之后你收获的不仅是一个辅助工具更是对“模型如何融入日常工作”这件事的判断力。我个人现在的工作方式是把本地部署的MoE模型作为“常驻知识引擎”同时用WorkBuddy把重复性的信息整理任务都接出去。遇到需要深度推理的问题我会临时调高模型的推理参数花更多token穷举可能性遇到只需要提取摘要的杂活就用低temperature快速出结果。这种组合拳打下来效率比单用一个工具高不少。希望这篇内容能帮你少走一些弯路也欢迎你把自己在部署和使用过程中踩到的坑分享出来。