elvezjp/GLM-5.3-Flash-ELVEZ-KDA-Q8_0-gguf

GLM-5.3-Flash-ELVEZ-KDA-Q8_0 (GGUF)

GLM-5.3-Flash-ELVEZ-KDA-Q8_0.gguf — GLM-5.3-Flash Q4K with its KDA projections requantized to Q80, by ELVEZ.

This is antirez/glm-5.3-flash-gguf's GLM-5.3-Flash-Q4_K.gguf with one change: the 136 KDA (linear attention) projection tensors that the published file keeps in BF16 are requantized to Q8_0. Every other tensor is left as it was.

On a Mac Studio (M3 Ultra, 512 GB), running the same ds4-based engine and settings, decode was 10–13% faster than the original file. In our evaluations the quality was equivalent within the noise of each test (details and one small regression below).

This is the model that IXV — ELVEZ's AI development distribution for software development in Japan — runs on a Mac Studio. It is published here so that anyone can check what we changed and what we measured.

This card records what we measured and what we have not. Everything here is as of 2026-09-16.

Runtime. We have run this file only on ELVEZ's internal fork of ds4 (the engine inside IXV), with Metal on an M3 Ultra. The llama.cpp, Ollama and other snippets in the "Use this model" menu are generated by Hugging Face for every GGUF; we have not tested any of them. See Compatibility.

日本語の概要は末尾にあります。

What changed

• —Checked on the actual files: exactly 136 tensors changed type, all of them kda_{q,k,v,output} from BF16 to Q8_0.
• —Still BF16 in this file (not converted): output.weight, token_embd.weight, and the other 321 BF16 tensors of the original (for example attn_k, attn_q_b, eh_proj, hc_*_fn, kda_beta, kda_f_*, kda_g_*, pool_*).
• —The routed experts stay Q4_K.
• —The tool copies unconverted tensor data byte for byte. We verified that behaviour on synthetic GGUFs; we have not run a byte comparison of the unconverted tensors across these two 187 GB files.
• —Why these tensors: the KDA projections are dense and read on every decoded token, so their size dominates the memory reads during decode. Q8_0 halves them.

Provenance

How it was made

glm53-requant-bf16 GLM-5.3-Flash-Q4_K.gguf GLM-5.3-Flash-ELVEZ-KDA-Q8_0.gguf --tensors kda

• —The tool glm53-requant-bf16 comes from antirez/ds4 PR #964 by trueimage (open, not merged, at the time of writing; the commit is now titled "gguf: add guarded GLM BF16 requantization tooling"). We ported an earlier revision of that commit into ELVEZ's internal fork of ds4 (not public).
• —One change on our side: tensor data is read with pread and written through a fixed buffer with the file cache disabled (F_NOCACHE on macOS). The original version filled the page cache when run beside a live inference server. The output of the changed tool was byte-identical to the unchanged port on synthetic GGUFs.
• —The PR's default is --tensors kda,head, which also converts output.weight. This file uses `kda` only.
• —Target type Q8_0 (the tool's default). The conversion took 52 seconds on the M3 Ultra.

Compatibility

Tested:

• —ELVEZ's internal fork of antirez/ds4, Metal backend, Mac Studio M3 Ultra 512 GB, macOS 27, --ctx 131072 --mtp.
• —Image input, with GLM-5.3-Flash-Vision-Encoder.gguf. IXV runs this file together with the vision encoder (--vision), and reads images such as design documents with it.

Not tested:

• —Upstream antirez/ds4 as released.
• —llama.cpp or other GGUF runtimes. The architecture is glm5-next.
• —CUDA / ROCm, SSD streaming, tensor parallelism.
• —Other Apple Silicon generations. The speed numbers below are for the M3 Ultra only.

Memory: the file is about 173.8 GiB.

Evaluation

All comparisons use the original GLM-5.3-Flash-Q4_K.gguf as the baseline, on the same machine, with the same engine build, the same settings and temperature 0, one model at a time (2026-09-15 and 2026-09-16).

Speed (decode, MTP on, 3 runs each)

• —MTP verify time per cycle: 53.8 ms → 48.4 ms. The acceptance rate was about the same (65.6% vs 66.4%).
• —Prefill speed was unchanged.
• —The three runs of the same model gave identical outputs.

Quality

Notes on the quality results:

• —HumanEval. Both models' raw scores were about 15%. Chat answers returned the first line of the function body without indentation, which breaks when joined to the prompt. As in our standard procedure, we indented that first line only for problems that failed raw, identically for both models. The original's 95.12% matches our earlier measurement of the same file.
• —Japanese knowledge QA (−2). Both lost questions are about idioms. For 「敷居が高い」, this file gave the common modern (non-original) meaning, which is a real miss. For 「馬が合う」, the answer (「仲が良い」) is correct in meaning but did not contain the expected keyword. With 48 questions we cannot say whether this is noise or a small regression.
• —Long-form. Both judges took points off one business email from this file for a misspelled honorific (「悪ろしい」). Otherwise the scores trade places prompt by prompt.
• —Outputs are not bit-identical. With greedy decoding, the text from this file diverges from the original's within the first sentences.
• —The Japanese QA and long-form prompts are ELVEZ's internal evaluation sets and are not published.

Limitations

• —One machine, one evaluation session. Small test sets (48 QA questions, 6 long-form prompts).
• —Long-context quality was checked only up to about 38k tokens (speed) and a 30k-token recall test.
• —This is not a release by Z.ai or antirez. Please report problems with this file to us, not to them.

License

MIT, following the base model zai-org/GLM-5.3-Flash.

Credits

• —Z.ai — GLM-5.3-Flash.
• —antirez — ds4 and the Q4_K GGUF this file is derived from.
• —trueimage — the BF16 requantization tool (antirez/ds4 PR #964).
• —[ELVEZ Inc. / 株式会社エルブズ](https://elvez.co.jp/) — conversion, the file-cache change to the tool, and evaluation. The conversion, evaluation and this card were prepared with Claude Code (Anthropic) and reviewed by ELVEZ.

日本語の概要

• —エルブズの AI開発ディストリビューション IXV が、Mac Studio で使っているモデルです。何を変え、何を測ったかを誰でも確かめられるよう、ここで公開しています。
• —antirez さんが公開している GLM-5.3-Flash-Q4_K.gguf のうち、BF16 のまま残っている KDA 射影 136 本だけを Q8_0 にしたファイルです。ほかのテンソルの型は変えていません。
• —Mac Studio（M3 Ultra、512 GB）で同じエンジン・同じ設定で比べると、decode が 10〜13% 速くなりました。
• —品質は、official-100、HumanEval（95.12% → 96.34%）、日本語長文の審査で同等でした。日本語知識 QA は 45/48 → 43/48 で、1 問は実際の誤り、1 問は採点語の不一致です。
• —動作を確かめたのは、エルブズ内部の ds4 派生版（IXV のエンジン、Metal、M3 Ultra）だけです。画像を読む部品（GLM-5.3-Flash-Vision-Encoder.gguf）と組み合わせて、画像の入力にも使っています。本家 ds4、llama.cpp、CUDA などでは確かめていません。「Use this model」に出る llama.cpp や Ollama の手順は、Hugging Face がすべての GGUF に自動で表示するもので、当社では試していません。
• —変換ツールは antirez/ds4 の PR #964（trueimage さん作）に由来します。
• —ライセンスは元のモデルに合わせて MIT です。