Studio: install torch 2.11 on all modern CUDA (cu126/cu128/cu130) by ThomasEricB · Pull Request #6982 · unslothai/unsloth

ThomasEricB · 2026-07-08T15:08:51Z

Continuation of #6970.

Summary

Install torch 2.11 on all modern CUDA indexes. This adds a per-index TORCH_CONSTRAINT override in install.sh for cu126, cu128, and cu130, mirroring the existing rocm7.2 one, so fresh CUDA 12.6+/13 installs land on torch 2.11 where torchao 0.17's cpp extensions load. flash-attn / causal-conv1d / mamba already reuse their torch2.10 wheels on 2.11 (wheel_utils.prebuilt_wheel_torch_mm, from #6970).

case "$TORCH_INDEX_URL" in
    */rocm7.2) TORCH_CONSTRAINT="torch>=2.11.0,<2.12.0" ;;
    */cu130)   TORCH_CONSTRAINT="torch>=2.11.0,<2.12.0" ;;
    */cu128)   TORCH_CONSTRAINT="torch>=2.11.0,<2.12.0" ;;
    */cu126)   TORCH_CONSTRAINT="torch>=2.11.0,<2.12.0" ;;
esac

The default torch>=2.4,<2.11.0 is intentionally left untouched, so older CUDA (cu124/cu118), other ROCm tags, CPU, and macOS stay on the 2.10 family. torch 2.11 publishes no wheels for those indexes, so bumping the default would make old-driver fresh installs resolve a nonexistent wheel and fail. Keeping the default also keeps the "hardcoded torch>=2.4 appears exactly once" test guard valid. GPU-arch support is unchanged: cu126 2.11 keeps Maxwell/Pascal/Volta/Turing+, and cu128/cu130 are Turing (SM 7.5)+ exactly as their 2.10 counterparts were.

Verification

Structural test asserts each cu126/cu128/cu130 override is present; tests/sh/test_torch_constraint.sh is 28/28 and bash -n install.sh is clean. tests/python/test_tokenizers_and_torch_constraint.py and studio/backend/tests/test_torchao_select.py pass.

Stack smoke on both Blackwell tiers under torch 2.11.0+cu130:

RTX 5090 (sm_120): flash-attn, torchao (cutlass/mxfp8 kernels), bitsandbytes, xformers (cu130 build), triton, and unsloth's compiled kernels all load and run; vLLM 0.24 pins torch==2.11.0.
B200 (sm_100, compute cap 10.0), fresh torch 2.11.0+cu130 venv with the exact wheels the installer selects: torch stays 2.11.0+cu130, flash-attn 2.8.1 (torch2.10 cu13 wheel) FA2 matches SDPA (max|err| = 8.1e-03, bf16), torchao 0.17.0 int8-weight-only Linear runs (cpp path loads), bitsandbytes 0.49.2 Linear4bit runs, triton 3.6.0 and xformers 0.0.35 import.

Scope / follow-ups

cu126/cu128 target Ampere/Hopper/older; a spot-check LoRA run on one of those archs would round it out, though the accelerator reuse is a torch-version ABI property (proven on 2.11) independent of CUDA major.
CPU, macOS arm64, and Windows CUDA (install.ps1) are separate follow-ups; each has torch 2.11 wheels but wants its own smoke pass. Old CUDA (cu124/cu118), non-7.2 ROCm, and macOS x86 stay on 2.10 (no 2.11 wheels).

Related: #6961, #6970.

Readiness canary (torch 2.12)

Verified on a B200 (sm_100) that torch 2.12 breaks the accelerator wheel reuse for flash-attn only: torch 2.12 changed the c10 CUDA-check ABI, so every pre-2.12 flash-attn wheel fails to import, while causal-conv1d and mamba still load and pass via their cu13torch2.10 wheels. This is why the ceiling stays <2.12.0.

studio/backend/tests/test_flash_attn_torch212_canary.py plus .github/workflows/flash-attn-torch212-canary.yml poll the flash-attn releases weekly and fail once a torch >= 2.12 wheel appears, opening a tracking issue with the steps to raise the ceiling. The live poll is gated behind UNSLOTH_RUN_FLASH_ATTN_CANARY so only the scheduled job runs it; the offline parser tests run in every suite.

gemini-code-assist

Code Review

This pull request adds a PyTorch version constraint override for CUDA 13 (cu130 / Blackwell) in install.sh to support up to torch < 2.12.0, along with a corresponding test in test_torch_constraint.sh. Feedback suggests tightening the cu130 constraint to torch>=2.11.0,<2.12.0 instead of torch>=2.4 to prevent package managers from resolving to torch==2.10.0, which has known compatibility issues with torchao kernels on CUDA 13. The associated test should also be updated to match this tightened constraint.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

danielhanchen · 2026-07-08T22:24:38Z

Reviewed this. The install.sh change is correct: the */cu130 case is present and a correct grep confirms it, so fresh cu130 (Blackwell) installs will resolve torch>=2.11.0,<2.12.0 from the cu130 index (which ships 2.11.0), while cu126/cu128/ROCm/macOS stay on the 2.10 family. It also lines up with #6970's _CUDA_TORCH_PKG_SPEC (already <2.12.0) and the prebuilt_wheel_torch_mm mapping, so flash-attn / causal-conv1d / mamba reuse their torch2.10 wheels on 2.11.

One real issue: the new structural test's regex was over-escaped. In a single-quoted ERE, \\*/cu130\\)... makes grep -E read \\* as a zero-or-more-backslashes quantifier and \\) as an unmatched paren, so it matched nothing and the assertion failed even though the override is there. Confirmed with GNU grep 3.11 (what CI uses): the doubled-backslash pattern returns 0, the single-backslash pattern returns 1. I pushed a one-line fix (37d5026) using single backslashes; bash tests/sh/test_torch_constraint.sh is now 26/26.

Rest of the constraint suite is green. tests/python/test_tokenizers_and_torch_constraint.py passes apart from test_negative_control_no_tokenizers, which is a pre-existing environment artifact (it expects from transformers import AutoConfig to fail without tokenizers, but the installed transformers imports fine) and is unrelated to this change.

Two notes, not blockers:

Scope is Linux install.sh only. Windows CUDA Blackwell (install.ps1's hardcoded constraint) still lands on 2.10, so if we want Windows parity that is a separate follow-up.
Moving fresh cu130 installs onto torch 2.11 is the meaningful behavior change here. The 5090 smoke pass in the description (flash-attn, torchao cutlass/mxfp8, bitsandbytes, xformers cu130, triton, compiled kernels, vLLM 0.24 pinning 2.11) covers the concern I had earlier; a B200 (sm_100) pass would round it out since the constraint targets all of cu130, not just sm_120.

ThomasEricB · 2026-07-08T23:07:12Z

Scope is Linux install.sh only. Windows CUDA Blackwell (install.ps1's hardcoded constraint) still lands on 2.10, so if we want Windows parity that is a separate follow-up.

I am afraid of pushing anything Windows side without at least verifying it runs there.

Moving fresh cu130 installs onto torch 2.11 is the meaningful behavior change here. The 5090 smoke pass in the description (flash-attn, torchao cutlass/mxfp8, bitsandbytes, xformers cu130, triton, compiled kernels, vLLM 0.24 pinning 2.11) covers the concern I had earlier; a B200 (sm_100) pass would round it out since the constraint targets all of cu130, not just sm_120.

While it's great that it runs, but we don't know if there is a bump ahead in the road yet, so I can't in good consciousness allow this PR to be merged without at least me actually running Unsloth Studio and generating lots and lots of activity in it. Will report back when satisfied.

…thai#6982 The cu126/cu128/cu130 indexes all ship torch 2.11.0 wheels, so add cu128 and cu126 to the TORCH_CONSTRAINT override next to cu130. Older CUDA (cu124/cu118), other ROCm tags, CPU and macOS keep the <2.11.0 default (no torch 2.11 wheels there). Extend the structural test to assert all three overrides.

danielhanchen · 2026-07-09T02:12:26Z

Broadened this to all modern CUDA (cu126/cu128/cu130) in 93d4e1d, not just cu130. All three indexes ship torch 2.11.0 wheels, so one per-index override block handles them. The default torch>=2.4,<2.11.0 stays for cu124/cu118, other ROCm tags, CPU and macOS, since torch 2.11 publishes no wheels there.

Also verified on a B200 (sm_100) to complement your RTX 5090 (sm_120) run: a fresh torch 2.11.0+cu130 venv with the wheels the installer selects has flash-attn FA2 matching SDPA (max|err| = 8.1e-03), torchao 0.17 int8 cpp running, bitsandbytes 4bit running, and triton/xformers importing.

Updated the structural test to assert all three overrides and refreshed the title/description to match. I had opened #6997 with the same change before deciding to fold it in here, so I am closing that in favor of this.

danielhanchen · 2026-07-09T02:32:41Z

Windows is untouched here. This only adds per-index overrides in the Linux install.sh case block, so install.ps1 keeps its existing 2.10 constraint and Windows stays exactly as-is. Windows parity would be its own PR with a real Windows run behind it, so nothing ships there without verification.

On the B200: 93d4e1d adds that sm_100 pass. Fresh torch 2.11.0+cu130 venv with the exact wheels the installer selects, flash-attn FA2 matches SDPA (max|err| = 8.1e-03, bf16), torchao 0.17 int8-weight-only cpp path loads and runs, bitsandbytes 4bit runs, triton and xformers import. So both Blackwell tiers are covered now: sm_120 on the 5090, sm_100 on the B200. Take your time with the Studio activity run.

ThomasEricB · 2026-07-09T03:00:44Z

I reviewed the latest 3 commits on my end and it works perfectly!

chatgpt-codex-connector · 2026-07-09T03:02:04Z

Codex Review: Didn't find any major issues. Breezy!

Reviewed commit: d4f037dd8b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-07-09T03:47:45Z

Codex Review: Didn't find any major issues. Delightful!

Reviewed commit: b8b8855c5c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

danielhanchen · 2026-07-09T09:00:58Z

Folded in a readiness canary for the torch 2.12 blocker.

Context: on a B200 (sm_100) I checked flash-attn, causal-conv1d and mamba on torch 2.12.0+cu130. causal-conv1d (tests/ 9412 passed) and mamba (selective_scan 20/20; the 3 triton failures are bf16 tolerance, not ABI) both load and pass via their cu13torch2.10 wheels. flash-attn does not: torch 2.12 changed the c10 CUDA-check ABI (c10_cuda_check_implementation gained an unsigned int arg), so every pre-2.12 flash-attn wheel (newest is cu13torch2.9/cu13torch2.10) fails to import with an undefined symbol. That is exactly why this PR caps modern CUDA at <2.12.0.

To catch when that blocker lifts, studio/backend/tests/test_flash_attn_torch212_canary.py polls the flash-attn GitHub releases and fails once a wheel built against torch >= 2.12 appears. The live poll only runs in the new scheduled workflow (.github/workflows/flash-attn-torch212-canary.yml, weekly + manual dispatch), gated behind UNSLOTH_RUN_FLASH_ATTN_CANARY, so it never turns unrelated PRs red. The offline parser tests run in every suite, so the detection logic stays covered. When it fires it opens a deduplicated tracking issue with the update steps: extend wheel_utils.prebuilt_wheel_torch_mm for torch 2.12, raise the ceiling toward <2.13.0 (once causal-conv1d/mamba also ship 2.12 wheels), re-run the Blackwell accelerator smoke, then bump the canary threshold.

chatgpt-codex-connector · 2026-07-09T09:08:53Z

Codex Review: Didn't find any major issues. Hooray!

Reviewed commit: 260d96eb85

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

ThomasEricB · 2026-07-09T11:41:52Z

@danielhanchen Commit 8413342 fixes the 4 out of 5 things the bot above and in the disposable CI run at danielhanchen#315 flagged.

Orchestrator change from: [staging CI] unslothai/unsloth#6982 danielhanchen/unsloth-staging-2#315 (comment)
Fail open scan from: [staging CI] unslothai/unsloth#6982 danielhanchen/unsloth-staging-2#315 (comment)
Duplicate _active_tool_names from: [staging CI] unslothai/unsloth#6982 danielhanchen/unsloth-staging-2#315 (comment)
Canary from above at Studio: install torch 2.11 on all modern CUDA (cu126/cu128/cu130) #6982 (comment)

danielhanchen · 2026-07-09T11:55:19Z

Thanks for grabbing these. Your canary workflow fix is exactly right: adding id: poll and gating the issue step on failure() && steps.poll.outcome == 'failure' means only a real canary failure opens the tracking issue, not a transient checkout or pip hiccup. Confirmed, and I reacted to the bot note.

On the 5th (worker.py _skip_internal_final_save): that one is unrelated to this PR. It only surfaced because the disposable staging PR diffs against a stale base, so it swept in main code this branch does not touch. It is a fair flag on its own though. HF Trainer calls save_model(_internal_call=True) from _save_checkpoint, so if a save fires during train() the raise would abort the run. It is only safe while save_strategy keeps internal saves off during training. A no-op body, or restoring the original in the same finally, would be more robust. Happy to take that as its own change, but it does not belong in the torch 2.11 PR.

ThomasEricB · 2026-07-09T11:59:51Z

On the 5th (worker.py _skip_internal_final_save): that one is unrelated to this PR. It only surfaced because the disposable staging PR diffs against a stale base, so it swept in main code this branch does not touch. It is a fair flag on its own though. HF Trainer calls save_model(_internal_call=True) from _save_checkpoint, so if a save fires during train() the raise would abort the run. It is only safe while save_strategy keeps internal saves off during training. A no-op body, or restoring the original in the same finally, would be more robust. Happy to take that as its own change, but it does not belong in the torch 2.11 PR.

I can make a new PR later for that one but I don't want to step too much into something I have no clue about actually (I am already mostly out of my depth).

danielhanchen · 2026-07-09T12:07:08Z

Folded the worker.py fix into this branch in cabdb49 rather than opening a separate PR. _skip_internal_final_save now returns None instead of raising, so an internal save_model call during train() (HF Trainer does this from _save_checkpoint) can no longer abort the run. The worker still owns the final save via the restore in the finally block, so behavior on the happy path is unchanged. One line, ast.parse clean.

ThomasEricB · 2026-07-09T12:28:54Z

So far no problems in actual use that I can see (these are with Gemma 4 31b QAT)

ThomasEricB · 2026-07-10T05:17:15Z

@danielhanchen I think this is read to merge?

ThomasEricB · 2026-08-10T02:50:48Z

~~@danielhanchen Interesting find! Apparently this PR is required if some brave soul ever wants to run Unsloth on the Steam Deck. According to Claude:~~

.../whl/rocm7.2 is the only pytorch.org index with the torch 2.11 + torchao 0.18 pair. The cpu index's torchao stops at 0.9.0; every rocm leaf below 7.2 caps torch at 2.10. I confirmed torch-2.11.0+rocm7.2, torchvision-0.26.0+rocm7.2, torchaudio-2.11.0+rocm7.2, torchao-0.18.0+rocm7.2 all exist for cp313.

Outdated, ROCM sucks on the Steam Deck LOL

Continuation of unslothai#6982, which added per-index TORCH_CONSTRAINT overrides for rocm7.2 and the modern CUDA indexes and explicitly left CPU as a follow-up wanting its own smoke pass. This is that follow-up. The cpu index ships the whole 2.11 trio -- torch 2.11.0+cpu, torchvision 0.26.0+cpu, torchaudio 2.11.0+cpu -- for cp312 and cp313, so a Linux CPU install currently lands on the 2.10 family for no reason other than the default constraint never having been revisited. case "$_torch_index_leaf" in cpu) if [ "$OS" != "macos" ]; then TORCH_CONSTRAINT="torch>=2.11.0,<2.12.0" TORCHVISION_CONSTRAINT="torchvision>=0.26.0,<0.27.0" TORCHAUDIO_CONSTRAINT="torchaudio>=2.11.0,<2.12.0" fi ;; esac The companions move with torch, matching how the rocm7.2 arm pins its trio. The existing bounded companion defaults already prevent the bare-companion mismatch described above them (verified: with the current bounds the cpu leaf resolves a consistent torch/torchaudio/torchvision 2.10/2.10/0.25 set; only bare companion names reproduce torch 2.10.0+cpu with torchaudio 2.11.0+cpu), so this is not a fix for that -- it keeps the same property one version up. No glibc floor moves: the 2.11 cpu wheels use the same manylinux_2_28 platform tag as the 2.10 cpu wheels on both x86_64 and aarch64, so no older distro is stranded. macOS is deliberately excluded. get_torch_index_url returns $_base/cpu on Darwin, so macOS shares this leaf, and its arm64 wheels have had no smoke pass; it keeps the default window and the Python 3.13 >=2.6 floor set earlier. install.ps1 is untouched, so Windows is unaffected. The default torch>=2.4,<2.11.0 also stays put for every other leaf, keeping the "hardcoded torch>=2.4 appears exactly once" guard valid. Verification: uv resolves the intended trio from the cpu index on cp312, cp313 and aarch64 (torch 2.11.0+cpu / torchvision 0.26.0+cpu / torchaudio 2.11.0+cpu); unsloth 2026.8.10's torch<2.12.0,>=2.4.0 admits 2.11. Full Linux x86_64 CPU stack smoke pass on that trio with unsloth 2026.8.10 and torchao 0.18.0 -- torch.autograd.gradcheck passes in float64, a 60-step SGD run converges identically to the pre-bump stack (0.9710 -> 0.1148), torchao int8-weight-only quantize_() plus forward runs, and Unsloth Studio starts and serves. tests/sh/test_torch_constraint.sh is 51/51, extended with linux/wsl/macos cpu cases and a mirror whose base path contains cpu but whose leaf does not. The real case block was also extracted from install.sh and exercised across {linux,wsl,macos} x {cpu,rocm7.2,cu128,xpu} to confirm the other leaves are unchanged on every OS. bash -n install.sh clean.

chatgpt-codex-connector · 2026-08-31T15:42:47Z

Codex Review: Didn't find any major issues. Keep it up!

Reviewed commit: 3a450a4b14

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

ThomasEricB · 2026-08-31T15:54:40Z

@oobabooga Just updated the branch to be with main.

Net diff vs main is exactly the 4 intended files: orchestrator.py, routes/settings.py, test_orchestrator_unload_cancel.py, test_audio_tts_cancellation.py.

oobabooga · 2026-08-31T16:00:32Z

Thanks. Added ba2cc23: a test for the update_embedding_model fail-open path, which had none. It stubs utils.security.evaluate_file_security to raise and asserts the PUT still returns 200 and persists; on the pre-change route it is a 500, so it pins the reason that hunk is in the PR.

Diff vs main is now those four files plus the new test. worker.py dropped out when the _skip_internal_final_save revert made it identical to main.

chatgpt-codex-connector · 2026-08-31T16:05:34Z

Codex Review: Didn't find any major issues. You're on a roll.

Reviewed commit: ba2cc23728

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-08-31T16:26:55Z

Codex Review: Didn't find any major issues. Nice work!

Reviewed commit: df36b16fe5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

oobabooga · 2026-08-31T18:12:38Z

Codex approved df36b16, so reviews have converged. Last push was the comment-reduction pass (comment lines on the added hunks 42 -> 17, AST-gated as comment-only).

CI has two reds, both pre-existing and not from this PR:

Repo tests (CPU) -- tests/studio/install/test_install_manifest_damage.py::test_an_unimportable_helper_forces_the_dependency_pass[absent-keeps-the-fast-path]
(Python 3.13) -- tests/test_torchao_select.py::test_skips_torchao_on_windows_rocm[True-False]

Both exercise studio/install_python_stack.py, which this PR does not touch. #10081, #10082 and #10077 fail the same two jobs on the same two tests, and both files pass locally at this head (51 and 29 passed). I re-ran the failed jobs; the queue has not picked them up yet.

Backend suites for the touched code are green here: test_orchestrator_unload_cancel, test_audio_tts_cancellation, test_embedding_model_security_gate, test_orchestrator_idle_subprocess_teardown, test_embedding_model_settings, test_rag_embeddings -- 201 passed, ruff clean.

The description still needs rewriting before merge: it describes the torch 2.11 install.sh work, and the diff is now the dispatcher exclusive-op reservation plus the embedding-scan fail-open.

for more information, see https://pre-commit.ci

oobabooga · 2026-09-01T17:06:54Z

@codex review

chatgpt-codex-connector · 2026-09-01T17:10:25Z

Codex Review: Didn't find any major issues. Swish!

Reviewed commit: 738e43186f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

oobabooga · 2026-09-01T17:18:27Z

Codex approved 738e431, so reviews are converged again on the merged head. The two new commits are a main merge and a pre-commit.ci autofix; no PR code changed, and the 201 backend tests for the touched modules still pass here with ruff clean.

Of the four CI reds, two were noise and cleared on re-run:

Chat UI, API, Update and GGUF inference was cancelled by concurrency, not failed.
GGUF inference smoke failed multi_turn_chat.py on llama-server nondeterminism at temperature=0.0 -- the same prompt returned ...58 + 27 = 95\nSo, 58 + 27 = 95 on one replay and stopped at ...= 95 on the next, across all 3 attempts. Green on re-run.

The remaining two, Repo tests (CPU) and (Python 3.13), are the same pair of tests and are broken on main, not here:

tests/studio/test_model_picker_contracts.py::test_a_pinned_cached_row_loads_from_the_id_the_backend_pinned -- picker.count("loadId: c.load_id") == 4 gets 1.
studio/backend/tests/test_non_gguf_reload_settings.py::TestNonGgufStatusReportsWhatTheLoadAskedFor::test_the_non_gguf_status_branch_publishes_them -- the status branch no longer contains requested_context_length = model_info.get("max_seq_length_requested").

Both are source-text contract assertions against files this PR does not touch. I checked out upstream main at 024df09 with none of this PR's changes and got the identical 2 failed, 203 passed, and 6 of the 8 newest open PRs carry the same two reds. Whichever main change moved the picker mapper and the non-GGUF status branch needs to update its contract tests; nothing here can clear them.

The description still needs rewriting before merge -- it describes the torch 2.11 install.sh work, and the diff is the dispatcher exclusive-op reservation plus the embedding-scan fail-open.

danielhanchen · 2026-09-14T08:23:00Z

Confirmed the unguarded drain is still there in studio/backend/core/inference/orchestrator.py around the share_distributed_object call, and the embedding scan route still 500s on a scan error, so both hunks land on real code. One thing before I review: the description still describes the torch 2.11 install.sh work rather than what the diff now does, so could you update it to match?

danielhanchen · 2026-09-23T01:59:56Z

Main's install.sh now defaults the torch ceiling to 2.12.0 on every index, including cu126, cu128 and cu130, so the install change is no longer needed, and the branch now only carries orchestrator and test changes unrelated to the title. Sorry for the slow review, and thanks for putting it together.

ThomasEricB requested a review from danielhanchen as a code owner July 8, 2026 15:08

ThomasEricB changed the title ~~Studio: install torch 2.11 on Blackwell so that torchao's cpp extensions can load (REQUIRES EXTENSIVE TESTING)~~ TENTATIVE: Studio: install torch 2.11 on Blackwell so that torchao's cpp extensions can load (REQUIRES EXTENSIVE TESTING) Jul 8, 2026

gemini-code-assist Bot reviewed Jul 8, 2026

View reviewed changes

Comment thread install.sh Outdated

Comment thread tests/sh/test_torch_constraint.sh Outdated

danielhanchen mentioned this pull request Jul 9, 2026

Studio: install torch 2.11 on all modern CUDA (cu126/cu128/cu130) #6997

Closed

danielhanchen changed the title ~~TENTATIVE: Studio: install torch 2.11 on Blackwell so that torchao's cpp extensions can load (REQUIRES EXTENSIVE TESTING)~~ Studio: install torch 2.11 on all modern CUDA (cu126/cu128/cu130) Jul 9, 2026

This comment was marked as resolved.

Sign in to view

danielhanchen mentioned this pull request Jul 9, 2026

[staging CI] unslothai/unsloth#6982 Datta0/unsloth-staging-3#59

Closed

This comment was marked as resolved.

Sign in to view

danielhanchen mentioned this pull request Jul 9, 2026

[staging CI] unslothai/unsloth#6982 danielhanchen/unsloth-staging-2#315

Closed

This comment was marked as resolved.

Sign in to view

unslothai deleted a comment from danielhanchen Aug 31, 2026

This comment was marked as resolved.

Sign in to view

Name the share in the compare mailbox-recheck refusal

3a450a4

Merge main into torch11

337ff4b

Cover the embedding-model scan fail-open path

ba2cc23

unslothai deleted a comment from chatgpt-codex-connector Bot Aug 31, 2026

Trim the dispatcher-reservation comments

df36b16

oobabooga mentioned this pull request Aug 31, 2026

CI: dispatcher exclusive-op reservation + embedding scan fail-open (#6982 mirror) oobabooga/unsloth#152

Closed

danielhanchen removed the conflicts# label Aug 31, 2026

oobabooga and others added 2 commits September 1, 2026 10:33

Merge main into torch11

bb6f849

[pre-commit.ci] auto fixes from pre-commit.com hooks

738e431

for more information, see https://pre-commit.ci

danielhanchen added conflicts# and removed refactor# labels Sep 3, 2026

danielhanchen added codex-converged# superseded# and removed codex-converged# edge case# labels Sep 20, 2026

Uh oh!

Conversation

ThomasEricB commented Jul 8, 2026 • edited by danielhanchen Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Verification

Scope / follow-ups

Readiness canary (torch 2.12)

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

danielhanchen commented Jul 8, 2026

Uh oh!

ThomasEricB commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danielhanchen commented Jul 9, 2026

Uh oh!

danielhanchen commented Jul 9, 2026

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

ThomasEricB commented Jul 9, 2026

Uh oh!

chatgpt-codex-connector Bot commented Jul 9, 2026

Uh oh!

chatgpt-codex-connector Bot commented Jul 9, 2026

Uh oh!

danielhanchen commented Jul 9, 2026

Uh oh!

chatgpt-codex-connector Bot commented Jul 9, 2026

Uh oh!

This comment was marked as resolved.

Uh oh!

ThomasEricB commented Jul 9, 2026

Uh oh!

This comment was marked as resolved.

Uh oh!

danielhanchen commented Jul 9, 2026

Uh oh!

ThomasEricB commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danielhanchen commented Jul 9, 2026

Uh oh!

ThomasEricB commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ThomasEricB commented Jul 10, 2026

Uh oh!

ThomasEricB commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

Uh oh!

chatgpt-codex-connector Bot commented Aug 31, 2026

Uh oh!

ThomasEricB commented Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oobabooga commented Aug 31, 2026

Uh oh!

chatgpt-codex-connector Bot commented Aug 31, 2026

Uh oh!

chatgpt-codex-connector Bot commented Aug 31, 2026

Uh oh!

oobabooga commented Aug 31, 2026

Uh oh!

oobabooga commented Sep 1, 2026

Uh oh!

chatgpt-codex-connector Bot commented Sep 1, 2026

Uh oh!

oobabooga commented Sep 1, 2026

Uh oh!

ThomasEricB commented Jul 8, 2026 •

edited by danielhanchen

Loading

ThomasEricB commented Jul 8, 2026 •

edited

Loading

ThomasEricB commented Jul 9, 2026 •

edited

Loading

ThomasEricB commented Jul 9, 2026 •

edited

Loading

ThomasEricB commented Aug 10, 2026 •

edited

Loading

ThomasEricB commented Aug 31, 2026 •

edited

Loading