GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — fix: restore sm_60 (P100) PyTorch kernels in GPU image (best-effort, unverified against real fleet) by shivansh193 · Pull Request #1561 · Kaggle/docker-python

Conversation

@shivansh193

@shivansh193 shivansh193 commented Sep 5, 2026

Copy link
Copy Markdown

What

Fixes #1546 (Tesla P100 / sm_60 + recent PyTorch build incompatibility). For GPU images only, reinstalls the same torch/torchvision/torchaudio version already selected by the Colab base image, but from the cu126 wheel index instead of whichever CUDA index the base image used (currently cu128).

Root cause (as I found it)

  • The GPU image is FROM us-docker.pkg.dev/colab-images/public/runtime:.... Dockerfile.tmpl doesn't install PyTorch directly — it pip freezes the base image's existing torch/torchvision/etc. versions into /colab_requirements.txt and reinstalls those exact versions (see lines 9-17). So the actual PyTorch wheel/CUDA-index choice is inherited from the upstream Colab image, not controlled by anything in this repo today.
  • Per the issue thread and my own check of pytorch/pytorch's current .ci/manywheel/build_env_setup.py (TORCH_CUDA_ARCH_LIST_TABLE), PyTorch's officially published wheels have per-CUDA-version compute-capability sets, e.g.:
    • cu126 → {50, 60, 70, 75, 80, 86, 90} (x86_64) — includes sm_60
    • newer CUDA lines (matching the sm_70 sm_75 sm_80 sm_86 sm_90 sm_100 sm_120 reported in the issue and in torch.cuda's own startup warning) drop sm_50/sm_60 in exchange for sm_100/sm_120 (Blackwell) support.
  • This matches multiple comments on Pytorch CUDA P100 GPU Incompatibility #1546: reinstalling the same torch version from --index-url https://download.pytorch.org/whl/cu126 was independently found by users to fix P100, while leaving T4 (sm_75) unaffected.
  • I also noticed tests/common.py already has a long-standing p100_exempt test decorator (b/342143152 P100s are slowly being unsupported in new release of popular ml tools such as RAPIDS), and tests/test_pytorch.py's p100_exempt-marked tests (test_gpu_computation, a .sum() reduction; test_linalg) line up exactly with the failure mode reported in Pytorch CUDA P100 GPU Incompatibility #1546 and its comments. So this appears to be a recurring, known category of breakage rather than a one-off regression, which is part of why I think a build-level fix is worth proposing rather than only a per-user workaround.

The change

In Dockerfile.tmpl, right after the existing "Install Kaggle packages" step (which installs whatever torch version the base image already has), add a GPU-only step that force-reinstalls the same torch/torchvision/torchaudio version from the cu126 index:

{{ if eq .Accelerator "gpu" }}
RUN TORCH_VERSION=$(python -c "import torch; print(torch.__version__.split('+')[0])") && \
    uv pip install --system --no-cache --force-reinstall \
        "torch==${TORCH_VERSION}" torchvision torchaudio \
        --index-url https://download.pytorch.org/whl/cu126 \
        --extra-index-url https://pypi.org/simple
{{ end }}

I deliberately did not hardcode a torch version — it reads back whatever version is already installed (from the base image) and re-pulls that same version's cu126 build, so this doesn't fight the existing "freeze the base image's version" mechanism and shouldn't need to be bumped every time the Colab base image updates. It's scoped to the GPU template branch only; I rendered Dockerfile.tmpl locally with renderizer --ACCELERATOR=gpu and --ACCELERATOR=none to confirm the new block only appears in the GPU output.

What I could not verify

I don't have access to Kaggle's build pipeline, its Jenkins GPU executors, or an actual P100/T4 to test against, so I could not:

  • Actually build this Dockerfile against the real base image and confirm the install succeeds without dependency conflicts (e.g. other packages in kaggle_requirements.txt or the base image that may have been compiled/linked against the cu128 build's ABI — I don't have visibility into whether anything like that exists).
  • Confirm on real hardware that this restores P100 functionality end-to-end (only that PyTorch's own published cu126 wheel arch table includes sm_60, and that this specific cu128→cu126 swap-at-same-version was independently reported to work by commenters on Pytorch CUDA P100 GPU Incompatibility #1546).
  • Confirm there isn't a newer/better-supported PyTorch release line that covers both sm_60 and sm_100/120 simultaneously — as far as I could tell from PyTorch's current build matrix, that combination isn't offered in any single official wheel today, so this is a "pick one" tradeoff, not a strict win.

So please treat this as a best-effort, plausible starting point for someone with access to your actual CI/build pipeline to verify and adjust, not a guaranteed-correct fix.

Other context I noticed while investigating

While looking through recent branches/PRs I came across #1560 ("chore: drop P100 from the CI pipeline"), which is tearing down the P100 Jenkins CI/build agent. I don't know if that reflects a broader decision to deprecate P100 as a user-facing accelerator too, in which case this PR may be moot — flagging it in case it's useful context for triage, and apologies in advance if this duplicates effort already in flight internally.

Scope

This only touches Dockerfile.tmpl's GPU branch. I did not touch tests, CI, or anything else, per the intent of keeping this change minimal and targeted at the specific issue.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@shivansh193
fix: restore sm_60 (P100) PyTorch kernels in GPU image
66f3db1
The Colab GPU base image ships PyTorch built against a CUDA wheel
index (currently cu128) whose compute-capability list is
sm_70/75/80/86/90/100/120 -- it drops sm_60 (Pascal, e.g. the Tesla
P100 Kaggle's scheduler still assigns as a free GPU option). Any real
GPU op on a P100 then fails with "CUDA error: no kernel image is
available for execution on the device", even for plain fp16
model.generate() calls with no quantization involved.

PyTorch's cu126 wheels are still built for {50,60,70,75,80,86,90}
(verified against pytorch/pytorch's
.ci/manywheel/build_env_setup.py arch table), so for GPU images only,
reinstall the *same* torch/torchvision/torchaudio version from the
cu126 index instead of whatever the base image pulled. This restores
sm_60 while keeping every GPU Kaggle currently offers (T4, sm_75)
working. The tradeoff is losing sm_100/sm_120 (Blackwell) kernels,
which Kaggle does not currently offer as a notebook accelerator.

Fixes Kaggle#1546
@google-cla

google-cla Bot commented Sep 5, 2026

Copy link
Copy Markdown

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@calderjo

calderjo commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Hey Kaggle staff here, i saw that you mention a PR i am working on

note that google cloud is deprecating p100s which Kaggle relies on:
https://www.kaggle.com/discussions/product-announcements/735239

Kaggle team is working on moving users over to T4 for new notebooks and sessions,
and we have no intention of maintaining p100 support in future docker image releases.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

shivansh193 added a commit to shivansh193/hippovoice that referenced this pull request Sep 5, 2026
@shivansh193 @claude
feat: validate top_k=10 as a real F1 improvement via Kaggle sweep
b2dc80f
A coordinate-descent sweep (decay_lambda x relevance_weight x top_k) on
Kaggle found top_k as the actual driver of a real improvement: 24.1% ->
27.74% avg F1 on the full 1540-question LoCoMo set, with the whole score
distribution shifting favorably (fewer near-zero, more partial and high),
not just the mean. decay_lambda and relevance_weight landed at values
statistically indistinguishable from the existing defaults.

Deliberately did not bump run_locomo()'s shared top_k default (still 5) --
Mem0-style/A-MEM-style were both run at top_k=5 and haven't been re-swept,
so changing the shared default would silently make the README comparison
table apples-to-oranges. scripts/run_full_locomo.py and colab.ipynb's
LoCoMo cell both opt into top_k=10 explicitly for HippoVoice only.

Also documents a real, currently-open Kaggle platform bug hit while
running the sweep (P100 GPU assignment + a PyTorch build with zero
compiled kernels for that architecture), the --accelerator NvidiaTeslaT4
workaround, and a good-faith upstream fix attempt at
Kaggle/docker-python#1561.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
shivansh193 added a commit to shivansh193/hippovoice that referenced this pull request Sep 28, 2026
@shivansh193
feat: validate top_k=10 as a real F1 improvement via Kaggle sweep
7f7989e
A coordinate-descent sweep (decay_lambda x relevance_weight x top_k) on
Kaggle found top_k as the actual driver of a real improvement: 24.1% ->
27.74% avg F1 on the full 1540-question LoCoMo set, with the whole score
distribution shifting favorably (fewer near-zero, more partial and high),
not just the mean. decay_lambda and relevance_weight landed at values
statistically indistinguishable from the existing defaults.

Deliberately did not bump run_locomo()'s shared top_k default (still 5) --
Mem0-style/A-MEM-style were both run at top_k=5 and haven't been re-swept,
so changing the shared default would silently make the README comparison
table apples-to-oranges. scripts/run_full_locomo.py and colab.ipynb's
LoCoMo cell both opt into top_k=10 explicitly for HippoVoice only.

Also documents a real, currently-open Kaggle platform bug hit while
running the sweep (P100 GPU assignment + a PyTorch build with zero
compiled kernels for that architecture), the --accelerator NvidiaTeslaT4
workaround, and a good-faith upstream fix attempt at
Kaggle/docker-python#1561.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Pytorch CUDA P100 GPU Incompatibility

Uh oh!

There was an error while loading. Please reload this page.

2 participants

@shivansh193 @calderjo
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.