An existing GPU deployment may have more to give. In our October MI300X study, a serving configuration change improved both response starts and output capacity on the same four GPUs, using the same software image.
Average time to first token fell by 47.1%. Output throughput rose by 16.7%. For teams evaluating how much useful work their AMD infrastructure can support, the result offers a concrete reason to examine the serving configuration before planning an expansion.
Less waiting, more output
We compared a local baseline with an updated configuration on four AMD MI300X GPUs, using DeepSeek V4.1 Flash and 32 concurrent trace sessions.
| Metric | Local baseline | Updated configuration | Change |
|---|---|---|---|
| Average time to first token | 1.52 s | 0.80 s | 47.1% lower |
| Output throughput, tokens/s/GPU | 185.5 | 216.5 | 16.7% higher |
| Completed profiling requests | 2,818 | 3,247 | 15.2% more |
ProsGrow local measurements, October 25, 2026. Each run used a one-hour scheduled benchmark window. Percentages are calculated from unrounded measurements.
The reduction in first-token wait means the tested system began delivering responses about 0.71 seconds sooner on average. Higher throughput means it delivered more generated output across the benchmark. The request count provides another view of the same comparison, rather than a separate result or a count of completed business tasks.
Why context reuse matters to an agent service
Many AI applications carry information forward: instructions, retrieved material, or earlier conversation turns. Reusing eligible context can reduce repeated processing as the interaction continues.
Our change allowed the serving stack to make better use of that opportunity. We kept the GPU allocation and software image fixed, then measured the effect of the updated serving configuration. The method is relevant to applications with repeated context, while the size of any benefit depends on their actual traffic.
A fresh, unrelated prompt may behave differently from a long-running agent session. This is why deployment evaluation should include the request patterns the application will serve.
Put existing capacity to work
For an infrastructure team, the practical question is whether a configuration can meet the required response times and traffic level with the available resources. These results identify a useful candidate to test on MI300X.
They do not establish a particular reduction in operating costs or a universal increase in supported users. Those outcomes depend on workload, utilization, hosting price, and quality requirements. The business value of the experiment is that it gives the team a measured improvement to evaluate before making an infrastructure decision.
ProsGrow's role is to make that evaluation concrete: establish a baseline, identify avoidable repeated work, and test a candidate under relevant load. We build on the capabilities of DeepSeek and the open-source serving ecosystem.
Measurement notes
This comparison uses the same MI300X allocation, software image, and speculative-generation settings. Both runs used recorded AgentX traces and simulated speculative acceptance. These are controlled engineering benchmarks, separate from production responses using real verification.
Throughput is measured over the observed request window, including pauses in the trace. Each selected configuration has one formal run and no confidence interval. The figures describe the 32-session operating point; they should not be extrapolated to all traffic levels.
A local MI300X quality evaluation has not yet been completed. Workload-specific quality and real-serving performance checks remain part of production qualification. The figures here use the context-reuse comparison; subsequent experimental settings whose gains still need real-verification testing are excluded.
Explore your AMD deployment's potential
Running private DeepSeek on AMD, or evaluating dedicated GPU capacity? ProsGrow can help test the relationship between response time, throughput, and the infrastructure your workload needs.