llama.cpp убрала лишние 216 МиБ у Gemma — в определённом режиме загрузки
В b12008 изменили порядок создания общей таблицы весов. Экономия показана для Gemma 4 на CPU без mmap; переносить её на все режимы нельзя.
В предварительной сборке llama.cpp b12008 от 30 октября исправили лишнюю копию таблицы весов при некоторых вариантах загрузки Gemma. В примере разработчика буфер модели на CPU уменьшился с 3163,73 до 2947,73 МиБ — на 216 МиБ. Для локального запуска это полезная экономия, но она зависит от настроек.
Одна таблица вместо двух
У затронутых архитектур вход и выход могут использовать общую таблицу token_embd. Раньше загрузчик создавал выход раньше самой таблицы, не находил готовый объект для повторного использования и выделял второй. Исправление меняет порядок создания: таблица появляется первой, и её можно разделить между входом и выходом.
Представьте два указателя на один справочник: если справочника ещё нет, программа заводит две копии. Здесь исправили именно этот порядок, а не уменьшили точность весов или размер самой модели.
Кому достанется экономия
В описании исправления приведён запуск gemma-4-E2B-it в формате Q4_K_M: только CPU, без mmap. Исправление касается gemma3n и gemma4, когда вход и выход используют один тип буфера. При обычном mmap обе таблицы и раньше указывали на одни отображённые страницы. Если выход находится на GPU, отдельная копия сохраняется.
Число 216 МиБ — результат конкретной конфигурации из PR, а не обещание для любой Gemma. Независимого измерения здесь нет; ускорение генерации не заявлено. Сначала сопоставьте режим загрузки и размещение слоёв, затем сравните строки размера буфера в журнале своей сборки. Обновление ради этой экономии имеет смысл именно при совпадении условий.
Комментарии
Войдите, чтобы оставить комментарий
Пока нет комментариев. Начните обсуждение.