[{"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\u002Fllm-endpoint-aufsetzen":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},1333,"\u002Fde\u002Fwissen\u002Fllm-endpoint-aufsetzen","llm-endpoint-aufsetzen","2026-07-07T12:10:17.342Z",{"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},"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.","2026-06-30T00:00:00Z","how-to",{"id":48,"slug":49,"path":10,"page_type":50,"published":51,"type":52},675,"bare-metal","service",true,"Cms::Page",null,"Eigenen LLM Endpoint aufsetzen: Schritt für Schritt | Twentyone","Von der GPU zum produktiven LLM-Endpoint: Treiber, Engine, Modell, API und Betrieb. Die realistische Schritt-für-Schritt-Reihenfolge und die typischen Stolpersteine.","## Die Frage hinter dem ersten Token\n\nEin Entwickler schrieb uns letzten Monat: „vLLM läuft, ich kriege Antworten, wir gehen nächste Woche live.“ Eine Woche später stand der Endpoint still, nicht weil das Modell schlecht war, sondern weil ein einziger Nutzer mit zwanzig parallelen Anfragen den Speicher gesprengt hatte, den auf der Demo niemand gerechnet hatte. Genau das ist der Punkt: Einen LLM-Endpoint zum **ersten Token** zu bringen ist an einem Nachmittag erledigt. Ihn so zu betreiben, dass er **produktive Last über Wochen** zuverlässig trägt, ist ein anderes Projekt. Die klare Frage lautet darum nicht „wie starte ich vLLM“, sondern „was liegt zwischen dem ersten Token auf meiner Maschine und einem Endpoint, dem ich Kunden zumute“. Dieser Beitrag geht den Weg in der Reihenfolge durch, in der er real passiert, und nennt an jedem Schritt den Fehler, der die meisten ersten Versuche kostet.\n\n## Schritt 1: Hardware und VRAM nüchtern ausrechnen\n\nBevor du irgendetwas installierst, **rechne nach, ob dein Modell überhaupt in den Speicher passt**. Der Speicher für die reinen Modellgewichte ergibt sich aus **Parameterzahl mal Bytes pro Parameter**: In FP16 sind das 2 Bytes, bei 8-bit-Quantisierung 1 Byte, bei 4-bit rund 0,5 Bytes. Ein 70B-Modell braucht also in FP16 etwa **140 GB**, in 4-bit nur noch rund **35 GB**. Auf diese reine Gewichtsgrösse schlägst du grob den **Faktor 1,2** auf, um KV-Cache, Aktivierungen und Overhead der Engine abzudecken, unter Last eher mehr, weil jeder gleichzeitige Request zusätzlichen **KV-Cache** belegt.\n\nAus dieser Rechnung folgt direkt, was auf welche Maschine passt. Eine klassische Karte mit **24 GB** trägt bequem ein 7B- bis 13B-Modell in FP16 oder ein quantisiertes 30B-Modell, aber kein grosses Modell in voller Präzision. Eine [DGX Spark](\u002Fde\u002Fdgx-spark) mit **128 GB Unified Memory** trägt dagegen ein 70B-Modell in FP16 am Stück oder mehrere kleinere Modelle parallel, ohne dass du über PCIe nachladen musst. Die Modellwahl nach Aufgabe und Speicher haben wir in [Welches offene Modell für welche Aufgabe](\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl) ausgeführt; an dieser Stelle zählt nur die nüchterne Rechnung, ob **Gewichte plus Cache plus Overhead** unter dein VRAM-Budget passen.\n\nUnd genau hier liegt der teuerste Anfängerfehler: **nur die Gewichte zu rechnen und den KV-Cache zu vergessen**. Ein Modell, das beim Start mit einem einzelnen Request läuft, kippt unter zwanzig gleichzeitigen Anfragen in den **Out-of-Memory**, weil der Cache mit der Zahl und Länge der Sessions wächst, der Fall vom Entwickler oben. **Rechne den Betriebsfall, nicht den Demofall.**\n\n## Schritt 2: Treiber und Laufzeit sauber aufsetzen\n\nDer unspektakuläre Teil, an dem trotzdem die meisten ersten Versuche scheitern. Du brauchst den passenden **NVIDIA-Treiber**, ein **CUDA-Toolkit** in einer Version, die deine Inference-Engine erwartet, und das **NVIDIA Container Toolkit**, wenn du (dringend empfohlen) in Containern arbeitest. Treiber und CUDA-Laufzeit müssen zueinander passen, und die Engine bringt ihrerseits eine Erwartung an die CUDA-Version mit. **Diese drei in Einklang zu halten** ist die eigentliche Aufgabe dieses Schritts.\n\nWarum **Container statt blanker Installation**? Eine native Installation von Treiber, CUDA und Engine direkt aufs Host-System reisst dir früher oder später die Versionen auseinander, sobald du etwas aktualisierst. Mit dem Container-Ansatz bleibt **nur der Treiber auf dem Host**, während CUDA-Laufzeit und Engine im Image gekapselt sind. Das macht Updates und Rollbacks beherrschbar und ist der Grund, warum die offiziellen Engine-Images genau so ausgeliefert werden. Der klassische Fehler bleibt trotzdem der **Versionskonflikt zwischen Treiber, CUDA und Engine**: ein zu alter Treiber für ein neues CUDA, oder eine Engine, die eine andere CUDA-Minor-Version erwartet. Prüf nach der Installation mit `nvidia-smi`, dass Treiber und CUDA-Version erkannt werden, und wähle das Engine-Image passend dazu, **statt blind das neueste Tag zu ziehen**.\n\n## Schritt 3: die Inference-Engine wählen und starten\n\nJetzt kommt die Schicht, die das Modell tatsächlich serviert, und welche Engine passt, **hängt am Lastprofil, nicht an der Mode**. Für einen Endpoint mit echter Parallel-Last ist **vLLM** meist die richtige Wahl: hoher Durchsatz dank **Continuous Batching**, eine **OpenAI-kompatible API** und Tensor-Parallelismus, um grosse Modelle über mehrere GPUs zu legen. Du startest es als Container, zeigst ihm die GPU und übergibst Modell sowie die zentralen Flags, nämlich `--tensor-parallel-size` für die Zahl der GPUs, `--max-model-len` für die maximale Kontextlänge und `--gpu-memory-utilization` für den Anteil des VRAM, den die Engine belegen darf. **Diese drei Schrauben bestimmen, wie viele Nutzer parallel passen.**\n\nWillst du dagegen nur schnell prüfen, ob ein Modell das Richtige tut, ist **Ollama** in Minuten startklar und läuft auch auf bescheidener Hardware. Für einen produktiven Endpoint mit vielen gleichzeitigen Nutzern ist es das **falsche Werkzeug**, weil das Batching schwächer ist. Die ganze Abwägung zwischen den Engines steht in [vLLM, Ollama oder TGI](\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich).\n\nBeim Tuning lauert hier der Stolperstein: Ein zu hoch gesetztes `--max-model-len` **sprengt den KV-Cache-Speicher**, denn die Engine reserviert Cache für die volle Kontextlänge mal die Zahl paralleler Sequenzen, und schon ein scheinbar harmloser Wert lässt die Reservierung explodieren. Ebenso treibt ein zu hohes `--gpu-memory-utilization` die Maschine beim Warmup in den **OOM**. **Taste dich von konservativen Werten nach oben**, statt am Limit zu starten.\n\n## Schritt 4: das Modell laden\n\nJetzt bekommt die Engine das Modell, das sie servieren soll, samt der Entscheidung über die Präzision. **Prüf, ob eine quantisierte Variante reicht**, bevor du in mehr VRAM investierst: **AWQ** und **GPTQ** sind verbreitete 4-bit-Formate für GPU-Inferenz, **GGUF** ist das Format aus der llama.cpp-Welt und eher für CPU- oder gemischte Setups. Eine gute 4-bit-Quantisierung spart **drastisch Speicher** bei oft kaum spürbarem Qualitätsverlust und lässt dadurch mehr Nutzer parallel zu.\n\nBeim ersten Start lädt die Engine die Gewichte herunter und in den Speicher. Das **braucht Zeit**, belegt mehrere Dutzend Gigabyte auf der Platte und führt einen **Warmup** durch, bei dem CUDA-Graphen kompiliert werden. Plane diesen Vorlauf ein und häng ihn nicht an einen Health-Check, der schon nach Sekunden Alarm schlägt. Der Stolperstein hier ist der **Warmup-OOM**: Wenn Gewichte plus voller KV-Cache zusammen knapp über das VRAM-Budget gehen, kippt die Maschine genau in dem Moment, in dem du denkst, es läuft.\n\n## Schritt 5: den Endpoint absichern\n\nJetzt antwortet dein Endpoint, und genau das ist das Problem, solange ihn jeder erreichen kann. Dieser Schritt **trennt das Spielzeug vom Produkt**. Leg einen **Reverse Proxy** davor, der **TLS** terminiert und den nackten Engine-Port nicht ins Netz lässt. Davor gehört eine **API-Key-Authentifizierung**, sonst betreibt früher oder später jemand anderes dein Modell auf deine Rechnung: ein offener, ungesicherter Inferenz-Port ist kein theoretisches Risiko, sondern **wird im Internet aktiv gescannt**.\n\nDazu kommen Limits und ein bewusstes Überlastverhalten: **Rate-Limits pro Schlüssel**, ein **Concurrency-Limit** für die Engine, **Timeouts** und ein Request-Size-Limit für überlange Prompts. Entscheide bewusst, was bei Überlast passieren soll, eine begrenzte **Warteschlange**, die Requests puffert, oder ein sauberes **429**, das dem Client sagt, er möge es später versuchen. Der gefährlichste Verzicht ist hier das **fehlende Timeout**: Ohne es blockiert eine einzige hängende Anfrage einen GPU-Slot und zieht die Latenz für alle anderen hoch.\n\n## Schritt 6: Betrieb und Monitoring\n\nDer Schritt, den alle unterschätzen, und der über die Zeit **teuerste**, denn ein Endpoint ist kein Projekt mit Ende, sondern **ein System, das gepflegt werden will**. Sichtbar aufs Dashboard gehören **GPU-Auslastung** und **VRAM-Verbrauch**, **Latenz als p50 bis p99**, **Fehlerrate** und **Tokens pro Sekunde**, typischerweise mit **Prometheus und Grafana**, gespeist aus `nvidia-smi` beziehungsweise **DCGM** und den Metriken der Engine. Dazu kommen **Health-Checks**, die den Endpoint regelmässig anfragen, und Alarme, die anschlagen, bevor Nutzer etwas merken. Du willst die Kapazitätsgrenze an **steigender p99-Latenz** erkennen, nicht am Support-Ticket.\n\nDer zweite Teil des Betriebs ist **Update-Disziplin**. Engine-Versionen bringen Durchsatzgewinne und Bugfixes, Modelle werden abgelöst, und Sicherheits-Patches wollen zeitnah eingespielt sein. Jedes dieser Updates kann die **fragile Balance aus Treiber, CUDA und Engine** stören, weshalb du in einer **Staging-Umgebung** testest, bevor du Produktion anfasst. Diese Dauerpflege ist **der Block, der bleibt**, wenn der spannende Teil längst läuft.\n\n## Was das realistisch kostet\n\nDie Schritte 1 bis 4 schafft ein gutes Team an **ein bis zwei Tagen** bis zum ersten produktiven Token. Schritt 5 und vor allem Schritt 6, **Absicherung und stabiler Dauerbetrieb**, sind der Aufwand, der nie aufhört und der **die Rechnung dominiert**. Genau diesen Betriebsblock haben wir in den [Kosten eigener LLMs](\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten) auseinandergenommen, weil er fast immer unterschätzt wird.\n\nDeshalb die klare Weggabelung am Ende. Willst du die **volle Kontrolle**, geben wir dir die Hardware [bare metal](\u002Fde\u002Fbare-metal) mit **Root-Zugang**, und du baust die Schichten 1 bis 6 selbst, so wie hier beschrieben. Willst du den **fertigen, souveränen Endpoint**, aber nicht den Betrieb erben, übernehmen wir mit [Managed Inference](\u002Fde\u002Fmanaged-inference) genau diese sechs Schichten: du bekommst eine **OpenAI-kompatible API in der Schweiz** und musst dich um Treiberkonflikte, KV-Cache-Tuning und nächtliche Alarme nicht kümmern. Im Zweifel **rechnen wir deinen konkreten Fall durch** und sagen dir, welcher Weg sich für deine Last lohnt.","\u003Ch2>Die Frage hinter dem ersten Token\u003C\u002Fh2>\n\n\u003Cp>Ein Entwickler schrieb uns letzten Monat: „vLLM läuft, ich kriege Antworten, wir gehen nächste Woche live.“ Eine Woche später stand der Endpoint still, nicht weil das Modell schlecht war, sondern weil ein einziger Nutzer mit zwanzig parallelen Anfragen den Speicher gesprengt hatte, den auf der Demo niemand gerechnet hatte. Genau das ist der Punkt: Einen LLM-Endpoint zum \u003Cstrong>ersten Token\u003C\u002Fstrong> zu bringen ist an einem Nachmittag erledigt. Ihn so zu betreiben, dass er \u003Cstrong>produktive Last über Wochen\u003C\u002Fstrong> zuverlässig trägt, ist ein anderes Projekt. Die klare Frage lautet darum nicht „wie starte ich vLLM“, sondern „was liegt zwischen dem ersten Token auf meiner Maschine und einem Endpoint, dem ich Kunden zumute“. Dieser Beitrag geht den Weg in der Reihenfolge durch, in der er real passiert, und nennt an jedem Schritt den Fehler, der die meisten ersten Versuche kostet.\u003C\u002Fp>\n\n\u003Ch2>Schritt 1: Hardware und VRAM nüchtern ausrechnen\u003C\u002Fh2>\n\n\u003Cp>Bevor du irgendetwas installierst, \u003Cstrong>rechne nach, ob dein Modell überhaupt in den Speicher passt\u003C\u002Fstrong>. Der Speicher für die reinen Modellgewichte ergibt sich aus \u003Cstrong>Parameterzahl mal Bytes pro Parameter\u003C\u002Fstrong>: In FP16 sind das 2 Bytes, bei 8-bit-Quantisierung 1 Byte, bei 4-bit rund 0,5 Bytes. Ein 70B-Modell braucht also in FP16 etwa \u003Cstrong>140 GB\u003C\u002Fstrong>, in 4-bit nur noch rund \u003Cstrong>35 GB\u003C\u002Fstrong>. Auf diese reine Gewichtsgrösse schlägst du grob den \u003Cstrong>Faktor 1,2\u003C\u002Fstrong> auf, um KV-Cache, Aktivierungen und Overhead der Engine abzudecken, unter Last eher mehr, weil jeder gleichzeitige Request zusätzlichen \u003Cstrong>KV-Cache\u003C\u002Fstrong> belegt.\u003C\u002Fp>\n\n\u003Cp>Aus dieser Rechnung folgt direkt, was auf welche Maschine passt. Eine klassische Karte mit \u003Cstrong>24 GB\u003C\u002Fstrong> trägt bequem ein 7B- bis 13B-Modell in FP16 oder ein quantisiertes 30B-Modell, aber kein grosses Modell in voller Präzision. Eine \u003Ca href=\"\u002Fde\u002Fdgx-spark\">DGX Spark\u003C\u002Fa> mit \u003Cstrong>128 GB Unified Memory\u003C\u002Fstrong> trägt dagegen ein 70B-Modell in FP16 am Stück oder mehrere kleinere Modelle parallel, ohne dass du über PCIe nachladen musst. Die Modellwahl nach Aufgabe und Speicher haben wir in \u003Ca href=\"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl\">Welches offene Modell für welche Aufgabe\u003C\u002Fa> ausgeführt; an dieser Stelle zählt nur die nüchterne Rechnung, ob \u003Cstrong>Gewichte plus Cache plus Overhead\u003C\u002Fstrong> unter dein VRAM-Budget passen.\u003C\u002Fp>\n\n\u003Cp>Und genau hier liegt der teuerste Anfängerfehler: \u003Cstrong>nur die Gewichte zu rechnen und den KV-Cache zu vergessen\u003C\u002Fstrong>. Ein Modell, das beim Start mit einem einzelnen Request läuft, kippt unter zwanzig gleichzeitigen Anfragen in den \u003Cstrong>Out-of-Memory\u003C\u002Fstrong>, weil der Cache mit der Zahl und Länge der Sessions wächst, der Fall vom Entwickler oben. \u003Cstrong>Rechne den Betriebsfall, nicht den Demofall.\u003C\u002Fstrong>\u003C\u002Fp>\n\n\u003Ch2>Schritt 2: Treiber und Laufzeit sauber aufsetzen\u003C\u002Fh2>\n\n\u003Cp>Der unspektakuläre Teil, an dem trotzdem die meisten ersten Versuche scheitern. Du brauchst den passenden \u003Cstrong>NVIDIA-Treiber\u003C\u002Fstrong>, ein \u003Cstrong>CUDA-Toolkit\u003C\u002Fstrong> in einer Version, die deine Inference-Engine erwartet, und das \u003Cstrong>NVIDIA Container Toolkit\u003C\u002Fstrong>, wenn du (dringend empfohlen) in Containern arbeitest. Treiber und CUDA-Laufzeit müssen zueinander passen, und die Engine bringt ihrerseits eine Erwartung an die CUDA-Version mit. \u003Cstrong>Diese drei in Einklang zu halten\u003C\u002Fstrong> ist die eigentliche Aufgabe dieses Schritts.\u003C\u002Fp>\n\n\u003Cp>Warum \u003Cstrong>Container statt blanker Installation\u003C\u002Fstrong>? Eine native Installation von Treiber, CUDA und Engine direkt aufs Host-System reisst dir früher oder später die Versionen auseinander, sobald du etwas aktualisierst. Mit dem Container-Ansatz bleibt \u003Cstrong>nur der Treiber auf dem Host\u003C\u002Fstrong>, während CUDA-Laufzeit und Engine im Image gekapselt sind. Das macht Updates und Rollbacks beherrschbar und ist der Grund, warum die offiziellen Engine-Images genau so ausgeliefert werden. Der klassische Fehler bleibt trotzdem der \u003Cstrong>Versionskonflikt zwischen Treiber, CUDA und Engine\u003C\u002Fstrong>: ein zu alter Treiber für ein neues CUDA, oder eine Engine, die eine andere CUDA-Minor-Version erwartet. Prüf nach der Installation mit \u003Ccode>nvidia-smi\u003C\u002Fcode>, dass Treiber und CUDA-Version erkannt werden, und wähle das Engine-Image passend dazu, \u003Cstrong>statt blind das neueste Tag zu ziehen\u003C\u002Fstrong>.\u003C\u002Fp>\n\n\u003Ch2>Schritt 3: die Inference-Engine wählen und starten\u003C\u002Fh2>\n\n\u003Cp>Jetzt kommt die Schicht, die das Modell tatsächlich serviert, und welche Engine passt, \u003Cstrong>hängt am Lastprofil, nicht an der Mode\u003C\u002Fstrong>. Für einen Endpoint mit echter Parallel-Last ist \u003Cstrong>vLLM\u003C\u002Fstrong> meist die richtige Wahl: hoher Durchsatz dank \u003Cstrong>Continuous Batching\u003C\u002Fstrong>, eine \u003Cstrong>OpenAI-kompatible API\u003C\u002Fstrong> und Tensor-Parallelismus, um grosse Modelle über mehrere GPUs zu legen. Du startest es als Container, zeigst ihm die GPU und übergibst Modell sowie die zentralen Flags, nämlich \u003Ccode>--tensor-parallel-size\u003C\u002Fcode> für die Zahl der GPUs, \u003Ccode>--max-model-len\u003C\u002Fcode> für die maximale Kontextlänge und \u003Ccode>--gpu-memory-utilization\u003C\u002Fcode> für den Anteil des VRAM, den die Engine belegen darf. \u003Cstrong>Diese drei Schrauben bestimmen, wie viele Nutzer parallel passen.\u003C\u002Fstrong>\u003C\u002Fp>\n\n\u003Cp>Willst du dagegen nur schnell prüfen, ob ein Modell das Richtige tut, ist \u003Cstrong>Ollama\u003C\u002Fstrong> in Minuten startklar und läuft auch auf bescheidener Hardware. Für einen produktiven Endpoint mit vielen gleichzeitigen Nutzern ist es das \u003Cstrong>falsche Werkzeug\u003C\u002Fstrong>, weil das Batching schwächer ist. Die ganze Abwägung zwischen den Engines steht in \u003Ca href=\"\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich\">vLLM, Ollama oder TGI\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Cp>Beim Tuning lauert hier der Stolperstein: Ein zu hoch gesetztes \u003Ccode>--max-model-len\u003C\u002Fcode> \u003Cstrong>sprengt den KV-Cache-Speicher\u003C\u002Fstrong>, denn die Engine reserviert Cache für die volle Kontextlänge mal die Zahl paralleler Sequenzen, und schon ein scheinbar harmloser Wert lässt die Reservierung explodieren. Ebenso treibt ein zu hohes \u003Ccode>--gpu-memory-utilization\u003C\u002Fcode> die Maschine beim Warmup in den \u003Cstrong>OOM\u003C\u002Fstrong>. \u003Cstrong>Taste dich von konservativen Werten nach oben\u003C\u002Fstrong>, statt am Limit zu starten.\u003C\u002Fp>\n\n\u003Ch2>Schritt 4: das Modell laden\u003C\u002Fh2>\n\n\u003Cp>Jetzt bekommt die Engine das Modell, das sie servieren soll, samt der Entscheidung über die Präzision. \u003Cstrong>Prüf, ob eine quantisierte Variante reicht\u003C\u002Fstrong>, bevor du in mehr VRAM investierst: \u003Cstrong>AWQ\u003C\u002Fstrong> und \u003Cstrong>GPTQ\u003C\u002Fstrong> sind verbreitete 4-bit-Formate für GPU-Inferenz, \u003Cstrong>GGUF\u003C\u002Fstrong> ist das Format aus der llama.cpp-Welt und eher für CPU- oder gemischte Setups. Eine gute 4-bit-Quantisierung spart \u003Cstrong>drastisch Speicher\u003C\u002Fstrong> bei oft kaum spürbarem Qualitätsverlust und lässt dadurch mehr Nutzer parallel zu.\u003C\u002Fp>\n\n\u003Cp>Beim ersten Start lädt die Engine die Gewichte herunter und in den Speicher. Das \u003Cstrong>braucht Zeit\u003C\u002Fstrong>, belegt mehrere Dutzend Gigabyte auf der Platte und führt einen \u003Cstrong>Warmup\u003C\u002Fstrong> durch, bei dem CUDA-Graphen kompiliert werden. Plane diesen Vorlauf ein und häng ihn nicht an einen Health-Check, der schon nach Sekunden Alarm schlägt. Der Stolperstein hier ist der \u003Cstrong>Warmup-OOM\u003C\u002Fstrong>: Wenn Gewichte plus voller KV-Cache zusammen knapp über das VRAM-Budget gehen, kippt die Maschine genau in dem Moment, in dem du denkst, es läuft.\u003C\u002Fp>\n\n\u003Ch2>Schritt 5: den Endpoint absichern\u003C\u002Fh2>\n\n\u003Cp>Jetzt antwortet dein Endpoint, und genau das ist das Problem, solange ihn jeder erreichen kann. Dieser Schritt \u003Cstrong>trennt das Spielzeug vom Produkt\u003C\u002Fstrong>. Leg einen \u003Cstrong>Reverse Proxy\u003C\u002Fstrong> davor, der \u003Cstrong>TLS\u003C\u002Fstrong> terminiert und den nackten Engine-Port nicht ins Netz lässt. Davor gehört eine \u003Cstrong>API-Key-Authentifizierung\u003C\u002Fstrong>, sonst betreibt früher oder später jemand anderes dein Modell auf deine Rechnung: ein offener, ungesicherter Inferenz-Port ist kein theoretisches Risiko, sondern \u003Cstrong>wird im Internet aktiv gescannt\u003C\u002Fstrong>.\u003C\u002Fp>\n\n\u003Cp>Dazu kommen Limits und ein bewusstes Überlastverhalten: \u003Cstrong>Rate-Limits pro Schlüssel\u003C\u002Fstrong>, ein \u003Cstrong>Concurrency-Limit\u003C\u002Fstrong> für die Engine, \u003Cstrong>Timeouts\u003C\u002Fstrong> und ein Request-Size-Limit für überlange Prompts. Entscheide bewusst, was bei Überlast passieren soll, eine begrenzte \u003Cstrong>Warteschlange\u003C\u002Fstrong>, die Requests puffert, oder ein sauberes \u003Cstrong>429\u003C\u002Fstrong>, das dem Client sagt, er möge es später versuchen. Der gefährlichste Verzicht ist hier das \u003Cstrong>fehlende Timeout\u003C\u002Fstrong>: Ohne es blockiert eine einzige hängende Anfrage einen GPU-Slot und zieht die Latenz für alle anderen hoch.\u003C\u002Fp>\n\n\u003Ch2>Schritt 6: Betrieb und Monitoring\u003C\u002Fh2>\n\n\u003Cp>Der Schritt, den alle unterschätzen, und der über die Zeit \u003Cstrong>teuerste\u003C\u002Fstrong>, denn ein Endpoint ist kein Projekt mit Ende, sondern \u003Cstrong>ein System, das gepflegt werden will\u003C\u002Fstrong>. Sichtbar aufs Dashboard gehören \u003Cstrong>GPU-Auslastung\u003C\u002Fstrong> und \u003Cstrong>VRAM-Verbrauch\u003C\u002Fstrong>, \u003Cstrong>Latenz als p50 bis p99\u003C\u002Fstrong>, \u003Cstrong>Fehlerrate\u003C\u002Fstrong> und \u003Cstrong>Tokens pro Sekunde\u003C\u002Fstrong>, typischerweise mit \u003Cstrong>Prometheus und Grafana\u003C\u002Fstrong>, gespeist aus \u003Ccode>nvidia-smi\u003C\u002Fcode> beziehungsweise \u003Cstrong>DCGM\u003C\u002Fstrong> und den Metriken der Engine. Dazu kommen \u003Cstrong>Health-Checks\u003C\u002Fstrong>, die den Endpoint regelmässig anfragen, und Alarme, die anschlagen, bevor Nutzer etwas merken. Du willst die Kapazitätsgrenze an \u003Cstrong>steigender p99-Latenz\u003C\u002Fstrong> erkennen, nicht am Support-Ticket.\u003C\u002Fp>\n\n\u003Cp>Der zweite Teil des Betriebs ist \u003Cstrong>Update-Disziplin\u003C\u002Fstrong>. Engine-Versionen bringen Durchsatzgewinne und Bugfixes, Modelle werden abgelöst, und Sicherheits-Patches wollen zeitnah eingespielt sein. Jedes dieser Updates kann die \u003Cstrong>fragile Balance aus Treiber, CUDA und Engine\u003C\u002Fstrong> stören, weshalb du in einer \u003Cstrong>Staging-Umgebung\u003C\u002Fstrong> testest, bevor du Produktion anfasst. Diese Dauerpflege ist \u003Cstrong>der Block, der bleibt\u003C\u002Fstrong>, wenn der spannende Teil längst läuft.\u003C\u002Fp>\n\n\u003Ch2>Was das realistisch kostet\u003C\u002Fh2>\n\n\u003Cp>Die Schritte 1 bis 4 schafft ein gutes Team an \u003Cstrong>ein bis zwei Tagen\u003C\u002Fstrong> bis zum ersten produktiven Token. Schritt 5 und vor allem Schritt 6, \u003Cstrong>Absicherung und stabiler Dauerbetrieb\u003C\u002Fstrong>, sind der Aufwand, der nie aufhört und der \u003Cstrong>die Rechnung dominiert\u003C\u002Fstrong>. Genau diesen Betriebsblock haben wir in den \u003Ca href=\"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten\">Kosten eigener LLMs\u003C\u002Fa> auseinandergenommen, weil er fast immer unterschätzt wird.\u003C\u002Fp>\n\n\u003Cp>Deshalb die klare Weggabelung am Ende. Willst du die \u003Cstrong>volle Kontrolle\u003C\u002Fstrong>, geben wir dir die Hardware \u003Ca href=\"\u002Fde\u002Fbare-metal\">bare metal\u003C\u002Fa> mit \u003Cstrong>Root-Zugang\u003C\u002Fstrong>, und du baust die Schichten 1 bis 6 selbst, so wie hier beschrieben. Willst du den \u003Cstrong>fertigen, souveränen Endpoint\u003C\u002Fstrong>, aber nicht den Betrieb erben, übernehmen wir mit \u003Ca href=\"\u002Fde\u002Fmanaged-inference\">Managed Inference\u003C\u002Fa> genau diese sechs Schichten: du bekommst eine \u003Cstrong>OpenAI-kompatible API in der Schweiz\u003C\u002Fstrong> und musst dich um Treiberkonflikte, KV-Cache-Tuning und nächtliche Alarme nicht kümmern. Im Zweifel \u003Cstrong>rechnen wir deinen konkreten Fall durch\u003C\u002Fstrong> und sagen dir, welcher Weg sich für deine Last lohnt.\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,87,98,108,116,124,131,137,143,149,155,161,167,173,175,181,187,194],{"path":78,"slug":79,"title":80,"summary":81,"image":53,"publication_date":82,"big5_category":83,"primary_hub":53,"cluster":53,"pillar":53,"hubs":84},"\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","comparisons",[85],{"slug":86,"title":13},"managed-inference",{"path":88,"slug":89,"title":90,"summary":91,"image":53,"publication_date":82,"big5_category":92,"primary_hub":53,"cluster":53,"pillar":53,"hubs":93},"\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",[94,96],{"slug":49,"title":95},"Bare Metal GPU mit Root-Zugriff",{"slug":97,"title":5},"dgx-spark",{"path":99,"slug":100,"title":101,"summary":102,"image":53,"publication_date":82,"big5_category":103,"primary_hub":53,"cluster":53,"pillar":53,"hubs":104},"\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",[105],{"slug":106,"title":107},"agents","Hermes Agents as a Service",{"path":109,"slug":110,"title":111,"summary":112,"image":53,"publication_date":82,"big5_category":113,"primary_hub":53,"cluster":53,"pillar":53,"hubs":114},"\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",[115],{"slug":86,"title":13},{"path":117,"slug":118,"title":119,"summary":120,"image":53,"publication_date":82,"big5_category":121,"primary_hub":53,"cluster":53,"pillar":53,"hubs":122},"\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",[123],{"slug":86,"title":13},{"path":125,"slug":126,"title":127,"summary":128,"image":53,"publication_date":129,"big5_category":83,"primary_hub":53,"cluster":53,"pillar":53,"hubs":130},"\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":132,"slug":133,"title":134,"summary":135,"image":53,"publication_date":129,"big5_category":46,"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.",[],{"path":138,"slug":139,"title":140,"summary":141,"image":53,"publication_date":129,"big5_category":113,"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":129,"big5_category":113,"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":129,"big5_category":46,"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":113,"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":113,"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":103,"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":35,"slug":36,"title":43,"summary":44,"image":53,"publication_date":45,"big5_category":46,"primary_hub":53,"cluster":53,"pillar":53,"hubs":174},[],{"path":176,"slug":177,"title":178,"summary":179,"image":53,"publication_date":45,"big5_category":92,"primary_hub":53,"cluster":53,"pillar":53,"hubs":180},"\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":182,"slug":183,"title":184,"summary":185,"image":53,"publication_date":45,"big5_category":83,"primary_hub":53,"cluster":53,"pillar":53,"hubs":186},"\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich","vllm-ollama-tgi-vergleich","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.",[],{"path":188,"slug":189,"title":190,"summary":191,"image":53,"publication_date":192,"big5_category":83,"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":121,"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.",[]]