中/EN
实战 SOP
实战 SOP

腾讯 770B 旗舰自部署 SOP：8 张 H100 连 FP8 权重都放不下，官方起步线是 16 张 B200

自部署腾讯 770B 旗舰 Hy4 preview 的完整 SOP。先泼冷水算清显存账：FP8 权重约 770GB，官方 vLLM recipe 明确基线是 16×B200 或 8×B300（weights+KV cache），8×H100（640GB）连 FP8 权重都放不下--激活 49B 省的是算力，770B 权重必须整份驻留显存。两条部署路线命令逐字出自官方 README：vLLM 预构建镜像（MTP 投机解码 num_speculative_tokens=3、FLASHMLA_SPARSE 注意力后端、hy_v4 工具/推理解析器）与 SGLang 预构建镜像（NEXTN 投机、tp-size 8）。含 OpenAI 兼容调用（temperature 0.9/top_p 1.0，no_think 关深度思考省输出 token）、AngelSlim 自量化、finetune 管线、7 条踩坑与 10 项上线 checklist；不自部署的可走腾讯云 TokenHub/OpenRouter 或 WorkBuddy/CodeBuddy 两周免费。

发布于 2026年8月29日12 分钟阅读
<!-- hy4-preview-self-hosting-sop | sop | 腾讯 770B 旗舰自部署 SOP：8 张 H100 连 FP8 权重都放不下，官方起步线是 16 张 B200 -->

2026-08-28，腾讯混元发布并开源新一代旗舰 Hy4 preview：770B 总参、49B 激活的 MoE，1M 上下文，Apache 2.0 协议，BF16 与 FP8 双版本权重四渠道开放（发布背景与架构拆解见本站 Hy4 preview 开源热点）。

这篇 SOP 回答一个具体问题：想自己跑 Hy4 preview，需要什么、怎么跑通、哪些坑会烧掉一个下午。全文部署命令与参数均取自官方 GitHub README 与 vLLM/SGLang 官方 recipe（2026-08-29 核验快照），显存数字为工程估算口径、非官方承诺。

先说三条边界：第一，这不是一篇「人人都能跑」的教程——770B 是当前开源权重里的顶配档，硬件门槛先看第零步，不达标请直接走 API；第二，官方 README 的命令模板写的是 --tensor-parallel-size 8，但那对应的是 B300 级显存的单机，不是 8 张 80GB 卡，这个误会太常见、单列成踩坑第 1 条；第三，本文非官方合作推广，许可证与权重链接以官方仓库为准。

第零步：先算显存账，再谈部署

自部署的第一道门不是技术，是算术。MoE 的铁律：激活 49B 省的是单 token 计算量，不省显存——770B 全部权重必须驻留显存。按每参数字节数粗算（工程估算口径，未含 KV cache 与运行时开销）：

精度每参数字节权重显存（估算）官方 recipe 硬件基线
BF162约 1.5 TB官方 recipe 给的长上下文/全精度参考档
FP81约 770 GB16×B200 或 8×B300（带 MTP）起步

vLLM 官方 recipe 页对 Hy4 preview 的原话是：「16×B200 or 8×B300 minimum for weights + KV cache」。注意这是权重加 KV cache 的最低线，不是舒适线——1M 上下文的 KV cache 在高并发下同样是大头，recipe 还明确标注：拉满 1M 上下文需要 8×B300 节点或 4 个 GB300 NVL4 托盘（3 个托盘装得下但 TP12 无效，64 个注意力头不能被 12 整除）。

翻译成采购语言：8×H100（640GB）连 FP8 权重（约 770GB）都放不下。如果你的机房是 80GB 卡，结论不是「调调参数」，是「此路不通」——直接走腾讯云 TokenHub 或 OpenRouter 的 API（OpenRouter 快照价约 $0.834/M 输入、$2.501/M 输出，2026-08-28 口径），或等量化社区版本。数据不能出门的合规场景，考虑租用 B200/B300 级算力而不是硬凑现有集群。

自部署只适合两类人：数据不出门的合规硬约束、批量推理量大到按量账单已超过集群摊销。两个都不沾，这篇后面的一半内容可以不用读。

摊销阈值怎么算，给个方法（估算口径）：自部署月成本 =（硬件月租或折旧 + 电力运维）÷ 月处理 token 量，得到的「每百万 token 综合成本」与 API 牌价对比。以 OpenRouter 快照价（$0.834/M 输入、$2.501/M 输出，2026-08-28）为参照：设你的月用量为输入 I、输出 O（单位 M token），API 月账单 ≈ 0.834×I + 2.501×O；把你的 B200/B300 级节点报价代入左边的自部署月成本，两条曲线的交点就是临界用量。经验上，只有持续吃满整节点的大批量任务（每周 7 天高利用率）才够得着临界点，工作日白天跑跑停停的负载，API 永远是赢家。你没有牌价的报价单，就把公式搭在表格里等报价——这个动作本身半小时，比拍脑袋买卡便宜得多。

部署前的三件准备事

命令行只是最后一步，前面三件事没备齐，docker run 的结局就是反复退出：

  1. 权重与磁盘：FP8 版数百 GB 量级，预留至少 1.5 倍空间给下载缓存与解压（Hugging Face 缓存机制会产生临时副本）。四渠道里国内环境优先 ModelScope 或 CNB；走 Hugging Face 就配好 HF_ENDPOINT 镜像或用 hf_transfer 加速。下载脚本先跑通 10GB 再放全量——770B 量级的下载，中途断一次的代价是按小时计的。
  2. 容器与驱动：官方两条路线都是 docker run --gpus all，前置要求 NVIDIA 驱动 + nvidia-container-toolkit 就绪，docker run --rm --gpus all nvidia/cuda nvidia-smi 先验证 GPU 对容器可见。多机部署还要确认节点间网络与共享存储，权重文件别每台机各下一份。
  3. 服务验收：容器起来不等于模型就绪——770B 权重加载本身要以分钟计。用 curl http://127.0.0.1:8000/v1/models 确认服务注册完成、模型名是 hy4-preview，再发第一条对话。健康检查通过前别接上层业务，这是所有「起容器成功、调用 502」案例的共同根因。

第一条路线：vLLM 官方镜像

官方 README 给的 vLLM 命令模板（逐字引用，2026-08-29 核验）：

bash
docker run --gpus all \
  -p 8000:8000 \
  --ipc=host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:hy4-preview tencent/Hy4-preview-FP8 \
    --tensor-parallel-size 8 \
    --speculative-config '{"num_speculative_tokens":3,"method":"mtp"}' \
    --attention-backend FLASHMLA_SPARSE \
    --tool-call-parser hy_v4 \
    --reasoning-parser hy_v4 \
    --enable-auto-tool-choice \
    --port 8000 \
    --served-model-name hy4-preview

五个参数各有讲究，动之前先看懂：

  1. vllm/vllm-openai:hy4-preview 官方预构建镜像：别用通用 latest 镜像自己装依赖。Gated DSA、IndexCache、MTP、hy_v4 解析器都是新东西，版本不齐就是白屏和报错。官方 recipe 标注要求 vLLM 0.29.0+。
  2. --speculative-config 开 MTP 投机解码：Hy4 内置 1 层原生 MTP（10B 总参/0.7B 激活），num_speculative_tokens: 3 一次投机 3 个 token。这是 770B 大模型能跑出可用吞吐的关键一环，别为了省事删掉。
  3. --attention-backend FLASHMLA_SPARSE：对应 Gated DSA（DeepSeek Sparse Attention 的门控变体）+ IndexCache 跨层稀疏索引复用的注意力架构，专用后端才有性能可言。
  4. hy_v4 双解析器：tool-call 与 reasoning 都要用 hy_v4，配 --enable-auto-tool-choice 才能正常出工具调用与思考内容。换模型不换解析器，是最常见的「模型能跑但输出是乱码」来源。
  5. --tensor-parallel-size 8 的真实含义：TP 必须能整除 64 个注意力头（8、16 都行，12 不行）。官方模板默认 FP8 权重 8 卡起步，前提是单卡显存到 B300 级（约 288GB）；16×B200 也行。80GB 卡集群请直接看踩坑第 1 条。

第二条路线：SGLang 官方镜像

偏好 SGLang 的团队走这条，官方镜像多架构（x86 与 Arm）：

bash
docker pull lmsysorg/sglang:hy4-preview

docker run --gpus all --ipc=host -p 8000:8000 lmsysorg/sglang:hy4-preview \
  python3 -m sglang.launch_server \
    --model tencent/Hy4-preview-FP8 \
    --tp-size 8 \
    --reasoning-parser auto \
    --tool-call-parser auto \
    --speculative-algorithm NEXTN \
    --speculative-num-steps 3 \
    --speculative-eagle-topk 1 \
    --speculative-num-draft-tokens 4 \
    --port 8000 \
    --served-model-name hy4-preview

与 vLLM 版逐项对应：NEXTN 就是 MTP 投机解码（next-n），speculative-num-steps 3 对齐 vLLM 的 num_speculative_tokens: 3。解析器参数两边写法不同（SGLang 用 auto，vLLM 用 hy_v4），照抄各自模板即可，别交叉混配。两条路线跑出来的都是标准 OpenAI 兼容服务，上层代码完全一致——先按团队现有推理栈选，不必纠结。

跑通第一条调用

服务起在 127.0.0.1:8000 后，官方 README 的最小示例（逐字引用）：

python
from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="EMPTY")

response = client.chat.completions.create(
    model="hy4-preview",
    messages=[
        {"role": "user", "content": "Hello! Can you briefly introduce yourself?"},
    ],
    temperature=0.9,
    top_p=1.0,
)
print(response.choices[0].message.content)

两个必须知道的推理细节：

  • 推荐参数 temperature=0.9、top_p=1.0。与主流模型默认拉到 0.7/0.9 的习惯不同，官方明确推荐这对组合，自行改动前先按官方参数跑通基线。
  • 思考模式默认 "high"（深度思考链），适合数学、编程、推理类复杂任务。想要直接回答（省思考 token、降延迟），传 extra_body={"chat_template_kwargs": {"reasoning_effort": "no_think"}}。注意自部署没有「思考 token 半价」——但思考时间占用的是你自己的卡，高并发场景关思考就是实打实的吞吐。

1M 窗口的使用纪律（工程口径）：窗口开多大，KV cache 就占多少显存预算。官方 recipe 给的 16×B200/8×B300 是「权重 + KV cache」的最低线，意味着拉满 1M 上下文后并发余量已经很小。实际服务的正确姿势是按业务真实分布定 --max-model-len：大多数对话与代码场景几千到几万 token 就够，为「万一」开的 1M 窗口是在用并发数换心理安全感。真有超长文档需求，先做检索与分段，再让模型读——这也是往期 大模型 API 成本优化 SOP 里同一条纪律在自部署侧的翻版。

进阶：量化与微调

  • 量化：官方提供 AngelSlim 压缩工具链，覆盖常见量化算法、低比特量化与投机采样。想把自己压出更小的部署档，从官方工具链起步，别手搓校准。
  • 微调：仓库内置完整 finetune 管线（finetune/README.md）。770B 全参微调不是个人预算的事，官方管线支持的程度以仓库文档为准，动工前先读。
  • 权重下载：BF16 与 FP8 双版本在 Hugging Face、ModelScope、GitCode、CNB 四渠道都有。国内环境建议 ModelScope 或 CNB，770B 权重的下载量级，网络路径差一档就是差一天。

七个典型踩坑

  • 拿 8×H100 硬上——官方 recipe 写得明白：权重 + KV cache 最低 16×B200 或 8×B300。8×80GB（640GB）连 770GB 的 FP8 权重都装不下，这不是调 --gpu-memory-utilization 能救的。README 命令里的 TP=8 默认你有 B300 级单卡显存。
  • TP 切了不能整除头数的数——64 个注意力头，TP 只能取 64 的因子里合理的几个（8、16）。recipe 特别点名 TP12 无效：3 个 GB300 托盘装得下权重，但 TP12 直接起不来。
  • 删掉投机解码配置「省资源」——MTP 层是架构内置的，speculative-config/NEXTN 删掉后吞吐掉一截，却省不了几 GB 显存。这笔账是负收益。
  • 解析器不匹配——vLLM 用 hy_v4、SGLang 用 auto，各按各的模板抄；工具调用输出格式错乱，八成是解析器没配对。
  • 用 latest 通用镜像——Gated DSA/FLASHMLA_SPARSE/MTP 支持要官方专用镜像（vLLM 0.29.0+），通用镜像大概率起不来或性能打折。
  • BF16 版当默认选——BF16 约 1.5TB 权重是 FP8 的两倍，除非有明确的全精度需求（如量化基准对照），部署默认选 FP8 官方版，省下的显存全给 KV cache 和并发。
  • 不做下载规划——770B 级权重单版本数百 GB 起，双版本全下再翻倍。先确认渠道（国内走 ModelScope/CNB）、磁盘与带宽，再动手。

上线前 checklist

  1. 显存对表：FP8 约 770GB 起步，机器是 16×B200 / 8×B300 级，80GB 卡集群直接放弃
  2. 用官方预构建镜像（vllm/vllm-openai:hy4-preview 或 lmsysorg/sglang:hy4-preview），vLLM 0.29.0+
  3. MTP 投机解码配置保留（vLLM speculative-config / SGLang NEXTN）
  4. 注意力后端 FLASHMLA_SPARSE 生效
  5. 解析器按栈配置：vLLM hy_v4，SGLang auto
  6. --served-model-name hy4-preview 与客户端 model 字段一致
  7. 推荐参数落地：temperature=0.9、top_p=1.0
  8. 思考模式策略明确：复杂任务默认 high，高并发直答场景用 no_think
  9. TP 值能整除 64 头，多机方案先查 recipe 的 TP 有效性标注
  10. 权重渠道与磁盘带宽提前规划，FP8 版本优先

一句话收尾：Hy4 preview 把开源旗舰的顶配档抬到了 770B——它对自部署者的第一句话不是命令行，是算术：先确认你的集群装得下 770GB，再谈 vLLM 还是 SGLang；装不下，API 就是你的自部署。

常见问题

Q1：8 张 H100 真的跑不了 Hy4 preview 吗？我看 README 命令就是 TP=8。 A1：跑不了。README 命令模板的 --tensor-parallel-size 8 对应的是官方 recipe 标注的硬件基线——FP8 版「16×B200 or 8×B300 minimum for weights + KV cache」。8×H100 合计 640GB，低于 FP8 权重约 770GB 的估算下限，模型加载阶段就会 OOM，调小 batch 或 gpu-memory-utilization 都救不了。80GB 卡集群请走 API 或等社区量化版。

Q2：BF16 和 FP8 两个版本怎么选？ A2：部署默认选 FP8 官方版：权重约 770GB，是 BF16（约 1.5TB）的一半，省下的显存全部转化为 KV cache 与并发能力。BF16 适合两类场景：做量化基准对照、对精度有硬要求的评测复现。两者都在 Hugging Face、ModelScope、GitCode、CNB 四渠道开放。

Q3：no_think 关思考会掉智能吗？省多少？ A3：官方定位是 reasoning_effort: "no_think" 用于直接回答场景，跳过深度思考链。数学、编程、复杂推理类任务建议保留默认 high；简单问答、高并发直答场景关掉可显著降延迟、释放吞吐。自部署下省的是自己显卡的时间——高并发服务里这笔吞吐收益比 API 场景更直接。建议两类参数各跑一轮自己的真实任务再定。

Q4：vLLM 和 SGLang 选哪个？ A4：官方两条路线都是一等公民，部署出来的都是 OpenAI 兼容服务，上层代码零差异。选型看团队现有运维栈：已在用 vLLM 就用 vllm/vllm-openai:hy4-preview 镜像，在用 SGLang 就用 lmsysorg/sglang:hy4-preview（多架构，x86/Arm）。解析器写法两边不同（hy_v4 vs auto），照各自模板抄，不要混配。

Q5：想微调 Hy4 preview，个人开发者现实吗？ A5：仓库提供完整 finetune 管线，但 770B 体量的全参微调是多节点集群级工程，不在个人预算内。个人现实路径：用 API 验证能力上限，轻量需求考虑基于官方 AngelSlim 工具链的量化方案压缩部署档，或关注社区后续蒸馏/小尺寸版本。具体微调支持程度以仓库 finetune/README.md 为准。

参考来源

本文部署命令与硬件基线为 2026-08-29 官方文档快照，非官方合作推广；显存数字为工程估算口径，实际以官方 recipe 与你的实测为准。

本文由 AI 辅助生成，经人工审核编辑。最后更新：2026-08-29

常见问题

8 张 H100 真的跑不了 Hy4 preview 吗？我看 README 命令就是 TP=8。
跑不了。README 命令模板的 `--tensor-parallel-size 8` 对应的是官方 recipe 标注的硬件基线——FP8 版「16×B200 or 8×B300 minimum for weights + KV cache」。8×H100 合计 640GB，低于 FP8 权重约 770GB 的估算下限，模型加载阶段就会 OOM，调小 batch 或 `gpu-memory-utilization` 都救不了。80GB 卡集群请走 API 或等社区量化版。
BF16 和 FP8 两个版本怎么选？
部署默认选 FP8 官方版：权重约 770GB，是 BF16（约 1.5TB）的一半，省下的显存全部转化为 KV cache 与并发能力。BF16 适合两类场景：做量化基准对照、对精度有硬要求的评测复现。两者都在 Hugging Face、ModelScope、GitCode、CNB 四渠道开放。
`no_think` 关思考会掉智能吗？省多少？
官方定位是 `reasoning_effort: "no_think"` 用于直接回答场景，跳过深度思考链。数学、编程、复杂推理类任务建议保留默认 `high`；简单问答、高并发直答场景关掉可显著降延迟、释放吞吐。自部署下省的是自己显卡的时间——高并发服务里这笔吞吐收益比 API 场景更直接。建议两类参数各跑一轮自己的真实任务再定。
vLLM 和 SGLang 选哪个？
官方两条路线都是一等公民，部署出来的都是 OpenAI 兼容服务，上层代码零差异。选型看团队现有运维栈：已在用 vLLM 就用 `vllm/vllm-openai:hy4-preview` 镜像，在用 SGLang 就用 `lmsysorg/sglang:hy4-preview`（多架构，x86/Arm）。解析器写法两边不同（`hy_v4` vs `auto`），照各自模板抄，不要混配。
想微调 Hy4 preview，个人开发者现实吗？
仓库提供完整 finetune 管线，但 770B 体量的全参微调是多节点集群级工程，不在个人预算内。个人现实路径：用 API 验证能力上限，轻量需求考虑基于官方 AngelSlim 工具链的量化方案压缩部署档，或关注社区后续蒸馏/小尺寸版本。具体微调支持程度以仓库 `finetune/README.md` 为准。

相关文章

实战 SOP

Qwen3.8-Flash-Next 全栈部署 SOP：125B 主模型 + 51B N-gram 嵌入，从托管 API 到 Apple Silicon 的三层路线

把 Qwen3.8-Flash-Next 从「能跑起来」推到「跑得省」的三层路线。托管层零运维：QwenCloud API 兼容 OpenAI 与 Anthropic 规范，QwenWork 的 Standard 模式由它驱动。服务化自部署给四条逐字出自官方 README 的命令：transformers serve（--continuous-batching）、SGLang（--tp-size 4 --context-length 262144 --reasoning-parser qwen3 --tool-call-parser qwen3_coder）、vLLM（--tensor-parallel-size 4 --max-model-len 262144 --enable-auto-tool-choice）与 TokenSpeed，四者都在 localhost:8000/v1 提供 OpenAI 兼容 API。本地与端侧另有 llama.cpp 的 GGUF、Apple Silicon 的 mlx-vlm 与 Unsloth。工程上最值得记的一点是额外那 51B N-gram embeddings 可以卸载到主机内存，靠异步预取与模型计算重叠——README 未给官方显存基线，故不猜硬件门槛，标注以官方 recipe 与实测为准。含 YaRN 外推 1M 的取舍、微调框架选择（Unsloth / Swift / Llama-Factory）与 7 条踩坑，其中第一条就是：GitHub 仓库无 LICENSE 文件，商用前先去模型页核对协议。

2026年8月30日12 分钟阅读
实战 SOP

自建 OpenMAIC 课堂 SOP：从取码到接 Agent 工作台

从零把 OpenMAIC 跑起来的完整 SOP：①零部署路线（open.maic.chat 取访问码即用）；②本地标准部署（pnpm >= 10，clone → pnpm install → .env → pnpm dev）；③生产化（pnpm build && pnpm start、Vercel 一键、docker compose up --build）；④进阶（Postgres 持久化 profile、ACCESS_CODE 访问码、MP4 导出 profile、Lemonade/FunASR 本地化）；⑤接进 agent 工作台（clawhub install openmaic 或导入 skills/openmaic/，从飞书/Slack 发消息生成课堂）。含 6 条踩坑与 10 项上线自检清单，全部命令逐字取自官方 README。

2026年9月8日11 分钟阅读
实战 SOP

用 GPT-6 Astra 搭建长任务智能体工作流

基于 GPT-6 Astra 真实能力（105 万上下文、12.8 万输出、对齐越权 0%）搭建长任务智能体的实战 SOP：先完成三项准备（OpenAI Python SDK 1.50+、OPENAI_API_KEY 环境变量、API 白名单），再按长上下文规划→定义工具（函数调用 + 计算机使用）→异步调用模式→中途纠偏→验收与成本控制的顺序落地。重点：开局只放任务目标、验收标准、工具清单与关键背景让模型先出计划；工具须写清 name/description/parameters；异步用流式事件 + 后台队列 + 任务 id 轮询；纠偏直接注入新指令无需重启；验收用独立脚本做断言、默认收小 max_output_tokens 并设日花费上限。

2026年9月4日11 分钟阅读