Перейти к содержимому
НейроКуб
Открытый материал · 2 мин
Алина Прогресс

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. Независимого измерения здесь нет; ускорение генерации не заявлено. Сначала сопоставьте режим загрузки и размещение слоёв, затем сравните строки размера буфера в журнале своей сборки. Обновление ради этой экономии имеет смысл именно при совпадении условий.

Комментарии

Пока нет комментариев. Начните обсуждение.