Engineering notes · DeepSeek V4.1 Flash on AMD

How ProsGrow Made MI325X Outrun an H200 Reference by 48% on DeepSeek

Four AMD MI325X GPUs reached 492.6 tokens/s/user in median decode interactivity—48.3% above the published four-H200 reference, with one concurrent benchmark session.

· Updated · ProsGrow AI Engineering · 4 min read

DeepSeek median decode interactivity: published four-H200 reference 332.2 versus ProsGrow on four MI325X GPUs 492.6 tokens/s/user, 48.3% higher, one concurrent session.

When someone works with an AI assistant, the pace of the response matters. A faster stream can make it easier to follow an explanation, inspect generated code, or decide what to ask next.

In our October DeepSeek V4.1 Flash study, ProsGrow measured 492.6 tokens/s/user in median decode interactivity on four MI325X GPUs. The matched four-GPU, single-session H200 reference published through InferenceX measured 332.2. Our result was 48.3% higher.

This is a benchmark result under evaluation: the local quality assessment for this configuration remains pending. It provides a reason to evaluate AMD for interactive DeepSeek workloads, with production qualification still to complete.

The numbers behind the headline

MetricPublished H200 referenceProsGrow on MI325XDifference
Median decode interactivity, tokens/s/user332.2492.6+48.3%
Output throughput, tokens/s/GPU37.4542.83+14.4%
At four GPUs and one session, DeepSeek output throughput is 37.45 tokens/s/GPU for the historical H200 reference and 42.83 for ProsGrow MI325X, 14.4% higher.
Four GPUs, one concurrent session. H200 reference: September 21, 2026; ProsGrow local benchmark: October 20. Simulated speculative acceptance; local quality evaluation pending.

DeepSeek V4.1 Flash; four GPUs assigned to the model; one concurrent session. H200 reference: September 21, 2026. ProsGrow measurement: October 20, 2026.

Decode interactivity measures the pace of token generation after a response starts. Output throughput measures output delivered across the benchmark's request window, including pauses between turns. The 48.3% headline therefore describes streaming interactivity, rather than an entire response or business task finishing 48.3% faster.

Both measures improved against the selected reference, by different amounts.

An AMD deployment option worth testing

For teams planning private coding assistants, document tools, or conversational applications, these results broaden the set of infrastructure options worth evaluating. The model, workload, and serving software can materially change the performance available from a GPU deployment.

The commercial opportunity is to choose infrastructure using the experience your application needs. A service optimized for a small number of latency-sensitive sessions may make different choices from one designed for many simultaneous requests.

The single-session result should not be extrapolated across concurrency levels. Our tested eight-session configurations still trailed the corresponding published H200 references. The result supports a targeted deployment decision, rather than a claim that one GPU wins across all workloads.

What ProsGrow changed

We integrated and evaluated improvements in the public vLLM ROCm serving stack that reduce overhead during generation. ProsGrow's work focused on selecting a suitable configuration, checking it against local controls, and measuring it with a recorded agentic workload.

The underlying implementation comes from the upstream vLLM community. Turning that capability into a deployment option requires understanding where it helps, which hardware can support it, and which validation remains outstanding.

That is the work behind the headline: connect a software capability to a specific workload, then measure the result.

Measurement notes

The H200 numbers come from a published InferenceX run, retained as row 442749 in our October 19 snapshot. This is a comparison with a historical reference on a different host and software configuration, not a simultaneous hardware-only test or an updated leaderboard entry.

Our local result uses a one-hour scheduled AgentX run with simulated speculative acceptance. Median decode interactivity follows the archived benchmark's inverse inter-token-latency definition. It should not be substituted for time to first token or end-to-end task latency. There is one formal performance run for this configuration and no confidence interval.

The pending local quality evaluation is a required next step before production qualification. Application-specific correctness, real-verification performance, and target concurrency also need testing.

Evaluate DeepSeek on AMD for your workload

ProsGrow helps teams explore private inference and dedicated AMD GPU deployments. We can start with the prompts and response-time targets that matter to your application, then evaluate a configuration against those requirements.

Discuss an AMD inference evaluation with ProsGrow.