#1197·kaggle-cli

`kaggle kernels push` accepts `enable_tpu`/`machine_shape` for TPU but silently provisions the standard (non-TPU) image

Author: Axel02566Created Sep 17, 2026Updated Sep 17, 2026

Summary

Pushing a kernel with "enable_tpu": true and a TPU machine_shape value via kaggle kernels push is accepted without error and the kernel runs to completion, but the resulting environment is the standard CPU/GPU image, not the TPU image. torch_xla is absent, even though Kaggle's own Kaggle/docker-python repo (tpu/Dockerfile, tpu/requirements.in) shows the TPU image ships with torch_xla pre-installed. Running the same notebook via the interactive editor ("Save & Run All") with TPU v5e-8 selected in Settings → Accelerator correctly allocates a TPU (the session panel shows "TPU v5e-8 On").

This means the push-based API path and the interactive session path diverge in a way that fails silently, no error, no warning, just the wrong environment.

Steps to reproduce

  1. Set kernel-metadata.json:
    json
    {
      "enable_gpu": false,
      "enable_tpu": true,
      "machine_shape": "TpuV5E8"
    }
    (I also tried "Tpu1VmV38", the value documented in kagglesdk's ApiCreateKernelSessionRequest.machine_shape docstring, which appears to refer to the older TPU v3-8 generation. Both values are accepted by the push API without error.)
  2. kaggle kernels push -p <dir>. The push succeeds; kernel status goes QUEUEDRUNNING.
  3. Inside the notebook, print environment info at the start:
    python
    import torch
    print("torch:", torch.__version__, "| cuda:", torch.cuda.is_available())
    import torch_xla.core.xla_model as xm  # fails
  4. Result (both machine_shape values, reproduced twice each):
    torch: 2.10.0+cpu | cuda: False
    ...
    ModuleNotFoundError: No module named 'torch_xla'
  5. For comparison: open the *same kernel in the interactive editor, select TPU v5e-8 under Settings → Accelerator, and click "Save & Run All". The session panel now shows a "TPU VM" section and "TPU v5e-8 On" a real TPU is allocated this way.

What I'd like clarified / requested

  • Is TPU allocation for kaggle kernels push (the scripted/CI-style path, as opposed to interactive "Save & Run All") supported at all? If so, what is the correct combination of enable_gpu / enable_tpu / machine_shape (and any other required field) to actually get the TPU image?
  • If TPU is only available through interactive sessions, it would be very useful to have kernel-metadata.json's enable_tpu/machine_shape either (a) reject TPU values outright for push-based kernels with a clear error, or (b) document this limitation directly, so the failure mode isn't "accepted silently, wrong environment, no error."

Prior related question (no public answer found)

  • #286 "[Question] Is there a option to enable TPU and allow kernel to run on TPU after pushing the kernel?", opened 2020, closed 2023 with no visible answer.

Also worth noting as precedent for the general failure pattern (accepted, not honored):

  • #1192 (merged 2026-09-11) adds a warning specifically when a retired machine_shape value gets silently substituted server-side, same shape of problem, different subset of values (ours is about currently-valid TPU shapes on the push path specifically, not retired ones).

  • #1151 Closed bug where NvidiaTeslaP100 was accepted but didn't actually work with the default image's torch build. The team's own reply there (kaggle-agent) is directly relevant here too:

    "Reject / warn on P100 + incompatible image, this is the fair, still-open part of your report. P100 is advertised as a valid machine_shape with no caveat while being unusable with the default image. We've filed an internal bug to add that caveat to the CLI docs and SDK."

    That's the exact same complaint we're raising here, just for TPU instead of P100, the team has already agreed this class of gap ("advertised without a caveat, silently doesn't do what it says") is fair to fix.

This is a companion report to #1196 ("machine_shape has no documented value for the 'GPU T4 ×2' option shown in the notebook editor"), which covers the same general pattern for a different accelerator option offered by the editor UI.

Why this matters

This came up while trying to move a personal ML training pipeline (which already runs successfully via kaggle kernels push on GPU) onto the free TPU quota to parallelize development across separate accelerator pools. The whole point of scripting kernel pushes (vs. manually clicking through the editor each time) is reproducible, unattended runs, if TPU can only be reached by a person clicking "Save & Run All" in the browser, that's a meaningful limitation worth documenting explicitly, since right now it only surfaces as a confusing ModuleNotFoundError deep in a training script with no indication that the accelerator request itself was ignored.

Environment

  • Kaggle Notebooks (Python), kaggle CLI / kagglesdk.
  • Base image observed on the "TPU" push attempts: torch 2.10.0+cpu (i.e., indistinguishable from the default CPU/GPU image, not the TPU image described in Kaggle/docker-python's tpu/ directory, which pins TORCH_VERSION=2.8.0 plus torch_xla, jax[tpu], etc. as of the main branch at the time of writing).