0Pricing
AI Engineering Academy · Lekcja

Buforowanie prefiksów promptów OpenAI

Wykorzystaj automatyczne buforowanie promptów OpenAI, które obniża o 50% koszt powtarzanych, długich prefiksów promptów systemowych, i konstruuj prompty tak, aby maksymalizować trafienia w pamięci podręcznej.

Buforowanie prefiksów promptów OpenAI to bezpłatna lekcja AI Engineering Academy na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AI Engineering Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AI Engineering Academy zawiera 4 lekcji w sumie.

Czym jest buforowanie prefiksów promptów?

Buforowanie prefiksów promptów to wbudowana w API OpenAI optymalizacja po stronie serwera, która automatycznie obniża cenę tokenów znajdujących się w prefiksie promptu, jeśli wystąpiły one w niedawnym wcześniejszym żądaniu. W przeciwieństwie do buforowania na poziomie aplikacji, które zwraca zapisaną odpowiedź, buforowanie prefiksów promptów nadal wywołuje model — ale dla buforowanej części prefiksu obowiązuje cena tokenów wejściowych niższa o 50 procent. Zmniejsza to koszty bez rezygnowania ze świeżo generowanych odpowiedzi.

Jak działa buforowanie prefiksów od środka

Współczesne LLM-y reprezentują prompty jako pamięci podręczne KV (key-value) w pamięci GPU. Przetwarzanie promptu polega na obliczeniu kluczy i wartości mechanizmu uwagi dla każdego tokenu. Jeśli pierwsze N tokenów dwóch kolejnych żądań jest identyczne, OpenAI może ponownie użyć pamięci KV z pierwszego żądania, pomijając kosztowne obliczenia dla tych tokenów. API wykonuje to automatycznie i w sposób niewidoczny — gdy buforowanie ma zastosowanie, płacą Państwo po prostu niższą stawkę za buforowane tokeny.

# No code changes needed to enable prefix caching!
# It is automatic on supported models.

# The API response shows you how many tokens were cached:
# response.usage.prompt_tokens_details.cached_tokens

# Example response usage:
# ChatCompletionUsage(
#   prompt_tokens=2048,
#   completion_tokens=256,
#   total_tokens=2304,
#   prompt_tokens_details=PromptTokensDetails(
#     cached_tokens=1984,   # these tokens were served from KV cache
#     audio_tokens=0,
#   )
# )

Sprawdzanie trafienia pamięci podręcznej w odpowiedzi

Po każdym wywołaniu API należy sprawdzić response.usage.prompt_tokens_details.cached_tokens, aby zobaczyć, ile tokenów wejściowych zostało obsłużonych z pamięci KV. Jeśli cached_tokens > 0, za te tokeny zapłacono według stawki niższej o 50 procent. Rejestrowanie tej wartości pozwala śledzić rzeczywistą wydajność pamięci podręcznej i z czasem obliczać oszczędności wynikające z buforowania prefiksów.

from openai import OpenAI

client = OpenAI()

SYSTEM_PROMPT = 'You are an expert AI engineer assistant. ' * 100  # long system prompt

def call_with_cache_check(user_message: str):
    response = client.chat.completions.create(
        model='gpt-4o-mini',
        messages=[
            {'role': 'system', 'content': SYSTEM_PROMPT},
            {'role': 'user', 'content': user_message},
        ],
    )
    usage = response.usage
    cached = usage.prompt_tokens_details.cached_tokens if usage.prompt_tokens_details else 0
    print(f'Total prompt tokens: {usage.prompt_tokens}')
    print(f'Cached tokens: {cached} ({100*cached//usage.prompt_tokens}%)')
    return response.choices[0].message.content

Prefiks musi być dokładnie identyczny

Buforowanie prefiksów ma zastosowanie tylko wtedy, gdy pierwsze N tokenów jest identyczne bajt po bajcie z niedawnym wcześniejszym żądaniem. Nawet pojedyncza zmiana znaku w prompcie systemowym unieważnia pamięć podręczną. OpenAI buforuje dane w blokach po 128 tokenów — pamięć podręczna ma zastosowanie do kompletnych bloków, które dokładnie się zgadzają. Oznacza to, że część promptu zmieniająca się w każdym żądaniu powinna znajdować się za długim, stabilnym prefiksem, aby zmaksymalizować liczbę buforowanych tokenów.

# Optimal structure for prefix caching:
# [LONG STABLE SYSTEM PROMPT] [CACHED DOCUMENTS] [USER QUERY]
#         ↑                              ↑                ↑
#    always same               always same         varies per request
#    → cached at 50%           → cached at 50%     → not cached, full price

# BAD structure (defeats prefix caching):
# [USER QUERY] [CACHED DOCUMENTS] [LONG STABLE SYSTEM PROMPT]
#       ↑                                       ↑
#  changes every request                 never cached because
#  so prefix never matches               it comes after the query

Strukturyzowanie promptów pod kątem maksymalnej wydajności pamięci podręcznej

Aby zmaksymalizować współczynnik trafień, należy tak strukturyzować prompty, aby stabilne części znajdowały się na początku. W systemie RAG: (1) prompt systemowy z instrukcjami i personą, (2) pobrane dokumenty, które zmieniają się tylko wtedy, gdy zapytanie ulega istotnej zmianie, (3) historia konwersacji, (4) zapytanie użytkownika na samym końcu. Sam prompt systemowy — często zawierający 500–2000 tokenów — będzie zazwyczaj buforowany, co pozwoli zaoszczędzić 25–50 procent kosztów tokenów wejściowych.

def build_rag_prompt_for_caching(
    system_prompt: str,
    retrieved_docs: list[str],
    conversation_history: list[dict],
    user_query: str,
) -> list[dict]:
    # Order: stable → semi-stable → variable
    context_block = '\n\n'.join(
        f'[Document {i+1}]\n{doc}' for i, doc in enumerate(retrieved_docs)
    )
    return [
        # 1. Stable system prompt (always cached after first request)
        {'role': 'system', 'content': system_prompt},
        # 2. Context injection as a user message (cached when same docs retrieved)
        {'role': 'user', 'content': f'Context documents:\n{context_block}'},
        {'role': 'assistant', 'content': 'I have read the documents.'},
        # 3. Conversation history (semi-stable)
        *conversation_history,
        # 4. Current user query (always different → never cached prefix)
        {'role': 'user', 'content': user_query},
    ]

Czas przechowywania i eksmisja z pamięci podręcznej

Pamięć podręczna KV OpenAI jest utrzymywana w pamięci GPU i ma określoną politykę eksmisji. Prefiksy, które nie zostały ponownie użyte przez około 5–10 minut, są usuwane, gdy inne żądania zajmują pamięć GPU. Oznacza to, że korzyści z buforowania prefiksów są największe w aplikacjach o dużej przepustowości, w których często pojawiają się żądania współdzielące ten sam prefiks. Aplikacje o małym ruchu mogą odnotować niewiele trafień, ponieważ prefiks jest usuwany między oddalonymi w czasie żądaniami.

Obsługiwane modele i ceny

W 2025 roku buforowanie prefiksów promptów jest dostępne w modelach GPT-4o, GPT-4o-mini, o1 i o3-mini. Cena buforowanych tokenów wynosi 50 procent standardowej ceny tokenów wejściowych w przypadku większości modeli. Minimalna długość prefiksu, który można buforować, to 1024 tokeny — krótsze prefiksy nie otrzymują zniżki. Należy zawsze sprawdzać stronę cenową OpenAI, aby poznać aktualne stawki, ponieważ ceny zmieniają się wraz z rozwojem tej funkcji.

# Rough pricing reference (verify at platform.openai.com/pricing)
PRICING = {
    'gpt-4o': {
        'input_per_1M': 2.50,
        'cached_input_per_1M': 1.25,   # 50% off
        'output_per_1M': 10.00,
    },
    'gpt-4o-mini': {
        'input_per_1M': 0.15,
        'cached_input_per_1M': 0.075,  # 50% off
        'output_per_1M': 0.60,
    },
}

def estimate_cost_with_caching(prompt_tokens, cached_tokens, output_tokens, model):
    p = PRICING[model]
    uncached = (prompt_tokens - cached_tokens) * p['input_per_1M'] / 1_000_000
    cached_cost = cached_tokens * p['cached_input_per_1M'] / 1_000_000
    output_cost = output_tokens * p['output_per_1M'] / 1_000_000
    return uncached + cached_cost + output_cost

Buforowanie promptów w Anthropic

Anthropic oferuje podobną funkcję o nazwie prompt caching dla modeli Claude, ale wymaga ona jawnego włączenia przez oznaczenie punktów podziału pamięci podręcznej w prompcie za pomocą pola cache_control. W przeciwieństwie do automatycznego buforowania OpenAI, użytkownik jawnie wskazuje, które części promptu powinny być buforowane (maksymalnie 4 punkty podziału pamięci podręcznej na żądanie). Buforowane tokeny kosztują 10 procent standardowej ceny tokenów wejściowych i są przechowywane przez 5 minut.

import anthropic

client = anthropic.Anthropic()

LONG_DOCUMENT = 'This is a very long reference document...' * 500  # 2000+ tokens

response = client.messages.create(
    model='claude-sonnet-4-5',
    max_tokens=1024,
    system=[
        {
            'type': 'text',
            'text': 'You are a helpful assistant.',
        },
        {
            'type': 'text',
            'text': LONG_DOCUMENT,
            'cache_control': {'type': 'ephemeral'},  # mark for caching
        }
    ],
    messages=[{'role': 'user', 'content': 'Summarize the document.'}],
)
print(response.usage.cache_read_input_tokens)   # tokens served from cache
print(response.usage.cache_creation_input_tokens)  # tokens written to cache

Łączenie buforowania prefiksów z buforowaniem na poziomie aplikacji

Buforowanie prefiksów i buforowanie na poziomie aplikacji są uzupełniające się. Buforowanie prefiksów zmniejsza koszt każdego wywołania API, ale nadal wywołuje LLM. Dokładne i semantyczne pamięci podręczne na poziomie aplikacji całkowicie eliminują wywołania API w przypadku powtarzających się zapytań. Buforowanie prefiksów należy stosować dla wszystkich żądań, aby zmniejszyć koszt danych wejściowych pojedynczego wywołania, a na nim umieścić buforowanie na poziomie aplikacji, aby całkowicie eliminować wywołania w przypadku często powtarzających się zapytań. Łącznie mogą one zmniejszyć koszty infrastruktury AI o 60–80 procent.

# Three-layer cost optimization stack
#
# Layer 1: Exact cache (Redis, hash-based)
#   → Eliminates 100% of API cost for identical requests
#   → Miss rate: ~60-80% (most queries are unique)
#
# Layer 2: Semantic cache (vector similarity)
#   → Eliminates 100% of API cost for semantically similar requests
#   → Miss rate: ~40-60% of remaining queries
#
# Layer 3: OpenAI prefix caching (automatic)
#   → Reduces input token cost by 50% for long stable prefixes
#   → Applies to ALL remaining API calls that escape layers 1 and 2
#
# Combined effect: 60-80% cost reduction in FAQ/support applications

Pomiar wydajności pamięci podręcznej

Należy śledzić współczynnik efektywności pamięci podręcznej jako metrykę złożoną: całkowitą liczbę tokenów po pełnej cenie podzieloną przez całkowitą liczbę faktycznie rozliczonych tokenów. Uwzględnia to wszystkie warstwy buforowania. Należy rejestrować cached_tokens z każdej odpowiedzi API i sumować te wartości co tydzień. System, w którym buforowanych jest 50 procent tokenów we wszystkich wywołaniach API, skutecznie zmniejsza o połowę koszty tokenów wejściowych bez konieczności wprowadzania zmian w kodzie aplikacji, aby korzystać z buforowania prefiksów.

from dataclasses import dataclass, field
from typing import ClassVar

@dataclass
class CachingMetrics:
    total_prompt_tokens: int = 0
    total_cached_tokens: int = 0
    app_cache_hits: int = 0
    app_cache_misses: int = 0

    @property
    def prefix_cache_ratio(self) -> float:
        if self.total_prompt_tokens == 0:
            return 0
        return self.total_cached_tokens / self.total_prompt_tokens

    @property
    def app_cache_hit_rate(self) -> float:
        total = self.app_cache_hits + self.app_cache_misses
        return self.app_cache_hits / total if total > 0 else 0

    def report(self):
        print(f'App cache hit rate: {self.app_cache_hit_rate:.1%}')
        print(f'Prefix cache ratio: {self.prefix_cache_ratio:.1%}')
        savings_multiplier = (1 - self.app_cache_hit_rate) * (1 - 0.5 * self.prefix_cache_ratio)
        print(f'Effective cost vs no-cache: {savings_multiplier:.1%}')

Kiedy buforowanie prefiksów nie pomaga

Buforowanie prefiksów nie przynosi korzyści w przypadku: (1) krótkich promptów mających mniej niż 1024 tokeny (minimalna długość możliwa do buforowania), (2) bardzo zmiennych prefiksów, gdy prompt systemowy zmienia się dla każdego użytkownika lub żądania, (3) aplikacji o małym ruchu, w których pamięć KV jest usuwana między żądaniami, lub (4) sytuacji, gdy już płacą Państwo minimalną stawkę za tokeny. W takich przypadkach należy skupić działania optymalizacyjne na semantycznym buforowaniu na poziomie aplikacji.

Szybki test

Sprawdź swoją wiedzę na temat buforowania prefiksów promptów OpenAI z tej lekcji.

Podsumowanie lekcji

W tej lekcji dowiedział się Pan / dowiedziała się Pani, że buforowanie prefiksów promptów OpenAI automatycznie obniża o 50 procent cenę buforowanych tokenów wejściowych, gdy prefiks promptu pasuje do niedawnego wcześniejszego żądania; stabilna zawartość musi znajdować się na początku struktury wiadomości (prompt systemowy, dokumenty, a następnie zapytanie użytkownika), aby zmaksymalizować liczbę buforowanych tokenów; a Anthropic wymaga jawnych znaczników cache_control w podobnej funkcji dla modeli Claude. Połączenie tej funkcji z buforowaniem na poziomie aplikacji zapewnia maksymalne obniżenie kosztów. Następnie omówimy przetwarzanie wsadowe, routing modeli i pulpity kosztów, aby uzupełnić zestaw narzędzi optymalizacyjnych.

Często zadawane pytania

Czy lekcja „Buforowanie prefiksów promptów OpenAI” jest bezpłatna?

Tak — pełny tekst „Buforowanie prefiksów promptów OpenAI” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AI Engineering Academy, przejdź na CoddyKit PRO. Kurs AI Engineering Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Buforowanie prefiksów promptów OpenAI”?

Wykorzystaj automatyczne buforowanie promptów OpenAI, które obniża o 50% koszt powtarzanych, długich prefiksów promptów systemowych, i konstruuj prompty tak, aby maksymalizować trafienia w pamięci po… Ćwiczysz AI Engineering Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć AI Engineering Academy?

Nie wymagamy żadnego doświadczenia. AI Engineering Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Buforowanie prefiksów promptów OpenAI”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji AI Engineering Academy?

Tak. Każda lekcja AI Engineering Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Dokładne buforowanie za pomocą Redis
  2. Buforowanie semantyczne z embeddingami
  3. Buforowanie prefiksów promptów OpenAI
  4. Batchowanie, routing modeli i pulpity kosztów
← Powrót do AI Engineering Academy