Artificial Intelligence

Stos LLM na produkcji: Co naprawdę działa w połowie 2026 roku

By Anurag Verma•June 5, 2026

Warstwa inferencji to wciąż otwarty problem. Przy wywołaniach na skalę agentową latencja tail percentile zabija wszystko. vLLM radzi sobie z tym lepiej niż większość alternatyw, ale nadal tracisz czas przy dużych sekwencjach KV-cache jeśli nie masz skonfigurowanego preempcji.

Retrieval: Embedding Models Have a New King

The state of the art in embedding models shifted significantly this year. OpenAI's text-embedding-3-large has been dethroned by a combination of open-source alternatives. Voyage AI's voyage-3-large is what most teams I know have moved to for production RAG. Its recall numbers on real enterprise corpora consistently outperform the OpenAI embeddings, and it's competitive on price at scale.

For teams that want to self-host embeddings, the Alibaba-NLP/gte-Qwen2-7B-instruct model on Hugging Face is the strongest open option right now. Not the most convenient, but the quality gap over smaller models is significant enough to justify the compute for high-stakes retrieval.

The hybrid search story has matured. Most production RAG systems now run dense vector search alongside BM25 sparse retrieval, with reciprocal rank fusion to combine results. If you aren't doing this, you're leaving meaningful recall gains on the table. The question isn't whether to do it; it's which BM25 implementation to use and how to weight the fusion.

Context Window: Bigger Is Not Always Better

Every major model now supports long context windows, and the temptation is to just stuff everything in and call it retrieval-free. This is wrong for a few reasons.

First, the lost-in-the-middle problem is real and has not been fully solved. Relevant information buried in the middle of a 200k token context reliably performs worse than the same information at the edges. Second, cost. A 200k token context window call is expensive in ways that don't scale. Third, latency. First-token latency scales with context length across every model family I've tested.

The correct framing is to use long context as a complement to retrieval, not a replacement. Run retrieval to narrow the search space, use long context for the cases where you genuinely need it: document comparisons, complex multi-document reasoning, anything where chunking destroys necessary relationships.

Agent Reliability: The Unsolved Problem

Agents are the most interesting and most frustrating part of the current stack. Multi-step reasoning chains work well until they don't, and the failure modes are brutal: silent errors, confident hallucinations, tool calls that succeed but do the wrong thing.

The pattern that has most improved reliability in my experience is aggressive checkpointing combined with structured output validation at each step. If a step produces a structured output you can verify, verify it before passing it forward. Don't trust the model's self-assessment of whether a step succeeded.

Tool use quality varies more by model than benchmarks suggest. Claude models have consistently been the most reliable on complex multi-tool workflows in my testing. Gemini 2.0 Flash is the cost-competitive alternative, but it requires much more careful prompt engineering to avoid tool call errors. GPT-4o sits somewhere in the middle on tool use but tends to be more verbose, which hurts latency.

Timeout handling is underrated. Set aggressive timeouts on individual tool calls and build retry logic with exponential backoff. The failure mode you're most likely to encounter at scale isn't the model making a wrong decision; it's a tool call hanging indefinitely because an external API is slow.

Cost Control: Where the Math Actually Matters

At real agentic workloads, token costs dominate. The levers are prompt caching, output length control, and model routing.

Prompt caching, specifically Anthropic's prefix caching, gives you real savings if your system prompts are long and repeated. For RAG workflows where you're prepending a large context to every call, prompt caching can cut effective input token costs by 60-80%. If you're on Anthropic's API and not using prompt caching, you're leaving money on the table.

Output length is the underappreciated lever. Models will produce as much output as you allow. Explicit output length constraints in your system prompt, combined with structured output formats, consistently reduce verbosity. A model asked to return JSON will almost always produce fewer tokens than the same model asked to respond in prose.

Model routing is the approach with the highest ceiling. The idea is to route easier subtasks to cheaper, faster models (Haiku, Flash) and reserve expensive models for steps that actually need them. The hard part is classification: knowing in advance which subtasks are "easy" enough for the cheap model. In practice, this requires running dual-model evaluations to build a routing classifier, which is significant upfront work. But at the call volumes where costs become painful, it pays off.

Observability

You cannot debug what you cannot trace. At minimum you need: per-request token counts, latency by model and endpoint, tool call success/failure rates, and a way to replay failed agent runs against a changed prompt.

LangSmith remains the most complete solution I've used despite the lock-in concern. LangFuse is a solid open-source alternative with fewer features. Rolling your own trace collection in OpenTelemetry is viable if you have the infrastructure capability and want to avoid vendor dependency.

The key metric that most people aren't tracking but should be is agent success rate at the task level, not at the step level. A chain that completes all steps but produces the wrong final output has a 100% step success rate and 0% task success rate. That gap is where the real reliability work lives.

If you're building LLM-backed features today, the baseline is higher than it was eighteen months ago, but so are the expectations. The teams that are ahead are the ones who've moved past "can we get the model to do X" to "can we do X reliably at a cost structure that makes sense." That's a systems problem, a data problem, and a product problem, and it's where most of the work actually is.

Stos LLM w produkcji: co naprawdę działa w połowie 2026 roku

Produkcyjne systemy LLM przekroczyły próg, którego większość tekstów o AI jeszcze nie odnotowała: same modele przestały być najtrudniejszą częścią układanki. Uzyskanie dobrego uzupełnienia od Claude'a 3.5 Sonnet czy Gemini 2.0 Flash to dziś absolutne minimum. Prawdziwe wyzwanie inżynierskie leży we wszystkim, co otacza model: efektywności inferencji, jakości wyszukiwania, niezawodności agentów i kontroli kosztów przy wolumenach wywołań, jakie generują rzeczywiste obciążenia agentowe.

Od osiemnastu miesięcy uruchamiam funkcje oparte na LLM w produkcji i stos zmienił się znacząco. Oto, co wiem na pewno według stanu na czerwiec 2026.

Warstwa inferencji: vLLM wygrał, na razie

Jeśli hostujesz modele samodzielnie, wybór frameworka inferencyjnego ma większe znaczenie, niż się powszechnie przyznaje. Trzy poważne opcje to vLLM, SGLang i TensorRT-LLM, przy czym każda służy innym celom. vLLM to właściwy punkt wyjścia dla niemal każdego zespołu. Obejmuje największy zakres modeli, nie wymaga etapu kompilacji i konsekwentnie zapewnia konkurencyjną przepustowość dzięki PagedAttention i ciągłemu batchowaniu. SGLang wyprzedza go przy obciążeniach ze wspólnym prefiksem, gdzie liczy się czas do pierwszego tokena, na przykład w potokach RAG poprzedzających każde zapytanie tym samym długim promptem systemowym. TensorRT-LLM wart jest zachodu tylko wtedy, gdy model jest zamrożony na miesiące i trzeba wycisnąć z niego każdy token na sekundę przy dużej skali.

TGI od HuggingFace jest oficjalnie w trybie konserwacji. Sam HuggingFace rekomenduje teraz vLLM lub SGLang. Odczytuję to jako jednoznaczny sygnał.

Warstwa inferencji to wciąż otwarty problem. Przy wywołaniach na skalę agentową latencja tail percentile niszczy wszystko. vLLM radzi sobie z tym lepiej niż większość alternatyw, ale nadal tracisz czas przy dużych sekwencjach KV-cache, jeśli nie masz skonfigurowanej wywłaszczania.

Wyszukiwanie: modele embeddingów mają nowego króla

Stan wiedzy w zakresie modeli embeddingów zmienił się w tym roku znacząco. OpenAI text-embedding-3-large zostało detronizowane przez kombinację rozwiązań open-source. Voyage AI voyage-3-large to wybór, na który przeszła większość znanych mi zespołów przy produkcyjnym RAG. Wyniki recall na rzeczywistych korpusach korporacyjnych konsekwentnie przewyższają embeddingi OpenAI, a cenowo jest konkurencyjne przy dużej skali.

Dla zespołów chcących hostować embeddingi samodzielnie, model Alibaba-NLP/gte-Qwen2-7B-instruct na Hugging Face to najsilniejsza opcja open-source dostępna teraz. Nie najwygodniejsza, ale luka jakościowa względem mniejszych modeli jest na tyle znacząca, że uzasadnia koszty obliczeniowe przy wyszukiwaniu wysokiej stawki.

Historia hybrydowego wyszukiwania dojrzała. Większość produkcyjnych systemów RAG łączy teraz gęste wyszukiwanie wektorowe z rzadkim wyszukiwaniem BM25, używając reciprocal rank fusion do łączenia wyników. Jeśli tego nie robisz, zostawiasz na stole znaczące zyski w recall. Pytanie nie brzmi, czy to robić, ale z której implementacji BM25 skorzystać i jak ważyć fuzję.

Okno kontekstowe: większe nie zawsze znaczy lepsze

Każdy duży model obsługuje teraz długie okna kontekstowe i pojawia się pokusa, by po prostu wpychać wszystko do środka i rezygnować z wyszukiwania. To błąd z kilku powodów.

Po pierwsze, problem "lost-in-the-middle" jest realny i nie został w pełni rozwiązany. Istotne informacje ukryte w środku 200 tys. tokenów kontekstu konsekwentnie wypadają gorzej niż te same informacje umieszczone na brzegach. Po drugie, koszty. Wywołanie z oknem 200 tys. tokenów jest drogie w sposób, który się nie skaluje. Po trzecie, latencja. Latencja pierwszego tokena rośnie wraz z długością kontekstu w każdej rodzinie modeli, jaką testowałem.

Właściwe podejście to traktowanie długiego kontekstu jako uzupełnienia wyszukiwania, nie jego zamiennika. Używaj wyszukiwania do zawężenia przestrzeni poszukiwań, a długiego kontekstu tam, gdzie naprawdę go potrzebujesz: do porównywania dokumentów, złożonego rozumowania wielodokumentowego, wszędzie tam, gdzie chunking niszczy niezbędne relacje.

Niezawodność agentów: nierozwiązany problem

Agenci to najbardziej fascynująca i najbardziej frustrująca część obecnego stosu. Wieloetapowe łańcuchy rozumowania działają dobrze, dopóki nie przestają, a tryby awarii są brutalne: ciche błędy, pewne siebie halucynacje, wywołania narzędzi, które kończą się sukcesem, ale robią coś złego.

Wzorzec, który w moim doświadczeniu najbardziej poprawił niezawodność, to agresywny checkpointing połączony z walidacją strukturyzowanego wyjścia na każdym etapie. Jeśli krok produkuje strukturyzowane wyjście, które można zweryfikować, zweryfikuj je przed przekazaniem dalej. Nie ufaj samoocenie modelu co do tego, czy krok się powiódł.

Jakość korzystania z narzędzi różni się między modelami bardziej, niż sugerują benchmarki. Modele Claude konsekwentnie były najbardziej niezawodne przy złożonych przepływach pracy z wieloma narzędziami w moich testach. Gemini 2.0 Flash to konkurencyjna cenowo alternatywa, ale wymaga znacznie staranniejszego prompt engineeringu, by unikać błędów wywołań narzędzi. GPT-4o plasuje się gdzieś pośrodku pod względem korzystania z narzędzi, ale ma tendencję do większej gadatliwości, co szkodzi latencji.

Obsługa timeoutów jest niedoceniana. Ustaw agresywne timeouty dla poszczególnych wywołań narzędzi i zbuduj logikę ponownych prób z wykładniczym wycofaniem. Tryb awarii, na który najczęściej natrafisz przy dużej skali, to nie model podejmujący złą decyzję, lecz wywołanie narzędzia zawieszające się w nieskończoność, bo zewnętrzne API jest wolne.

Kontrola kosztów: gdzie matematyka naprawdę ma znaczenie

Przy rzeczywistych obciążeniach agentowych koszty tokenów dominują. Dźwignie to prompt caching, kontrola długości wyjścia i routing modeli.

Prompt caching, konkretnie prefix caching Anthropica, przynosi realne oszczędności, jeśli twoje prompty systemowe są długie i powtarzające się. Dla przepływów pracy RAG, gdzie poprzedzasz każde wywołanie dużym kontekstem, prompt caching może obniżyć efektywny koszt tokenów wejściowych o 60-80%. Jeśli korzystasz z API Anthropica i nie używasz prompt cachingu, zostawiasz pieniądze na stole.

Długość wyjścia to niedoceniana dźwignia. Modele będą produkować tyle wyjścia, ile im na to pozwolisz. Jawne ograniczenia długości wyjścia w prompcie systemowym w połączeniu ze strukturyzowanymi formatami wyjścia konsekwentnie redukują gadatliwość. Model poproszony o zwrócenie JSON prawie zawsze wyprodukuje mniej tokenów niż ten sam model poproszony o odpowiedź prozą.

Routing modeli to podejście o najwyższym suficie. Idea polega na kierowaniu łatwiejszych podzadań do tańszych i szybszych modeli (Haiku, Flash) i rezerwowaniu drogich modeli dla kroków, które naprawdę ich potrzebują. Najtrudniejsza część to klasyfikacja: wiedzieć z góry, które podzadania są "wystarczająco łatwe" dla taniego modelu. W praktyce wymaga to uruchomienia dwumodelowych ewaluacji w celu zbudowania klasyfikatora routingu, co jest znaczącym nakładem pracy na starcie. Ale przy wolumenach wywołań, przy których koszty stają się bolesne, opłaca się.

Obserwability

Nie możesz debugować tego, czego nie możesz śledzić. Minimum to: liczba tokenów na żądanie, latencja według modelu i endpointu, wskaźniki sukcesu i porażki wywołań narzędzi oraz sposób na odtworzenie nieudanych uruchomień agentów na zmienionym prompcie.

LangSmith pozostaje najbardziej kompletnym rozwiązaniem, z jakiego korzystałem, pomimo obaw o lock-in. LangFuse to solidna alternatywa open-source z mniejszą liczbą funkcji. Własne zbieranie śladów w OpenTelemetry jest wykonalne, jeśli masz możliwości infrastrukturalne i chcesz uniknąć zależności od dostawcy.

Kluczowa metryka, której większość ludzi nie śledzi, a powinna, to wskaźnik sukcesu agenta na poziomie zadania, nie na poziomie kroku. Łańcuch, który kończy wszystkie kroki, ale produkuje błędne końcowe wyjście, ma 100% wskaźnik sukcesu kroków i 0% wskaźnik sukcesu zadania. Ta luka to miejsce, gdzie tkwi prawdziwa praca nad niezawodnością.

Jeśli dziś budujesz funkcje oparte na LLM, punkt startowy jest wyższy niż osiemnaście miesięcy temu, ale oczekiwania też są wyższe. Zespoły, które są z przodu, to te, które wyszły poza etap "czy możemy sprawić, by model robił X" do "czy możemy robić X niezawodnie przy strukturze kosztów, która ma sens". To problem systemowy, problem z danymi i problem produktowy, i tam właśnie leży większość prawdziwej pracy.

Warstwa architektury stosu produkcyjnego dla poważnych wdrożeń obejmuje trzy poziomy: silnik wnioskowania na sprzęcie akceleracyjnym, warstwę obsługi zarządzającą routingiem i kontraktami API (LiteLLM lub Envoy AI Gateway) oraz warstwę orkiestracji opartą na Kubernetes z KEDA do automatycznego skalowania. Cele wydajnościowe, do których inżynierowie są teraz zobowiązani, to TTFT poniżej 300 ms dla standardowych obciążeń oraz opóźnienie między tokenami rzędu kilkudziesięciu milisekund.

Koszty: Matematyka się zmieniła, problem pozostał

Ceny API spadły o około 80% między 2025 a 2026 rokiem. Wydajność klasy GPT-4 kosztuje teraz około 0,40 USD za milion tokenów, w porównaniu z 30 USD za milion na początku 2023 roku. Wygląda to jak rozwiązany problem, dopóki nie uwzględni się tego, co systemy agentyczne faktycznie robią: jedno zadanie użytkownika może wywołać od 50 do 200 wywołań LLM. Niska cena za token bardzo szybko staje się wysokim kosztem zadania.

Techniki, które faktycznie robią różnicę, to buforowanie promptów (które obniża koszty wejścia nawet o 90% przy powtarzającym się kontekście), kwantyzacja FP8 w połączeniu z Flash Attention 3 i dekodowaniem spekulatywnym, a także inteligentny routing żądań kierujący prostsze podzadania do mniejszych, tańszych modeli. Dekodowanie spekulatywne warto dokładnie profilować: używa małego modelu szkicowego do generowania kandydatów na tokeny, które model główny weryfikuje równolegle, ale jeśli wskaźnik akceptacji spadnie poniżej około 0,5 tokena na krok, zamiast redukować narzut, go zwiększasz.

Moja opinia: zespoły, które nie zbudują dashboardu kosztów per funkcja, będą wydawać bez kontroli. Oszczędności są realne, ale wymagają dyscypliny pomiarowej.

RAG: Retrieval nadal jest problemem

Wzorzec wrzucania plików PDF do bazy wektorowej i nazywania tego bazą wiedzy jest już powszechnie rozumiany jako niewystarczający. Od 2026 roku etap wyszukiwania jest źródłem większości awarii RAG, a nie model generujący. Tryb awarii jest subtelny: system zwraca pewnie brzmiące odpowiedzi zakorzenione w błędnych fragmentach, a użytkownicy tego nie wychwytują.

Hybrydowe wyszukiwanie łączące gęste wyszukiwanie wektorowe z BM25 i uzupełnione o reranker oparty na cross-encoderze to obecny standard dla systemów produkcyjnych. Samo wyszukiwanie wektorowe osiąga gorsze wyniki przy zapytaniach wymagających precyzji. Wyszukiwanie wspomagane grafem zyskuje popularność w dziedzinach ze strukturalnymi relacjami między encjami. A kwestia zarządzania źródłami wiedzy, czyli kto odpowiada za aktualność fragmentów, deduplikację i kontrolę jakości, to decyzja produktowa, którą zespoły inżynierskie wciąż próbują odkładać, aż w końcu ich to dopadnie.

Agenci i MCP: Standard, który się przyjął

Model Context Protocol firmy Anthropic, wprowadzony pod koniec 2024 roku, stał się dominującym standardem łączenia narzędzi z agentami LLM. OpenAI przyjął go w marcu 2025 roku i jednocześnie ogłosił wycofanie Assistants API, zaplanowane na połowę 2026 roku. To połączenie wymusiło konwergencję ekosystemu. Cursor, Cline i większość poważnych środowisk programistycznych opartych na agentach oczekują teraz serwerów narzędzi zgodnych z MCP.

Ma to znaczenie operacyjne. Standaryzowany interfejs narzędzi oznacza, że można wymienić bazowy model bez przepisywania konektorów narzędzi. Oznacza to również, że powierzchnia ataku pod kątem wstrzykiwania promptów i nadużycia narzędzi jest teraz przewidywalna i audytowalna. Żadna z tych rzeczy nie była prawdą osiemnaście miesięcy temu.

Obserwowalność: już nie opcjonalna

Langfuse zostało przejęte przez ClickHouse w styczniu 2026 roku, co wiele mówi o kierunku, w jakim zmierza rynek: potoki śledzenia potrzebują baz danych zdolnych obsłużyć wolumeny zapisów generowane przez agenty produkcyjne. Wiodące platformy w tej przestrzeni to LangSmith (naturalny wybór dla stosów opartych intensywnie na LangChain), Langfuse (najlepsza opcja do samodzielnego hostowania) oraz Arize Phoenix (najsilniejszy w przepływach pracy z intensywnym pobieraniem danych RAG).

Czego tradycyjny APM nie potrafi wyjaśnić: który krok pobierania zwrócił nieistotny kontekst, dlaczego agent wpadł w pętlę rekurencyjną, czy jakość wyników odchyla się od wartości bazowej w kolejnych wersjach modelu. Te pytania wymagają śledzenia natywnego dla LLM, które podąża za żądaniami przez wywołania LLM, kroki pobierania, wywołania narzędzi i gałęzie decyzji agenta łącznie, a nie w izolacji.

Halucynacja: wskaźnik, nie wartość binarna

Halucynacje pozostają główną przeszkodą dla wdrożeń produkcyjnych o wysokiej stawce. Istotna zmiana w 2026 roku polega na tym, że zespoły w większości przestały traktować je jako kwestię zero-jedynkową i zaczęły mierzyć je jako wskaźnik. Wykrywanie metodą LLM-as-judge wychwytuje od 60 do 75% halucynowanych wyników w zależności od projektu promptu. W zadaniach opartych na pobieraniu danych wskaźniki spadają poniżej 2% w dobrze zaprojektowanych systemach. Zabezpieczenia działające w czasie rzeczywistym, które sprawdzają wyniki przed dostarczeniem i kierują oznaczone odpowiedzi do weryfikacji, stały się standardem, choć opóźnienie detekcji wynoszące od 200 do 500 ms stanowi realne obciążenie dla budżetów opóźnień.

Praktyczne zalecenie: zbuduj pętlę próbkowania halucynacji w swoim potoku ewaluacyjnym od pierwszego dnia. Oceniaj losową próbkę śladów produkcyjnych na żywo każdego dnia. Wykryjesz dryfowanie modelu, przestarzałe indeksy pobierania i regresje promptów, zanim zgłoszą je użytkownicy.

Co to oznacza dla całego stosu

Model to towar. Silnik wnioskowania, jakość wyszukiwania, protokół narzędzi, warstwa obserwowalności i dyscyplina kosztowa wokół wolumenów wywołań agentowych -- to tam tkwi prawdziwa dźwignia inżynierska w 2026 roku. Zespoły, które traktują te kwestie jako sprawy drugorzędne, będą wciąż gasić pożary. Zespoły, które traktują je jako zagadnienia pierwszej kategorii, dostarczają niezawodne produkty.