MIG on Jetson Thor: GPU Partitioning for Mixed-Criticality Robotics in JetPack 7.2

A humanoid does not fall over because a kernel crashed. It falls over because a visual-language model decided to run a long attention kernel at exactly the moment the balance controller needed the GPU, and the controller’s 1 ms deadline slipped to 4 ms. Nothing logged an error. The tail just got fatter. MIG on Jetson Thor, introduced in JetPack 7.2, is NVIDIA’s answer to that class of failure: the integrated Blackwell GPU can now be split into two hardware-isolated instances, one of 12 streaming multiprocessors and one of 8, each with dedicated compute, cache, and memory bandwidth. That changes GPU contention from a scheduling problem you fight in software into a partitioning decision you make at boot. It also costs you something real, and the vendor material is quiet about what.

What this covers: what the two partitions actually isolate, how they differ from datacenter MIG’s seven-instance model, how the Preemptible RT kernel fits in, how to bind workloads with CUDA Runtime and the NVIDIA Container Toolkit, a worked humanoid/AMR split, and the failure modes engineers are hitting in the field today.

Context and Background

Until JetPack 7.2, every Jetson was a single-tenant GPU pretending to be a multi-tenant one. If a perception pipeline, a motion planner, and a language model all wanted the iGPU, they queued against one hardware scheduler and shared one L2 cache and one LPDDR interface. The tools for arbitrating that were entirely software: CUDA streams, stream priorities, the Multi-Process Service, cudaLimitDevRuntimeSyncDepth tuning, and the blunt instrument of simply not running the big model while the robot was moving.

None of those mechanisms provide quality-of-service guarantees. NVIDIA’s own Multi-Instance GPU User Guide is explicit on this point. CUDA streams offer no SM performance isolation, no memory protection, no memory-bandwidth QoS, and no error isolation; a fault in one stream takes down the process. MPS adds memory protection and optional SM percentage limits across up to 48 clients, but the scheduling hardware stays shared and memory bandwidth, caches, and capacity remain common property. Only MIG is listed as a physical partition with memory-bandwidth QoS and error isolation.

Datacenter operators have had that capability since Ampere. A100 and H100 have been carved into as many as seven GPU instances for multi-tenant inference since 2020. The robotics world could not use any of it, because MIG did not exist on Tegra silicon. Mixed-criticality designs therefore did what embedded engineers always do when isolation is unavailable: they bought a second compute box, ran the safety loop on a separate microcontroller or an Orin dedicated to control, and paid for the extra mass, wiring, power, and thermal budget.

That second box is exactly what Thor’s specification sheet is designed to eliminate. NVIDIA publishes Jetson AGX Thor at 2,070 FP4 TFLOPS, 128 GB of memory, and a 40–130 W envelope — enough headroom to host perception, planning, control, and a generative model on one module. Consolidation only works if the workloads can be isolated from each other, which is precisely the gap MIG closes. For the broader silicon comparison, see our Jetson Thor versus Jetson AGX Orin analysis; this post is about what you do with the GPU once you have it.

What MIG on Jetson Thor Actually Partitions

MIG on Jetson Thor divides the integrated Blackwell GPU into two isolated GPU instances with dedicated compute, cache, and memory bandwidth. NVIDIA supports exactly two partitions: a 12 SM, 1,536 CUDA core instance for inference, rendering, and general CUDA work, and an 8 SM, 1,024 CUDA core instance for robotics, control, perception, or safety-critical workloads.

Figure 1: How MIG on Jetson Thor maps the 20 SM Blackwell GPU onto two GPU instances, their compute instances, and the workloads bound to each.

The figure traces the full binding chain. The physical Blackwell iGPU exposes 20 SMs. Enabling MIG mode converts it into a partitionable device. Two GPU instances are then created from published profiles, each receiving its own SM slice, its own share of cache and memory bandwidth, and its own copy and media engines. Each GPU instance carries a single compute instance, which is the object CUDA actually binds a context to. Applications and containers select an instance by UUID, and from that point a kernel launched on one partition cannot occupy an SM belonging to the other.

The two profiles are named, numbered, and fixed

This is not a flexible geometry. The Jetson Linux Developer Guide’s MIG page lists seven GPU instance profiles on Thor — IDs 78, 80, 81, 82, 83, 0, and 32 — but only one pairing is supported in practice. NVIDIA’s documented walkthrough and its support engineers both point at profile 83 (MIG 2g.0gb+gfx) plus profile 78 (MIG 1g.0gb+me). The +gfx suffix marks the graphics-capable partition; the +me suffix marks media extensions, giving that instance a decoder, encoder, JPEG engine, and optical flow accelerator.

Two consequences follow immediately. First, only the 2g partition can host a display server or a Vulkan/OpenGL workload, so anything rendering a teleoperation view or a Isaac Sim visualisation belongs on the big side. Second, the profile pair is a product decision, not a tunable. You cannot create three instances, you cannot move the boundary to 10/10, and you cannot resize at runtime. The partition ratio is 60/40 or nothing.

Note the zero in 0gb — memory capacity is not partitioned

Every Thor MIG profile reports 0.00 GiB of memory. That is not a display bug; it is the defining structural difference from datacenter MIG. Thor has a unified memory architecture, where CPU and GPU address the same physical LPDDR. There is no discrete frame buffer to carve, so there are no memory slices to hand out and no per-instance capacity ceiling.

Read NVIDIA’s claim carefully: dedicated compute, cache, and memory bandwidth. Capacity is conspicuously absent from that list. The practical meaning is that a runaway allocation on the AI partition can still exhaust the memory both partitions draw from. MIG will keep your control loop’s SMs and its share of bandwidth intact while an oversized model weights allocation pushes the system into swap or an out-of-memory kill. If you want capacity isolation on Thor, you still need cgroup memory limits on the containers — MIG will not do it for you.

How this differs from the datacenter seven-instance model

Figure 2: Datacenter MIG on A100-class silicon versus the two-partition model on Jetson Thor.

The figure contrasts the two partitioning models side by side. On the datacenter side, the GPU is decomposed into eight memory slices and seven SM slices; a GPU slice is one of each, a GPU instance is a bundle of GPU slices plus engines, and a compute instance subdivides the SM slices within an instance. NVIDIA’s terminology is precise: each memory slice is roughly one eighth of total memory resources, covering both capacity and bandwidth, and each SM slice is roughly one seventh of the SMs. Up to seven instances can coexist, and the A100-40GB profile table assigns each profile an explicit L2 cache fraction and copy-engine count.

On the Thor side, that lattice collapses. There are no memory slices because there is no partitionable frame buffer. Compute instances exist, but with one CI per GI they are a formality. Maximum instance count drops from seven to two. What survives the translation is the part that matters for control: SM assignment, cache partitioning, memory-bandwidth QoS, and error isolation.

That last property deserves emphasis. Error isolation means an illegal memory access or an unrecoverable fault inside the AI partition does not poison the context on the control partition. Under CUDA streams or MPS, a sticky error is process-wide or worse. On a robot, the difference between “the LLM container restarted” and “the balance controller lost its CUDA context” is the difference between an incident and an injury.

Resolving the SM-count contradiction

There is a genuine discrepancy in the published material, and getting it wrong will wreck your capacity model. NVIDIA’s JetPack 7.2 announcement describes the partitions as 12 SMs and 8 SMs. But nvidia-smi mig -lgip on Thor reports the 1g profiles at 6 SMs and the 2g profiles at 12, which would leave 2 of the device’s 20 SMs stranded.

The 8 SM figure is the correct one. The R39.2 release notes carry known issue 6162096, “Output of nvidia-smi is incorrect when using MIG,” and the CUDA Runtime tells the true story: cudaGetDeviceProperties on the small instance returns multiProcessorCount = 8. NVIDIA support engineers reproduced exactly that output in a public forum thread, printing name=NVIDIA Thor MIG 1g.0gb SMs=8. The arithmetic closes cleanly: 12 plus 8 equals 20, and NVIDIA’s own CUDA-core figures of 1,536 and 1,024 sum to 2,560 across those 20 SMs at 128 cores per SM. Trust the runtime query, not the nvidia-smi table.

Contention, Jitter, and What Isolation Actually Buys

A control engineer does not care about average throughput. They care about the 99.99th percentile of loop execution time, because that is what sets the safety margin. Understanding why a shared SoC inflates that tail explains precisely which parts of the problem MIG fixes and which it leaves untouched.

Four contention paths, only three of which MIG closes

The first path is SM occupancy. Without partitioning, a large inference kernel with high block counts can fill every SM on the device. A control kernel submitted a microsecond later waits for blocks to retire. This is the path that makes MIG’s reputation, and partitioning eliminates it completely: 8 SMs are reserved whether or not anything is using them.

The second is L2 cache thrashing. Streaming a multi-gigabyte weight tensor evicts a controller’s working set repeatedly, turning cache hits into DRAM round-trips. MIG’s cache partitioning addresses this, which is why NVIDIA lists cache alongside compute in its isolation claim.

The third is DRAM bandwidth. This is usually the dominant term on an SoC, because a unified memory architecture means the GPU, the CPU, the camera ISP, and the video encoders all pull from the same LPDDR controllers. Memory-bandwidth QoS is the property that distinguishes MIG from MPS in NVIDIA’s own comparison table, and it is the reason a partitioned control loop holds its timing while a language model saturates its own bandwidth share.

The fourth path is the one MIG does not touch: the CPU. Kernel launches, driver callbacks, sensor ingest, and the ROS 2 executor all run on Arm cores. If the control thread is preempted by a container’s garbage collector before it ever reaches cudaLaunchKernel, a perfectly isolated GPU partition sits idle while the deadline passes. GPU partitioning solves half of a two-sided problem.

The Preemptible RT kernel is the other half

Figure 3: The timing path of a control cycle when the RT kernel owns isolated CPUs and MIG owns a dedicated GPU partition.

The figure follows one control cycle end to end. A sensor delivers a frame or an IMU sample. An RT-priority thread pinned to an isolated CPU wakes, does its pre-processing, and launches a kernel on the control partition. The partition executes on its reserved SMs, returns, and the thread emits an actuator command. In parallel, the AI partition runs its own workload and touches none of those resources. Determinism requires both isolations: remove the CPU pinning and the wake-up jitters; remove the GPU partition and the kernel queues behind someone else’s work.

JetPack 7 ships a Preemptible RT kernel, offered at developer-preview quality for Jetson T5000, AGX Orin, and Orin NX/Nano. It installs as a Debian package set from the rt-kernel apt repository, and you select it by setting DEFAULT real-time in /boot/extlinux/extlinux.conf. NVIDIA publishes measured latency for it, which is unusually candid and worth quoting precisely.

In NVIDIA’s own tuning example, CPUs 8–13 are isolated for the real-time application while CPUs 0–7 carry system load. The kernel is built with CONFIG_NO_HZ_FULL and CONFIG_RCU_NOCB_CPU, efi=runtime is removed from the boot parameters, and isolcpus, nohz_full, rcu_nocbs, irqaffinity, and kthread_cpus are set to match. Under a deliberately hostile load — glmark2 on a 4K display, fio over USB, pings every 2 ms on two interfaces, rteval running kernel compiles and hackbench, and stress on the isolated cores — rtla timerlat reports maximum thread latency of 96 microseconds on the loaded CPUs and 26 microseconds on the isolated ones.

That 3.7x gap is the entire argument for CPU isolation in one number. It also sets expectations honestly: 26 µs of worst-case wake-up jitter is excellent for a 1 kHz loop with a 1 ms period, marginal for a 10 kHz current loop, and irrelevant if your GPU kernel itself varies by milliseconds. Note also that the guide recommends disabling UEFI runtime services and RT throttling via kernel.sched_rt_runtime_us=-1, both of which have security and robustness implications you should weigh deliberately.

Assigning Partitions with CUDA Runtime and the Container Toolkit

Partitioning is a privileged, disruptive, boot-scoped operation. The GPU must be free of clients before instances can be created, which on a developer kit means stopping the display manager and the camera daemon. Do this over SSH, not from the local console.

# The GPU must have no active clients
sudo systemctl isolate multi-user.target        # or: sudo systemctl stop gdm nvargus-daemon

sudo nvidia-smi -pm 1                            # persistence mode - survives client exit
sudo nvidia-smi -i 0 -mig 1                      # enable MIG mode

sudo nvidia-smi mig -lgip                        # list GPU instance profiles
sudo nvidia-smi mig -cgi 78,83 -C                # create both GIs and their CIs
nvidia-smi -L                                    # capture the two MIG UUIDs

The -C flag matters: it creates the compute instance inside each GPU instance in the same step. Without it you get GPU instances that CUDA cannot bind to. Persistence mode is not optional for production — without it, MIG configuration is lost on reboot, and a robot that reboots into an unpartitioned GPU is a robot whose safety argument just evaporated.

Binding a workload is deliberately boring. MIG is designed to be transparent to the CUDA programming model, so CUDA_VISIBLE_DEVICES does the work, taking a MIG UUID rather than an index.

# Control-side workload on the 1g partition
CUDA_VISIBLE_DEVICES=MIG-<1g-uuid> ./control_node &

# AI-side workload on the 2g partition
CUDA_VISIBLE_DEVICES=MIG-<2g-uuid> ./inference_server &

Prefer UUIDs to indices everywhere. Indices are ordering-dependent and will silently point at the wrong partition after a reconfiguration — a failure mode that produces a working system with the wrong isolation properties, which is worse than a crash.

Containers: what works today and what does not

The NVIDIA Container Toolkit is the supported path, and on Thor it is currently the roughest edge in the stack. A straightforward docker run --runtime=nvidia may fail to enumerate MIG devices inside the container. NVIDIA has acknowledged this as a known issue and offers --privileged as an interim workaround while a container-toolkit fix lands.

docker run --rm --runtime=nvidia --privileged \
  -e CUDA_VISIBLE_DEVICES=MIG-<1g-uuid> \
  -it my-control-image:latest

Handing a control container full privilege to work around a device-enumeration bug is an unpleasant trade, and you should treat it as temporary. The underlying mechanism is the MIG capability device nodes under /dev/nvidia-caps/, with the GPU-instance and compute-instance minors listed in /proc/driver/nvidia-caps/mig-minors. Engineers have confirmed that explicitly exposing the matching nvidia-cap* nodes with the right device-cgroup permissions lets an unprivileged container use its partition, which is the shape the eventual fix will take.

Kubernetes is further behind. One reported setup — Container Toolkit 1.19.1, k8s-device-plugin v0.18.2, K3s v1.36.3+k3s1 — advertises only nvidia.com/gpu: 1 on a partitioned Thor node. The expected nvidia.com/mig-1g.0gb and nvidia.com/mig-2g.0gb resources do not appear under either the tegra discovery strategy or the mixed MIG strategy, and NVIDIA has confirmed it as a known issue under active work. Until it lands, scheduling MIG partitions on Thor under Kubernetes means privileged pods with hand-set CUDA_VISIBLE_DEVICES, which defeats most of the point of a device plugin. If you are designing a fleet around orchestrated partitions, read our Kubernetes GPU sharing comparison of MIG, time-slicing and MPS and then assume the Jetson path lags the datacenter path by at least one release.

A Worked Partitioning Example for a Humanoid Stack

Consider a bipedal humanoid with six cameras, a lidar, a 6-axis IMU, and 28 actuated joints, running a vision-language-action model for task selection. The stack has four tiers with genuinely different criticality, and the partition assignment follows from that.

Figure 4: A worked assignment of a humanoid stack across the two Thor partitions, with the CPU-side split shown alongside.

The figure shows the full mapping. The 8 SM control partition hosts the whole-body controller, the state estimator’s GPU-accelerated filter, and the reflexive collision-avoidance check — every workload whose deadline miss is a safety event. The 12 SM partition hosts the VLA model, the multi-camera detection and segmentation pipeline, the occupancy-grid builder, and any teleoperation rendering, since it is the graphics-capable instance. On the CPU side, RT-priority threads for the controller and state estimator pin to isolated cores; everything else runs on the general pool.

Sizing the control partition

Start from the deadline, not from the hardware. A 1 kHz whole-body controller has a 1,000 µs budget. Allocate it: 26 µs of worst-case RT wake-up jitter from NVIDIA’s measured figures, roughly 20–40 µs of kernel launch and synchronisation overhead per GPU call, the kernel execution itself, and the actuator write over EtherCAT or CAN. If the controller makes two GPU calls per cycle, fixed overhead alone consumes 10–15% of the budget before any arithmetic runs.

That leaves the question of whether 8 SMs suffice for the compute. A centroidal-dynamics QP or a batched forward-dynamics rollout at these joint counts is a small problem by GPU standards — measured in tens of microseconds, not milliseconds. The binding constraint is almost never SM count; it is launch overhead and determinism. This is the argument for giving control the smaller partition: it needs predictable SMs, not many SMs, and every SM you move across the boundary is a straight loss to the AI side.

Sizing the AI partition, honestly

The 12 SM partition is where the pain lands. A model that previously burst across all 20 SMs now caps at 12, a 40% reduction in peak compute. If the workload is a token-generation loop that is memory-bandwidth bound rather than SM bound, the practical loss is smaller, because bandwidth QoS gives the partition a defined share rather than a hard 60% ceiling. If it is a compute-bound vision backbone, expect something closer to the full 40%.

A single community-reported measurement on a partitioned Thor gives a useful sanity check, with the caveat that it is one engineer’s data point and not a benchmark. A CV-CUDA resize ran in 0.0733 ms on the 2g partition against 0.1214 ms on the 1g partition, a ratio of 1.66. A VPI CUDA resize ran 0.0909 ms against 0.1099 ms, a ratio of just 1.21. Neither matches the 1.5 ratio the 12:8 SM split would predict. The spread is exactly what you would expect once fixed launch overhead and memory-bound behaviour compress or distort the compute ratio — which is the real lesson. Partition scaling is workload-dependent, and you must measure your own kernels rather than assuming linearity in SM count.

The reservation tax

Here is the arithmetic nobody puts on a slide. Unpartitioned, a GPU statistically multiplexes: when control is idle, inference gets everything. Partitioned, a reservation is a reservation. If the control partition has a 30% duty cycle, then 8 SMs × 70% idle equals 5.6 SM-equivalents of permanently stranded capacity — 28% of the device doing nothing, permanently, by design.

That is the trade in one sentence: you convert statistical multiplexing into static reservation, paying stranded capacity in exchange for a bounded tail. It is the right trade when a missed deadline is a safety event and the wrong trade when you are maximising tokens per second. Most teams should run the mixed workload unpartitioned first, measure the control loop’s p99.9 under realistic AI load, and only partition if the tail is out of budget. Partitioning to feel safe, without a measurement showing contention, buys you a 28% capacity loss for nothing.

Trade-offs, Gotchas, and What Goes Wrong

The feature is young, and the field reports are specific enough to plan around. Take them seriously before committing a product architecture to MIG on Jetson Thor.

Launch order is load-bearing. Engineers have reported that starting a long-lived CUDA process on the 2g partition first causes cudaSetDevice on the 1g partition to hang indefinitely — not fail, hang. Reverse the order and it works. Start the control-side process first, always, and treat that as an architectural invariant rather than a scripting detail.

A hung client can poison its partition. After the hang above, SIGKILLing the stuck process does not restore the slice even on a fully idle GPU. Recovery requires destroying and recreating the instances with mig -dci and mig -dgi. Your supervisor logic needs a partition-level reset path, not just a process restart.

You may not get MIG mode back. Disabling MIG with -mig 0 succeeds silently and gives you the full 20 SM GPU. Re-enabling it afterwards can fail with “GPU requires reset,” and --gpu-reset is not supported on an integrated GPU. Only a reboot recovers. Any orchestration that toggles MIG off to run a whole-GPU job can therefore strand a robot in an unpartitioned state, with relaunched CUDA apps silently finding no MIG devices.

Several SoC engines break under MIG. A detailed report found that VPI workloads on the VIC, PVA, and OFA backends fail or hang with MIG enabled, while plain CUDA on both partitions works fine. NVIDIA traced it to a VPI bug handling MIG-based UUIDs, confirmed the SoC hardware itself is functional, and said in September 2026 that the fix ships in an upcoming JetPack. If your perception pipeline leans on VPI’s hardware backends to offload the GPU, verify on your target release before designing around them.

The upgrade path can silently remove your profiles. After an SDK Manager “System Upgrade” from R38.2.1 to R39.2.1, one Thor exposed only the 3g profiles; creating profile 83 failed with “Invalid Argument.” Neither bootloader-only nor full image-based OTA fixed it. The root cause was a stale /etc/modprobe.d/nvidia-unifiedgpudisp.conf left behind from the rel38 environment; removing it and rebooting restored all profiles. A clean USB reflash also worked. Validate profile availability as a post-update gate, not an assumption.

Anti-pattern: partitioning for tenancy you do not have. Two partitions is a small number. If you have three workload classes with real isolation requirements, MIG cannot express that, and forcing two of them to share a partition reintroduces exactly the contention you were trying to remove. Decide which single workload class is genuinely safety-relevant, and put everything else on the other side.

Practical Recommendations

Treat partitioning as a measurement-driven decision. Instrument your control loop’s end-to-end latency distribution first, under a realistically hostile AI load, and look at p99.9 rather than the mean. If the tail fits your budget unpartitioned, do not pay the reservation tax. If it does not, MIG on Jetson Thor gives you a hardware answer that no amount of stream-priority tuning will match.

When you do partition, pair it with the RT kernel and CPU isolation. GPU isolation alone leaves the wake-up path unbounded, and NVIDIA’s own figures show a 96 µs versus 26 µs difference between loaded and isolated cores. Half an isolation story produces half a determinism result.

Build the operational scaffolding before the robot leaves the bench. Persistence mode, deterministic launch ordering, UUID-based device selection, and a partition-reset recovery path are all cheap to add early and painful to retrofit after a field failure.

• Measure control-loop p99.9 under AI load before deciding to partition.
• Create instances with -cgi 78,83 -C and enable persistence mode; verify after every reboot.
• Bind workloads by MIG UUID, never by device index.
• Launch the control partition’s process first; enforce it in your init system.
• Confirm cudaGetDeviceProperties reports 8 SMs on the small instance; ignore the nvidia-smi SM column.
• Add cgroup memory limits — MIG partitions bandwidth, not capacity, on unified memory.
• Re-validate MIG profile availability after every JetPack update.
• Test your VPI and SoC-engine paths under MIG before committing to them.
• Give the graphics-capable 2g partition anything that renders.

Frequently Asked Questions

How many MIG instances does Jetson Thor support?

Two. NVIDIA supports exactly one pairing: profile 83 (MIG 2g.0gb+gfx) at 12 SMs and 1,536 CUDA cores, plus profile 78 (MIG 1g.0gb+me) at 8 SMs and 1,024 CUDA cores. The profile list shows 1g, 2g, and 3g entries, but only that pair is the validated configuration. This is a hard limit compared with datacenter GPUs, which support up to seven instances, and the split ratio is fixed rather than tunable.

Does MIG on Jetson Thor partition memory as well as compute?

No. Every Thor MIG profile reports 0.00 GiB, because Thor uses unified memory with no discrete frame buffer to carve into slices. NVIDIA’s claim is dedicated compute, cache, and memory bandwidth — capacity is deliberately absent from that list. Both partitions draw from the same 128 GB pool, so an oversized allocation on one side can still starve the other. Use container memory limits if you need capacity isolation.

Why does nvidia-smi report 6 SMs when NVIDIA says 8?

It is a documented bug. The R39.2 release notes list known issue 6162096, “Output of nvidia-smi is incorrect when using MIG,” and the SM column in nvidia-smi mig -lgip is one of its symptoms. The CUDA Runtime is authoritative: cudaGetDeviceProperties returns multiProcessorCount = 8 for the 1g instance, which NVIDIA engineers have reproduced publicly. The 12 plus 8 split also accounts for all 20 SMs, whereas 12 plus 6 would strand two.

Do I still need the real-time kernel if I use MIG?

Yes, for any hard deadline. MIG isolates GPU compute, cache, and bandwidth but does nothing for CPU scheduling, and every GPU kernel is launched by a CPU thread. NVIDIA’s measured rtla timerlat results show maximum thread latency of 96 µs on loaded cores against 26 µs on isolated ones under the same load. Without CPU isolation, that wake-up jitter sits in front of your perfectly isolated partition.

Can I run MIG partitions in Docker containers on Thor?

Partially, today. The NVIDIA Container Toolkit currently has a known issue where MIG devices fail to enumerate inside containers, and NVIDIA’s interim guidance is --privileged while a fix is developed. The underlying requirement is access to the matching /dev/nvidia-caps/nvidia-cap* device nodes with correct cgroup permissions. Kubernetes is further behind: the device plugin advertises only nvidia.com/gpu: 1 rather than per-partition resources.

Does partitioning reduce total GPU throughput?

Aggregate SM count is preserved at 12 plus 8, but usable throughput usually drops. A single workload can no longer burst across all 20 SMs, capping peak compute at 60% for the AI partition, and any idle time on the control partition is permanently stranded rather than reclaimed. A control partition with a 30% duty cycle strands about 28% of the device. You are trading throughput for a bounded latency tail.

Further Reading

• Jetson Thor versus Jetson AGX Orin — the silicon-level comparison behind the consolidation argument in this post.
• Kubernetes GPU sharing: MIG, time-slicing and MPS — how the same partitioning mechanisms are scheduled in the datacenter.
• NVIDIA Jetson Thor humanoid robot architecture — the full-stack context for the worked partitioning example above.
• Jetson Thor versus Hailo-10H versus Coral for edge inference — where Thor sits against fixed-function edge accelerators.
• NVIDIA Jetson Linux Developer Guide — Multi-Instance GPU — the authoritative profile list and enablement procedure.
• NVIDIA Multi-Instance GPU User Guide — Concepts — slice, GPU-instance and compute-instance semantics on datacenter silicon.

By Riju — about