We wanted to see how much we could squeeze out of one GPU. More projects are finding ways to run huge models by keeping some weights in system RAM or on disk, instead of needing enough GPU memory for everything. We wanted to explore that on CDNA4.
We had already done something similar with Qwen3.8 Flash Next on two Radeon AI PRO R9700s, keeping less-used experts in system RAM. This time, we picked a completely different, much heavier model: DeepSeek V4.1 Flash. The hardware limit was one MI350P, backed by a substantial CPU host, not a rack of GPUs.
And we're pretty happy with the results. DeepSeek V4.1 Flash generates 77.9 tokens per second for one request on that single MI350P with Paiton. At 64 concurrent requests, LocalMaxxing records 709.6 tokens/s in total. A separate batch-serving profile reaches 1,107.6 output tokens/s across 512 requests with long answers.
In this article
- Hardware and quantization
- Serving profiles and cache capacity
- Decode speed and prefill
- RTX PRO 6000 comparison
- RTX 5090, RTX 3090 and Mac Studio, plus multi-GPU setups
- Concurrent requests, long inputs and long answers
- Power consumption
- Accuracy and retrieval checks
- Stock vLLM and SGLang attempts
- Weights, source data and recording
- Discuss your token factory
That last number is for batch processing, not responsive chat. Each request generates about 2.3 tokens/s after a median wait of three minutes for its first token. All MI350P measurements use a 450 W GPU power limit and a host that holds about 290 GB of model data. Its CPUs compute the experts that do not fit on the GPU. “One GPU” does not mean the GPU does all the work.
The model is DeepSeek-V4.1-Flash-1017. Its original checkpoint occupies 475 GiB, far beyond this card's 144 GB of HBM. The result comes from changing how the model is stored and executed, rather than fitting the entire original model onto the card.
Paiton is our framework for optimizing AI on AMD hardware. These measurements use its proprietary native CDNA4 runtime, which is not included with the public weights. Downloading the quantization does not provide a working stock-vLLM deployment or everything needed to reproduce these results.
Keeping useful work on the GPU
The original checkpoint contains about 269 GiB of routed experts, 189 GiB of engram lookup tables and 17 GiB of other components. We compress selectively rather than changing every weight.
We keep the most-used experts on the GPU. The 3,000 hottest experts retain their original 4-bit values; the next 2,812 use our 3-bit format, at about 3.3 bits per weight including scales. Another 9,548 experts remain in host memory in their original 4-bit format. A set of 1,024 GPU slots follows the experts used by current requests.
During generation, the host CPUs compute cold experts in place. Only their inputs and outputs cross PCIe, not entire expert weights at each step. For long prompts, the runtime streams cold experts to the GPU instead, where the larger batch makes that worthwhile. The engram tables stay in host memory in a compressed 4-bit row format.
The tested machine has two AMD EPYC 9654 CPUs, with the MI350P connected over PCIe Gen5 x16. Released host profile B uses approximately 287.5 GB for the model, including host experts, compressed engram tables and pinned buffers. That is a model allocation, not a minimum total system-RAM specification: the OS, loading and other processes need headroom too.
Separate engine diagnostics point to CPU computation and host-memory bandwidth as constraints under heavier decode load. Enough RAM alone does not guarantee these speeds. We have not measured another host or a second MI350P.
Two profiles, two different uses
The interactive profile reserves 64 request slots, each configured for up to 70,000 tokens. It uses the model's own speculative drafter for up to 12 running requests: the drafter proposes two tokens, which the main model checks together. We did not record draft acceptance rates for these release runs.
The token-factory profile disables drafting and shortens the per-request limit to 12,288 tokens, leaving room for 512 slots. It favors total completed work over the speed of an individual answer.
Runtime-reported physical KV-cache capacity. Slot budgets are configuration limits, not measured simultaneous full-length conversations.
| Profile | Physical cache, tokens | Request slots | Limit per request | Configured slot budget |
|---|---|---|---|---|
| Interactive | 4,484,095 | 64 | 70,000 | 4,480,000 |
| Token factory | 6,324,224 | 512 | 12,288 | 6,291,456 |
The KV cache holds working state for processed tokens. Neither total is a context window for a single request. We also did not test 64 simultaneous 70K conversations or 512 simultaneous maximum-length requests. Allocating their slots is different from measuring that workload.
Decode speed, without the prompt-processing work
LocalMaxxing measures sustained generation from an empty context, without the prompt-processing work included in a serving test.
Aggregate output tokens/s in LocalMaxxing. One MI350P at a configured 450 W limit; higher is better. These are not end-to-end request rates.
| Concurrent requests | 1 | 2 | 4 | 8 | 16 | 32 | 64 |
|---|---|---|---|---|---|---|---|
| Output tokens/s | 77.9 | 112.7 | 166.9 | 241.4 | 377.9 | 518.4 | 709.6 |
Prompt processing, or prefill, reaches 4,366 input tokens/s for an 8,119-token prompt and 4,227 for a 63,742-token prompt. The measured first-token times are 1.86 seconds and 15.08 seconds, respectively. These are single-prompt tests, not the latency under simultaneous arrivals.
How this compares with an RTX PRO 6000
We keep the original 4-bit values for most routed experts, rather than starting from a 2-bit Q2_K checkpoint. Our custom 3-bit tier compresses a selected group of GPU experts. That distinction matters as much as the tokens-per-second figure: a faster answer is only useful if the model still gives you the answer you need.
The public deepseek-one-gpu results provide a useful single-card reference. They use an RTX PRO 6000 Blackwell with CPU expert offload and a Q2_K checkpoint. Here are the separately reported decode results, not a matched GPU benchmark:
| Paiton / 1 × MI350P | deepseek-one-gpu / 1 × RTX PRO 6000 | |
|---|---|---|
| GPU memory | 144 GB | 96 GB |
| Expert weights | Original FP4 for most experts; custom 3-bit GPU tier | Q2_K checkpoint, described as 2-bit by its authors |
| One request, output tok/s | 77.9 | 63.11 |
| Four requests, total output tok/s | 166.9 | 127.58 |
| Eight requests, total output tok/s | 241.4 | 152.53 |
Paiton reports higher decode rates here while retaining more expert-weight precision. The measurements differ: ours uses LocalMaxxing's empty-context, 30-second cells; the RTX results average three 15-second windows after reading approximately 16K tokens per request. They also use different CPUs, memory capacities and checkpoints. The RTX one- and four-request results use an EPYC 9575F, while its eight-request result uses an EPYC 9655; ours uses two EPYC 9654s. These numbers do not isolate the GPU or quantify a controlled Paiton speedup.
Why we kept more precision
Our served checks measure approximately 0.031 chat KL, 0.042–0.044 long-context KL and 94–95% next-token agreement against the original model. The retrieval checks also recover every tested passphrase. We publish the sample sizes and limitations in the accuracy section below.
The RTX project's quality report measures downstream tasks instead, including GSM8K and HumanEval, against the DeepSeek API. We have not run those same tests for this release, and it does not provide a matching KL measurement. Our selective quantization preserves more original expert-weight precision; a numerical claim that it is more accurate than Q2_K still needs a shared evaluation.
More single-machine results
The same model family also runs on smaller NVIDIA cards and Apple Silicon. These reports make different tradeoffs between expert precision, GPU memory, host RAM and SSD access. Rates below are the authors' measurements, not reruns on our test bench.
| Setup and source | Weights and memory | Reported single-request output | Test context |
|---|---|---|---|
| Paiton / 1 × MI350P | Most experts retain original FP4; selected GPU experts use 3-bit. 144 GB GPU memory, about 290 GB of host model data | 77.9 tok/s | LocalMaxxing, empty starting context, 30-second cells; two EPYC 9654 CPUs compute cold experts |
| RTX 5090 / Project Maya | Maya-S 2–3-bit experts; 32 GB VRAM, 128 GB RAM, NVMe offload | 26.3–26.7 tok/s | Author's October 29 update, Maya 1.1.27, drafting off; Ryzen 9 9950X3D |
| RTX 3090 / dsv41-flash-offload | EXL3 3-bit experts; 24 GB VRAM, measured host with 503 GiB DDR4; Engram on NVMe | 19.3 tok/s | Published D141 default; EPYC 7443P. Also reports 26.6 aggregate tok/s at four streams |
| Mac Studio M3 Ultra / Rapid-MLX | Mixed 2–3-bit routed experts; 256 GB unified memory; 4-bit Engram on SSD | 34.3–42.7 tok/s | Default depth-two drafting, roughly 0.7–1K-token prompts and 256 output tokens; up to 49.0 tok/s on code with depth-four drafting |
Our approach keeps more of the original expert weights intact instead of quantizing all routed experts to 2–3 bits. The smaller-card setups use much less GPU memory, and the RTX 5090 host also has substantially less RAM. Their lower rates are not evidence of an isolated GPU or software disadvantage.
Quality numbers need the same care. Rapid-MLX reports 0.260 KL and 85.1% top-1 agreement on its 19,456-position held-out set, using full-vocabulary KL. Our roughly 0.031 chat KL and 95% agreement come from 1,767 positions with top-64-bucket KL. Those different tests do not establish an accuracy ratio. The RTX 3090 project's 0.0068 KL checks an execution path against the same quantized pack, not quantization loss against the original model.
What changes with more GPUs?
More cards can provide substantially higher speeds, but they solve a different hardware-budget problem. These are total setup results, not per-GPU figures.
| Setup and source | Model placement | Separately reported result |
|---|---|---|
| 2 × RTX PRO 6000 / Diffbot | 192 GB combined VRAM; calibrated EXL3 3-bit routed experts, one third in pinned host RAM | One-stream agentic replay: 224.1 tok/s with GPU expert computation, or 261.8 with the optional CPU runtime |
| 4 × B200 / Lambda | Official checkpoint, vLLM TP4, five speculative tokens | Approximately 8K input / 1K output: 374.8 aggregate output tok/s at one request; 3,713.9 at 64 and 4,858.7 at 256 |
Diffbot's host-resident experts mean its two-card result is not an all-VRAM deployment. Lambda's numbers include prompt processing across 512 prompts per concurrency point, unlike our LocalMaxxing decode matrix. Neither is a matched comparison with our single-card run.
For a latency-sensitive service, the extra GPUs may be worth it. Our result addresses a different question: what can one MI350P do with a capable CPU host, while preserving most original expert-weight precision?
What happens when requests arrive together?
The serving sweep includes both input processing and generation. Here 1K means 1,024 tokens. Requests use distinct source-text windows, greedy generation and fixed output lengths, with EOS ignored. These are concurrent synthetic requests, not a measurement of the same number of people using an assistant.
1K input / 1K output. Total throughput and median decode per request measure different things. First-token times include prompt processing.
| Profile | Requests | Total output, tok/s | Decode per request, tok/s | First token, median / sample p99 |
|---|---|---|---|---|
| Interactive | 1 | 90.7 | 95.4 | 0.69 / 0.77 s |
| Interactive | 4 | 154.3 | 42.4 | 0.80 / 2.87 s |
| Interactive | 16 | 203.8 | 14.4 | 8.91 / 11.42 s |
| Interactive | 64 | 297.2 | 5.2 | 28.25 / 44.64 s |
| Token factory | 256 | 542.8 | 2.6 | 91.56 / 178.51 s |
| Token factory | 384 | 620.8 | 2.1 | 131.76 / 249.57 s |
| Token factory | 512 | 682.5 | 1.7 | 167.90 / 331.24 s |
One request starts answering in under a second. At 16, median first-token time is nearly nine seconds; at 64 it is 28 seconds. The card produces more overall, but each answer slows down. At 512 factory requests, the wait approaches three minutes.
Per-request decode is derived from median time per output token after the first. It is not total throughput divided by concurrency. Sample p99 describes these recorded requests, not a population percentile or a production service-level guarantee. Variable arrivals, prompt lengths, tool calls and scheduling need their own capacity test.
Long inputs are the harder serving workload
An 8K input with a 1K answer spends more of its time processing prompts. At 64 requests, the interactive median wait reaches 70.45 seconds. At 512 factory requests it is 586.39 seconds, nearly 9.8 minutes, with a sample p99 of about 19.9 minutes.
8K input / 1K output. The longer prompt raises first-token latency substantially, particularly in the batch profile.
| Profile | Requests | Total output, tok/s | Decode per request, tok/s | Median first token |
|---|---|---|---|---|
| Interactive | 1 | 79.5 | 95.2 | 1.83 s |
| Interactive | 4 | 129.8 | 39.9 | 3.87 s |
| Interactive | 16 | 151.1 | 12.1 | 17.09 s |
| Interactive | 64 | 201.6 | 4.0 | 70.45 s |
| Token factory | 256 | 299.1 | 1.8 | 285.42 s |
| Token factory | 384 | 317.8 | 1.3 | 434.14 s |
| Token factory | 512 | 328.9 | 1.1 | 586.39 s |
Single-prompt prefill cannot predict latency for a queue of long documents. This batch profile does not suit someone waiting for an immediate reply.
Long answers improve total throughput
With 1K input and 8K output, prompt processing is spread across much more generated text. The factory reaches 1,107.6 tokens/s at 512 requests, compared with 682.5 for short answers. Individual generation still runs at only 2.3 tokens/s, after a median first-token wait of 180.84 seconds.
1K input / 8K output. More total output does not make each batch request interactive.
| Profile | Requests | Total output, tok/s | Decode per request, tok/s | Median first token |
|---|---|---|---|---|
| Interactive | 1 | 109.0 | 120.0 | 0.72 s |
| Interactive | 4 | 199.3 | 52.3 | 2.99 s |
| Interactive | 16 | 243.6 | 15.4 | 11.02 s |
| Interactive | 64 | 370.5 | 5.9 | 29.09 s |
| Token factory | 256 | 813.2 | 3.3 | 92.90 s |
| Token factory | 384 | 953.4 | 2.6 | 138.96 s |
| Token factory | 512 | 1,107.6 | 2.3 | 180.84 s |
Offline summaries, evaluations and data generation can tolerate that tradeoff. An interactive coding assistant generally cannot. The useful operating point depends on the output length and acceptable wait, not just the largest throughput number.
Power: the limit is not the consumption
The 450 W setting is a GPU power limit, not a claim that the GPU constantly draws 450 W. At 512 factory requests, mean GPU power is 212.5 W for 1K / 1K and 214.7 W for 1K / 8K. Combining those readings with output gives approximately 0.086 and 0.054 Wh per 1,000 output tokens, respectively.
The long-input factory cell draws more, 273.4 W on average at 512 requests, while producing less output. Interactive 1K / 1K cells average 251.8 W at one request and 207.6 W at 64. More batching can improve GPU energy per token even when individual responses slow down.
These figures cover GPU board energy only. They exclude the two CPUs computing offloaded experts, system RAM, storage, power-supply losses and cooling. Without whole-server power measurements, they cannot establish total energy cost or a financial return.
How close are the predictions to the original?
We compare teacher-forced next-token distributions against the original model on two MI355X GPUs. KL divergence measures the difference between distributions; zero means identical. The diagnostic groups the reference's top 64 tokens and remaining probability mass. Top-1 agreement asks whether both setups pick the same most-likely next token.
Served next-token checks at eight concurrent requests, except the explicitly labelled 512-request chat check. These are not downstream answer-accuracy scores.
| Profile / check | Chat KL | Chat top-1 | Long-context KL | Long-context top-1 |
|---|---|---|---|---|
| Interactive, c8 | 0.0307 | 95.0% | 0.0438 | 94.2% |
| Token factory, c8 | 0.0311 | 94.5% | 0.0418 | 94.2% |
| Token factory, c512 | 0.0306 | 94.5% | Not measured | Not measured |
Chat covers 1,767 scored positions. The long-context check covers 1,000 positions across 40 conversations. The profile names describe server configurations, not evidence that every accuracy test ran at 64 or 512 requests. A 95% token agreement does not mean 95% of answers are correct. We did not benchmark math, coding, knowledge, multilingual or tool-use tasks for this release.
Repeated runs also differ slightly because of arithmetic and discrete expert routing. Published interactive noise checks give KL of 0.0039 for chat and 0.0033 for long context, but used an older 16K prefill chunk rather than the released 8K chunk. Factory repeats give 0.0006 and 0.0086. Those help interpret the diagnostic; they are not a matching release-build control for every row.
There is an important limit to the long-context result. Our internal gate is 0.045 KL. The measured 1,000-position served checks fall below it. On a larger 171,200-position set, the model card reports 0.0444 from an arithmetic emulator and projects about 0.0456 when served, slightly above the gate. That is a projection, not a full-set measurement of the running server. Raw full-set emulator results are not in the public proof.
Retrieval checks found all 12 hidden passphrases in interactive prompts up to 68,160 tokens, and all six factory passphrases up to 11,033 tokens. That supports this narrow retrieval test, not general long-document accuracy.
What happened with stock engines?
Our published stock-attempt summary covers the original checkpoint on the same MI350P host. vLLM 0.33.0 eventually answers tiny prompts on its reference MoE path at about 0.2 tokens/s, after 35 to 47 minutes of loading. A 1,024-token prompt then runs out of GPU memory. The tested fast MoE paths also fail to fit; SGLang 0.5.23 and the tested ROCm preview run out of memory while loading.
These attempts did not produce a usable stock-serving baseline for this card. They are not proof that every possible configuration fails. The public stock evidence contains a summary, OOM excerpts and a small request record, not complete commands, full container digests and memory traces for every attempt.
Inspect the measurements
The public weights and model card are pinned to revision 2dd8058e. The derivative files use the MIT license, as does the original model. This is a 135.8 GiB patch, not a standalone model: the runtime also needs the original 475 GiB checkpoint. Stock engines cannot directly load our 3-bit expert format and placement map.
The proof directory includes LocalMaxxing matrices, per-request serving records, power logs, accuracy checks and the original terminal recording. We checked 68 proof files against its SHA-256 manifest. That confirms file integrity, not independent validation of the experiment. Public logs support inspection, but the proprietary runtime and missing evaluation artifacts prevent complete independent reproduction.
Unaltered benchmark screenshot. The original animated terminal recording shows a separate live run, not the selected headline matrix.
LocalMaxxing uses lmx 0.1.54 and llm-inference-bench 0.7.7, with 30-second decode cells. We ran three complete matrices on the warm server and selected the whole run with median single-request decode. The serving sweep uses a separate streaming client and two warm-up rounds. Chart data and source paths keep the tests separate.
Our previous MI350P article covers Qwen3.8 Flash Next with much less host computation. The Radeon RDNA4 work explores a different model and memory budget. Both follow the same Paiton approach: choose the storage format and execution path together, then measure the result on the target hardware.
For DeepSeek, this release makes a large model usable with one MI350P and a substantial CPU host. It does not replace the latency of an all-GPU deployment. The next useful checks are whole-host energy, task quality and a measured two-card configuration.
Learn more about Paiton or inspect the linked evidence before choosing a serving profile.
Cover: AI-generated editorial illustration, not a product photograph or benchmark capture.
Building a token factory on AMD?
If you are planning batch inference or already serving models on AMD hardware, we can help work through throughput, latency and memory constraints with your workload.