Что происходит: приложение сохраняет модели не как GGUF
Пользователь macOS menu bar приложения для llama.cpp, которое распространяется как llama.app, описал два связанных наблюдения. Первое: скачивание модели через UI заканчивается не появлением файла с расширением .gguf, а хешированием в стиле Ollama. Второе: если положить GGUF в папку моделей вручную, ни menu bar UI, ни веб-интерфейс его не распознают (обсуждение в r/LocalLLaMA).
Короткий ответ на главный вопрос: интерфейс показывает то, что приложение само занесло в свой внутренний каталог. Файловая система для него вторична, поэтому копирование файла в папку моделей ничего не меняет.
Дальше важная оговорка. Это единичный опыт одного пользователя, а не официальная документация llama.cpp или llama.app. В исходном сообщении нет ни версии приложения, ни списка скачанных моделей, ни точного расположения блобов. Все выводы ниже опираются на описанное поведение и общие свойства llama.cpp, а не на результаты замеров.
Почему ручной GGUF не появляется в списке моделей
Механика, которая лучше всего объясняет описанное поведение, выглядит так. При скачивании приложение считает хеш загруженных данных, раскладывает их по внутреннему хранилищу и создаёт запись в своём индексе или манифесте: имя модели, ссылки на фрагменты, возможно, метаданные кванта. Список моделей и в строке меню, и в веб-интерфейсе строится по этому индексу.
Ручное копирование GGUF в папку моделей не добавляет ничего в индекс. Получается ситуация, когда файл на диске есть, а записи о нём нет, и обе панели показывают прежний список. Ошибки в самом файле тут нет: тот же GGUF, переданный в llama.cpp напрямую, читается штатно.
Эту схему логично считать наиболее вероятным объяснением, а не подтверждённым фактом. Автор сообщения внутреннее устройство приложения не разбирал. Не исключены и другие причины, например сверка модели с контрольной суммой, которую ожидает увидеть приложение.
Как llama.app хранит модели: хешированные блобы в стиле Ollama
Ключ к описанному поведению во втором наблюдении пользователя:
When you use the UI to download a model, it seems to do an Ollama-esque hashing instead of just saving the GGUF (источник).
В Ollama модели действительно не лежат отдельными .gguf-файлами. Каждый слой сохраняется под именем из хеша (SHA256) в каталоге блобов, а манифест связывает набор слоёв с тегом модели. В стандартной установке это ~/.ollama/models с подпапками blobs и manifests. Переименование блоба в model.gguf ничего не даёт: манифест ссылается на конкретные хеши, и без пересчёта связей модель не соберётся.
По сообщению пользователя, llama.app повторяет этот принцип. Точное расположение скачанных блобов в исходном опыте не указано, формат не раскрыт. Конкретный путь приводить нельзя, его можно только искать самостоятельно: типичные места для macOS это ~/Library/Application Support или каталог, куда установлено приложение. Это догадка о распространённых местах хранения, а не подтверждённый адрес.
Чем это отличается от классического GGUF
Классический GGUF - один файл. Квантованная модель упакована в него целиком вместе с метаданными: архитектурой, числом слоёв, размером контекста, типом квантования. Такой файл можно скопировать на внешний диск, передать коллеге, положить в любую папку и указать путь в llama.cpp: ./llama-cli -m /path/model.gguf. Больше инструменту ничего знать не нужно.
Внутреннее хранилище llama.app устроено иначе. Фрагменты существуют для приложения и его индекса, а не как самостоятельные единицы. Хеш выступает именем файла, а человекочитаемое название модели живёт в манифесте. Отсюда следствие: разорвать связь между файлом и приложением простым копированием нельзя.
| Свойство | Классический GGUF | Хранилище llama.app по описанному опыту |
|---|---|---|
| Имя файла | Понятное, например qwen2.5-7b-q4_k_m.gguf | Хеш или набор фрагментов |
| Перенос на другой диск | Копированием одного файла | Без индекса приложения смысла не имеет |
| Использование в других инструментах | Путь через -m в llama.cpp | Не подтверждено |
| Удаление модели | Удалить файл | Нужно понимать, какие фрагменты относятся к модели |
| Проверка версии и кванта | Видно в имени и метаданных файла | Зависит от интерфейса приложения |
Какие неудобства это создаёт на практике
- Модель сложно передать другому человеку: копирование файла не работает, нужна повторная загрузка на его стороне.
- Освобождать место на диске неудобно: непонятно, какой объём занимает конкретная модель и какие фрагменты можно удалить безопасно.
- Ту же модель в другом приложении придётся скачивать заново, потому что готового GGUF на диске нет.
- Проверить, какой именно квант и какая ревизия модели лежат внутри, без интерфейса приложения трудно.
- Скрипты и автоматизация, которые привыкли работать с путём к .gguf-файлу, с таким хранилищем не стыкуются.
Это не приговор подходу. Хеширование даёт дедупликацию фрагментов и предсказуемость загрузок. Цена такой предсказуемости - потеря прямого контроля над файлами.
Можно ли подсунуть приложению свой GGUF
Честный ответ: в описанном опыте ручное добавление GGUF в папку моделей не сработало. Ни menu bar UI, ни веб-интерфейс модель не увидели, и подтверждённого способа обойти это штатными средствами в исходном сообщении нет. Придумывать рабочий рецепт без проверки не стоит: слишком легко выдать желаемое за действительное.
Отдельно стоит сказать, что вопрос «можно ли подсунуть приложению собственный GGUF» в источнике не поднимался. Автор сообщения такого эксперимента не описывал, результат неизвестен.
Что можно попробовать, но без гарантий
Если хочется проверить самостоятельно, разумно начать с наименее рискованных шагов:
- Перезапустить приложение и посмотреть, не появится ли модель в списке после повторного сканирования папки.
- Поискать в настройках пункт ручного добавления или импорта модели, а также упоминание папки моделей, которую приложение отслеживает.
- Проверить, не создаёт ли приложение рядом с блобами манифест или индекс, который можно дополнить.
- Уточнить путь к хранилищу в документации проекта или в его репозитории, если она там описана.
Правка внутренних файлов приложения может привести к нестабильной работе или потере скачанных моделей. Копию данных перед такими опытами делать обязательно. Ни один из перечисленных шагов в описанном случае не подтверждён как рабочий.
Альтернативы запуска llama.cpp на macOS
Ограничения хранилища llama.app не мешают пользоваться самой библиотекой llama.cpp. Она работает с обычными GGUF-файлами и не требует ни хеширования, ни манифестов. Официальное приложение с иконкой в строке меню и командой llama serve описано в разборе релиза llama.app, и его стоит воспринимать как один из вариантов запуска, а не единственный.
Запуск llama.cpp напрямую из терминала
Самый прямой обход внутреннего хранилища: собрать или скачать llama.cpp и запускать модель из командной строки.
./llama-cli -m ~/models/qwen2.5-7b-q4_k_m.gguf -p "Кратко объясни, что такое квантование"Путь указывает на ваш файл, и приложение про него знать ничего не должно. Для инференса на сервере подойдёт llama-server с OpenAI-совместимым API. На Apple Silicon важна сборка с поддержкой Metal, иначе вычисления пойдут на CPU и скорость упадёт. Как собрать llama-cli, как выбрать квант (Q4_0, Q4_K_M, Q5_K_M, Q8_0) под объём памяти и где CPU-инференс упирается в ограничения, подробно разобрано в материале про llama.cpp на обычном железе.
Плюс этого пути в полном контроле: файлы лежат там, где вы их положили, их можно копировать, версионировать и подключать к любому количеству инструментов. Минус в том, что интерфейса нет: управлять моделями придётся через терминал или свои скрипты.
Другие оболочки и инструменты
GUI-надстройки над llama.cpp существуют, и логику их работы полезно проверять до установки. Критерий простой: понимает ли инструмент прямой путь к .gguf-файлу и не требует ли обязательного импорта в собственное хранилище.
Показательный пример такого подхода - LLaMA.cpp Windows Manager, где профили запуска ссылаются на GGUF-файлы, а модели можно переключать из визуального интерфейса. Важная оговорка: это решение для Windows, на macOS оно не заменяет llama.app. Речь о принципе: визуальное управление и прямое хранение GGUF совместимы, если так задумано автором инструмента. Конкретные macOS-оболочки в исходном опыте не упоминались, поэтому называть работающие альтернативы по именам без проверки не стоит.
Ещё один способ не зависеть от чужой логики: держать модели в отдельной папке на внешнем SSD и подключать их к llama.cpp, а приложение использовать только как пульт для запуска сервера.
Стоит ли использовать llama.app, если вы привыкли к GGUF
Решение зависит от того, насколько для вас важен контроль над файлами.
Menu bar приложение подойдёт, если вы хотите минимум действий: скачал модель из встроенного списка, получил иконку в строке меню и работающий API без ручной настройки флагов. Тогда внутреннее хранилище и хеширование остаются деталью реализации, которая вас не касается.
Привычный к GGUF подход выигрывает, если модели нужно переносить между машинами, хранить на внешнем диске, подключать к нескольким инструментам сразу или отдавать коллегам. Здесь важны проверяемые имена файлов и путь, который вы задаёте сами. В описанном опыте llama.app такие сценарии не поддерживает: ручной GGUF в папке моделей остаётся невидимым для интерфейса.
Практичный компромисс выглядит так: скачивайте модели как обычные GGUF-файлы, храните их в отдельном каталоге со понятной структурой и указывайте путь через -m в llama.cpp, а menu bar приложение держите для быстрого доступа к серверу. Так вы не привязываетесь к внутреннему формату хранения и в любой момент можете сменить инструмент без повторной загрузки десятков гигабайт.