RuntimeError: mat1 and mat2 shapes cannot be multiplied
The message
RuntimeError: mat1 and mat2 shapes cannot be multipliedWhat it means
Two parts of your workflow expect data of different sizes, so PyTorch can't multiply them. In ComfyUI that almost always means a model from one family, like SD1.5, fed into another, like SDXL.
What to do
Check that every model in the workflow (checkpoint, ControlNet, AnimateDiff model, text encoder) was made for the same base model, and swap the one that wasn't.
This usually appears when the sampler starts. The popup names the node that failed:
KSampler
mat1 and mat2 shapes cannot be multiplied (154x2048 and 768x320)and the console ends its traceback with the full line:
RuntimeError: mat1 and mat2 shapes cannot be multiplied (1x2048 and 768x3072)Both are pasted from real reports (#8463 and #4669). The message comes from PyTorch, which ComfyUI runs on, so it doesn't mention models at all. We found it in 74 issues in the ComfyUI repo as of September 26, 2026.
What the numbers mean
A matrix multiply needs the second number of the first pair to equal the first number of the second pair. In 154x2048 and 768x320, one layer is handing over rows 2048 wide to a layer built for 768. Neither number is wrong by itself: each belongs to a different model. The ComfyUI docs list this exact error under "Model Architecture Mismatch", with the root cause "Using models from different architecture families together".
The mismatches maintainers keep finding
- A ControlNet for the wrong base model. The docs' own example is an SD1.5 ControlNet with an SDXL checkpoint. On #8463, ltdrdata (a ComfyUI maintainer) answered: "You cannot apply SD1.5 controlnet model to the SDXL checkpoint model." Back in 2023, comfyanonymous, another maintainer, told an SDXL user "That controlnet is only for the base model not the refiner."
- An AnimateDiff motion model for the wrong family. "You are mixing the SDXL checkpoint with the SD1.5 AnimateDiff models. They are not compatible." (ltdrdata, #6370)
- The wrong text encoder. Newer models load their text encoder (the CLIP or LLM file) separately, and a close-but-wrong one fails here. A contributor reproduced #12076 by pairing
qwen_3_4bwith flux2-klein-9b and said "This is the wrong clip"; it wantedqwen_3_8b_fp8mixed. For Wan 2.1 (#7114), the fix was the umt5 encoder from Comfy-Org's repackaged files. - The wrong loader. A Flux ControlNet user got
1x2048 and 768x3072through the triple CLIP loader and fixed it with the dual one. ltdrdata's note: "Currently, SD3.x is the only model that uses triple clip."
Finding the odd one out
Write down the base model of every file the workflow loads. The checkpoint sets the family, so the ControlNet, motion model, text encoder and loader choice all have to match it. The docs suggest downloading a model's files together from one source and starting from a template workflow before customizing, which avoids most of this.
If every file really does match, suspect the loader node. ltdrdata said on #8391 that "Normally, this type of issue occurs when a model is used incorrectly, but in this case, it could also be an issue with the model loader node," and a GGUF text encoder in #9416 failed this way until the GGUF node's author shipped a fix. That's a report for the custom node's own repo.
Other lines the same feature prints
Match yours against these if the one at the top of the page is not quite it. They come from the same code and mean related things.
mat1 and mat2 shapes cannot be multipliedmat1 and mat2 shapes cannot be multiplied (154x2048 and 768x320)!!! Exception during processing !!! mat1 and mat2 shapes cannot be multipliedKSampler mat1 and mat2 shapes cannot be multiplied