Имя файла GGUF с меткой Q4_K_M не доказывает, что весь полезный объём весов хранится по ожидаемой схеме. В одном файле могут использоваться разные типы тензоров, а отдельные слои могут занимать значительную долю данных. Поэтому более агрессивный квант иногда скрывается под более тяжёлой маркировкой.
Надёжная проверка строится по содержимому файла: сначала фиксируют исходный GGUF и его хэш, затем читают metadata, проверяют ключи вроде .block_count, выгружают распределение типов тензоров, отделяют полезный размер параметров от служебных структур и только после этого сравнивают результат с референсом. KLD помогает усилить подозрение, если качество заметно отклоняется от сопоставимого файла, но сама по себе эта метрика не определяет тип квантизации.
Первое техническое правило касается чтения metadata GGUF. gguf_find_key() возвращает -1, если ключ не найден. Такое значение нельзя передавать в gguf_get_val_u32(): внутри возможен GGML_ASSERT и аварийное завершение. Отсутствие .block_count не доказывает подмену кванта, однако требует отдельной проверки происхождения, генератора и совместимости файла.
Как проверить GGUF-кванты: короткий алгоритм
Проверка должна идти в фиксированном порядке. Это снижает риск принять особенность конкретной архитектуры за доказательство неправильной маркировки.
- Зафиксируйте исходный артефакт. Сохраните полный путь к GGUF, размер файла, хэш, название заявленного кванта и источник загрузки. Если файл потом заменят под тем же именем, хэш позволит отличить новую копию от исходной.
- Снимите metadata. Сохраните найденные ключи и их значения, отдельно отметьте отсутствующие поля и ошибки чтения.
- Проверьте структуру. Начните с идентификатора архитектуры, числа блоков, сведений о модели и параметрах. Ключ
.block_countпроверяйте явно. - Соберите список тензоров. Для каждого тензора нужны имя, тип, количество элементов и, если инструмент это показывает, фактический объём данных.
- Сравните полезный размер. Отделите данные тензоров от metadata, каталога тензоров, выравнивания и других накладных расходов контейнера.
- Сопоставьте качество. При наличии корректных измерений сравните KLD с референсной моделью в одинаковых условиях.
- Сформулируйте вердикт. Подмена маркировки требует совокупности независимых признаков. Один необычный тип тензора или небольшой разброс размера такой вывод не подтверждает.
Какие данные собрать до анализа
Сначала зафиксируйте объект проверки. Анализ страницы репозитория без сохранённого файла не даёт воспроизводимого результата: автор может заменить GGUF, изменить описание или загрузить новую ревизию под похожим названием.
- полный путь к файлу и его исходное имя;
- размер в байтах и криптографический хэш;
- заявленный квант, например Q4_K_M, Q3 или IQ2;
- название модели, архитектуру и число параметров;
- источник загрузки и идентификатор ревизии, если он доступен;
- название и версию инструмента, который читал GGUF;
- сопоставимый референсный файл той же модели.
Для файлов, которые обновляются без очевидного изменения имени, полезна отдельная сверка SHA-256, commit и дампа GGUF. Практический пример такого подхода разобран в материале про тихую замену GGUF-файлов.
Как выглядит предварительный вердикт
Промежуточный результат лучше оформлять как уровень уверенности, а не как обвинение автора файла. Такой формат учитывает особенности смешанного квантования и неполные metadata.
| Категория | Что наблюдается | Что делать |
|---|---|---|
| Признаки соответствия | Metadata читаются, архитектура совпадает, распределение типов и полезный размер близки к референсу. | Считать маркировку согласованной с содержимым, сохранив отчёт. |
| Единичное несоответствие | Один ключ отсутствует, размер немного отличается или встречается нетипичный тип тензора. | Перепроверить версию конвертера, архитектуру и состав исключений. |
| Несколько независимых признаков | Распределение смещено к более агрессивным типам, полезный размер заметно ниже референса, KLD хуже. | Считать маркировку сомнительной и не использовать файл для сравнения моделей без дополнительного подтверждения. |
| Недостаточно данных | Metadata не читаются, нет референса или инструмент не показывает типы тензоров. | Не делать вывод о честности кванта. Сначала получить недостающий отчёт. |
Почему по названию Q4_K_M нельзя определить реальный квант
Метка вроде Q4_K_M описывает заявленный способ хранения весов. Она помогает быстро подобрать файл под доступную память, но не заменяет проверку контейнера. Название файла, карточка модели и обсуждения сообщества относятся к внешней маркировке. Metadata и каталог тензоров показывают, что реально записано в GGUF.
Что именно обещает маркировка кванта
В названии кванта зашифрована ожидаемая битность и схема распределения типов между группами весов. Буква или цифра в имени не означает, что каждый тензор использует один и тот же формат. Чувствительные компоненты могут храниться с большей точностью, а разные группы слоёв могут получать разные типы блоков.
Для Q4_K_M корректный вопрос звучит так: совпадает ли фактический набор и объём типов тензоров с ожидаемой схемой для этой архитектуры? Вопрос «нашёлся ли внутри один Q4-тензор» слишком узкий и часто приводит к ошибочному выводу.
Обратная ситуация тоже встречается в практических сценариях: низкобитный файл может содержать более тяжёлые типы из-за fallback-механизма конвертера. Причины такого поведения и проверка фактического размера разобраны в статье о несовпадении имени GGUF-кванта с содержимым файла.
Какие несоответствия должны насторожить
- Типы тензоров не совпадают с заявленной схемой. Например, файл с меткой Q4_K_M по основному объёму данных похож на более агрессивный набор Q2 или Q3, тогда как отдельные Q4-тензоры составляют небольшую часть.
- Доля агрессивных типов необычно велика. Само присутствие Q2, Q3, IQ1 или IQ2 ничего не доказывает: исключения для отдельных слоёв допустимы. Сигнал появляется при сравнении их вклада с референсом той же модели.
- Полезный размер выглядит нетипично. Сравнивать нужно объём данных тензоров, а не только размер файла в файловой системе.
- KLD заметно хуже референса. Метрика усиливает подозрение, если измерения выполнены на той же исходной модели и в тех же условиях.
- Metadata неполны или противоречивы. Отсутствие ожидаемых ключей снижает уверенность в том, что файл корректно описан и совместим с используемым читателем.
Каждый признак нужно проверять относительно той же модели, архитектуры, версии конвертации и набора исключений. Сравнение Q4_K_M одной архитектуры с Q4_K_M другой модели не показывает честность маркировки.
Как читать metadata GGUF и что делать с block_count
Metadata GGUF дают контекст для анализа: помогают понять архитектуру, число блоков, сведения о модели и параметры, с которыми нужно сравнивать файл. Они не заменяют каталог тензоров. Уровень квантизации устанавливают по фактическим типам и объёму тензорных данных, а metadata помогают проверить, что перед вами нужная модель и корректно описанный контейнер.
Какие поля metadata проверять в первую очередь
Набор ключей зависит от архитектуры и генератора GGUF, поэтому удобнее проверять группы полей, а не составлять универсальный список для всех моделей.
| Группа данных | Что проверяет | Чего не подтверждает |
|---|---|---|
| Идентификатор архитектуры | Помогает убедиться, что файл относится к нужной архитектуре и сопоставим с референсом. | Не показывает битность отдельных тензоров. |
.block_count | Показывает число блоков там, где этот ключ предусмотрен логикой чтения. | Не устанавливает, Q4 это, Q3 или другой квант. |
| Сведения о модели | Позволяют сверить имя, параметры и другие признаки исходного checkpoint. | Не исключают ошибку конвертации или переименование файла. |
| Параметры контекста и токенизатора | Помогают выявить файл от другой версии модели или несовместимого преобразования. | Не заменяют подсчёт типов тензоров. |
| Каталог тензоров | Содержит имена, размеры и типы массивов, по которым оценивают фактическую схему хранения. | Сам по себе не сообщает, насколько хорошо квант сохраняет качество. |
Почему отсутствие ключа нельзя молча игнорировать
В логике, связанной с определением speculative types для draft-модели, сначала ищут ключ .block_count. Функция gguf_find_key() возвращает -1, если поиск завершился без результата. Программа должна проверить это значение до чтения числа.
// схематичный псевдокод
key_id = gguf_find_key(ctx, '.block_count')
if key_id < 0:
report('key not found')
else:
block_count = gguf_get_val_u32(ctx, key_id)Передача отрицательного key_id в gguf_get_val_u32() может привести к проверке GGML_ASSERT(key_id >= 0 ...) и остановке процесса. Для диагностического инструмента это плохое поведение: вместо отчёта о неполной metadata пользователь получает падение программы.
Отсутствующий .block_count нужно трактовать как отдельный сигнал совместимости и происхождения. Он может указывать на неполный набор metadata, особенности генератора или несовместимость читателя. Сам по себе этот факт не доказывает, что Q4_K_M переименовали из Q3 или другого уровня.
Как зафиксировать результат чтения metadata
Сохраните отчёт в текстовом или структурированном виде. Скриншот страницы репозитория не подходит для повторной проверки: в нём нет полного набора ключей, значений и ошибок чтения.
- запишите все найденные ключи и значения;
- составьте отдельный список отсутствующих ключей;
- отметьте ошибки декодирования типов и массивов;
- сохраните версию инструмента чтения GGUF;
- свяжите отчёт с хэшем проверяемого файла;
- зафиксируйте дату анализа и имя референсного GGUF.
Такой отчёт позволяет отделить проблему файла от ошибки конкретного инструмента. Если два читателя по-разному показывают metadata, сначала сравните их версии и поддержку формата.
Как определить реальный квант GGUF по типам тензоров
После проверки metadata нужно перейти к содержимому каталога тензоров. Для каждого массива соберите имя, тип, форму, количество элементов и фактический объём данных, если его возвращает инструмент. Затем сгруппируйте записи по типу и посчитайте вклад каждой группы в общий полезный размер.
Почему одного типа тензора недостаточно
Квантованные модели используют смешанное распределение. Большие матрицы, эмбеддинги, выходные слои и чувствительные компоненты могут храниться с разными типами. Один найденный Q4-тензор подтверждает только наличие этого типа в файле.
Для оценки схемы важнее доля данных, которую занимает группа тензоров. Десять небольших тензоров Q4 не компенсируют крупные матрицы, записанные в более агрессивном формате. Поэтому считайте объём по тензорам, а не только количество строк в списке.
Практическая запись в отчёте может выглядеть так:
- тип тензора;
- число тензоров этого типа;
- суммарное количество элементов;
- суммарный объём полезных данных;
- список крупных тензоров, которые сильнее всего влияют на итоговый размер.
С чем сравнивать распределение
Лучший референсный файл содержит ту же модель, ту же архитектуру и близкую схему квантизации. Желательно, чтобы оба GGUF создавались с сопоставимыми исключениями для отдельных слоёв.
- Сравнение с другой моделью даёт слабый сигнал: у неё могут отличаться размеры матриц и набор чувствительных тензоров.
- Сравнение с другим checkpoint той же модели требует проверки числа параметров и версии исходных весов.
- Сравнение с файлом от другого конвертера ограничено: инструмент мог использовать другой набор типов или иной fallback.
- Сравнение только по числу тензоров хуже сравнения по суммарному объёму их данных.
При выборе между ультранизким IQ1_S и более тяжёлым Q4 полезно разделять два вопроса: сколько памяти занимает файл и какую схему действительно использует его содержимое. Практическое сравнение этих вариантов собрано в материале об IQ1_S и Q4 для локального запуска.
Как интерпретировать явный перекос
| Наблюдение | Сила сигнала | Корректная трактовка |
|---|---|---|
| Встречается отдельный тип, которого нет в описании | Слабая | Проверить исключения для слоёв и референсный файл. |
| Крупные матрицы используют более агрессивные типы, чем в референсе | Средняя | Есть техническое несоответствие, требуется проверка полезного размера и качества. |
| Большая часть полезного объёма смещена к более низкой битности | Сильная | Маркировка может скрывать более агрессивную схему сжатия. |
| Распределение, размер и качество одновременно отличаются от референса | Очень сильная | Файл следует считать сомнительным до выяснения происхождения и способа сборки. |
Универсальный процент для определения подмены задавать нельзя. Итог зависит от архитектуры, числа параметров, метода квантизации, imatrix, специальных типов и исключений для отдельных слоёв.
Размер GGUF после удаления служебных таблиц: полезный, но не решающий признак
Размер файла в файловой системе складывается из данных параметров и накладных расходов контейнера. В него входят metadata, tensor directory, выравнивание, таблицы смещений и другие служебные структуры. Поэтому сравнивать только общий размер недостаточно.
Что именно сравнивать в размерах
Если используемый читатель показывает смещения и размеры массивов, оцените полезный объём как сумму фактических данных всех тензоров. Это приближение удобнее считать отдельно от metadata и каталога тензоров.
| Показатель | Зачем нужен |
|---|---|
| Общий размер GGUF | Показывает, сколько места занимает весь контейнер на диске. |
| Суммарный размер данных тензоров | Позволяет сравнить реальный вклад параметров без большей части служебных структур. |
| Размер metadata и каталога тензоров | Помогает объяснить разницу между двумя файлами с похожим составом весов. |
| Доля крупных тензоров | Показывает, какие массивы определяют итоговый размер и могут менять средний bpw. |
Для корректного сравнения нужны одна модель, сопоставимое число параметров и близкая структура исключений. Сопоставляйте Q4_K_M с референсным Q4_K_M этой же модели, а не с условным Q4 другой архитектуры.
Почему маленький или большой файл не доказывает подмену
Размер меняется из-за битности, формы матриц, специальных типов отдельных слоёв, версии конвертера и выравнивания. На итог влияют и служебные области контейнера. Поэтому необычный размер служит сигналом для следующего шага, а не готовым вердиктом.
- Меньший файл может использовать больше низкобитных типов или иметь другой состав исключений.
- Больший файл может содержать чувствительные тензоры в более точном формате.
- Разница в служебных данных особенно заметна при сравнении небольших моделей.
- Одинаковая метка не гарантирует одинаковый средний bpw, если конвертеры распределяли типы по-разному.
Если общий размер отличается, сначала сравните полезный объём тензоров. Затем проверьте распределение типов. Связка этих двух показателей намного информативнее числа, указанного в свойствах файла.
KLD и качество: когда метрика усиливает подозрения
KLD, или дивергенция Кульбака-Лейблера, измеряет расхождение распределений. В контексте GGUF обычно сравнивают распределение вероятностей следующих токенов у исходной или референсной модели и у проверяемого кванта.
Как сделать сравнение KLD корректным
Число KLD имеет смысл только вместе с методикой измерения. Зафиксируйте одинаковые условия для обоих файлов.
- Используйте один и тот же исходный checkpoint.
- Подавайте одинаковый набор текстов или входных последовательностей.
- Применяйте одну токенизацию и одинаковые специальные токены.
- Сохраняйте одинаковые настройки вычислений, включая режимы, которые влияют на численную точность.
- Используйте одну процедуру агрегации: среднее по токенам, слоям или последовательностям нельзя смешивать.
Сравнение с произвольным числом из обсуждения не даёт надёжного вывода. Разные наборы входов и разные процедуры расчёта могут заметно изменить результат даже для одного GGUF.
Что KLD может и не может показать
| Ситуация | Интерпретация |
|---|---|
| KLD близок к референсу, типы и размер совпадают | Это поддерживает гипотезу о соответствии файла заявленной схеме, но не заменяет чтение GGUF. |
| KLD заметно выше, а полезный размер и типы указывают на более агрессивный квант | Несколько независимых признаков усиливают подозрение в несоответствии маркировки. |
| KLD выше при совпадающей структуре тензоров | Причиной может быть конвертация, токенизация, вычислительный режим или другой исходный checkpoint. |
| KLD отсутствует | Проверку можно провести по metadata, типам и размеру, но уровень уверенности будет ниже. |
KLD не сообщает напрямую, какой тип блока записан в конкретном тензоре. Высокое значение может согласовываться с более агрессивным квантованием, ошибкой конвертации или несовместимыми условиями теста. Метрика усиливает техническую гипотезу, но не идентифицирует Q4_K_M, Q3 или IQ2 по одному числу.
Итоговая проверка честности GGUF-кванта
Финальный вердикт формируйте после объединения всех доступных признаков. Файл, который помещается в VRAM, ещё не доказал соответствие своей маркировке: меньший размер может быть следствием более агрессивной квантизации и потенциальной потери качества.
Чек-лист перед запуском модели
- Проверьте источник, имя файла и хэш.
- Сохраните полный отчёт по metadata GGUF.
- Отдельно обработайте отсутствующие ключи, включая
.block_count. - Соберите список типов тензоров, их количества и объёма данных.
- Отделите полезный размер параметров от metadata,
tensor directoryи выравнивания. - Сравните результат с референсным GGUF той же модели.
- При наличии сопоставимого измерения проверьте KLD и сохраните условия расчёта.
Когда файл можно считать сомнительным
Маркировка заслуживает отдельной проверки, если несколько независимых признаков указывают на более агрессивную схему: крупные тензоры используют более низкую битность, полезный размер заметно отличается от референса, metadata неполны, а KLD ухудшается в одинаковом тесте.
| Итог | Основание |
|---|---|
| Соответствует | Структура metadata, распределение типов, полезный размер и качество согласуются с референсом. |
| Есть признаки несоответствия | Обнаружен один технический сигнал, который ещё может объясняться архитектурой или инструментом. |
| Маркировка сомнительна | Несколько независимых признаков указывают на более агрессивный фактический квант. |
| Данных недостаточно | Файл не удаётся полноценно прочитать или отсутствует сопоставимый референс. |
Формулировка «файл сомнительный» точнее, чем категоричное заявление о подмене. Она показывает, что содержимое не согласуется с описанием, но оставляет место для проверки конвертера, версии исходных весов и специальных исключений.
Что дает проверка аттестации артефакта
Если для конкретного файла существует аттестация, её можно проверить отдельной командой:
gh attestation verify --owner ggml-org <filename-or-url>Такая проверка относится к происхождению артефакта и связанному с ним процессу сборки. Она может подтвердить, что файл связан с заявленным процессом публикации, но сама по себе не доказывает наличие внутри именно Q4_K_M. Уровень квантизации по-прежнему проверяют по metadata, типам тензоров, полезному размеру и качеству.
| Признак | Что он подтверждает | Ограничение |
|---|---|---|
| Название файла | Заявление автора о формате. | Не гарантирует фактический состав тензоров. |
| Metadata GGUF | Контекст модели, архитектуру, число блоков и параметры контейнера. | Не описывает полностью качество кванта. |
| Типы тензоров | Фактическую структуру хранения массивов. | Нужен анализ всего распределения, а не одного тензора. |
| Полезный размер | Приблизительный объём данных параметров. | Зависит от архитектуры, исключений и служебных структур. |
| KLD | Расхождение поведения с референсом при заданной методике. | Не идентифицирует конкретный квант и чувствителен к условиям теста. |
| Аттестация | Происхождение или связь файла с процессом сборки, если такая проверка доступна. | Не доказывает фактическую битность весов. |
Практический критерий простой: доверяйте согласованной совокупности признаков. Если название обещает Q4_K_M, metadata читаются корректно, типы и полезный размер близки к референсу, а KLD измерен в тех же условиях, оснований для подозрений мало. Если файл заметно меньше, содержит другой набор типов и одновременно показывает худшее качество, его лучше считать сомнительным до дополнительной проверки.