Inquiry Regarding GGUF Architecture Error
I am writing to seek your assistance regarding an issue I encountered while attempting to load one of the GGUF model files. When using the Unet Loader (GGUF), I received the following error:
"Unexpected architecture type in GGUF file, expected one of flux, sd1, sdxl, t5encoder but got 'wan'"
From my understanding, this error occurs because the Unet Loader has strict expectations regarding the model's architecture type. It seems that the model file specifies an architecture type of "wan," which the loader does not recognize. I have learned that this issue might be resolved by either using the GGUF Loader—which supports a broader range of architectures—or by manually editing the metadata in the model file.
Before proceeding with either of these solutions, I would greatly appreciate your guidance. Specifically, could you please advise on the following points?
Should I be using the GGUF Loader instead of the Unet Loader (GGUF) for this model file?
Is it safe to modify the general.architecture field in the model file (using tools such as those from llama.cpp) to match the expected value?
Are there any specific instructions or known issues regarding this discrepancy in the model’s architecture metadata?
Thank you very much for your time and assistance. I look forward to your advice on how to resolve this issue.
That error just means that you haven't updated the ComfyUI-GGUF node set to the latest version.
Whenever a new model releases and a new architecture is added, I do a full test run on all quants then add the architecture string to the list of supported ones. If you look at the code, it's listed here already
Modifying the arch string manually should not be required in most cases, except for when it was set incorrectly by an external utility or third party convert script - though we have support for models created with both other current conversion options (that being the "pig" gguf code, which is our code with all checks disabled and the arch string set to "pig", and the other one being stable-diffusion.cpp, which does not set the arch string) - though loading models created with either of these will tell you in the console that compatibility mode is active, instead of giving you an error.
So yeah. TL;DR: try to update the ComfyUI-GGUF node set - you may need to manually git pull or re-clone to the custom_nodes folder in case it's an issue with the manager or repo metadata.
I am facing the same issue, in my case the error rises in "tools\convert.py" script, the error is in line 98, "Unknown Model Architecture".
My python library for gguf is also updated to its latest version 0.14
I have pulled the latest code from github, and checked the files, loader.py surely have "wan" in architecture list, but "convert.py" does not have "wan".
Please help me out, I strictly need gguf models to run, as I am working with 6GB Vram.
My Execution :-
got prompt
Using pytorch attention in VAE
Using pytorch attention in VAE
VAE load device: cuda:0, offload device: cpu, dtype: torch.bfloat16
Requested to load CLIPVisionModelProjection
loaded completely 3608.8 1208.09814453125 True
Using scaled fp8: fp8 matrix mult: False, scale input: False
CLIP/text encoder model load device: cuda:0, offload device: cpu, current: cpu, dtype: torch.float16
Requested to load WanTEModel
loaded partially 3608.8 3603.4767150878906 0
0 models unloaded.
loaded partially 3603.476715183258 3603.4767150878906 0
Requested to load WanVAE
0 models unloaded.
loaded partially 128.0 127.9998779296875 0
!!! Exception during processing !!! Unknown model architecture!
Traceback (most recent call last):
File "D:\ComfyUI_windows_portable_v035\ComfyUI\execution.py", line 327, in execute
output_data, output_ui, has_subgraph = get_output_data(obj, input_data_all, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\ComfyUI_windows_portable_v035\ComfyUI\execution.py", line 202, in get_output_data
return_values = _map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\ComfyUI_windows_portable_v035\ComfyUI\execution.py", line 174, in _map_node_over_list
process_inputs(input_dict, i)
File "D:\ComfyUI_windows_portable_v035\ComfyUI\execution.py", line 163, in process_inputs
results.append(getattr(obj, func)(**inputs))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\ComfyUI_windows_portable_v035\ComfyUI\custom_nodes\ComfyUI-GGUF\nodes.py", line 152, in load_unet
sd = gguf_sd_loader(unet_path)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\ComfyUI_windows_portable_v035\ComfyUI\custom_nodes\ComfyUI-GGUF\loader.py", line 78, in gguf_sd_loader
arch_str = detect_arch(set(val[0] for val in tensors)).arch
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\ComfyUI_windows_portable_v035\ComfyUI\custom_nodes\ComfyUI-GGUF\tools\convert.py", line 98, in detect_arch
assert model_arch is not None, "Unknown model architecture!"
^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Unknown model architecture!
Prompt executed in 425.92 seconds
@MrMadd That is a separate issue. The conversion code for wan is currently in this draft PR
Also keep in mind the warning in the readme on that branch, as it's still a WIP multistep process that I'm working on streamlining:
For hunyuan video/wan 2.1, you will have to uncomment the block in convert.py that deals with 5D tensors. This will save a non functional model to disk first, that you can quantize. After quantization, run fix_5d_tensor.py to add back the missing key that was saved by the conversion code. You will have to edit this file to set the correct paths/architecture. This may change in the future.
Okay, i understand this better now and will wait for the new code.
But one thing i did not understand yet.
I used a wan quantized model (wan2.1-i2v-14b-480p-q5_k_m.gguf) provided by "city96" hugging face repository, I used "comfyui-gguf" latest code from "city96" github repository, I updated my "comfyui" to the latest, I used the native "comfyui-gguf" workflow, and after running it successfully till "wanimagetovideo" node, It went into error when loading the provided "gguf model" at "unet-loader" node.
If I understand it correctly, basically it ran loader.py, and it couldn't find the provided model architecture correct, that is why it ran the tools/convert.py
My question is, why was needed to run convert.py and why the provided "GGUF" Model wasn't loaded successfully with loader.py? Is there any issue with the provided Model or with my understanding of how this code works?
This is important for me to know as I did not find many people facing this same issue.
Okay wait, I just looked at the log above properly, it calls that line because the model architecture isn't set to any known default one, meaning it goes into fallback detection mode:
The ones that have the architecture set to "pig" aren't files from this repo. Which means you're running the file from calcuis/wan-gguf instead (the name is also different, the one in this repo is called "wan2.1-i2v-14b-480p-Q5_K_M.gguf" with the quant name in upper case).
We have fallback logic for those, but it needs convert.py to detect the correct model. I didn't realize it'd fail without the draft PR, I'll fix that tonight and merge it, thanks for the report.
I'm not sure if it's related, but I’ve already encountered a strange conflict between GGUF and ComfyUI.
In ComfyUI, there's the node called ComfyUI-GGUF, but there's also another node simply named gguf.
I don’t remember who created that node, but I think on GitHub they mention installing it under a different name — yet in the ComfyUI manager, it gets installed as gguf.
This causes multiple issues with the gguf library that's installed in the ComfyUI environment.
Some nodes using GGUF models can run into strange bugs because the custom node named gguf is treated like the library.
I remember fixing a lot of problems just by renaming the gguf node folder to something else.
The only downside is that you have to update it manually afterwards.
I’m not sure if they’ve fixed this in the download manager now, but I just wanted to share my experience in case it helps.
@Evados
That node pack is pretty much just our code repackaged with some checks removed to allow loading other architectures, as far as I understand.
There is an issue here where the name conflict is pointed out, and they added a workaround where the node exposes the functions of the official python gguf package.
I've also asked Comfy to fix the issue of node packs overwriting global packages, which has been merged here, meaning it shouldn't break the main node on latest.
That node pack is also the source of the gguf files with just "pig" as the arch string and no metadata info on what the actual model is, hence why we need to call convert.py while loading (source of the issue above, should be fixed on latest and load via compat mode.).