[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"reazon-offering-angebot-leistungen":3,"reazon-offering-angebot-zielgruppen":20,"reazon-angebot-subnav":21,"reazon-mainnav":22,"reazon-page-\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich":32,"reazon-footernav":59,"reazon-articles-\u002Fde\u002Fwissen":76},[4,8,12,16],{"title":5,"href":6,"description":7},"DGX Spark mieten","\u002Fde\u002Fdgx-spark","Der NVIDIA-AI-Supercomputer für den Schreibtisch — on-demand aus der Schweiz, bare metal oder gemanagt.",{"title":9,"href":10,"description":11},"Bare Metal GPU","\u002Fde\u002Fbare-metal","DGX Spark & H100 als dedizierte Maschine — volle Kontrolle, Root-Zugriff, Schweizer Rechenzentrum.",{"title":13,"href":14,"description":15},"Managed Inference","\u002Fde\u002Fmanaged-inference","LLM-Endpoints via vLLM — von uns betrieben, ohne Ops-Aufwand, mit Schweizer Datenhoheit.",{"title":17,"href":18,"description":19},"Hermes Agents","\u002Fde\u002Fagents","Agentische Workloads gemanagt — Hermes-Agents auf souveräner Hardware, von uns betrieben.",[],[],[23,26,29],{"title":24,"href":25},"Preise","\u002Fde\u002Fpreise",{"title":27,"href":28},"Wissen","\u002Fde\u002Fwissen",{"title":30,"href":31},"Über Twentyone","\u002Fde\u002Fueber-uns",{"data":33},{"id":34,"path":35,"slug":36,"published_at":37,"page_type":38,"no_index":41,"fields":42,"blocks":58},1324,"\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich","vllm-ollama-tgi-vergleich","2026-07-07T12:06:59.532Z",{"identifier":39,"name":40},"article","Blog Post",false,{"title":43,"summary":44,"publication_date":45,"big5_category":46,"primary_service":47,"related_articles":53,"meta_title":54,"meta_description":55,"body":56,"body_html":57},"vLLM, Ollama oder TGI: welche Inference Engine für welchen Fall","Die Engine entscheidet über Durchsatz, Latenz und Betriebsaufwand. Ein nüchterner Vergleich der drei verbreitetsten Optionen, inklusive der Fälle, in denen die einfache Lösung gewinnt.","2026-06-30T00:00:00Z","comparisons",{"id":48,"slug":49,"path":14,"page_type":50,"published":51,"type":52},676,"managed-inference","service",true,"Cms::Page",null,"vLLM vs. Ollama vs. TGI: Inference Engines im Vergleich | Twentyone","vLLM, Ollama und TGI im nüchternen Vergleich: Durchsatz, Batching, Speicher und Betriebsaufwand. Welche Inference-Engine zu welchem Workload passt.","## Die Schicht, an die niemand denkt\n\n„Das Modell läuft, aber es ist langsam.“ Der Satz fällt fast immer, wenn ein Team sein erstes selbst gehostetes LLM produktiv setzt. Auf dem Laptop war alles flott, ein, zwei Nutzer, sofort eine Antwort. Dann gehen zehn Leute gleichzeitig drauf, und plötzlich dauert jede Antwort eine gefühlte Ewigkeit, während die teure GPU im Monitoring trotzdem **halb gelangweilt** vor sich hin dümpelt. Die Schuld liegt selten am Modell. Sie liegt an der Schicht darunter, an die beim Aufsetzen niemand gedacht hat: der **Inference-Engine**.\n\nDiese Schicht nimmt Requests an, verwaltet den Speicher, plant die Berechnung und streamt die Tokens zurück. Sie entscheidet über fast alles, was du im Betrieb spürst: wie viele Nutzer gleichzeitig passen, wie lange das erste Token braucht, wie viel VRAM du wirklich brauchst und wie viel deiner Karte brachliegt. **vLLM**, **Ollama** und **TGI** lösen diese Aufgabe mit grundverschiedenen Prioritäten. Wer sie verwechselt, zahlt entweder mit **schlechter Auslastung** oder mit **unnötiger Komplexität**. Um die Wahl zu verstehen, muss man kurz darunterschauen, was beim Generieren eigentlich passiert.\n\n## Warum ein Einzelrequest deine GPU langweilt\n\nEin Request läuft in zwei Phasen ab, und die zweite ist das Problem. Im **Prefill** verarbeitet die GPU den ganzen Prompt auf einmal, parallel über alle Tokens, rechenintensiv, aber kurz, und die Karte ist gut ausgelastet. Im **Decode** entsteht die Antwort Token für Token, jeder Schritt hängt vom vorigen ab. Diese Phase ist **seriell** und **speicher- statt rechengebunden**: Die GPU wartet mehr auf Daten, als dass sie rechnet. Ein einzelner Decode-Schritt multipliziert einen kleinen Vektor mit den Gewichten und beschäftigt nur einen **Bruchteil** der zehntausenden Recheneinheiten einer modernen Karte.\n\nGenau deshalb lastet ein einzelner Nutzer die GPU **nie** aus, egal wie schnell die Hardware ist. Der einzige Weg, sie zu füllen, ist, **viele Requests gleichzeitig** durch dieselben Gewichts-Matrizen zu schicken. Durchsatz ist damit keine Frage der rohen Rechenleistung, sondern der Frage, wie clever die Engine parallele Anfragen **bündelt**. Und das wiederum scheitert oft nicht an der Rechenzeit, sondern am Speicher, an einer Struktur namens **KV-Cache**.\n\n## Der KV-Cache frisst deinen Speicher\n\nDamit das Modell beim Decode nicht in jedem Schritt den ganzen Kontext neu berechnet, speichert es pro Token Zwischenergebnisse: die **Keys und Values** jeder Attention-Schicht. Dieser **KV-Cache** wächst linear mit der Kontextlänge und mit der Zahl gleichzeitiger Nutzer, und er liegt im VRAM direkt neben den Modellgewichten. In der Praxis ist **nicht das Modell der Engpass, sondern dieser Cache**: Er bestimmt, wie viele Nutzer gleichzeitig passen, bevor dir der Speicher ausgeht.\n\nDie Grössenordnung überrascht fast jeden, der sie zum ersten Mal rechnet. Grob gilt pro Sequenz `KV-Bytes = 2 · n_layers · n_kv_heads · head_dim · seq_len · bytes_pro_element`, wobei die `2` für Keys und Values steht. Nimm ein **8B-Modell** mit Grouped-Query-Attention: 32 Layer, 8 KV-Heads, head_dim 128, fp16 mit 2 Byte. Pro Token sind das `2 · 32 · 8 · 128 = 65 536` Elemente, mal 2 Byte also **128 KiB**. Bei 8 192 Token Kontext wächst das auf rund **1 GiB pro Sequenz**, und bei 32 gleichzeitigen Nutzern mit vollem Kontext landest du bei **32 GiB allein für den KV-Cache**, zusätzlich zu den rund 16 GiB Modellgewichten. Auf einer 80-GiB-Karte geht das knapp auf, aber du siehst sofort: **Der Kontext, nicht das Modell, ist deine Obergrenze.** Bei einem 70B-Modell mit 80 Layern liegt der Cache schnell bei **2,5 GiB pro Sequenz**, und die Gewichte sprengen ohnehin eine einzelne GPU.\n\nHier liegt auch ein stiller Hebel: Wie die Gewichte lässt sich der KV-Cache **quantisieren**. Speicherst du Keys und Values in **fp8** statt **fp16**, halbierst du den KV-Speicher und **verdoppelst grob** die mögliche Zahl gleichzeitiger Sequenzen, meist bei kaum messbarem Qualitätsverlust. Engines, die fp8-KV-Cache beherrschen, holen so aus derselben Karte deutlich mehr **Concurrency**, einer der Punkte, die im Engine-Vergleich oft den Ausschlag geben.\n\n## Batching ist der ganze Unterschied\n\nWie eine Engine mit dem Speicher und der Parallelität umgeht, trennt Spielzeug von Produktion. Beim **statischen Batching** sammelt die Engine eine feste Gruppe von Requests, verarbeitet sie gemeinsam und gibt erst frei, wenn der **langsamste** fertig ist. Ein Nutzer, der drei Tokens will, blockiert dann seinen Slot, bis der Nutzer mit dreitausend Tokens durch ist, und die GPU läuft **halbleer**. **Continuous Batching** räumt damit auf: Sobald eine Sequenz fertig ist, rückt im nächsten Schritt sofort eine neue nach. Die GPU **bleibt voll**, die Wartezeiten sinken, und dieser eine Unterschied erklärt einen Grossteil der Durchsatzlücke zwischen den Engines.\n\nvLLM geht noch einen Schritt weiter und löst das Speicherproblem an der Wurzel. Klassisch reserviert man pro Sequenz einen **zusammenhängenden** KV-Block für die maximal mögliche Länge und verschwendet alles, was der Nutzer nicht ausschöpft. **PagedAttention** zerlegt den KV-Cache stattdessen in kleine, gleich grosse **Blöcke** und verwaltet sie wie ein Betriebssystem virtuellen Speicher: nicht zusammenhängend, bei Bedarf zugeteilt, **kaum Fragmentierung**. Dadurch passen spürbar mehr Sequenzen in denselben VRAM. Geteilte Präfixe, etwa ein gemeinsamer System-Prompt, lassen sich über **Prefix Caching** sogar mehrfach nutzen, statt sie pro Request neu zu berechnen. Höhere Belegung heisst direkt **höherer Durchsatz pro Franken GPU**.\n\n## Drei Engines, drei Prioritäten\n\n**vLLM** ist die Engine für den produktiven Ernstfall. PagedAttention und Continuous Batching sind der Kern, dazu kommen **Tensor-Parallelismus**, um grosse Modelle über mehrere GPUs zu legen, Prefix Caching, optional **speculative decoding** für niedrigere Latenz und eine **OpenAI-kompatible API**, gegen die deine bestehende Client-Bibliothek einfach läuft. In unseren Tests liefert vLLM bei vielen parallelen Nutzern typischerweise **ein Vielfaches** der Tokens pro Sekunde gegenüber einer llama.cpp-basierten Engine. Die genaue Zahl hängt an Modell, Kontext und GPU, aber die **Grössenordnung ist konsistent**. Der Preis ist **Komplexität**: vLLM will konfiguriert werden und läuft am besten auf sauberer Datacenter-GPU wie einer [H100 bare metal](\u002Fde\u002Fbare-metal) oder einer [DGX Spark](\u002Fde\u002Fdgx-spark).\n\n**Ollama** steht am anderen Ende. Ein Befehl, und ein Modell läuft, auf CPU, auf **Apple Silicon**, auf einer kleinen GPU. Im Kern steckt **llama.cpp** mit **GGUF-Modellen**, und das Modell-Hot-Swapping macht das Ausprobieren angenehm. Für **lokale Entwicklung**, Prototypen und Einzelnutzer ist das unschlagbar bequem. Unter echter Parallel-Last fällt Ollama aber deutlich zurück: Das **Concurrency-Batching ist schwach**, der Durchsatz pro GPU niedrig. Für einen Endpoint mit vielen gleichzeitigen Nutzern ist es das **falsche Werkzeug**, so angenehm es im Kleinen ist.\n\nDazwischen sitzt **TGI**, Hugging Faces produktionsreife Engine. Sie bringt Continuous Batching, **Token-Streaming** und fertige Container mit und ist eng ins **Hugging-Face-Ökosystem** integriert. Wenn dein Stack ohnehin dort lebt und dir gute Integration und robuste Defaults wichtiger sind als die letzten Prozent Durchsatz, ist TGI eine **bequeme, solide Wahl**. Am absoluten oberen Ende des Durchsatzes hat vLLM in vielen Szenarien dennoch die Nase vorn, und der **direkte Vergleich auf deinem Modell** lohnt sich.\n\n## Die Entscheidung nach Lastprofil\n\nDie Wahl folgt nicht der Mode, sondern deiner **Last** und deiner **Hardware**. In den allermeisten Fällen läuft sie auf eine dieser drei Situationen hinaus:\n\n- **Einzelnutzer oder Prototyp:** Du entwickelst lokal, baust eine interne Demo oder testest Modelle. Nimm **Ollama**, denn Apple Silicon oder eine kleine Karte reichen, du bist in Minuten startklar, und schwaches Batching ist bei einem Nutzer egal.\n- **Mittlere Last mit HF-Bindung:** Du gehst produktiv, hast moderate Parallelität und steckst tief im Hugging-Face-Stack. **TGI** gibt dir Continuous Batching und fertige Container ohne grossen Tuning-Aufwand, der pragmatische Default.\n- **Hohe Parallel-Last:** Viele gleichzeitige Nutzer, hoher Token-Durchsatz, Datacenter-GPU. **vLLM**, weil PagedAttention, Tensor-Parallelismus und fp8-KV-Cache die Komplexität rechtfertigen: Sie tragen pro GPU am meisten Last und drücken damit die **Kosten pro Token**.\n\nDie Schwelle, ab der sich der Umstieg von Ollama auf vLLM lohnt, liegt nicht bei einer bestimmten Nutzerzahl, sondern dort, wo aus „ein paar Leute probieren das mal aus“ ein **echter, gleichzeitig genutzter Endpoint** wird. Spätestens dann zahlt sich die Engine, die deine GPU wirklich füllt, in **barer Münze** aus.\n\n## Wer die Engine am Ende betreibt\n\nDie Engine auszuwählen ist der **einfache Teil**. Sie aktuell zu halten, für ein neues Modell neu zu tunen, fp8 und Parallelismus richtig zu setzen und unter Last stabil zu fahren, ist der **Aufwand, der bleibt**, und genau der **Betriebsblock**, den wir in den [Kosten eigener LLMs](\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten) auseinandergenommen haben. Wenn du die **Datenhoheit** offener Modelle willst, aber **nicht den Betrieb erben** möchtest, übernehmen wir mit [Managed Inference](\u002Fde\u002Fmanaged-inference) genau diese Schicht und wählen die Engine **passend zu deinem Workload**, statt dich auf eine festzunageln.","\u003Ch2>Die Schicht, an die niemand denkt\u003C\u002Fh2>\n\n\u003Cp>„Das Modell läuft, aber es ist langsam.“ Der Satz fällt fast immer, wenn ein Team sein erstes selbst gehostetes LLM produktiv setzt. Auf dem Laptop war alles flott, ein, zwei Nutzer, sofort eine Antwort. Dann gehen zehn Leute gleichzeitig drauf, und plötzlich dauert jede Antwort eine gefühlte Ewigkeit, während die teure GPU im Monitoring trotzdem \u003Cstrong>halb gelangweilt\u003C\u002Fstrong> vor sich hin dümpelt. Die Schuld liegt selten am Modell. Sie liegt an der Schicht darunter, an die beim Aufsetzen niemand gedacht hat: der \u003Cstrong>Inference-Engine\u003C\u002Fstrong>.\u003C\u002Fp>\n\n\u003Cp>Diese Schicht nimmt Requests an, verwaltet den Speicher, plant die Berechnung und streamt die Tokens zurück. Sie entscheidet über fast alles, was du im Betrieb spürst: wie viele Nutzer gleichzeitig passen, wie lange das erste Token braucht, wie viel VRAM du wirklich brauchst und wie viel deiner Karte brachliegt. \u003Cstrong>vLLM\u003C\u002Fstrong>, \u003Cstrong>Ollama\u003C\u002Fstrong> und \u003Cstrong>TGI\u003C\u002Fstrong> lösen diese Aufgabe mit grundverschiedenen Prioritäten. Wer sie verwechselt, zahlt entweder mit \u003Cstrong>schlechter Auslastung\u003C\u002Fstrong> oder mit \u003Cstrong>unnötiger Komplexität\u003C\u002Fstrong>. Um die Wahl zu verstehen, muss man kurz darunterschauen, was beim Generieren eigentlich passiert.\u003C\u002Fp>\n\n\u003Ch2>Warum ein Einzelrequest deine GPU langweilt\u003C\u002Fh2>\n\n\u003Cp>Ein Request läuft in zwei Phasen ab, und die zweite ist das Problem. Im \u003Cstrong>Prefill\u003C\u002Fstrong> verarbeitet die GPU den ganzen Prompt auf einmal, parallel über alle Tokens, rechenintensiv, aber kurz, und die Karte ist gut ausgelastet. Im \u003Cstrong>Decode\u003C\u002Fstrong> entsteht die Antwort Token für Token, jeder Schritt hängt vom vorigen ab. Diese Phase ist \u003Cstrong>seriell\u003C\u002Fstrong> und \u003Cstrong>speicher- statt rechengebunden\u003C\u002Fstrong>: Die GPU wartet mehr auf Daten, als dass sie rechnet. Ein einzelner Decode-Schritt multipliziert einen kleinen Vektor mit den Gewichten und beschäftigt nur einen \u003Cstrong>Bruchteil\u003C\u002Fstrong> der zehntausenden Recheneinheiten einer modernen Karte.\u003C\u002Fp>\n\n\u003Cp>Genau deshalb lastet ein einzelner Nutzer die GPU \u003Cstrong>nie\u003C\u002Fstrong> aus, egal wie schnell die Hardware ist. Der einzige Weg, sie zu füllen, ist, \u003Cstrong>viele Requests gleichzeitig\u003C\u002Fstrong> durch dieselben Gewichts-Matrizen zu schicken. Durchsatz ist damit keine Frage der rohen Rechenleistung, sondern der Frage, wie clever die Engine parallele Anfragen \u003Cstrong>bündelt\u003C\u002Fstrong>. Und das wiederum scheitert oft nicht an der Rechenzeit, sondern am Speicher, an einer Struktur namens \u003Cstrong>KV-Cache\u003C\u002Fstrong>.\u003C\u002Fp>\n\n\u003Ch2>Der KV-Cache frisst deinen Speicher\u003C\u002Fh2>\n\n\u003Cp>Damit das Modell beim Decode nicht in jedem Schritt den ganzen Kontext neu berechnet, speichert es pro Token Zwischenergebnisse: die \u003Cstrong>Keys und Values\u003C\u002Fstrong> jeder Attention-Schicht. Dieser \u003Cstrong>KV-Cache\u003C\u002Fstrong> wächst linear mit der Kontextlänge und mit der Zahl gleichzeitiger Nutzer, und er liegt im VRAM direkt neben den Modellgewichten. In der Praxis ist \u003Cstrong>nicht das Modell der Engpass, sondern dieser Cache\u003C\u002Fstrong>: Er bestimmt, wie viele Nutzer gleichzeitig passen, bevor dir der Speicher ausgeht.\u003C\u002Fp>\n\n\u003Cp>Die Grössenordnung überrascht fast jeden, der sie zum ersten Mal rechnet. Grob gilt pro Sequenz \u003Ccode>KV-Bytes = 2 · n_layers · n_kv_heads · head_dim · seq_len · bytes_pro_element\u003C\u002Fcode>, wobei die \u003Ccode>2\u003C\u002Fcode> für Keys und Values steht. Nimm ein \u003Cstrong>8B-Modell\u003C\u002Fstrong> mit Grouped-Query-Attention: 32 Layer, 8 KV-Heads, head_dim 128, fp16 mit 2 Byte. Pro Token sind das \u003Ccode>2 · 32 · 8 · 128 = 65 536\u003C\u002Fcode> Elemente, mal 2 Byte also \u003Cstrong>128 KiB\u003C\u002Fstrong>. Bei 8 192 Token Kontext wächst das auf rund \u003Cstrong>1 GiB pro Sequenz\u003C\u002Fstrong>, und bei 32 gleichzeitigen Nutzern mit vollem Kontext landest du bei \u003Cstrong>32 GiB allein für den KV-Cache\u003C\u002Fstrong>, zusätzlich zu den rund 16 GiB Modellgewichten. Auf einer 80-GiB-Karte geht das knapp auf, aber du siehst sofort: \u003Cstrong>Der Kontext, nicht das Modell, ist deine Obergrenze.\u003C\u002Fstrong> Bei einem 70B-Modell mit 80 Layern liegt der Cache schnell bei \u003Cstrong>2,5 GiB pro Sequenz\u003C\u002Fstrong>, und die Gewichte sprengen ohnehin eine einzelne GPU.\u003C\u002Fp>\n\n\u003Cp>Hier liegt auch ein stiller Hebel: Wie die Gewichte lässt sich der KV-Cache \u003Cstrong>quantisieren\u003C\u002Fstrong>. Speicherst du Keys und Values in \u003Cstrong>fp8\u003C\u002Fstrong> statt \u003Cstrong>fp16\u003C\u002Fstrong>, halbierst du den KV-Speicher und \u003Cstrong>verdoppelst grob\u003C\u002Fstrong> die mögliche Zahl gleichzeitiger Sequenzen, meist bei kaum messbarem Qualitätsverlust. Engines, die fp8-KV-Cache beherrschen, holen so aus derselben Karte deutlich mehr \u003Cstrong>Concurrency\u003C\u002Fstrong>, einer der Punkte, die im Engine-Vergleich oft den Ausschlag geben.\u003C\u002Fp>\n\n\u003Ch2>Batching ist der ganze Unterschied\u003C\u002Fh2>\n\n\u003Cp>Wie eine Engine mit dem Speicher und der Parallelität umgeht, trennt Spielzeug von Produktion. Beim \u003Cstrong>statischen Batching\u003C\u002Fstrong> sammelt die Engine eine feste Gruppe von Requests, verarbeitet sie gemeinsam und gibt erst frei, wenn der \u003Cstrong>langsamste\u003C\u002Fstrong> fertig ist. Ein Nutzer, der drei Tokens will, blockiert dann seinen Slot, bis der Nutzer mit dreitausend Tokens durch ist, und die GPU läuft \u003Cstrong>halbleer\u003C\u002Fstrong>. \u003Cstrong>Continuous Batching\u003C\u002Fstrong> räumt damit auf: Sobald eine Sequenz fertig ist, rückt im nächsten Schritt sofort eine neue nach. Die GPU \u003Cstrong>bleibt voll\u003C\u002Fstrong>, die Wartezeiten sinken, und dieser eine Unterschied erklärt einen Grossteil der Durchsatzlücke zwischen den Engines.\u003C\u002Fp>\n\n\u003Cp>vLLM geht noch einen Schritt weiter und löst das Speicherproblem an der Wurzel. Klassisch reserviert man pro Sequenz einen \u003Cstrong>zusammenhängenden\u003C\u002Fstrong> KV-Block für die maximal mögliche Länge und verschwendet alles, was der Nutzer nicht ausschöpft. \u003Cstrong>PagedAttention\u003C\u002Fstrong> zerlegt den KV-Cache stattdessen in kleine, gleich grosse \u003Cstrong>Blöcke\u003C\u002Fstrong> und verwaltet sie wie ein Betriebssystem virtuellen Speicher: nicht zusammenhängend, bei Bedarf zugeteilt, \u003Cstrong>kaum Fragmentierung\u003C\u002Fstrong>. Dadurch passen spürbar mehr Sequenzen in denselben VRAM. Geteilte Präfixe, etwa ein gemeinsamer System-Prompt, lassen sich über \u003Cstrong>Prefix Caching\u003C\u002Fstrong> sogar mehrfach nutzen, statt sie pro Request neu zu berechnen. Höhere Belegung heisst direkt \u003Cstrong>höherer Durchsatz pro Franken GPU\u003C\u002Fstrong>.\u003C\u002Fp>\n\n\u003Ch2>Drei Engines, drei Prioritäten\u003C\u002Fh2>\n\n\u003Cp>\u003Cstrong>vLLM\u003C\u002Fstrong> ist die Engine für den produktiven Ernstfall. PagedAttention und Continuous Batching sind der Kern, dazu kommen \u003Cstrong>Tensor-Parallelismus\u003C\u002Fstrong>, um grosse Modelle über mehrere GPUs zu legen, Prefix Caching, optional \u003Cstrong>speculative decoding\u003C\u002Fstrong> für niedrigere Latenz und eine \u003Cstrong>OpenAI-kompatible API\u003C\u002Fstrong>, gegen die deine bestehende Client-Bibliothek einfach läuft. In unseren Tests liefert vLLM bei vielen parallelen Nutzern typischerweise \u003Cstrong>ein Vielfaches\u003C\u002Fstrong> der Tokens pro Sekunde gegenüber einer llama.cpp-basierten Engine. Die genaue Zahl hängt an Modell, Kontext und GPU, aber die \u003Cstrong>Grössenordnung ist konsistent\u003C\u002Fstrong>. Der Preis ist \u003Cstrong>Komplexität\u003C\u002Fstrong>: vLLM will konfiguriert werden und läuft am besten auf sauberer Datacenter-GPU wie einer \u003Ca href=\"\u002Fde\u002Fbare-metal\">H100 bare metal\u003C\u002Fa> oder einer \u003Ca href=\"\u002Fde\u002Fdgx-spark\">DGX Spark\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>Ollama\u003C\u002Fstrong> steht am anderen Ende. Ein Befehl, und ein Modell läuft, auf CPU, auf \u003Cstrong>Apple Silicon\u003C\u002Fstrong>, auf einer kleinen GPU. Im Kern steckt \u003Cstrong>llama.cpp\u003C\u002Fstrong> mit \u003Cstrong>GGUF-Modellen\u003C\u002Fstrong>, und das Modell-Hot-Swapping macht das Ausprobieren angenehm. Für \u003Cstrong>lokale Entwicklung\u003C\u002Fstrong>, Prototypen und Einzelnutzer ist das unschlagbar bequem. Unter echter Parallel-Last fällt Ollama aber deutlich zurück: Das \u003Cstrong>Concurrency-Batching ist schwach\u003C\u002Fstrong>, der Durchsatz pro GPU niedrig. Für einen Endpoint mit vielen gleichzeitigen Nutzern ist es das \u003Cstrong>falsche Werkzeug\u003C\u002Fstrong>, so angenehm es im Kleinen ist.\u003C\u002Fp>\n\n\u003Cp>Dazwischen sitzt \u003Cstrong>TGI\u003C\u002Fstrong>, Hugging Faces produktionsreife Engine. Sie bringt Continuous Batching, \u003Cstrong>Token-Streaming\u003C\u002Fstrong> und fertige Container mit und ist eng ins \u003Cstrong>Hugging-Face-Ökosystem\u003C\u002Fstrong> integriert. Wenn dein Stack ohnehin dort lebt und dir gute Integration und robuste Defaults wichtiger sind als die letzten Prozent Durchsatz, ist TGI eine \u003Cstrong>bequeme, solide Wahl\u003C\u002Fstrong>. Am absoluten oberen Ende des Durchsatzes hat vLLM in vielen Szenarien dennoch die Nase vorn, und der \u003Cstrong>direkte Vergleich auf deinem Modell\u003C\u002Fstrong> lohnt sich.\u003C\u002Fp>\n\n\u003Ch2>Die Entscheidung nach Lastprofil\u003C\u002Fh2>\n\n\u003Cp>Die Wahl folgt nicht der Mode, sondern deiner \u003Cstrong>Last\u003C\u002Fstrong> und deiner \u003Cstrong>Hardware\u003C\u002Fstrong>. In den allermeisten Fällen läuft sie auf eine dieser drei Situationen hinaus:\u003C\u002Fp>\n\n\u003Cul>\n\u003Cli>\u003Cstrong>Einzelnutzer oder Prototyp:\u003C\u002Fstrong> Du entwickelst lokal, baust eine interne Demo oder testest Modelle. Nimm \u003Cstrong>Ollama\u003C\u002Fstrong>, denn Apple Silicon oder eine kleine Karte reichen, du bist in Minuten startklar, und schwaches Batching ist bei einem Nutzer egal.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Mittlere Last mit HF-Bindung:\u003C\u002Fstrong> Du gehst produktiv, hast moderate Parallelität und steckst tief im Hugging-Face-Stack. \u003Cstrong>TGI\u003C\u002Fstrong> gibt dir Continuous Batching und fertige Container ohne grossen Tuning-Aufwand, der pragmatische Default.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Hohe Parallel-Last:\u003C\u002Fstrong> Viele gleichzeitige Nutzer, hoher Token-Durchsatz, Datacenter-GPU. \u003Cstrong>vLLM\u003C\u002Fstrong>, weil PagedAttention, Tensor-Parallelismus und fp8-KV-Cache die Komplexität rechtfertigen: Sie tragen pro GPU am meisten Last und drücken damit die \u003Cstrong>Kosten pro Token\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Die Schwelle, ab der sich der Umstieg von Ollama auf vLLM lohnt, liegt nicht bei einer bestimmten Nutzerzahl, sondern dort, wo aus „ein paar Leute probieren das mal aus“ ein \u003Cstrong>echter, gleichzeitig genutzter Endpoint\u003C\u002Fstrong> wird. Spätestens dann zahlt sich die Engine, die deine GPU wirklich füllt, in \u003Cstrong>barer Münze\u003C\u002Fstrong> aus.\u003C\u002Fp>\n\n\u003Ch2>Wer die Engine am Ende betreibt\u003C\u002Fh2>\n\n\u003Cp>Die Engine auszuwählen ist der \u003Cstrong>einfache Teil\u003C\u002Fstrong>. Sie aktuell zu halten, für ein neues Modell neu zu tunen, fp8 und Parallelismus richtig zu setzen und unter Last stabil zu fahren, ist der \u003Cstrong>Aufwand, der bleibt\u003C\u002Fstrong>, und genau der \u003Cstrong>Betriebsblock\u003C\u002Fstrong>, den wir in den \u003Ca href=\"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten\">Kosten eigener LLMs\u003C\u002Fa> auseinandergenommen haben. Wenn du die \u003Cstrong>Datenhoheit\u003C\u002Fstrong> offener Modelle willst, aber \u003Cstrong>nicht den Betrieb erben\u003C\u002Fstrong> möchtest, übernehmen wir mit \u003Ca href=\"\u002Fde\u002Fmanaged-inference\">Managed Inference\u003C\u002Fa> genau diese Schicht und wählen die Engine \u003Cstrong>passend zu deinem Workload\u003C\u002Fstrong>, statt dich auf eine festzunageln.\u003C\u002Fp>\n",[],[60,67],{"title":61,"links":62},"Leistungen",[63,64,65,66],{"title":5,"href":6},{"title":9,"href":10},{"title":13,"href":14},{"title":17,"href":18},{"title":68,"links":69},"Unternehmen",[70,71,72,73],{"title":30,"href":31},{"title":27,"href":28},{"title":24,"href":25},{"title":74,"href":75},"Kontakt","\u002Fde\u002Fkontakt",[77,85,97,107,115,123,130,137,143,149,155,161,167,173,179,185,187,194],{"path":78,"slug":79,"title":80,"summary":81,"image":53,"publication_date":82,"big5_category":46,"primary_hub":53,"cluster":53,"pillar":53,"hubs":83},"\u002Fde\u002Fwissen\u002Fazure-openai-bedrock-alternative-schweiz","azure-openai-bedrock-alternative-schweiz","Souveräne Inferenz gegen Azure OpenAI und AWS Bedrock: was sich im Alltag ändert","Azure OpenAI und AWS Bedrock gegen einen souverän betriebenen Endpoint: warum der Schweizer Serverstandort der Hyperscaler das Kernproblem nicht löst und was der Unterschied im Betrieb bedeutet.","2026-07-13T00:00:00Z",[84],{"slug":49,"title":13},{"path":86,"slug":87,"title":88,"summary":89,"image":53,"publication_date":82,"big5_category":90,"primary_hub":53,"cluster":53,"pillar":53,"hubs":91},"\u002Fde\u002Fwissen\u002Fbeste-gpu-llm-inferenz","beste-gpu-llm-inferenz","Die beste GPU für LLM-Inferenz: DGX Spark, H100, L40S und RTX im Vergleich","Welche GPU für eigene Inferenz? DGX Spark, H100, L40S und RTX 4090 nach dem, was zählt: wie viel Modell hineinpasst, wie viel Durchsatz herauskommt und was der Monat kostet.","bestof",[92,95],{"slug":93,"title":94},"bare-metal","Bare Metal GPU mit Root-Zugriff",{"slug":96,"title":5},"dgx-spark",{"path":98,"slug":99,"title":100,"summary":101,"image":53,"publication_date":82,"big5_category":102,"primary_hub":53,"cluster":53,"pillar":53,"hubs":103},"\u002Fde\u002Fwissen\u002Fhermes-agent-erfahrungsbericht","hermes-agent-erfahrungsbericht","Hermes-Agent im Realbetrieb: was ein souveräner Agent wirklich leistet","Ein Erfahrungsbericht statt Hochglanzprospekt: wie sich ein souverän betriebener Hermes-Agent im täglichen Einsatz verhält, wo er glänzt und wo die Begleitung anfängt.","reviews",[104],{"slug":105,"title":106},"agents","Hermes Agents as a Service",{"path":108,"slug":109,"title":110,"summary":111,"image":53,"publication_date":82,"big5_category":112,"primary_hub":53,"cluster":53,"pillar":53,"hubs":113},"\u002Fde\u002Fwissen\u002Fki-regulierte-daten-schweiz","ki-regulierte-daten-schweiz","KI mit regulierten Daten: LLMs nutzen, ohne dass die Daten die Schweiz verlassen","Für Branchen, in denen Daten das Land nicht verlassen dürfen: was revDSG, Berufsgeheimnis und der CLOUD Act für KI-Projekte bedeuten, und wie souveräne Inferenz den Rahmen einhält.","problems",[114],{"slug":49,"title":13},{"path":116,"slug":117,"title":118,"summary":119,"image":53,"publication_date":82,"big5_category":120,"primary_hub":53,"cluster":53,"pillar":53,"hubs":121},"\u002Fde\u002Fwissen\u002Fopenai-api-kosten-vs-eigener-endpoint","openai-api-kosten-vs-eigener-endpoint","Ab welchem Volumen sich ein eigener Endpoint gegen die API rechnet","Die Pay-per-Token-API ist günstig, bis sie es nicht mehr ist. Wo genau der Break-even zu einem reservierten Endpoint mit fester Monatspauschale liegt, an einem konkreten Beispiel durchgerechnet.","cost",[122],{"slug":49,"title":13},{"path":124,"slug":125,"title":126,"summary":127,"image":53,"publication_date":128,"big5_category":46,"primary_hub":53,"cluster":53,"pillar":53,"hubs":129},"\u002Fde\u002Fwissen\u002Ffine-tuning-rag-prompt","fine-tuning-rag-prompt","Fine-Tuning, RAG oder besserer Prompt? Die klare Entscheidungsregel","Fine-Tuning ist meistens nicht die Antwort auf „das Modell kennt unsere Daten nicht“. Wann Prompting, RAG oder Fine-Tuning wirklich das richtige Werkzeug sind und wie du die Eskalationsleiter korrekt durchläufst.","2026-07-07T00:00:00Z",[],{"path":131,"slug":132,"title":133,"summary":134,"image":53,"publication_date":128,"big5_category":135,"primary_hub":53,"cluster":53,"pillar":53,"hubs":136},"\u002Fde\u002Fwissen\u002Fopenai-api-migration","openai-api-migration","Von der OpenAI-API zu souveräner Inferenz: die Migration in der Praxis","Der Umstieg von OpenAI oder Anthropic auf ein selbst betriebenes offenes Modell in der Schweiz sieht dank OpenAI-kompatibler Endpoints nach einer Ein-Zeilen-Änderung aus, ist aber doch mehr. Wo Prompts, Tool-Calling und Feature-Lücken zur Stolperfalle werden.","how-to",[],{"path":138,"slug":139,"title":140,"summary":141,"image":53,"publication_date":128,"big5_category":112,"primary_hub":53,"cluster":53,"pillar":53,"hubs":142},"\u002Fde\u002Fwissen\u002Fquantisierung-int4-int8-awq-gptq-gguf","quantisierung-int4-int8-awq-gptq-gguf","Quantisierung ohne Qualitätsverlust: int4, int8, AWQ, GPTQ, GGUF entzaubert","int8 ist fast immer verlustfrei, int4 meistens auch, aber nicht bei Reasoning, Code und langen Agenten-Ketten. Wir zeigen dir ungeschönt, was Quantisierung wirklich kostet und wo GPTQ, AWQ, GGUF und bitsandbytes hingehören.",[],{"path":144,"slug":145,"title":146,"summary":147,"image":53,"publication_date":128,"big5_category":112,"primary_hub":53,"cluster":53,"pillar":53,"hubs":148},"\u002Fde\u002Fwissen\u002Frag-schlechte-antworten","rag-schlechte-antworten","RAG richtig gebaut: warum eure Wissensbasis schlechte Antworten gibt","Die meisten RAG-Systeme scheitern nicht am Sprachmodell, sondern am Retrieval davor. Wir zeigen die häufigsten Fehlerquellen bei Chunking, Embeddings und Retrieval-Strategie sowie, wie du Retrieval- und Generationsfehler sauber auseinanderhältst.",[],{"path":150,"slug":151,"title":152,"summary":153,"image":53,"publication_date":128,"big5_category":135,"primary_hub":53,"cluster":53,"pillar":53,"hubs":154},"\u002Fde\u002Fwissen\u002Fvram-modell-gpu-berechnen","vram-modell-gpu-berechnen","Welches Modell passt auf welche GPU? VRAM richtig berechnen","Bevor du GPUs kaufst oder mietest: die Faustformel für Gewichte, KV-Cache und Overhead, damit du weisst, welches Modell wirklich auf deine Hardware passt.",[],{"path":156,"slug":157,"title":158,"summary":159,"image":53,"publication_date":45,"big5_category":112,"primary_hub":53,"cluster":53,"pillar":53,"hubs":160},"\u002Fde\u002Fwissen\u002Fagent-oder-endpoint","agent-oder-endpoint","Braucht ihr wirklich einen Agent oder reicht ein Endpoint?","Agenten sind im Trend, aber oft die teurere und fragilere Lösung für ein Problem, das ein einfacher Endpoint löst. Wann sich der Aufwand lohnt und wann nicht.",[],{"path":162,"slug":163,"title":164,"summary":165,"image":53,"publication_date":45,"big5_category":112,"primary_hub":53,"cluster":53,"pillar":53,"hubs":166},"\u002Fde\u002Fwissen\u002Fdatenhoheit-was-bedeutet-das","datenhoheit-was-bedeutet-das","Was Datenhoheit konkret heisst und wo deine Prompts wirklich landen","Datenhoheit ist mehr als ein Hosting-Standort. Was rechtlich, technisch und vertraglich dahintersteckt, und welche Fragen du jedem AI-Anbieter stellen solltest.",[],{"path":168,"slug":169,"title":170,"summary":171,"image":53,"publication_date":45,"big5_category":102,"primary_hub":53,"cluster":53,"pillar":53,"hubs":172},"\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht","dgx-spark-erfahrungsbericht","DGX Spark im Betrieb: was die Maschine nach drei Monaten wirklich kann","Kein Datenblatt, sondern ein Erfahrungsbericht. Wo die DGX Spark im täglichen Betrieb glänzt, wo ihre Grenzen liegen und für wen sich die Maschine lohnt.",[],{"path":174,"slug":175,"title":176,"summary":177,"image":53,"publication_date":45,"big5_category":135,"primary_hub":53,"cluster":53,"pillar":53,"hubs":178},"\u002Fde\u002Fwissen\u002Fllm-endpoint-aufsetzen","llm-endpoint-aufsetzen","Eigenen LLM Endpoint aufsetzen: von der GPU zum ersten Token","Ein realistischer Weg vom blanken Server zum produktiven Inferenz-Endpoint. Die Schritte, die Reihenfolge und die Stolpersteine, die zwischen „läuft lokal“ und „läuft produktiv“ liegen.",[],{"path":180,"slug":181,"title":182,"summary":183,"image":53,"publication_date":45,"big5_category":90,"primary_hub":53,"cluster":53,"pillar":53,"hubs":184},"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl","offene-modelle-auswahl","Welches offene Modell für welche Aufgabe? Llama, Qwen, Mistral & Co.","Nicht das grösste Modell gewinnt, sondern das passende. Wie du offene Modelle nach Aufgabe, Speicherbedarf und Lizenz auswählst, statt Benchmarks hinterherzulaufen.",[],{"path":35,"slug":36,"title":43,"summary":44,"image":53,"publication_date":45,"big5_category":46,"primary_hub":53,"cluster":53,"pillar":53,"hubs":186},[],{"path":188,"slug":189,"title":190,"summary":191,"image":53,"publication_date":192,"big5_category":46,"primary_hub":53,"cluster":53,"pillar":53,"hubs":193},"\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu","dgx-spark-vs-cloud-gpu","DGX Spark gegen Cloud-GPU: wann sich eigene Hardware lohnt","Unified Memory gegen rohen Durchsatz, Schweizer Hardware gegen Hyperscaler. Ein nüchterner Vergleich, inklusive der Fälle, in denen die Cloud gewinnt.","2026-06-18T00:00:00Z",[],{"path":195,"slug":196,"title":197,"summary":198,"image":53,"publication_date":192,"big5_category":120,"primary_hub":53,"cluster":53,"pillar":53,"hubs":199},"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten","llm-selbst-betreiben-kosten","Was kostet es, ein LLM selbst zu betreiben?","Die nüchterne Rechnung hinter eigenen LLM-Endpoints: Hardware, Betrieb und der Punkt, ab dem sich Selbermachen wirklich lohnt.",[]]