arch and quantization fields blank for deepseek_v4 models despite valid config.json values

[True2456]

Summary

For a local deepseek_v4 model, the model listing (both /api/v0/models and the GUI's model info) shows blank/missing arch and quantization fields, even though config.json has valid, well-formed values for both ("architectures": ["DeepseekV4ForCausalLM"], and a "quantization" dict in the same base+per-path-override shape used by other working listings, e.g. mlx-community/DeepSeek-V4-Flash-2bit-DQ).

I don't have a confirmed root cause to report — I traced this as far as ~/.lmstudio/.internal/model-index-cache.json, where the cached entry for the model has "metadata": {"configJson": {}} (completely empty, not partially populated), while an otherwise-comparable local model of a different architecture shows a fully populated configJson with the expected fields. The directory scan itself completes cleanly (no entries in the cache's errors array, correct mtime), so this isn't a parse exception — the classifier appears to produce nothing for this field, specifically for this architecture, for a reason I can't pin down from outside the (presumably frontend) code that builds this.

Ruled out while investigating (in case useful): not caused by a missing chat_template.jinja (added one, matching the convention used by other listings for the same architecture family, no change), not caused by the shape of the quantization field (verified byte-for-byte structurally comparable to a listing that displays correctly).

Repro

1. Load or index a local MLX checkpoint with model_type: deepseek_v4 (config.json has valid top-level architectures and quantization fields).
2. Check /api/v0/models or the GUI's model card.
3. arch and quantization are absent/blank, unlike other locally-indexed architectures (e.g. a step3p7 model in the same models folder shows both correctly).

Environment

• LM Studio 0.4.20 (build 1), macOS
• Model: local MLX conversion of deepseek-ai/DeepSeek-V4-Flash (deepseek_v4 architecture, text-only)
• Related: Manual context-length input capped at 2048 for architectures outside the auto-fit validated family list (e.g. deepseek_v4) #356, and the mlx_lm/mlx_vlm dispatch issue filed alongside this one — same underlying "this architecture isn't fully accounted for yet" theme, but this is a display-only symptom, distinct code path from either of those (the model itself loads and generates correctly once the dispatch issue is worked around).

[True2456]

Closing this — I found the actual root cause, and it isn't in this repo.

The blank arch and quantization are a downstream symptom of metadata.configJson being empty ({}) in model-index-cache.json, which I noted in the original report but couldn't explain. The trigger is tokenizer_config.json using the HuggingFace AddedToken object form for bos_token/eos_token/pad_token:

"bos_token": {"__type": "AddedToken", "content": "<｜begin▁of▁sentence｜>", "lstrip": false, "normalized": true, "rstrip": false, "single_word": false}

Converting those three to plain strings populates configJson with arch, modelType, quantizationBits, quantizationMode, chatTemplate, and the correct contextLength in one go. Nothing else in the model directory changes.

This has nothing to do with the architecture. I reproduced it with ~600-byte throwaway model directories (a tiny model.safetensors saved with metadata={"format": "mlx"}, a config.json, a tokenizer_config.json) using llama as the model type: object form → configJson: {}; plain strings → fully populated. The AddedToken object form is standard HF tokenizer output, so any checkpoint carrying it is affected.

Also ruled out with individual controlled tests, since they were plausible and are worth recording as negatives: config.json size (a 140KB config indexes fine), the deepseek_v4 model type itself, the presence or absence of vision_config, and a 102GB single-file model.safetensors.

Because this is the classifier that writes model-index-cache.json rather than anything in mlx_engine, this is the wrong repo — closing here. Sorry for the misfile and for the vaguer original report.

Worth flagging for anyone who hits this: converting to plain strings is not a usable workaround on its own. With correct metadata, LM Studio stops delegating prompt templating to mlx_vlm and then fails every request with TypeError: Cannot read properties of undefined (reading 'template') at temp_createMlxPredictionArgs. In my case it also persisted an llm.prediction.promptTemplate entry into ~/.lmstudio/.internal/user-concrete-model-default-config/<owner>/<model>.json with type: "jinja" but no jinjaPromptTemplate object (only a manualPromptTemplate), which kept the model failing after the tokenizer change was reverted, and survived unload/reload and lms server restart. Deleting that field restored it.

#356 is the same root cause and is being closed alongside this. #357 is unrelated and still stands.