Hi,
On AGX Thor with MIG enabled, a 1g compute instance enumerates correctly and then the
first real GPU operation never returns.
Not an error, not a slow result: no return
value, no exception, no output. Every run had to be killed on a timeout.
2g instances on the same board, in the same session, work perfectly, this blocks us from running both SONIC and GR00T on the same Thor.
from using MIG at all, because every two-way split this board allows puts a 1g instance on one side.
System
Jetson AGX Thor
L4T R39.2.0 (/etc/nv_tegra_release) -> JetPack 7.2
nvidia-l4t-core 39.2.0-20260601141651
Driver 595.78, CUDA 13.2
Ubuntu 24.04.4
20 SMs, 125748 MB, num_DLA_cores = 0
MIG mode: Enabled, persistence mode Enabled
Reproducer
import torch
torch.cuda.init()
print(torch.cuda.get_device_name(0)) # fine
p = torch.cuda.get_device_properties(0)
print(p.multi_processor_count, p.total_memory) # fine
x = torch.randn(2048, 2048, device="cuda", dtype=torch.bfloat16) # NEVER RETURNS
torch.cuda.synchronize()
print("ok")
Create a 1g instance and point CUDA at it:
$ sudo nvidia-smi mig -i 0 -cgi 80 -C
Successfully created GPU instance ID 2 on GPU 0 using profile MIG 1g.0gb (ID 80)
Successfully created compute instance ID 0 on GPU 0 GPU instance ID 2 using profile MIG 1g.0gb (ID 0)
$ CUDA_VISIBLE_DEVICES=MIG-84de54e1-f9d8-5bd7-a199-7b0603c64a82 timeout 180 python probe.py
import torch
cuda.init() name=NVIDIA Thor MIG 1g.0gb
SMs=8 mem=125748MB
<nothing further; killed at 180 s>
The allocation is 8 MB and the workload is one kernel, so this is not memory pressure.
Scope
Every MIG instance we have created on this board, all probed with the script above:
| Profile | SMs reported | Device opens | First kernel |
| 2g.0gb (82) | 14 | yes | 0.145 ms, 118 TFLOP/s |
| 2g.0gb+gfx (83) | 12 | yes | 0.136 ms, 127 TFLOP/s |
| 1g.0gb (80) | 8 | yes | never returns (180 s) |
| 1g.0gb+gfx (81) | 6 | yes | never returns (180 s) |
Both 1g variants hang. Both 2g variants work.
Question that I have regarding this:
1. Is 1g expected to be functional on Thor, or is it enumerated by the driver but not
actually supported on this silicon? If it is not supported, we would much rather know
that than keep testing.
2. If it is expected to work is this a known issue, and is there a JetPack or driver
level where it is fixed?
3. Is there any diagnostic we can collect that would be more useful than a timeout?
There is no error, no log line and no exit code.
The process simply sits at 100% of one core with no GPU activity.
Please any support to solve this issue.