Ein LLM auf Serverless GPU deployen: 5 Plattformen, echte Preise, ehrliche Cold Starts

Ein LLM auf Serverless GPU deployen: 5 Plattformen, echte Preise, ehrliche Cold Starts

RunPod berechnet 2,72 $/Std. für eine A100 80GB. Ihr Endpoint bekommt zwölf Requests vor dem Mittagessen. Die GPU steht die anderen 23 Stunden leer und rechnet die ganze Zeit weiter. Deployen Sie ein LLM auf Serverless GPU, und Sie zahlen nur, während ein Request läuft. Fünf Plattformen bieten genau das an. Sie rechnen in fünf verschiedenen Einheiten ab. Niemand normalisiert sie.

Eine leere GPU kostet exakt so viel wie eine ausgelastete.

Die wichtigsten Erkenntnisse

• Serverless GPU rechnet nur ab, während ein Request läuft, und skaliert dazwischen auf null.
• Eine GPU pro Instanz auf Cloud Run; 70B-Modelle brauchen mehrere GPUs, daher kann Serverless sie meist nicht hosten.
• Modellgewichte liegen im Image, auf einem Netzwerk-Volume oder werden bei jedem Cold Start neu heruntergeladen.
• Ein Cold Start besteht aus drei Dingen: Container-Boot, Laden der Gewichte, Engine-Init. Nur der erste ist schnell.
• Unterhalb von grob 47.000 Requests pro Tag schlägt Scale-to-zero eine gemietete 24/7-GPU.

Was bedeutet „Serverless GPU" eigentlich für ein LLM?

Eine Serverless-GPU-Plattform führt Ihren Inferenz-Container auf geteilter GPU-Hardware aus, startet ihn, wenn ein Request eintrifft, und skaliert auf null, sobald der Traffic stoppt. Sie zahlen pro Sekunde (oder pro Minute oder pro Stunde, je nach Anbieter) nur, solange der Container lebt. Keine Leerlauf-Rechnung. Keine reservierte Instanz.

Die Abrechnungseinheit unterscheidet sich je nach Anbieter, weshalb der nächste Abschnitt alles in $/GPU-Stunde normalisiert.

Zwei Einschränkungen überraschen viele. Erstens erlaubt Google Cloud Run maximal eine GPU pro Instanz. Damit liegt Ihre VRAM-Obergrenze bei einer einzelnen Karte. Zweitens bedeutet „serverless" nicht persistenten Zustand. Es gibt keinen langlebigen Prozess, der Ihre Gewichte zwischen den Requests im RAM hält. Wenn der Container stirbt, stirbt alles im Speicher mit. Genau diese eine Tatsache treibt die Speicherentscheidung im Abschnitt zu Modellgewichten unten.

Serverless heißt nicht ohne Server. Es heißt ohne Server zwischen Ihren Requests, und genau dort verschwinden Ihre Modellgewichte.

Welche Serverless-GPU-Plattform sollten Sie wählen? (Preise 2026, nebeneinander)

Wir verkaufen keine dieser Plattformen und nehmen von keiner Affiliate-Einnahmen. Von den sieben Artikeln, die um diese Suchanfrage und ihre nahen Varianten konkurrieren, stammen vier von einem Unternehmen, das Serverless GPUs verkauft. Diese Tabelle nicht.

Alle Preise stammen von den Pricing-Seiten der Anbieter selbst, abgelesen am 30.07.2026. Preise ändern sich; prüfen Sie neu, bevor Sie sich festlegen.

Die Normalisierungs-Rechnung, einmal gezeigt, damit Sie sie nachprüfen können: Modal A100 80GB bei $0,000694/s mal 3600 Sekunden ergibt $2,4984/Std. Beam: $0,000625 mal 3600 ergibt $2,25/Std. Baseten: $0,06667/Min. mal 60 ergibt $4,00/Std. Diese 1,8-fache Spanne zwischen Beam und Baseten für dieselbe A100 ist real, und sie versteckt sich offen vor aller Augen, weil niemand dieselbe Einheit veröffentlicht.

Drei Einschränkungen. Beams Pricing-Seite sagt ausdrücklich, dass sie Server-Spin-up oder das Laden des Container-Images nicht abrechnet. Die Pricing-FAQ von Baseten beantwortet „Do I pay for idle time on Baseten?" mit „No, you do not pay for idle time" und ergänzt dann, dass abrechenbare Zeit „the time your model is actively deploying, scaling up or down, or making predictions" ist; der Zähler deckt also mehr ab als die Vorhersagezeit, und genau der Teil gehört ins Budget. RunPod veröffentlicht auf seiner Pricing-Seite Stundenpreise und keine Cold-Start-Zahl.

Wenn Modal Ihre Wahl ist, haben wir die vollständige Modal-Anleitung separat geschrieben.

Passt Ihr Modell überhaupt? VRAM, Ein-GPU-Limits und Quota

Kann man ein 70B-Modell auf einer Serverless GPU betreiben? Meist nicht. Bei FP16 braucht 70B rund 140 GB VRAM. Cloud Run deckelt bei einer GPU pro Instanz (maximal 96 GB auf RTX PRO 6000). Die Rechnung geht ohne Quantisierung (FP8/GGUF) oder eine Multi-GPU-Plattform nicht auf.

Das Standard-Quota von Cloud Run liegt bei 3 L4-GPUs pro Region und Projekt (RTX PRO 6000 wird separat als 3.000 milliGPU gewährt), verteilt auf sechs L4-Regionen: asia-southeast1, asia-south1, europe-west1, europe-west4, us-central1, us-east4. Das ist die Cloud-Run-Hälfte der Antwort zur Datenresidenz für alle, die nach Serverless GPU in Europa fragen; Modal und RunPod dokumentieren ihre eigenen EU-Regionen, und die FAQ hat den Rest.

Der Cloud-Run-Walkthrough von Ismaili Simba auf dev.to (April 2025) berichtet, dass die Quota-Anfrage „can take some time (up to 5 working days) to be approved", und dass „the L4 GPUs available on Cloud Run have a limit of 16GB RAM". Planen Sie diese Verzögerung ein.

Für die VRAM-Dimensionierung je Modell siehe unseren Leitfaden zu den VRAM-Anforderungen.

Wo liegen Ihre Modellgewichte (und was kostet das)?

Ein Reddit-Thread vom November 2024, der bei unserer Prüfung am 30.07.2026 für genau diese Suchanfrage immer noch auf Platz 5 bei Google stand, fragt wörtlich:

„I have been unable to find rate for storing the 80 gb model… What's an alternative if I don't want to download the model at every api calls (pod provisioned at call then closed)? … Why do these platforms not list model storage cost?"

Drei Antworten mit niedrigem Score, keine davon eine Antwort. Als wir diese Suche am 30.07.2026 ausführten, enthielten die Top Ten immer noch diesen zwei Jahre alten Thread, der fragt, was Modellspeicherung kostet. Niemand im Thread hat es beantwortet. Beide Plattformen veröffentlichen den Satz. Bei Modal sind es $0,09 pro GiB pro Monat, wobei das erste TiB frei ist, sodass dieser 80-GB-Checkpoint mit $0,00 zu Buche schlägt. Bei RunPod sind es $0,07 pro GB pro Monat für Netzwerkspeicher unter 1 TB, was denselben Checkpoint auf rund $5,60 im Monat bringt.

Die dritte Zeile ist der Fehlermodus. Ein Review der TU München zu ServerlessLLM von 2024 (arXiv 2411.15664) berichtet, dass LLaMA-2-70B (130 GB) über 26 Sekunden braucht, um bei 5 GB/s gezogen zu werden, plus rund 84 Sekunden, um auf 8 GPUs geladen zu werden, gegenüber rund 100 ms Token-Generierung. Diese Zahlen werden in jenem Review zitiert, nicht von ihm gemessen.

Die Pricing-Seite von RunPod führt einen Storage-Abschnitt: Container-Disk $0,10/GB/Mo., Volume-Disk $0,10/GB/Mo. laufend und $0,20/GB/Mo. im Leerlauf, Netzwerkspeicher $0,07/GB/Mo. unter 1 TB und $0,05/GB/Mo. darüber, Hochleistungs-Netzwerkspeicher $0,14/GB/Mo. Die Zahl existiert. Sie steht nur nicht neben den Serverless-Pro-GPU-Sätzen, die ein Leser vergleicht, wenn ihm die Frage einfällt, und auch nicht im Endpoint-Konfigurationsfluss. Ein Auffindbarkeits-Problem, kein Geheimhaltungs-Problem, und genug, um die Frage zwei Jahre später am Leben zu halten.

# Point the Hugging Face cache at a mounted network volume
# so weights persist across cold starts (RunPod / Modal pattern)
export HF_HOME=/workspace/hf-cache
export TRANSFORMERS_CACHE=/workspace/hf-cache
export HF_HUB_ENABLE_HF_TRANSFER=1

# Alternative: bake weights into the image at build time
FROM vllm/vllm-openai:latest
COPY ./model-weights /models/qwen3-27b-fp8
ENV MODEL_NAME=/models/qwen3-27b-fp8
# Downside: 30+ GB image, full rebuild to change models

Wenn Sie noch kein Modell gewählt haben, unser 2026er-Roundup zu Open-Weights-Modellen dimensioniert jede Option für das Deployment.

Deployen: vLLM auf RunPod Serverless, End to End

Sechs Schritte von null zu einem aufrufbaren Endpoint. Prüfen Sie jeden gegen die vLLM-Anleitung von RunPod (aktualisiert am 22. Juni 2026), die keine Preise veröffentlicht.

1. Modell wählen. Wählen Sie ein Open-Weights-Modell, das zu Ihrer GPU passt (siehe VRAM-Tabelle oben). Wenn es auf Hugging Face zugangsbeschränkt ist, erzeugen Sie zuerst ein Access-Token.

2. Serverless-Endpoint anlegen. Wählen Sie in der Konsole von RunPod Serverless aus, nehmen Sie die vLLM-Worker-Vorlage und wählen Sie Ihre GPU-Stufe.

3. Die entscheidenden Umgebungsvariablen setzen.

MODEL_NAME=Qwen/Qwen3.6-27B-FP8
MAX_MODEL_LEN=32768
GPU_MEMORY_UTILIZATION=0.90
DTYPE=auto

Ein falsches MODEL_NAME bedeutet einen 404 beim Boot. Ein zu hoch für Ihren VRAM gesetztes MAX_MODEL_LEN bedeutet OOM vor dem ersten Token. GPU_MEMORY_UTILIZATION über 0,95 lässt keinen Puffer für KV-Cache-Spitzen.

1. Min/Max-Worker und Idle-Timeout setzen. Min-Worker auf 0 gibt Ihnen Scale-to-zero (und Cold Starts). Min-Worker auf 1 beseitigt Cold Starts, rechnet aber durchgehend ab. Der Cold-Start-Abschnitt unten arbeitet diesen Trade-off durch.

2. Netzwerk-Volume anhängen, das Sie im Abschnitt zu Modellgewichten gewählt haben, oder den Image-Bake-Pfad akzeptieren. Überspringen Sie das, lädt jeder Cold Start den Checkpoint neu herunter.

3. Den ersten Request abfeuern. Lesen Sie die Endpoint-ID aus der Konsole und bestätigen Sie, dass Tokens zurückkommen.

curl -X POST "https://api.runpod.ai/v2/${ENDPOINT_ID}/runsync" \
  -H "Authorization: Bearer ${RUNPOD_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "input": {
      "messages": [{"role": "user", "content": "Explain cold starts in one sentence."}],
      "max_tokens": 60
    }
  }'

Wenn Sie die Serving-Engine selbst abwägen, haben wir vLLM und SGLang bei Durchsatz und Latenz verglichen.

Wie rufen Sie den Endpoint aus Ihrer App auf?

Jede Plattform auf der Shortlist spricht eine OpenAI-kompatible API. Ein Python-Snippet funktioniert überall. Der Anbieterwechsel ist eine Änderung der base_url, kein Rewrite. Das rückt „welcher Anbieter" von einer Lock-in-Entscheidung in eine Konfigurations-Entscheidung.

import os

from openai import OpenAI

ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]

client = OpenAI(
    base_url=f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
    api_key=os.environ["RUNPOD_API_KEY"],
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.6-27B-FP8",
    messages=[{"role": "user", "content": "What is scale to zero?"}],
    max_tokens=120,
)
print(response.choices[0].message.content)

# Same code, different provider. One line changes.
ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]

PROVIDERS = {
    "runpod": f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
    "modal": "https://your-app--your-func.modal.run/v1",
    "beam": "https://your-beam-endpoint/v1",
}

client = OpenAI(base_url=PROVIDERS["modal"], api_key="your-key")

Wenn jeder Anbieter den Dialekt von OpenAI spricht, hört „welcher Serverless-GPU-Anbieter" auf, eine Architektur-Entscheidung zu sein, und wird zu einer Zeile Konfiguration.

Sobald Sie mehrere Endpoints haben, deckt unser LLM-Gateway-Vergleich Routing und Failover ab. Für ein leichteres Setup ergänzt ein LiteLLM-Proxy Retries und Logging.

Welchen Cold Start sehen Sie tatsächlich?

Für ein 7B-Modell auf Serverless GPU erwarten Sie bei einem echten Cold Start 10 bis 30 Sekunden (Container-Boot plus Laden der Gewichte plus Engine-Init), basierend auf Berichten von Praktikern. Anbieter-Dokumentationen nennen 1 bis 5 Sekunden allein für den Container-Boot. Die Lücke zwischen diesen Zahlen ist Ihr Checkpoint, der ein Netzwerk überquert.

Die Produktseite von RunPod behauptet FlashBoot-Cold-Starts unter 200 ms (eine Anbieter-Angabe, keine Messung). Ein Praktiker in r/LLMDevs berichtet: „cold starts in my experience aren't great … I would say ~ 10 - 30 s", und ergänzt „most of my experience revolves around diffusion models though." Beides stimmt. Sie messen verschiedene Dinge.

Die Cold-Start-Zahl sind drei gestapelte Zahlen:

1. Container-Boot. Die Docs von Modal: „Containers boot in about one second." Cloud Run: Instanzen mit vorinstallierten Treibern „start in approximately 5 seconds."

2. Laden der Gewichte. Der Teil, den niemand bewirbt. Ein Review der TU München zu ServerlessLLM von 2024 (arXiv 2411.15664) setzt LLaMA-2-70B mit über 26 Sekunden für das Ziehen plus rund 84 Sekunden für das Laden auf 8 GPUs an.

3. Engine-Init. vLLM-Graph-Capture und Warm-up. Logesh Umapathi hat gemessen, dass Qwen3.6-27B-FP8 auf einer A100-80GB von 460 s Baseline auf 219 s mit Eager Mode und auf rund 70 s mit vLLM-Sleep-Mode plus Modal-GPU-Snapshots geht. Das ist das 6,5-Fache, veröffentlicht am 17. Mai 2026.

Unsere Interpretation der veröffentlichten Daten: Anbieter-Zahlen messen den Container. Praktiker-Zahlen messen den ganzen Request. Zwischen diesen beiden Stoppuhren sitzen 80 GB Gewichte, die ein Netzwerk überqueren. Die Spalte Typ ist der Punkt.

Was zu tun ist: vLLM-Sleep-Mode, GPU-Snapshots und das Feintuning des Scaledown-Fensters. Der Standard-Idle von Modal liegt bei 60 Sekunden (konfigurierbar 2s-20min). Ein warmer Worker beseitigt Cold Starts, rechnet aber als Always-on ab.

# Modal scaledown config (illustrative)
# A 60s window means you pay for 60 idle seconds per burst.
# A warm worker (min_containers=1) costs ~$2.50/hr on A100 80GB, 24/7.
@app.function(
    gpu="A100",
    scaledown_window=60,  # seconds idle before shutdown
    # min_containers=1,   # uncomment to kill cold starts; costs $60/day
)

Ist Serverless GPU günstiger als eine Always-on-GPU?

Serverless GPU ist günstiger, wenn Ihre GPU den Großteil des Tages leersteht. Bei 3.000 Requests/Tag mit je 2 Sekunden im Schnitt auf einer A100 80GB kostet Serverless grob $4,17/Tag gegenüber $65,28/Tag für eine gemietete, rund um die Uhr laufende GPU. Der Break-even ist eine Frage des Duty Cycle, nicht der Menge.

Annahmen (unsere, offengelegt, damit Sie sie nachrechnen können): A100 80GB zu $2,50/Std. von Modal, 2 Sekunden mittlere GPU-Zeit pro Request, gemietete GPU zu $2,72/Std. von RunPod rund um die Uhr, gehostete Token-API zu $0,40/1M Tokens (ein veröffentlichter Mittelfeld-Satz) und rund 1.000 Tokens pro Request.

Der Break-even liegt bei rund 47.000 Requests/Tag. Darunter gewinnt Serverless. Eine gehostete Token-API schlägt bei geringer Menge mit einem Commodity-Modell beide. Der Break-even hängt nicht davon ab, wie viele Requests Sie bekommen. Er hängt davon ab, wie viele Stunden Ihre GPU mit Nichtstun verbringt.

Die Analyse von BentoML vom August 2024 rahmt diesen Trade-off gut, auch wenn ihre Preisbeispiele aus der GPT-3.5-turbo-Ära stammen und zwei Jahre alt sind.

Für die Kosten einer gehosteten Token-API bei Ihrer Menge siehe unser LLM-API-Preisvergleich. Um die Kosten pro Request auf der Inferenz-Seite zu senken, spart Prompt-Caching typischerweise 30-60 % bei wiederholtem Kontext.

# Break-even calculator: adjust these and re-run
REQUESTS_PER_DAY = 3000
SECONDS_PER_REQUEST = 2
SERVERLESS_RATE_HR = 2.50   # Modal A100 80GB
RENTED_RATE_HR = 2.72       # RunPod A100 80GB, 24/7

serverless_daily = REQUESTS_PER_DAY * SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR
rented_daily = RENTED_RATE_HR * 24

print(f"Serverless: ${serverless_daily:.2f}/day")
print(f"Rented 24/7: ${rented_daily:.2f}/day")
print(f"Crossover: {int(RENTED_RATE_HR * 24 / (SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR))} req/day")

Wann Serverless GPU die falsche Wahl ist

• Anhaltend hoher Traffic. Über rund 47.000 Requests/Tag zu diesen Sätzen kippt der Duty Cycle, und eine gemietete GPU ist pro Request günstiger.
• Harte Sub-Sekunden-SLOs auf einem kalten Pfad. Kein Snapshot-Trick macht einen ersten Request instantan. Halten Sie einen warmen Worker oder mieten Sie die Kiste.
• 70B+-Modelle, die mehrere GPUs brauchen. Eine GPU pro Instanz auf Cloud Run beendet dieses Gespräch.
• Strenge Datenresidenz. Sechs L4-Regionen sind auf Cloud Run die ganze Auswahl.
• Request-Ökonomie, die gegen einen bereits bezahlten Worker-Slot verliert. Wenn Sie freie GPU-Kapazität haben, kostet zusätzliche Inferenz nichts extra.

Wenn Ihre GPU sechzehn Stunden am Tag ausgelastet ist, ist Serverless die teure Option, und wer Ihnen etwas anderes erzählt, verkauft Serverless.

Für den Local-First-Pfad siehe unseren Leitfaden zu lokalen LLM-Tools.

Häufig gestellte Fragen

Was ist eine Serverless GPU?

Eine Serverless-GPU-Plattform führt Ihren Modell-Container auf geteilter Hardware aus, skaliert zwischen den Requests auf null und rechnet nur aktive Rechenzeit ab. Sie bekommen einen Inferenz-Endpoint, ohne eine persistente GPU-Instanz zu verwalten. Der Trade-off ist eine Cold-Start-Verzögerung beim Spin-up.

Was kostet es, ein LLM auf einer Serverless GPU zu betreiben?

Eine A100 80GB läuft für $2,25/Std. auf Beam, $2,50/Std. auf Modal, $2,72/Std. auf RunPod (geprüft am 30.07.2026). Ihre Rechnung hängt vom Duty Cycle ab: 3.000 Requests/Tag zu je 2 s kosten rund $4/Tag auf Modal. Speicher kommt mit $0,09/GiB/Monat dazu, wobei 1 TiB frei ist.

Zahle ich für das Speichern der Modellgewichte?

Ja, aber es ist günstig. Modal berechnet $0,09/GiB/Monat bei 1 TiB/Monat frei, sodass ein 80-GB-Checkpoint nichts kostet. Die Pricing-Seite von RunPod führt Netzwerkspeicher mit $0,07/GB/Monat unter 1 TB, also rund $5,60/Monat für dieselben 80 GB.

Wird mein Modell bei jedem Request neu heruntergeladen?

Nur wenn nichts gecacht ist. Gewichte auf einem persistenten Volume oder ins Image gebacken überleben Cold Starts. Zeigen Sie den Hugging-Face-Cache auf flüchtigen Speicher, lädt ein 130-GB-Modell bei jedem Spin-up neu. Das ist der Fehlermodus, den es zu vermeiden gilt.

Wie lang ist der Cold Start für ein 7B-Modell?

Erwarten Sie 10-30 Sekunden bei einem echten Cold Start, laut Berichten von Praktikern (r/LLMDevs, Dez. 2024). Der Container bootet in 1-5 s (Docs von Modal, Cloud Run). Der Rest ist Laden der Gewichte und Engine-Init. Mit Snapshots und Sleep-Mode hat Umapathi rund 70 s für ein 27B-Modell gemessen, herunter von 460 s.

Kann ich ein 70B-Modell auf Serverless GPU betreiben?

Meist nicht. Ein 70B-Modell bei FP16 braucht rund 140 GB VRAM. Cloud Run erlaubt eine GPU pro Instanz (maximal 96 GB). Sie bräuchten FP8-Quantisierung, um auf eine einzelne 80-GB-Karte zu passen, oder eine Multi-GPU-Plattform. Die meisten Serverless-Oberflächen deckeln bei einer GPU.

Ist Serverless GPU günstiger als eine GPU 24/7 zu mieten?

Unterhalb von rund 47.000 Requests/Tag (bei 2 s/Request auf einer A100 80GB), ja. Serverless rechnet nur aktive Sekunden ab; eine gemietete GPU rechnet unabhängig davon 24 Stunden ab. Darüber gewinnt die gemietete GPU. Eine gehostete Token-API schlägt bei geringer Menge beide. Siehe die Break-even-Tabelle oben.

Kann ich ein LLM auf Serverless GPU kostenlos deployen?

Modal gibt $30/Monat Gratis-Guthaben (Starter). Beam gibt $30/Monat. Das $300-Guthaben für neue GCP-Konten deckt die Cloud-Run-GPU-Nutzung. Genug zum Prototypen, nicht für Produktions-Traffic. Keine Plattform bietet einen dauerhaften Gratis-Tier für GPU-Inferenz.

Welche Serverless-GPU-Anbieter sind in Europa verfügbar?

Cloud Run bedient L4-GPUs in europe-west1 (Belgien) und europe-west4 (Niederlande). Modal dokumentiert die EU-Regionsauswahl (eu-west, eu-north, eu-south) zu Preisen vom 1,5-1,75-Fachen der Basissätze. RunPod nennt europäische Rechenzentren einschließlich EU-NL-1 und EU-FR-1. Pinnen Sie die Region explizit; keiner von ihnen steht standardmäßig auf der EU.

Brauche ich Docker, um ein LLM auf Serverless GPU zu deployen?

Nicht immer. RunPod bietet vorgebaute vLLM-Worker-Vorlagen, die Docker überspringen. Modal baut Container aus einer Python-Image-Definition im Code. Für eigene Abhängigkeiten schreiben Sie ein Dockerfile. Für Standard-vLLM-Serving funktioniert der vorgebaute Pfad in Minuten.

Fazit

Fünf Plattformen, fünf Abrechnungseinheiten, eine normalisierte Tabelle. Die Entscheidung ist einfacher, als die Anbieter-Seiten sie aussehen lassen:

• Wählen Sie Ihre GPU nach VRAM, nicht nach Marke.
• Legen Sie Ihre Gewichte auf ein Volume, nicht ins Image, außer Sie wechseln nie Modelle.
• Erwarten Sie 10-30 Sekunden Cold Start und planen Sie darum herum.
• Unterhalb von rund 47.000 Requests/Tag gewinnt Scale-to-zero bei den Kosten.
• Die Serving-Engine hinter dem Endpoint ist austauschbar; die base_url ist eine Zeile.

Sie haben einen aufrufbaren Endpoint. Als Nächstes: Was sitzt davor, wenn Sie Routing und Failover brauchen? Unser LLM-Gateway-Vergleich beantwortet das. Oder sprechen Sie mit uns über Ihr Setup.