Tensormesh spouští platformu, která díky opětovnému využívání KV cache snižuje náklady na inferenci LLM

Pokaždé, když asistent s umělou inteligencí obdrží dlouhý dokument, musí jej zpracovat, než může začít odpovídat. Když se znovu objeví stejné dokumenty, pokyny nebo historie konverzace, může být nutné velkou část tohoto zpracování opakovat. Ve firemním měřítku může takové opakování spotřebovávat nákladnou kapacitu GPU, aniž by přinášelo užitečnou práci navíc.

Tensormesh se zaměřuje na tento problém platformou Tensormesh Platform, kterou oznámila 14. října 2026. Společnost, jejíž tým vytvořil open source projekt LMCache, přináší organizacím provozujícím velké jazykové modely na vlastní infrastruktuře vrstvu pro správu ukládání klíčů a hodnot, neboli KV cache.

Platforma spravuje znovu využitelný stav inference v paměti GPU, paměti CPU i úložišti. Zamýšlený přínos je přímočarý: omezit množství zpracování promptů, které musí flotila GPU opakovat, a zároveň dát operátorům možnost řídit, jak se tento stav uložený v mezipaměti uchovává, sdílí a monitoruje.

Proč je KV cache důležitá

Inference LLM má dvě důležité fáze. Během fáze předzpracování model zpracovává vstupní prompt. Během fáze dekódování generuje odpověď token po tokenu. KV cache uchovává průběžný stav související s mechanismem pozornosti, který modelu umožňuje vracet se ke zpracovaným tokenům, aniž by musel vše znovu počítat od začátku.

Opětovné využití tohoto stavu napříč požadavky může omezit práci při předzpracování, pokud se kontext vstupu opakuje. Asistent zákaznické podpory může například při odpovídání na stovky různých otázek vycházet ze stejné příručky k produktu. Agent může opakovaně přikládat stejné pokyny nebo nástroje, zatímco se mění úloha.

To se liší od ukládání hotové odpovědi do mezipaměti. Systém může znovu využít výpočty spojené se sdíleným kontextem a zároveň stále generovat novou odpověď na novou otázku.

Dokumentace vLLM k automatickému ukládání prefixů do mezipaměti popisuje tento přínos při opakovaných dotazech k dokumentům a ve vícedílných konverzacích. Zároveň stanovuje důležité omezení: ukládání prefixů do mezipaměti urychluje zpracování promptu, nikoli generování nových výstupních tokenů. U úloh, v nichž převažují dlouhé odpovědi nebo převážně jedinečné vstupy, může být přínos menší.

Pro firemní zákazníky je důležité zjistit, jaká část jejich skutečného pracovního zatížení obsahuje znovu využitelný kontext — a zda jej lze získat rychleji a levněji, než kdyby se zpracovával znovu.

Od mezipaměti ke spravované infrastruktuře

V oznámení společnost Tensormesh uvádí pět provozních priorit: zabezpečení, pozorovatelnost, odolnost, správu zásad a podporu více tenantů. Tyto priority se týkají praktických úkolů, jako je ochrana dat uložených v mezipaměti, sledování výkonu, obnova po selhání, řízení uchovávání a vyřazování dat a oddělení týmů nebo zákazníků ve sdílené infrastruktuře.

Společnost také popisuje rozhraní API řadiče pro připínání, vyhledávání, přesouvání, kompresi a mazání položek mezipaměti. Správa životního cyklu mezipaměti se tak stává výslovnou provozní záležitostí, místo aby byla ponechána zcela na jednotlivých procesech inference.

Základní projekt LMCache odděluje správu mezipaměti od obslužného modulu a podporuje přesun i načítání dat napříč několika úrovněmi úložiště. Jeho dokumentace popisuje opětovné využití napříč požadavky, relacemi a instancemi obslužného modulu, a to s možností připojit různé backendy úložiště a přenosu dat.

Podniková platforma na tomto základu staví. Podle jejího instalačního průvodce spravuje operátor Kubernetes komponenty modulu mezipaměti; servery mezipaměti běží na uzlech GPU a koordinátor zajišťuje koordinaci na úrovni celé flotily. Helm slouží k nasazení, zatímco k provozu pomáhá webové rozhraní a nástroje příkazového řádku.

Tato architektura je důležitá, protože paměť GPU je omezeným zdrojem. Uchovávání všech promptů, které by případně bylo možné znovu využít, by konkurovalo ostatním potřebám inference. Přesun stavu, který není potřeba okamžitě, do paměti hostitele nebo úložiště může zvýšit množství uchovávaných dat, načítání však přináší vlastní náklady na šířku pásma a latenci.

Více než jen totožné prefixy promptů

Ukládání prefixů do mezipaměti funguje dobře, když dva prompty začínají stejnými tokeny. S generováním rozšířeným o vyhledávání, neboli RAG, to může být složitější: aplikace načte relevantní dokumenty, ale ty se mohou objevit v různém pořadí nebo až po odlišném předcházejícím textu.

Představme si dvě hypotetické žádosti, které využívají stejné dokumenty. Jedna obsahuje dokument A a po něm dokument B; druhá obsahuje dokument B a po něm dokument A. Obě zahrnují znovu využitelný obsah, ale jejich společný začátek může být krátký.

Tensormesh využívá CacheBlend k rozšíření opětovného využití i za začátek promptu. Dokumentace LMCache vysvětluje, že systém selektivně znovu počítá část tokenů a současně znovu využívá bloky uložené v mezipaměti. Opětovný výpočet je důležitý, protože okolní kontext bloku může ovlivnit vnitřní stav modelu.

Výzkumná práce o CacheBlend, představená na konferenci EuroSys 2025, uvádí, že v hodnocených úlohách dosáhla 2,2–3,3krát kratší doby do prvního tokenu a 2,8–5krát vyšší propustnosti ve srovnání s úplným přepočítáním KV cache. Autoři hodnotili tři modely s otevřeným zdrojovým kódem a čtyři sady benchmarků.

Jde o výsledky výzkumu dosažené za konkrétních podmínek, nikoli o zaručenou úsporu při každém nasazení Tensormesh. Ukazují však, proč je z technického hlediska zajímavé opětovné využití i nad rámec sdíleného prefixu: umožňuje obnovit výpočetní práci, kterou by běžné porovnávání prefixů přehlédlo.

Opětovné využití napříč uzly a význam podpory pro konkrétní verze

Oznámení o uvedení popisuje přenosy KV mezi uzly typu peer-to-peer, které umožňují jednomu uzlu načíst stav z mezipaměti jiného uzlu, a produktové materiály společnosti popisují oddělení fází prefill a decode. Toto oddělení rozděluje zpracování promptu a generování výstupu, takže obě fáze mohou běžet na různých pracovních uzlech.

Jde o vzájemně se doplňující způsoby organizace inference. Sdílení kompatibilního stavu může zabránit jeho opětovnému výpočtu na jiném uzlu; oddělení jednotlivých fází zase umožňuje infrastrukturním týmům přidělovat prostředky odlišně podle jejich nároků na zpracování.

Veřejné materiály se však v otázce dostupnosti funkcí v jednotlivých verzích zcela neshodují. Úvodní informace o uvedení popisují sdílení napříč uzly a oddělení fází, zatímco matice kompatibility podle verzí ze 17. září uvádí přenosy typu peer-to-peer a oddělení fází v plánu dalšího vývoje. Dokumentace k funkcím obsahuje také stránky s náhledovými verzemi.

Stejná matice rozlišuje mezi funkcemi ověřenými při testování Tensormesh a funkcemi podporovanými v upstreamových projektech, které však před nasazením do produkce vyžadují další testování. Jako ověřené obslužné enginy uvádí vLLM a NVIDIA Dynamo, zatímco SGLang a TensorRT-LLM jsou v plánu dalšího vývoje.

Obecně formulovaná tvrzení o široké kompatibilitě při uvedení proto vyjadřují směr vývoje, nikoli důkaz, že byla ověřena každá kombinace modelu a infrastruktury. Týmy by si měly potvrdit přesnou verzi, obslužný engine, model a režim mezipaměti, které hodlají nasadit.

Úvodní informace o uvedení konkrétně popisují vLLM v Kubernetes s grafickými procesory NVIDIA nebo podporovanými grafickými procesory AMD Instinct prostřednictvím ROCm a úložištěm založeným na souborovém systému. Uvádějí, že ukládání do mezipaměti bez využití prefixů pro husté modely a podpora SGLang jsou teprve plánovány. Zároveň upřesňují, že mezipaměť funguje souběžně s modely hostovanými vlastními silami; nejde o doplněk, který lze připojit k libovolnému rozhraní API hostovaného modelu.

Kde by ekonomika provozu mohla dávat smysl

Nejvhodnějšími kandidáty jsou aplikace, které opakovaně zpracovávají rozsáhlý sdílený kontext: interní asistenti pro znalostní báze, služby pro analýzu dokumentů a agenti, kteří se opakovaně vracejí ke stabilnímu souboru pokynů nebo referenčních materiálů.

Užitečné vyhodnocení by porovnalo chování při prázdné a zahřáté mezipaměti na reprezentativním provozu. Provozovatelé by měli měřit dobu do prvního tokenu, propustnost, dobu načítání z mezipaměti, využití GPU a náklady na paměť, úložiště a síť spojené s uchováváním stavu.

Samotná míra zásahů do mezipaměti nestačí. Vysoká míra zásahů je přínosná jen tehdy, pokud ušetřená práce přináší čistý prospěch i po započtení režie na přenos a správu. Stejně tak rychlejší zobrazení prvního tokenu nutně neznamená, že se celá odpověď dokončí úměrně rychleji.

Kvalitu odpovědí je třeba ověřovat samostatně, zejména když se části uložené v mezipaměti kombinují v odlišném kontextu. Selektivní přepočítávání v CacheBlend je navrženo tak, aby tento problém řešilo, testování v produkčním prostředí by však mělo zahrnovat vlastní dokumenty organizace, formáty promptů a konfigurace modelů.

S tím, jak se mezipaměť rozšiřuje za hranice jediného procesu, nabývají na významu také pravidla uchovávání dat a izolace tenantů. Mezi důležité provozní otázky patří, kdo může položku znovu použít, jak dlouho zůstává dostupná a jak změny zásad nebo žádosti o vymazání ovlivní uložený stav. Ohlášené funkce pro správu od Tensormesh mají umožnit tato rozhodnutí řídit.

Praktická sázka na omezení opakované práce

Podle oznámení společnosti je Tensormesh Platform k dispozici od uvedení na trh. Její význam spočívá v tom, že stav inference chápe jako prostředek, který lze spravovat napříč celým prostředím, přičemž výpočetní práci lze opakovaně využívat i po skončení životnosti jednotlivého požadavku.

Podnikům, které provozují vlastní infrastrukturu pro LLM, to nabízí konkrétní způsob, jak zvýšit efektivitu: opakovaně využít větší část práce na zpracování promptů, která už byla vykonána. Výsledek bude záviset na míře opakování úloh, kompatibilitě mezipaměti a nákladech na přenos dat — to vše jsou však měřitelné technické otázky, které mohou týmy ověřit na vlastním provozu.