Витіснення KV Cache може приховувати збої LLM у production

Так. Витіснення KV cache може приховувати збої LLM, оскільки політика обслуговування може відкинути стан attention, який мав значення, а потім не мати достатньо інформації, щоб оцінити шкоду лише за збереженим cache.

Стаття, подана 23 липня 2026 року, чітко окреслює цю проблему: детерміноване, value-blind top-k витіснення не може стабільно оцінювати спричинену ним помилку attention-output за збереженим станом. Запропонована альтернатива зберігає ймовірнісну вибірку відкинутого хвоста та будує статистичний сертифікат навколо оціненої помилки. Метод покращив атрибуцію збоїв у наведених експериментах, але прототип повільніший, експерименти обмежені контекстом до 16K і 8B параметрів, а стаття не доводить наскрізну правильність відповідей.

Перед rollout порівняйте кожен кандидатний варіант роботи з cache з контролем на повному cache на тих самих зафіксованих запитах. Порахуйте випадки, коли повний cache проходить перевірку, а кандидат — ні. Тестуйте eviction, quantization, offload і reuse окремо, щоб кожне порівняння ізолювало одне джерело помилки.

Рівень читача: Advanced. Цей посібник передбачає розуміння transformer inference, attention і базової оцінки моделей.

Зміст

Чому витіснення KV cache може приховувати збої

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

ArXiv:2607.21475 досліджує цю проблему спостережуваності. Її негативний результат стосується детермінованого, value-blind top-k eviction: лише збережений стан не дає змоги отримати узгоджену оцінку помилки attention-output, спричиненої eviction. Результат не стверджує, що кожна детермінована політика породжує низькоякісні виходи. Він стверджує, що цей клас політик не може надійно сертифікувати спричинену ним помилку, використовуючи лише те, що було збережено.

Запропонований метод зберігає докази щодо відкинутого хвоста. Він виконує Poisson sampling записів, які інакше зникли б, застосовує корекцію Hájek і поєднує цю оцінку з variance certificate для збереженої множини.

Виміряно: Сертифікат помилки зафіксував 0.97 coverage у 12 096 attention replay cells. Окреме дослідження на реальних workload використало близько 74 000 генерацій для перевірки атрибуції збоїв. У цьому дослідженні сертифікат досяг AUC 0.73–0.75 для розрізнення збоїв, спричинених cache, від внутрішніх збоїв моделі. Output confidence досяг 0.47–0.54 у тому самому завданні атрибуції.

Виміряно: Output confidence краще передбачав загальний збій. Два сигнали відповідають на різні питання:

Виведено: Низький output confidence не може бути єдиним сигналом тривоги щодо cache regression. Він може позначити слабку відповідь, не визначивши її причину, тоді як упевнена відповідь усе одно може змінитися після того, як політика cache видалить корисний стан.

Стаття також повідомляє про негативні та операційні результати. Три з семи preregistered claims не підтвердилися. Її прототип займав 0.043 секунди на token порівняно з 0.023 для deterministic eviction і 0.015 для full cache. Експерименти охоплювали контексти до 16K, моделі до 8B і single-turn proxy. Автори не надають теореми, яка пов’язувала б сертифікат із наскрізною правильністю завдання.

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

Чотири варіанти роботи з cache, чотири питання надійності

Команди часто об’єднують кілька втручань під назвою “KV cache optimization”. Кожне втручання змінює іншу частину inference.

Системно-орієнтований огляд у arXiv:2607.08057 класифікує галузь через temporal scheduling, spatial placement and migration, а також structural representation and retention. Ця таксономія також працює як межа оцінювання. Порівняння full-cache BF16 control із evicted FP8 candidate одночасно змінює дві structural variables. Невдалий candidate не дає змоги визначити, чи спричинили regression eviction, quantization або їхня взаємодія.

Практична інтерпретація: Тестуйте кожне cache intervention як окремий експеримент. Поєднуйте їх лише після того, як окремі варіанти пройдуть перевірку.

Політики, що зберігають більше корисного стану

Дві інші статті показують, що дизайн політики може зберігати більше якості за того самого memory budget. Жодна з них не надає універсального production threshold.

VaSE, arXiv:2606.03928 захищає value states із високою magnitude, зберігаючи stochastic diversity. На Qwen3-4B і Qwen3-14B у шести reasoning tasks метод досяг приблизно 4× cache compression і покращив результати на 4.4 та 4.9 пункту порівняно з найсильнішим eviction baseline. В одному 16K, single-A100 setup було досягнуто 3.1× tokens per second.

Ці вимірювання охоплюють лише decode, моделі Qwen3 і не включають production batching. Вони не встановлюють такого самого приросту для іншої model family, serving engine, рівня concurrency або workload.

K-VEC, arXiv:2606.29563 координує retention coverage між attention heads і layers. На Llama 3.1 8B у 16 LongBench subsets метод покращив scores щонайбільше на 10.35 пункту і в середньому на 1.61 пункту за budget `B=128`. Оцінювання використовує одну model family і один benchmark suite, а метод додає prefill work.

Практична інтерпретація: Value-aware, stochastic і coverage-aware політики варто включити до кандидатів для оцінювання. Ваш full-cache run залишається локальним джерелом істини.

Чому quantization потребує окремого контролю

FP8 KV cache quantization зменшує precision, а не видаляє tokens. Її помилки все одно можуть дійти до application без engine error.

Офіційне дослідження vLLM FP8, опубліковане 22 квітня 2026 року, повідомило про падіння long-context needle accuracy з 91% із BF16 cache до 13% із FP8 до виправлення two-level accumulation. Виправлення відновило accuracy до 89%. У найкращій наведеній FP8 configuration decode slope становив 54% від BF16.

Виміряно: Один numerical path спричинив severe regression, а kernel-level correction відновила більшу частину втраченої accuracy.

Не встановлено: FP8 cache не спричиняє таку regression універсально і не гарантує такого speedup. Результат залежить від implementation, model, hardware, attention path і benchmark.

vLLM issue #37554 додає вузьке попередження: reporter виявив silent corrupted FP8 KV scaling у hybrid model. Цей bug report не може підтвердити загальне твердження про FP8 або hybrid architectures.

Обговорення LocalLLaMA від 7 квітня містить суперечливі practitioner reports щодо cache formats і quality. Ці reports можуть підказати test cases, але рішення про rollout має ґрунтуватися на controlled evaluation.

Реліз vLLM v0.26.0, датований 25 липня, містить 411 commits від 212 contributors і розширює visibility щодо KV tiering, offload metrics і cache reuse. Release activity і нові observability features не доводять широкого production adoption або correctness.

Парний workflow валідації на повному cache

Визначте “full cache” як native attention behavior моделі без додаткових eviction або cache quantization. У межах кожної пари зафіксуйте model weights, tokenizer, runtime version, attention backend, sampling settings, prompt tokens і output validator.

1. Запустіть ablation matrix

Використовуйте щонайменше чотири варіанти:

Порівняння лише A з D може виявити combined regression, але не може визначити причину. Runs B і C надають відсутні controls.

Тестуйте кожну підтримувану model, runtime, kernel і hardware path окремо. Результат vLLM FP8 показує, чому позначки на кшталт “FP8 enabled” недостатньо для рішення щодо reliability.

*Підпис: Парна валідація на повному cache ізолює збої, властиві candidate, до того, як eviction або quantization потраплять у production.*

2. Зафіксуйте workload matrix

Побудуйте matrix на основі реальних request shapes і включіть boundary cases:

Long-context workloads потребують більшого, ніж synthetic needle test. Якщо продукт запускає code agents або extended workflows, включіть representative traces. Token volume і workflow shape впливають на economics, описану в More Tokens, Better AI — and the Compute Bill і Code Agents, 21 Billion Activity Tokens, and the Fable of GPT-5.6.

3. Об’єднайте запити в пари та ізолюйте cache state

Використовуйте таку evaluation logic:

text for each frozen_case: full = run(frozen_case, treatment=A, isolated_cache=true) candidate = run(frozen_case, treatment=candidate, isolated_cache=true)

full_pass = validate(full, frozen_case.expected_behavior) candidate_pass = validate(candidate, frozen_case.expected_behavior)

record(full_pass, candidate_pass, context_length, task_type, model, runtime, hardware, treatment)

Цей блок є pseudocode, а не engine-specific API. Використовуйте task validator, а не text equality, коли правильними можуть бути кілька відповідей. Придатні validators включають unit tests для generated code, schema checks для structured output, exact tool-and-argument checks, retrieval assertions або preregistered rubric.

Ізолюйте cache namespaces. Prefix state, повторно використаний між treatments, може забруднити порівняння.

4. Вимірюйте candidate-only failures

Використовуйте цю primary metric:

text cache_induced_failure_rate = count(full passes and candidate fails) / count(full passes)

Denominator обмежує rate випадками успіху full-cache. Пара, у якій обидва runs завершилися невдало, не показує, що cache compression спричинила failure.

Звітуйте про raw numerator і denominator для кожного critical slice. Один aggregate може приховати regression на максимальному context, на одній model або під одним attention backend. Відстежуйте total failure rate поруч із paired metric, оскільки output confidence і cache-attribution signals охоплюють різні failure modes.

5. Заздалегідь визначте decision rule

Оберіть максимальний прийнятний rate, `τ`, до перегляду результатів candidate. Встановлюйте суворіші правила для critical tasks. Відтворюваний candidate-only failure може бути підставою для відхилення на tool, safety або transaction path, навіть якщо aggregate залишається нижче `τ`.

Cache configuration належить до execution policy. Записуйте та застосовуйте її з тією самою дисципліною, що й для deterministic AI-agent permissions: explicit configuration, observable decisions і repair path, коли enforcement fails.

Рішення щодо rollout

Release-note activity, anecdotal reports і average benchmark gains не можуть замінити paired rollout gate.

Обмеження поточних доказів

Найсильніший результат щодо certificate охоплює attention-output error у межах single-turn proxy, а не наскрізну correctness application. Експерименти обмежені 16K і 8B, тоді як production systems можуть запускати більші моделі, довші контексти, multiple turns, tools і batches. Виміряний prototype також потребує більше часу на token, ніж deterministic eviction і full cache у наведеному setup.

VaSE і K-VEC залишаються прив’язаними до конкретних models, tasks, budgets і serving setups. Докази vLLM показують, що implementation details можуть домінувати над результатом cache format. Жодне з цих джерел не надає універсального safe compression ratio.

Практична інтерпретація: Використовуйте дослідження для вибору candidate policies і monitoring signals. Використовуйте paired full-cache validation, щоб вирішити, чи відповідає ваша implementation reliability limits для вашого workload.

Перевірка тверджень

Джерела