Add an NVFP4 quantization converter by rdspring1 · Pull Request #3914 · pytorch/torchtitan

rdspring1 · 2026-07-13T20:48:51Z

Summary

Add NVFP4 (NVIDIA Blackwell, sm_100+) as a first-class quantization recipe using the converter mechanism, alongside Float8LinearConverter and MXFP8LinearConverter (#3558): the quantized module is built from a config node via model_registry(converters=...), so NVFP4 is selectable through the normal config path and tested in the standard flow.

What changed

New torchtitan/components/quantization/nvfp4.py: NVFP4LinearConverter (a Linear.Config -> NVFP4Linear.Config leaf swap, mirroring MXFP8LinearConverter) and NVFP4Linear.
NVFP4Linear reuses torchao's stateful NVFP4Linear (weight/bias, the _sr_seed / _rht_sign_vector runtime buffers, RHT logic, state-dict handling) and adds:
- torchtitan's meta-init buffer protocol. _sr_seed is a per-rank, non-persistent stochastic-rounding key (SR is unbiased and no quantized values cross the wire, so distinct seeds per rank are correct; a Philox key needs no checkpointing). _rht_sign_vector is drawn per-rank at random but broadcast to a replicated, persistent buffer, because the Hadamard basis must match across TP ranks (rowwise TP shards the GEMM contraction dim, and the transform only cancels when both operands share the sign vector).
- a tensor-parallel path on the spmd_types backend. torchao's functional NVFP4 op (nvfp4_mm_triton) is an opaque Triton autograd Function that DTensor cannot dispatch on, so TP runs it inside an spmd.local_map region (modeled on RoutedExperts): the framework converts activations to local shards on entry and re-types the output on exit, and nvfp4_mm_triton is registered via spmd.register_local_autograd_function.
Mixed-precision NVFP4 with bf16 tail: new qwen3_8b_nvfp4_mixed and lama3_8b_nvfp4_mixed configs convert only the leading decoder layers to NVFP4 and keep the last ceil(n_layers * 0.15) layers and lm_head in bf16.

Design notes

spmd_types-only TP. The opaque NVFP4 op needs an explicit local-compute region to type-check under SPMD; the DTensor backend has no way to dispatch it. So TP is supported only under spmd_backend='spmd_types', and is validated with debug.spmd_typechecking (an eager type checker that confirms the local_map colwise/rowwise output and input-gradient types). FSDP-only / single-GPU runs are unaffected and take torchao's local functional path directly.

bf16 collectives at the block boundary. The converter keeps the model's stock bf16 TP collectives and quantizes only the GEMM -- it does not move fp4 codes over the wire. Moving fp4 would only help the column-parallel all-gather (the rowwise reduction needs a real sum and stays bf16), scales only with TP degree x sequence length, and is zero at TP=1. For NVFP4's targets -- large-K MoE models trained low-TP / high-EP, where bf16 all-to-all dominates and MoE experts are out of scope here -- the fp4 compute win is the prize and is fully retained. Keeping bf16 collectives also lets NVFP4Linear stay a leaf swap that composes with FSDP/TP through the standard sharding_config.

Numerical and performance validation

Llama 3 8B was trained on C4 dataset for 763 steps (200,015,872 tokens), sequence length 2048, global batch size 128, 4-way FSDP, TP 1. NVFP4, MXFP8, BF16 used the same local batch size of 32 with global accumulation of 1.

Experiment Setup

GPUs: 4× NVIDIA GB200, 184.3 GiB HBM each (~737 GiB total), sm_100
OS: Ubuntu 24.04.4 LTS
Driver: NVIDIA 595.84.01
Python: 3.12.3
PyTorch: 2.14.0a0+gitd9abf9e
CUDA: 13.3 (nvcc 13.3.73)
OAI Triton: 3.8.0+git43422b04
TorchAO: 0.18.0+gitcb76f29 for MXFP8 compiled cuda kernels; TOT for NVFP4 and BF16.

Table 1 — Eager Trainer 200M-token run

Precision	TPS/GPU	Aggregate TPS	TFLOPs/GPU	Peak mem	× BF16 TPS	× BF16 mem	Loss @200M
BF16	21,919	87,676	1,057.59	174.49 GiB	1.00×	1.00×	1.27381
MXFP8	28,084	112,336	1,355.08	179.94 GiB (97.6%)	1.28×	1.03×	1.26707
NVFP4	31,758	127,032	1,532.34	103.00 GiB	1.45×	0.59×	1.26874

Takeaway: NVFP4 has higher tokens per second (TPS) and lower peak memory usage than MXFP8 and BF16. It delivers ~1.45× throughput at ~0.59× memory with matched loss (1.274 vs 1.268) against BF16. MXFP8 is ~1.28 faster than BF16 but gives no memory relief because it saves BF16 activations for backwards pass. NVFP4 beats MXFP8 by ~1.13× on throughput while using only ~0.57× its memory (103 vs 180 GiB, ~77 GiB less). NVFP4 saves quantized activations and scale factors for backwards pass, reducing memory pressure.

Training Loss Convergence

Eager Trainer 200M-token run for NVFP4, MXFP8, BF16

AI tools used

Claude Opus 4.8 (1M context) and OAI GPT 5.6 via Codex

pytorch-bot · 2026-07-13T20:48:58Z

~~Workflows were awaiting approval.~~ CI has now been triggered for the ciflow labels on this PR.

tianyu-l · 2026-07-19T01:40:56Z

    ngpu: int = 4
    disabled: bool = False
    skip_rocm_test: bool = False
+    skip_if_no_blackwell: bool = False


torchtitan CI doesn't have blackwell
@syed-ahmed any plan to sponsor?

Blackwell CI support is in the works. Once it's allocated in the pytorch org, we can start using it.

Maybe remove this test for now? CI has no signal so can't guard it anyway.

So remove all gpu tests?

We run the torchtitan tests in our internal blackwell CI and will maintain the tests.

Your CI has blackwell so you don't need this flag?

tianyu-l · 2026-07-19T01:44:32Z

+@override(
+    "nvfp4_feed_forward",
+    target=FeedForward.Config,
+    fqns=["layers.*.feed_forward", "*.layers.*.feed_forward"],
+    description="NVFP4 sequence-parallel FFN block (fp4 all-gather, no bf16 gather).",
+)


override should be mostly used for unblocking work outside the repo. For in-repo quantization support, we should put in https://github.com/pytorch/torchtitan/tree/main/torchtitan/components/quantization

You could make a converter (as a convenient util) following other quantization applications https://github.com/pytorch/torchtitan/blob/main/torchtitan/components/quantization/float8.py#L53

@tianyu-l I thought we were moving away from converters and writing quantized modules explicitly? Is there a change in guidance there?

@syed-ahmed
It might be slightly subtle:

We are moving away from "first create an nn.Linear and then call quantize_() to convert the module". See. enable graph trainer + mxfp8 composability #3558

We are moving towards "creating a quantized module directly", in torchtitan out of a quantized module config.

How do you obtain this config is flexible, via converter / override / creating one directly.

Here I'm saying we shouldn't use override if this is some code we seriously support in the repo. Converters are just config utils, which I don't see problem working with. E.g. for LoRA it's pretty convenient https://github.com/pytorch/torchtitan/blob/main/torchtitan/components/lora.py#L141

I don't have problem if someone insists on not using converter, but then we need to introduce more entries in model_registry() which themselves are model config utils. https://github.com/pytorch/torchtitan/blob/main/torchtitan/models/qwen3/__init__.py#L606

tianyu-l · 2026-07-19T01:45:24Z

@vkuzo @drisspg could you help review?

vkuzo · 2026-07-20T18:32:33Z

+            self.tp_group = tp_mesh.get_group("tp")
+            self.world_size = tp_mesh.size()
+            if self.tensor_parallel_style is None:
+                self.tensor_parallel_style = _infer_tp_style(self._sharding_config)


why is inferring needed here? is there precendent for doing it this way vs making the user do it?

Why is inferring needed here?

Not for any normally-specified TorchTitan model. Every model sets weight placement via colwise_config()/rowwise_config(), and the two override factories then set tensor_parallel_style explicitly on top. Inference at 345-346 fires only when a config is under-specified (style left None with a populated sharding_config) — i.e. hand-construction, which no in-repo caller does.

Precedent for doing it this way vs making the user do it?

The implicit precedent is the weight placement — the repo's sole canonical colwise/rowwise encoding across every model. Instead of inferring, the override can trigger an assertion when the sharding configuration is incomplete.

vkuzo · 2026-07-20T18:36:09Z

+
+
+def _nvfp4_rowwise_sp(x_BLD, w_local, bias, sr_seed, sign_vector, tp_group, world_size):
+    """Rowwise NVFP4 over a full-sequence feature shard, returning a seq shard.


is "rowwise" here talking about the nvfp4 recipe (outer scale rowwise, inner scale 1x16), or something else?

"rowwise" refers to rowwise sequence parallel layer. It isn't related to nvfp4 recipe.

vkuzo · 2026-07-20T18:40:59Z

Override the parent FeedForward and GQAttention blocks via the nvfp4_feed_forward / nvfp4_attention factories so their child linears use NVFP4, while leaving the LM head and MoE shared experts in bf16.
Preserve the sequence-parallel block input (in_dst = in_src) instead of the stock tp=R bf16 all-gather, and keep the existing rowwise output contract. Declare out_dst=None only when the inherited contract already targets the SP sequence shard, so TorchTitan does not reduce twice.
Define a dual checkpoint contract: native NVFP4 checkpoints keep the _sr_seed (stochastic-rounding seed) and _rht_sign_vector (Hadamard sign vector) buffers persistent and explicitly sharded, while the HF export boundary strips them automatically. Loading a stock checkpoint into NVFP4 is a redraws the buffers.

can you provide some more context on all of these?

rdspring1 · 2026-07-23T19:00:47Z

Override the parent FeedForward and GQAttention blocks via the nvfp4_feed_forward / nvfp4_attention factories so their child linears use NVFP4, while leaving the LM head and MoE shared experts in bf16.

Only the linears are replaced with NVFP4. The remaining gemms in MOE are unchanged.

Preserve the sequence-parallel block input (in_dst = in_src) instead of the stock tp=R bf16 all-gather, and keep the existing rowwise output contract. Declare out_dst=None only when the inherited contract already targets the SP sequence shard, so TorchTitan does not reduce twice.

The idea is do all-gather on the quantized NVFP4 tensors to save comm bandwidth. Stock TorchTitan does bf16 all-gather separately from Linear, so you miss out on that if you don't override FeedForward and GQAttention blocks.

The TorchAO NVFP4ColwiseParallel and NVFP4RowwiseParallel bake in comms to do NVFP4 All-Gather, the override needs to ensure TorchAO agrees with TorchTitan sharding scheme.

Define a dual checkpoint contract: native NVFP4 checkpoints keep the _sr_seed (stochastic-rounding seed) and _rht_sign_vector (Hadamard sign vector) buffers persistent and explicitly sharded, while the HF export boundary strips them automatically. Loading a stock checkpoint into NVFP4 is a redraws the buffers.

NVFP4 tracks stochastic rounding seed and sign vector for random hadamard transform in its checkpoint state. When you export to HuggingFace you lose them. The PR's behavior is to redraw a new SR seed and sign vector.

cc: @vkuzo

tianyu-l · 2026-07-23T22:47:47Z

+        def parallelize(self, parallel_dims: ParallelDims) -> None:
+            self._tp_active = parallel_dims.tp_enabled
+            if self._sharding_config is not None:
+                # Declare the runtime buffers (replicated) so _distribute_states
+                # and DCP handle them alongside weight/bias.
+                sc = self._sharding_config
+                self._sharding_config = replace(
+                    sc,
+                    state_shardings={
+                        **sc.state_shardings,
+                        "_sr_seed": _replicated_layout(),
+                        "_rht_sign_vector": _replicated_layout(),
+                    },
+                )
+                self._tp_style = _infer_tp_style(self._sharding_config)
+                self._validate(parallel_dims)
+                self._cache_buffer_spec(parallel_dims)
+            super().parallelize(parallel_dims)


What are we trying to achieve by modifying this code? Some more context would be helpful.

TorchAO's NVFP4Linear isn't a plain Linear. It carries two extra runtime buffers (_sr_seed, _rht_sign_vector) and a hard kernel constraint that each local GEMM dim must be a multiple of 128. TorchTitan's Module protocol requires every piece of state to be declared before it distributes params, and the stock colwise/rowwise sharding_config only knows about weight and bias. So we override parallelize() to do the NVFP4-specific setup, then delegate to the base via super().parallelize().

tianyu-l · 2026-07-23T22:48:40Z

+            )
+            out_tp = Shard(-1) if self._tp_style == "colwise" else Partial()
+            mesh, placements = _swap_tp_placement(x, out_tp)
+            return DTensor.from_local(y, mesh, placements, run_check=False)


We are migrating from DTensor to spmd_types, could you make sure it (only) works with spmd_types backend and debug.spmd_typechecking?

The spmd local_map-region pattern was modeled on RoutedExperts in torchtitan/models/common/moe/. It wraps an opaque local-compute op in a module-level spmd.local_map region via sharding_config.local_map.

tianyu-l · 2026-07-23T22:49:50Z

    ngpu: int = 4
    disabled: bool = False
    skip_rocm_test: bool = False
+    skip_if_no_blackwell: bool = False


Maybe remove this test for now? CI has no signal so can't guard it anyway.

tianyu-l · 2026-07-23T23:16:39Z

+            self._sr_seed = self._materialize_buffer(
+                torch.randint(
+                    -(2**63), 2**63 - 1, (1,), dtype=torch.int64, device=dev
+                )
+            )
+            self._rht_sign_vector = self._materialize_buffer(
+                _make_rht_sign_vector(None, device=dev)
+            )


I don't think you'd need to introduce _materialize_buffer -- I feel it can be configured right e.g. https://github.com/pytorch/torchtitan/blob/main/torchtitan/overrides/fused_swiglu.py#L500-L504

RHT must be replicated across TP ranks because RHT transformation must be consistent along quantized dimension and gemm contraction dim. The broadcast is load-bearing and the spmd_types R path won't do it. I added comment to code.

rdspring1 · 2026-07-24T00:59:47Z

@vkuzo @tianyu-l I changed the PR from override to a converter like MXFP8LinearConverter (#3558).

Updated Llama3 8B training loss with NVFP4 converter.

tianyu-l · 2026-07-24T02:35:40Z

    ngpu: int = 4
    disabled: bool = False
    skip_rocm_test: bool = False
+    skip_if_no_blackwell: bool = False


rdspring1 · 2026-07-27T20:19:24Z

The llama3_8b_nvfp4_mixed config keeps last 15% layers in BF16 for stability. This config follows recipe in Pretraining Large Language Models with NVFP4.

Run	Loss	Token/sec (per-gpu)	Memory
NVFP4 (bf16 tail)	1.2715	30,040	111 GiB (60%)
NVFP4 full	1.2687	31,758	103 GiB (56%)
MXFP8	1.2671	28,084	180 GiB (98%)
BF16	1.2738	21,919	174 GiB (95%)

tianyu-l · 2026-07-29T23:51:27Z

    ngpu: int = 4
    disabled: bool = False
    skip_rocm_test: bool = False
+    skip_if_no_blackwell: bool = False


Your CI has blackwell so you don't need this flag?

Fold the native-checkpoint exclusion assertion into the exposes-buffers test and drop test_nvfp4_native_checkpoint_excludes_runtime_buffers. The dropped test's load_state_dict + torch.equal round-trip added no distinct failure mode: loading a weight-only state dict cannot touch the non-persistent runtime buffers by construction. The merged test keeps the real invariant -- a native checkpoint carries only the stock weight. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

rdspring1 · 2026-08-02T22:51:39Z

@tianyu-l @vkuzo I fixed the lint errors and added torchtitan/components/quantization/nvfp4.md with warnings and experiments. I also trained qwen3-8B from random init as a separate network from llama3-8B.

Run	Loss	Tokens/sec (per GPU)	Peak Reserved Memory
NVFP4 (bf16 tail)	3.82986	26,732	78.63 GiB (42.67%)
MXFP8	3.81545	27,587	112.63 GiB (61.12%)
BF16	3.81439	20,913	112.88 GiB (61.25%)

4xFSDP GB200

vkuzo · 2026-08-03T11:50:30Z

+
+1. Train with NVFP4 for most of the run.
+2. When exact loss recovery matters, switch the linear-layer GEMM inputs to a higher precision shortly before learning-rate decay begins.
+3. Prefer switching only the forward-pass GEMMs to bf16 or, potentially, MXFP8.


can you explain this recommendation in more detail? Naively I would have expected the opposite, but tbh it's best to either not say this, or if we do say it it should be backed with data

This also comes from Appendix D. Switching to Higher Precision from the same paper. I can drop the part about MXFP8, which wasn't tested in the paper.

makes sense! how about the following to frame it:

we quote https://arxiv.org/pdf/2509.25149 here

we extract some of the things in Appendix D here in plain english and explain how do do those in titan (to save the reader the click to the paper + agent search titan code)

I think that would be a good combination of sharing and attributing the tips+tricks found by the NVIDIA researchers so far and also making it clear that these are not universal rules that are guaranteed to work. It's also good to link back to the paper for those who want to understand where these guidelines are coming from

Prefer switching only the forward-pass GEMMs to bf16 or, potentially, MXFP8.

btw, both of these are not yet supported in titan + torchao, right? It should be doable and useful to implement, but if not supported yet would be good to clarify it in this doc!

Yes, you can't switch only fwd to bf16 and keep nvfp4 bwd today. The simplest option is to switch all layers to bf16 at end of training. I'll make the wording precise about what is available today.

vkuzo · 2026-08-03T11:50:41Z

+### NVFP4 Training Recommendations
+
+1. Train with NVFP4 for most of the run.
+2. When exact loss recovery matters, switch the linear-layer GEMM inputs to a higher precision shortly before learning-rate decay begins.


do we have data backing this?

This comes from the Pretraining Large Language Models with NVFP4. See Appendix D. Switching to Higher Precision

# Conflicts: # torchtitan/models/llama3/config_registry.py

syed-ahmed · 2026-08-05T18:14:28Z

Merging since this PR doesn't touch the failing tests in CI.

Merged upstream/main (merge ddb4173). No conflicts, no replay required. - bcc0929 NVFP4 quantization converter (pytorch#3914) - d905f73 dependabot: pypa/gh-action-pypi-publish 1.14.1 -> 1.14.2 (CI only) The protocol replays llama3/ changes onto ezpz/agpt/, so bcc0929 was checked line by line: it is purely additive (zero removed/modified lines in llama3/config_registry.py; +3 each in the shared quantization/__init__.py and utils.py with nothing existing changed). NVFP4 is additionally NVIDIA-only (Blackwell FP4, every GEMM dim divisible by 128), so it is inapplicable on XPU regardless. Nothing to port.

pytorch-bot Bot added the ciflow/8gpu label Jul 13, 2026

meta-cla Bot added the CLA Signed This label is managed by the Meta Open Source bot. label Jul 13, 2026

rdspring1 force-pushed the nvfp4_linear_ao branch 2 times, most recently from fc8b67b to 2a36c34 Compare July 14, 2026 19:01

rdspring1 marked this pull request as ready for review July 14, 2026 19:02

rdspring1 requested review from fegin, tianyu-l, wconstab and wwwjn as code owners July 14, 2026 19:02

syed-ahmed added this to PyTorch + CUDA Jul 14, 2026

tianyu-l requested changes Jul 19, 2026

View reviewed changes

vkuzo reviewed Jul 20, 2026

View reviewed changes

rdspring1 force-pushed the nvfp4_linear_ao branch from 2a36c34 to b97cecb Compare July 23, 2026 18:44

tianyu-l requested a review from vkuzo July 23, 2026 22:19

tianyu-l reviewed Jul 23, 2026

View reviewed changes

Comment thread torchtitan/components/quantization/nvfp4.py Outdated

rdspring1 changed the title ~~[overrides] Add an NVFP4 training override with sequence-parallel TP~~ Add an NVFP4 quantization converter Jul 24, 2026

tianyu-l reviewed Jul 24, 2026

View reviewed changes

rdspring1 requested a review from tianyu-l July 27, 2026 20:19

tianyu-l reviewed Jul 29, 2026

View reviewed changes

rdspring1 force-pushed the nvfp4_linear_ao branch 2 times, most recently from d0ce31f to db06503 Compare July 30, 2026 18:58

rdspring1 requested a review from tianyu-l July 30, 2026 20:09

rdspring1 and others added 4 commits August 1, 2026 10:12

Update _sr_seed comment

3fa6d79

Fix Pyrefly errors in NVFP4 configs

8d6877e

Add NVFP4 training guide

5d2e9ff

rdspring1 force-pushed the nvfp4_linear_ao branch from bbb4492 to 5d2e9ff Compare August 1, 2026 18:04

Document Qwen3 NVFP4 training results

3c1999e

rdspring1 force-pushed the nvfp4_linear_ao branch from 4ab90ed to 3c1999e Compare August 2, 2026 18:43

Add Llama continued pretraining recipes

3a299f2

rdspring1 force-pushed the nvfp4_linear_ao branch from 3713874 to 3a299f2 Compare August 2, 2026 22:31

cleanup

6ad5b44

vkuzo reviewed Aug 3, 2026

View reviewed changes

Comment thread torchtitan/components/quantization/nvfp4.py Outdated

vkuzo reviewed Aug 3, 2026

View reviewed changes

Comment thread torchtitan/models/llama3/config_registry.py Outdated

vkuzo reviewed Aug 3, 2026

View reviewed changes

Comment thread torchtitan/models/llama3/config_registry.py

vkuzo reviewed Aug 3, 2026

View reviewed changes

Comment thread torchtitan/components/quantization/nvfp4.py

rdspring1 added 2 commits August 3, 2026 09:47

rename and remove tests

5dfb4d4

Move _NVFP4_BF16_TAIL_FRACTION from converter to model config

f620059

syed-ahmed moved this to In Progress in PyTorch + CUDA Aug 3, 2026

rdspring1 added 2 commits August 3, 2026 11:07

Revise NVFP4 Training Recommendations

9f739d7

Merge remote-tracking branch 'origin/main' into nvfp4_linear_ao

d45671b

# Conflicts: # torchtitan/models/llama3/config_registry.py

vkuzo approved these changes Aug 3, 2026

View reviewed changes

rdspring1 added 2 commits August 4, 2026 22:52

lint

05eb698

remove misc config

ce078a6

syed-ahmed merged commit bcc0929 into pytorch:main Aug 5, 2026
18 of 19 checks passed

github-project-automation Bot moved this from In Progress to Done in PyTorch + CUDA Aug 5, 2026

syed-ahmed mentioned this pull request Aug 5, 2026

NVFP4 Training Tracker pytorch/ao#3293

Open

59 tasks



		def _nvfp4_rowwise_sp(x_BLD, w_local, bias, sr_seed, sign_vector, tp_group, world_size):
		"""Rowwise NVFP4 over a full-sequence feature shard, returning a seq shard.

Uh oh!

Conversation

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

Uh oh!

Summary

What changed

Design notes

Numerical and performance validation

Training Loss Convergence

AI tools used

Uh oh!

pytorch-bot Bot commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vkuzo commented Jul 20, 2026

Uh oh!

rdspring1 commented Jul 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rdspring1 commented Jul 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rdspring1 commented Aug 2, 2026

rdspring1 commented Jul 13, 2026 •

edited

Loading

pytorch-bot Bot commented Jul 13, 2026 •

edited

Loading

rdspring1 commented Jul 24, 2026 •

edited

Loading

rdspring1 Aug 3, 2026 •

edited

Loading

vkuzo Aug 3, 2026 •

edited

Loading