Старого 10-річного Xeon цілком достатньо

Техніка, якій це не мало б під силу

Третій допис Крістіни Еміліє Соренсен про MTP-драфтери Gemma 4 ставить питання, як запустити результат на переробленому сервері, який не повинен цього вміти. Машина має 128 GB оперативної пам'яті, але це DDR3 — у п'ять-шість разів повільніша за найкращу сучасну пам'ять ноутбука. Процесор — один Intel Xeon E5-2620 v4 2016 року: 8 фізичних ядер, 16 потоків, лише AVX2 — без AVX-512 і BF16 — 20 MiB L3 та 2 MiB L2, і жодного GPU. ollama і навіть стандартний llama.cpp не дають достатньо «важелів», тож відповідь — форк ik_llama.cpp і командний рядок із 25 прапорців. На CPU генерація обмежена пропускною здатністю пам'яті: процесор завершує матричні обчислення й чекає, поки ваги перемістяться з RAM у кеш.

Спекулятивне декодування та маршрутизація MoE на CPU

Gemma 4 26B-A4B — модель суміші експертів: 128 експертів, 8 активних на токен, тобто близько 3,8 млрд активних параметрів із приблизно 25,2 млрд загальних. Прапорці --spec-type mtp, --draft-max 3, --draft-p-min 0.0 і --spec-autotune з'єднують 26-мільярдний верифікатор із малим MTP-драфтером, беручи до трьох токенів на чернетку. На думку Соренсен, спекулятивне декодування дає більше на CPU, ніж на GPU: цикли CPU дешеві порівняно з проштовхуванням ваг верифікатора через кеш, а робочий набір драфтера вміщається в L3. --cpu-moe узгоджує маршрутизацію експертів з ієрархією кешів CPU, щоб стрибки між 128 експертами не «били» кеш, а --merge-up-gate-experts зливає дві проєкції в один matmul — у логах fused_up_gate = 1. Кількість потоків, -t 8, відповідає фізичним ядрам, а не 16 потокам SMT: на навантаженні, обмеженому пам'яттю, зайві потоки додають лише витрати на планування.

Закріплення, перепакування і прапорці, що тихо не спрацьовують

--mlock просить ядро тримати ~27 GB ваг у фізичній пам'яті, і за замовчуванням запит не проходить: «failed to mlock 27628376064-byte buffer ... Try increasing RLIMIT_MEMLOCK». Прапорець правильний, а ліміт memlock — ні, і чорноскринькові інструменти цієї оптимізації просто не просять, залишаючи модель витіснятися на диск. --run-time-repack перевпорядковує матриці ваг перед інференсом під розкладку кешу CPU (логи: 265 перепакованих тензорів), а --no-kv-offload обриває пошук GPU для KV-кешу. Прапорець розбиття графа не витримує зустрічі з MTP: рушій повідомляє «Split mode 'graph' is not supported for Gemma4 external MTP => changing split mode to 'layer'» і переходить на послідовне розбиття за шарами.

Flash Attention на CPU і рахунок пам'яті

Автор ik_llama.cpp під псевдонімом ikawrakow написав для Flash Attention власні ядра під CPU: вона зливає softmax уваги з matmul, тож матриця N×N ніколи не записується в RAM — оптимізація, створена спершу для GPU. --mla-use 3 вмикає Multi-Head Latent Attention, яка стискає KV-кеш у компактніше латентне подання. Спрацювало й те, й те: flash_attn = 1, fused_moe = 1, fused_up_gate = 1. Підсумок — 82 355 MiB: приблизно 25 GB ваг і 56 GB KV-кешу на повному контексті 262K, тобто кеш більший за саму модель. Висновок Соренсен: перешкода для локальних відкритих моделей не в кремнії — потрібно глибоко розуміти рушій інференсу.