Deployment
Install SGLang
Install SGLang
For all methods and hardware platforms, see the official SGLang installation guide. The two paths below match the Python / Docker toggle in the command panel.Then run the Python output of the command panel below in that environment.
- Python (pip / uv)
- Docker
Command
8000.
The MI355X multi-node strategies Low-Latency, Balanced, and High-Throughput use fixed concurrency presets of 16, 48, and 256, respectively. Pro uses EAGLE/MTP; Pro Official (0813) uses DSpark. Both enable UMBP on prefill by default. The Playground inherits the selected worker, including its speculative decoder and cache settings.
Run these recipes’ Python commands inside the ROCm image shown in the Docker tab, where Aiter is already enabled. Add explicit parser and network-device settings through the Playground’s Parsers and PD Disagg → IB Device controls.
Pick your hardware + recipe to generate the launch command. The three serving strategies cover the common operating points:
- Low-Latency — fastest reply for a single user. Pick for chat.
- Balanced — good speed with several users at once. Use for typical multi-user serving.
- High-Throughput — most tokens per second across many users. Best for batch jobs.
The Flash Vision (Exp) variant runs on a dedicated preview Docker image,
lmsysorg/sglang:dev-dsv4-flash-vision — its support (sgl-project/sglang#37253) has not shipped in a release yet. The command panel’s Docker mode emits that image automatically for Flash Vision cells; see the Flash Vision notes.For a runnable end-to-end example, see the DeepSeek-V4-Flash demo notebook.
Panel controls (top of the command box):
- Python / Docker — bare
sglang serve …for an existing SGLang env, or adocker run … sglang serve …wrap against the per-hardware image from the Install SGLang panel above. - ⧉ Copy — copies the current command (with whichever framing is active) to your clipboard.
- $ cURL — a sample request against
localhost:30000to confirm the server is up. - ⚙ Env — edits the placeholders (
HOST_IP,PORT,HF_TOKEN,NODE_RANK,NODE0_IP) the command and cURL share. Persists in localStorage across cookbooks. - Verified / Not Verified badge — green when the
(hw, variant, quant, strategy, nodes)combo has been run end-to-end on real hardware; yellow when auto-derived from a neighbor and not yet re-checked.
Playground
The Playground is where you experiment with SGLang features beyond the verified matrix. The Deploy panel above only emits combinations the SGLang team has signed off on; the Playground lets you turn on additional knobs on top of whichever cell the Deploy panel is currently showing. The base is read live from your Deploy selection — only your overrides change. The knobs come in two flavors:- Built-in SGLang features — parallelism overrides (TP / CP / DP-Attention — DP-Attention’s value is the DP degree, with
offto disable), MoE backend + EP, reasoning / tool-call parsers, speculative-decoding presets, prefill/decode disaggregation, HiCache tiers, and HiSparse hierarchical sparse attention (decode-role only — the card appears once PD-Disagg mode is set to decode). - DeepSeek-V4 specific features — MegaMoE W4A8 / W4A4 fused kernel (Blackwell only; Hopper SM90 uses a separate all-FP8 MegaMoE path — see Configuration Tips below).
Panel controls reuse Python / Docker · ⧉ Copy · $ cURL · ⚙ Env from the Deploy panel, plus one extra:
- Submit ↗ — opens a pre-filled GitHub issue so you can land your override combo as a new verified cookbook cell. Shown only while the badge says Not Verified; click it once you’ve actually run the command on your hardware and confirmed it works.
Agentic Long-Context Deployment
Agentic workloads, such as coding agents and other multi-turn, tool-using assistants, send long prompts whose prefixes grow and repeat from turn to turn. Serving them well depends on reusing the KV cache across turns, offloading it beyond GPU memory, and keeping each session on the workers that already hold its prefix. This section gives complete launch commands for such deployments, each benchmarked in SemiAnalysis InferenceX and linked to the run that measured it. Pick a hardware platform, checkpoint, deployment shape, concurrency, KV cache offloading mechanism and router to get every process of the deployment as a raw command, one tab per process in launch order.- Router. Each configuration was submitted behind one front door: Dynamo (
dynamo.frontendwithdynamo.sglangworkers) or SGLang (sglang.launch_server, behindsglang_routerwhen there are several workers or DP-attention ranks). - KV offload. Choose among these KV cache offloading mechanisms: none (GPU KV only), HiCache (host DRAM), or a Mooncake store attached through the external linker. The Mooncake option needs an image whose SGLang build includes
--enable-unified-cache-external-linker. - Container image. Run the commands inside the image listed for each configuration. Several are SGLang nightly images, so flag names follow that image.
1. Model Introduction
DeepSeek-V4 is the next-generation Mixture-of-Experts model from DeepSeek, released 2026-04-24 under an MIT License. The 0731 Flash and 0813 Pro refreshes add checkpoints with a bundled DSpark draft head, and the experimental Flash Vision checkpoint builds image understanding on top of the 0731 Flash base:| Variant | Total params | Active (MoE) | Use |
|---|---|---|---|
| DeepSeek-V4-Flash | 284B | 13B | single-node serving on B200 / B300 / GB200 / GB300 / H200 (TP=4); RTX PRO 6000 (TP=2); H100 (TP=8) |
| DeepSeek-V4-Flash-0731 | 304 | 13B | Flash Official (0731), with a bundled DSpark draft head; verified on 8×B200, 4×GB300, and 4×H200 |
| DeepSeek-V4-Flash-Vision-Exp | 305B | 13B | Flash Vision (Exp) — experimental multimodal (image-text-to-text): the 0731 Flash base + vision encoder & aligner; verified on 4×B200 (TP=4), requires the preview build |
| DeepSeek-V4-Pro | 1.6T | 49B | high-capacity: B200 / B300 (TP=8) · GB300 (TP=4) · H200 FP4 (TP=8) · GB200 (2-node, TP=8) · H200 FP8 (2-node, TP=16) · H100 (2-node, TP=16) |
| DeepSeek-V4-Pro-0813 | 1.65T | 49B | Pro Official (0813), with a bundled DSpark draft head; verified on 4×GB300 (TP=4) · B200 / B300 / H200 FP4 (TP=8) · GB200 (2-node, TP=8) · H100 (2-node, TP=16) · MI355X |
*-Base repos ship pure FP8 mixed and are for further pre-training only — not for chat or tool calling.
Highlights: hybrid CSA + HCA attention (~27% inference FLOPs / ~10% KV cache vs DSv3.2 at 1M context), manifold-constrained hyper-connections (mHC), Muon optimizer, 1M-token context (32T+ pre-training tokens), three reasoning modes (Non-think / Think High / Think Max — use ≥ 384K context for Think Max), and a dedicated encoding_dsv4.encode_messages Python encoder + DSML tool-call grammar.
Recommended generation: temperature=1.0, top_p=1.0.
Resources: HuggingFace · Flash Official (0731) · Flash · Flash Vision (Exp) · Pro · Pro Official (0813) · ModelScope · Flash · Pro.
2. Configuration Tips
Concurrency & DeepEP dispatch buffer Must hold:max-running-requests × MTP_draft_tokens ≤ SGLANG_DEEPEP_NUM_MAX_DISPATCH_TOKENS_PER_RANK. Violating it blows DeepEP’s dispatch buffer at steady-state load (deep_ep.cpp:1105). When tuning, move --cuda-graph-max-bs-decode, --max-running-requests, and the env together.
The generator currently picks values on the conservative side (mirroring an internal stress-test matrix). They run safely out of the box but likely leave throughput on the table — please tune them up toward your actual workload’s peak concurrency and report findings back so the defaults can be revised.
Speculative decoding
The original Flash and Pro recipes use EAGLE. Flash Official (0731) and Pro Official (0813) use the bundled DSpark draft head; see DSpark for its launch and tuning notes.
For the original Flash and Pro checkpoints:
low-latency: steps=3, draft-tokens=4 → largest win at bs=1.balanced: steps=1, draft-tokens=2 → gentler MTP, reduces throughput hit at higher batch.high-throughput: MTP disabled — at saturation the verify step costs more than it saves.- MTP runs on the v2 speculative path.
- Docker image — all three cells use
lmsysorg/sglang:dev-v4f-2dgx-v2, a preview build made only for DGX Spark (branchb12x-vision@452239a74f): it bakes in the SM12xb12xMoE (W4A8) and compressed-MLA attention kernels (#34878, #35899, #34018), the Flash Vision model support (#37253), the b12x image-prefill fix that lets Flash Vision serve images on SM12x, the NVFP4 MTP-layer dispatch fix, and the CuTeDSL and NCCL pins the GB10 pair needs. Do not use it on other hardware, and use the panel’s Docker mode — the bare Python command needs theb12xkernel package this image ships. - Run the same command on both Sparks with
--node-rank 0/--node-rank 1and--dist-init-addrpointing at node 0 over the ConnectX-7 link. Thedocker runflags the panel emits (--network host --ulimit memlock=-1:-1 --cap-add IPC_LOCK --device /dev/infiniband) are what let NCCL use RDMA; without them NCCL silently falls back to TCP and decode slows by roughly 40%. - Env knobs in the cells are part of the recipe:
SGLANG_SM120_FLASHMLA_BACKEND=b12xselects the b12x attention path,SGLANG_B12X_MAX_TOKENSmust equal--chunked-prefill-size, andPYTORCH_CUDA_ALLOC_CONF=expandable_segments:Trueavoids unified-memory fragmentation OOMs on GB10. - NVFP4 (
nvidia/DeepSeek-V4-Flash-0731-NVFP4) — only the routed experts are NVFP4; attention, shared experts and the DSpark MTP layer stay in the checkpoint’s native formats. On SM12x that means three extra flags:--moe-runner-backend flashinfer_cutlass(b12x’s MoE is MXFP4-only and trtllm-gen kernels are sm100-only),--speculative-moe-runner-backend b12x(the DSpark draft’s MTP experts are MXFP4 and run on b12x), and--disable-shared-experts-fusion(HashTopK rejects fused shared experts under the cutlass runner). Throughput and DSpark acceptance match the FP4 cell within noise. - Flash Vision — images are served natively on the b12x recipe with the same flags as Flash Official (send
image_urlcontent on/v1/chat/completions, see Vision); text-only requests work unchanged. Expect roughly 15–20% lower text throughput than Flash Official on this checkpoint — its bundled DSpark head accepts fewer drafts (~3.2 vs ~3.9) — with text accuracy intact.
deepseek-ai/DeepSeek-V4-Flash-Vision-Exp is DeepSeek’s first experimental multimodal V4 checkpoint: the 0731 Flash base plus a vision encoder and aligner, served through the same sglang serve flow with OpenAI-style image_url inputs (see Vision below). Select the Flash Vision variant in the Deploy panel for its recipes.
- Preview build required — support lands via sgl-project/sglang#37253 and has not shipped in a release. Docker mode on the Flash Vision cells already emits the preview image
lmsysorg/sglang:dev-dsv4-flash-vision; for a Python environment, install SGLang from that PR’s branch. The DGX Spark Flash Vision cell is the exception: it uses the DGX Spark imagelmsysorg/sglang:dev-v4f-2dgx-v2(see the DGX Spark notes). - Verified matrix — MMMU-Pro via sgl-eval at
temperature 1.0,top-p 0.95,--reasoning-effort max. - Engine auto-configuration — the engine picks the
flashinfer_mxfp4MoE runner and auto-disables shared-experts fusion for this checkpoint (its HashTopK routing rejects fused shared experts); don’t pass--enforce-shared-experts-fusion. - Chunked prefill & radix cache stay enabled — the scheduler keeps image spans consistent automatically: chunked-prefill truncation points are span-aligned (an image span always prefills within a single extend, overshooting the chunk budget by at most one span), and a radix-cache prefix match ending deep inside an image span is re-issued from the span start.
- Speculative decoding — the checkpoint bundles a DSpark head, and the low-latency recipes enable it with
--speculative-algorithm DSPARK(verified with image batches on B200 via the MMMU-Pro round; the other hardware rows are pending verification). The balanced and high-throughput recipes run target-only: they use DP Attention, which DSpark is incompatible with on current releases. As on the 0731/0813 checkpoints, do not pass the EAGLE flags.
--moe-runner-backend flashinfer_mxfp4), the shared expert runs as a separate FP8 MLP on an alternate stream by default. Adding:
Command
moe_ep_size > 1 the flag is rejected at startup, unless the DeepEP/MegaMOE per-rank shared-slot path is in use. Not applicable to Flash Vision (Exp) — the engine auto-disables the fusion on that checkpoint.
Compressed attention state dtype
DeepSeek-V4 uses hybrid compressed attention for long-context efficiency. SGLANG_DSV4_COMPRESS_STATE_DTYPE controls the dtype of the C4 / C128 compressed attention state pools. Supported values are float32 / fp32 (default: float32) and bfloat16 / bf16. For BF16 on the offline compression path:
Command
c4_state and c128_state pool sizes. Keep the default float32 setting for the most conservative behavior.
EPLB + Waterfill (Experimental)
For recorded/static EPLB reproduction, first record an expert-distribution file by following
Capture expert selection distribution in MoE models.
For reproduction runs, use the generated expert_distribution_recorder_*.pt as
the initial expert location. Please checkout to latest main branch for this feature.
For non-PD reproduction, use:
Command
normal mode on the prefill server and
low_latency mode on the decode server. Add the same --init-expert-location
flag to both commands:
Command
--ep-num-redundant-experts and --eplb-algorithm to customize
EPLB placement.
Waterfill also supports MegaMOE. Use --moe-a2a-backend megamoe --enable-waterfill to keep the MegaMOE backend while applying Waterfill to the
fused shared expert slot.
FP4 Indexer (Experimental)
DeepSeek-V4 uses the default indexer path unless --enable-deepseek-v4-fp4-indexer is set. Enable this flag to use the experimental FP4 C4 indexer. This path is intended for decode-heavy long-context workloads where reducing indexer cache bandwidth is beneficial.
On NVIDIA (SM100 / SM120), pair the flag with DeepGEMM FP4 indexer support and the FlashInfer MXFP4 MoE runner:
Command
--moe-runner-backend flashinfer_mxfp4:
Command
nvidia/DeepSeek-V4-Pro-NVFP4 and
nvidia/DeepSeek-V4-Flash-NVFP4 checkpoints
quantize MoE experts to NVFP4 while keeping attention and dense layers in
FP8. The official releases have matching NVFP4 checkpoints at
nvidia/DeepSeek-V4-Flash-0731-NVFP4 and
nvidia/DeepSeek-V4-Pro-0813-NVFP4.
All of them require --moe-runner-backend flashinfer_trtllm_routed which will be automatically selected if not provided.
Command
Command
Mxfp4FlashinferTrtllmMoEMethod path
automatically.
The official (0731 / 0813) NVFP4 checkpoints preserve the bundled DSpark draft
head, so their low-latency recipes use --speculative-algorithm DSPARK instead
of the EAGLE/MTP shape flags — same as the corresponding original-precision
official checkpoints.
Hopper (H100 / H200) note
Two options are available for running DeepSeek-V4 on Hopper:
- Original FP4 checkpoints — run the MoE experts with W4A16 kernels (Marlin or the FlashInfer SM90 CUTLASS runner) as the command generator picks for Hopper cells. With FlashInfer >= 0.6.18 you can instead select the W4A8 path — MXFP4 weights with FP8 activations via FlashInfer’s Humming kernels — by adding
--flashinfer-mxfp4-moe-precision fp8to--moe-runner-backend flashinfer_mxfp4; the low-latency Hopper cells now generate this form. Both work on H100 and H200; FP4 is the only option for H100 (no FP8 path). It is TP-only; on H200 the Pro variant fits on a single 8-GPU node, while H100 Pro needs 2 nodes (TP=16). - Converted FP8 checkpoints (H100 and H200 only) — pre-repackaged FP8 weights at
sgl-project/DeepSeek-V4-Flash-FP8andsgl-project/DeepSeek-V4-Pro-FP8unlock DP-attention + DeepEP and richer parallelism (e.g. Pro TP=16 across 2 nodes).
docker run --privileged --ulimit memlock=-1
(or --device /dev/infiniband:/dev/infiniband --cap-add IPC_LOCK) so mooncake
can discover the IB HCAs; without IB exposure mooncake silently falls back to
TCP, which can lead to garbled KV transfer on large checkpoints.
RTX PRO 6000 (SM120 / Blackwell Desktop) note
RTX PRO 6000 (96 GB) runs Flash only with the FlashInfer MXFP4 MoE runner.
V4-Pro doesn’t fit on 8× 96 GB; the Deploy panel greys out unsupported recipes.
HiCache and MegaMoE are not supported on RTX PRO 6000.
AMD (MI300X / MI355X) note
- Model checkpoints — for correct accuracy, the FP4 model uses the stock
deepseek-ai/DeepSeek-V4-{Flash,Pro}, and the FP8 model uses the repackagedsgl-project/DeepSeek-V4-{Flash,Pro}-FP8. - Supported models — MI300X supports DeepSeek-V4-Flash in FP8; MI355X supports DeepSeek-V4-Flash / Pro in both FP4 and FP8. All recipes run single-node.
- TP / DP setting (MI355X) — both TP=4 and TP=8 are supported. At low concurrency we recommend TP-only; at high concurrency use TP + DP (balanced / high-throughput recipes). The verified MI355X DP recipes additionally set
--attn-dp-size 8 --enable-dp-attention-local-control-broadcast --tokenizer-worker-num 8 --stream-interval 20 --prefill-decode-interval 10. - MTP — speculative decoding on the original Flash / Pro checkpoints, which bundle an MTP head; add
--speculative-algorithm EAGLE --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4. Pro Official (0813) has no MTP head, so these flags do not apply there and the Playground does not offer them. - DSpark (MI355X Pro Official 0813) — the 0813 checkpoint bundles the DSpark draft head, and DSpark is the only speculative algorithm it supports. Enable
--speculative-algorithm DSPARK(low-latency) and see the MI355X agentic recipe for the long-context path. DSpark also runs under PD disaggregation — see the Pro Official pairs in §3.7. - Kernels — uses the Unified KV attention and the flydsl MoE.
- FP4 indexer (MI355X) — FP4 C4 indexer is supported via
--enable-deepseek-v4-fp4-indexeron top of the standard ROCm recipe.
--moe-a2a-backend mori), not DeepEP. Add the flags below on top of the verified recipe when sharding experts across GPUs; set --ep-size to the EP degree (typically the GPU count on one node).
Two optional env vars improve MoRI throughput (both off by default):
Command
- FP4: enable both env vars.
- FP8: use
SGLANG_MORI_RECV_BOUND=1only; omitSGLANG_MORI_DISPATCH_DTYPE=mxfp8.
--moe-a2a-backend deepep for
--moe-a2a-backend megamoe and add the relevant launch settings automatically.
Two variants are exposed:
- W4A8 — default MegaMoE kernel (FP4 weights, FP8 activations).
- W4A4 — adds
--enable-w4a4-mxfp4-megamoeto run the custom W4A4 kernel (FP4 activations). The flag configures the required DeepGEMM settings. Higher throughput with negligible accuracy drop (~89.5 GPQA on Pro).
- The W4A8 / W4A4 variants above are Blackwell-only (B200 / B300 / GB200 / GB300). On Hopper (SM90, H100 / H200) use the all-FP8 MegaMoE path described below instead.
- MegaMoE is only wired into the
high-throughputrecipe on Blackwell (per sgl-project/sglang#26451). The chip is hidden onlow-latencyandbalanced— switch tohigh-throughputto expose it. - When running MegaMoE, don’t set
--moe-runner-backendmanually. - Adjust
SGLANG_OPT_DEEPGEMM_MEGA_MOE_NUM_MAX_TOKENS_PER_RANKbased on your workload and memory usage. Setting higher number of tokens for MegaMoE requires more HBM space (recommended: 8320 for high-throughput).
mega_moe runner for higher long-context / large-decode throughput on
the FP8 checkpoints. Unlike the Blackwell W4A8 / W4A4 variants above, experts
stay in FP8 — keep SGLANG_DSV4_FP4_EXPERTS=0. It requires a sgl-deep-gemm
build with SM90 FP8 MegaMoE support. Please use the latest image for this
feature.
Enable the MegaMoE path with --moe-a2a-backend megamoe
Command
SGLANG_OPT_DEEPGEMM_MEGA_MOE_NUM_MAX_TOKENS_PER_RANK caps the number of tokens
the MegaMoE path processes per rank (i.e. per GPU); the MegaMoE path is only used
for batches at or below this cap. The right value depends on your parallelism /
token-split scheme, and larger values reserve more HBM.
GB300 PD-Disagg cross-pod MNNVL
On some GB300 clusters with cross-pod KV transfer over NVLink, mooncake may
fail with nvlink_transport.cpp:497 Requested address ... not found!. If
this happens, prepend MC_FORCE_MNNVL=1 NCCL_MNNVL_ENABLE=1 NCCL_CUMEM_ENABLE=1
to both prefill and decode sglang serve commands.
3. Advanced Usage
3.1 Reasoning
Enable thedeepseek-v4 reasoning parser (toggle Reasoning Parser in the Parsers card of the Playground above) to separate thinking from the final answer into reasoning_content vs content.
Streaming with Thinking Process (Python)
Streaming with Thinking Process (Python)
Example
Example Output
Example Output
Output
3.2 Tool Calling
Enable thedeepseekv4 tool-call parser (toggle Tool Call Parser in the Parsers card of the Playground above) to surface structured tool calls via message.tool_calls.
Python Example with Thinking Process
Python Example with Thinking Process
Example
Example Output
Example Output
Output
3.3 HiCache (Hierarchical KV Caching)
HiCache enables multi-tier KV cache offloading (GPU → CPU → Storage), significantly expanding effective context capacity for long-context and multi-turn scenarios. Combined with UnifiedRadixTree, it provides intelligent prefix caching across all tiers. To enable HiCache, open the HiCache card in the Playground above and flip Enable:- L2 (GPU + CPU) — leave Storage on
auto(default). Cold KV pages spill to CPU pinned memory only. - L3 (GPU + CPU + Storage) — pick a Storage backend (
file/mooncake/hf3fs/nixl); the Playground emits the canonicalpage_first_directmem-layout +directIO backend +wait_completeprefetch policy, matching the HiCache best-practices recipe.
- L2 (GPU + CPU) — leave Storage on
auto(default). Cold KV pages spill to CPU pinned memory only. UsedirectIO backend +page_first_directorlayer-firstmem-layout. - L3 (GPU + CPU + Storage) — pick a Storage backend (
file); the Playground emits the canonicalpage_first_directmem-layout +directIO backend +wait_completeprefetch policy, matching the HiCache best-practices recipe.
write_through (the upstream default); switch to write_back / write_through_selective to trade durability for write speed when the storage tier is slow.
For more details, see the HiCache documentation. For the alternative that skips the host tier entirely, see §3.8 UMBP — it is a sibling of HiCache, not a storage backend for it, and the two cannot be enabled together.
3.4 DSpark (Speculative Decoding)
Flash Official (0731) and Pro Official (0813) bundle a DSpark draft head indeepseek-ai/DeepSeek-V4-Flash-0731 and deepseek-ai/DeepSeek-V4-Pro-0813. The target and draft weights therefore come from the same checkpoint: enable DSpark with --speculative-algorithm DSPARK and do not set a separate --speculative-draft-model-path.
The experimental Flash Vision checkpoint also bundles a DSpark head, enabled the same way: the Flash Vision low-latency recipes ship with --speculative-algorithm DSPARK (verified with image batches on B200 via the MMMU-Pro round; other hardware rows pending). The balanced and high-throughput Flash Vision recipes stay target-only because they run DP Attention.
Unlike the EAGLE recipes for the original Flash and Pro checkpoints, this recipe omits --speculative-num-steps, --speculative-eagle-topk, and --speculative-num-draft-tokens. SGLang reads the DSpark shape from the checkpoint.
The Pro Official (0813) low-latency speed numbers in the Deploy panel were measured with
SGLANG_SIMULATE_ACC_LEN=4, which pins the DSpark accept length at exactly 4.00. The recipe as shipped earns 4.678 on the same engine, so those rows read slightly conservative. The GSM8K figure for that cell is from the shipped command.Command
--mem-fraction-static 0.90 on this topology to leave enough headroom for the batch-256 verify graph. The first cold start can take 10–15 minutes while FlashInfer autotunes and SGLang captures the draft and verify graphs; later starts reuse the cache. This path is verified end-to-end on 4×GB300 with SGLang v0.5.16.
Tune proposed draft tokens. --speculative-dspark-block-size N asks DSpark to propose N tokens per step; the target verifies a window of N + 1. If the flag is omitted, SGLang reads the value from the checkpoint. Both the 0731 and 0813 checkpoints resolve to five proposed tokens (the startup log reports gamma=5, verify_num_draft_tokens=6), which is the verified default. Use the DSpark Proposed Draft Tokens slider in the Playground to sweep one through five.
Larger blocks can improve decode latency when acceptance stays high, but they also increase verification work and graph memory. Start from the checkpoint default, then sweep downward under the real prompt-length and concurrency distribution. The gain is usually largest for short interactive traffic and narrows as prefill dominates. Track P50/P99 TTFT and TPOT, total throughput, accepted length, GPU memory, and stop rate rather than choosing from acceptance alone.
For every candidate, compare with the same recipe without --speculative-algorithm DSPARK. Restart the server between the DSpark and non-speculative legs, keep the request corpus, sampling, concurrency, and warmup identical, and give each bench_serving leg its own --flush-cache. Leave --speculative-draft-attention-backend unset unless a separate profiling run justifies an override.
DSpark requires pp_size == 1. Selecting a prefill or decode role in the Playground keeps the inherited DSpark flags on both roles; for PD-disaggregated configurations that run DSpark, see the Agentic Long-Context Deployment and the MI355X Pro Official PD pairs. The MI355X Flash Official recipes run target-only, and so do the DP-Attention recipes in the Deploy panel — for DP-Attention configurations that do run DSpark, see the Agentic Long-Context Deployment and the MI355X agentic recipe. If a larger draft block or concurrency causes graph-capture OOM, lower --mem-fraction-static, the draft block size, or the configured maximum running requests, then rerun both performance and accuracy gates.
3.5 Vision (Image Inputs)
The experimentalDeepSeek-V4-Flash-Vision-Exp checkpoint (the Flash Vision variant in the Deploy panel — see the configuration notes) takes images via the OpenAI-compatible image_url content type, as public URLs or base64 data: URIs; text and images mix freely in one message. Vision input works with the same server the Deploy panel produces — no extra model-specific flags needed.
Image Understanding (Python)
Image Understanding (Python)
Example
Example Output
Example Output
Output
3.6 Agentic Long-Context with HiCache DRAM Offload (MI355X FP4, DSpark)
Three commands follow, one per concurrency range. They share the model, parser, attention and DSpark flags, and differ in parallelism, MoE path and host offload:
DeepSeek-V4-Pro-0813 bundles the DSpark head, so
--speculative-draft-model-path is not needed. --speculative-dspark-block-size 6 is the AL-optimal draft length on the committed golden curve (verify window 7). Keep SGLANG_DSV4_UNIFIED_KV_FP8=1 on every command. The first three use --enforce-shared-experts-fusion; the MegaMoE command uses --disable-shared-experts-fusion instead.
Four adjustments are not in the commands below. Add them when they apply:
--cuda-graph-backend-prefill breakableat concurrency 1–4.--enable-prefill-cp --cp-strategy interleave --enable-cp-decode-attn-tpon the TP-only commands at concurrency 16 and above. Prefill context parallelism splits each prompt across all eight ranks (CP size = TP size).SGLANG_DSV4_GROUPED_ASM=1on the TP-only commands at concurrency 16 and above — the kernel needs at least 16 requests per draft token.- At concurrency 384 on the MegaMoE command:
--prefill-decode-interval 20,SGLANG_AMD_FLYDSL_MEGA_MOE_DECODE_MTPR=1024, andAITER_MEGA_FIXED_SLOT_MAX_MTPR=2047.
Command
--hicache-ratio is the host/device token ratio; 1.5 is what stays under a ~2.7 TB host DRAM budget at TP8. The same five flags appear in the two DP commands below.
Command
Command
--chunked-prefill-size is a global budget divided by --attn-dp-size, so 131072 keeps 16384 tokens per rank. --enable-dp-lm-head is required for DSpark under DP attention. Front the DP ranks with sglang_router --policy cache_aware, so a multi-turn session lands on the rank already holding its prefix; above concurrency 160 add --balance-abs-threshold 32. Both apply to the MegaMoE command below as well.
DP8 EP8 MegaMoE, concurrency 128–384:
Command
SGLANG_AMD_USE_FLYDSL_MEGA_MOE, SGLANG_AMD_FLYDSL_MEGA_MOE_MTPR and the MORI symmetric heap; the heap is 16 GiB here rather than 8 GiB because --mem-fraction-static 0.85 leaves more GPU memory free. SGLANG_DP_USE_REDUCE_SCATTER=0 turns off the reduce-scatter path that MegaMoE’s all-to-all replaces. The three SGLANG_AITER_MEGA_* variables and --enable-eplb enable expert-load balancing, recorded during prefill only. SGLANG_EPLB_P2P_BATCH_CHUNK_SIZE=7 keeps each RCCL P2P group under 31 ops during EPLB rebalance.
3.7 PD Disaggregation on MI355X (MORI-IO)
The prefill and decode roles can use any transport the PD Disagg card in the Playground above offers. On MI300X / MI355X that is MORI-IO, Mooncake and NiXL, and all three stay selectable. This section covers MORI-IO only, because it is the transport every AMD recipe in this cookbook was measured with. It is also what the card selects by default on those two platforms, and it is the one transport that is ROCm-only, so the card hides it on the CUDA platforms. The MI355X multi-node recipes start with IB Device → Auto. Select therdma0-7 (all NICs) option in the Playground to add the explicit NIC list. ROCm nodes enumerate their NICs as rdmaN, so the card hides the ConnectX mlx5_* names on AMD platforms. On CUDA platforms it hides the rdmaN list instead.
Both roles need the RDMA NICs passed into the container, so the Docker output adds the fabric flags below on top of the usual ROCm device access from the Install panel. /dev/infiniband covers rdma_cm and the per-NIC uverbs0…uverbs7 nodes, and the memlock/IPC_LOCK pair is what lets MORI-IO pin the buffers it registers with the NICs:
Command
SGLANG_DSV4_DENSE_MXSCALE and SGLANG_ROUTER_P2C_LOAD_METRIC settings. --network host replaces the single-node -p mapping because the two roles run on different hosts.
For the MI355X Pro / Pro Official FP4 presets, High-Throughput sets MORI_IO_QP_MAX_SEND_WR=32767 and MORI_IO_QP_MAX_CQE=32768 on both MORI roles. Low-Latency and Balanced use the transport’s default queue sizes. The send-queue backoff timeout uses MORI’s default of 5 seconds.
Role-based configuration
Select MI355X → Pro Official → FP4 → Multi-Nodes, then a strategy and role. Replace the host and model-path placeholders with your deployment’s values. The Pro Official commands use the kernel and routing settings described below.
These are two separate workers: neither receives
--nnodes 2 or a cross-node TP rendezvous address. Prefill listens on 30000, decode on 30100, and the router on 8000. Other hardware’s Multi-Nodes recipes can still represent a model sharded across nodes.
--cuda-graph-bs-decode covers 1 to --max-running-requests / attn_dp_size: the full value on the TP-only rows and an eighth on the DP8 rows. Each strategy sets both workers’ admission limit and decode’s graph sizes together. The TP-only points use --mem-fraction-static 0.86 and SWA ratio 0.1; the DP8 points use 0.92 and 0.15.
All prefill roles enable UMBP, --optimistic-prefill-attempts 2, and cache reporting. Decode does not use an offload tier. The high-throughput prefill worker uses Aiter MegaMoEv2 with EP8; decode keeps TP MoE. All Pro Official PD workers enable SGLANG_DSV4_UNIFIED_KV_FP8=1. Low-Latency and Balanced also set SGLANG_DSV4_DENSE_MXSCALE=1 on both roles; High-Throughput sets mxscale on decode only. The decode dispatch budget is 64 × (DSpark block size + 1): MORI_MAX_DISPATCH_TOKENS_DECODE=448 at concurrency 16 and 256 at concurrency 48 or 256. The commands below show concurrency 256.
Select Pro to use the original checkpoint’s EAGLE/MTP 3-1-4 head with the same topology and admission limits. Its commands contain no DSpark parameters. In the Playground, Off (greedy) removes speculative decoding. Enabling HiCache automatically turns off Unified Cache External Linker and removes UMBP’s socket configuration and optimistic prefill. Enabling the linker turns HiCache off.
Selecting a TP-only role forces DP-Attention off and greys the control.
--max-running-requests is server-wide and floor-divided by attn_dp_size, so turning DP on would cut the per-rank batch below the captured --cuda-graph-bs-decode values without changing either flag in the command.- CUDA graphs. Prefill runs
--disable-cuda-graph, because the FP4 indexer’s prefill path is not captured. Decode captures--cuda-graph-bs-decode. - Speculative decoding is the same on both. Keep
--speculative-dspark-block-sizeequal on the two roles. The original Flash and Pro checkpoints have no DSpark head and use their MTP head instead:--speculative-algorithm EAGLE --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4.
Command
Command
--ep-size nor --moe-a2a-backend. --moe-a2a-backend names the dispatch path for expert parallelism, so at ep_size 1 there is nothing for it to name, and the MoE runs replicated across TP.
The shared-expert, SGLANG_DP_USE_GATHERV, and SGLANG_DP_USE_REDUCE_SCATTER settings control the all_gatherv / reduce_scatterv path. Shared-expert locality and gatherv default to off; reduce-scatter defaults to on for ROCm. The commands only set the values that differ from those defaults. That is what decode’s TP MoE uses and what prefill’s all-to-all replaces, so leaving them on under EP8 would run both over the same tokens.
The rest of the difference is the prefill-only set already described above: --chunked-prefill-size, --disable-cuda-graph, and the linker flags with --optimistic-prefill-attempts / --enable-cache-report. Decode replaces the first two with --cuda-graph-bs-decode.
On the prefill env:
SGLANG_AMD_USE_FLYDSL_MEGA_MOE=1is required.--moe-a2a-backend megamoealone runs the DeepGEMM MegaMoE path, which has no ROCm kernel. Do not set this variable on decode: the scheduler reads it too, so it also changes how decode schedules batches.SGLANG_AMD_FLYDSL_MEGA_MOE_MTPRmust be at least--chunked-prefill-size / attn_dp_size, here 65536 / 8. Below that SGLang reports no error and runs fused MoE for the extra tokens. 8192 is the default, so the command omits this variable. Set it explicitly if you increase the per-rank chunk size.MORI_SHMEM_HEAP_SIZEsizes the MORI symmetric heap, where MegaMoEv2 allocates its dispatch and combine buffers. It needs about 0.51 GiB per 1024 tokens of MTPR — about 4.2 GiB at 8192 — and the 4 GiB default fails during CUDA graph capture. SGLang allocates the whole heap at the first MegaMoE forward pass, after the KV cache pool, so it consumes the GPU memory--mem-fraction-staticleft free whether MegaMoE fills it or not. 8 GiB fits next to0.92; §3.6 runs at0.85and can afford more.
These recipes leave
MORI_SHMEM_MODE unset and use MORI’s default STATIC_HEAP. The pinned Aiter MegaMoEV2 implementation allocates its buffers through mori_shmem_create_tensor() / shmem_malloc() after SGLang initializes MORI shmem. This requires the symmetric heap; the separate MORI CCO allocator is not used by this implementation. If your launch script exports MORI_SHMEM_MODE=ISOLATION, unset it before launching MegaMoE: its peer-pointer lookup requires the heap mapping. Keep MORI_SHMEM_HEAP_SIZE=8G for the prefill recipe above.SGLANG_DSV4_UNIFIED_KV_FP8=1 at every Pro Official PD concurrency, which splits the unified KV cache pool into an FP8 nope pool and a BF16 rope pool. It requires the unified_kv_triton kernels, which the base cell already selects through SGLANG_HACK_FLASHMLA_BACKEND. The value must match on both roles — the PD handshake compares KV cache layouts and fails if they differ. The DSpark draft worker stays BF16 either way.
Router configuration
Run the two roles on separate nodes with the same transport and IB device, then front them with the router the card prints. On MI355X it is cache-aware:--policy consistent_hashing keeps a conversation on the prefill worker that already holds its prefix, and --balance-abs-threshold 2 / --balance-rel-threshold 1.1 stop that affinity from starving the peer. The TP-only presets keep --decode-policy round_robin. Pro Official’s DP-attention presets (concurrency 192–512, including the High-Throughput preset at 256) instead use:
Router settings
Power-of-two load metric: LeastRequests in the router startup log.
The multi-node router presets retain the default request timeout. The standalone high-throughput Playground preset uses --request-timeout-secs 14400. At high concurrency the prefill role queues many requests. When the default 1800 s passes the router aborts the request, and an abort that lands while MORI is writing KV cache over RDMA leaves the transfer neither finished nor failed: that prefill worker can no longer send KV cache to decode, and you have to restart it.
Additional Pro Official concurrency points
The panel keeps its c16 / c48 / c256 strategy presets. Apply the following overrides to the Multi-Nodes commands to reproduce the optimized recipe’s endpoints. HerecN means a target concurrency of N.
c1 (replaces c4): start from Low-Latency. Keep prefill TP4, set decode to --tp 4, and set --max-running-requests 8 on both roles. Replace decode’s graph list with --cuda-graph-bs-decode 1 2 3 4 5 6 7 8. Keep DSpark block size 6 (7 draft tokens), MORI_MAX_DISPATCH_TOKENS_DECODE=448, and both kernel switches on both roles. The source also sets SGLANG_MLA_HCA_KV_SPLITS=8 on both roles; the FP8 KV path does not read this setting. Keep these 8 server slots and graph sizes when benchmarking with client concurrency 1; do not reduce them to 2 using the strategy presets’ N*2 rule.
c32: start from Low-Latency, keep TP4 → TP8 and block size 6, set both admission limits to 64, and capture decode graph sizes 1–64. Both roles use FP8 KV and mxscale, as at c16 and c48.
c192 / c384 / c512: start from High-Throughput. Keep TP8+DP8+EP8 prefill → TP8+DP8 decode, DSpark block size 3 (4 draft tokens), and decode dispatch budget 256. Set both admission limits to 384 / 768 / 1024 and capture decode graph sizes 1–48 / 1–96 / 1–128, respectively. Keep FP8 KV on both roles, mxscale on decode only, and the power-of-two router settings above. At c384 and c512, add --request-timeout-secs 14400 to the router.
c512 prefill EPLB: additionally set these environment variables on the prefill worker:
Prefill environment
Prefill flags
--expert-balancedness-report-mode with this mode: it can deadlock prefill on the first request. Decode uses TP MoE and receives none of these EPLB settings. EPLB is specific to c512; the c256 panel preset leaves it disabled.
3.8 Unified Cache External Linker (UMBP)
The unified cache external linker is the second way to move KV cache off the GPU. The linker is the SGLang feature, and you enable it with--enable-unified-cache-external-linker. UMBP is one store the linker can use; you select it with --unified-cache-external-linker-backend mori. The Playground card uses the feature name, not the store name.
The linker is an alternative to HiCache, not a tier inside it. HiCache is a hierarchy — GPU, then pinned host memory, then optionally a storage backend. The linker connects the unified radix tree directly to the external store, with no host cache tier in between, so pages load and offload against that store. SGLang rejects the two together, so enabling the Unified Cache External Linker card in the Playground above strips the whole HiCache flag family from the command:
Command
mori is the UMBP pool; mooncake drives the same direct-linker path against a Mooncake store instead.
The linker does not need PD disaggregation. It works in aggregated serving as well, with the PD Disagg card set to Off. The §3.7 pairs use it on their prefill role because that is where the KV is produced, but that is a property of those recipes, not a requirement of the linker. Turn the card on next to any command whose selection satisfies the condition below.
DP Attention is not required. The linker runs under pure TP as well, and the Pro Official low-latency and balanced prefill roles in §3.7 are exactly that shape.
DP Attention does change how much the tier holds, so it is worth understanding before you size one. The linker keys its objects by rank, and MLA KV is replicated across TP. Under pure TP, a TP8 worker therefore opens eight separate keyspaces, and all eight hold copies of the same tokens: the tier stores an eighth of the distinct tokens that its byte budget suggests. At TP4 it stores a quarter. DP Attention collapses the keys onto one shared keyspace, so the whole budget counts. Size the pool for the copies you will actually get, and do not read the byte budget as a distinct-token figure.
Every MI355X Pro / Pro Official multi-node prefill role uses a standalone UMBP tier: a separate umbp_standalone_server process on the prefill node owns the DRAM pool, and the prefill server attaches to it over a Unix socket. Start the tier server first; the 1500 GB DRAM budget below is what the verified runs used:
Command
host memory registered for GPU access before starting prefill. For the pinned ROCm image, the tier binary is /sgl-workspace/mori/python/mori/umbp_standalone_server; include /sgl-workspace/mori/python/mori in LD_LIBRARY_PATH.
If the tier also runs in Docker, pass the ROCm and RDMA devices and hugepage access through to that container and mount -v /tmp/umbp:/tmp/umbp in both containers. The generated Prefill Docker command already includes that socket-directory mount.
The standalone server defaults to unix:///run/umbp/standalone/node0.grpc.sock when neither an address argument nor UMBP_STANDALONE_ADDRESS is supplied (UMBP_NODE_ID replaces node0 when set). SGLang’s client has no default standalone address: set UMBP_STANDALONE_ADDRESS to enable this mode. These commands use an explicit socket under /tmp/umbp so the server and worker share the same path.
UMBP defaults to a 4 GiB DRAM capacity, hugepages disabled, and a 30-second startup wait. This recipe uses 1.5 TB with hugepages enabled and keeps the default startup wait. It also sets UMBP_SSD_ENABLED=0 to disable the SSD tier (whose config default is enabled), and MORI_UMBP_LOG_LEVEL=info to expose the readiness log (the default log level is error).
Then launch the prefill role with the socket in its environment. The Deployment panel and Playground include this address and use the default 30-second startup wait.
Command
