Кешування інференсу LLM: де втрачається швидкість
Кожен новий запит модель обробляє з нуля: заново рахує увагу по всьому контексту, хоча 80–90 % промпту не змінювалися з попереднього виклику.
На довгих системних інструкціях і історії діалогу частка повторного обчислення сягає дев'яноста відсотків — і платиться за неї часом до першого токена, а не логікою продукту.
Поки одночасних сесій мало, це непомітно. Коли їх стає десятки, закінчується пам'ять під KV-стан, сервер починає вишиковувати чергу й різати розмір пакета.
Висока затримка відповіді моделі виглядає як «модель гальмує», хоча вузьке місце під час генерації — повторний префіл і переповнений кеш.
Пропускна здатність падає швидше, ніж зростає кількість запитів, а деградація при зростанні запитів перетворюється на таймаути на шлюзі, обриви потоку й повторні спроби клієнта, які знову навантажують той самий інференс-сервер.
Додати прискорювачів — найдорожче й найслабше рішення: лінійного зростання пропускної здатності не буде, поки кожен запит перераховує те саме.
Розбираємо, як це закривається: кешування інференсу LLM спирається на два механізми — повторне використання вже порахованого префікса (як у vLLM) і кеш на рівні сенсу запиту.
Що дає повторне використання відповідей і контексту
У діалоговому сервісі запити майже не бувають незалежними: системна інструкція, опис предметної області та попередні репліки повторюються в кожному зверненні.
Без повторного використання контексту обчислювач заново рахує той самий префікс, і саме на ньому минає основна частина часу до першої відповіді. Кеш уваги прибирає цю роботу: пораховані вектори залишаються в пам'яті й підставляються в наступні запити тієї самої сесії.
У сервісних рушіях актуальної гілки, наприклад у vLLM, кеш ведеться блоками, а спільні префікси перевикористовуються між сесіями — зростання кількості одночасних діалогів перестає лінійно з'їдати пам'ять обчислювача.
Час до першої відповіді на довгому системному префіксі скорочується у 2–4 рази, повний час видачі падає пропорційно частці перевикористаного контексту.
Семантичний кеш працює рівнем вище: питання на кшталт «як оформити повернення» надходять десятками формулювань, векторний пошук знаходить близький за змістом запит і віддає готову відповідь без запуску генерації. Такі звернення обслуговуються за час, непомітний для користувача.
Обидва механізми додаються до пропускної здатності сервісу: за частки влучань 30–50 % на типовому потоці навантаження на обчислювачі знижується майже пропорційно, пік проходить на тому самому парку, а хвіст затримок перестає розповзатися.
Режими кешування: точний, семантичний, контекстний
Три режими кешування вирішують різні задачі, і плутати їх — часта причина розчарування.
Точний кеш відповідей ловить повтор запиту символ у символ, семантичний — перефразування на кшталт «як оформити повернення» і «повернення товару як зробити», а контекстний тримає кеш станів уваги, щоб не перераховувати спільний префікс промпту на кожному виклику.
Вибір диктує профіль запитів: частка повторів, довжина спільної частини промпту й ціна помилки на хибному влучанні. Для семантичного критичний поріг схожості запитів — занижений дає впевнену відповідь не на те питання, завищений перетворює кеш на декорацію. Поріг підбираємо на реальному лозі звернень, окремо розбираючи хибні влучання.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Точний кеш відповідей | Шаблонні звернення, повторювані запити, фіксовані форми | Не ловить перефразування, марний на живій мові |
| Семантичний кеш | Підтримка, асистенти, де одну думку пишуть десятком формулювань | Потребує налаштування порога схожості й регулярного розбору хибних спрацювань |
| Кеш станів уваги | Довгий незмінний префікс: інструкції, база знань, документи | Працює лише на спільній частині контексту, скидається при зміні моделі або порядку блоків |
На практиці режими ставлять шарами: точний — першим, семантичний — за ним, кеш станів уваги — на рівні самого інференсу. Так перефразування не промахується повз дешевий шар, а оновлення моделі зачіпає нижній рівень і не ламає верхні.
Як ми впроваджуємо: аудит, схема, замір, передача
Роботи йдуть етапами, і перший з них — не налаштування, а вимірювання. Впровадження кешування без базових замірів перетворюється на суперечку про смаки: незрозуміло, що дало приріст і що зламається при наступному оновленні моделі.
Тому спочатку фіксуємо поточний стан, потім міняємо конфігурацію — і повторюємо заміри на тому самому навантаженні.
- Аудит навантаження. Розбираємо реальний трафік: частка дослівно повторюваних і перефразованих запитів, розподіл довжин контексту, частка системних підказок.
- Схема проходження запиту. Малюємо шлях від клієнта до моделі й назад, позначаємо, де стає перевірка кешу і що відбувається при промаху.
- Налаштування KV-кешу. Підбираємо обсяг буфера, політику витіснення й розділення за сесіями, щоб пам'ять не зростала з кожним діалогом.
- Семантичний кеш. Задаємо поріг схожості, правила нормалізації запиту й ізоляцію за орендарями — відповідь одного користувача не повинна піти іншому.
- Замір метрик. Порівнюємо стан до і після на зіставній вибірці: час до першого токена, повний час відповіді, частка влучань, завантаження прискорювачів.
- Перевірка на граничних режимах. Холодний старт, сплеск трафіку, недоступність сховища кешу, зміна моделі — система має деградувати, а не падати.
- Передача в експлуатацію. Регламент обслуговування, панель моніторингу з ключовими метриками, план відкату й навчання вашої команди.
Що залишається у вас: конфігурації, схеми, регламенти
Проєкт закінчується не демонстрацією, а передачею: у вашої команди мають залишитися артефакти, за якими систему можна розвивати й супроводжувати без нас. Ось що входить у комплект із кешування інференсу.
- Конфігурації кешу — розміри сховищ, пороги схожості запитів, час життя записів і правила витіснення, з поясненням щодо кожного обраного значення.
- Схема проходження запиту — де він потрапляє в кеш і де промахується, які заміри знімаються на кожній ділянці шляху.
- Регламент інвалідації — що скидається при оновленні моделі, зміні системної вказівки або правці довідкових даних, хто це ініціює і як перевіряється результат.
- Політики доступу — розмежування за ключами й споживачами, щоб закешована відповідь не пішла чужому, плюс правила зберігання чутливих даних і логування звернень.
- Метрики й оповіщення — частка влучань, час відповіді, класи помилок; з описом, як відрізнити зростання навантаження від деградації кешу.
- Документація щодо кешу — архітектура, допустимі діапазони параметрів, порядок розгортання й відкат на попередню конфігурацію.
Усе передаємо файлами конфігурацій і описами, без прив'язки до нашої інфраструктури. Розбір із вашими інженерами й сценарії перевірки на реальних запитах — частина здачі, щоб супровід перейшов на ваш бік без втрати знань про те, як влаштоване кешування.
Кейс: час відгуку й частка влучань до і після
Задача надійшла від сервісу підтримки: асистент відповідає за базою знань, за добу проходить близько 12 тисяч діалогів, більш ніж половина — у двох пікових вікнах.
До кешування інференс перераховував контекст цілком на кожен запит — системна інструкція, історія й знайдені фрагменти документації йшли в модель заново, навіть коли питання повторювалося дослівно.
Заміри до впровадження: медіана відгуку трималася на 7 секундах, у пік сягала 14, частка влучань у кеш була нульовою. Головний клас відмов — обрив за таймаутом: черга запитів зростала, і частина звернень закінчувалася помилкою замість відповіді.
Що змінювали
Розділили незмінний префікс підказки й змінну частину: блоки уваги для спільної інструкції більше не рахуються заново, кеш ключ-значення перевикористовується між діалогами.
Поверх поставили семантичний кеш — питання приводиться до вектора, і при збігу вище порога 0,92 готова відповідь віддається без звернення до моделі.
Записи розбиті за правами доступу, строк життя прив'язаний до версії бази знань, тому при оновленні документації пов'язані відповіді інвалідуються автоматично.
Метрики після впровадження: медіана відгуку — 1,8 секунди, на повторних питаннях — 0,6; частка влучань у кеш — 47 % у середньому і 63 % у пікові вікна.
Таймаути як клас відмов пішли, навантаження на інференс упало приблизно вчетверо, а вивільнений запас пішов на зростання кількості одночасних діалогів.
Заміри до і після знімали на одному наборі сценаріїв, тому цифри зіставні. Кейс за згодою замовника ми розбирали на профільній конференції — Інференс LLM у продакшені.
Чим повторне використання контексту відрізняється від повтору відповідей?
Різниця — у рівні, на якому економиться робота. Повторне використання контексту живе всередині одного звернення: модель не перераховує стани уваги для вже прочитаної частини запиту, а продовжує зі збереженої позиції.
Це прискорює видачу першого токена на довгих системних інструкціях і в діалозі, але саме звернення до моделі все одно відбувається.
Повторне використання відповідей працює вище — на рівні звернення цілком. Якщо близький запит уже оброблявся, система віддає готовий результат, і модель не запускається взагалі.
Звідси два різні механізми: точний кеш звіряє нормалізований текст запиту, семантичний — порівнює сенс і допускає перефразування.
| Механізм | Що економить | Коли підходить | Обмеження |
|---|---|---|---|
| Повторне використання контексту | Перерахунок префікса, час до першого токена | Довгі інструкції, діалог, незмінний системний блок | Кількість звернень до моделі не скорочує |
| Точний кеш | Звернення цілком при збігу запиту | Повторювані типові запити з детермінованою відповіддю | Будь-яка відмінність у тексті дає промах |
| Семантичний кеш | Звернення при близькому за змістом запиті | Часті питання, підтримка, вузький набір тем | Хибне влучання: потрібен поріг близькості й контроль |
Вибір механізму — не «або-або». Повторне використання контексту вмикають завжди: воно не змінює відповідь і знижує навантаження на довгих входах.
Семантичний кеш ставлять там, де потік запитів помітно повторюється, і обов'язково з порогом близькості, журналом влучань і винятками для персональних даних і транзакційних питань.
Слабо підібраний поріг дає найгірший клас відмови: система впевнено віддає схожу, але неправильну відповідь. Тому частку влучань і точність звіряють на наборі еталонних пар «запит — очікувана відповідь», а спірні теми позначають як такі, що не підлягають кешуванню.
Обмеження й типові помилки при налаштуванні
Кеш прискорює відповіді, але вносить клас помилок, якого без нього не було: користувач отримує впевнено сформульовану, але застарілу відповідь.
KV-кеш тримається за конкретний префікс промпту й розсипається при зміні системної інструкції, а семантичний кеш шукає за змістом і тому схильний до хибних збігів. Розбираємо сумніви, які спливають на прийманні.
Більшість збоїв живе не в самому кеші, а в правилах влучання й строці життя запису. Ключ із сирого тексту запиту дає нульові влучання при перестановці слів, а ключ без прив'язки до версії джерела тиражує застаріле. Перевіряємо обидві межі до вмикання в бій.
Як кеш перестає віддавати застарілі відповіді?
Ключ запису прив'язується до версії джерела: хеш документа, тег індексу, час переіндексації. Після оновлення бази знань записи з попередньою міткою у видачі не беруть участі — їх знімає або явна інвалідація за подією, або строк життя.
Де межа хибних збігів у семантичному пошуку?
Поріг близькості підбираємо за розміткою: пари «запит — очікуване влучання» і пари сусідніх, але різних за змістом питань. Занижений поріг змішує запити про різні сутності, завищений — обнуляє влучання. Запити з числом, датою або іменем позначаємо як непридатні для кешу.
Що точно не варто кешувати?
Персоналізовані відповіді, запити з перевіркою прав доступу й разові операції. Частку влучань рахуємо за журналом: якщо сценарій повторюється рідко, запис витрачає пам'ять і додає затримку без виграшу.
Обговоримо задачу: що потрібно від вас для старту
Щоб обговорити задачу предметно, а не «за відчуттями», нам вистачає мінімального вхідного набору даних. Замовити налаштування кешування має сенс тоді, коли зрозумілі профіль трафіку й цільові метрики — саме це й розбираємо на першій розмові.
- яка модель використовується і як запущена: власний контур, хмарний провайдер або змішана схема, чи є обмеження на вихідні запити;
- профіль трафіку: частка повторюваних запитів, типова довжина контексту, розподіл за сесіями й користувачами;
- поточні метрики: час до першого токена, повна затримка відповіді, завантаження прискорювачів у години пік;
- вимоги до приватності: чи можна зберігати тексти запитів і відповідей, де саме і на який строк;
- цільові показники: у скільки разів потрібно скоротити затримку і яку частку влучань у кеш вважаєте робочою;
- вікно на зміни: чи є тестовий контур, чи допустима коротка просадка на робочому контурі при викатці, як влаштований відкат;
- відповідальні й доступи: хто з боку замовника підтверджує правки конфігурації й запуск у продакшн.
У відповідь надсилаємо оцінку й план робіт: інвентаризацію поточного інференсу, схему KV-cache і семантичного шару з політикою інвалідації, порядок викатки й набір замірів, за якими перевірятимемо ефект. Погоджуємо етапи — і старт проєкту займає дні, а не тижні.
