Fix wrong general.file_type value for I2_S GGUF conversion output by pujitha24 · Pull Request #620 · microsoft/BitNet · GitHub
Skip to content

Fix wrong general.file_type value for I2_S GGUF conversion output - #620

Open
Pujitha Paladugu (pujitha24) wants to merge 1 commit into
microsoft:mainfrom
pujitha24:auto/issue-619
Open

Pujitha Paladugu (pujitha24) wants to merge 1 commit into
microsoft:mainfrom
pujitha24:auto/issue-619

Conversation

@pujitha24

Copy link
Copy Markdown

Motivation:
utils/convert-hf-to-gguf-bitnet.py and utils/convert-bitnet-embedding-to-gguf.py
both wrote general.file_type = 40 for I2_S-quantized output. Per llama.cpp's
llama_ftype enum, 40 is LLAMA_FTYPE_MOSTLY_Q1_0 and 41 is
LLAMA_FTYPE_MOSTLY_I2_S, so tools that read this metadata field (e.g.
llama-cli) report the quant type as Q1_0 instead of I2_S. This does not affect
the tensor data itself or the model's numerical behavior -- only the
general.file_type metadata field and anything that displays/labels the quant
type from it.

Approach:
Change the hardcoded literal from 40 to 41 in both converters, and drop a
stale comment ("matches official model") on the now-corrected line that
implied 40 was intentional.

Two sibling converters (utils/convert.py, utils/convert-ms-to-gguf-bitnet.py)
write general.file_type for their own "i2" outtype from a different,
pre-existing GGMLFileType.MostlyI2 enum (value 2, not 40/41). That is a
separate, out-of-scope potential mislabeling in a different code path and is
not touched here.

Validation:
The 3rdparty/llama.cpp git submodule could not be checked out in this
environment (git submodule update --init failed with "No space left on
device"), and the torch/gguf/sentencepiece Python packages this repo's
converters import are not installed here either, so the full HF-to-GGUF
pipeline could not be run end to end.

To still validate by execution rather than inspection alone:

  • For convert-hf-to-gguf-bitnet.py: stubbed sys.modules for torch,
    sentencepiece, safetensors, and gguf (the gguf stub's MODEL_ARCH /
    GGMLQuantizationType return the attribute name for any access, and its
    GGUFWriter just records add_file_type's argument), loaded the real,
    unmodified utils/convert-hf-to-gguf-bitnet.py via
    importlib.util.spec_from_file_location, built a BitnetModel via
    object.new with ftype set to the I2_S sentinel, and called the real
    Model.set_gguf_parameters() method on it. Before the fix this recorded
    file_type 40; after changing 40 to 41 in the source, rerunning the same
    harness recorded file_type 41.
  • For convert-bitnet-embedding-to-gguf.py: read the exact ftype-selection
    if/elif/else block out of the file at runtime and exec'd that extracted
    source text (unmodified from disk) with args.outtype = "i2_s"; the
    resulting ftype was 40 before the fix and 41 after.
  • python3 -m py_compile on both changed files passes.
  • Verified independently via the GitHub API that this repo's pinned
    llama.cpp submodule commit (390c307752ab78fd8189f359d6954c9ba1be74af)
    defines LLAMA_FTYPE_MOSTLY_Q1_0 = 40 and LLAMA_FTYPE_MOSTLY_I2_S = 41 in
    include/llama.h, confirming 41 is the correct value.

Not run: the actual HF checkpoint -> GGUF conversion end to end, and
llama-quantize/llama-cli against a real model (blocked by the submodule
checkout failure above).

Report: #619
Signed-off-by: Pujitha Paladugu 10557236+pujitha24@users.noreply.github.com
Assisted-by: claude-sonnet-5 (via Claude Code)

Fixes #619

Motivation:
utils/convert-hf-to-gguf-bitnet.py and utils/convert-bitnet-embedding-to-gguf.py
both wrote general.file_type = 40 for I2_S-quantized output. Per llama.cpp's
llama_ftype enum, 40 is LLAMA_FTYPE_MOSTLY_Q1_0 and 41 is
LLAMA_FTYPE_MOSTLY_I2_S, so tools that read this metadata field (e.g.
llama-cli) report the quant type as Q1_0 instead of I2_S. This does not affect
the tensor data itself or the model's numerical behavior -- only the
general.file_type metadata field and anything that displays/labels the quant
type from it.

Approach:
Change the hardcoded literal from 40 to 41 in both converters, and drop a
stale comment ("matches official model") on the now-corrected line that
implied 40 was intentional.

Two sibling converters (utils/convert.py, utils/convert-ms-to-gguf-bitnet.py)
write general.file_type for their own "i2" outtype from a different,
pre-existing GGMLFileType.MostlyI2 enum (value 2, not 40/41). That is a
separate, out-of-scope potential mislabeling in a different code path and is
not touched here.

Validation:
The 3rdparty/llama.cpp git submodule could not be checked out in this
environment (git submodule update --init failed with "No space left on
device"), and the torch/gguf/sentencepiece Python packages this repo's
converters import are not installed here either, so the full HF-to-GGUF
pipeline could not be run end to end.

To still validate by execution rather than inspection alone:
- For convert-hf-to-gguf-bitnet.py: stubbed sys.modules for torch,
  sentencepiece, safetensors, and gguf (the gguf stub's MODEL_ARCH /
  GGMLQuantizationType return the attribute name for any access, and its
  GGUFWriter just records add_file_type's argument), loaded the real,
  unmodified utils/convert-hf-to-gguf-bitnet.py via
  importlib.util.spec_from_file_location, built a BitnetModel via
  object.__new__ with ftype set to the I2_S sentinel, and called the real
  Model.set_gguf_parameters() method on it. Before the fix this recorded
  file_type 40; after changing 40 to 41 in the source, rerunning the same
  harness recorded file_type 41.
- For convert-bitnet-embedding-to-gguf.py: read the exact ftype-selection
  if/elif/else block out of the file at runtime and exec'd that extracted
  source text (unmodified from disk) with args.outtype = "i2_s"; the
  resulting ftype was 40 before the fix and 41 after.
- python3 -m py_compile on both changed files passes.
- Verified independently via the GitHub API that this repo's pinned
  llama.cpp submodule commit (390c307752ab78fd8189f359d6954c9ba1be74af)
  defines LLAMA_FTYPE_MOSTLY_Q1_0 = 40 and LLAMA_FTYPE_MOSTLY_I2_S = 41 in
  include/llama.h, confirming 41 is the correct value.

Not run: the actual HF checkpoint -> GGUF conversion end to end, and
llama-quantize/llama-cli against a real model (blocked by the submodule
checkout failure above).

Report: microsoft#619
Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
Assisted-by: claude-sonnet-5 (via Claude Code)
@microsoft-github-policy-service

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant