You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ERF GELU CPU execution and CUDA dispatch/support wiring
Notes
MiniMax M3’s HF implementation describes the vision tower preprocessing as Qwen2.5VL-compatible, so this reuses the existing Qwen2.5VL preprocessing path rather than adding a separate MiniMax-specific preprocessor.
The MiniMax projector has two stages:
multi_modal_projector.linear_1/2
patch_merge_mlp.linear_1/2
The patch merge needs to happen after the first projector stage, matching the HF/reference path. The converter writes both projector stages into the mmproj GGUF as mm.0, mm.2, mm.4, and mm.6.
ERF GELU is kept intentionally. Farmadupe’s parity test showed tanh GELU materially diverges from the reference embeddings, while ERF GELU keeps much closer parity.
The custom f32 conv path is also intentional. Testing showed the default conv path had noticeably worse embedding parity, while f32 conv closely matched the reference implementation.
Testing
Tested locally with the generated MiniMax M3 mmproj GGUF and MiniMax M3 Q6 model through the OpenAI-compatible server path.
Image smoke tests passed:
stop sign image: correctly identified STOP sign and readable text
cat image: correctly identified tabby cat and visual details
receipt image: correctly read merchant/header, date, line items, and total
Hermes native image attachment path was also tested after marking the local minimax-m3 provider as vision-capable; it routed images natively to the active MiniMax M3 model and produced correct results for all three images.
I had this for about a week, I still need to test this properly but I think its good to get this out for testing. Also I am unsure if this the right way go about it, suggestion are welcome. Another thing is where do we publish mmproj-minimax-m3-f16.gguf?
I was hoping that someone would pick up the vision side of minimax3!
Some comments:
the hf transformers source for minimaxv3 is stating that preprocessing for the vision tower is a clone of qwen2.5vl.
I think that means in clip.cpp all preprocessing is already implemented, and function minimax_m3_preprocess_image is actually not needed, because we already have all of the preprocessing. Where you see case PROJECTOR_TYPE_QWEN25VL: in clip.cpp, you can add minimax3l too.
I had some tokens to burn, so I think this may be a rough cut of the entire feature.
Mostly vibed. But the changes to src aren't that big. Certainly for the parts I understand.
New GGML ops: GGML_UNARY_OP_GELU_ERF
The LLM mentioned that these ops were already defined in mainline, but I don't know if it lifted them. Lifting would be ideal.
New image rope function: build_rope_vision_neox
Embedding performance metrics relative to reference implementation are provided. The table shows worst token cosim and l2norm per image.
I ordered the LLM to chase l2 norm divergence quite "low" (it could be better), so it may have gone a bit over the top in implementation. conv_2d_f32 may not actually be necessary.
I'm not sure that inventing the erf ggml ops was necessary? tanh is basically the same? I can run the benchmarks again with normal gelu and see if ti makes a meaningful difference to the numbers.
I'm not sure if the LLM wrote a erf gelu implementation for cuda. Either way, if tanh will do then we don't need one.
Upshot is that bf16 is actually _worse_, so f16 conversion is worthwhile, and the custom f32 implementation of whatever op that wsa custom implmeented, is probably surprisngly necessary.
@Farmadupe Thank you very much for guiding me (codex) to the right direction. Please kindly test with the latest code and the GGUF I have published on HF (I have updated the PR description).
FYI the mmproj doesn't have a license, which makes it forbidden for most people to download and use. The usual solution here is to use the same license as the orignal model was released under.
It's already been published so it's no a disaster, but the appearence of `qwen` in the name might be a LLMism coming through. This is totally the vision tower of minimax m3 (the reuse of qwen's preprocessing code is an ipmlementation detail))
The LLM thinks that the warnings could be solved by swapping some arguments around somewhere
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds MiniMax M3 vision support to
examples/mtmd.This adds:
PROJECTOR_TYPE_MINIMAX_M3_VLNotes
MiniMax M3’s HF implementation describes the vision tower preprocessing as Qwen2.5VL-compatible, so this reuses the existing Qwen2.5VL preprocessing path rather than adding a separate MiniMax-specific preprocessor.
The MiniMax projector has two stages:
multi_modal_projector.linear_1/2patch_merge_mlp.linear_1/2The patch merge needs to happen after the first projector stage, matching the HF/reference path. The converter writes both projector stages into the mmproj GGUF as
mm.0,mm.2,mm.4, andmm.6.ERF GELU is kept intentionally. Farmadupe’s parity test showed tanh GELU materially diverges from the reference embeddings, while ERF GELU keeps much closer parity.
The custom f32 conv path is also intentional. Testing showed the default conv path had noticeably worse embedding parity, while f32 conv closely matched the reference implementation.
Testing
Tested locally with the generated MiniMax M3 mmproj GGUF and MiniMax M3 Q6 model through the OpenAI-compatible server path.
Image smoke tests passed:
Hermes native image attachment path was also tested after marking the local
minimax-m3provider as vision-capable; it routed images natively to the active MiniMax M3 model and produced correct results for all three images.Artifact
The tested mmproj artifact is published here:
https://huggingface.co/jkyamog/MiniMax-M3-mmproj-GGUF
File:
mmproj-minimax-m3-f16-qwen-preproc.gguf