KV cache compression е инфраструктурно решение, не спор за модела
KV cache compression вече не е дебат за качеството на модела. Това е решение за инфраструктурна покупка, към което има и чисто математически проблем.
Казвам го директно, защото твърде много екипи още третират паметта на LLM при дълъг контекст като надпревара по бенчмаркове: TurboQuant срещу OSCAR срещу EpiCache, избираш победител и продължаваш. На практика внедряванията не се провалят така. Те се провалят, защото един екип оптимизира за bit-width, друг за преносимост, а трети разбира твърде късно, че историята на многоходов чат е различен проблем от единичен prompt с 128K. Според обобщението на MarkTechPost от 18 юни, трите подхода решават съседни тесни места, а не едно и също.
KV cache compression става болезнен, когато таванът ви е HBM, а не FLOPs
Математиката на паметта е частта, която операторите не могат да игнорират. Примерът в източника използва Llama-3.1-70B в BF16: около 0.31 MB KV cache на токен, приблизително 40 GB при 128K токена и над 300 GB при 1M токена. Това е моментът, в който cache-ът може да надмине самите тегла на модела. Ако обслужвате заявки с дълъг контекст и concurrency, всеки декодиран токен връща този cache обратно през high-bandwidth memory.
Тази промяна е по-важна от още една точка в leaderboard. Щом декодирането стане bandwidth-bound, кривата на разходите ви се променя. Вече не питате: може ли този модел да отговаря добре? Питате: колко сесии мога да държа активни, преди трафикът към паметта да срине latency?
В един клиентски load test, който проведох миналия месец, изборът на модел не беше основното ограничение. Prefix reuse изглеждаше отлично самостоятелно, но щом броят на конкурентните сесии се повиши, tail latency скочи, защото ограничението беше движението на паметта, а не compute. Затова базовата 2-bit работа на KIVI все още има значение през 2026 г.: тя рамкира quantization на KV cache като проблем на inference системи, а не просто като трик за компресия.
TurboQuant е ходът за преносимост, не универсалният победител
TurboQuant е впечатляващ с причина. Google Research и NYU изграждат data-oblivious подход, който атакува outlier каналите без calibration. Първо върти векторите на случаен принцип, така че координатите да се държат повече като независими Gaussian променливи. После прилага предварително изчислен scalar quantizer и 1-bit QJL transform върху остатъка. Теоретичното твърдение е силно: изкривяването остава в рамките на малък константен фактор от долната граница.
Това е правилният инструмент, когато държите на преносимост между модели и не можете да си позволите персонализиран calibration run за всяка цел на обслужване. Докладваният sweet spot е диапазонът 3 до 4 bit, където качеството остава почти без загуба при натоварванията, върху които статията акцентира. Това прави TurboQuant привлекателен за екипи с хетерогенни fleet-и или за такива, които експериментират върху множество архитектури.
Но ето и по-острата теза: хората постоянно повтарят грешното обещание. Най-шумното твърдение около TurboQuant е репликата за „8x по-бърз attention на H100“ от блога на Google Research, но изходната статия правилно отбелязва, че това се отнася за тесен microbenchmark, а не за end-to-end serving. Виждал съм този модел и преди при inference kernel-и: победа в един етап се превръща в аргумент за цялата инфраструктура. Така екипите си купуват разочарование.
OSCAR има значение, защото някой реално е доставил мръсната работа
Ако целта ви е внедрим INT2 KV cache compression, OSCAR е практическата история в момента. Системата на Together AI не просто предлага attention-aware rotation; тя пакетира около него mixed-precision paging, Triton kernel-и и интеграция със SGLang. Това е важно, защото производствените печалби обикновено идват от пакета, не само от статията.
Детайлите имат значение. OSCAR запазва sink и recent token-ите в BF16, докато компресира историческите token-и до INT2, като според обобщението оставя некомпресирани едва около 0.24% от token-ите при 128K контекст. Освен това доставя предварително изчислени ротации за поддържаните модели, което премахва една неприятна стъпка при внедряване. Докладваното предимство е съществено: до 7.83x throughput на ниво job, около 8x редукция на паметта за KV cache при 100K контекст и до 3x по-бързо декодиране в тестваните среди.
Затова смятам, че OSCAR в момента печели аргумента за deployability в нискобитовия край. Не защото идеята е по-елегантна. А защото някой затвори пропастта между теорията за quantization и реалността на serving.
Най-силният аргумент за пряк победител пак не издържа
Честният контрааргумент е, че на enterprise екипите им трябва прост отговор. Ако един метод побеждава друг по benchmark качество и throughput, изборът на лидера намалява сложността. В това има логика. Всеки допълнителен inference път добавя overhead за тестване, логика за rollback, работа по observability и натоварване за поддръжката. Стандартизацията върху един метод често е разумният оперативен избор.
Съгласен съм с този инстинкт. Просто не мисля, че наличните доказателства подкрепят универсален победител.
Сравнението, докладвано от OSCAR, подсказва, че TurboQuant губи сериозно при сходни бюджети, но този прочит идва с уговорки, които изходната статия правилно маркира: сравнението се изпълнява в рамката на OSCAR, quantize-ва всички слоеве, използва единичен случаен seed и оценява TurboQuant под неговия замислен режим от 3 до 4 bit. Това не е достатъчно за категорична присъда. Обратно, тезата за преносимостта на TurboQuant не отговаря на въпроса дали следващата седмица можете да получите стабилно production поведение с INT2 върху вашия точен stack.
Затова реалното решение е по-тясно и по-скучно:
- Изберете TurboQuant, когато преносимото внедряване между модели и почти беззагубното поведение при 3 до 4 bit са по-важни от абсолютната компресия.
- Изберете OSCAR, когато ви трябват INT2 за поддържани модели, production интеграция и незабавни спестявания на памет при дълъг контекст.
- Не насилвайте нито едно от двете да решава управлението на паметта при многоходови разговори, защото това не е тяхната задача.
EpiCache напомня, че дългите prompt-ове и дългите разговори са различни системни проблеми
Точно тази част много екипи пропускат. Един prompt с 128K и разговор с продължителност два часа не са едно и също натоварване, дори и двете да изглеждат като „дълъг контекст“ на слайд.
Apple’s EpiCache адресира директно разговорния сценарий. Вместо да пита само колко прецизно да съхранява token-ите, той пита коя история да остане активна, как да се сегментира в смислени епизоди и как да се извлече правилният епизод по време на inference. Рамката добавя block-wise prefill, episodic clustering, retrieval върху епизоди и layer-wise budgeting на паметта.
Оперативно това е различна ос спрямо quantization на KV cache. Това е управление на cache, не просто свиване на cache. Докладваните резултати в изходния материал показват защо това разграничение има значение: до 40% по-висока точност спрямо eviction baseline-и, почти точност на пълен cache при 4 до 6x компресия, до 3.5x по-ниска пикова памет и около 2.4x по-ниска latency в оценените conversational benchmark-и.
Моето възражение срещу мисленето „просто изберете победител“ е просто: EpiCache се комбинира с TurboQuant или OSCAR. Така че ако натоварването ви е support copilot, research assistant или вътрешен agent с дълбока чат история, най-добрият stack може да е един метод за retention и друг за прецизност на съхранението. Това не е колебание. Това е системен дизайн.
Правилният въпрос е кое ограничение ви струва пари първо
Когато вляза в review на inference инфраструктура, не започвам с имената на статиите. Започвам с три въпроса.
Първо, serving fleet-ът memory-bound ли е по време на decode, или още сме compute-bound? Второ, трябва ли ни преносимост между модели, или можем да оптимизираме агресивно за поддържан stack? Трето, натоварването доминира ли се от един дълъг prompt, или от много разговорни ходове?
Тези въпроси обикновено стесняват избора бързо. Ако преносимостта доминира, TurboQuant има по-чистия аргумент. Ако екипът ви вече е на stack, който OSCAR поддържа, и ви трябват агресивни INT2 спестявания сега, OSCAR изглежда по-силен. Ако support сесиите или agent паметта са болезнената точка, EpiCache трябва да е в дизайна, дори ако паралелно правите и quantization.
Затова се връщам към една и съща контраинтуитивна теза: KV cache compression всъщност не е състезание. Това е проблем по дизайн на stack, който беше маркетираn като клетъчен двубой.
Related reads
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation