Step 5 Preview 本地跑起来：从权重下载到部署的一站式实操

Step 5 Preview 本地跑起来：从权重下载到部署的一站式实操

【免费下载链接】Step-5-PreviewStep 5 Preview 是阶跃星辰面向智能体工作打造的旗舰模型。该模型在软件工程和专业知识工作领域均展现出前沿级性能，尤其在金融领域表现突出。 Step 5 Preview 是一个稀疏混合专家（MoE）模型，总参数量为 600B，激活参数量为 27B。它支持高达 100 万 token 的上下文长度，并可接收文本、图像和视频输入，能够在复杂任务中实现持续推理与工具调用。项目地址: https://ai.gitcode.com/StepFun/Step-5-Preview

9 月 20 日，阶跃星辰发布了面向 Agentic 工作流的旗舰基座模型 Step 5 Preview：600B 总参数、27B 激活参数的稀疏 MoE，支持最长 1M token 上下文，原生接收文本、图像与视频输入。发布后它一路冲上 OpenRouter 全球 Trending 榜，配合腾讯 WorkBuddy 10 月 12 日至 25 日的限时免费，社区实测集中在 3D 游戏开发、金融分析、网页生成等长程工具调用场景。10 月 15 日，权重正式开源——FP8 与 BF16 两套 checkpoint 分别上线 Hugging Face 与 ModelScope（stepfun-ai/Step-5-Preview与stepfun-ai/Step-5-Preview-BF16）。

API 调用零门槛，但"本地跑起来"是另一回事。600B 的权重怎么下、几张卡才装得下、FP8 量化有什么坑、1M 上下文是不是虚标，都是实操里绕不开的问题。本文全部以仓库源码与官方文档为据，从磁盘预算一路讲到首跑验证，给出可直接复制的命令。

一、先把预算算清楚：下载 600B 权重到底要多少空间

先看磁盘。用 Git LFS 拉取stepfun-ai/Step-5-Preview仓库，权重文件清单可以从 model.safetensors.index.json 里核对：索引里metadata.total_size声明为644,100,979,280 字节（约 599.9 GiB / 644 GB），对应 24 个主分片（model-00001.safetensors至model-00024.safetensors）、MTP 分片与视觉分片共 2704 个张量。按 LFS 指针中的实际 size 逐文件求和，整套下载内容约为：

两个实操提醒：一是磁盘要预留1TB 以上可用空间，因为除了权重本尊，推理框架还要写 KV cache、激活、分片转换产物；二是vit.safetensors是独立侧车文件，fp8_vit_sidecar_ready.json 中标记vit_in_model_index: false，即它不在权重索引内，校验下载完整性时容易漏掉，建议拉完后核对这 27 个 LFS 文件一个不少。如果走鉴权仓库，容器内先执行hf auth login再下载。

显存预算则按部署形态分档。README.md 给出的官方部署配置矩阵如下：

结论先说：FP8 是本地部署的甜点档，最低 4 张 B300 即可起服务；BF16 则基本是"双节点 16 卡"起步——仓库中 inference/README.md 给出了实测依据：92 层 BF16 模型在 TP/EP=8 下仅参数就需约 144.41 GiB/卡，直接超出 H200 的 140.40 GiB 上限；拉到 TP/EP=16 后，实测加载参数约 74.93 GiB/卡，batch=1、943 token 图文请求下 PyTorch 显存分配峰值 76.37 GiB/卡。这个峰值还没算 NCCL、CUDA context、KV cache 与长上下文的余量，所以 1M 上下文在 BF16 双节点上依然要"精打细算"。

二、稀疏 MoE 的量化结构与部署注意点

Step 5 Preview 的量化不是"一把梭"，而是有明确边界的混合精度，直接看 config.json 里的quantization_config：

• quant_method: "fp8"，fmt: "e4m3"，activation_scheme: "dynamic"，weight_block_size: [128, 128]——即分块缩放（block-scaled）FP8 E4M3权重 + 动态激活量化，而不是 per-tensor 的朴素 FP8；
• modules_to_not_convert列出了全部排除项：第 88、89、90 三层 MoE 的专家权重（w13_weight/w2_weight）以及视觉编码器全部 47 层保持BF16。这也解释了仓库里为什么视觉权重单独以 BF16 侧车文件存在——inference/README.zh.md 明确"排除量化的专家层和视觉编码器保留 BF16 权重"。

MoE 侧的参数同样写死在配置里：moe_num_experts: 352、moe_top_k: 8，另有与专家并列的共享专家（share_expert_dim: 1536）。92 层中第 3~90 层（共 88 层）为 MoE 层。激活 27B 的口径即由此而来：每 token 只路由 8/352 的专家加共享部分，这也是 FP8 权重能压到 600 GB 左右、而单卡显存压力集中在专家并行切分的原因。

部署时真正容易踩的坑有四个：

1. --dtype bfloat16不会"反量化"。README 特意强调：对 FP8 checkpoint 设置--dtype bfloat16不会把量化权重转回 BF16，想要 BF16 必须挂载独立的 BF16 checkpoint 并把MODEL指向它。
2. MegaMoE 只在 B300（Blackwell）上启用。vLLM 的 TEP4/DEP4 命令带--moe-backend deep_gemm_mega_moe，该后端要求专家并行；在 H200（Hopper）上必须删掉这个参数、回落到默认 MoE 后端。
3. SGLang 的 backend 选择与 GPU 代际绑定。官方镜像lmsysorg/sglang:step-5-preview下，B300 用--moe-runner-backend flashinfer_trtllm --moe-a2a-backend megamoe --attention-backend fa4；H200 换成--moe-runner-backend triton --attention-backend fa3。两者都配--page-size 64 --kv-cache-dtype bfloat16 --mem-fraction-static 0.9，并用--swa-full-tokens-ratio 0.03控制混合注意力中全量 KV 的保留比例（后文讲 1M 上下文时还会用到它）。
4. 投机解码走 MTP，但仅服务侧框架支持。vLLM 示例统一带--spec-method mtp --spec-tokens 3；SGLang 侧对应--speculative-algorithm EAGLE --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4 --enable-multi-layer-eagle。这与配置中num_nextn_predict_layers: 3的 3 层 MTP 权重（即model-mtp3-*.safetensors那两份分片）对应。而仓库自带的 Transformers 独立推理路径不加载 MTP 层、没有投机解码，且只支持贪心生成——用它做基准对比时要心里有数。

推理内核方面，inference/kernel.py（约 3300 行 Triton/CUDA）把三件性能关键的事做成了自研算子：DSA 稀疏注意力（先由 indexer 选区再做注意力）、分块缩放 FP8 专家 GEMM（fp8_gemm/linear_fp8_or_bf16）、以及融合的 QKNorm/RoPE。长输出稳定性约定也写进了文档：TP 部分结果按 rank 顺序以 FP32 累加、EOS 后逐行整理 cache——inference/README.md 明确这不承诺不同批大小/硬件间的逐位一致。

三、不想上 vLLM/SGLang？用仓库自带的 Transformers 路径

inference/ 目录是一套可独立运行的最小推理路径，共 8400 行 Python（model.py 2500 行、generate.py 976 行、kernel.py 3320 行）。典型流程是"一次性转换 → 多进程生成"：

cd inference python3 -m venv --system-site-packages .venv source .venv/bin/activate python -m pip install -r requirements.txt # torch>=2.10,<2.14 等版本范围 export STEP5_FP8_CHECKPOINT="<FP8_CHECKPOINT_DIRECTORY>" export STEP5_FP8_OUT="<FP8_SHARD_OUTPUT_DIRECTORY>" # 先只读文件头核对 key 与形状，再真正分片 python3 convert.py --checkpoint "$STEP5_FP8_CHECKPOINT" \ --tp-size 8 --ep-size 8 --check-only python3 convert.py --checkpoint "$STEP5_FP8_CHECKPOINT" \ --out-dir "$STEP5_FP8_OUT" --tp-size 8 --ep-size 8 torchrun --standalone --nproc-per-node=8 generate.py \ --tp-dir "$STEP5_FP8_OUT/tp8" --ep-size 8 \ --prompt "请介绍一下张量并行。" --max-new-tokens 128

几个必须注意的工程细节（均出自 inference/convert.py 与 inference/README.zh.md）：

• 转换产物是tpN/model-r{rank}.safetensors+ 配套config-r{rank}.json，分片配置与权重必须同批生成配套使用；generate.py从分片配置读 TP 度数并校验WORLD_SIZE，刻意不提供独立的--tp-size开关；
• 路由专家走专家并行（EP）而非张量切分：TP=EP=8 时每 rank 放置 44/352 个完整专家，TP=EP=16 时 22 个，TP 与 EP 共用进程组；
• --ep-size当前必须等于 TP/进程总数，TP=4, EP=2这类独立进程组组合未实现；
• BF16 双节点启动不用--standalone，改用--nnodes=2 --master-addr的 rendezvous 方式，两节点分别执行同一命令、各设NODE_RANK=0/1；
• 已验证运行环境为 PyTorch 2.13.0+cu129、Triton 3.7.1、Transformers 5.15.0、Safetensors 0.8.0。另有一个隐藏坑：Transformers 5.15 的自动分词器选择会把长 prompt 压成很少的 token，发布版推理直接读取本地 tokenizer.json 的字节级 BPE 规则，不要指望框架替你自动选对实现。

该路径的边界也要清楚：贪心生成、无连续动态批处理/分页 KV/前缀缓存/CUDA Graph；BF16 的"文件分片全流程"官方标注尚未端到端验证（流式权重加载方式下双节点 16 卡已通过文本与单图生成验证）。它是验证权重、跑回归的可靠底座（test_vision.py 提供 203 项配置/生成/缓存回归），但生产服务还是建议走 vLLM 或 SGLang。

四、首跑验证：1M 上下文是真能吃下，还是配置摆设？

先看事实基线。config.json 中max_seq_len与max_position_embeddings均为1048576，位置编码采用rope_type: "llama3"缩放；注意力为"滑窗 + 全量"混合布局——92 层里每 4 层插入一个full_attention（第 3、7、…、91 层共 23 层），其余为 512 窗口滑窗注意力（sliding_window: 512）。全量注意力层还挂了 DSA 稀疏索引器：topk: 512、region_block_size: 8、num_provider_groups: 4，即长程依赖通过"先选 512 个最相关历史区域再算注意力"来摊薄成本。这套结构决定了 1M 上下文的 KV 占用不会随层数线性爆炸——滑窗层只缓存 512 窗口，全量层也只保留索引器选中的区域。

vLLM 起服务时上下文参数是显式写满的：

vllm serve stepfun-ai/Step-5-Preview \ --served-model-name "step5" \ --tensor-parallel-size 8 \ --max-model-len 1048576 \ --max-num-batched-tokens 16384 \ --max-num-seqs 64 \ --gpu-memory-utilization 0.85 \ --enable-prefix-caching \ --spec-method mtp --spec-tokens 3 \ --reasoning-parser step5 \ --enable-auto-tool-choice --tool-call-parser step5

但 README 同时给了一句非常克制的话："1M-token 上下文上限覆盖输入与输出之和；如果 KV cache 内存不足，降低--max-model-len或并发。"换句话说，能不能真吃下 1M，取决于"权重 + 激活 + KV cache"三本账在单节点 8×H200（1128 GiB）或 4×B300 上能否同时闭合：

• 权重账：FP8 约 600 GiB，H200×8 摊薄后每卡 75 GiB 上下，还有余量；
• KV 账：1M token 的 KV cache 是主要变量。--max-num-seqs 64意味着最多 64 条序列共享 KV 预算，跑长上下文时应把并发压到个位数甚至 1；SGLang 侧对应调--max-running-requests与--swa-full-tokens-ratio 0.03（只给全量 KV 留 3% 的预算比例，其余靠滑窗 + 稀疏区域压缩）；
• prefill 账：--max-num-batched-tokens 16384（vLLM）/--chunked-prefill-size 16384（SGLang）把 1M 的 prefill 切成 16K 的分块渐进执行，避免一次性激活峰值撑爆显存。

仓库自带的离线路径则明确承认：BF16 双节点验证"尚未覆盖长上下文负载与吞吐"。所以严谨的结论是——1M 在架构与配置层面是完整支持且可配置满的（滑窗 + DSA 稀疏索引 + llama3 RoPE 三件套就是为此设计的），但"端到端 1M 请求"的显存账单没有官方逐卡实测数字，社区情报中也尚未见 1M 满上下文的成功案例；首跑建议按"短请求验证功能 → 逐步放大max-model-len（如 128K、256K）→ 观察 KV 余量"的节奏推进，而非直接拉满。

服务起来后，用一条请求完成闭环验证（注意官方推荐的采样参数temperature=1.0, top_p=0.95, top_k=0，且 reasoning 与 tool-call 都要挂step5解析器，否则思考链和工具调用会混进正文）：

curl http://127.0.0.1:18000/v1/chat/completions \ --header 'Content-Type: application/json' \ --data '{ "model": "step5", "messages": [{"role": "user", "content": "你好，请自我介绍，并说明你能处理的最长上下文。"}], "max_tokens": 4096, "temperature": 1.0, "top_p": 0.95, "stream": true }'

流式返回能正常出 token、思考段与正文分离、/v1/models里能查到step5，就说明权重、分片、解析器链路全部打通。

五、落地清单

把前面四节收敛成一张清单：

1. 磁盘：FP8 约 606 GiB，预留 1TB+，拉完核对 27 个 LFS 文件（含不在索引内的vit.safetensors侧车）；
2. 硬件：FP8 选 4×B300（TP4/TEP4/DEP4）或 8×H200（TP8/TEP8/DEP8）单节点；BF16 需 8×B300 或双节点 16×H200，别指望--dtype bfloat16救场；
3. 镜像：vLLM 用vllm/vllm-openai:step-5-preview，SGLang 用lmsysorg/sglang:step-5-preview，自带 Transformers 路径则严格按 inference/requirements.txt 的版本范围装依赖；
4. 后端口径：Hopper（H200）与 Blackwell（B300）的 MoE/attention backend 参数不同，MegaMoE 仅限 B300；
5. 上下文：1M 可配置、KV 是硬约束，压并发、分块 prefill、调滑窗保留比例，逐级放大验证；
6. 验收：reasoning-parser step5+tool-call-parser step5+ MTP 投机解码三件套齐了才算"完整形态"，离线generate.py路径只适合做权重回归验证，不宜直接当服务用。

600B 的权重从 Hugging Face 落到 8 张 H200 上，本质上是一道"600 GiB 权重 + 1M KV"的双账本问题。把账算清、把 backend 选对，Step 5 Preview 的本地部署并没有想象中玄学。

【免费下载链接】Step-5-PreviewStep 5 Preview 是阶跃星辰面向智能体工作打造的旗舰模型。该模型在软件工程和专业知识工作领域均展现出前沿级性能，尤其在金融领域表现突出。 Step 5 Preview 是一个稀疏混合专家（MoE）模型，总参数量为 600B，激活参数量为 27B。它支持高达 100 万 token 的上下文长度，并可接收文本、图像和视频输入，能够在复杂任务中实现持续推理与工具调用。项目地址: https://ai.gitcode.com/StepFun/Step-5-Preview