Description
Prerequisites
- I am running the latest code. Mention the version if possible as well.
- I carefully followed the README.md.
- I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
- I reviewed the Discussions, and have a new and useful enhancement to share.
Feature Description
I’m currently working on adapting LLaVA-style multimodal models to GGUF for efficient quantization and deployment. During this process, I encountered a persistent and deeply frustrating limitation related to the GGML_MAX_NAME constant.
Specifically, the 64-character tensor name limit seems to be hardcoded in a way that’s difficult to override externally. Despite updating GGML_MAX_NAME before including ggml.h, modifying relevant constants, and even rebuilding from source, the restriction persists—leading to truncated names or quantization failure due to duplicated, clipped identifiers.
This creates significant friction for research workflows, particularly in multimodal models like LLaVA and OpenFlamingo where tensor names naturally exceed 64 characters due to deeply nested submodules. It’s become a genuine blocker for clean, lossless GGUF conversion and downstream quantization.
Would you be willing to shed light on:
The original reason behind the hardcoded 64-character limit — was it a memory concern, compatibility, legacy constraint?
Whether there's a canonical or recommended way to override or extend this limit without patching multiple parts of ggml and gguf manually?
Any known risks of increasing the max tensor name size (e.g., 128 or 256) across the toolchain, and whether longer names might be supported in future versions?
Motivation
I completely understand the need for internal constraints in a performant library like ggml. That said, I and others in the community would greatly appreciate a clearer path or guidance for adapting the library to larger-scale, real-world models with complex naming hierarchies.
Thank you very much for your time, and for your incredible work on this project.
Possible Implementation
No response