OrionLLM/GRM-2.6-Plus
Image-Text-to-Text • 28B • Updated • 3.05k • 68
DedeProGames PRO
DedeProGames
AI & ML interests
Thinking and Agentic Finetuning
Recent Activity
new activity about 2 hours ago
SL-AI/GRaPE-2-Pro:Update README.md updated a model 3 days ago
OrionLLM/GRM-2.6-Plus liked a model 5 days ago
OrionLLM/GRM-OCROrganizations
Update README.md
#3 opened about 2 hours ago
by DedeProGames
updated a
model 3 days ago
liked a
model 5 days ago
updated a
model 5 days ago
published a
model 5 days ago
liked a
model 6 days ago
liked 6
models 13 days ago
nvidia/Nemotron-Labs-Diffusion-14B-Base
Text Generation • 14B • Updated • 3.72k • 6
nvidia/Nemotron-Labs-Diffusion-14B
Text Generation • 14B • Updated • 7.23k • 134
nvidia/Nemotron-Labs-Diffusion-8B
Text Generation • 8B • Updated • 47k • 41
nvidia/Nemotron-Labs-Diffusion-3B
Text Generation • 4B • Updated • 25.2k • 28
nvidia/Nemotron-Labs-Diffusion-3B-Base
Text Generation • 4B • Updated • 15.3k • 9
nvidia/Nemotron-Labs-Diffusion-VLM-8B
Image-Text-to-Text • 9B • Updated • 3.74k • 18
Update README.md
1
#1 opened 14 days ago
by DedeProGames
inclusionAI/Ring-2.6-1T
🚀 6
#9887 opened 18 days ago
by DedeProGames
liked 2
models 18 days ago
liked a
Space 18 days ago
updated a
Space 18 days ago
reacted to Imosu's post with 👀🔥 18 days ago
Post
3326
# ZeroGPU Hardware Mismatch: Why Am I Getting RTX PRO 6000 Blackwell MIG Instead of the Documented H200?
I recently ran into a surprising issue while debugging a Hugging Face ZeroGPU Space.
According to the Hugging Face ZeroGPU documentation, ZeroGPU is described as using NVIDIA H200-based resources, with configurations such as “large” and “xlarge” offering H200-class memory. However, when I printed the actual GPU information inside my Space, I got something different:
GPU: NVIDIA RTX PRO 6000 Blackwell Server Edition MIG 2g.48gb
Capability: (12, 0)
Torch: 2.8.0+cu128
CUDA: 12.8
This is not an H200. It appears to be a MIG slice of an RTX PRO 6000 Blackwell Server Edition GPU, with 48GB VRAM.
This difference matters. It is not just a cosmetic hardware-name issue.
In my case, the Space was running Qwen3-TTS and failed with:
CUDA error:
no kernel image is available for execution on the device
The issue appears related to GPU architecture compatibility. The app was using kernels-community/flash-attn3, which is generally aligned with Hopper-class GPUs such as H100/H200, but the actual device exposed to the Space was Blackwell with compute capability 12.0. As a result, CUDA kernels that might work on the expected H200 environment failed on the actual assigned GPU.
To be clear, I am not saying the RTX PRO 6000 Blackwell is a bad GPU. It is a newer architecture and may be powerful in many workloads. But it is not the same as H200, and the software ecosystem compatibility is different. For ML workloads, especially those relying on custom CUDA kernels, the exact GPU architecture matters a lot.
This raises a few questions:
Is Hugging Face ZeroGPU now assigning RTX PRO 6000 Blackwell MIG instances instead of H200 instances?
If yes, why is this not clearly documented?
I recently ran into a surprising issue while debugging a Hugging Face ZeroGPU Space.
According to the Hugging Face ZeroGPU documentation, ZeroGPU is described as using NVIDIA H200-based resources, with configurations such as “large” and “xlarge” offering H200-class memory. However, when I printed the actual GPU information inside my Space, I got something different:
GPU: NVIDIA RTX PRO 6000 Blackwell Server Edition MIG 2g.48gb
Capability: (12, 0)
Torch: 2.8.0+cu128
CUDA: 12.8
This is not an H200. It appears to be a MIG slice of an RTX PRO 6000 Blackwell Server Edition GPU, with 48GB VRAM.
This difference matters. It is not just a cosmetic hardware-name issue.
In my case, the Space was running Qwen3-TTS and failed with:
CUDA error:
no kernel image is available for execution on the device
The issue appears related to GPU architecture compatibility. The app was using kernels-community/flash-attn3, which is generally aligned with Hopper-class GPUs such as H100/H200, but the actual device exposed to the Space was Blackwell with compute capability 12.0. As a result, CUDA kernels that might work on the expected H200 environment failed on the actual assigned GPU.
To be clear, I am not saying the RTX PRO 6000 Blackwell is a bad GPU. It is a newer architecture and may be powerful in many workloads. But it is not the same as H200, and the software ecosystem compatibility is different. For ML workloads, especially those relying on custom CUDA kernels, the exact GPU architecture matters a lot.
This raises a few questions:
Is Hugging Face ZeroGPU now assigning RTX PRO 6000 Blackwell MIG instances instead of H200 instances?
If yes, why is this not clearly documented?
- 2 replies