fix: select the text-model family by prefix instead of one exact string

[janhilgard]

Fixes the first half of #685.

Problem

_import_text_model_classes matched model_type == "gemma4_text" exactly and defaulted everything else to qwen3_5.TextModel:

gemma4_text            -> mlx_lm.models.gemma4_text.Model
gemma4_unified_text    -> mlx_lm.models.qwen3_5.TextModel     # <-- wrong
gemma4_unified         -> mlx_lm.models.qwen3_5.TextModel     # <-- wrong
anything-else          -> mlx_lm.models.qwen3_5.TextModel

Gemma 4 reports gemma4_text on some checkpoints and gemma4_unified_text on others, so the latter reached qwen3_5.TextModelArgs, which leaves num_experts as None, and construction died on args.num_experts > 0:

TypeError: '>' not supported between instances of 'NoneType' and 'int'

A wrong guess does not fail where it is made. It fails deep inside the chosen constructor with an error naming neither the model nor the class, build_text_model catches it and returns None, and the engine then reports itself loaded with _text_model=None. The whole visible trace is:

ERROR:vllm_mlx.text_model_from_vlm:Failed to build TextModel from vlm: '>' not supported between instances of 'NoneType' and 'int'

That reads like a warning rather than a route losing its backend, which is why it sat there.

Changes

• Families are matched by prefix, longest first, so one entry covers a family's variants instead of needing a line per checkpoint spelling.
• The generic fallback stays. qwen3_5.TextModel handles dense and MoE natively, and making unknown types raise would be a regression for every model that works through it today — but the fallback is now logged instead of silent.
• A failed build names the model_type and the class that was selected, with exc_info=True so the traceback survives.

Verification

gemma-4-12B-it (text_config.model_type: gemma4_unified_text, mlx_vlm conversion, M3 Ultra):

	before	after
build_text_model	None + TypeError	builds
engine._text_model	None	mlx_lm.models.gemma4_text

Repo suite: 2305 passed (four local failures reproduce on pristine main — three Python 3.14, one missing ffmpeg). Confirmed by mutation: restoring the exact-match dispatch fails four of the new tests, including the gemma4_unified_text case specifically.

Scope: this does not fix the other half of #685, and I want to be clear about why

#685 also reports stream_generate(prompt=...) returning empty chunks, and in the issue I guessed that the missing chat template on the mlx_vlm fallback was to blame. That guess was wrong and I have corrected the issue.

_stream_generate_impl calls the mlx_vlm path regardless of whether a TextModel exists, so a working TextModel does not change that route. More to the point, I drove mlx_lm against the now-correctly-built Gemma 4 TextModel with the same raw prompt:

backend	raw prompt output
mlx_vlm path	'-..1.1______'
mlx_lm + Gemma 4 TextModel	'-......1.1___-______'
either, with the chat template applied	'The three primary colors are:\n\n1. **Red**'

Both backends agree, so this is an instruct-tuned model being handed a bare completion prompt — which is exactly what /v1/completions is for. Applying a chat template inside stream_generate would break that endpoint's semantics for every VLM, so I have deliberately left it alone.

The one thing I still cannot explain is why the engine surfaces empty text where a direct call on the same model instance surfaces the garbage above; the leading chunks are empty in both and the pump stops at completion_tokens >= max_tokens, which accounts for part of it but not the differing chunk counts. Both are wrong outputs from a wrong-shaped prompt, so I have left that noted in #685 rather than guessing at a fix.

[Thump604]

This is the right split. The family dispatch now handles Gemma 4 variants without changing the existing fallback, and failures identify the selected class with a traceback. Focused dispatch/build tests pass at the exact head. The remaining blank-chunk behavior stays correctly scoped to #685.

[waybarrios]

I noticed the new test file was missing from the Apple Silicon CI list, so I added it. This way the Gemma dispatch tests will actually run on every PR. Small oversight, but it’s covered now.