fix(transformers): use greedy decoding at temperature 0 for Gemma 3, Gemma 4, GLM-4V and MiniCPM-V 4.6 - #5727

What happens

#5708 made the Qwen2-VL adapter decode greedily at temperature: 0. Four other direct-chat Transformers adapters still pass the request's temperature straight to generate(): Gemma 3 (multimodal/gemma3.py), Gemma 4 (gemma4.py), GLM-4V (multimodal/glm4v.py, which also forces do_sample=True) and MiniCPM-V 4.6 (multimodal/minicpmv46.py). The generation configs of their built-in checkpoints all set "do_sample": true (google/gemma-3-*-it, google/gemma-4-*-it, zai-org/glm-4v-9b, openbmb/MiniCPM-V-4.6). With sampling on, transformers 5.17 rejects zero:

ValueError: `temperature` (=0) has to be a strictly positive float, otherwise your next token scores will be invalid.

The error is raised in the generation thread, so the request never gets it:

I drove each adapter's build_direct_chat_result() on CPU with a stub model whose generate() applies transformers' own temperature check, as a sampling-enabled checkpoint does. Positive temperatures answer on all five.

Change

• Gemma 3, Gemma 4 and GLM-4V use the rule Qwen2-VL has had since fix(transformers): use greedy decoding for Qwen2-VL at temperature 0 #5708: exactly 0 selects greedy decoding (do_sample=False, no temperature), and any positive temperature samples with its value. An omitted temperature keeps its default (1 for Gemma, 0.7 for GLM-4V).
• MiniCPM-V 4.7's rule (sample only for a positive temperature; greedy drops temperature, top_p and top_k) moves from its override into MiniCPMV46Model.build_generate_kwargs, which 4.7 inherits. 4.6 now decodes greedily at 0, and 4.7's kwargs don't change.
• The batching path is not touched; it already treats temperatures below 1e-5 as greedy. The adapters' handling of other generation errors is not changed either.

Tests

New xinference/model/llm/tests/test_transformers_temperature.py runs build_direct_chat_result() for the five adapters at temperatures 0, 1e-6, 0.7 and omitted, streaming and not (40 cases), with the stub model above. It checks the answer and the kwargs passed to generate(). With the five source files restored from e4b24a9e, the 8 temperature-0 cases for Gemma 3, Gemma 4, GLM-4V and MiniCPM-V 4.6 fail; with this change all 40 pass. The existing MiniCPM-V 4.7 tests in test_minicpmv47.py pass unchanged.

I ran these on Linux (Python 3.12, CPU torch 2.14.1, transformers 5.17.0):

• pytest xinference/model/llm/tests xinference/model/llm/transformers/tests, without test_llm_model.py and test_tensorizer.py as in CI: 972 passed, 50 skipped, 1 failed. The failure is test_llm_family.py::test_query_engine_general, which expects the llama.cpp engine. It isn't installed here, and the test fails the same way on e4b24a9e.
• pre-commit run --files on the changed files: all hooks pass.

I did not run a real model.