Open-source contributions

PaliGemma 2 pairs a SigLIP vision encoder with Gemma 2. Gemma 2's config sets final_logit_softcapping=30, which passes the logits through tanh(x / 30) * 30 before the softmax. Up to v4.51, PaliGemma wrapped Gemma2ForCausalLM, which applied the cap. A refactor in v4.52 replaced it with the bare text model and a separate lm_head, and the cap was dropped. Greedy decoding does not change because tanh is monotonic, which is why the integration tests never caught it.

On the released paligemma2-3b-mix-224 checkpoint the logits never reach 30, but the cap still matters. The caption's log-probability goes from -5.83 to -7.93, and at T=1 the sampling distribution shifts by 13% (total variation distance). I opened the issue with a CPU reproduction; the maintainer checked big_vision and asked me for the PR.

The fix applies the cap after lm_head, as Gemma 3n does. It reads the cap with getattr, because PaliGemma 1's GemmaConfig has no such field. A new test sets a small cap and checks that no logit goes past it: it fails on main and passes with the fix. The maintainer ran the slow PaliGemma tests and merged it unchanged three days after it was opened.

NemotronH stacks Mamba-2, attention, MLP and mixture-of-experts layers, and is native in transformers. The export reuses optimum-intel's GraniteMoeHybrid support, so the Mamba-2 layers go through the same recurrent cell (an OpenVINO loop) and the same cache layout. What differs: each layer has a single mixer, picked by its block type, and the experts have no gate (up, relu², down). The shared experts patch now handles that case without changing the graph of gated models.

One choice is backed by measurements. transformers clamps the time step dt at time_step_min when it processes the prompt, but not when it decodes token by token. NVIDIA's original code, mamba_ssm and vLLM clamp with config.time_step_limit instead. In Nemotron 3 Nano 4B, 23% of the dt values sit below time_step_min, so the choice shows on long contexts: following NVIDIA, perplexity at 16k tokens is 1.91 instead of 2.14.

Exported to int4, Nano 4B takes 2.4 GB. Its hidden size (3136) is not a multiple of 128, so without --group-size-fallback adjust about half of the weights stay in bf16 and the model takes 5.0 GB.

With local_files_only=True, which HF_HUB_OFFLINE=1 also forces, OVBaseModel.from_pretrained assumed the model id was a Hub id and read refs/main from the Hub cache to find the snapshot. For a local folder that file does not exist. The error was swallowed with a misleading warning, the export stayed off, and loading then failed looking for openvino_model.xml.

The fix only resolves the Hub cache when the model id is not a local directory, so loading cached Hub models offline works as before. A new test covers local_files_only and offline mode; both cases fail on main and pass with the fix. There was no issue for it: the bug came from reading the code.

encode(..., output_value="token_embeddings") cut each row at its last real token, which only handles right padding. The Qwen3-Embedding model cards recommend padding_side="left", and with it the shorter texts in a batch came back with their padding rows still attached. Anything built on the token embeddings, like mean pooling or late chunking, then included padding.

Each row is now sliced from its first to its last attended token, and right-padded outputs are unchanged. The existing test now runs with both padding sides; the left case failed before the fix. The maintainer merged it 54 minutes after it was opened.