LLM-запити дорогі та повільні. Особливо коли 30–40% з них дублюються або семантично схожі. Кешування LLM — найдешевший спосіб знизити обидва показники. Наша компанія має 10+ років досвіду в AI/ML та понад 50 реалізованих проєктів із впровадження exact та semantic кешування LLM під ключ: від простого exact match до семантичного пошуку за ембеддингами. Exact cache дає hit rate до 35%, Semantic cache — ще 28%, і разом вони закривають 63% запитів без виклику LLM. При типовому навантаженні 5000 запитів/день це значна економія коштів — до $10,000 на місяць на GPT-4o або $15,000 на Claude. Оцінимо ваш проєкт за 1 день — просто зв'яжіться з нами.
Головний біль — кожен повторний запит до GPT-4o або Claude летить в API та оплачується. При типовому навантаженні 5000 запитів/день 30% — дублікати. Exact cache на Redis повертає відповідь за 5–15 мс замість 2–5 секунд — це в 100 разів швидше. Semantic cache додає ще 20–28% збігів за змістом, навіть якщо формулювання інше. Провали контексту при частих однотипних питаннях також усуваються — кеш гарантує стабільну відповідь без галюцинацій. Exact та Semantic cache — два основні види кешування LLM, які ми комбінуємо для максимальної ефективності.
Як влаштований Exact Cache?
Просто: хешуємо промпт (messages, model, temperature) та зберігаємо відповідь у Redis. При повторному запиті з тим же хешем — повертаємо без виклику LLM. Підходить для FAQ, форм, шаблонних запитів. Exact cache обробляє запит у 100 разів швидше, ніж Semantic cache (5–15 мс проти 50–100 мс).
Реалізація Exact Cache
import hashlib import json import redis from typing import Optional from functools import wraps class ExactLLMCache: def __init__(self, redis_url: str = "redis://localhost:6379", ttl: int = 3600): self.redis = redis.from_url(redis_url) self.ttl = ttl def _make_key(self, messages: list[dict], model: str, temperature: float) -> str: """Створює ключ кешу з параметрів запиту""" cache_input = { "messages": messages, "model": model, "temperature": temperature, } content = json.dumps(cache_input, sort_keys=True, ensure_ascii=False) return f"llm:exact:{hashlib.sha256(content.encode()).hexdigest()}" def get(self, messages: list[dict], model: str, temperature: float = 0) -> Optional[str]: key = self._make_key(messages, model, temperature) cached = self.redis.get(key) if cached: return cached.decode() return None def set(self, messages: list[dict], model: str, temperature: float, response: str): key = self._make_key(messages, model, temperature) self.redis.setex(key, self.ttl, response.encode()) def cached_complete(self, complete_fn): """Декоратор для кешування функцій""" @wraps(complete_fn) def wrapper(messages, model="gpt-4o", temperature=0, **kwargs): cached = self.get(messages, model, temperature) if cached: return cached result = complete_fn(messages, model=model, temperature=temperature, **kwargs) self.set(messages, model, temperature, result) return result return wrapper Навіщо потрібен Semantic Cache?
Exact кеш ловить лише однакові запити, але користувачі часто переформульовують питання. Semantic Cache вирішує цю проблему: перетворюємо питання на ембеддинг, шукаємо у векторній БД схожі, і при косинусній схожості >0.92 повертаємо відповідь. Ефективно для чатів, де формулювання відрізняються. Семантичний кеш хоч і повільніший за точний (50–100 мс vs 5–15 мс), але краще справляється з варіаціями питань.
Реалізація Semantic Cache
from openai import OpenAI import numpy as np from dataclasses import dataclass @dataclass class CachedEntry: query_embedding: list[float] question: str answer: str model: str created_at: float class SemanticLLMCache: """Кеш на основі векторної схожості питань""" def __init__( self, similarity_threshold: float = 0.92, max_entries: int = 10000, ): self.openai = OpenAI() self.threshold = similarity_threshold self.entries: list[CachedEntry] = [] def _get_embedding(self, text: str) -> list[float]: response = self.openai.embeddings.create( model="text-embedding-3-small", input=text, ) return response.data[0].embedding def _cosine_similarity(self, a: list[float], b: list[float]) -> float: a_arr = np.array(a) b_arr = np.array(b) return np.dot(a_arr, b_arr) / (np.linalg.norm(a_arr) * np.linalg.norm(b_arr)) def get(self, question: str, model: str = None) -> Optional[str]: """Шукає схоже питання в кеші""" if not self.entries: return None query_embedding = self._get_embedding(question) best_similarity = 0 best_answer = None for entry in self.entries: if model and entry.model != model: continue similarity = self._cosine_similarity(query_embedding, entry.query_embedding) if similarity > best_similarity: best_similarity = similarity best_answer = entry.answer if best_similarity >= self.threshold: return best_answer return None def set(self, question: str, answer: str, model: str): """Додає запис до кешу""" import time embedding = self._get_embedding(question) entry = CachedEntry( query_embedding=embedding, question=question, answer=answer, model=model, created_at=time.time(), ) self.entries.append(entry) # Обмежуємо розмір кешу if len(self.entries) > 10000: self.entries = sorted(self.entries, key=lambda e: e.created_at)[-10000:] Порівняння Exact та Semantic Cache
| Характеристика | Exact Cache | Semantic Cache |
|---|---|---|
| Принцип | Хеш промпту | Векторна схожість |
| Сховище | Redis | ChromaDB / Qdrant |
| Latency (p95) | 5–15 мс | 50–100 мс |
| Hit rate | до 35% | до 28% |
| Використання | Часто повторювані запити | Семантично схожі питання |
| Складність реалізації | Низька | Середня |
Exact та Semantic cache – два основні види кешування LLM, які ми комбінуємо для досягнення максимального hit rate.
Комбінований кеш: Redis + векторне сховище
У production ми об'єднуємо обидва підходи: спочатку перевіряємо exact cache (Redis), потім semantic (ChromaDB). Це дає мінімальну latency та максимальний hit rate. Така комбінація exact та semantic кешування LLM дозволяє досягти 63% попадань.
Production реалізація
import chromadb import time class ProductionSemanticCache: """Production-ready кеш: Redis для exact, Chroma для semantic""" def __init__(self): self.redis = redis.from_url("redis://localhost:6379") self.chroma = chromadb.HttpClient(host="localhost", port=8000) self.collection = self.chroma.get_or_create_collection("llm_cache") self.openai = OpenAI() self.similarity_threshold = 0.93 self.exact_ttl = 3600 self.semantic_ttl = 86400 # 24 години def get(self, question: str, model: str) -> Optional[dict]: # 1. Exact match спочатку (швидко) exact_key = f"llm:exact:{hashlib.md5(f'{question}:{model}'.encode()).hexdigest()}" exact_hit = self.redis.get(exact_key) if exact_hit: return {"answer": exact_hit.decode(), "cache_type": "exact"} # 2. Semantic match embedding = self.openai.embeddings.create( model="text-embedding-3-small", input=question, ).data[0].embedding results = self.collection.query( query_embeddings=[embedding], n_results=1, where={"model": model}, ) if results["distances"] and results["distances"][0]: distance = results["distances"][0][0] similarity = 1 - distance # Chroma використовує косинусну відстань if similarity >= self.similarity_threshold: answer = results["documents"][0][0] return {"answer": answer, "cache_type": "semantic", "similarity": similarity} return None def set(self, question: str, answer: str, model: str): # Exact cache у Redis exact_key = f"llm:exact:{hashlib.md5(f'{question}:{model}'.encode()).hexdigest()}" self.redis.setex(exact_key, self.exact_ttl, answer.encode()) # Semantic cache у Chroma embedding = self.openai.embeddings.create( model="text-embedding-3-small", input=question, ).data[0].embedding self.collection.add( ids=[f"{int(time.time())}_{hash(question)}"], embeddings=[embedding], documents=[answer], metadatas=[{"model": model, "question": question, "created_at": time.time()}], ) Як виміряти ефективність кешу?
Для оцінки впроваджуємо метрики: hit rate, latency p95, cost per request. Типові показники: exact hit 35%, semantic hit 28%, середня latency знижується з 2.3 с до 0.4 с. Для моніторингу використовуємо дашборди з алертами при падінні hit rate нижче порогу. Поріг косинусної схожості 0.92 обраний емпірично — він мінімізує false positives, зберігаючи до 95% релевантних збігів. При порозі 0.95 hit rate падає на 12%, при 0.90 — зростає кількість невірних відповідей.
Кейс нашого клієнта: FAQ-бот на 5000 запитів/день
Ми впровадили для клієнта (сервіс технічної підтримки) комбінований exact та semantic кеш LLM. До впровадження всі запити йшли напряму в GPT-4o. Наша команда (10+ років досвіду, понад 50 проєктів) налаштувала рішення. Результати:
| Метрика | До кешу | Після кешу |
|---|---|---|
| Витрати на LLM | 100% | 37% |
| Економія | — | $8,000/міс |
| Середня latency | 2.3 сек | 0.4 сек |
| Exact hit rate | 0% | 35% |
| Semantic hit rate | 0% | 28% |
Економія 63% (до $8,000 на місяць) — лише за рахунок кешування, без зміни моделі. Отримайте консультацію інженера — розрахуємо потенційну економію для вашого проєкту.
Що входить у нашу роботу
- Аналітика — аудит ваших запитів, виявлення патернів, розрахунок потенційного hit rate.
- Архітектура — вибір стеку (Redis / Chroma / Qdrant), проектування схеми кешу.
- Реалізація — написання production-коду (Python, інтеграція з вашим LLM-провайдером).
- Тестування — A/B тест із заміром latency та cost на ваших даних.
- Моніторинг — дашборд hit rate, dashboard latency, алерти при падінні ефективності.
- Документація та навчання — передача коду, інструкції, навчання команди.
Терміни орієнтовно
• Exact cache (Redis): 0.5–1 день • Semantic cache (Chroma + embeddings): 2–3 дні • Повне production-рішення з моніторингом: 1 тиждень
Гарантуємо стабільну роботу кешу, підтримку після впровадження та прозору звітність. Замовте аудит вашого проєкту — оцінимо hit rate та економію за 1 день.