Короткий ответ: обновление нужно сначала подтвердить по файлу
Скачивать новый GGUF для Ornith 1.5 35B A3B вслепую пока не нужно. В доступных материалах нет официального commit, SHA-256, дампов метаданных и результатов сравнения старого и нового Q4_K_M. Поэтому нельзя подтвердить изменение весов, калибровочного чекпоинта, качества ответов или скорости генерации.
Изменившийся размер файла, поле version, finetune или путь в метаданных сигнализируют о том, что файл стоит проверить. Эти признаки не доказывают обновление самой модели. Байтовое различие может появиться после повторной квантизации, изменения служебных строк, новой упаковки тензоров или смены исходного checkpoint.
Новому пользователю разумно брать файл, который привязан к актуальному commit и контрольной сумме. Владельцу рабочей локальной установки стоит сохранить старый GGUF, снять его SHA-256 и сравнить новый файл в одинаковой конфигурации. Для production-задач заменять квант следует после smoke test и проверки ключевых сценариев.
- Есть SHA-256 и commit, локальный хэш совпадает: файл идентифицирован.
- Хэш отличается, но видны лишь служебные метаданные: качество пока под вопросом.
- Меняются tensor data, исходный checkpoint или параметры квантизации: повторное тестирование оправдано.
Что считать тихим апдейтом Ornith 1.5 35B GGUF
Тихим апдейтом называют замену файла в репозитории без заметного changelog или отдельного анонса. Имя Ornith 1.5 35B Q4_K_M при этом может остаться прежним. Имя кванта не гарантирует одинаковые тензоры, одинаковый размер и одинаковое происхождение сборки.
Перезаливка, повторная квантизация или новые веса
Повторная загрузка того же файла дает одинаковый SHA-256. Дата публикации и время скачивания при этом могут отличаться, поэтому на них полагаться нельзя.
Другой размер при том же имени иногда связан с обновлением GGUF-метаданных, иной версией конвертера или составом служебных данных. Такой случай требует сравнения, но сам по себе ничего не говорит о поведении модели.
Повторная квантизация меняет байты тензоров даже при одном и том же исходном FP16 или BF16 checkpoint. Причинами бывают новая версия llama-quantize, другой набор imatrix-данных, отличающиеся параметры сборки и иная обработка отдельных тензоров. Подробнее о ситуации, когда маркировка кванта расходится с фактическим содержимым, разобрано в материале о несоответствии имени GGUF-кванта его содержимому.
Обновление исходных весов можно подтвердить историей публикации, описанием нового checkpoint или воспроизводимым сравнением тензоров после исключения метаданных. Разный SHA-256 показывает различие файлов, но не отвечает на вопрос, где именно оно находится.
Почему калибровочный чекпоинт важен для Q4_K_M
Q4_K_M хранит веса в 4-битном K-кванте с дополнительными правилами для части тензоров. При квантизации сборщик может применять калибровочные данные, часто называемые imatrix, чтобы точнее распределить ошибку округления между весами.
Если для двух файлов использованы разные калибровочные наборы или checkpoint, итоговые квантованные значения способны различаться при одинаковом имени Q4_K_M. Это потенциально влияет на форматирование, следование инструкции, устойчивость длинного контекста и ошибки в отдельных задачах. Направление эффекта заранее неизвестно: новый calibration checkpoint не доказывает улучшение ответов.
Что изменилось в Ornith 1.5 35B Q4_K_M: карта проверяемых отличий
В предоставленном Research Pack нет фактических значений для старого и нового Ornith 1.5 35B A3B Q4_K_M. Ниже приведена карта проверки, которая отделяет наблюдаемые признаки от выводов о весах.
| Признак | Что фиксировать | Что подтверждает | Чего не подтверждает |
|---|---|---|---|
| Имя файла | Полное имя и расширение | Целевой вариант кванта | Идентичность содержимого |
| Размер | Точное число байт | Байтовое различие при заметном расхождении | Рост качества |
| SHA-256 | Полная контрольная сумма | Идентичность или различие файлов | Причину различия |
| Commit Hugging Face | Идентификатор, дата, история файла | Происхождение опубликованной версии | Преимущество новой сборки |
| Метаданные | general.version, general.finetune, пути, архитектура | Различия служебной информации | Изменение всех весов |
| Tensor data | Список, типы и байты тензоров | Существенное различие кванта | Лучшие ответы без теста |
Пути в метаданных: что они показывают и чего не доказывают
В GGUF иногда сохраняются строки с путём к исходной модели, каталогу конвертации, checkpoint или файлу калибровки. Путь помогает понять происхождение сборки, если автор его оставил. Он может поменяться после переноса процесса сборки на другой сервер или в другой каталог.
Например, различие между двумя строками пути подтверждает изменение окружения или входного файла, на который ссылается метаданные. Для вывода об обновлении весов нужен более сильный сигнал: различающиеся тензоры, прозрачная история commit или описание новой базовой модели.
Поля version и finetune в GGUF
general.version часто отражает строку версии, заданную при конвертации. general.finetune может обозначать вариант дообучения или имя ветки. Набор ключей зависит от конвертера и автора файла, поэтому отсутствие поля тоже не указывает на проблему.
Сравнивайте значения в двух дампах построчно. Изменение version полезно для идентификации сборки, а новое значение finetune может указывать на другую ветку модели. Ни одно из этих полей не заменяет бенчмарк или проверку качества на одинаковых промптах.
Размер файла: полезный сигнал, но не окончательное доказательство
Размер Q4_K_M зависит от числа и типов тензоров, их формы, схемы квантизации, встроенных метаданных и служебных блоков. Разница даже в несколько мегабайт заслуживает проверки, если имя файла не поменялось. Фиксируйте размер в байтах вместе с SHA-256 и commit, иначе позднее будет сложно восстановить, какие именно файлы сравнивались.
Без опубликованных значений нельзя честно назвать размер старой или новой версии Ornith 1.5 35B. В таблице проверки вместо догадок должны стоять фактические данные из карточки файла и локальной копии.
Как проверить свою версию GGUF Ornith 1.5 35B
Проверка занимает несколько минут и не требует запускать модель. Начните с полного имени файла, точного размера и SHA-256. Затем сохраните дамп метаданных и свяжите результат с конкретным commit в репозитории.
Проверка размера и контрольной суммы
В Linux используйте:
stat -c '%n %s bytes' Ornith-1.5-35B-A3B-Q4_K_M.gguf
sha256sum Ornith-1.5-35B-A3B-Q4_K_M.ggufВ macOS:
stat -f '%N %z bytes' Ornith-1.5-35B-A3B-Q4_K_M.gguf
shasum -a 256 Ornith-1.5-35B-A3B-Q4_K_M.ggufВ Windows PowerShell:
Get-Item .\Ornith-1.5-35B-A3B-Q4_K_M.gguf | Select-Object Name,Length
Get-FileHash .\Ornith-1.5-35B-A3B-Q4_K_M.gguf -Algorithm SHA256Сохраните вывод рядом с параметрами запуска. Совпадающий SHA-256 надежнее совпадающего имени, даты файла и округленного размера. Если в репозитории нет опубликованной контрольной суммы, зафиксируйте свою: она поможет сравнить версии после будущей замены файла.
Просмотр метаданных GGUF
Для просмотра используйте gguf-dump или утилиту дампа из установленной версии llama.cpp. Название исполняемого файла зависит от сборки, поэтому сначала проверьте список доступных утилит. Нужен текстовый вывод, который можно сохранить и сравнить обычным diff-инструментом.
gguf-dump Ornith-1.5-35B-A3B-Q4_K_M.gguf > ornith-q4km-metadata.txtЗафиксируйте как минимум general.architecture, general.name, general.version, general.finetune, число тензоров, типы тензоров и строки, связанные с исходной моделью или калибровкой. Поле может отсутствовать, если конвертер его не записал.
Сопоставление с commit на Hugging Face
В истории файлов репозитория найдите конкретный commit, дату публикации, имя GGUF и размер. Сверьте их с локальной копией. Если история показывает замену файла с тем же именем, запишите идентификатор commit в заметки к локальной модели.
Без истории commit или опубликованной checksum нельзя надежно установить, какая версия была скачана раньше. В таком случае не удаляйте старый файл: он нужен для локального сравнения и отката.
Что может измениться после обновления: качество, скорость и память
Различия в кванте способны повлиять на ответы, загрузку и расход памяти. Направление изменений нельзя предсказать по одному размеру файла или строке в метаданных. Проверка должна проходить на одинаковом backend, железе и настройках генерации.
Качество на одинаковых промптах
Подготовьте набор из 10-20 характерных задач: строгий JSON, суммаризация длинного текста, извлечение фактов, код, русский диалог и ваш реальный рабочий сценарий. Для старого и нового GGUF задайте один system prompt, одинаковые seed, temperature, top_p, контекст, шаблон чата и backend.
Сравнивайте соблюдение формата, фактические ошибки, обрывы ответа, поведение на длинном контексте и повторяемость. Одна удачная генерация не дает основания назвать новый Q4_K_M лучше.
VRAM, RAM и offload
Размер GGUF на диске не равен расходу VRAM во время инференса. На память влияют число слоёв, выгруженных на GPU, размер KV cache, длина контекста, batch size, backend и дополнительные тензоры модели.
После обновления запишите потребление RAM и VRAM при одинаковом n_ctx и числе GPU layers. Если используется свежая сборка llama.cpp, проверьте загрузку дополнительных тензоров: автоматическая обработка MTP может менять бюджет видеопамяти независимо от основного GGUF. Практические детали описаны в разборе автоматической загрузки MTP-тензоров в llama.cpp.
Скорость и стабильность запуска
Измеряйте отдельно обработку промпта и генерацию токенов. Зафиксируйте версию llama.cpp или другого backend, драйвер GPU, число потоков CPU, GPU layers, batch size, context length и параметры генерации. Разная версия движка легко перекрывает эффект от различий между двумя GGUF.
Проверьте старт модели, загрузку каждого слоя, ошибки несовместимости, скорость первого токена и стабильность на нескольких последовательных запусках. Обновление backend тоже может дать заметный эффект, пример изменений в локальном инференсе разобран в материале про Koboldcpp v1.119.
Стоит ли обновляться на новый GGUF Ornith 1.5 35B
Решение зависит от того, насколько важна воспроизводимость и есть ли подтверждение происхождения нового файла. Пока нет первичных данных по Ornith 1.5 35B A3B, корректная рекомендация условная: скачивать и сравнивать можно, заменять рабочую копию без резерва не стоит.
Когда обновление имеет практический смысл
- Опубликованы commit, дата, размер и SHA-256 нового Q4_K_M.
- История сборки прямо сообщает об изменении tensor data, исходного checkpoint, калибровки или исправлении совместимости.
- Новый файл проходит проверку хэша и успешно загружается в вашем backend.
- Smoke test на фиксированных промптах не показывает регрессий в критичных задачах.
- Есть место для параллельного хранения двух версий до завершения сравнения.
Когда лучше оставить текущую версию
- Известны лишь отличающиеся пути или поля метаданных.
- Нет checksum, commit и пояснения автора сборки.
- Текущий GGUF стабильно работает, а повторная проверка невозможна.
- Локальная конфигурация чувствительна к лимиту RAM, VRAM или времени простоя.
- Модель используется в задаче, где важна повторяемость ответов.
Чек-лист перед удалением старого файла
- Запишите SHA-256, размер и полное имя старого GGUF.
- Сохраните команду запуска, версию backend, драйверы, system prompt и chat template.
- Зафиксируйте
n_ctx, GPU layers, batch size, temperature, seed и другие параметры генерации. - Сохраните несколько базовых промптов и результаты, важные для вашей задачи.
- Загрузите новый файл отдельно и проверьте его хэш.
- Удаляйте старую копию только после успешного сравнения и наличия резервной версии.
Что можно считать доказанным, а что требует дополнительных данных
В предоставленном Research Pack нет релевантных фактов о репозитории Ornith 1.5 35B A3B, старом или новом Q4_K_M, их размере, метаданных и весах. Любые конкретные числа, заявления о новом calibration checkpoint и выводы об улучшении модели потребуют первичных материалов.
| Утверждение | Статус без первичных данных | Что нужно для проверки |
|---|---|---|
| Файл был заменен | Не подтверждено | История commit и дата изменения |
| У Q4_K_M изменился размер | Не подтверждено | Точные размеры двух файлов |
| Изменились version, finetune или пути | Не подтверждено | Два дампа метаданных |
| Изменились веса модели | Не подтверждено | Описание checkpoint или сравнение tensor data |
| Сменился калибровочный checkpoint | Не подтверждено | Лог квантизации или метаданные сборки |
| Новая версия лучше по качеству или скорости | Не подтверждено | Воспроизводимый сравнительный тест |
Минимальный набор источников для окончательного вывода
Для фактического разбора нужны адрес официального репозитория, ссылки на старую и новую публикацию Q4_K_M, история commit, SHA-256, точные размеры, дампы GGUF-метаданных, сведения о checkpoint и calibration/imatrix, а также протокол сравнения. Для тестов понадобятся команда запуска, версия backend, параметры контекста, настройки генерации, данные по RAM и VRAM, логи ошибок и результаты на одинаковых промптах.
Такой набор позволяет отделить тихую замену упаковки от нового кванта и обновленных весов. Без него статья может дать метод проверки, но не вердикт о конкретной версии Ornith.
Итог для владельца локальной установки
Сначала сравните SHA-256, размер и метаданные. Затем сохраните старый GGUF и настройки запуска. После этого проверьте новый файл на одинаковых условиях, включая качество ответов, скорость, RAM, VRAM и стабильность. Называть новый Ornith 1.5 35B Q4_K_M лучшей версией можно только после подтверждения commit, содержимого файла и результатов сравнения.