Step 5 Preview Open Weights: 600B MoE, 27B Active, 1M Context for Agents

A 600-billion-parameter model that only computes with 27 billion parameters per token, reads a million tokens of context, and ships with downloadable weights is no longer a research curiosity. It is a deployment decision with a hardware bill attached. Step 5 Preview, from the Chinese lab StepFun, is the latest model to force that decision: it is a sparse mixture-of-experts (MoE) system aimed squarely at long-horizon agent work such as repository-level coding, repeated tool calls, and verification loops.

It matters now because the open-weight frontier has shifted from “can it chat” to “can it run for two hundred tool calls without losing the plot, at a price and on hardware I can control.” Open weights change the answer to the second half of that question. They also change the risks, because a 1M-token window and a 600B checkpoint stress memory systems in ways that benchmark tables do not show.

You will leave with a verified picture of what StepFun has and has not disclosed, how the architecture works, what the vendor benchmarks do and do not tell you, how to size serving hardware, how to read the license, and when to choose this model over its open-weight peers.

What this covers: the release timeline, the architecture (Sparse GQA, sliding-window layers, multi-token prediction), the training claims, benchmark interpretation, serving recipes with a runnable snippet, illustrative KV-cache and hardware math, failure modes, and a decision matrix against DeepSeek V4.1 Flash and MiMo-V2.6.

Context and Background

The open-weight market in late 2026 is crowded with large sparse models. The pattern is consistent: total parameters in the hundreds of billions to low trillions, active parameters in the tens of billions, and a context window that has crept from 128K to a million tokens. Mixture-of-experts is what makes that arithmetic work. Each token is routed to a small subset of experts, so per-token compute tracks the active parameter count while model capacity tracks the total. If routing is new to you, our deep dive on MoE routing, top-k gating, load balancing and expert capacity covers the mechanics that Step 5 Preview builds on.

StepFun is not a newcomer. The lab previously published multimodal and reasoning models under the Step name, and Step 5 Preview is its first release positioned explicitly as an agent model rather than a general assistant. Its closest open-weight peers in this series are DeepSeek V4.1 Flash, which we analysed for its KV-cache design, and Xiaomi’s MiMo-V2.6 Pro. Where they optimise different corners of the same design space, Step 5 Preview optimises for long, tool-heavy trajectories.

The release timeline, and why sources disagree

The timeline is messier than a single press release suggests, and it is worth stating carefully. Secondary sources agree on the following sequence, though dates differ by source:

A model catalogue (llmreference.com) lists Step 5 Preview under 2026-09-20 with the 600B total, 27B active, 1M context specification. A related benchmark score cited in the official README is dated to Artificial Analysis on September 20, 2026, which is consistent with a hosted preview in late September.
The model reached OpenRouter on October 8, 2026 under the identifier stepfun/step-5-preview, with StepFun as the only provider. At that time Artificial Analysis labelled it proprietary.
StepFun stated the model would be released with open weights on October 15, 2026, and secondary coverage (MarkTechPost, DevelopersDigest) reports the release on or about that date. The initial announcement did not name a license.

So “Preview” refers to the model’s maturity label, not to a closed-then-open handover by accident: the hosted API came first, the weights followed within about a week of the OpenRouter listing. One caveat: I could not retrieve the MarkTechPost article during research, so its details are cited only as headline-level corroboration. Everything below that carries a number comes from the official repository README, the StepFun technical blog, the vLLM recipe page, or the DevelopersDigest summary, and is attributed accordingly.

What “Preview” implies for adopters

A preview tag means the post-training recipe is not final. Expect a later checkpoint with different behaviour, and expect tooling such as parsers and chat templates to change. The official serving recipes already require custom containers (vllm/vllm-openai:step-5-preview and lmsysorg/sglang:step-5-preview) and custom step5 reasoning and tool-call parsers, which tells you that mainline inference engines had not yet absorbed the model’s quirks at release. Pin your versions.

Step 5 Preview Architecture: Sparse GQA, Sliding Windows and MTP

Step 5 Preview is a sparse mixture-of-experts transformer with 600B total and 27B active parameters per token, 92 blocks, a 1M-token context window, and a hybrid attention stack that interleaves gated sliding-window layers with sparse full-attention layers at a 3:1 ratio. It reads text and images, outputs text, and uses a multi-token prediction head for faster decoding.

Figure 1: Step 5 Preview block layout as disclosed by StepFun. Expert count, top-k routing and head dimensions are not published.

Figure 1 summarises the disclosed structure. Three groups of numbers are official: the parameter counts (600B total, 27B active), the depth (92 transformer blocks, which StepFun’s technical blog describes as “narrow but deep”), and the attention layout. Several numbers a reader would expect are not disclosed: the number of experts, the top-k routing width, the hidden size, the number of attention and KV heads, and the tokenizer vocabulary. I will not guess them. Where the sections below need a number to illustrate memory math, I use clearly labelled assumptions.

Active versus total parameters

The 27B active figure is about 4.5 percent of the 600B total. That ratio drives everything operationally. Per-token compute is roughly that of a 27B dense model, so decoding throughput per GPU can be high once the weights are resident. But every expert must be resident somewhere, because any token may route to any of them. You pay memory for 600B and FLOPs for 27B.

This is the central misunderstanding in open-weight MoE adoption. Teams read “27B active” and imagine a single-GPU workload. The README’s hardware table disposes of that: the smallest supported configuration is one node of four B300 GPUs or eight H200 GPUs, in FP8. The DevelopersDigest write-up reaches the same conclusion and notes that one reader could not run it on 128GB of shared memory.

StepFun’s blog adds a comparison point: total parameters under one quarter, and active parameters under one third, of two larger rivals it names (Qwen3.8-Max and Kimi K3). The exact counts for those rivals are not given in the source, so treat the claim as StepFun’s positioning, not a measured ratio.

Hybrid attention: gated sliding window plus Sparse GQA

Attention cost is the other half of the long-context problem. Dense full attention over a million tokens is quadratic in compute and linear in KV-cache memory. Step 5 Preview attacks both with two mechanisms.

First, three of every four attention layers use Gated Sliding Window Attention, which attends only to a local window. These layers keep a bounded KV cache regardless of sequence length. Second, the remaining one in four layers uses gated grouped-query attention (GQA) with a sparse selection mechanism, called Sparse GQA. Instead of attending to all prior tokens, a lightweight indexer scores blocks of keys and each query attends only to the top-scoring ones.

StepFun reports the final configuration: a block size of B = 8 and top-k of 4,096 tokens, which is 512 blocks. Blocking cuts the indexer and top-k cost by a factor of 8 relative to token-level selection. The company reports token coverage of 78.06 percent for the B = 8, k = 4,096 setting, versus 79.09 percent for a B = 1, k = 2,048 reference. In plain terms, the coarser block selection recovers nearly the same set of important tokens at much lower selection cost. That coverage metric is a proxy and not an accuracy result; the blog publishes no downstream accuracy comparison for it.

Figure 2 shows the per-layer data flow for the sparse full-attention path.

Figure 2: Sparse GQA in a full-attention layer. An indexer scores 8-token key blocks, the top 512 blocks (4,096 tokens) are selected, and standard grouped-query attention runs only over them.

The design resembles the family of sparse-attention approaches that other labs have adopted for long context, including the indexer-plus-top-k pattern seen in DeepSeek’s recent work, which our DeepSeek V4.1 Flash analysis examines from the KV-cache angle. The distinguishing choices here are the 3:1 local-to-sparse ratio, the gating on both attention types, and the block size of 8.

Multi-token prediction

StepFun trains an MTP-3 head after supervised fine-tuning. The serving recipes expose it through --spec-method mtp --spec-tokens 3 in vLLM, and an EAGLE-style multi-layer speculative decoder in SGLang. StepFun reports roughly a 30 percent end-to-end speedup from it. Speculative decoding is lossless in distribution when verified correctly, so the trade-off is extra memory and complexity, not quality. I would treat the 30 percent as a vendor figure that depends on batch size and acceptance rate.

Modalities and the documentation inconsistency

The README specification table lists text and image input with text output. The introduction text of the same README also mentions video, so the official page is internally inconsistent. The llmreference changelog likewise lists reasoning, vision and video. I would treat image input as confirmed and video as “claimed, verify against the model card before building on it.” OpenRouter’s listing, per DevelopersDigest, advertises text and image input only.

Training, Benchmarks and What the Numbers Mean

StepFun’s technical blog, “Inside Step 5 Preview,” covers four themes: training stability, Sparse GQA, agentic data synthesis, and reinforcement learning. The blog is unusually specific about infrastructure and unusually quiet about data volume, token counts and compute budget. None of those three are disclosed, so I cannot give you a pre-training token count and will not estimate one.

Training stability for a deep FP8 model

A 92-block model trained in mixed-precision FP8 is fragile. StepFun reports four mitigations:

FP32 hidden states and gradients in the residual stream, which it says reduces peak activation values by nearly an order of magnitude.
An FP32 zero-centred RMSNorm scale parameterised as (1 + gamma), which avoids instability when gamma drifts close to -1.
A fine-grained gradient clamp that clips only 0.00004 percent of gradient values per layer, so it acts as a safety net rather than a regulariser.
Mixed-precision FP8 matrix multiplications for the bulk of the compute.

The pattern is familiar: keep the residual path and normalisation in high precision, push the expensive GEMMs to FP8, and clamp rarely. The same recipe logic explains why the released FP8 checkpoint is a first-class citizen. The model was trained with FP8 in mind, so the FP8 weights are not a lossy afterthought, although StepFun does not publish an accuracy delta between FP8 and BF16 serving.

Agentic data synthesis and reinforcement learning

The blog describes constructing “million-level” verifiable environments across scientific reasoning, software engineering, machine-learning research and professional work. Four components are named: a unified context layer, agent-driven knowledge sourcing, quality steering, and a division of labour between human experts, agents and deterministic code. Difficulty is estimated from task constraints, ground-truth patch length, test-case count, and cross-model pass rates. No thresholds are given, which means the curriculum cannot be reproduced from the blog alone.

On the reinforcement-learning side, task selection is described along three axes: duration, depth (files touched and lines edited), and discriminativeness, meaning reward variance across rollouts. Tasks where every rollout succeeds or fails teach little, so selecting for variance is sensible. The infrastructure claims are concrete: the end-to-end sample drop rate is below 1 percent, native FP8 MoE adds about 20 percent throughput, and KV-cache capacity expands 8 to 12 times. A training-inference alignment claim stands out: logprob difference is exactly zero at staleness zero, and TP=1 and TP=8 runs are bitwise identical with under 10 percent overhead. Bitwise reproducibility between training and inference engines removes a classic source of off-policy drift in RL. Credit assignment and context compaction are described only qualitatively.

These are vendor claims in a vendor blog. They are plausible and technically specific, but no third party has reproduced them.

Vendor-reported benchmarks

The numbers below come from the benchmark table summarised by DevelopersDigest from StepFun’s materials. The official README presents scores only as an image, so I cannot cross-check each cell in text. Treat every cell as vendor-reported.

Benchmark	Step 5 Preview	Kimi K3	GLM-5.3	Claude Opus 5	GPT-6 Astra
DeepSWE v1.1	67.7%	67.5%	66.9%	74.0%	74.1%
ProgramBench	80.5%	77.8%	72.0%	82.3%	85.4%
Terminal-Bench v4	33.3%	12.6%	41.9%	52.3%	57.9%
StepCodeBench (StepFun’s own)	49.0%	43.9%	40.2%	63.9%	61.0%

Figure 3: How to read the benchmark table. Treat each column as a different question: repository repair, program synthesis, terminal autonomy, and a vendor-authored suite.

Three observations matter more than the headline numbers.

First, the open-weight peers are close on DeepSWE (67.7 against 67.5 and 66.9), but the closed frontier models lead by roughly six to seven points. Step 5 Preview is competitive with the best open peers and still behind the closed leaders on repository-level repair.

Second, Terminal-Bench v4 is where the picture splits. Step 5 Preview scores 33.3 percent, far above Kimi K3 at 12.6 but below GLM-5.3 at 41.9 and well below the closed models. Terminal autonomy, with its long chains of shell commands and recovery from errors, is exactly the workload the model markets itself for, so this is its weakest relative showing and the one to test on your own tasks.

Third, StepCodeBench is StepFun’s own benchmark. Vendor-authored suites tend to favour the vendor’s training distribution. Even there it trails both closed models. DevelopersDigest also notes that StepFun compared its “High” reasoning setting against rivals’ “Max” settings, which is an asymmetric comparison that probably understates the gap in some rows and is hard to interpret in others.

Independent evaluation

Artificial Analysis, an independent aggregator, gave Step 5 Preview an Intelligence Index of 44, ranking it 40th of 226 tracked models, against a median of 26 for comparable reasoning models. It also recorded 160 million output tokens to complete the index against a median of 81 million, and described the model as very verbose. A Hacker News commenter, whose figures are unverified, placed Kimi K3 (max) at 44 with 160M tokens, GLM-5.3 at 45 with 210M tokens, and DeepSeek 4.1 Flash at 39 with 250M tokens. If those figures hold, Step 5 Preview is on par for intelligence and mid-pack for verbosity.

Verbosity is a cost multiplier and a latency multiplier. A model that thinks twice as long as the median at the same per-token price costs twice as much per task. Artificial Analysis puts one Intelligence Index task at $1.03 for this model, and OpenRouter pricing checked on October 9, 2026 was $1.00 per million input tokens, $2.70 per million output tokens and $0.05 per million cache-read tokens. Those are hosted-API prices, not self-hosting costs, and they will move.

Benchmark caveats you should apply

Agent benchmarks depend heavily on the harness. The README states that DeepSWE v1.1 used the SWE-agent harness at temperature 1.0 and top-p 0.95. A different scaffold can shift scores by several points either way.
Recommended sampling is temperature 1.0, top-p 0.95, top-k 0 (disabled). Using greedy decoding on a reasoning model trained under these settings can degrade results.
Contamination risk is not addressed in the sources. Any public repository benchmark has some.
Early OpenRouter telemetry from October 9 reported a tool-call error rate under 2 percent but a structured-output error rate of about 17 percent, on a single provider shortly after launch. This is a small, early sample, but if your agent relies on strict JSON schema output, test that path first.

Serving a 600B MoE: Memory, Hardware and a Runnable Recipe

To serve Step 5 Preview you need roughly 600 GB for FP8 weights, plus KV-cache headroom. The official minimum is one node of four B300 GPUs or eight H200 GPUs in FP8, with vLLM, SGLang or Transformers. BF16 needs about twice that, and the README warns BF16 configurations may not fit a full 1M-token request.

Figure 4: Serving topology. A single FP8 node holds all experts across GPUs, with tensor, expert or data parallelism selecting how tokens and weights are split.

Weight memory arithmetic

The arithmetic is simple and worth doing before any procurement call. FP8 stores one byte per parameter, so 600B parameters occupy about 600 GB. BF16 stores two bytes, so about 1.2 TB. These figures exclude activations, the KV cache, CUDA graphs and framework overhead.

An H200 carries 141 GB of HBM, so eight give about 1,128 GB. A B300 carries roughly 288 GB (a vendor specification I am quoting from memory of NVIDIA’s published figure, so verify it before purchasing), so four give about 1,152 GB. At the recipe’s --gpu-memory-utilization 0.85, an eight-H200 node offers about 959 GB, leaving roughly 350 GB after 600 GB of FP8 weights. That remainder must cover the KV cache and all runtime buffers. The BF16 configurations need either a B300 node with eight GPUs or two H200 nodes with sixteen GPUs, matching the README table.

KV-cache math at 1M tokens (illustrative)

StepFun does not publish head counts or head dimensions, so the following is explicitly an illustrative calculation using assumed values, not Step 5 Preview’s real numbers.

Assume 8 KV heads, a head dimension of 128 and a 2-byte cache (the SGLang recipe sets --kv-cache-dtype bfloat16). Per token per layer, keys plus values cost 2 x 8 x 128 x 2 = 4,096 bytes. With 92 blocks at a 3:1 ratio, about 23 layers are sparse full attention and 69 are sliding window.

The 23 full-attention layers must retain the whole sequence, because the indexer may select any block. At 1M tokens: 23 x 4,096 bytes x 1,048,576 is about 99 GB (roughly 92 GiB).
The 69 sliding-window layers hold only the window. With an assumed 4,096-token window, that is 69 x 4,096 x 4,096 bytes, about 1.2 GB per sequence, which is negligible.

Under those assumptions a single 1M-token request costs on the order of 100 GB of cache, nearly all of it in the sparse layers. If real head counts are larger, the figure scales linearly. If the model uses a compressed cache representation, it shrinks. The takeaway is structural: the 3:1 hybrid cuts the cache by roughly four times against a model with full attention in every layer, and the sparse top-k cuts compute per decoded token to a fixed 4,096-token read in the full-attention layers. With 350 GB of headroom on one H200 node, you could hold only a few concurrent near-maximal sequences, which is why the recipe caps --max-num-seqs at 64 and suggests reducing --max-model-len or concurrency when memory is short. The NVFP4 recipe on four B300 GPUs reduces --max-model-len to 320,000 for exactly this reason.

Parallelism modes

The recipes name three modes. TP shards every weight matrix across GPUs and all-reduces activations, which is simple and latency-friendly. TEP adds expert parallelism on top of tensor parallelism, placing different experts on different GPUs and moving tokens with all-to-all communication. DEP uses data parallelism for attention and expert parallelism for the MoE layers, which usually maximises throughput for many concurrent requests because attention replicas do not communicate. On Blackwell the TEP and DEP paths use a MegaMoE backend (deep_gemm_mega_moe); on Hopper you omit the flag and use the default backend. For SGLang the recipe sets different attention backends by hardware: fa4 on B300 and fa3 on H200.

A runnable vLLM recipe

The following is adapted from the official vLLM recipe for an eight-GPU FP8 node. I have not executed it, and flags in a preview container can change, so check the recipe page before use.

docker pull vllm/vllm-openai:step-5-preview
docker run --rm -it --gpus all --ipc=host --network=host \
  --volume "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  --entrypoint /bin/bash vllm/vllm-openai:step-5-preview

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

A client call then uses any OpenAI-compatible SDK, with the recommended sampling settings:

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
    model="stepfun-ai/Step-5-Preview",
    messages=[{"role": "user", "content": "Plan a refactor of utils.py"}],
    temperature=1.0,
    top_p=0.95,
    max_tokens=4096,
)
print(resp.choices[0].message.content)

Note the port. The vLLM recipe page uses 8000 and the model name equals the checkpoint path, while the README’s variant serves on port 18000 under the name step5. Both are official, so match the client to whichever launch command you used.

Alternatives: SGLang, Transformers, quantised checkpoints

SGLang is the other first-class path: lmsysorg/sglang:step-5-preview, with TP4/EP4 on B300 or TP8/EP8 on H200, a page size of 64, a bfloat16 KV cache, and EAGLE speculative decoding with three steps. The Transformers path is offline: a convert.py step shards the checkpoint for tensor and expert parallelism and generate.py runs under torchrun. The README says the BF16 shard workflow is not fully validated, so prefer FP8. An NVFP4 checkpoint (stepfun-ai/Step-5-Preview-NVFP4) exists for four B300 GPUs, though community NVFP4 builds also appear on Hugging Face and should be treated as unvetted.

License, Agent Workloads and How It Compares

The StepFun Model License 1.0

The README states the weights are released under the StepFun Model License 1.0, which it describes as Apache-2.0-style with added attribution and commercial-license conditions. It covers the weights, parameters, configuration, tokenizer, model-specific code and documentation, while separately marked third-party materials keep their own licenses. I could read only the README summary, not the full legal text, so I cannot tell you the exact commercial threshold or what the attribution clause requires. That matters: “Apache-style” and “Apache-2.0” are not the same thing, and a conditional commercial clause can block a product launch late in the process.

Practical implications for a legal review: confirm whether the commercial condition is triggered by revenue, user count or hosting-as-a-service; whether derivative models (fine-tunes, distilled students, quantisations) inherit the terms; and whether the attribution requirement forces visible branding in your product. Until you have read the text, assume it is more restrictive than MIT or Apache-2.0, and do not describe the model internally as “fully permissive.”

What agent workloads actually need

An agent loop differs from a chat workload in four ways, and each stresses a different part of this model.

Long, growing context. An agent that edits a repository accumulates file contents, diffs, test output and tool results. Context of 100K to 400K tokens is common in practice, well below the 1M ceiling. Prefix caching matters enormously because each turn resends nearly the same prefix. The hosted API’s reported cache hit rate of about 95 percent and $0.05 per million cache-read tokens reflect that, and --enable-prefix-caching is on in every self-hosted recipe.
Many short decodes. Each turn usually produces a tool call of a few hundred tokens after a prefill of tens of thousands. Prefill throughput and time to first token dominate, not peak decode speed. Artificial Analysis lists about 88 output tokens per second, and a community report cites 115 tokens per second on OpenRouter; neither number captures prefill-heavy agent traffic.
Parser reliability. Tool calling works only if the tool-call parser extracts valid arguments from the model’s output. The dedicated step5 parsers exist for this reason. A mismatch between parser and chat template is a leading cause of “the model is dumb” reports that are really integration bugs.
Verbosity. Long reasoning inflates both cost and wall-clock time per task. You can tune reasoning effort through the setting your serving stack exposes, but the published evaluations used the High setting.

DevelopersDigest estimates about $0.56 for a 40-turn session with 60K context at 90 percent cache hits and 2K output tokens per turn on the hosted API. That is the author’s estimate, not a measured figure, but the order of magnitude is plausible given the published prices. The point is that for moderate volumes the hosted API at these prices is hard to beat on cost, and self-hosting wins on data control, latency isolation and customisation, not on raw dollars.

Decision matrix against peers

The matrix below is qualitative and reflects the disclosed designs and my reading of the sources, not a head-to-head benchmark, since I found no independent study that tests all three on identical harnesses. Our deeper write-ups on DeepSeek V4.1 Flash and MiMo-V2.6 Pro give the details for those models.

Use case	Step 5 Preview	DeepSeek V4.1 Flash	MiMo-V2.6 Pro
Long-horizon coding agent	Strong fit: designed for tool loops, 1M window, MTP	Strong on cost per token, but reported as more verbose in one unverified comment	Check the post for agent evals before choosing
Multimodal input (images)	Supported, video claim unverified	Check model card	Check model card
Smallest serving footprint	One 8xH200 or 4xB300 node in FP8	Generally lighter per the Flash positioning, verify	Verify per post
Licensing clarity	Custom license, commercial conditions	See post	See post
Terminal-heavy autonomy	Mixed: 33.3 percent Terminal-Bench v4	Not benchmarked here	Not benchmarked here

The honest summary is that Step 5 Preview is a credible first choice when you want a self-hosted agent model with very long context and you have eight-GPU-node hardware. If your constraint is footprint or the most permissive license, look first at the peers.

Trade-offs, Gotchas, and What Goes Wrong

Hardware is the real gate. The cheapest legitimate deployment is a single high-end node. For a team that would have used a 70B dense model on two GPUs, this is a different budget class. The alternative of paying for the hosted API removes the gate but also removes the reason to want open weights.

Context length is a ceiling, not a target. The README says the 1M limit covers input and output combined, and that BF16 configurations may not fit a full request. Even where it fits, quality across a million tokens is not documented. StepFun publishes no needle-in-a-haystack or long-context retrieval results in the sources I could access. Sparse attention selects 4,096 tokens per query in the full-attention layers, so tasks that need to integrate evidence scattered across hundreds of thousands of tokens are exactly where sparse selection could miss something. Measure retrieval on your own documents at the lengths you intend to use.

Verbosity and cost. At 160 million output tokens for the Artificial Analysis index against a median of 81 million, you should budget for roughly double the output of a typical reasoning model at equal task difficulty. On a self-hosted node this shows up as lower effective throughput, not a bill.

Structured output errors. The 17 percent structured-output error rate in early OpenRouter telemetry is a single-provider, single-day figure. It could reflect launch-week provider issues rather than the model. Still, if you depend on JSON-schema-constrained output, add validation and a retry, or use guided decoding in your own serving stack.

Preview instability. Expect a final checkpoint to follow. Prompt formats, parsers and the reasoning parser may change. A pipeline that hard-codes step5 parser behaviour should be tested against each container update.

Documentation inconsistencies. The video-input mismatch, two default ports, and the benchmark table living only in an image all signal a hurried release. Verify claims against your own tests rather than the README.

Supply-chain hygiene. Community quantisations such as NVFP4 builds posted by individuals are convenient and unvetted. Prefer the official stepfun-ai organisation, verify checksums, and never load unknown custom code with trust_remote_code on a production host without reviewing it. The orchestration containers are also custom builds, so pull them from the official registries named in the README.

Practical Recommendations

Treat Step 5 Preview as a serious candidate for self-hosted agent work, and evaluate it the way you would evaluate any new infrastructure component: on your workload, with your harness, before committing hardware. The vendor numbers establish that it is in the competitive band of open-weight agent models. They do not establish that it wins on your tasks, especially terminal autonomy and strict structured output, where the early signals are mixed.

Start with the hosted API. At $1.00 per million input tokens, $2.70 per million output tokens and $0.05 per million cached tokens (as checked on October 9, 2026, and subject to change), a week of real traffic costs little and tells you about verbosity, tool-call accuracy and latency. Only then decide whether the data-control and customisation benefits of open weights justify a node that costs far more per month than the API would at your volume.

If you do self-host, run FP8, not BF16, and begin with the vendor’s tested topology for your GPUs. Choose TP for latency-sensitive single-user workloads and DEP for high-concurrency throughput, then measure. Keep --max-model-len as low as your use case allows, because the cache budget is what limits concurrency. Align your own multi-agent systems with sound memory management by reading our companion piece on MoE routing and expert capacity, since expert load imbalance affects tail latency in expert-parallel modes.

Checklist before production:

Read the full StepFun Model License 1.0 and get legal sign-off on the commercial condition and attribution clause.
Pin the container tag and parser versions; re-run your regression suite on every update.
Use temperature 1.0, top-p 0.95 and top-k 0 unless your own tests show otherwise.
Validate every structured output and every tool-call argument; add retries.
Measure long-context retrieval at your real context lengths, not at 1M.
Track output tokens per task, since verbosity drives cost and latency.
Run your own agent harness on at least 50 representative tasks against one named alternative.
Verify the video-input claim before building on it.

Frequently Asked Questions

What is Step 5 Preview?

Step 5 Preview is an open-weight sparse mixture-of-experts language model from StepFun with 600 billion total parameters and 27 billion active per token. It has a 1M-token context window, accepts text and images, outputs text, and targets agentic software engineering, long-horizon tool use and professional knowledge work. The weights were announced for release on October 15, 2026, following a hosted preview in September and an OpenRouter listing on October 8, 2026.

Is Step 5 Preview really open source?

It is open weight, not necessarily open source in the OSI sense. The README names the StepFun Model License 1.0, described as Apache-2.0-style with added attribution and commercial-license conditions. The weights, tokenizer, configuration and model-specific code are covered. Because the license has custom conditions, read the full text before commercial use. Training data and training code are not released, so you cannot reproduce the model.

How much GPU memory does Step 5 Preview need?

In FP8 the weights alone are about 600 GB, so the official minimum is one node of four B300 or eight H200 GPUs. BF16 weights are about 1.2 TB and need eight B300 or sixteen H200 GPUs, and the README warns this may not hold a full 1M-token request. KV cache comes on top, and for a single million-token request it can be on the order of 100 GB under illustrative assumptions.

Can I run Step 5 Preview on a single consumer GPU?

No, not at any useful quality. Although only 27B parameters are active per token, every expert must stay in memory because routing is data-dependent, so you still need hundreds of gigabytes for even 4-bit variants. Offloading experts to system RAM is technically possible in some engines but would be very slow, and community reports say 128 GB of shared memory is not enough. Use the hosted API for experiments.

How does Step 5 Preview compare to DeepSeek V4.1 Flash and MiMo-V2.6?

On vendor-reported agent benchmarks it is competitive with open peers such as Kimi K3 and GLM-5.3 on repository repair, and behind Claude Opus 5 and GPT-6 Astra. Artificial Analysis gave it an Intelligence Index of 44, with high token verbosity. A rigorous three-way comparison on identical harnesses does not yet exist, so test on your workload. See our DeepSeek V4.1 Flash and MiMo-V2.6 analyses for their designs.

What is Sparse GQA and why does it matter for a 1M context?

Sparse GQA is StepFun’s sparse full-attention mechanism. An indexer scores blocks of eight keys and each query attends only to the top 4,096 tokens (512 blocks) instead of the whole sequence. Combined with sliding-window layers in a 3:1 ratio, it keeps compute per decoded token bounded and shrinks KV-cache growth, which is what makes a million-token window economically plausible. The trade-off is possible misses when evidence is widely scattered.