Rulări de evaluare și CI
Suitele de teste și evaluările de prompturi trimit aceleași cereri la fiecare rulare. În spatele gateway-ului, costă ceva doar prompturile schimbate.
IA și LLMAplicații LLM
Gateway LLM cu caching
Îndreptați SDK-ul OpenAI sau Anthropic spre un singur URL, iar cererile repetate primesc răspuns de la HotKV în loc să fie plătite din nou. Fără modificări de cod.
- linie de cod de schimbat
- 1
- binar static
- ~6 MB
- open source
- Apache-2.0
Pasul 1 din 5
Porniți gateway-ul
Un binar sau un container în fața furnizorului. Cheia API a apelantului este transmisă mai departe, deci gateway-ul nu are nevoie de niciuna.
Sesiune de exempluplaying
# Porniți gateway-ul
$ hotkv-gateway --upstream https://api.openai.com --semantic --embedding-model text-embedding-3-small
(gateway listening on 127.0.0.1:8080, cache in HotKV)
O demonstrație animată cu comenzi HotKV reale și răspunsuri de exemplu. Faceți clic pe orice pas pentru a sări la el. Comenzile și răspunsurile rămân în engleză, exact așa cum le tastați și le vedeți în HotKV.
Problema
Cea mai mare parte a traficului LLM se repetă. Același prompt de sistem și aceeași întrebare sosesc iar și iar de la utilizatori diferiți, din reîncercări și din rulări de test, iar fiecare este facturată. Să adăugați un cache în interiorul fiecărui serviciu, în fiecare limbaj pe care îl folosiți, este lent și ușor de greșit.
Cum o rezolvă HotKV
hotkv-gateway stă între aplicația dvs. și API-ul LLM. Schimbați base URL-ul SDK-ului, iar cererile identice sunt servite de HotKV, răspunsurile în streaming sunt reluate ca streamuri, întrebările reformulate pot fi servite după sens, iar cererile identice aflate în desfășurare împart un singur apel către upstream. Dacă HotKV este lent sau căzut, cererile merg direct la furnizor.
Pas cu pas
Ce se întâmplă, comandă cu comandă
- 01
Porniți gateway-ul
Un binar sau un container în fața furnizorului. Cheia API a apelantului este transmisă mai departe, deci gateway-ul nu are nevoie de niciuna.
hotkv-gateway --upstream https://api.openai.com --semantic --embedding-model text-embedding-3-small - 02
Prima cerere, o ratare
Nimic în cache încă. Cererea merge o dată la upstream, iar răspunsul 200 finalizat este stocat.
curl -si localhost:8080/v1/chat/completions -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d @question.json | grep -i x-hotkv-cache - 03
Aceeași cerere, un succes
O cerere identică, chiar și cu chei în altă ordine, primește răspuns de la HotKV și nu ajunge niciodată la furnizor.
curl -si localhost:8080/v1/chat/completions -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d @question.json | grep -i x-hotkv-cache - 04
O întrebare reformulată
Cu cache-ul semantic activat, o întrebare dintr-un singur tur, formulată diferit, poate fi servită cu răspunsul la una similară.
curl -si localhost:8080/v1/chat/completions -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d @rephrased.json | grep -i x-hotkv-cache - 05
O rafală de cereri identice
Trei cereri identice sosesc cât timp prima este încă în desfășurare. Ele împart un singur apel către upstream.
for i in 1 2 3; do curl -si localhost:8080/v1/chat/completions -H "Authorization: Bearer $OPENAI_API_KEY" -d @new.json & done
Unde se potrivește
Scenarii din lumea reală
Platforme poliglote
Un backend Python, un worker Node.js și un serviciu Go primesc același cache schimbând un singur base URL, fără o bibliotecă în fiecare limbaj.
Modele găzduite propriu
În fața vLLM sau Ollama, gateway-ul economisește timp de GPU în loc de taxe API, pentru că prompturile repetate nu ajung niciodată la serverul de modele.
Integrat
Ce primiți
Cache exact și semantic
Cererile identice de chat, completion și embeddings sunt puse în cache, iar întrebările de chat dintr-un singur tur se pot potrivi și după sens (--semantic).
Reluarea streamingului
Răspunsurile în streaming sunt capturate și reluate ca stream, deci clienții se comportă exact ca înainte.
Sigur implicit
Fiecare cheie API are propriul cache. Erorile și răspunsurile filtrate nu sunt niciodată stocate, iar cererile pot ocoli cache-ul printr-un header.
Niciodată în drum
Dacă HotKV este lent sau indisponibil, cererile merg direct la furnizor. Gateway-ul își raportează cifrele și la /_hotkv/metrics.
Singura modificare din codul dvs.
python
from openai import OpenAI client = OpenAI(base_url="http://localhost:8080/v1") # the only change # For Anthropic: start the gateway with --upstream https://api.anthropic.com import anthropic client = anthropic.Anthropic(base_url="http://localhost:8080")
Întrebări frecvente
Are gateway-ul nevoie de o licență HotKV?
Nu. Funcționează cu orice server HotKV. Cu o licență care include cache-ul de prompturi, intrările stau într-un spațiu de nume PCACHE, iar HotKV urmărește tokenii economisiți. Cache-ul semantic are mereu nevoie de licență.
Pot doi clienți să vadă răspunsurile unul altuia?
Nu. Cheia de cache include credențialele apelantului, deci fiecare cheie API are propriul cache, cu excepția cazului în care păstrați o singură cheie upstream în gateway sau îl porniți cu --scope global.
Cu ce furnizori funcționează?
OpenAI, Azure OpenAI, OpenRouter, vLLM, Ollama, LiteLLM și orice altceva care vorbește API-ul OpenAI, plus Messages API de la Anthropic cu cache-ul exact.
Cazuri de utilizare înrudite
Încercați pe propria sarcină de lucru
HotKV vorbește protocolul Redis, așa că puteți îndrepta spre el un client existent și rula aceleași comenzi.