Hey fellow llamas. we have something new for Strix Halo owners we thought would be useful to share. i'll keep it short:

We were able to fit DeepSeek V4 Flash plus its speculative draft on a single Ryzen AI MAX+ 395 with 128 GB of unified memory, and got it to a usable decode rate.

Blog post with all details here: https://www.lucebox.com/blog/deepseek-v4-strix-halo (code is open-source, Apache-2.0)

We submitted the run to LocalMaxxing. On July 25th, its next-fastest DeepSeek V4 Flash entry for the Radeon 8060S was HipFire at 18.99 tok/s. The previous best in the site’s Ryzen AI Max 395 unified-memory group was DwarfStar at 15.6 tok/s.

That puts our run 68.5% ahead of HipFire and at 2.05× the DwarfStar result. These are comparisons against the public LocalMaxxing entries shown above, not controlled A/B tests.

ROCmFPX: fitting 284B weights into 128 GB

ROCmFPX is not one quantization format. It is a family of block formats built around the AMD ROCm/HIP path. Each block holds 32 weights as packed low-bit codes plus one or two small scales. ROCmFP2 stores a block in 10 bytes, or 2.50 bits per weight; ROCmFP3 uses 3.50 bits per weight; and the fast ROCmFP4 layout uses 4.25.

For DeepSeek V4 Flash, we added the missing 2-bit format and its HIP kernels, then built a Strix-specific mixed-precision recipe. The enormous routed-expert gate and up matrices use ROCmFP2, expert down projections use ROCmFP3, and dense or more sensitive projections keep ROCmFP4 or higher precision. We used an importance matrix during quantization and kept the model’s MTP head. The final 102.3 GB target works out to roughly 2.88 bits per parameter; the filename says ROCmFP2 because that is the dominant format, not because every tensor is 2-bit.

Piece	Measured configuration
Hardware	Ryzen AI MAX+ 395, Radeon 8060S (gfx1151), 128 GB LPDDR5X
Target	DeepSeek-V4-Flash-ROCMFP2-STRIX.gguf, 102.3 GB
Draft	DeepSeek-V4-Flash-DSpark-draft-Q4RMFP4-denseF16.gguf, 11.3 GB
Runtime	ROCm 7.2.4, HIP gfx1151, platform performance, Radeon high (2.9 GHz observed), q=4 verification cap
Server context	8,192 tokens in the published setup

Decode: up to 32 tok/s

ROCmFPX handles the weight traffic. We then added a DeepSeek-specific HIP decode path for the model’s hyper-connections, attention, routing, and expert work. With no speculative draft, that target runs at 25.31 tok/s autoregressive.

DSpark is the next layer. With a q=4 batch, its small draft proposes up to three new tokens and the 284B target verifies four positions, including the current seed, in one fused pass.

01 · propose; DSpark draft = A compact three-layer draft proposes the next few tokens from captured target features. 02 · verify; q=4 target pass = The 284B target checks several positions together through the fused HIP graph. 03 · commit; accepted prefix = Correct proposals are committed in one step; the target repairs the first miss. 

With a q=4 cap and adaptive width disabled, the public run reached 32.0 tok/s, 26.4% above the 25.31 tok/s autoregressive result. The gain varies with how many draft tokens the target accepts.

Sparse prefill: roughly 250 tok/s

The public LocalMaxxing request reports 245 tok/s prefill with --ds4-prefill sparse. In a separate 7,960-token validation, indexed sparse prefill reached 251.79 tok/s; the 8K cases ranged from 246.8 to 255.9 tok/s. At roughly 24K tokens, throughput was 221.9 tok/s.

Sparse prefill uses DeepSeek V4’s learned indexer to limit compressed-history attention. It also batches work layer by layer, which changes floating-point reduction order. The output is not byte-identical to tokenwise exact prefill, so sparse mode remains opt-in. It scored 10/10 on our small GSM8K set and 3/3 on a HumanEval smoke set; we have not run a broad quality evaluation yet.

Reproducing the run

Starting from a 128 GB Strix Halo machine with ROCm 7.2.4 already installed:

sudo apt-get update sudo apt-get install -y build-essential cmake git ninja-build curl \ hipblas-dev hipcub-dev rocblas-dev rocprim-dev rocwmma-dev git clone --branch main --recurse-submodules \ https://github.com/Luce-Org/lucebox.git cd lucebox cmake -S server -B server/build-hip -G Ninja \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_HIP_COMPILER=/opt/rocm/lib/llvm/bin/clang++ \ -DDFLASH27B_GPU_BACKEND=hip \ -DDFLASH27B_HIP_ARCHITECTURES=gfx1151 \ -DDFLASH27B_HIP_SM80_EQUIV=ON \ -DCMAKE_HIP_FLAGS=-DDFLASH_WAVE_SIZE=32 \ -DGGML_HIP_MMQ_MFMA=ON \ -DGGML_HIP_NO_VMM=ON \ -DGGML_HIP_GRAPHS=OFF cmake --build server/build-hip --target dflash_server -j"$(nproc)" 

Download the ROCmFPX target and DSpark draft, then start the measured profile:

mkdir -p models curl -L -C - --retry 5 \ -o models/DeepSeek-V4-Flash-ROCMFP2-STRIX.gguf \ "https://huggingface.co/Lucebox/DeepSeek-V4-Flash-ROCMFPX/resolve/main/DeepSeek-V4-Flash-ROCMFP2-STRIX.gguf" curl -L -C - --retry 5 \ -o models/DeepSeek-V4-Flash-DSpark-draft-Q4RMFP4-denseF16.gguf \ "https://huggingface.co/Lucebox/DeepSeek-V4-Flash-DSpark-Drafter-GGUF/resolve/main/DeepSeek-V4-Flash-DSpark-draft-Q4RMFP4-denseF16.gguf" MODEL="$PWD/models/DeepSeek-V4-Flash-ROCMFP2-STRIX.gguf" DRAFT="$PWD/models/DeepSeek-V4-Flash-DSpark-draft-Q4RMFP4-denseF16.gguf" echo performance | sudo tee /sys/firmware/acpi/platform_profile sudo /opt/rocm/bin/rocm-smi -d 0 --setperflevel high printf '0\n' > /tmp/ds4_awidth printf '4\n' > /tmp/ds4_spec_q DFLASH_DS4_SPEC=1 \ DFLASH_DS4_FUSED_VERIFY=1 \ DFLASH_DS4_SPEC_Q=4 \ DFLASH_DS4_TIMING=1 \ DFLASH_DS4_DRAFT="$DRAFT" \ LUCE_MMVQ_MAX_NCOLS=4 \ ./server/build-hip/dflash_server "$MODEL" \ --target-device hip:0 \ --host 127.0.0.1 --port 8000 \ --max-ctx 8192 --default-max-tokens 2048 \ --chunk 2048 --ds4-prefill sparse \ --ds4-fused-decode \ --ds4-expert-top-k 4 \ --prefix-cache-slots 0 --prefill-cache-slots 0 \ --disk-prefix-cache off 

Warm the model once and use temperature: 0. The server prints decode speed on its [deepseek4] DSpark decode line. DFLASH_DS4_SPEC_Q=4 sets the DS4 verification cap; --verify-width is a Laguna option and is not used here. The implementation may shorten a batch at a compressor boundary, which is required for correct state handling.

Throughput varies with prompt shape and, for decode, how many DSpark proposals the target accepts. If you switch to exact prefill or restore the model’s six experts, those numbers no longer apply. No integration branch or private patch is required.

-------

Of course any feedback is more than welcome :)