THE AGENT SIGNALdaily · 23 lanes
  1. Home
  2. NVIDIA Training
  3. Sep 6, 2026

NVIDIA Training · AI Newsletter

Marvell Raised Its Outlook but Fell as Google Chip Revenue Stayed Distant. Has the AI Payoff Been Priced In? (Ready for review)

Audio edition · 15.3 min

The Hook

This is THE AGENT SIGNAL — NVIDIA Training edition: the hands-on skills newsletter for engineers learning NVIDIA's AI stack from the ground up.

Today's session is motivated by a market signal every GPU learner should understand: Marvell beat earnings and still dropped, as Wall Street priced in doubt about custom-chip revenue timelines. That tension — custom silicon vs. the NVIDIA standard — is exactly why mastering TensorRT and CUDA inference optimization is a durable career bet. Let's build.

The Signal

1. Marvell's Chip Signal — What It Means for GPU Learners

Marvell Technology raised its revenue outlook, beat Wall Street estimates, and its stock dropped anyway. The culprit: Google's custom AI chip revenue — Marvell is a key supplier for Google's tensor-processing infrastructure — hasn't materialized on Marvell's books at the pace investors modeled. The result is a market sending a clear message: custom silicon timelines are longer and harder than the hype suggests. For engineers learning NVIDIA's stack, this is actually reinforcing news. When hyperscalers build custom ASICs, the gap between 'announced' and 'production-ready' routinely stretches for years. During that window — and often long after — NVIDIA GPUs remain the dominant inference platform. The practical takeaway: every hour invested in CUDA kernel optimization, TensorRT deployment, and multi-GPU scaling is an hour invested in a skill set with durable, compounding demand.

2. PyTorch CI Update — What's Shipping in the Trunk

A CI/CD merge into the PyTorch trunk landed this week (ciflow/trunk/195929), keeping the framework's nightly build pipeline current. This is the scaffolding beneath every NVIDIA GPU workflow — PyTorch's CUDA backend, its ATen kernel dispatch, and its eager vs. compiled execution paths all flow through this pipeline. The practical signal for learners: PyTorch trunk moves fast. If you're running custom CUDA extensions or Triton kernels, pin to a stable release branch rather than tracking nightly unless you're specifically testing new features. The nightly is for contributors, not for production inference.

3. Xenon's Epilepsy Trial — GPU-Accelerated Drug Discovery

Xenon Pharmaceuticals is heading to European regulators with pivotal data for its epilepsy treatment. The GPU angle: drug discovery is one of the fastest-growing workloads on NVIDIA H100 and GH200 clusters — molecular dynamics simulations, protein folding inference, and genomic sequencing all map naturally to GPU parallelism. AlphaFold2 required massive specialized compute to run.; its successors and the entire downstream therapeutic pipeline run on NVIDIA hardware. If you're considering where to specialize your inference optimization skills beyond the obvious web-serving workloads, biotech AI pipelines are a high-value and underserved target.

4. Sports Analytics — The Unexpected GPU Workload

Premier League match analytics — the kind running behind Everton vs Manchester United this weekend — are built on GPU-accelerated infrastructure. Player pose estimation, real-time ball tracking, crowd analytics, and coach decision-support tools all run TensorRT-optimized computer vision models at real-time frame rates under broadcast deadlines. Sports AI has become a significant industry driven by high-performance inference hardware. The GPU skills you're building in this newsletter apply directly to this domain — and the latency requirements are among the most demanding in production AI.

5. Rate Risk and AI Infrastructure Capex

The BND vs BSV bond spread debate — whether longer-duration Treasuries now justify the extra rate risk — has a direct read-across for AI infrastructure investment cycles. Higher rates make the discounted cash flows from GPU infrastructure harder to justify on spreadsheets, which is exactly why hyperscalers are scrutinizing custom silicon ROI so carefully right now. Understanding the macro forces that govern GPU capex cycles helps you read the industry's hiring and investment signals more accurately — which is practical career intelligence, not just market commentary.

6. Nasdaq Income Funds and the AI Infrastructure Bet

The QQQ vs JEPQ debate is ultimately a bet on how much of the Nasdaq's future return comes from AI capex. The fund story is a proxy signal: institutional money remains long on AI infrastructure, but options-overlay income strategies reflect hedging against a plateau. The meta-lesson is the same as the Marvell story — the expectation of AI returns is already priced in, which means differentiated technical skills matter more, not less, for engineers who want to stay on the right side of the demand curve.

7. pysnmp-pyasn1 2.0.0 — Network Monitoring for GPU Clusters

A new release of the pysnmp-pyasn1 ASN.1 codec library landed on PyPI this week. Niche, but operationally relevant: SNMP-based network monitoring is the standard protocol for tracking GPU cluster health, switch fabric utilization, and NVLink and InfiniBand bandwidth on multi-node DGX systems. If you're managing a GPU fleet in production, SNMP telemetry feeds your observability stack. Knowing how these tools work at the protocol level is an underrated infrastructure skill for anyone running multi-GPU training or inference clusters.

Quick Hits

  • PyTorch trunk: ciflow/trunk/195929 merged — pin custom CUDA extensions to a stable release, not the nightly build.
  • Xenon to Europe: Pivotal epilepsy trial heads to the EMA — GPU-accelerated drug discovery is producing real regulatory outcomes on H100 clusters.
  • Sports AI: Broadcast sports analytics increasingly run optimized inference pipelines at real-time frame rates. — your GPU skills have a larger addressable market than you think.
  • Cluster monitoring: pysnmp-pyasn1 2.0.0 released — the right tool for tracking GPU cluster health and InfiniBand switch utilization at the protocol level.

The Cold Open

Picture a room full of chip designers at a hyperscaler — Google, Amazon, Microsoft — each betting billions that their custom silicon will displace the GPU in AI inference workloads. The announcements have been loud. The timelines, quietly, keep slipping.

Meanwhile, the engineers who know how to squeeze the last ten percent of throughput out of an NVIDIA H100 cluster are being hired faster than they can be trained. The gap between what the market expects from custom chips and what actually ships in production is exactly the gap your skills are designed to fill.

Today's session is about closing that gap — one calibration run at a time. Welcome in.

The Anchor

Marvell's Miss and the Custom Silicon Illusion

Marvell Technology's latest quarter should have been a celebration. Revenue beat consensus, guidance came in above expectations, and the company's AI networking and custom ASIC pipeline looked healthy on paper. Instead, the stock fell — and the reason matters for everyone tracking AI infrastructure.

The drag came from Google's custom chip revenue. Marvell is a key supplier for Google's tensor-processing infrastructure, but the ramp in actual revenue from those custom chip programs has lagged the ambitious timelines both companies telegraphed to investors. Analysts had priced in a steeper revenue curve. When it didn't materialize, the market repriced the stock downward despite the earnings beat.

This dynamic — beat the number, miss the narrative — is the defining tension of the AI chip market right now. Investors priced in an acceleration that hasn't arrived at the pace they modeled. The gap between a chip tape-out, production qualification, customer integration, and actual revenue generation can easily span two to three years for custom silicon programs. Google's custom accelerator and processor programs have produced real, capable chips. — but the revenue ramp for suppliers like Marvell is nonlinear and longer-tailed than the hype cycle suggested.

For engineers learning NVIDIA's stack, the read-across is direct. NVIDIA's advantage isn't just raw compute performance — it's ecosystem depth: CUDA, cuDNN, TensorRT, NVLink, the entire software layer that makes an H100 cluster actually work in production. Custom ASICs, however well-designed, require rebuilding that software ecosystem from scratch or adapting frameworks that were written to target CUDA. That work takes years and requires enormous engineering investment.

The career implication is concrete: the engineers who understand NVIDIA's inference stack deeply — who can profile a model in Nsight, build a calibrated TensorRT engine, and tune multi-GPU communication patterns — are filling exactly the gap that custom silicon ambition creates but cannot yet close. Marvell's stock drop is a market signal. Your training is the hedge against it.

Deep Dive

How TensorRT INT8 Quantization Actually Works

Quantization is the process of reducing a neural network's numerical precision — typically from 32-bit floating point (FP32) to 8-bit integers (INT8) — to achieve faster inference with less memory bandwidth. TensorRT ships with a calibration-based INT8 quantization pipeline that is more sophisticated than most tutorials describe. Here is the mechanism.

The Core Problem: Range Mapping

A floating-point weight or activation can take any value across a continuous range. An INT8 value can only represent a limited number of discrete levels compared to higher-precision formats. The quantization problem is: how do you map the continuous FP32 range to 256 buckets without destroying model accuracy? Naive approach: find the min and max of every tensor and divide evenly. This works poorly in practice because neural network activations often have heavy-tailed distributions — most values cluster near zero, but a few outliers extend far. A linear mapping from min to max wastes most of your 256 buckets on the outlier tail.

TensorRT's Calibration Approach: KL Divergence Minimization

TensorRT solves this with calibration. You provide a representative dataset of real production inputs — enough to capture the distribution your model will actually see., run a forward pass, and collect activation histograms at every quantizable layer. TensorRT then searches for a clipping threshold T: it clips the activation range to [−T, +T] and maps that to [−127, +127], discarding the outlier tail. The threshold T is chosen to minimize the KL divergence — the information loss — between the original FP32 distribution and the quantized INT8 approximation. This is the calibration step that makes TensorRT INT8 more accurate than symmetric min-max quantization.

Per-Channel Quantization for Weights

For weights, TensorRT uses per-channel quantization: each output channel of a convolutional layer gets its own scale factor. This matters because different channels can have very different value ranges. Per-channel quantization preserves far more information than a single scale applied to the entire weight tensor.

The Speed Mechanism: INT8 Tensor Cores

On Turing (T4), Ampere (A100), and Hopper (H100) GPUs, NVIDIA's Tensor cores support INT8 matrix multiply operations natively. These run at significantly higher throughput than FP16 on the same silicon., because you are moving half the bytes through memory bandwidth and the integer multiply-accumulate is cheaper in transistor area. The result: A well-calibrated INT8 TensorRT engine typically achieves substantially higher throughput than an FP32 engine for the same model, with minimal accuracy loss on most tasks.

Where It Goes Wrong

Quantization accuracy degrades when: (1) the calibration dataset does not represent your production inputs — the histograms will be wrong; (2) the model uses operations TensorRT cannot fuse, causing layers to fall back to FP32; or (3) the first and last layers of the network are sensitive to precision loss — TensorRT's layer-wise precision setting lets you keep those in FP16 even inside an otherwise INT8 engine. The hands-on exercise today walks through all three checks.

One Technique

Calibrate and Benchmark an INT8 TensorRT Engine in Under 10 Minutes

This is the hands-on skill for today. You will export a model, run TensorRT calibration, and verify your throughput gain with a clear success check.

Prerequisites: TensorRT 8.x or later with trtexec on your PATH (available inside the NVIDIA TensorRT Docker container). An ONNX export of any classification model — ResNet-50 from torchvision works perfectly as a test case.

Step 1 — Export to ONNX:

import torch, torchvision
model = torchvision.models.resnet50(weights='IMAGENET1K_V1').eval()
dummy = torch.randn(1, 3, 224, 224)
torch.onnx.export(
    model, dummy, 'resnet50.onnx',
    input_names=['input'], output_names=['output'],
    dynamic_axes={'input': {0: 'batch'}, 'output': {0: 'batch'}}
)

Step 2 — Build the INT8 engine:

trtexec --onnx=resnet50.onnx \
  --int8 \
  --calib=calibration_cache.bin \
  --saveEngine=resnet50_int8.engine \
  --best \
  --workspace=2048

The --best flag tells TensorRT to profile all available CUDA kernel implementations for your specific GPU and batch size, then select the fastest. Build time is longer for large models, but you do it once and cache the result. The --workspace flag sets scratch memory in MB during optimization.

Step 3 — Benchmark and verify:

trtexec --loadEngine=resnet50_int8.engine \
  --batch=32 \
  --iterations=100 \
  --percentile=99

Success check: Compare Throughput (images/sec) and Latency 99th pct against your FP32 baseline. A well-calibrated INT8 engine on an A100 or H100 should show significant throughput improvement. If your gain is below 1.5x, add --verbose and look for layers that fell back to FP32 — those are your calibration gaps.

One Prompt

Use this with Claude or any frontier model before running your quantization workflow:

I have a neural network model running in TensorRT FP32 mode on an NVIDIA [GPU model].
I want to convert it to INT8 with minimal accuracy loss.
The model architecture is [describe it: e.g. ResNet-50 classification / BERT-base NLP / YOLOv8 detection].
My production inputs are [describe your data distribution].

Please walk me through:
1. How to select and prepare a calibration dataset representative of my production traffic
2. Which layers are most likely to be sensitive to INT8 quantization in this architecture
3. How to verify the accuracy delta before deploying the INT8 engine to production
4. The trtexec flags I should use for this specific use case

Be specific about thresholds, dataset sizes, and how to interpret the calibration cache output.

The more specific you are about your GPU model, architecture, and production data distribution, the more targeted and actionable the calibration guidance will be.

One Tip

Build once with --best, then always load from cache.

When you build a TensorRT engine for the first time, always include the --best flag (or BuilderFlag.kPREFER_PRECISION_CONSTRAINTS in the Python API). This tells TensorRT to profile every available CUDA kernel implementation for each layer on your specific GPU and batch size, then select the fastest one. The build takes longer for a large model, sometimes considerably so. — but you do it exactly once. Serialize the result with --saveEngine and reload it in microseconds on every subsequent inference call. Never rebuild engines in a production inference path. If your GPU model or target batch size changes, rebuild once and re-cache. Engine files are not portable across GPU architectures.

Tool of the Day

NVIDIA Nsight Systems

What it is: A system-wide GPU performance profiler that captures a unified timeline of CPU activity, CUDA kernel execution, memory copies (host-to-device and device-to-host), NVTX annotations, and synchronization events. It is the tool you reach for when your GPU is not performing as fast as you expect and you do not yet know why.

What it is genuinely good for: Identifying GPU idle gaps between kernel launches where the CPU has not yet issued the next work unit; catching unnecessary host-device memory copies; spotting synchronization bottlenecks in multi-stream pipelines; and confirming that your TensorRT engine is actually keeping the Tensor cores busy.

How to start:

nsys profile --trace=cuda,nvtx python your_inference_script.py

This generates a .nsys-rep file you open in the Nsight Systems GUI. Look for wide blue gaps between green kernel bars — those gaps are GPU idle time and are your first optimization targets.

Honest limits: The GUI takes practice to read fluently. Start with a short trace on a simple model before profiling a production workload. Nsight Systems gives you the 'what and when' of execution; for 'why a specific kernel is slow internally,' you need Nsight Compute, which goes one level deeper into kernel-level metrics.

Signature Bites

  • Custom silicon timelines regularly slip by years. NVIDIA's software moat is why GPU inference skills have durable career value — the ecosystem takes a decade to rebuild from scratch.
  • TensorRT INT8 delivers substantial throughput gains. Not magic — INT8 Tensor cores running IMMA instructions and half the memory bandwidth of FP32.
  • Calibration dataset quality determines INT8 accuracy. A small set of representative production samples beats a large pool of random ones every time. — distribution match is everything.
  • Build once, cache always. A serialized TensorRT engine loads in microseconds. Rebuilding in the inference path is always a bug.

Joke of the Day

Why did the GPU engineer get promoted?

Because they were the only one on the team who could distinguish between 'our model is slow' and 'our CPU has been holding the GPU hostage for 40 milliseconds per batch while it prepares the next input.'

Fact of the Day

NVIDIA's CUDA platform was designed for scientific computing and graphics, not machine learning. The fact that PyTorch, TensorRT, and nearly every major deep learning framework targets CUDA as its primary backend is an accident of timing: CUDA was simply the most mature programmable GPU compute platform when deep learning took off around 2012. That twenty-year head start is the moat that every custom silicon program is spending billions to bridge.

Stat That Matters

The throughput improvement TensorRT INT8 delivers over FP32 inference on NVIDIA Hopper (H100) hardware is substantial, with minimal accuracy loss on most classification and language tasks when calibration is performed correctly. The number matters because it effectively doubles your inference capacity without purchasing new hardware — making quantization one of the highest return-on-investment optimizations available to an inference engineer operating within a fixed GPU budget.

Bold Prediction

The prediction: By Q2 2027, at least one major hyperscaler will publicly acknowledge that their custom AI ASIC program has missed its originally announced production deployment timeline by more than 18 months — and will cite software ecosystem gaps, not silicon performance, as the primary reason. This will accelerate, not reduce, demand for engineers who understand NVIDIA's full inference stack.

Falsifiable check: Track public statements from Google, Amazon, and Microsoft on TPU v5, Trainium 2, and Maia production deployment milestones against their 2025 announcements. If all three hit within 6 months of their announced schedules, this prediction is wrong.

Paper Watch

SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models

MIT and NVIDIA, NeurIPS 2023

This paper solved one of the core blockers for INT8 quantization of transformer-based LLMs: the outlier activation problem. In large language models, certain activation channels contain values far larger than the mean. — a distribution property that causes naive INT8 quantization to destroy model accuracy at scale.

SmoothQuant's solution is mathematically elegant: rather than trying to quantize the activations directly, it migrates the quantization difficulty from activations to weights by applying a per-channel smoothing transformation. The transformation is mathematically equivalent — the model's outputs are identical — but the resulting activations are much easier to quantize accurately. The weights absorb the scaling, and their quantization is handled per-channel where the method is already robust.

The result is LLM inference at INT8 precision with minimal accuracy loss on standard benchmarks. The technique has seen broad adoption in production LLM inference stacks. If you are quantizing transformer models rather than CNNs, this paper explains the mechanism your toolchain is running under the hood — and why the results are better than you might expect from naive quantization theory.

Founder Spotlight

Jensen Huang's Software-First Infrastructure Play

The Marvell story this week is partly a story about Jensen Huang's most underappreciated strategic move: making CUDA the tax that every AI company pays. While Marvell and its hyperscaler customers debate custom silicon timelines, NVIDIA's software layer — CUDA, cuDNN, TensorRT, NVLink, NIM microservices — is quietly becoming the de-facto standard for production AI inference across every industry vertical.

Jensen's bet was never purely about faster chips. It was about making the software ecosystem so deep, so embedded, and so well-documented that switching costs dwarf any hardware performance advantage a competitor might achieve. The Marvell earnings miss is evidence that this strategy is working. The builder move worth watching now: NVIDIA NIM — Inference Microservices — which packages optimized TensorRT engines as containerized APIs, making it straightforward for enterprises to deploy GPU-optimized models without touching the underlying optimization stack directly. That is CUDA's moat packaged as a product.

Quote

'The market has priced in an acceleration that hasn't arrived at the pace they modeled.'

— Analyst commentary on Marvell's post-earnings drop, Insider Monkey, September 2026

The read-across for GPU learners: your skills are not priced in yet. The gap between market expectations and engineering reality is exactly where career opportunity lives.

Learner's Edge

Concept: CUDA Cores vs. Tensor Cores — Why the Distinction Matters

Every modern NVIDIA GPU contains two fundamentally different types of processing units: CUDA cores and Tensor cores. Understanding the difference is essential for reading benchmarks and understanding why TensorRT's optimizations matter in practice.

CUDA cores are general-purpose floating-point and integer processors. They handle one multiply-add operation per clock cycle, one element at a time. They are flexible — they can run any arithmetic operation — but they are not specialized for the matrix multiplications that dominate neural network computation.

Tensor cores are specialized matrix multiply-accumulate units. On an H100, each Tensor core performs a large matrix multiplication in a single clock cycle — many multiply-add operations in one step, compared to a CUDA core's single operation. The result: Tensor cores achieve dramatically higher throughput for the specific operation (GEMM — general matrix multiply) that accounts for the vast majority of compute in a transformer or CNN layer.

TensorRT's primary job is to express your model's computation in a form that maximizes Tensor core utilization. When a layer 'falls back to FP32' in TensorRT's verbose output, it typically means that layer could not be mapped to Tensor core instructions — and you are leaving the majority of the GPU's compute capacity idle.

Sign-off

That is today's NVIDIA Training session. You now have a calibrated INT8 workflow, a profiling tool, and the market context that explains why these skills compound in value over time. Show up tomorrow — every session builds on the last.

Sources

  1. Marvell Raised Its Outlook but Fell as Google Chip Revenue Stayed Distant. Has the AI Payoff Been Priced In? (Ready for review) — Insider Monkey
  2. ciflow/trunk/195929: [UPDATE] Update — github.com
  3. Xenon (XENE) Heads To Europe With Data That Could Reshape Epilepsy Care — Insider Monkey
  4. Everton vs Manchester United: Premier League – prediction, teams, lineups — aljazeera.com
  5. BND Pays More Than BSV Again. Is the Extra Rate Risk Finally Worth It? — 24/7 Wall St.
  6. Forget JEPQ: The Company Behind QQQ Runs Its Own Nasdaq Income Fund — 24/7 Wall St.
  7. pysnmp-pyasn1 2.0.0 — pypi.org

Get it in your inbox. NVIDIA Training — Learn NVIDIA's AI stack, hands-on. Free.

Subscribe free