Оптимізація інференсу LLM: llama.cpp, квантизація GGUF, гібрид

llama.cpp: де вузьке місце під час локального інференсу

Під час локального запуску моделі на власних серверах вузьке місце майже ніколи не там, де його шукають. llama.cpp розділяє інференс LLM на дві різні за профілем фази: обробку промпта й генерацію токенів.

Перша впирається у обчислення й добре розпаралелюється, друга — у пропускну здатність пам’яті й від кількості ядер майже не виграє. Звідси знайома картина: короткий запит відповідає швидко, а зі зростанням діалогу затримка відповіді зростає нелінійно.

Друге джерело втрат — формат ваг і вивантаження шарів. Квантизація GGUF економить пам’ять, але частина шарів залишається у високій точності й не вміщається на прискорювач: рушій починає перекладати їх між пам’яттю пристрою й основною на кожному токені. Модель формально запустилася, а кожен крок генерації чекає на передавання даних.

Третє — робота з контекстом. KV-кеш зростає разом із довжиною діалогу, і без обмеження вікна та повторного використання спільного префікса запити починають витісняти один одного.

За кількох паралельних користувачів це дає зростання затримки на тому самому обладнанні, а іноді й відмову через нестачу пам’яті замість плавної деградації.

Окремо варто згадати серверну обв’язку: синхронна видача токенів, відсутність безперервної пакетної обробки, зайва серіалізація. Обчислення йдуть швидко, але відповідь збирається по одному токену й чекає на звільнення потоку.

Розбираємо, де саме втрачається швидкість і пам’ять у конкретній конфігурації, і як це закривається — від вибору квантизації до режиму вивантаження шарів.

Що дає оптимізація: швидкість відповіді, пам’ять, відмови

Оптимізація llama.cpp корисна рівно настільки, наскільки її видно в замірах. До правок і після знімаємо чотири величини: час до першого фрагмента відповіді, швидкість генерації, пам’ять під вагами й частку запитів з помилкою на піку навантаження. Без цих чисел «стало швидше» — питання віри, а не інженерії.

Підбір квантизації GGUF змінює не лише вагу моделі, а й профіль навантаження на вузол. Звільнена пам’ять іде під кеш і паралельні сесії, тому пропускна здатність зростає на тому самому обладнанні, без докупівлі потужностей.

Що перевіряємо на виході:

• Час відповіді — перший фрагмент приходить раніше, хвіст затримок коротший.
• Пропускна здатність — один вузол тримає більше одночасних діалогів.
• Споживання пам’яті — запас під кеш замість упору в ліміт.
• Стійкість під навантаженням — зникає клас відмов через нестачу пам’яті.
• Передбачуваність — затримка не «пливе» зі зростанням кількості запитів.

Підсумок фіксуємо у звіті: що було, що змінили, який ефект отримали. Будь-яку цифру замовник може переперевірити своїми прогонами на тому самому наборі запитів.

Порівняння підходів: llama.cpp і альтернативні схеми

Вибір схеми запуску визначає не модель, а вимоги до контуру даних і профілю навантаження. Ті самі ваги можна підняти повністю на власному обладнанні через llama.cpp, віддати у зовнішній сервіс або зібрати гібрид — і кожен варіант по-своєму обмежує архітектуру.

Квантизація GGUF — окрема вісь вибору всередині локального й гібридного варіантів: формат визначає, скільки ваг вміщається в пам’ять і який рівень якості ми за це віддаємо.

Схему обирають за найжорсткішим обмеженням — зазвичай це контур даних або пікове навантаження, — а решту параметрів підганяють під нього.

Порядок робіт: від аудиту навантаження до передавання схем

Профіль навантаження в LLM-сервісу рідко збігається з тим, що закладено в конфігурації «за замовчуванням»: піки припадають на робочі вікна, уночі черга простоює, а довжина запитів різниться в рази.

Налаштування без знятого профілю дає або простоюючі потужності, або відмови й зростання затримки в годину пік. Тому роботи ведемо від вимірювань до схеми, а не навпаки.

1. Аудит навантаження та профіль запитів. Збираємо довжину промпта й відповіді, частку паралельних запитів, добові піки та повторювані системні префікси — це визначає, що взагалі має сенс оптимізувати.
2. Вибір конфігурації на реальному трафіку. Порівнюємо варіанти квантизації GGUF і глибину винесення шарів на прискорювач на ваших запитах, а не на синтетиці: де втрачається якість відповіді, а де зростає пропускна здатність.
3. Схема розгортання. Фіксуємо гібридну модель: постійний контур на власних потужностях, піковий — на орендованих, правила перемикання й точки відмови.
4. Налаштування та оптимізація. Вмикаємо безперервну пакетну обробку й повторне використання спільного префікса промпта — контур на llama.cpp перестає впиратися в пам’ять зі зростанням кількості одночасних діалогів.
5. Перевірка під навантаженням. Проганяємо піковий профіль, заміряємо час до першого токена, пропускну здатність і поведінку в разі відмови одного з вузлів.
6. Передавання рішення. Віддаємо конфігурації, схему, політики масштабування, регламент оновлення моделей і навчання вашої команди.

Що передаємо: конфігурації, схеми, регламенти оновлення

Комплект на виході — не набір файлів для галочки, а робоча система, яку команда замовника розгортає й розвиває без нас. За кожним артефактом видно, які параметри виставлено, чому саме так і що змінювати зі зростанням навантаження.

• Конфігурації llama.cpp: розмір вікна контексту, частка шарів на прискорювачі, розмір пакета запитів, ліміт одночасних звернень — з поясненням, як кожен параметр впливає на затримку й споживання пам’яті.
• Схема рішення: де зберігаються ваги в GGUF, який варіант квантизації обрано для кожної моделі й з якої причини, як запит проходить від застосунку до інференсу й де вузькі місця.
• Правила розмежування доступу: ролі для панелі та програмного інтерфейсу, ізоляція ключів, ліміти на користувача, порядок видавання й відкликання.
• Документація: призначення моделі та її обмеження, вимоги до обладнання, типові збої запуску й порядок дій, інструкція з локального стенда.
• Регламент оновлення: як приймається нова версія моделі або ваг, обов’язкова перевірка на наборі контрольних запитів, повернення до попереднього набору в разі регресії.
• Скрипти розгортання та швидких перевірок: підйом з нуля й контроль працездатності, щоб оновлення не залишалося ручною операцією з простоєм сервісу.

Приклад упровадження: менше вузлів, стабільний час відповіді

Замовник — асистент із корпоративної бази знань.

Потік запитів зростав, а разом із ним і парк вузлів: кожна репліка тримала повну модель у пам’яті, тому на піках середній час відповіді тримався в нормі, а хвіст розподілу йшов угору — частина користувачів чекала на відповідь у рази довше. Запас тримали заздалегідь, але черги на довгих контекстах усе одно з’являлися.

Ми зняли профіль за етапами: підготовка входу, генерація, очікування в черзі. Виявилося, час втрачається не на самій генерації, а на очікуванні пам’яті та на повторній обробці спільних префіксів.

Інференс перевели на llama.cpp: ваги в зниженій розрядності формату GGUF, гібридний розрахунок — частина шарів на прискорювачі, частина на процесорі, повторне використання кешу станів і безперервна пакетна обробка замість фіксованих пакетів.

Метрики до та після

• кількість вузлів: було сім, стало два — п’ять машин звільнилися під інші задачі;
• час відповіді на піку: було 4,2 с за 95-м процентилем, стало 1,8 с;
• поведінка під навантаженням: черга перестала зростати, розкид часу відповіді — десяті частки секунди;
• якість відповідей: порівняли на відкладеній вибірці запитів, розбіжностей із вихідною моделлю не побачили.

Ключове тут — оборотність. Вихідні ваги й конфігурації збережено окремо, схема запуску та параметри описані в документації, тому повернення до попереднього режиму — це один прогін розгортання.

Чим гібридна схема відрізняється від локального запуску

Локальний запуск означає, що генерація цілком іде на вашому обладнанні: запит не покидає контур, але стеля якості впирається в те, що вміщається на наявних машинах.

Гібридна схема локальний контур не скасовує — вона ставить перед ним маршрутизатор: частина запитів залишається всередині, частина йде зовнішньому сервісу. Різниця не в «краще чи гірше», а в тому, який клас задач ви закриваєте власними ресурсами усвідомлено.

Маршрутизація будується на явних правилах, а не на здогадках моделі. Критерії зазвичай такі: чутливість даних, довжина контексту, потрібна якість відповіді та тип операції — коротка класифікація, вилучення полів із документа або довге міркування.

Правила описані конфігурацією й пишуться в журнал, тому завжди видно, чому конкретний запит пішов назовні і що потрібно змінити, щоб повернути його всередину.

Приватність даних тримається на тому, що назовні нічого відправляти. Персональні дані, договори й внутрішнє листування обробляються квантованою моделлю у форматі GGUF усередині вашої мережі, а зовнішній сервіс отримує лише знеособлені фрагменти або не отримує нічого.

Це перевіряється окремо: набір контрольних запитів проганяється через маршрутизатор, і за журналом видно, що жоден із них не вийшов за периметр.

Передбачуваність затримок — друга причина розділяти потоки.

Локальний контур на llama.cpp дає рівний час до першого токена й не залежить від чужого навантаження та мережевих сплесків, тому інтерактивні сценарії — підказки в інтерфейсі, пошук по базі знань — працюють однаково й на піку. Зовнішній сервіс бере на себе рідкісні важкі задачі, де важливіша якість відповіді, ніж секунди.

На практиці гібрид обирають, коли дані різнорідні: типові звернення обслуговує власний контур, складні та нечутливі — зовнішній. Пропорція задається правилами й змінюється без перезбирання застосунку, а ресурси витрачаються за реальним обсягом, а не за піковим навантаженням.

Часті технічні питання щодо оптимізації інференсу

Сумніви перед запуском зазвичай ті самі: чи просяде якість після стиснення, чи влізе модель у наявне обладнання, як оновлювати її без зупинки сервісу. Нижче — короткі відповіді, які ми даємо до початку робіт, щоб рішення ухвалювалося на цифрах, а не на вірі.

Чи вистачить наявного обладнання?

Вважаємо бюджет ресурсів: ваги, кеш контексту й одночасні запити. Якщо запас не сходиться, є два важелі — сильніше стиснення або гібридний режим, коли частину роботи забирає прискорювач, а частину — процесор. У більшості випадків цього достатньо, щоб не змінювати парк обладнання.

Як оновити модель без зупинки сервісу?

Нова версія піднімається поруч зі старою, проходить прогрів і перевірку на тіньовому потоці, і лише потім на неї переводиться трафік. Попередня залишається доступною для відкату. Перемикання займає секунди, застосунок розриву не помічає.

Наскільки архітектура рішення прив’язана до конкретної моделі?

Шар інференсу на llama.cpp закрито внутрішнім інтерфейсом: застосунок, черги й логіка обробки не знають, яка модель відповідає. Тому зміна моделі — правка конфігурації, а не переписування сервісу. Туди ж виносимо заміри затримок, щоб деградацію було видно до скарг користувачів.

Обговоримо задачу: що надіслати для попередньої оцінки

Щоб оцінка робіт була предметною, а не «плюс-мінус порядок», потрібні ввідні щодо вашого навантаження й обладнання. Чим точніше опишете поточний контур інференсу, тим конкретніше повернемося з планом упровадження та порядком старту.

• Цільова модель: архітектура, кількість параметрів, ліцензія — і чи є плани її змінювати або дообучати.
• Профіль навантаження: скільки одночасних користувачів, середня та гранична довжина контексту, частка довгих відповідей.
• Клас обладнання: одна машина чи пул, чи є прискорювачі й якої пам’яті вистачає під модель цілком.
• Поточний контур: як інференс запущено зараз — llama.cpp, серверний рантайм, який квант GGUF — і що саме не влаштовує: швидкість, якість, поведінка під навантаженням.
• Вимоги до якості: набір реальних запитів для порівняння та межа, за якою деградація після квантизації вже неприпустима.
• Обмеження щодо даних: чи можна виносити запити за периметр, де зберігаються логи, чи потрібна ізоляція за клієнтами.
• Вікно змін: коли допустиме перемикання трафіку, чи потрібен паралельний контур і відкат на поточну конфігурацію.

Опишіть задачу у вільній формі — цього достатньо для першого кроку. Обговоримо ввідні, повернемося з оцінкою робіт, етапами та планом упровадження, а те, чого бракує, уточнимо вже в розмові.