У популярному інструменті llama-server виявлено серйозну проблему з кешуванням, яка призводить до використання невірних KV-даних (Key-Value) під час роботи з LoRA-адаптерами. Суть помилки полягає в тому, що система кешування оперативної пам'яті зберігає стан обчислень, але не фіксує, з якими саме параметрами масштабування адаптера вони були отримані. В результаті, коли запит повертається до слота, сервер може застосувати застарілі дані, обчислені для іншого масштабу, що спотворює кінцевий результат генерації.
Технічно проблема виникає через те, що механізм перевірки LoRA порівнює поточний запит не з кешованим записом, а з попереднім станом слота. Якщо слот був звільнений іншим запитом, а потім знову зайнятий, сервер помилково вважає, що кешовані дані є актуальними. Це створює ситуацію, коли модель генерує текст, базуючись на змішаних налаштуваннях: контекст був оброблений з одним масштабом адаптера, а продовження — з іншим, що робить відповіді непередбачуваними та фактично помилковими.
Ця вразливість особливо підступна, оскільки сервер не видає жодних помилок, а згенеровані токени виглядають цілком правдоподібно. На малих моделях, таких як stories15M, відмінності стають очевидними, проте на великих мовних моделях з використанням складних стилістичних адаптерів помилка може проявлятися як незначне погіршення якості або зміна тону відповіді. Користувачі можуть навіть не здогадуватися, що отримують некоректні дані, оскільки система звітує про успішне використання кешу.
Дослідження показало, що проблема проявляється при певній послідовності дій: запит з адаптером, витіснення його з кешу іншим запитом, і повторний запит з іншим масштабом адаптера. Якщо сервер має достатньо слотів і запити не витісняють один одного, помилка може не виникати, що ускладнює її діагностику. Саме тому стандартні тести, які виконують запити послідовно без проміжних операцій, часто не виявляють цю критичну ваду.
Для тимчасового вирішення проблеми розробники рекомендують запускати сервер із параметром --cache-ram 0. Це вимикає кешування в оперативній пам'яті, що гарантує коректність обчислень для кожного запиту, хоча й дещо знижує продуктивність. Також можна використовувати прапор cache_prompt: false для кожного окремого запиту. Ці заходи дозволяють уникнути використання «забруднених» даних до моменту, поки розробники не оновлять логіку кешування, додавши параметри адаптерів до ключів кешу.
Цей випадок є важливим уроком для розробників систем кешування: ключ кешу повинен включати всі змінні, що впливають на результат обчислень. У випадку з LLM це не лише вхідні токени, а й конфігурація адаптерів. Досвід llama-server демонструє, що перевірка стану лише за токенами є недостатньою, якщо архітектура підтримує динамічне налаштування параметрів. Подібні вразливості підкреслюють необхідність ретельного тестування кешування в сценаріях з частим перемиканням контекстів.
🔗 Першоджерело: Читати оригінал