Dataconomy’s claim that AMD’s Instinct MI355X beats Nvidia’s B300 on Kimi K3 inference cost is not supported by the public InferenceX record it cites. As of August 3, SemiAnalysis’s InferenceX performance-per-dollar index lists exactly one Kimi K3 hardware pairing: Nvidia B200 versus Nvidia B300. It does not publish a Kimi K3 MI355X-versus-B300 cost comparison, and its B200/B300 page says no interpolated cost-per-token data is available for the default configuration. The discrepancy is more than a missing chart point. Dataconomy appears to have combined real MI355X results for the older 1-trillion-parameter Kimi K2.5/K2.6/K2.7-Code family with Kimi K3’s new hardware requirements. The resulting headline converts a plausible broader AMD price-performance narrative into a Kimi K3 result that the benchmark’s own public dashboard does not show.
For enterprises deciding whether Kimi K3 can be self-hosted on AMD infrastructure, the meaningful news is narrower but still consequential: AMD has a documented, validated path to load and serve Kimi K3 on an eight-GPU MI355X node. It has not yet released independently comparable K3 throughput or cost-per-token figures against B300.

Infographic compares AMD MI355X and NVIDIA B300 8-GPU nodes running a 1.56TB Kimi K3 model.The Kimi K3 comparison is missing from InferenceX​

SemiAnalysis describes InferenceX as an open-source, continuously updated benchmark whose recipes, run logs, artifacts, and resulting database entries are publicly auditable. Its Kimi K3 landing page lists the model as a 2.8-trillion-parameter workload, but its performance-per-dollar directory identifies only one K3 GPU pair: B200 versus B300.
Opening that K3 comparison reveals an important limitation. The page provides estimated “owning hyperscaler” GPU costs of $1.73 per B200 GPU-hour and $2.26 per B300 GPU-hour, but it supplies no interpolated dollars-per-million-token result for the default K3 FP4 workload. There is no MI355X entry on that page, no AMD-versus-Nvidia K3 comparison, and no disclosed result that could substantiate a claim that MI355X delivered lower K3 token cost than B300.
That is sharply different from the InferenceX page for Kimi K2.5/K2.6/K2.7-Code. There, SemiAnalysis does publish a B300-versus-MI355X comparison. At one 46-token-per-second-per-user operating point, the site estimates $0.19 per million output tokens for B300 and $0.12 for MI355X. At 72 tokens per second per user, the gap narrows to $0.21 versus $0.18. At 97 tokens per second per user, B300 becomes the more cost-efficient option, at $0.23 versus $0.25.
In other words, the older Kimi benchmark does support a qualified conclusion: MI355X can be cheaper for some Kimi K2-class serving targets, while B300 can pull ahead at others. It does not establish a blanket AMD win, and it does not establish any Kimi K3 result.
The $2.50-per-hour MI355X and roughly $6-per-hour B300 figures in the submitted report are also not the economics used by InferenceX’s K2-family comparison. SemiAnalysis uses its own “owning hyperscaler” total-cost model, pegging MI355X at $1.50 per GPU-hour and B300 at $2.26 per GPU-hour in that specific chart. Public cloud pricing is a different measurement with different assumptions around availability, tenancy, region, commitment, networking, and whether a provider sells a single GPU or only an eight-GPU node.

Kimi K3 changes the hardware floor​

Kimi K3 is not simply a somewhat larger Kimi K2. Moonshot AI’s technical report puts the model at 2.8 trillion total parameters, with 104 billion activated per token, native vision support, and a 1-million-token context window. Its released mixed MXFP4 and BF16 checkpoint occupies roughly 1.56 TB before the memory required for serving state, cache, communication buffers, and runtime overhead.
That footprint is why the K3 story is about memory capacity and system topology before it is about chip-level token speed. Nvidia’s B200 carries 180 GB of HBM3E per GPU, putting eight B200s at 1.44 TB—below the K3 checkpoint size. Nvidia’s B300 and AMD’s MI355X each provide 288 GB per GPU, giving an eight-GPU server 2.304 TB of aggregate HBM.
SemiAnalysis has made the same distinction publicly: a single eight-GPU B200 system cannot hold Kimi K3 at FP4, while a B300, GB300 NVL72, or MI355X deployment has the per-GPU memory capacity needed for the model’s practical single-node configurations. vLLM separately says K3 can barely fit in one Nvidia DGX B300 and needs at least 16 B200 or GB200 GPUs on that generation.
This is a material correction to the common shorthand that K3 “requires 288 GB per GPU.” The model requires a cluster-scale memory pool and a viable distributed-inference configuration; it does not run on one 288 GB accelerator. For the practical minimum configurations being discussed, organizations are renting or buying eight MI355X or B300 accelerators at once, not shopping single-GPU hourly prices in isolation.
At the submitted article’s nominal $2.50 per MI355X GPU-hour, an eight-GPU node would be $20 per hour before host CPUs, local storage, networking, management, and any provider markup for the full server. At $6 per B300 GPU-hour, the equivalent eight-GPU node would be $48 per hour. Those figures illustrate why price matters, but they cannot produce a cost-per-token verdict without measured throughput, latency, concurrency, cache behavior, and actual deployment topology.

AMD has validated loading Kimi K3, not benchmarked a K3 win​

AMD’s own July 27 technical article is more precise than the cost-performance claim. It says Kimi K3 can be deployed on eight MI355X GPUs using tensor parallelism across eight accelerators, with the ATOM serving stack and an FP8 latent KV cache. AMD calculates roughly 190.974 GiB of model weights per GPU and approximately 205.401 GiB after adding known state for one 1-million-token sequence. That leaves about 82.6 GiB per GPU before accounting for remaining runtime overhead.
AMD also says it completed a full 1,319-sample GSM8K five-shot correctness validation on the MI355X configuration, using a 16,384-token maximum model length. That is legitimate deployment evidence: the model loads, starts an OpenAI-compatible service, and completes a basic correctness test on AMD’s latest accelerator.
But AMD explicitly excludes the missing metrics from its article. It makes no throughput, time-to-first-token, time-per-output-token, or kernel-efficiency claims. It says K3-specific tuning for tensor-parallel collectives, MXFP4 grouped MoE, Kimi Delta Attention, prefill, decode, and long-context serving will appear in later work.
That omission is understandable. K3 is a complicated mixture-of-experts model, and serving it efficiently requires more than having enough HBM. The workload’s expert routing, long-context cache management, speculative decoding, inter-GPU communication, and framework maturity can change the answer substantially. A system that loads K3 with useful headroom is not automatically the system with the lowest production cost per completed request.
vLLM’s K3 launch coverage shows the same split. The project announced day-one support across Nvidia Hopper and Blackwell platforms plus AMD MI355X, but its published performance headline was for 16 Nvidia GB300 NVL72 GPUs: 118 tokens per second per user without speculative decoding and up to 370 tokens per second with DSpark. It did not publish an equivalent MI355X K3 throughput figure in that announcement.

The useful conclusion for Windows and infrastructure teams​

AMD now has a credible Kimi K3 deployment option for organizations building on ROCm: an eight-MI355X system has the memory capacity to host the 1.56 TB checkpoint, and AMD has documented a working TP8 serving recipe. That is strategically important because it prevents K3’s unusually large checkpoint from becoming a B300-only procurement decision.
The reported MI355X victory on K3 cost, however, should not guide capacity planning. SemiAnalysis’s public K3 data does not show that matchup, does not provide default interpolated cost-per-token results even for its B200/B300 K3 pair, and cannot support a claim about AMD’s K3 token economics. The public result being cited belongs to the smaller Kimi K2.5/K2.6/K2.7-Code model family, where the outcome varies with the operating point.
For now, the defensible procurement position is simple: treat MI355X as a validated Kimi K3 hosting platform, treat B300 as the corresponding Nvidia high-memory option, and demand a reproducible K3 run with matched context length, concurrency, precision, interactivity target, software stack, and full-node price before assigning either vendor a cost-per-token crown.

References​

  1. Primary source: dataconomy.com
    Published: 2026-08-03T08:34:37+00:00
  2. Related coverage: tomsguide.com
  3. Related coverage: tomshardware.com
  4. Related coverage: amd.com
  5. Related coverage: kie.ai
  6. Related coverage: ctxwire.com
  7. Related coverage: axios.com
  8. Related coverage: implicator.ai
  9. Related coverage: todayforai.com
  10. Related coverage: presenc.ai
  11. Related coverage: kimi-ai.chat
  12. Related coverage: amd.com
  13. Related coverage: linkedin.com
  14. Related coverage: blockchain.news
  15. Related coverage: cometapi.com
  16. Related coverage: lightseek.org
  17. Related coverage: runpod.io
  18. Related coverage: tokencost.app
  19. Related coverage: gpufinder.dev
  20. Related coverage: docs.nvidia.com
  21. Related coverage: aiwiki.ai
  22. Related coverage: docs.nvidia.com
  23. Related coverage: cyfuture.ai
  24. Related coverage: computeprices.com
  25. Related coverage: cyfuture.cloud
  26. Related coverage: investor.nvidia.com
  27. Related coverage: oracle.com
  28. Related coverage: nvidianews.nvidia.com
  29. Related coverage: nvidianews.nvidia.com
  30. Related coverage: tomshardware.com