Broken processor_class and auto_map prevent loading on mlx-vlm 0.6.8

#1
by v-urushkin - opened

Environment

  • macOS (Apple Silicon)
  • Python 3.14
  • mlx-vlm 0.6.8
  • This model's README states it was converted with mlx-vlm 0.3.10

Problem

load("mlx-community/DeepSeek-OCR-2-bf16") fails before any inference can run. There are two independent issues in the repo files; both must be fixed before the model loads.
from mlx_vlm import load, generate
from mlx_vlm.prompt_utils import apply_chat_template

model, processor = load("mlx-community/DeepSeek-OCR-2-bf16", trust_remote_code=True)
ValueError: Unrecognized processing class in <path>. Can't instantiate a processor,
a tokenizer, an image processor, a video processor or a feature extractor for this model.

Root cause

1. Wrong processor_class in processor_config.json

The file declares:

"processor_class": "DeepseekVLV2Processor"
DeepseekVLV2Processor is the class mlx-vlm registers for model_type: deepseek_vl_v2, not for this model. config.json has "model_type": "deepseekocr_2", for which mlx-vlm registers DeepseekOCR2Processor (mlx_vlm/models/deepseekocr_2/processing_deepseekocr.py).

mlx-vlm 0.6.8 dispatches processors by reading config.json's model_type in a composable patch on AutoProcessor.from_pretrained (mlx_vlm/models/base.py, install_auto_processor_patch). For deepseekocr_2 it calls DeepseekOCR2Processor.from_pretrained(...). However, transformers.ProcessorMixin.from_pretrained validates the processor_class field against the current class name; the mismatch (DeepseekVLV2Processor ≠ DeepseekOCR2Processor) raises, that exception is swallowed by a bare except in the patch (base.py:582), and execution falls through to the stock AutoProcessor.from_pretrained, which then errors with the message above. (The swallowed exception makes this misleading to debug — the real failure is hidden.)

2. auto_map in config.json points to torch modeling files with unavailable deps

config.json contains two auto_map blocks (top-level and nested under language_config), referencing the bundled torch .py files:

"auto_map": {
  "AutoConfig": "modeling_deepseekocr2.DeepseekOCR2Config",
  "AutoModel": "modeling_deepseekocr2.DeepseekOCR2ForCausalLM"
}

During processor loading, AutoTokenizer.from_pretrained → AutoConfig.from_pretrained(trust_remote_code=True) loads the dynamic module, which imports addict and matplotlib:
ImportError: This modeling file requires the following packages that were not found
in your environment: addict, matplotlib. Run pip install addict matplotlib
These torch modeling files are irrelevant to MLX inference (mlx-vlm dispatches by model_type into its own MLX classes). For comparison, the working mlx-community ports of the sibling DeepSeek-OCR / unlimited-ocr models ship no auto_map and no torch .py files at all.

Fix

Two minimal edits to the repo files:

processor_config.json:
-  "processor_class": "DeepseekVLV2Processor",
+  "processor_class": "DeepseekOCR2Processor",
config.json — remove the top-level auto_map:
     "architectures": ["DeepseekOCR2ForCausalLM"],
-    "auto_map": {
-      "AutoConfig": "modeling_deepseekocr2.DeepseekOCR2Config",
-      "AutoModel": "modeling_deepseekocr2.DeepseekOCR2ForCausalLM"
-    },
     "bos_token_id": 0,
and the nested one under language_config:
         "architectures": ["DeepseekV2ForCausalLM"],
-        "auto_map": {
-          "AutoConfig": "configuration_deepseekv2.DeepseekV2Config",
-          "AutoModel": "modeling_deepseek.DeepseekV2Model",
-          "AutoModelForCausalLM": "modeling_deepseek.DeepseekV2ForCausalLM"
-        },
         "bos_token_id": 0,

After both edits, the model loads and runs correctly, producing the expected structured output (<|ref|>…<|/ref|><|det|>[[x1,y1,x2,y2]]<|/det|>) with <|grounding|>OCR this image..

Expected behavior

The model should load out-of-the-box on the current mlx-vlm release. Since the port predates the current processor-class naming and still carries torch-side auto_map, it would help to either regenerate the port with a recent mlx_vlm.convert or apply the two edits above (and ideally drop the unused torch .py files).


This issue was generated by GLM-5.2 (max)

MLX Community org

Hi @v-urushkin !

Thank you so much for this incredibly detailed breakdown! Since I am a non-coder community member, I actually consulted an AI assistant to make sure I fully understood your technical analysis regarding the processor_class mismatch and the legacy auto_map torch dependencies.

Your diagnosis is incredibly precise, and providing the exact line edits to get it running on mlx-vlm 0.6.8 is immensely helpful! I am using my role in the community to flag this directly for the repository maintainers so they can update processor_config.json and config.json with your fixes (or cleanly re-run the port using a recent mlx_vlm.convert).

Thank you for doing the heavy lifting to help everyone out. Your contribution is greatly appreciated! 🙌

Sign up or log in to comment