NVIDIA describes co-design across AI infrastructure
NVIDIA’s Nov. 5 developer-blog post describes how it co-designs GPU architecture, interconnects, serving software, CPUs and storage for AI workloads. The post focuses on managing memory and serving performance across those components.

Key takeaways · 4
- 01
Assess NVFP4 where memory footprint and throughput matter: NVIDIA says it reduces model-weight footprint versus FP16 and FP8, and can deliver up to four times FP8 throughput in cited benchmarks.
- 02
Consider spreading model experts across more GPUs: NVIDIA says Wide Expert Parallelism can leave more HBM per GPU for KV cache, larger batches and concurrency.
- 03
Treat KV cache as a resource to place and route across tiers, not only as local GPU memory.
- 04
Read system-performance claims alongside their stated workload and metric: NVIDIA reports different Vera Rubin comparisons for throughput per megawatt and throughput per dollar.
Co-design across the stack
The post, authored by Eduardo Alvarez, Jamie Li and Ronil Prasad, is dated Nov. 5.[1] NVIDIA frames the engineering challenge as co-design across GPU architecture, scale-up interconnect, serving software, CPU and storage.[1] It identifies HBM as the fastest, most expensive and most contested memory tier, shared by model weights and KV cache.[2] The framing matters because a serving system’s usable capacity depends not just on the GPU, but also on how the surrounding system stores and moves context.[1][2]
Precision and parallelism
NVIDIA describes NVFP4 as 4-bit E2M1 values with shared FP8 scaling for each 16-value block and a per-tensor FP32 scale.[1] It says the format cuts model-weight footprint by about 3.5 times versus FP16 and 1.8 times versus FP8, and has become the default precision for several open agentic benchmarks with strict accuracy requirements.[1] NVIDIA also says NVFP4 can deliver up to four times FP8 throughput in cited benchmarks at the same interactivity.[1] Its Wide Expert Parallelism approach spreads experts across eight or more GPUs, which the company says can free HBM for cache and concurrency.[1]
More bandwidth, managed cache
NVIDIA says GPU HBM capacity stayed at 288 GB from GB300 to Rubin while bandwidth rose to 19.2 TB/s.[1] It reports GB200 NVL72’s aggregate NVLink bandwidth at 130 TB/s and says EP32 can deliver up to 1.8 times EP8’s output tokens per second per GPU at 100 tokens per second per user.[1] For KV cache, NVIDIA describes Dynamo’s router as tracking cache-block locations and weighing cached-prefix overlap and worker load when assigning requests.[1] Decode GPUs can then dedicate HBM to cache and batch size rather than holding headroom for bursty prefill, according to the company.[1]
Cache beyond GPU memory
NVIDIA says its KV Cache Runner tracks cache blocks across GPU, pinned CPU and storage tiers, including local SSDs and mounted network filesystems.[1] In a separate design, Dynamo can stage inactive-session cache in Vera CPU memory during tool calls and return it over NVLink-C2C when an agent resumes.[1] NVIDIA also describes CMX as shared context memory with lower cost per bit than HBM, and says Dynamo moves inactive context there and retrieves it before reuse.[2] NVIDIA lists Cloudian, DDN, Dell Technologies and Everpure as CMX partners.[2]
For teams planning AI-serving capacity, NVIDIA’s post argues that performance depends on coordinating precision, interconnect, cache placement and storage—not on GPU specifications alone. The reported gains are tied to particular workloads and metrics, so professionals should compare them against their own latency, accuracy and utilization requirements.
Why it matters
Bring this to your team — one session a day, built for your industry.
kju.ai is built for teams: daily sessions, team analytics, and rollout support for your organization.
For teamsHow this developed
6 November 2026
NVIDIA describes co-design across AI infrastructure