pytorch - ✅(Solved) Fix CTC loss cuDNN backend ignores `zero_infinity=True` [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
pytorch/pytorch#176910Fetched 2026-04-08 00:23:56
View on GitHub
Comments
1
Participants
1
Timeline
51
Reactions
0
Participants
Timeline (top)
mentioned ×15subscribed ×15labeled ×10referenced ×4

Fix Action

Fix / Workaround

CPU: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 48 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 30 On-line CPU(s) list: 0-29 Vendor ID: AuthenticAMD Model name: AMD EPYC 7J13 64-Core Processor CPU family: 25 Model: 1 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 30 Stepping: 1 BogoMIPS: 4899.99 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw perfctr_core ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves clzero xsaveerptr wbnoinvd arat npt nrip_save umip pku ospke vaes vpclmulqdq rdpid fsrm arch_capabilities Virtualization: AMD-V Hypervisor vendor: KVM Virtualization type: full L1d cache: 1.9 MiB (30 instances) L1i cache: 1.9 MiB (30 instances) L2 cache: 15 MiB (30 instances) L3 cache: 480 MiB (30 instances) NUMA node(s): 1 NUMA node0 CPU(s): 0-29 Vulnerability Gather data sampling: Not affected Vulnerability Indirect target selection: Not affected Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Mmio stale data: Not affected Vulnerability Reg file data sampling: Not affected Vulnerability Retbleed: Not affected Vulnerability Spec rstack overflow: Vulnerable: Safe RET, no microcode Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected Vulnerability Srbds: Not affected Vulnerability Tsa: Vulnerable: Clear CPU buffers attempted, no microcode Vulnerability Tsx async abort: Not affected Vulnerability Vmscape: Not affected

PR fix notes

PR #176911: Fix behavor of CTC loss cuDNN backend when zero_infinity=True

Description (problem / solution / changelog)

This PR addresses and fixes #176910.

I've arranged this PR into 4 commits to make it easier to reproduce the issues and verify that they have been resolved:

  1. Adds a test that the loss is set to zero correctly, which fails.
  2. Patches the CTC loss to fix the above test.
  3. Adds a test that the gradients are set to zero correctly, which fails.
  4. Patches the CTC loss backwards function to fix the above test.

Both tests employ the private function torch._use_cudnn_ctc_loss to ensure the cuDNN backend is used. The second test additionally uses torch._cudnn_ctc_loss with deterministic=False. The reason for this is that I was unable to find examples that genuinely produced infinite gradients from cuDNN's deterministic implementation (which is the only one available through the public API), even when zero_infinity=False (likely due to this backend's unusual behavior, as described in #176910). Please let me know if this approach should be modified.

Changed files

  • aten/src/ATen/native/LossCTC.cpp (modified, +4/-3)
  • test/test_nn.py (modified, +55/-0)
  • torch/csrc/autograd/FunctionsManual.cpp (modified, +1/-1)

Code Example

import torch
probs = torch.nn.functional.one_hot(torch.tensor([0], device='cuda'), num_classes=2).float()
log_probs = torch.log(probs).unsqueeze(1).requires_grad_()
targets = torch.tensor([1], device='cuda', dtype=torch.int32)
input_lengths = torch.tensor([1], device='cuda', dtype=torch.int32)
target_lengths = torch.tensor([1], device='cuda', dtype=torch.int32)
loss = torch.nn.functional.ctc_loss(
    log_probs, targets, input_lengths, target_lengths, reduction='sum', zero_infinity=True
)
assert torch.isfinite(loss)

---

import torch
device = 'cuda'
log_probs = torch.nn.functional.log_softmax(torch.randn(2, 1, 3, device=device), dim=-1)
targets = torch.tensor([0, 0], device=device, dtype=torch.int32)
input_lengths = torch.tensor([2], device=device, dtype=torch.int32)
target_lengths = torch.tensor([2], device=device, dtype=torch.int32)
loss = torch.nn.functional.ctc_loss(
    log_probs, targets, input_lengths, target_lengths, reduction='sum', zero_infinity=False
)
assert torch.isfinite(loss)
RAW_BUFFERClick to expand / collapse

🐛 Describe the bug

The zero_infinity parameter in torch.nn.functional.ctc_loss currently has no effect when the cuDNN backend is used. For example, the following raises an AssertionError, even though zero_infinity=True:

import torch
probs = torch.nn.functional.one_hot(torch.tensor([0], device='cuda'), num_classes=2).float()
log_probs = torch.log(probs).unsqueeze(1).requires_grad_()
targets = torch.tensor([1], device='cuda', dtype=torch.int32)
input_lengths = torch.tensor([1], device='cuda', dtype=torch.int32)
target_lengths = torch.tensor([1], device='cuda', dtype=torch.int32)
loss = torch.nn.functional.ctc_loss(
    log_probs, targets, input_lengths, target_lengths, reduction='sum', zero_infinity=True
)
assert torch.isfinite(loss)

A similar issue applies to the gradients.

I believe this issue may have gone unnoticed for some time due to cuDNN's unusual behavior for inputs that should cause a divergence. For instance, the following does not raise an AssertionError (though zero_infinity=False):

import torch
device = 'cuda'
log_probs = torch.nn.functional.log_softmax(torch.randn(2, 1, 3, device=device), dim=-1)
targets = torch.tensor([0, 0], device=device, dtype=torch.int32)
input_lengths = torch.tensor([2], device=device, dtype=torch.int32)
target_lengths = torch.tensor([2], device=device, dtype=torch.int32)
loss = torch.nn.functional.ctc_loss(
    log_probs, targets, input_lengths, target_lengths, reduction='sum', zero_infinity=False
)
assert torch.isfinite(loss)

This should be compared with the case device = 'cpu' (or in which cuDNN is disabled).

I have a fix ready and will open an MR shortly.

Versions

Collecting environment information... PyTorch version: 2.12.0a0+gitaee4170 Is debug build: False CUDA used to build PyTorch: 13.0 ROCM used to build PyTorch: N/A

OS: Ubuntu 24.04.4 LTS (x86_64) GCC version: (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 Clang version: Could not collect CMake version: version 4.2.3 Libc version: glibc-2.39

Python version: 3.11.14 (main, Feb 12 2026, 00:42:50) [Clang 21.1.4 ] (64-bit runtime) Python platform: Linux-6.8.0-1046-nvidia-x86_64-with-glibc2.39 Is CUDA available: True CUDA runtime version: 13.0.88 CUDA_MODULE_LOADING set to: GPU models and configuration: GPU 0: NVIDIA A100-SXM4-40GB Nvidia driver version: 580.126.20 cuDNN version: Probably one of the following: /usr/lib/x86_64-linux-gnu/libcudnn.so.9.19.1 /usr/lib/x86_64-linux-gnu/libcudnn_adv.so.9.19.1 /usr/lib/x86_64-linux-gnu/libcudnn_cnn.so.9.19.1 /usr/lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.19.1 /usr/lib/x86_64-linux-gnu/libcudnn_engines_runtime_compiled.so.9.19.1 /usr/lib/x86_64-linux-gnu/libcudnn_graph.so.9.19.1 /usr/lib/x86_64-linux-gnu/libcudnn_heuristic.so.9.19.1 /usr/lib/x86_64-linux-gnu/libcudnn_ops.so.9.19.1 Is XPU available: False HIP runtime version: N/A MIOpen runtime version: N/A Is XNNPACK available: False Caching allocator config: N/A

CPU: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 48 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 30 On-line CPU(s) list: 0-29 Vendor ID: AuthenticAMD Model name: AMD EPYC 7J13 64-Core Processor CPU family: 25 Model: 1 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 30 Stepping: 1 BogoMIPS: 4899.99 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw perfctr_core ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves clzero xsaveerptr wbnoinvd arat npt nrip_save umip pku ospke vaes vpclmulqdq rdpid fsrm arch_capabilities Virtualization: AMD-V Hypervisor vendor: KVM Virtualization type: full L1d cache: 1.9 MiB (30 instances) L1i cache: 1.9 MiB (30 instances) L2 cache: 15 MiB (30 instances) L3 cache: 480 MiB (30 instances) NUMA node(s): 1 NUMA node0 CPU(s): 0-29 Vulnerability Gather data sampling: Not affected Vulnerability Indirect target selection: Not affected Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Mmio stale data: Not affected Vulnerability Reg file data sampling: Not affected Vulnerability Retbleed: Not affected Vulnerability Spec rstack overflow: Vulnerable: Safe RET, no microcode Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected Vulnerability Srbds: Not affected Vulnerability Tsa: Vulnerable: Clear CPU buffers attempted, no microcode Vulnerability Tsx async abort: Not affected Vulnerability Vmscape: Not affected

Versions of relevant libraries: [pip3] Could not collect [conda] Could not collect

cc @ezyang @gchanan @kadeng @msaroufim @csarofeen @ptrblck @eqy @nWEIdia @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @xwang233

extent analysis

Fix Plan

Update PyTorch to the latest version

Update PyTorch to the latest version (2.12.0 or later) which includes the fix for the zero_infinity parameter issue.

Verify the fix

Run the following code snippet to verify the fix:

import torch
probs = torch.nn.functional.one_hot(torch.tensor([0], device='cuda'), num_classes=2).float()
log_probs = torch.log(probs).unsqueeze(1).requires_grad_()
targets = torch.tensor([1], device='cuda', dtype=torch.int32)
input_lengths = torch.tensor([1], device='cuda', dtype=torch.int32)
target_lengths = torch.tensor([1], device='cuda', dtype=torch.int32)
loss = torch.nn.functional.ctc_loss(
    log_probs, targets, input_lengths, target_lengths, reduction='sum', zero_infinity=True
)
assert torch.isfinite(loss)

This should pass without raising an AssertionError.

Disable cuDNN

As a temporary workaround, you can disable cuDNN by setting the torch.backends.cudnn.enabled flag to False. This will force PyTorch to use the CPU backend, which should work around the issue.

import torch
torch.backends.cudnn.enabled = False
# Run your code here

Note that disabling cuDNN may have performance implications, so this is only recommended as a temporary workaround.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

pytorch - ✅(Solved) Fix CTC loss cuDNN backend ignores `zero_infinity=True` [1 pull requests, 1 comments, 1 participants]