企业官网建设流程全解析

Hy4 preview 刚公布的时候，我盯着“770B MoE”这几个字愣了一会儿。上周还在帮朋友调一个26B的MoE模型，这周直接冒出来一个七百多亿总参数的大家伙，而且官方说权重开源，还顺手把WorkBuddy拿出来限时免费两周。这波动作放在大模型圈子里，冲击力不亚于一次小型地震。今天这篇东西，我想把它拆开来聊聊：770B MoE到底意味着什么，开源之后我们能拿它做什么，以及WorkBuddy这个号称“帮你把模型用起来”的工作流助手，在免费期内到底值不值得上手。

如果你最近一直在关注开源模型，应该能感觉到一个趋势：模型不再单纯比拼“总参数量大”，而是开始比“同样的显存下谁能跑得更快、更聪明”。Hy4 preview就是这种趋势下的典型产物。它对外挂出的招牌是770B总参数、MoE架构、开源权重，这三点单拎出来任意一个都够写好几篇分析，放到一起更值得好好聊。

1. 770B MoE 到底是一个什么水平

1.1 参数规模与激活参数的关系

很多人一看到770B就被唬住了，脑子里浮现的是“这得多少张卡才能跑起来”。实际上，MoE（Mixture 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模型总参数可以做得很大，但每次只激活其中一部分专家。

这张表能看出一个关键矛盾：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显卡仍然放不下，但可以通过CPU+GPU混合方式运行，速度会慢很多。

所以如果你想体验完整效果，最现实的路子是用云服务器租几张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_ENDPOINT=https://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_url="http://localhost:8000/v1", api_key="EMPTY", ) resp = client.chat.completions.create( model="hy4-preview-770B-MoE", messages=[ {"role": "system", "content": "你是一个严谨的编程助手，回答问题时先给思路，再给代码。"}, {"role": "user", "content": "用Python写一个能处理大文件的多线程下载器。"}, ], max_tokens=1024, temperature=0.3, ) print(resp.choices[0].message.content)

如果你的显存不足以跑vLLM，也可以用transformers配合accelerate，启用device_map="auto"和load_in_4bit=True来做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_4bit=True, bnb_4bit_compute_dtype="bfloat16", bnb_4bit_use_double_quant=True, bnb_4bit_quant_type="nf4", ) tokenizer = AutoTokenizer.from_pretrained("YourOrg/Hy4-preview-770B-MoE") model = AutoModelForCausalLM.from_pretrained( "YourOrg/Hy4-preview-770B-MoE", quantization_config=quant_config, device_map="auto", trust_remote_code=True, )

这段代码在消费级显卡上也能跑，前提是你的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 preview：

model_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分钟以内。大致步骤：

1. 创建一个新工作流，命名“周报生成”。
2. 添加“数据源”：选择一个文件夹或代码仓库，让WorkBuddy读取本周的提交记录、文档变更等。
3. 添加“处理步骤”：配置提示词模板，要求模型总结本周完成事项、风险点、下周计划。
4. 添加“输出”：生成Markdown文件并自动复制到剪贴板。

实际写Prompt时，我会先在WorkBuddy的“指令模板”里定义好输出格式，而不是只在聊天窗口里随便问。比如：

请根据以下信息生成本周工作总结： - 项目：A客户数据分析平台 - 本周提交：{{git_log}} - 本周文档：{{doc_changes}} 要求： 1. 按“进展-风险-计划”三段结构输出 2. 每段不超过100字 3. 使用中性书面语，不要使用“我们团队”这种模糊主语

把这类指令保存成Skill后，之后每次创建周报，直接选中这个Skill就行。WorkBuddy会自动提取上下文并调用模型，最终生成的内容质量相当稳定。

3.4 免费期内建议优先做的三件事

两周时间说长不长，说短不短，建议你不要只拿它聊聊天，而是集中做三件事：

第一，把自己日常最耗时、最机械的任务整理成一个Skill。哪怕只是一个自动给报销单分类的小脚本，也能让你感受工作流助手的真正价值。

第二，测试WorkBuddy与本地模型的稳定性。用同一个问题重复跑10次，观察响应时间波动和输出格式是否符合预期。很多问题会在连续调用后暴露，比如上下文被污染、工具调用失败等。

第三，评估免费期过后的付费意愿。如果两周后价格高于你的预期，或者在某些关键场景下并不能帮你省时间，那就果断弃用。别因为“限时免费”产生一种“不用白不用”的心理，结果浪费了大量学习成本。

4. 常见问题与避坑指南

4.1 部署与推理时的典型问题

结合我这两天的折腾经历，整理了几个高频问题，你大概率也会遇到。

还有一个很容易踩的坑：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快速出结果。这种组合拳打下来，效率比单用一个工具高不少。希望这篇内容能帮你少走一些弯路，也欢迎你把自己在部署和使用过程中踩到的坑分享出来。