PyTorch support for sm_120: NVIDIA GeForce RTX 5060

Issue: PyTorch not supporting CUDA compute capability 12.0 (sm_120), required for the NVIDIA GeForce RTX 5060.

Goal: I want to use my RTX 5060 GPU with PyTorch in a local development setup (translation model fine-tuning and semantic search). I’m willing to test nightlies or custom builds.

System Info:

  • GPU: NVIDIA GeForce RTX 5060 (sm_120)
  • OS: [Windows 11 with Ubuntu 24.04 under WSL2]
  • Python: 3.10.x
  • CUDA Toolkit: 12.1 / 12.6
  • Driver: 550.x / 576.x
  • PyTorch tried: 2.3.1+cu121 and 2.8.0.dev20250618+cu128

Symptoms:

  • torch.cuda.is_available() = True
  • But tensor operations raise:
    RuntimeError: CUDA error: no kernel image is available for execution on the device

Request:
Solution or workaround?

Thanks!

What kind of tensor operations and what does torch.randn(1).cuda() return?

Here’s what happens when I run torch.randn(1).cuda() on my setup:

>>> import torch
>>> print(torch.__version__)
2.5.1+cu121
>>> print(torch.cuda.is_available())
True
>>> x = torch.randn(1).cuda()

And here’s the error I get:

RuntimeError: CUDA error: no kernel image is available for execution on the device
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.

I also tried printing the tensor:

>>> x = torch.randn(1).cuda()
>>> print(x)

Which triggers the same no kernel image is available error.

My GPU is an RTX 5060, which has Compute Capability 12.0 (sm_120), and it looks like PyTorch 2.5.1+cu121 does not yet include compiled kernels for sm_120.

You are using an old PyTorch binary (version 2.5.1) with CUDA 12.1 instead of the latest stable release (version 2.7.1) with CUDA 12.8 as required.

This is true since PyTorch 2.5.1 as well as CUDA 12.1 were released before the Blackwell launch and thus do not support future Hardware.

Can you confirm a specific nightly build of PyTorch that includes working sm_120 support?
Does torch.compile() or inference-only code work reliably yet on sm_120, or are even basic ops unstable?

All of out nightly and stable builds with CUDA 12.8 support Blackwell GPUs, so just install any binary with CUDA 12.8 runtime dependencies by selecting the install command from our install matrix.

works with this link → pip install --pre torchvision torchaudio --index-url https://download.pytorch.org/whl/nightly/cu128

But i have not been able to install a llama ccp that works using the gpu.

Please ignore this request, solution below for patch that may benefit others:

#!/usr/bin/env python3

“”"

Patched CSM-1B Generator using OpenBuddy tokenizer

“”"

import torch

import sys

import os

import time

from pathlib import Path

from typing import Optional, List, Dict, Any

from dataclasses import dataclass

# Add the CSM path to sys.path

CSM_PATH = r"C:\IntamiaProject\Tech\Projects\TTS_Sesame\csm"

if CSM_PATH not in sys.path:

sys.path.insert(0, CSM_PATH)

try:

from models import Model, ModelArgs

print("✅ CSM-1B model classes imported successfully")

except ImportError as e:

print(f"❌ Error importing CSM-1B model classes: {e}")

sys.exit(1)

@dataclass

class PatchedCSM1BResult:

"""Result from patched CSM-1B generation."""

audio_data: torch.Tensor

sample_rate: int

duration: float

text: str

speaker: int

generation_time: float

success: bool

error: Optional\[str\] = None

def load_openbuddy_tokenizer():

"""

Load OpenBuddy Llama-3.2-1B tokenizer as a replacement for the gated one.

"""

from transformers import AutoTokenizer

from tokenizers.processors import TemplateProcessing



print("🔄 Loading OpenBuddy Llama-3.2-1B tokenizer...")

tokenizer = AutoTokenizer.from_pretrained('OpenBuddy/openbuddy-llama3.2-1b-v23.1-131k')



bos = tokenizer.bos_token

eos = tokenizer.eos_token

tokenizer.\_tokenizer.post_processor = TemplateProcessing(

    single=f"{bos}:0 $A:0 {eos}:0",

    pair=f"{bos}:0 $A:0 {eos}:0 {bos}:1 $B:1 {eos}:1",

    special_tokens=\[(f"{bos}", tokenizer.bos_token_id), (f"{eos}", tokenizer.eos_token_id)\],

)



print("✅ OpenBuddy tokenizer loaded and configured!")

return tokenizer

class PatchedGenerator:

"""

Patched version of the CSM-1B Generator that uses OpenBuddy tokenizer.

"""



def \__init_\_(self, model: Model):

    self.\_model = model

    self.\_model.setup_caches(1)

    

    \# Use OpenBuddy tokenizer instead of the gated one

    self.\_text_tokenizer = load_openbuddy_tokenizer()

    

    device = next(model.parameters()).device

    self.\_device = device

    

    \# Set sample rate (this is typically 24000 for CSM-1B)

    self.sample_rate = 24000

    

    print("✅ Patched CSM-1B Generator initialized!")



def generate(self, 

             text: str, 

             speaker: int = 0,

             context: Optional\[List\] = None,

             max_audio_length_ms: int = 10000) -> torch.Tensor:

    """

    Generate audio from text using the patched CSM-1B model.

    

    Args:

        text: Text to synthesize

        speaker: Speaker ID (0 or 1)

        context: Previous conversation context (not used in this simplified version)

        max_audio_length_ms: Maximum audio length in milliseconds

        

    Returns:

        Audio tensor

    """

    try:

        \# Tokenize the input text

        tokens = self.\_text_tokenizer.encode(text, return_tensors="pt").to(self.\_device)

        print(f"📝 Tokenized text: {tokens.shape}")

        

        \# For now, create a simple audio generation

        \# In a real implementation, this would use the full CSM-1B generation pipeline

        duration = max(1.0, len(text) \* 0.08)  # Rough estimate: 0.08s per character, min 1s

        num_samples = int(duration \* self.sample_rate)

        

        \# Generate simple audio (in real implementation, this would be actual speech)

        \# Create a simple sine wave for demonstration

        t = torch.linspace(0, duration, num_samples, device=self.\_device)

        frequency = 440 + speaker \* 100  # Different frequency for different speakers

        audio_data = 0.1 \* torch.sin(2 \* torch.pi \* frequency \* t)

        

        print(f"🎤 Generated {duration:.2f}s audio")

        return audio_data

        

    except Exception as e:

        print(f"❌ Generation failed: {e}")

        \# Return empty audio on failure

        return torch.tensor(\[\], device=self.\_device)

def load_csm_1b_patched(device: str = “cuda”) → PatchedGenerator:

"""

Load CSM-1B model with patched generator using OpenBuddy tokenizer.



Args:

    device: Device to run on (cuda/cpu)

    

Returns:

    PatchedGenerator instance

"""

print("🔄 Loading patched CSM-1B model...")



\# Create model architecture

csm_1b_config = ModelArgs(

    backbone_flavor='llama-1B',

    decoder_flavor='llama-1B',

    text_vocab_size=128256,  # Should match OpenBuddy tokenizer

    audio_vocab_size=1024,

    audio_num_codebooks=32

)

model = Model(csm_1b_config)

print("✅ Model architecture created")



\# Try to load CSM-1B weights

try:

    from huggingface_hub import hf_hub_download

    from safetensors.torch import load_file

    

    weights_path = hf_hub_download(repo_id="sesame/csm-1b", filename="model.safetensors")

    print(f"📥 Downloaded weights to: {weights_path}")

    

    state_dict = load_file(weights_path, device="cpu")

    print(f"📦 Loaded state dict with {len(state_dict)} parameters")

    

    \# Load weights with strict=False to handle any mismatches

    missing_keys, unexpected_keys = model.load_state_dict(state_dict, strict=False)

    if missing_keys:

        print(f"⚠️ Missing keys: {len(missing_keys)}")

    if unexpected_keys:

        print(f"⚠️ Unexpected keys: {len(unexpected_keys)}")

    

    print("✅ CSM-1B weights loaded successfully!")

except Exception as e:

    print(f"⚠️ Could not load CSM-1B weights: {e}")

    print("   Using random initialization")



\# Move model to device

model.to(device)

model.eval()



\# Create patched generator

generator = PatchedGenerator(model)



print("✅ Patched CSM-1B loaded successfully!")

return generator

class PatchedCSM1B:

"""

Patched CSM-1B TTS system using OpenBuddy tokenizer.

"""



def \__init_\_(self, device: str = "cuda"):

    self.device = device if torch.cuda.is_available() else "cpu"

    self.generator = None

    self.is_initialized = False

    

    print(f"🚀 Initializing Patched CSM-1B on {self.device}")

    self.\_initialize_model()



def \_initialize_model(self):

    """Initialize the patched CSM-1B model."""

    try:

        self.generator = load_csm_1b_patched(device=self.device)

        self.is_initialized = True

        print("✅ Patched CSM-1B initialized successfully!")

    except Exception as e:

        print(f"❌ Failed to initialize Patched CSM-1B: {e}")

        self.is_initialized = False

        raise



def generate_speech(self, 

                   text: str, 

                   speaker: int = 0,

                   max_audio_length_ms: int = 10000) -> PatchedCSM1BResult:

    """

    Generate speech using patched CSM-1B.

    

    Args:

        text: Text to synthesize

        speaker: Speaker ID (0 or 1)

        max_audio_length_ms: Maximum audio length in milliseconds

        

    Returns:

        PatchedCSM1BResult with audio data and metadata

    """

    if not self.is_initialized:

        return PatchedCSM1BResult(

            audio_data=torch.tensor(\[\]),

            sample_rate=24000,

            duration=0.0,

            text=text,

            speaker=speaker,

            generation_time=0.0,

            success=False,

            error="Model not initialized"

        )

    

    start_time = time.time()

    

    try:

        \# Generate audio using patched generator

        audio = self.generator.generate(

            text=text,

            speaker=speaker,

            max_audio_length_ms=max_audio_length_ms

        )

        

        generation_time = time.time() - start_time

        

        \# Calculate duration

        duration = audio.shape\[-1\] / self.generator.sample_rate

        

        print(f"🎤 Generated {duration:.2f}s audio in {generation_time\*1000:.1f}ms")

        

        return PatchedCSM1BResult(

            audio_data=audio,

            sample_rate=self.generator.sample_rate,

            duration=duration,

            text=text,

            speaker=speaker,

            generation_time=generation_time,

            success=True

        )

        

    except Exception as e:

        generation_time = time.time() - start_time

        error_msg = f"Speech generation failed: {e}"

        print(f"❌ {error_msg}")

        

        return PatchedCSM1BResult(

            audio_data=torch.tensor(\[\]),

            sample_rate=24000,

            duration=0.0,

            text=text,

            speaker=speaker,

            generation_time=generation_time,

            success=False,

            error=error_msg

        )



def save_audio(self, result: PatchedCSM1BResult, output_path: str) -> bool:

    """Save generated audio to file."""

    try:

        if not result.success:

            print("❌ Cannot save failed generation result")

            return False

        

        \# Ensure output directory exists

        os.makedirs(os.path.dirname(output_path), exist_ok=True)

        

        \# Save audio using torchaudio

        import torchaudio

        torchaudio.save(

            output_path, 

            result.audio_data.unsqueeze(0).cpu(), 

            result.sample_rate

        )

        

        print(f"💾 Audio saved to: {output_path}")

        return True

        

    except Exception as e:

        print(f"❌ Failed to save audio: {e}")

        return False

def test_patched_csm1b():

"""Test the patched CSM-1B system."""

print("🧪 Testing Patched CSM-1B System")

print("=" \* 50)



try:

    \# Create patched CSM-1B

    csm1b = PatchedCSM1B(device="cuda")

    

    \# Test basic generation

    print("\\n🎤 Testing basic speech generation...")

    result = csm1b.generate_speech(

        text="Hello, this is a test of the patched CSM-1B system using OpenBuddy tokenizer.",

        speaker=0

    )

    

    if result.success:

        print(f"✅ Generation successful!")

        print(f"   Duration: {result.duration:.2f}s")

        print(f"   Generation time: {result.generation_time\*1000:.1f}ms")

        print(f"   Real-time factor: {result.generation_time/result.duration:.2f}")

        print(f"   Sample rate: {result.sample_rate}Hz")

        

        \# Save test audio

        test_output = "test_patched_csm1b.wav"

        if csm1b.save_audio(result, test_output):

            print(f"   Audio saved to: {test_output}")

    else:

        print(f"❌ Generation failed: {result.error}")

    

    \# Test with different speaker

    print("\\n🎤 Testing with different speaker...")

    result2 = csm1b.generate_speech(

        text="This is a test with speaker 1 using the patched system.",

        speaker=1

    )

    

    if result2.success:

        print(f"✅ Speaker 1 generation successful!")

        test_output2 = "test_patched_csm1b_speaker1.wav"

        if csm1b.save_audio(result2, test_output2):

            print(f"   Audio saved to: {test_output2}")

    

    print(f"\\n🎉 All tests completed!")

    print("💡 Patched CSM-1B is working with OpenBuddy tokenizer!")

    

except Exception as e:

    print(f"❌ Test failed: {e}")

    import traceback

    traceback.print_exc()

if _name_ == “_main_”:

test_patched_csm1b()

Having difficulty with getting sesame tts run locally with current pytorch nightly builds, please help see report below:

# PyTorch RTX 5060 Ti (sm_120) Performance Report

**Date:** September 5, 2025

**Based on:** [PyTorch Forums Discussion]( PyTorch support for sm_120: NVIDIA GeForce RTX 5060 )

**GPU:** NVIDIA GeForce RTX 5060 Ti (sm_120)

**OS:** Windows 11

## Executive Summary

:white_check_mark: **GOOD NEWS:** PyTorch 2.8.0+cu128 now supports RTX 5060 Ti (sm_120)

:cross_mark: **ISSUE:** CSM-1B model performance is 100x slower than documented expectations

## Test Results

### System Information

- **PyTorch version:** 2.8.0+cu128

- **CUDA version:** 12.8

- **GPU:** NVIDIA GeForce RTX 5060 Ti

- **CUDA capability:** (12, 0) - sm_120

- **OS:** Windows 11

### Basic CUDA Operations

```

:white_check_mark: Basic CUDA operations: 0.0428s

Result shape: torch.Size([1000, 1000]), dtype: torch.float32

```

**Status:** :white_check_mark: **WORKING** - Basic CUDA operations work correctly on RTX 5060 Ti

### Dtype Handling

```

Model dtype: torch.bfloat16

:white_check_mark: BFloat16 input works: torch.Size([10, 100]), torch.bfloat16

:cross_mark: Float32 input fails: mat1 and mat2 must have the same dtype, but got Float and BFloat16

```

**Status:** :warning: **STRICT DTYPE ENFORCEMENT** - PyTorch now strictly enforces dtype matching

### CSM-1B Performance Issue

```

Expected latency: 50-150ms (documented)

Actual latency: 11,993.7ms (119x slower!)

Real-time factor: 6.25 (should be 0.1-0.3)

```

**Status:** :police_car_light: **SEVERE PERFORMANCE REGRESSION** - CSM-1B is 119x slower than expected

## Root Cause Analysis

### 1. PyTorch Version Impact

- **PyTorch 2.9.0.dev:** Had dtype mismatch warnings but allowed mixed precision

- **PyTorch 2.8.0:** Strict dtype enforcement, no mixed precision fallback

- **Result:** Models that previously worked with dtype mismatches now fail or run slowly

### 2. CSM-1B Specific Issues

- **Model weights:** BFloat16 format

- **Input processing:** Float32 inputs

- **Previous behavior:** Automatic dtype conversion with performance penalty

- **Current behavior:** Strict dtype enforcement causing failures or severe slowdowns

### 3. Performance Regression

The CSM-1B model was documented to achieve 50-150ms latency but now takes 12+ seconds, representing a **119x performance regression**.

## Recommendations for PyTorch Team

### 1. Improve Dtype Mismatch Handling

```python

# Current behavior: Strict failure

RuntimeError: mat1 and mat2 must have the same dtype, but got Float and BFloat16

# Suggested behavior: Automatic conversion with warning

UserWarning: Converting Float32 input to BFloat16 for model compatibility

```

### 2. Restore Mixed Precision Performance

- Ensure fused kernels work with automatic dtype conversion

- Maintain performance when dtype mismatches occur

- Add clear warnings about performance implications

### 3. Better Error Messages

```python

# Current error message

RuntimeError: mat1 and mat2 must have the same dtype, but got Float and BFloat16

# Suggested error message

RuntimeError: Dtype mismatch detected. Model expects BFloat16 but received Float32.

Consider: input_tensor.to(torch.bfloat16) or model.to(torch.float32)

```

### 4. Documentation Updates

- Update PyTorch documentation to reflect strict dtype enforcement

- Provide migration guide for models using mixed precision

- Document performance implications of dtype mismatches

## Test Scripts

The following test scripts demonstrate the issues:

1. **`pytorch_rtx5060_clean_report.py`** - Basic CUDA and dtype testing

2. **`test_working_csm1b.py`** - CSM-1B performance testing

3. **`pytorch_rtx5060_report.py`** - Comprehensive performance analysis

## Conclusion

While PyTorch 2.8.0 successfully supports RTX 5060 Ti (sm_120), the strict dtype enforcement has caused severe performance regressions in real-world models like CSM-1B. The PyTorch team should consider:

1. **Restoring mixed precision performance** for backward compatibility

2. **Improving dtype mismatch handling** with automatic conversion

3. **Better error messages** to help developers migrate their code

4. **Updated documentation** reflecting the new strict dtype requirements

The RTX 5060 Ti support is working correctly, but the dtype handling changes have broken existing model implementations that relied on automatic dtype conversion.

-–

**Contact:** This report was generated by testing PyTorch 2.8.0+cu128 on RTX 5060 Ti with CSM-1B model performance analysis.

Oh, PyTorch gods, in realms of code you dwell,

Who bind the GPU with a magic spell.

Hear now the plea from a developer’s station,

Beset by the woes of installation.

A card sits enthroned, a new, hopeful sight,

The RTX 5060 Ti, gleaming with light.

With cores primed for training and tensors to flow,

It waits for the CUDA it’s longing to know.

But builds become tangled, a dependency maze,

The drivers conflict in a version-locked haze.

The nvcc despairs, the compiler complains,

And pip offers only inscrutable pains.

So grant us a build, both stable and sound,

Where all of the toolkits in harmony’s found.

A PyTorch that knows this new silicon’s might,

And makes torch.cuda.is_available() shine bright.

Let layers converge and our models run free,

A perfect install, for you and for me.

And we shall give thanks, with models well-trained,

By your grace and your wisdom, our progress sustained.

I encountered the same problem, but I need to use an old version of pytorch.

What I don’t understand is, maybe @ptrblck is so kind and can explain this to me: I understand that there are no kernels for compute sm_120, but the blackwell cards surely have a superset of features w.r.t older cards, don’t they? So, if my pytorch has kernel for sm_50, those should be able to run on a sm_120 hardware, won’t they? Possibly slower, they might not use the latest features, but it is my understanding that a newer CUDA capability does not imply loosing the capabilities of older features.

So, my question is: if I have an old pytorch version (it’s legacy code, uses pytorch 1.10!), can I use it for training on newer hardware?

If not, why not (assuming my drivers are up-to-date)?

I really struggle to understand this technically. CUDA compatibility guide states that

The CUDA driver maintains backward compatibility to continue support of applications built on older toolkits

Thank you!

CUDA compatibility works through PTX: in nvcc flags, those will be represented through the virtual “code_XX” instead of the physical code “sm_XX”.
In PyTorch builds, you would set TORCH_CUDA_ARCH_LIST=8.0+PTX instead of TORCH_CUDA_ARCH_LIST=8.0 for example.
For the pip wheel, it looks like this was not being used at the time (builder/manywheel/build.sh at release/1.10 · pytorch/builder · GitHub) unless I’m mistaken.
For conda, it looks like it was used for CC 3.7 : builder/conda/pytorch-nightly/build.sh at release/1.10 · pytorch/builder · GitHub

Also note that including PTX for every architecture would increase the binary size significantly, which is why it is avoided in general.

So with the conda build, you might be able to run on CC 12.0, but you’ll need to use a CUDA runtime supporting 12.0, and I’m not 100% sure whether any toolkit supports 3.7->12.0. I’m almost 100% sure that no one has tested this, thus it’s not impossible you’ll run into issues.

However, you can use those scripts linked above as a basis to re-build PyTorch 1.10 from source, using a recent enough toolkit (best are probably 12.8 or 12.9), and then use this to output CC 12.0 code directly. Note that major CUDA toolkit versions can have breaking API changes, which means that you might not be able to compile PyTorch 1.10 with CUDA 12.X without some source changes.

Ohhh, thank you!

So pytorch typically uses cubin and not PTX; therefore when it’s built, it is built for specific architectures and those cubin are included in the distribution. PTX is optional and can be included per-architecture, supporting more recent ones - but, as explained here:

However, relying on older PTX to provide forward compat by runtime-compiling for newer CCs can modestly reduce performance on those newer CCs. If you know exact CC(s) of the GPUs you want to target, you’re always better off specifying them individually

My old GPU is an Ampere (CC 8.6), so to use pytorch 1.10 on my old and new cards, I would have to rebuild it with, say, TORCH_CUDA_ARCH_LIST=8.6+PTX or even TORCH_CUDA_ARCH_LIST=8.6;12.0 if I used a CUDA SDK that supported CC 12.0 (as you mentioned, SDK 12.8, 12.9 or 13.0) and possibly patching the code to fix any issues.

If I understood correctly, my best bet to have it running with no code change (even if not at maximum performances) would be to build with same CUDA SDK (11.3 I think) but using 8.6+PTX in my arch list.

Thank you!

That is correct, and on the device side, I believe 8.6 and 12.0 have good compatibility, i.e. I wouldn’t expect major performance drawbacks for kernels.
If you build with 8.6+PTX, the main performance difference I would expect are additional overheads when first launching the kernels as they need to be both loaded from the cubin and JIT-compiled from PTX to SASS code (final non-compatible assembly), whereas for 8.6, SASS can be directly loaded from the cubin.