NVIDIA operates one of the world’s largest and most complex supply chains; the company measures performance from wafer‑out to first token. That interval is split into two parts: time‑to‑rack, which covers silicon leaving the fab and an assembled system arriving on a data‑center floor, and time‑to‑token, which covers power, cooling, networking and the software stack that makes infrastructure productive on day one.
The Grace Blackwell NVL72 platform depends on millions of parts and thousands of suppliers worldwide, and the final system is assembled by dozens of OEMs and ODMs. A single compute tray — one of eighteen in a rack — requires two NVIDIA Grace CPUs, four NVIDIA Blackwell GPUs and thirty‑two HBM3e stacks. The supply chain built for Vera Rubin was twice that size. CPUs, GPUs and memory are all critical, and availability shifts week to week; a part that blocks a build one week may be readily available the next.
Contract manufacturers cannot begin assembly until every component has arrived from one of three pools: parts supplied directly by NVIDIA, parts NVIDIA holds on consignment, or parts coming from suppliers. When components don’t arrive together, whatever arrived early waits for the late items. NVIDIA measures the clock from the moment a manufacturing site receives material until it leaves as part of a sub‑assembly or product; that metric is Time of Ownership (TOO).
Given highly dynamic availability, NVIDIA must decide how much of each material to allocate to each manufacturing site — the critical material allocation problem — which is manually revised every week. Allocations run through the current quarter and the next; the closest weeks are already committed, so weekly updates mainly change outcomes further out.
Compressing time‑to‑rack requires four things: real‑time visibility into operational bottlenecks, redundancy to avoid single‑point failures, reliability so upstream commitments hold, and the codification of human expertise so complex allocation judgments become persistent organizational knowledge.
A supply‑chain command center in Palantir Foundry
NVIDIA’s supply‑chain operations team worked with Palantir to create a unified view of every input to a material allocation decision. They call this the Digital Supply Chain Intelligence command center; it surfaces risks, blockers and signals that were previously buried across disjoint data sources.
Palantir Foundry provides the operating context. The Ontology connects materials, manufacturing sites, commits, capacity, allocations, production outputs and unstructured qualitative signals into a governed data layer. Built from objects and links rather than rows and tables, the Ontology forms a complete representation of operational reality.
This representation lets allocation planners simulate and analyze many scenarios, broadening their decision space and laying groundwork for an AI flywheel that compounds new knowledge and improves performance over time.
Solving the quantitative side with NVIDIA cuOpt
Material allocation across multiple manufacturing sites starts as a quantitative optimization problem. Decision variables specify how much of each constrained material goes to which sites and when. Constraints include every manufacturer capable of building a given Blackwell sub‑assembly and the throughput each site can absorb after material arrival. The dependency graph maps every required part backward through the chain so the solver knows a compute tray is blocked by its scarcest input, not its average.
Binding constraints shift week to week: GPU, CPU or memory scarcity; inbound timing across the three supply routes; and customer commitments that determine the cost of shortfalls at any site. Thousands of variables and constraints resolve into a single weekly allocation.
NVIDIA cuOpt, an open‑source GPU‑accelerated decision‑optimization library, solves this formulation. It reads inputs from the Ontology and writes the allocation back. The allocation is posed as a mixed‑integer linear program with the objective of minimizing Time of Ownership (TOO). cuOpt also reports which constraints are binding, so planners can see whether Taiwan capacity or memory supply limited this week’s result.
Because solves are fast, planners can explore sensitivity: what if there is 10% less memory this period? What if a new site comes online? Planners move from asking for a single answer to asking about trade‑offs.
Where the math stops and human expertise matters
Quantitative optimization alone didn’t capture everything. NVIDIA and Palantir back‑tested historical allocation decisions versus actual outcomes and found a human factor cuOpt couldn’t see: planners used emails with partners, severe‑weather forecasts, geopolitical developments, supplier call transcripts and years of tacit experience. Those signals feed an instinct about allocation that often made human experts better than the math.
NVIDIA and Palantir therefore built a workflow around those experts. The system captures the allocation decision, the rationale, the expected result and the realized outcome. Institutional knowledge becomes explicit, reviewable decision logic and — because it lives in the Ontology — forms the foundation for training a large language model (LLM) to emulate expert judgment.
Codifying decision intelligence with Nemotron
Palantir and NVIDIA post‑trained an open‑weight LLM to apply the same reasoning and produce recommendations. After evaluating open models, they selected NVIDIA Nemotron 3.5 Lightning, which is designed for the execution layer of an agentic workflow. Its mixture‑of‑experts architecture enables efficient inference; the model is around 30 billion parameters overall with roughly 3 billion active parameters per forward pass, making it small enough for practical post‑training while large enough to learn a focused policy.
Because Nemotron is open, post‑training can occur within a customer’s own compute boundary, keeping proprietary supply‑chain data in‑house. The model is trained on the signals planners actually used: how much constrained material was offered to a site, what the manufacturer committed to produce, what it ultimately produced, and the qualitative operational evidence available when the decision was made.
The objective is to codify an allocation policy that can assess production risk, recommend an allocation range, identify the drivers behind that recommendation and explain its reasoning to the supply‑chain team.
The same recorded decision log doubles as an evaluation harness: each historical decision is replayed with only the information knowable at the time, the outcome is hidden, and the model’s recommendation is compared against the planner’s decision and the actual result. The key question is: if this model had been running last month, would it have made the right allocation call?
From Ontology data to a specialized model: training pipeline
Training begins with operational history in the Palantir Ontology and follows these steps:
- Anonymization: NeMo Anonymizer removes personally identifiable information and obfuscates sensitive fields before training.
- Synthetic data generation: NeMo Data Designer expands and balances examples so the model sees routine weeks as well as allocation increases, capacity constraints and disruption scenarios.
- Supervised fine‑tuning: NeMo AutoModel trains a small set of LoRA adapter parameters while keeping base weights frozen, reducing training time, memory needs and checkpoint sizes.
- Evaluation: A point‑in‑time backtest replays historical decisions through both the base and fine‑tuned models to isolate what post‑training added.
Palantir Autopilot manages the lifecycle end‑to‑end, launching jobs from Ontology data, monitoring the deployed Nemotron model and preserving lineage from data to model version to recommendation. Once deployed, the model ingests current operational context and returns a recommendation with rationale and attached risks; a planner then reviews and makes the final call.
Closing the loop and future work
Every acceptance, edit, override and production outcome is written back into the Ontology, accumulating until there is sufficient representative data to justify another governed training run. In future iterations, this feedback could be used for reinforcement learning: accepted and overridden recommendations would form preference pairs and rewards would cover allocation correctness, policy compliance and evidence grounding. The model does not retrain itself in production.
The compound effect is twofold: planners spend less time reconstructing routine decisions and can cover more sites and products, and allocation expertise becomes institutional knowledge, shortening onboarding and propagating key learnings across the organization.
What post‑training delivered in practice
NVIDIA’s supply‑chain team and Palantir specified model inputs, allowable recommendations and scoring criteria. They used this workflow as both application and allocation decision‑intelligence benchmark.
Three models were compared on the same task and evaluation data: base Nemotron 3.5 Lightning (BF16), Nemotron 3 Ultra (NVFP4), and the post‑trained Nemotron 3.5 Lightning (BF16). On the development benchmark, the post‑trained Lightning model achieved 86.7% allocation‑decision accuracy; Ultra reached 55.5% and base Lightning 17.5%. The post‑trained model outperformed Ultra by 31.2 percentage points and its own base by 69.2 points.
It also led on balanced metrics that weight classes equally: balanced accuracy 58.6% vs Ultra’s 42.0%, and macro‑F1 57.5% vs 39.5%. These matter because constrained supply causes planners to cut allocations far more often than increase them, so raw accuracy could overstate performance if a model simply favored the majority class.
The takeaway is specific: on a bounded allocation task, a specialized 30B model can outperform a general‑purpose model that is an order of magnitude larger. That does not imply the smaller model is generally more capable — its gains are concentrated in the post‑training domain. Some prediction tasks, such as future production‑risk forecasting, remained challenging despite fine‑tuning.
The LoRA fine‑tuning run completed in minutes on two NVIDIA B200 GPUs, light enough to repeat as feedback accumulates. This demonstrates sovereign AI in practice: proprietary supply‑chain data, model weights and inference all remain inside a single governed environment. The stack can be deployed on‑premises or in cloud environments to meet operational requirements.
Generalizability and conclusions
The supply‑chain workflow described is not unique to semiconductors. Any operation where critical capacity is allocated by experienced people from fragmented signals can implement the same flywheel and adapt it to new domains.
Three essentials are required: a governed operational layer, decision capture that includes rationale and outcome, and an open model that can be post‑trained within a secure compute boundary. Operational data trains the model, the model improves decisions, and decisions become new operational data for the next governed training round. NVIDIA and Palantir used this approach to compress the time from wafer‑out to first token and to create a supply chain that learns faster than it grows.
