GGUF: что внутри, кроме весов, и чего там не хватает?
Разбираем GGUF на запчасти: от хедеров до токенизатора — и находим пару дыр, которые мешают жить.
Если вы хоть раз скачивали LLM и думали «ну ещё один формат, отлично», то GGUF вам знаком. Но что на самом деле прячется внутри этого файла, кроме весов? Оказывается, там целый зоопарк метаданных, от типов данных до информации о токенизаторе. Но, как в любом зоопарке, некоторые клетки пустуют.
GGUF — это эволюция GGML, созданная для удобной загрузки моделей без лишних плясок с бубном. Внутри: хедер, метаданные (ключ-значение) и тензоры. Метаданные могут включать всё от имени модели до деталей токенизации. Но вот незадача: стандарт ещё не описал кучу важных вещей — например, как хранить информацию о LoRA-адаптерах или как правильно указывать архитектуру для кастомных моделей. Разработчики выкручиваются кто во что горазд: кто-то пихает данные в JSON внутри метаданных, кто-то — в отдельные файлы. Ирония: формат, который должен упрощать жизнь, иногда превращает её в квест «угадай архитектуру».
Что реально не хватает? Во-первых, внятной спецификации для описания архитектур — сейчас это поле для творчества, граничащего с хаосом. Во-вторых, поддержки чекпоинтов для обучения (да, GGUF заточен под инференс, но кто запрещает мечтать?). И в-третьих, единого способа хранить препроцессоры — без этого каждый фреймворк делает свою магию, а пользователь страдает.
Комментарий студии METABYTE: GGUF — отличная идея, но, как и любой молодой стандарт, требует доработки напильником. В наших проектах мы предпочитаем оборачивать модели в универсальные контейнеры, чтобы не гадать на кофейной гуще, что за токенизатор использовался. А вы всё ещё храните веса в Safetensors?