В этом материале
Автоматический fit в llama.cpp способен менять незаданные параметры, чтобы уложить запуск в доступную device memory.
Автоматический fit в llama.cpp способен менять незаданные параметры, чтобы уложить запуск в доступную device memory. Поэтому одинаковая команда на двух узлах не обязательно означает одинаковый эффективный контекст или placement. Для воспроизводимого сервера сохраняйте результат подбора и явно задавайте параметры, являющиеся частью клиентского контракта. Сам факт успешной загрузки не доказывает, что runtime использует все ранее ожидавшиеся настройки и предоставляет прежнюю емкость запросов.
Какие значения допускают автоподбор
В исходном определении аргументов fit описан как корректировка unset arguments. Там же определены ограничения целевого резерва памяти и минимального контекста. Важно различать незаданное значение и явно выбранное оператором. Не предполагайте, что автоматическая настройка обязательно изменит любой указанный предел. Перед исследованием сохраните исходную команду и effective configuration, чтобы видеть, какие решения принял runtime, а какие пришли из вашего файла настроек или среды запуска процесса.
Почему два запуска различаются
Свободная память зависит от других процессов, контекста и размещения компонентов. Документация сервера объясняет fit и эффективные настройки моделей. На одном узле автоматический выбор может получить другую область допустимых решений, чем на другом. Это не обязательно ошибка и не означает изменение checkpoint. Однако клиентское обещание длины контекста нельзя строить только на названии модели. Проверяйте фактический предел после подбора, особенно когда экземпляры включаются в одну группу и должны обслуживать одинаковые запросы.
Пример карточки сравнения
Для двух тестовых узлов запишите доступную память перед стартом, unset параметры, итоговый context и placement. Это пример структуры наблюдения, а не обещание, что модель поместится на обоих устройствах. Отдельно отметьте значения, которые должны быть фиксированы для API. Если runtime выбрал разные ограничения, определите, допустима ли такая неоднородность. Не исправляйте расхождение только одинаковым model alias: переименование не меняет реальную емкость и не заставляет автоматический подбор принять одинаковое решение.
Как зафиксировать контракт
После исследования явно задайте необходимый context и другие проверенные параметры, либо документируйте, что fit допускает изменение конкретного свойства. Повторите запуск с тем же окружением и функциональный запрос у границы требуемой длины. При этом не подавайте реальный рабочий максимальный запрос без предварительной проверки ресурсов. Для приемки достаточно сохраненного синтетического fixture. Если явная конфигурация не помещается, это полезный отказ выбранного контракта, а не причина незаметно вернуть автосокращение и продолжать объявлять прежний предел доступным.
Сохраните наблюдаемые ограничения
Версионируйте сборку, настройки fit, model revision и журнал effective values. Не считайте fit-target дополнительной физической памятью: он задает условие подбора. При смене оборудования или shared workload повторите проверку. Полезный релизный артефакт показывает, какие свойства закреплены и какие остаются зависимыми от состояния узла. Это помогает отличить планируемый адаптивный запуск от случайного изменения API поведения. Автоподбор удобен для исследования доступного размещения, но предсказуемое обслуживание требует отдельно подтвердить результат, а не выводить его из отсутствия ошибки. Особенно важно сохранить такую запись при переносе бинарника и при смене сборки, потому что вместе с доступной памятью могут измениться сами правила выбора или поддерживаемые параметры runtime.
Связанные материалы
llama.cpp GPU layers: как проверить частичный перенос модели; Воспроизводимый стек инференса: как сохранить результат GPU-пилота.