Infrastruktur Prompt Caching: Mengurangi Biaya dan Latensi LLM

Diperbarui 11 Desember 2025

Pembaruan Desember 2025: Prefix caching Anthropic memberikan pengurangan biaya 90% dan pengurangan latensi 85% untuk prompt panjang. Caching otomatis OpenAI diaktifkan secara default (penghematan biaya 50%). 31% query LLM menunjukkan kesamaan semantik—inefisiensi besar tanpa caching. Cache reads seharga $0,30/M token vs $3,00/M fresh (Anthropic). Arsitektur caching multi-tier (semantic → prefix → inference) memaksimalkan penghematan.

Prompt caching Anthropic mengurangi biaya hingga 90% dan latensi hingga 85% untuk prompt panjang.¹ OpenAI mencapai pengurangan biaya 50% dengan caching otomatis yang diaktifkan secara default. Penelitian menunjukkan 31% query LLM memiliki kesamaan semantik dengan request sebelumnya, mewakili inefisiensi besar dalam deployment tanpa infrastruktur caching.² Organisasi yang menjalankan aplikasi AI produksi kehilangan banyak uang tanpa strategi caching yang tepat.

Prompt caching beroperasi di berbagai level—dari prefix caching sisi provider yang menggunakan kembali komputasi KV cache, hingga semantic caching level aplikasi yang mengembalikan respons sebelumnya untuk query serupa. Memahami setiap lapisan dan kapan menggunakannya membantu organisasi mengoptimalkan biaya dan latensi untuk pola workload spesifik mereka.

Dasar-dasar caching

Biaya inferensi LLM berasal dari dua sumber: memproses token input dan menghasilkan token output. Strategi caching menargetkan keduanya:

Input token caching (prefix caching)

Setiap request LLM memproses token input melalui mekanisme attention model, menghasilkan key-value pairs yang disimpan di KV cache. Ketika beberapa request berbagi prefix identik—system prompt, few-shot examples, atau konteks dokumen—komputasi KV cache berulang secara tidak perlu.

Solusi prefix caching: Simpan nilai KV yang sudah dihitung untuk prefix umum. Request berikutnya dengan prefix yang cocok melewati rekomputasi, dimulai dari state yang sudah di-cache.

Dampak biaya: - Anthropic: Cache reads seharga $0,30/M token vs. $3,00/M untuk pemrosesan fresh (penghematan 90%) - OpenAI: Diskon 50% untuk token yang di-cache - Google: Harga variabel berdasarkan context window

Dampak latensi: Melewati komputasi prefix mengurangi time-to-first-token sebesar 50-85% tergantung panjang prefix.

Output caching (semantic caching)

Beberapa request layak mendapat respons identik—pertanyaan berulang, query deterministik, atau lookup yang tidak memerlukan regenerasi.

Solusi semantic caching: Simpan output respons dengan key berdasarkan input yang serupa secara semantik. Kembalikan respons yang di-cache tanpa pemanggilan LLM untuk query yang cocok.

Dampak biaya: Respons yang di-cache mengeliminasi panggilan API sepenuhnya—penghematan 100% pada cache hit.

Dampak latensi: Respons kembali dalam milidetik versus detik untuk inferensi LLM.

Hierarki caching

Sistem produksi biasanya mengimplementasikan beberapa lapisan caching:

Request → Semantic Cache (penghematan 100%) → Prefix Cache (penghematan 50-90%) → Full Inference
              ↓                                  ↓                              ↓
         Respons cached              KV state cached              Komputasi fresh

Setiap lapisan menangkap peluang optimisasi berbeda berdasarkan pola kesamaan request.

Prompt caching level provider

Anthropic Claude

Anthropic menawarkan prompt caching yang paling dapat dikonfigurasi:³

Harga: - Cache writes: Premium 25% di atas harga input dasar - Cache reads: Diskon 90% (10% dari harga dasar) - Break-even: 2+ cache hit per prefix yang di-cache

Persyaratan: - Minimum 1.024 token per cache checkpoint - Hingga 4 cache checkpoint per request - Cache lifetime: 5 menit dari akses terakhir (diperpanjang hingga 1 jam dengan hit reguler) - Hingga 5 conversation turn dapat di-cache

Implementasi:

import anthropic

client = anthropic.Anthropic()

# Tandai konten untuk caching dengan cache_control
response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are an expert assistant for our enterprise software...",
            "cache_control": {"type": "ephemeral"}  # Tandai untuk caching
        }
    ],
    messages=[{"role": "user", "content": "How do I configure user permissions?"}]
)

Praktik terbaik: - Tempatkan konten statis (system prompt, dokumentasi) di awal prompt - Tempatkan konten dinamis (input pengguna, percakapan) di akhir - Gunakan cache checkpoint di batas natural - Monitor cache hit rate untuk memverifikasi optimisasi

OpenAI

OpenAI mengimplementasikan caching otomatis tanpa perubahan kode:⁴

Harga: - Token yang di-cache: 50% dari harga input dasar - Tidak ada premium cache write

Persyaratan: - Minimum 1.024 token untuk kelayakan caching - Cache hit terjadi dalam increment 128 token - Cache lifetime: 5-10 menit ketidakaktifan

Perilaku otomatis: - Prompt melebihi 1.024 token otomatis di-cache - Sistem mendeteksi prefix yang cocok antar request - Tidak perlu perubahan API

Monitoring:

response = client.chat.completions.create(
    model="gpt-4-turbo",
    messages=[...],
)

# Periksa usage untuk cache hit
print(f"Cached tokens: {response.usage.prompt_tokens_details.cached_tokens}")
print(f"Total input tokens: {response.usage.prompt_tokens}")

Google Gemini

Google menyediakan context caching untuk model Gemini:⁵

Harga: - Variabel berdasarkan ukuran konteks yang di-cache dan durasi - Biaya penyimpanan untuk konten yang di-cache

Fitur: - Pembuatan dan manajemen cache eksplisit - Time-to-live yang dapat dikonfigurasi - Cache sharing antar request

Implementasi:

from google.generativeai import caching

# Buat cached content
cache = caching.CachedContent.create(
    model='models/gemini-1.5-pro-001',
    display_name='product-documentation',
    system_instruction="You are a product expert...",
    contents=[product_docs],
    ttl=datetime.timedelta(hours=1)
)

# Gunakan cached content dalam request
model = genai.GenerativeModel.from_cached_content(cached_content=cache)
response = model.generate_content("How do I configure feature X?")

Amazon Bedrock

AWS menawarkan prompt caching dalam preview untuk model yang didukung:⁶

Persyaratan: - Claude 3.5 Sonnet memerlukan minimum 1.024 token per checkpoint - Checkpoint kedua memerlukan 2.048 token

Pola implementasi mengikuti pendekatan cache_control Anthropic dalam struktur API Bedrock.

vLLM prefix caching

Inferensi self-hosted dengan vLLM menyertakan prefix caching otomatis:⁷

Arsitektur

Automatic Prefix Caching (APC) vLLM menyimpan KV block dalam hash table, memungkinkan cache reuse tanpa struktur tree:

Desain utama: - Semua KV block disimpan di block pool saat inisialisasi - Lookup berbasis hash untuk prefix matching - Operasi O(1) untuk manajemen block - Efisiensi memori PagedAttention dipertahankan

Konfigurasi

from vllm import LLM

llm = LLM(
    model="meta-llama/Llama-3.1-8B-Instruct",
    enable_prefix_caching=True,  # Aktifkan APC
    gpu_memory_utilization=0.90,
)

Dampak performa

vLLM dengan PagedAttention menunjukkan throughput 14-24x lebih tinggi daripada implementasi naive.⁸ Prefix caching menambahkan:

• Perbedaan biaya 10x antara token cached dan uncached
• Pengurangan latensi seorde magnitude untuk prefix yang cocok
• Efisiensi memori melalui shared KV block

Pertimbangan keamanan

vLLM mendukung isolasi cache untuk environment bersama:

# Cache salt per-request mencegah akses cache lintas tenant
response = llm.generate(
    prompt="...",
    sampling_params=SamplingParams(...),
    cache_salt="tenant-123"  # Isolasi cache berdasarkan tenant
)

Injeksi cache salt ke dalam block hash mencegah timing attack di mana adversary menyimpulkan konten yang di-cache melalui observasi latensi.

Ekstensi LMCache

LMCache memperluas vLLM dengan kemampuan caching lanjutan:⁹

Fitur: - KV cache reuse antar instance engine - Penyimpanan multi-tier (GPU → CPU RAM → disk) - Caching konten non-prefix - Pengurangan latensi 3-10x dalam benchmark

Arsitektur:

vLLM Engine → LMCache → GPU VRAM (hot)
                     → CPU RAM (warm)
                     → Local Disk (cold)

Semantic caching

Semantic caching mengembalikan respons sebelumnya untuk query yang serupa secara semantik (bukan hanya identik):

GPTCache

GPTCache menyediakan semantic caching open-source untuk aplikasi LLM:¹⁰

Arsitektur:

Query → Embedding → Vector Search → Similarity Check → Response/API Call
              ↓           ↓              ↓
         BERT/OpenAI   Milvus/FAISS   Threshold (0.8)

Komponen: - LLM Adapter: Integrasi dengan berbagai provider LLM - Embedding Generator: Vektorisasi query - Vector Store: Similarity search (Milvus, FAISS, Zilliz) - Cache Manager: Penyimpanan dan pengambilan - Similarity Evaluator: Pencocokan berbasis threshold

Implementasi:

from gptcache import cache
from gptcache.adapter import openai

# Inisialisasi semantic cache
cache.init(
    pre_embedding_func=get_text_embedding,
    data_manager=manager,
)

# Gunakan panggilan OpenAI yang di-cache
response = openai.ChatCompletion.create(
    model='gpt-4',
    messages=[{"role": "user", "content": "What is machine learning?"}]
)
# Query yang serupa secara semantik ("Explain ML", "Define machine learning")
# mengembalikan respons yang di-cache

Performa

GPTCache mencapai peningkatan efisiensi signifikan:¹¹

• Pengurangan panggilan API: Hingga 68,8% di seluruh kategori query
• Cache hit rate: 61,6% hingga 68,8%
• Akurasi: 97%+ positive hit rate
• Pengurangan latensi: 40-50% pada cache hit, hingga 100x untuk full hit

Teknik lanjutan

VectorQ adaptive threshold:¹²

Similarity threshold statis (misalnya, 0.8) berkinerja buruk di seluruh query yang beragam. VectorQ mempelajari region threshold spesifik embedding yang beradaptasi dengan kompleksitas query:

• Query faktual sederhana: Threshold lebih tinggi (pencocokan lebih ketat)
• Query open-ended: Threshold lebih rendah (lebih banyak reuse)
• Query ambigu: Penyesuaian dinamis

Deteksi pola SCALM:

SCALM meningkatkan GPTCache melalui deteksi pola dan analisis frekuensi: - Peningkatan 63% dalam cache hit ratio - Pengurangan 77% dalam penggunaan token - Mengidentifikasi pola cache entry frekuensi tinggi

Kapan menggunakan semantic caching

Kandidat bagus: - Query bergaya FAQ dengan ruang jawaban terbatas - Query lookup (info produk, dokumentasi) - Respons deterministik (kalkulasi, formatting) - Aplikasi traffic tinggi dengan pengulangan query

Kandidat buruk: - Generasi kreatif yang memerlukan keunikan - Respons yang dipersonalisasi (konteks spesifik pengguna) - Informasi sensitif waktu - Pola query dengan pengulangan rendah

Pola implementasi

Aplikasi chat

Sistem chat mendapat manfaat dari prefix dan semantic caching:

System prompt caching:

# System prompt statis di-cache di awal request
system_prompt = """
You are a customer support agent for Acme Corp...
[2000+ token panduan dan pengetahuan]
"""

# Percakapan dinamis ditambahkan setelah prefix yang di-cache
messages = [
    {"role": "system", "content": system_prompt, "cache_control": {...}},
    {"role": "user", "content": user_message}
]

Conversation history caching: Anthropic mendukung caching hingga 5 conversation turn, mengurangi biaya untuk percakapan multi-turn.

Aplikasi RAG

Retrieval-augmented generation meng-cache konteks yang diambil:

# Struktur cache untuk RAG
cached_context = {
    "system": system_prompt,           # Selalu di-cache
    "documents": retrieved_chunks,      # Cache per cluster query
    "examples": few_shot_examples       # Stabil antar request
}

# Hanya query pengguna yang bervariasi
dynamic_content = {
    "query": user_question
}

Document chunk caching: Ketika beberapa query mengambil dokumen yang sama, prefix caching mengeliminasi pemrosesan berlebihan dari konteks bersama.

Workflow agentic

Sistem agent dengan tool calling mendapat manfaat dari prefix caching:

System prompt → Tool definitions → Conversation history → Current query
    (cached)       (cached)           (sebagian di-cache)      (fresh)

Caching definisi tool: Deskripsi tool sering kali memiliki ribuan token. Caching prefix ini mengurangi biaya secara signifikan untuk sistem agentic.

Aplikasi batch processing

Request batch dengan konteks bersama mendapat manfaat maksimal:

# Proses banyak dokumen dengan instruksi bersama
base_prompt = """
Extract the following fields from each document:
- Company name
- Revenue figures
- Key personnel
[Instruksi ekstraksi mendetail - 3000+ token]
"""

# Setiap dokumen berbagi prefix yang di-cache
for doc in documents:
    response = process_with_cached_prefix(base_prompt, doc)

Strategi optimisasi

Pengurutan konten prompt

Susun prompt untuk cache hit maksimum:

┌─────────────────────────────────────────┐
│ System prompt (statis, selalu di-cache)  │
├─────────────────────────────────────────┤
│ Tool definitions (statis)                │
├─────────────────────────────────────────┤
│ Few-shot examples (semi-statis)          │
├─────────────────────────────────────────┤
│ Retrieved context (bervariasi per cluster)│
├─────────────────────────────────────────┤
│ Conversation history (bervariasi)        │
├─────────────────────────────────────────┤
│ Current query (selalu bervariasi)        │
└─────────────────────────────────────────┘

Konten yang lebih stabil di awal memaksimalkan panjang prefix yang dapat di-cache.

Monitoring cache

Lacak metrik untuk memvalidasi efektivitas caching:

Metrik utama: - Cache hit rate (target: >60% untuk workload yang sesuai) - Penghematan biaya vs. request non-cached - Pengurangan latensi pada cache hit - Distribusi panjang cache

Contoh implementasi:

class CacheMetrics:
    def __init__(self):
        self.hits = 0
        self.misses = 0
        self.tokens_saved = 0

    def record(self, response):
        cached = response.usage.prompt_tokens_details.cached_tokens
        total = response.usage.prompt_tokens

        if cached > 0:
            self.hits += 1
            self.tokens_saved += cached
        else:
            self.misses += 1

    @property
    def hit_rate(self):
        total = self.hits + self.misses
        return self.hits / total if total > 0 else 0

Manajemen cache lifetime

Strategi berdasarkan pola akses: - Traffic tinggi: Cache warm secara natural melalui penggunaan - Traffic sporadis: Implementasikan cache warming terjadwal - Request burst: Pre-warm cache sebelum beban puncak yang diharapkan

Contoh cache warming:

async def warm_cache(common_prefixes: list[str]):
    """Pre-warm cache dengan prefix umum"""
    for prefix in common_prefixes:
        await client.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=1,  # Token output minimum
            system=[{
                "type": "text",
                "text": prefix,
                "cache_control": {"type": "ephemeral"}
            }],
            messages=[{"role": "user", "content": "warmup"}]
        )

Caching multi-tenant

Untuk aplikasi yang melayani banyak tenant:

Shared cache (ketika sesuai): - Prompt sistem umum - Definisi tool umum - Konten referensi bersama

Cache per-tenant: - Data spesifik pelanggan - Instruksi khusus - Informasi sensitif

Implementasi:

def get_cache_key(tenant_id: str, content_type: str) -> str:
    if content_type in ["system_prompt", "tool_definitions"]:
        return f"shared:{content_type}"  # Cache bersama
    return f"tenant:{tenant_id}:{content_type}"  # Isolasi

Analisis biaya

Perhitungan break-even

Formula break-even Anthropic:

cache_write_cost = base_input_price × 1.25
cache_read_cost = base_input_price × 0.10
fresh_cost = base_input_price × 1.00

break_even_hits = cache_write_cost / (fresh_cost - cache_read_cost)
                = 1.25 / (1.00 - 0.10)
                = 1.39 hits

Dengan 2+ cache hit, prefix caching menghemat uang.

Contoh skenario

Skenario: Chatbot customer support - System prompt: 2.000 token - Rata-rata percakapan: 500 token - Request harian: 10.000 - Cache hit rate: 70%

Tanpa caching:

2.500 token × 10.000 request × $3/M = $75/hari

Dengan prefix caching (Anthropic):

Cache miss (30%): 2.500 × 3.000 × $3/M = $22.50
Cache hits (70%):
  - Cached portion: 2.000 × 7.000 × $0.30/M = $4.20
  - Fresh portion: 500 × 7.000 × $3/M = $10.50
Total: $37.20/hari (penghematan 50%)

Dengan semantic caching tambahan:

Semantic hits (20% dari total): Dilewati sepenuhnya
Prefix cache hits (50%): Perhitungan di atas
Fresh request (30%): Perhitungan di atas
Estimasi penghematan: 60-70%

Trade-off dan batasan

Trade-off prefix caching

Keuntungan: - Pengurangan biaya transparan - Tidak mempengaruhi kualitas respons - Overhead implementasi minimal

Batasan: - Hanya bekerja untuk prefix yang tepat sama - Benefit terbatas untuk prompt pendek (<1.024 token) - Expiry cache memerlukan manajemen

Trade-off semantic caching

Keuntungan: - Penghematan biaya maksimum pada hit - Menangkap kemiripan query - Mengeliminasi panggilan API sepenuhnya

Risiko: - False positive mengembalikan respons salah - Tuning threshold memerlukan eksperimen - Konten basi untuk data yang berubah - Overhead infrastruktur embedding

Decision framework

┌─────────────────────────────────────────────────────────┐
│ Apakah prompt melebihi 1.024 token?                      │
│   Ya → Implementasikan prefix caching                    │
│   Tidak → Pertimbangkan apakah penggabungan request layak│
├─────────────────────────────────────────────────────────┤
│ Apakah query sering berulang atau mirip?                 │
│   Ya → Tambahkan semantic caching                        │
│   Tidak → Prefix caching saja sudah cukup               │
├─────────────────────────────────────────────────────────┤
│ Apakah respons perlu segar/dipersonalisasi?             │
│   Ya → Hindari semantic caching untuk query tersebut    │
│   Tidak → Kandidat semantic caching                     │
└─────────────────────────────────────────────────────────┘

Pertimbangan produksi

Keandalan

• Cache miss graceful: Sistem harus bekerja dengan benar ketika cache tidak tersedia
• Isolasi kegagalan: Kegagalan caching tidak boleh menurunkan performa request
• Monitoring: Alert pada anomali cache hit rate

Keamanan

• Isolasi cache: Cegah kebocoran data lintas tenant
• Pertahanan timing attack: Gunakan cache salt untuk environment bersama
• Kebijakan retensi data: Clear cache sesuai persyaratan kepatuhan

Skalabilitas

• Lokasi cache: Pertimbangkan edge caching untuk aplikasi global
• Memory management: Pantau footprint memori cache
• Strategi eviction: Implementasikan kebijakan LRU/TTL yang sesuai

Kesimpulan

Prompt caching mewakili salah satu optimisasi paling berdampak untuk deployment LLM. Benefit gabungan dari prefix caching (pengurangan biaya 50-90%) dan semantic caching (penghematan panggilan API 60%+) secara dramatis meningkatkan ekonomi aplikasi AI.

Takeaway utama: - Mulai dengan prefix caching provider-native—tidak memerlukan perubahan kode untuk OpenAI - Susun prompt dengan konten statis di awal untuk cache hit maksimum - Tambahkan semantic caching untuk workload dengan repetisi query tinggi - Monitor cache hit rate untuk memvalidasi strategi optimisasi - Pertimbangkan isolasi cache untuk aplikasi multi-tenant

Seiring model berkembang dan volume penggunaan meningkat, investasi infrastruktur caching memberikan return yang semakin besar. Organisasi yang mengimplementasikan caching komprehensif melaporkan 60-80% pengurangan biaya LLM sambil mempertahankan atau meningkatkan kinerja latensi.