Формат GGUF, используемый проектом llama.cpp, объединяет весовые модели в один файл, что гораздо удобнее разбросанных по папкам JSON в репозиториях Hugging Face. Однако формат ещё не идеал, и в нём есть важные пробелы. Сначала разберём шаблоны чата. Модели обучаются на последовательностях, имитирующих диалоги, где каждый поворот разговора имеет строгий формат. Например, шаблон Gemma 4 использует специфические теги, в то время как LFM2 применяет свои собственные. Всё это обрабатывается скриптами на языке Jinja2, которые хранятся в метаданных файла под ключом tokenizer.chat_template. Некоторые модели поставляются с несколькими шаблонами: с поддержкой инструментов и без. Скрипты Jinja2 включают циклы, условные операторы и переменные, поэтому любой прикладной системе с LLM нужен интерпретатор для их выполнения. Команды от Hugging Face, llama-server и NobodyWho используют разные реализации этого языка, но скорость генерации пока не является критическим фактором, поэтому споры о том, какую использовать версию, пока бессмысленны.
Второй важный аспект — специальные токены. Языковые модели генерируют текст бесконечно, пока не встретят токен завершения последовательности. Такие токенны, как , или <|tool_call|>, имеют семантическое значение, отличное от букв, и обычно не отображаются пользователю. Таблица метаданных перечисляет их ID и назначение, например, токены для начала и конца инструментального вызова.
Третий компонент — конфигурация выборки. Модели выдают вероятностное распределение токенов, и выбор конкретного слова называется выборкой. Лаборатории часто предоставляют рекомендуемые настройки выборки, которые пользователь может скопировать из файла. Номера NobodyWho позволили упаковать эти настройки прямо в файл модели. Теперь пользователи не обязаны вручную загружать конфигурацию. Стандарт GGUF теперь включает поле general.sampling.sequence, позволяющее задавать порядок шагов выборки, хотя многие модели всё ещё полагаются на дефолтный порядок по умолчанию.
Важным упущением формата стала поддержка форматов вызова инструментов. Разные модели используют разные форматы данных для инструментов, и каждый движок вывода вынужден писать свой парсер. Идеальный вариант — наличие грамматики в файле модели, из которой можно автоматически сгенерировать парсер. Это решит проблему совместимости, особенно для маленьких моделей, которые часто ошибаются с типами данных. Кроме того, в стандарт пока не включено поле think_token, используемое для разделения блока размышлений модели от основного текста. Без этого поля движки не могут корректно обрабатывать внутренние мысли модели.
Ещё одна проблема — проекционные модели. Для работы с изображениями и аудио модели требуют отдельный небольшой модуль — проекционную модель. Сейчас нужно загружать два файла: основной и проекционный. Это нарушает принцип «одного файла». Было бы отлично, если бы в один файл можно было упаковать веса проекции, предлагая два варианта файла: с модулем обработки мультимедиа и без него.
Наконец, в метаданных нет списка поддерживаемых функций. Пользователю сложно понять, умеет ли модель обрабатывать картинки или инструменты без специальных метки. Сейчас приходится анализировать шаблоны чата на наличие ключевых слов или проверять наличие проекционного файла. Это грязный трюк. Было бы идеально добавить флаги функций в файлы моделей, чтобы библиотеки вывода могли выдавать точные ошибки, когда пользователь пытается вызвать инструмент на модели, которая это не поддерживает. Формат GGUF удобен, но ему нужно стать зрелее.