| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
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
|
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. |
Sorry, something went wrong.
|
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: Kaggle team is working on moving users over to T4 for new notebooks and sessions, |
Sorry, something went wrong.
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 <noreply@anthropic.com>
| Back | FazBrowse Home | New Git URL |
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 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:
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.