> A vLLM egy Hugging Face checkpointból OpenAI-kompatibilis szervert épít: mit ad a PagedAttention és a folyamatos batching, és mit kerül az üzemeltetés.
>
> Web page: https://balazscsorba.com/hu/blog/vllm · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/vllm.md) · [Deutsch](https://balazscsorba.com/de/blog/vllm.md)
> Author: Balázs Csorba · Published: 2026-06-30 · Keywords: vllm, vllm vs sglang, vllm vs tensorrt-llm, self-hosted llm server, openai compatible api server, llm inference throughput, pagedattention

[Blog](https://balazscsorba.com/hu/blog)/LLMOps és értékelés

# vLLM áttekintve: inferencia saját hardveren

A vLLM egy Hugging Face checkpointból OpenAI-kompatibilis szervert épít: mit ad a PagedAttention és a folyamatos batching, és mit kerül az üzemeltetés.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. június 30.·11 perc olvasás

-   Self-hosted inference
-   OpenAI API
-   PagedAttention
-   GPU serving
-   LLM runtime

![Osztott tálca laza lapokkal egy keskeny növekvő oszlopot táplál, nyíl távozik.](https://balazscsorba.com/images/blog/vllm/cover.webp?v=46f6c02794)

## A lényeg röviden

-   A vLLM az alapértelmezett, saját hardveren futó kiszolgálóengine a nyílt súlyú modellekhez NVIDIA- és AMD-hardveren, nem a sebessége miatt, hanem a modellek, kvantálások és API-lefedettség szélessége miatt.
-   A PagedAttention és a folyamatos batching a létoka; a megbízható állítás az, hogy a lapozott allokáció a KV-cache 60–80 százalékos pazarlását 4 százalék alá szorította, nem az 2023-as 24-szeres átvitel.
-   A prefix caching alapértelmezetten be van kapcsolva, és csak a prefillet rövidíti, ezért a hosszú, ismétlődő promptokat használó terhelések profitálnak belőle a legtöbbet, a hosszú, közös prefix nélküli generálások semmit.
-   A produkciós hibaforma a KV-cache túlméretezése miatti, újraszámítással végrehajtott preemption; a KV-cache kihasználtságát és az összesített preemption-számot kell figyelni, nem az összesített átvitelt.
-   A négy GPU-s telepítés hat processzben fut, és legalább hat fizikai CPU-magot igényel, ami a leggyakoribb oka a vártnál gyengébb átvitelnek.

Ezen az oldalon

1.  [Mi ez valójában](https://balazscsorba.com/#what-it-is)
2.  [Hogyan működik](https://balazscsorba.com/#how-it-works)
3.  [Kiszolgáló felállítása](https://balazscsorba.com/#getting-started)
4.  [Mit ér az átviteli állítás](https://balazscsorba.com/#performance)
5.  [Üzemeltetés produkcióban](https://balazscsorba.com/#running-in-production)
6.  [Hol fájik](https://balazscsorba.com/#where-it-stings)
7.  [Ítélet](https://balazscsorba.com/#verdict)
8.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

A vLLM egy nyílt forráskódú inféziós engine, amely Hugging Face checkpointból OpenAI API-t beszélő HTTP-szervert épít. Ez a réteg a modell és minden hívó között van, és az egyetlen feladata, hogy a GPU-t folyamatosan dolgoztassa. Az ítélet előre: NVIDIA- vagy AMD-hardveren, nyílt súlyú modellekkel ez az alapértelmezett választás, mert másik projekt sem fed le ennyi felület ennyi ragasztó kóddal. Laptopon, tisztán CPU-s gépen, vagy egy modellel és egy felhasználóval messzire túl nagy gépezet.

A kiszolgálási rétegben verseng, nem a modellrétegben. A versenytársak a SGLang, amely a design nagy részét osztja; az NVIDIA TensorRT-LLM, amely a szélességet cseréli a csúcseredményekért az NVIDIA alkatrészeken; a llama.cpp, amely ott kezdődik, ahol a vLLM feladja; és a Hugging Face TGI, amelynek utolsó kiadása a v3.3.7 volt 2025 decemberében. A szokásos helyettesítője a hosztolt API-nak is, mert ugyanaz az OpenAI klienskód, amely szolgáltatót hív, egy helyi processzhez is irányítható.

## Mi ez valójában

A kiszolgáló engine kiválasztásánál számító tények, mind a projekt saját dokumentációjából, nem szolgáltatói oldalról:

-   **Apache-2.0**, fizetős szint és a szolgáltató által hosztolt vezérlőréteg nélkül.
-   A UC Berkeley Sky Computing Lab laboratóriumában indult; a dokumentáció több mint 2000 közreműködőt említ, és az egyik legaktívabb nyílt forráskódú AI-projektnek nevezi.
-   Több mint 200 modellarchitektúra a Hugging Face-en, köztük decoder-only, mixture-of-experts, hibrid attention, multimodális, embedding-, rerank- és reward-modellek.
-   OpenAI-kompatibilis szerver, plusz Anthropic Messages és Cohere embed, illetve rerank végpontok, továbbá beszéd és strukturált kimenet. Egy processz egy modellt szolgál ki.
-   A CUDA és a ROCm első osztályú cél, az Intel XPU és a Google TPU támogatott, hardverpluginekkel az Ascend NPU-hoz, Gaudihoz, Spyre-hez, Apple Siliconhoz, MetaX-hez és továbbiakhoz.
-   Kvantálás FP8, NVFP4, MXFP4, INT8 és INT4 szinten, továbbá GPTQ-, AWQ-, GGUF- és compressed-tensors checkpointok.
-   Körülbelül kéthetente egy minor kiadás: a v0.24.0 2026. június 29-én jelent meg, hat héttel a v0.20.2 május 10-i kiadása után.

## Hogyan működik

Két gondolat hordozza az átvitel nagy részét. A PagedAttention fix méretű blokkokban tárolja a key-value cache-t, és egy blokktáblán keresztül nem összefüggő GPU-memóriára képezi le, ugyanúgy, ahogy egy operációs rendszer a lapokat; a 2023-as tanulmány a korábbi rendszerekben 60–80 százalékos KV-cache pazarlást mért töredezettség és túlreszerválás miatt, a lapozott allokációval szemben 4 százalék alatt. A folyamatos batching ezután minden dekódolási lépésnél befogad új kéréseket ahelyett, hogy megvárná a batch feltöltését, és innen származik a késleltetésjavulás nagy része.

![Egy kérés a vLLM V1 engine-en keresztül A kliensek egy API-kiszolgáló processzt hívnak, amely tokenizálja a promptot, és socketen át továbbítja egy engine core processznek. Az engine core tartja az ütemezőt és a KV-cache menedzsert, amely blokkokat ad át egy worker processznek GPU-nként. Tokenenként a workerek a lapozott KV-cache blokkokba írnak, a streamelt kimenet ugyanazon az úton visszafelé halad.](https://balazscsorba.com/images/blog/vllm/diagram-7.webp?v=13c97d2cdb)

A vLLM V1 processzekre bontja a munkát: HTTP és tokenizálás az API-kiszolgálóban, ütemezés és cache-kezelés az engine core-ban, GPU-nként egy worker.

A V1 engine, amely 2025-ben váltotta fel a V0-át, egy lépésben keveri a prefillet és a dekódolást, és a dekódolásnak ad prioritást, így egy hosszú prompt már nem fékezi le a streamelt forgalmat. A chunked prefill alapértelmezetten be van kapcsolva. A prefix caching is alapértelmezett, és tokenblokkokat hashel, így az ismétlődő rendszerprompt csak egyszer prefilletődik fel; a projekt dokumentációja külön kiemeli, hogy ez csak a prefillet rövidíti, a dekódolásra nem hat, tehát közös prefix nélküli hosszú generálásnál alig hoz valamit. A spekulatív dekódolás n-gram, EAGLE és DFlash javaslatkiválasztókkal érhető el, nem külön kis draft modellel.

## Kiszolgáló felállítása

A telepítés egy parancs, a dokumentált platform Linux Python 3.10-től 3.13-ig. Egy modell kiszolgálása így néz ki:

```
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

# Prefix caching and chunked prefill are on by default in V1.
vllm serve Qwen/Qwen3-8B \
  --served-model-name qwen3-8b \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.9 \
  --tensor-parallel-size 2 \
  --api-key "$VLLM_TOKEN"
```

A flagek lényegében kapacitási döntések. A `--max-model-len` korlátozza a kontextust, és ezzel az egy kérés által tartható KV-cache méretét, ezért a termék által valóban igényelt leghosszabb promptra állítsd, nem a modell maximumára. A `--gpu-memory-utilization` a VRAM azon hányada, amelyet előre a súlyoknak és a cache-nek foglal le; ami a súlyok után marad, azt méri az indulási profiling futás, és ebből lesznek blokkok. A `-O0` és `-O3` szabályozza, mennyire erősen fordít és rögzít CUDA grafikonokat, `-O2` az alapértelmezett; a `--enforce-eager` mindkettőt kihagyja. A megszólításhoz nem kell új kliens:

```
from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://localhost:8000/v1",
)

stream = client.chat.completions.create(
    model="qwen3-8b",
    messages=[
        {"role": "system", "content": "Answer in one sentence."},
        {"role": "user", "content": "Why beat a contiguous KV cache?"},
    ],
    max_tokens=200,
    temperature=0,
    stream=True,
)

for chunk in stream:
    print(chunk.choices[0].delta.content or "", end="", flush=True)
```

**A sampling alapértékek a modelltől jönnek, nem tőled**

Alapértelmezés szerint a szerver alkalmazza a Hugging Face repóban lévő `generation_config.json` fájlt, így a modellkészítő által javasolt sampling értékek csendben felülírják, amit a kérés kér. A `--generation-config vllm` opcióval az engine saját alapértékeit kapod, és ha a kimenetnek frissítéseken át stabilnak kell maradnia, rögzítsd a samplinget a kliensben.

## Mit ér az átviteli állítás

A híres számok a 2023-as bemutatkozó bejegyzésből származnak, nem friss benchmarkokból: LLaMA-7B egy A10G-n és LLaMA-13B egy 40 GB-os A100-on, ShareGPT-ből származó kéréshosszakkal, legfeljebb 24-szeres átvitelt adtak a Hugging Face Transformershez képest és 2,2–3,5-szöröst a TGI-hez képest. Ezek az értékek már történelem, nem specifikáció, és a történet tartós része a memóriapazarlás, nem a szorzók. Azóta változott a szint: a komoly versenytársak mind átvették a lapozott cache-t és a repülés közbeni batchinget, így a hasznos kérdés már nem az, ki batchel jobban, hanem az, ki hangol és patchel gyorsabban.

Kapcsoló

Mit változtat

Mikor érdemes állítani

`--max-model-len`

Korlátozza a kontextust, és vele egy kérés által tartható KV-cache méretét

A leghosszabb valós prompt messze a modell maximuma alatt van

`--gpu-memory-utilization`

A VRAM azon hányada, amely előre a súlyoknak és a KV-cache-nek foglal le

Az indulási log kevés blokkot jelez, vagy a kérések kiszorulnak

`max_num_batched_tokens`

Prefill tokenek lépésenként: kisebb érték a tokenközi késleltetést, nagyobb az első token idejét javítja

Interaktív chat kontra offline batch munka

`--tensor-parallel-size`

Szétosztja a súlyokat több GPU-ra, így kártyánként több KV-cache hely felszabadul

A modell nem fér be, vagy a KV-cache a szűk keresztmetszet

`-O0`\-tól `-O3`

Fordítás és CUDA grafik rögzítése; `-O2` az alapértelmezett

Az indulási idő fontosabb, mint a dekódolás állandósult állapotban

`--enforce-eager`

Teljesen kihagyja a fordítást és a grafikrögzítést

Fejlesztési ciklusok, vagy annak mérése, hogy egy indítás mennyi része a rögzítés

Az a hibaforma, amely valóban előfordul produkcióban, a preemption. Ha a KV-cache nem fér el minden futó szekvenciához, a vLLM kiszorítja a kéréseket, és újraszámolja őket a promptból, amikor lesz hely; az összesített átvitelben ez alig látszik, a faroklatenciában viszont dominál. A V1 alapértelmezés szerint újraszámításra vált a swappelés helyett, mert a swapelés többet fizetett, tehát a gyógyulat kapacitás, nem egy flag.

**Ismerd fel a logban**

Az ütemező így figyelmeztet: `Sequence group 0 is preempted by PreemptionMode.RECOMPUTE mode because there is not enough KV cache space`. Állítsd be a `disable_log_stats=False` opciót az összesített preemption-szám naplózásához, vagy riasztás a `vllm:kv_cache_usage_perc` közel 1,0 értékére. A kihasználtság vagy a tenzoros párhuzamosság növelése segít; a túlzottan magas kihasználtság az, ahogy egy közös gép másik bérlője out-of-memory killt okoz.

## Üzemeltetés produkcióban

### Először a megfigyelhetőség

Az engine a `/metrics` útvonalon Prometheus végpontot ad a `vllm:` előtaggal. A metrics design dokumentum szokatlanul egyértelmű a szándékról: a szerver szintű gauge-ok a kérés szintű hisztogramok magyarázatára valók, és a kérés szintű hisztogramok azok a sorok, amelyekre egy üzemeltetőnek riasztania kell.

-   `vllm:time_to_first_token_seconds` — a prefill költsége, amit a felhasználó hideg promptnál érzett
-   `vllm:inter_token_latency_seconds` — a dekódolás sebessége, amit a felhasználó a generálás megkezdése után érzett
-   `vllm:e2e_request_latency_seconds` az a sor, amelyre az időtúllapadási szabályt írni kell
-   `vllm:kv_cache_usage_perc` és `vllm:num_requests_running` — kapacitás; ha mindkettő egyszerre a határán áll, a sor nő
-   `vllm:prefix_cache_queries` és `vllm:prefix_cache_hits` arányához — ez mondja meg, valóban újrahasznosítják-e a közös promptokat, és tehát hogy illik-e a terhelés az engine-hez

### Processzszám és CPU

A négy GPU-s telepítés nem egy processz. A V1 egy API-kiszolgáló processzt, egy engine core processzt és GPU-nként egy worker processzt futtat, tehát egyetlen csomóponton tenzoros párhuzamosság 4 mellett összesen hat processzt, és az adat párhuzamosság egy koordinátort tesz hozzá. A hangolási útmutató N GPU-hoz 2 plusz N fizikai magot ír elő, mert az engine core szoros ciklust futtat, és a CPU-éheztől láthatóan szenved.

**A kiéheztetett CPU lassú GPU-nak látszik**

Az útmutató a tokenizálást, az ütemezési késleltetést és a streamelt detokenizálást nevezi meg elsőként szenvedőnek, a vártnál alacsonyabb GPU-kihasználtság a tünet. Ha a hyperthreading be van kapcsolva, a (2 + N) érték kétszeresét tervezd meg vCPU-ban.

### Biztonsági helyzet

A hitelesítés egyetlen megosztott titok. A `--api-key` flag vagy a `VLLM_API_KEY` környezeti változó bekapcsol egy fejléc-ellenőrzést, és egyszerre több kulcsot is elfogad, hogy rotálhatók legyenek. Nincs felhasználómodell, nincs bérlőnkénti kvóta és nincs jogosultsági réteg, így ami eléri a portot, használhatja az egész GPU-t.

**A fejlesztői végpontok produkciós incidensre várnak**

A `VLLM_SERVER_DEV_MODE=1` beállítás a `/pause`, `/reset_prefix_cache` és `/collective_rpc` végpontokat is regisztrálja, és a dokumentáció maga hordoz biztonsági figyelmeztetést. Tartsd a portot megbízható hálózaton belül, és tegyél elé hitelesítést, kvótát és sebességkorlátozást.

## Hol fájik

Először három dolog. Ez GPU-szerver, nem univerzális runtime: a dokumentált cél Linux CUDA-val vagy ROCm-mel, így a tisztán CPU-s gép vagy az Apple Silicon gép másik projektet és másik modellformátumot jelent. Az indulási idő valós, mert az alapértelmezett optimalizálási szint lefordítja a modellt és CUDA grafikonokat rögzít, és egy hideg konténer perceket tölthet a fordítóban, mielőtt az első token megjelenik. Az API pedig OpenAI-alakú, nem OpenAI-teljes: a `suffix` paraméter nem támogatott, a `user` paramétert figyelmen kívül hagyják, a párhuzamos tool hívások pedig modellfüggők és a legjobb esetben is csak részben adottak.

Engine

Licenc

Miben nyer

Mit fizet érte

**vLLM**

Apache-2.0

Szélesség: a legtöbb architektúra, a legszélesebb kvantálási és hardvercél halmaz, egy API a szövegre, embeddingre, rerankra, beszédre és strukturált kimenetre

Fordítás és grafikrögzítés minden indításkor, egy modell szerverenként, és egy szoros ciklus, amihez CPU kell mögötte

SGLang

Apache-2.0

Rádix-szerű prefix megosztás és többkörös állapot újrahasznosítás, ami az ugyanazt a hosszú kontextust újra és újra elérő agent- és retrieval-forgalmat kedvezményez

Kisebb modellzoo és vékonyabb kiszolgálási felület a chat kiegészítéseken túl

TensorRT-LLM

Apache-2.0, csak NVIDIA stack

Csúcseredmények a legújabb NVIDIA alkatrészeken, FP4 és FP8 kernelek, első osztályú integráció a Dynamo és a Triton rendszerrel

Csak NVIDIA, és újraépítés, valahányszor a modell, a kvantálás vagy a GPU-generáció változik

llama.cpp

MIT

CPU, Apple Silicon és edge hardver, GGUF kvantálás, egyetlen bináris fájl Python runtime nélkül

Más modellformátum, gyengébb batchelt kiszolgálási történet, nincs összemérhető felület embeddinghez vagy rerankhoz

A legtöbb csapat számára az igazi összehasonlítás az első és a második sor. A vLLM és az SGLang ugyanazt a problémát ugyanazokkal az elemekkel oldja meg, mindkettő Apache-2.0, mindkettő OpenAI-kompatibilis, és mindkettő jól szolgál ki egy szokásos chat terhelést. Az SGLang prefix-fája jobban illik oda, ahol ugyanaz a hosszú kontextus jön vissza újra és újra; a vLLM modelllefedettsége és kvantálási mátrixa jobban illik oda, ahol az új checkpointok gyorsabban érkeznek, mint a terhelések ismétlődnek.

## Ítélet

A vLLM az alapértelmezett eszköz, és ennek oka nem a nyers sebesség, hanem a felület: a legtöbb modell, a legtöbb kvantálási forma, a legtöbb hardvercél, és egy API, amely lefedi a kiegészítéseket, a chatet, az embeddinget, a rerankot, a beszédet és a strukturált kimenetet. A költségek valósak és többnyire unalmasan javíthatók. Az indulási idő állítható, a preemption kapacitáskérdés, a kiéheztetett CPU telepítési hiba. Egyik sem ok arra, hogy mást válassz.

1.  Válaszd, ha nyílt súlyú modelleket szolgálsz ki NVIDIA- vagy AMD GPU-ken, és a terhelés batchelt: sok egyidejű kérés, nem egyenként.
2.  Válaszd, ha gyors a modellváltás, mert egy új checkpoint rendszerint már akkor fut, amikor a versenytársak még nem támogatják.
3.  Válaszd, ha a körülvevő stack már OpenAI API-t beszél, mert a migráció egy base URL.
4.  Ne válaszd laptophoz, edge dobozhoz vagy egy felhasználós eszközhöz; a llama.cpp vagy egy MLX runtime a töredékéért elvégzi.
5.  Ne válaszd, ha egy modell egy NVIDIA generációhoz van kötve, és a csúcs token másodpercenként az egyetlen cél, mert a TensorRT-LLM megnyeri ezt a cserét a bezáródás árán.
6.  Mérd be az SGLang-et, mielőtt elköteleződsz, ha a forgalom agentikus vagy retrieval-nehezes, és erősen újrahasznosítja a kontextust; a kettő olyan közel van egymáshoz, hogy általában az dönt, melyiket lehet reggel háromkor hibakeresni.

**A véleményes rész**

A vLLM melletti érv csendben a sebesség helyett a szélesség melletti érv lett, és azok a projektek, amelyek megelőzik, nem a batchingben nyernek. Egyetlen terhelésben lesznek jobbak. A csapatokat általában jobban szolgálja egy általános engine és egy specialista, mint terhelésenként egy engine, és éppen ez az érv a vLLM-re való egységesítés mellett, akkor is, ha egy rivális egyetlen forgalmi alakzatra mérhetően gyorsabb.

## Források

1.  [vLLM dokumentáció](https://docs.vllm.ai/en/latest/)
2.  [Optimalizálás és hangolás a V1 engine-ben](https://docs.vllm.ai/en/stable/configuration/optimization.html)
3.  [Architektúraáttekintés és a V1 processz-elrendezés](https://docs.vllm.ai/en/stable/design/arch_overview.html)
4.  [Metrics design](https://docs.vllm.ai/en/stable/design/metrics.html)
5.  [Automatikus prefix caching és a dokumentált korlátai](https://docs.vllm.ai/en/stable/features/automatic_prefix_caching.html)
6.  [Online kiszolgálás és a HTTP API felület](https://docs.vllm.ai/en/stable/serving/online_serving.html)
7.  [Inside vLLM: egy nagy átvitelű inféziós rendszer anatómiája](https://vllm.ai/blog/2025-09-05-anatomy-of-vllm)
8.  [vLLM: egyszerű, gyors és olcsó LLM kiszolgálás PagedAttentionnel](https://blog.vllm.ai/2023/06/20/vllm.html)
9.  [Kiadástörténet](https://github.com/vllm-project/vllm/releases)

## Gyakori kérdések

Gyorsabb a vLLM az SGLangnél vagy a TensorRT-LLM-nél?

Nem általánosan, és a legtöbb közzétett összehasonlítás nem összevethető. A vLLM 2023-as bemutatkozó bejegyzése legfeljebb 24-szeres átvitelt jelentett a Hugging Face Transformershez és 2,2–3,5-szöröst a TGI-hez képest, LLaMA-7B és LLaMA-13B mellett, ShareGPT-ből származó kéréshosszakkal. Ez még a versenytársak lapozott cache-einek átvétele előtti idő, ezért a saját kéréshossz-eloszlást érdemes mérni.

Kell GPU a vLLM futtatásához?

A dokumentált cél Linux CUDA-val vagy ROCm-mel, Python 3.10-től 3.13-ig. Az Intel XPU és a Google TPU külön támogatott, az Apple Silicont pedig egy másik, MLX-alapú projekt fedi le, nem maga a vLLM. A tisztán CPU-s inferencia a llama.cpp területe.

Mennyi VRAM kell a vLLM-nek?

A vLLM a VRAM egy beállítható hányadát foglalja le a súlyoknak és a KV-cache-nek, majd induláskor egy profiling forward passzal méri a maradékot, és jelenti, hány blokk fér bele. Gyakorlatban a szűk keresztmetszet a modell súlya a választott kvantálás mellett; a többi a KV-cache, és annak mérete szabja meg a párhuzamosságot.

Egy vLLM szerver több modellt is kiszolgálhat?

Natívan nem. Egy szerverprocessz egyszerre egy modellt tart, ezért a többmodelles telepítések modellenként egy processzt futtatnak egy router mögött, vagy adat párhuzamossággal replikálják ugyanazt a modellt több GPU-ra. Kivétel a LoRA adapterek: ezek futásidőben betölthetők és leválaszthatók, a dokumentáció azonban ezt helyi fejlesztésre korlátozza.

Hogyan marad reprodukálható a vLLM kimenete frissítések után?

Rögzítsd az engine verzióját, mert a minor kiadásokként körülbelül két hetente érkeznek, és adj --generation-config vllm opciót, hogy a szerver ne alkalmazza a Hugging Face repóban lévő generation\_config.json fájlt, és ezzel ne írja felül csendben a sampling alapértékeket. Determinisztikus futásokhoz állítsd a hőmérsékletet nullára, és rögzítsd a modell revízióját is.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [DeepSeek V4.1 Flash 1017: 890 bájt KV-cache tokenenként, és mit nyer ezzel egy ágens](https://balazscsorba.com/hu/blog/deepseek-v4-1-flash-1017)
-   [LLM rate limitek élesben: újrapróbálás, backoff és szolgáltatóváltás](https://balazscsorba.com/hu/blog/llm-rate-limits-retries-provider-fallback)
-   [Promptverziózás élesben: git, registry, címkék és visszaállítás](https://balazscsorba.com/hu/blog/prompt-versioning-management)
-   [LLM batch API-k: félárú inferencia olyan munkára, amely várhat](https://balazscsorba.com/hu/blog/llm-batch-api-offline-workloads)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)