Step 5 Preview 本地跑起来从权重下载到部署的一站式实操【免费下载链接】Step-5-PreviewStep 5 Preview 是阶跃星辰面向智能体工作打造的旗舰模型。该模型在软件工程和专业知识工作领域均展现出前沿级性能尤其在金融领域表现突出。 Step 5 Preview 是一个稀疏混合专家MoE模型总参数量为 600B激活参数量为 27B。它支持高达 100 万 token 的上下文长度并可接收文本、图像和视频输入能够在复杂任务中实现持续推理与工具调用。项目地址: https://ai.gitcode.com/StepFun/Step-5-Preview9 月 20 日阶跃星辰发布了面向 Agentic 工作流的旗舰基座模型 Step 5 Preview600B 总参数、27B 激活参数的稀疏 MoE支持最长 1M token 上下文原生接收文本、图像与视频输入。发布后它一路冲上 OpenRouter 全球 Trending 榜配合腾讯 WorkBuddy 10 月 12 日至 25 日的限时免费社区实测集中在 3D 游戏开发、金融分析、网页生成等长程工具调用场景。10 月 15 日权重正式开源——FP8 与 BF16 两套 checkpoint 分别上线 Hugging Face 与 ModelScopestepfun-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 逐文件求和整套下载内容约为文件组大小24 个主模型分片FP8约 21 个 25.74 GiB/片 头尾片≈ 591.5 GiBmodel-mtp3-00001.safetensors/model-mtp3-full-00001.safetensors3 层 MTP 多 token 预测权重2.09 GiB / 4.69 GiBmodel-vit-00001.safetensors/ 侧车文件 vit.safetensors667 个 BF16 张量各 3.69 GiB合计≈ 606 GiB两个实操提醒一是磁盘要预留1TB 以上可用空间因为除了权重本尊推理框架还要写 KV cache、激活、分片转换产物二是vit.safetensors是独立侧车文件fp8_vit_sidecar_ready.json 中标记vit_in_model_index: false即它不在权重索引内校验下载完整性时容易漏掉建议拉完后核对这 27 个 LFS 文件一个不少。如果走鉴权仓库容器内先执行hf auth login再下载。显存预算则按部署形态分档。README.md 给出的官方部署配置矩阵如下框架精度硬件并行方式接口vLLMFP8单节点 4 × B300TP4 / TEP4 / DEP4OpenAI 兼容 APIvLLMFP8单节点 8 × H200TP8 / TEP8 / DEP8OpenAI 兼容 APIvLLMBF16单节点 8 × B300TP8 / TEP8 / DEP8OpenAI 兼容 APIvLLMBF16双节点 16 × H200TP16 / TEP16 / DEP16OpenAI 兼容 APITransformers仓库自带FP8单节点 8 × H200TP8 / EP8离线生成Transformers仓库自带BF16双节点 16 × H200TP16 / EP16离线生成SGLangFP8单节点 4 × B300TP4/EP4OpenAI 兼容 APISGLangFP8单节点 8 × H200TP8/EP8OpenAI 兼容 API结论先说FP8 是本地部署的甜点档最低 4 张 B300 即可起服务BF16 则基本是双节点 16 卡起步——仓库中 inference/README.md 给出了实测依据92 层 BF16 模型在 TP/EP8 下仅参数就需约 144.41 GiB/卡直接超出 H200 的 140.40 GiB 上限拉到 TP/EP16 后实测加载参数约 74.93 GiB/卡batch1、943 token 图文请求下 PyTorch 显存分配峰值 76.37 GiB/卡。这个峰值还没算 NCCL、CUDA context、KV cache 与长上下文的余量所以 1M 上下文在 BF16 双节点上依然要精打细算。二、稀疏 MoE 的量化结构与部署注意点Step 5 Preview 的量化不是一把梭而是有明确边界的混合精度直接看 config.json 里的quantization_configquant_method: fp8fmt: e4m3activation_scheme: dynamicweight_block_size: [128, 128]——即分块缩放block-scaledFP8 E4M3权重 动态激活量化而不是 per-tensor 的朴素 FP8modules_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 左右、而单卡显存压力集中在专家并行切分的原因。部署时真正容易踩的坑有四个--dtype bfloat16不会反量化。README 特意强调对 FP8 checkpoint 设置--dtype bfloat16不会把量化权重转回 BF16想要 BF16 必须挂载独立的 BF16 checkpoint 并把MODEL指向它。MegaMoE 只在 B300Blackwell上启用。vLLM 的 TEP4/DEP4 命令带--moe-backend deep_gemm_mega_moe该后端要求专家并行在 H200Hopper上必须删掉这个参数、回落到默认 MoE 后端。SGLang 的 backend 选择与 GPU 代际绑定。官方镜像lmsysorg/sglang:step-5-preview下B300 用--moe-runner-backend flashinfer_trtllm --moe-a2a-backend megamoe --attention-backend fa4H200 换成--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 上下文时还会用到它。投机解码走 MTP但仅服务侧框架支持。vLLM 示例统一带--spec-method mtp --spec-tokens 3SGLang 侧对应--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 专家 GEMMfp8_gemm/linear_fp8_or_bf16、以及融合的 QKNorm/RoPE。长输出稳定性约定也写进了文档TP 部分结果按 rank 顺序以 FP32 累加、EOS 后逐行整理 cache——inference/README.md 明确这不承诺不同批大小/硬件间的逐位一致。三、不想上 vLLM/SGLang用仓库自带的 Transformers 路径inference/ 目录是一套可独立运行的最小推理路径共 8400 行 Pythonmodel.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 # torch2.10,2.14 等版本范围 export STEP5_FP8_CHECKPOINTFP8_CHECKPOINT_DIRECTORY export STEP5_FP8_OUTFP8_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-node8 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而非张量切分TPEP8 时每 rank 放置 44/352 个完整专家TPEP16 时 22 个TP 与 EP 共用进程组--ep-size当前必须等于 TP/进程总数TP4, EP2这类独立进程组组合未实现BF16 双节点启动不用--standalone改用--nnodes2 --master-addr的 rendezvous 方式两节点分别执行同一命令、各设NODE_RANK0/1已验证运行环境为 PyTorch 2.13.0cu129、Triton 3.7.1、Transformers 5.15.0、Safetensors 0.8.0。另有一个隐藏坑Transformers 5.15 的自动分词器选择会把长 prompt 压成很少的 token发布版推理直接读取本地 tokenizer.json 的字节级 BPE 规则不要指望框架替你自动选对实现。该路径的边界也要清楚贪心生成、无连续动态批处理/分页 KV/前缀缓存/CUDA GraphBF16 的文件分片全流程官方标注尚未端到端验证流式权重加载方式下双节点 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×H2001128 GiB或 4×B300 上能否同时闭合权重账FP8 约 600 GiBH200×8 摊薄后每卡 75 GiB 上下还有余量KV 账1M token 的 KV cache 是主要变量。--max-num-seqs 64意味着最多 64 条序列共享 KV 预算跑长上下文时应把并发压到个位数甚至 1SGLang 侧对应调--max-running-requests与--swa-full-tokens-ratio 0.03只给全量 KV 留 3% 的预算比例其余靠滑窗 稀疏区域压缩prefill 账--max-num-batched-tokens 16384vLLM/--chunked-prefill-size 16384SGLang把 1M 的 prefill 切成 16K 的分块渐进执行避免一次性激活峰值撑爆显存。仓库自带的离线路径则明确承认BF16 双节点验证尚未覆盖长上下文负载与吞吐。所以严谨的结论是——1M 在架构与配置层面是完整支持且可配置满的滑窗 DSA 稀疏索引 llama3 RoPE 三件套就是为此设计的但端到端 1M 请求的显存账单没有官方逐卡实测数字社区情报中也尚未见 1M 满上下文的成功案例首跑建议按短请求验证功能 → 逐步放大max-model-len如 128K、256K→ 观察 KV 余量的节奏推进而非直接拉满。服务起来后用一条请求完成闭环验证注意官方推荐的采样参数temperature1.0, top_p0.95, top_k0且 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就说明权重、分片、解析器链路全部打通。五、落地清单把前面四节收敛成一张清单磁盘FP8 约 606 GiB预留 1TB拉完核对 27 个 LFS 文件含不在索引内的vit.safetensors侧车硬件FP8 选 4×B300TP4/TEP4/DEP4或 8×H200TP8/TEP8/DEP8单节点BF16 需 8×B300 或双节点 16×H200别指望--dtype bfloat16救场镜像vLLM 用vllm/vllm-openai:step-5-previewSGLang 用lmsysorg/sglang:step-5-preview自带 Transformers 路径则严格按 inference/requirements.txt 的版本范围装依赖后端口径HopperH200与 BlackwellB300的 MoE/attention backend 参数不同MegaMoE 仅限 B300上下文1M 可配置、KV 是硬约束压并发、分块 prefill、调滑窗保留比例逐级放大验证验收reasoning-parser step5tool-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/16 2:05:23 · 阅读 1.2k 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-Preview9 月 20 日阶跃星辰发布了面向 Agentic 工作流的旗舰基座模型 Step 5 Preview600B 总参数、27B 激活参数的稀疏 MoE支持最长 1M token 上下文原生接收文本、图像与视频输入。发布后它一路冲上 OpenRouter 全球 Trending 榜配合腾讯 WorkBuddy 10 月 12 日至 25 日的限时免费社区实测集中在 3D 游戏开发、金融分析、网页生成等长程工具调用场景。10 月 15 日权重正式开源——FP8 与 BF16 两套 checkpoint 分别上线 Hugging Face 与 ModelScopestepfun-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 逐文件求和整套下载内容约为文件组大小24 个主模型分片FP8约 21 个 25.74 GiB/片 头尾片≈ 591.5 GiBmodel-mtp3-00001.safetensors/model-mtp3-full-00001.safetensors3 层 MTP 多 token 预测权重2.09 GiB / 4.69 GiBmodel-vit-00001.safetensors/ 侧车文件 vit.safetensors667 个 BF16 张量各 3.69 GiB合计≈ 606 GiB两个实操提醒一是磁盘要预留1TB 以上可用空间因为除了权重本尊推理框架还要写 KV cache、激活、分片转换产物二是vit.safetensors是独立侧车文件fp8_vit_sidecar_ready.json 中标记vit_in_model_index: false即它不在权重索引内校验下载完整性时容易漏掉建议拉完后核对这 27 个 LFS 文件一个不少。如果走鉴权仓库容器内先执行hf auth login再下载。显存预算则按部署形态分档。README.md 给出的官方部署配置矩阵如下框架精度硬件并行方式接口vLLMFP8单节点 4 × B300TP4 / TEP4 / DEP4OpenAI 兼容 APIvLLMFP8单节点 8 × H200TP8 / TEP8 / DEP8OpenAI 兼容 APIvLLMBF16单节点 8 × B300TP8 / TEP8 / DEP8OpenAI 兼容 APIvLLMBF16双节点 16 × H200TP16 / TEP16 / DEP16OpenAI 兼容 APITransformers仓库自带FP8单节点 8 × H200TP8 / EP8离线生成Transformers仓库自带BF16双节点 16 × H200TP16 / EP16离线生成SGLangFP8单节点 4 × B300TP4/EP4OpenAI 兼容 APISGLangFP8单节点 8 × H200TP8/EP8OpenAI 兼容 API结论先说FP8 是本地部署的甜点档最低 4 张 B300 即可起服务BF16 则基本是双节点 16 卡起步——仓库中 inference/README.md 给出了实测依据92 层 BF16 模型在 TP/EP8 下仅参数就需约 144.41 GiB/卡直接超出 H200 的 140.40 GiB 上限拉到 TP/EP16 后实测加载参数约 74.93 GiB/卡batch1、943 token 图文请求下 PyTorch 显存分配峰值 76.37 GiB/卡。这个峰值还没算 NCCL、CUDA context、KV cache 与长上下文的余量所以 1M 上下文在 BF16 双节点上依然要精打细算。二、稀疏 MoE 的量化结构与部署注意点Step 5 Preview 的量化不是一把梭而是有明确边界的混合精度直接看 config.json 里的quantization_configquant_method: fp8fmt: e4m3activation_scheme: dynamicweight_block_size: [128, 128]——即分块缩放block-scaledFP8 E4M3权重 动态激活量化而不是 per-tensor 的朴素 FP8modules_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 左右、而单卡显存压力集中在专家并行切分的原因。部署时真正容易踩的坑有四个--dtype bfloat16不会反量化。README 特意强调对 FP8 checkpoint 设置--dtype bfloat16不会把量化权重转回 BF16想要 BF16 必须挂载独立的 BF16 checkpoint 并把MODEL指向它。MegaMoE 只在 B300Blackwell上启用。vLLM 的 TEP4/DEP4 命令带--moe-backend deep_gemm_mega_moe该后端要求专家并行在 H200Hopper上必须删掉这个参数、回落到默认 MoE 后端。SGLang 的 backend 选择与 GPU 代际绑定。官方镜像lmsysorg/sglang:step-5-preview下B300 用--moe-runner-backend flashinfer_trtllm --moe-a2a-backend megamoe --attention-backend fa4H200 换成--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 上下文时还会用到它。投机解码走 MTP但仅服务侧框架支持。vLLM 示例统一带--spec-method mtp --spec-tokens 3SGLang 侧对应--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 专家 GEMMfp8_gemm/linear_fp8_or_bf16、以及融合的 QKNorm/RoPE。长输出稳定性约定也写进了文档TP 部分结果按 rank 顺序以 FP32 累加、EOS 后逐行整理 cache——inference/README.md 明确这不承诺不同批大小/硬件间的逐位一致。三、不想上 vLLM/SGLang用仓库自带的 Transformers 路径inference/ 目录是一套可独立运行的最小推理路径共 8400 行 Pythonmodel.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 # torch2.10,2.14 等版本范围 export STEP5_FP8_CHECKPOINTFP8_CHECKPOINT_DIRECTORY export STEP5_FP8_OUTFP8_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-node8 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而非张量切分TPEP8 时每 rank 放置 44/352 个完整专家TPEP16 时 22 个TP 与 EP 共用进程组--ep-size当前必须等于 TP/进程总数TP4, EP2这类独立进程组组合未实现BF16 双节点启动不用--standalone改用--nnodes2 --master-addr的 rendezvous 方式两节点分别执行同一命令、各设NODE_RANK0/1已验证运行环境为 PyTorch 2.13.0cu129、Triton 3.7.1、Transformers 5.15.0、Safetensors 0.8.0。另有一个隐藏坑Transformers 5.15 的自动分词器选择会把长 prompt 压成很少的 token发布版推理直接读取本地 tokenizer.json 的字节级 BPE 规则不要指望框架替你自动选对实现。该路径的边界也要清楚贪心生成、无连续动态批处理/分页 KV/前缀缓存/CUDA GraphBF16 的文件分片全流程官方标注尚未端到端验证流式权重加载方式下双节点 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×H2001128 GiB或 4×B300 上能否同时闭合权重账FP8 约 600 GiBH200×8 摊薄后每卡 75 GiB 上下还有余量KV 账1M token 的 KV cache 是主要变量。--max-num-seqs 64意味着最多 64 条序列共享 KV 预算跑长上下文时应把并发压到个位数甚至 1SGLang 侧对应调--max-running-requests与--swa-full-tokens-ratio 0.03只给全量 KV 留 3% 的预算比例其余靠滑窗 稀疏区域压缩prefill 账--max-num-batched-tokens 16384vLLM/--chunked-prefill-size 16384SGLang把 1M 的 prefill 切成 16K 的分块渐进执行避免一次性激活峰值撑爆显存。仓库自带的离线路径则明确承认BF16 双节点验证尚未覆盖长上下文负载与吞吐。所以严谨的结论是——1M 在架构与配置层面是完整支持且可配置满的滑窗 DSA 稀疏索引 llama3 RoPE 三件套就是为此设计的但端到端 1M 请求的显存账单没有官方逐卡实测数字社区情报中也尚未见 1M 满上下文的成功案例首跑建议按短请求验证功能 → 逐步放大max-model-len如 128K、256K→ 观察 KV 余量的节奏推进而非直接拉满。服务起来后用一条请求完成闭环验证注意官方推荐的采样参数temperature1.0, top_p0.95, top_k0且 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就说明权重、分片、解析器链路全部打通。五、落地清单把前面四节收敛成一张清单磁盘FP8 约 606 GiB预留 1TB拉完核对 27 个 LFS 文件含不在索引内的vit.safetensors侧车硬件FP8 选 4×B300TP4/TEP4/DEP4或 8×H200TP8/TEP8/DEP8单节点BF16 需 8×B300 或双节点 16×H200别指望--dtype bfloat16救场镜像vLLM 用vllm/vllm-openai:step-5-previewSGLang 用lmsysorg/sglang:step-5-preview自带 Transformers 路径则严格按 inference/requirements.txt 的版本范围装依赖后端口径HopperH200与 BlackwellB300的 MoE/attention backend 参数不同MegaMoE 仅限 B300上下文1M 可配置、KV 是硬约束压并发、分块 prefill、调滑窗保留比例逐级放大验证验收reasoning-parser step5tool-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考