How to implement semantic cache in LLMs to cut costs
Practical engineering guide to structure vector caching for LLM responses, reducing token consumption and inference latency at scale.
Summary
- Semantic cache compares the meaning of questions rather than exact string matches.
- Vector databases quickly compute mathematical similarity between text embeddings.
- Similarity thresholds prevent returning outdated or incorrect AI responses.
- This architecture drastically reduces paid calls to external language models.
- High-volume applications achieve stable performance and near-instant answers.
Why traditional caching fails with artificial intelligence
When building modern applications powered by language models, request volumes can explode rapidly, driving operational costs to unsustainable levels. Traditional caching mechanisms used in web development, based on exact keys and in-memory dictionaries, simply do not work for queries sent to AIs. If one user types 'what are your opening hours' and another asks 'when do you open', a standard system sees two completely different keys, triggering two expensive cloud requests.
In practice, this means we pay twice for processing to get the exact same underlying meaning. To solve this financial waste, software engineering adopted semantic caching, which leverages advanced concepts of natural language processing and vector memory to group similar questions together. Instead of comparing letters, we compare usage intentions through mathematical representations called embeddings.
How vectors and meaning similarity actually work
To make a computer understand that two different phrases mean the same thing, we transform the text into a long sequence of numbers known as a numerical vector. This transformation is performed by a smaller, extremely fast model that places phrases with similar meanings close together in a geometric space. Imagine a map where cities with similar cultures are geographically close; text works in the exact same way.
When a new question arrives at our server, the system calculates its vector and performs a quick query in a specialized vector database like Redis or Milvus. If the mathematical distance between the new question and a previously answered one is below a safe threshold, we avoid calling the main model and return the cached text. This mechanism turns milliseconds of waiting into direct infrastructure savings.
Practical architecture of the caching flow in production
Developing a semantic caching layer requires a shift in application backend architecture. Before sending any structured JSON payload or request to an external API, the request passes through an interception middleware. This middleware generates the question vector and queries the local vector database to check if a valid response is stored.
If the system finds a high-similarity match, the response is delivered instantly to the client, saving precious pennies per consumed token. If there is no match, the normal flow proceeds, the large model's response is generated, and both the question and answer are written to the vector database for future users. It is a continuous cycle of learning and savings that operates without human intervention.
Implementing the search and validation algorithm
To illustrate the logic behind this verification, we can look at a Python code snippet that performs cosine similarity searches. This mathematical metric evaluates the angle between two vectors to determine how close they are, normally ranging from zero to one. Below, we show how this check is structured cleanly before deciding whether to use or bypass the cache.
import numpy as np
def calculate_similarity(vector_a, vector_b):
dot_product = np.dot(vector_a, vector_b)
norm_a = np.linalg.norm(vector_a)
norm_b = np.linalg.norm(vector_b)
if norm_a == 0 or norm_b == 0:
return 0.0
return dot_product / (norm_a * norm_b)
acceptance_threshold = 0.92
current_question = [0.12, 0.45, 0.88]
cached_question = [0.13, 0.44, 0.89]
score = calculate_similarity(current_question, cached_question)
if score >= acceptance_threshold:
print('Cache hit! Returning stored response.')
else:
print('Cache miss! Querying language model.')The acceptance threshold is the most critical parameter in this engineering design. If you set the value too low, the system will start answering different questions with incorrect responses, frustrating the end user. If you set it too high, you miss valuable cost-saving opportunities and the cache remains practically empty.
Operational challenges and handling sensitive data
Implementing this technology in high-volume environments brings complex challenges related to data consistency and information security. Questions containing sensitive personal data, such as document numbers or temporary passwords, must never be inserted into a shared cache. Otherwise, a malicious user could extract private information from other clients by asking subtly modified questions.
Furthermore, the data lifecycle inside the cache must be strictly managed, implementing time-based expiration policies or automatic updates whenever the underlying knowledge base changes. Maintaining a robust system requires constant monitoring of hit rates and the real financial impact on the artificial intelligence API bill. To explore these architectural concepts further in production, see our related technical analysis on Gemini 4 Hydrogen: What changes in the new Google AI speed?.
Final considerations on efficiency and scale
The intelligent use of vector caching transforms the financial dynamics of applications relying on large-scale artificial intelligence. By reducing end-to-end latency and eliminating wasted processing on repeated questions, companies can scale their products while maintaining healthy margins. The secret to success lies in balancing mathematical rigor in similarity with strict governance over stored data.