Llama ist ein Modell mit offenen Gewichten; seine Preise lassen sich nicht mit einer offiziellen Preisliste beantworten. Am 6. Juli 2026 hat Meta die öffentliche Vorschau der Llama API eingestellt; die alte Schnittstelle meldet das Dienstende. Die Modellgewichte sind nicht betroffen und weiterhin über die Downloadseite von Meta und Hugging Face verfügbar. Meta empfiehlt in der Mitteilung die Migration zu Drittanbietern, die Llama unterstützen.

Wer heute nach „Llama-API-Preisen“ fragt, muss eigentlich fragen: Welchen Zugangsweg nutzen Sie? Drittanbieter rechnen nach Tokens ab, Cloud-Anbieter nach Vertrag und Nutzung, Selbsthosting nach GPU-Stunden, Aggregations-Gateways nach umgerechnetem Guthaben. Die Rechnungsstrukturen unterscheiden sich, ein direkter Vergleich „Preis pro Million Tokens“ führt leicht zu falschen Schlüssen. Dieser Beitrag behandelt Kostenstrukturen und Methoden; konkrete Preise richten sich nach den Seiten der Plattformen und den Modellpreisen auf dieser Website.

Hinweis: Llama ist eine Marke von Meta Platforms, Inc. Dieser Beitrag dient der technischen Einordnung und begründet keine Zugehörigkeits-, Vertretungs- oder Kooperationsbeziehung zu Meta. Modellversionen, Lizenzen und Plattformpreise können sich ändern; vor der Beschaffung die Originalseiten prüfen.

1. Welche Zugangswege es nach dem Ende der Meta-Llama-API gibt

Der erste Weg ist eine gehostete Drittanbieter-API. AWS Bedrock, Azure AI Foundry und Google Cloud Vertex AI bieten Llama-Modelle; Together AI, Fireworks, DeepInfra, Novita und Parasail bieten nach Tokens abgerechnete Dienste. Unterstützte Modelle, Kontextlängen, Quantisierung und Regionen unterscheiden sich.

Der zweite Weg ist Selbsthosting. Die Gewichte werden auf eigenen oder gemieteten GPUs mit vLLM, SGLang oder TGI betrieben; für kleine Tests eignen sich auch llama.cpp oder Ollama. Gekauft werden Rechenleistung und Betrieb, kein API-Kontingent.

Der dritte Weg ist ein OpenAI-kompatibles Aggregations-Gateway. Plattformen wie das ZSQH AI Gateway bündeln mehrere Modelle in einer Schnittstelle und einem Guthabenkonto; das passt zu Teams in China, die in Yuan abrechnen und eine einheitliche Verbrauchsansicht brauchen.

Kein Weg ist grundsätzlich besser, nur passender. Vor der Wahl Modelllebenszyklus, Stabilität des Aufrufvolumens und Betriebskompetenz des Teams prüfen.

2. Woraus sich die Rechnung der vier Wege zusammensetzt

Weg Abrechnungseinheit Typische Bestandteile Geeignet für Leicht übersehene Kosten
Gehostete Drittanbieter-API Eingabe- und Ausgabe-Tokens getrennt Tokenverbrauch, Cache, Batch Schneller Start, kein GPU-Team Kontextwachstum, Retries, Warteschlange
Cloud-Anbieter Nutzungsbasierte Tokens oder reservierter Durchsatz Nutzungsgebühr, Verbrauchsverpflichtung, Support, Netz und Speicher Bestehender Cloud-Vertrag, Compliance Mindestumsatz, regionenübergreifender Traffic, Modellabschaltung
Selbsthosting GPU-Stunden oder Monatspauschale GPU-Miete, Speicher, Netz, Betriebspersonal Stabile hohe Auslastung, Datengrenzen Leerlauf, Skalierung, Störungsbehandlung
Aggregations-Gateway Umgerechneter Tokenverbrauch Prepaid-Guthaben, Wechselkurs, Servicegebühr Yuan-Abrechnung, einheitliche Multi-Modell-Verwaltung Guthabenverwaltung, Anbieterabhängigkeit

Entscheidend ist nicht der hohe oder niedrige Preis, sondern die unterschiedliche Abrechnungseinheit. Token-Rechnungen folgen der Nutzung, GPU-Stunden verrinnen mit der Zeit, reservierter Durchsatz wird auch bei Nichtnutzung berechnet. Ein Vergleich von Stückpreisen über verschiedene Einheiten ist meist unzuverlässig.

3. Abrechnung nach Tokens: nicht der Stückpreis, sondern die Verbrauchsstruktur

Eine Token-Rechnung besteht aus Eingabe und Ausgabe. System-Prompt, Verlauf, Tool-Definitionen und abgerufene Dokumente zählen zur Eingabe; die generierte Ausgabe zur Ausgabe. Der Ausgabepreis liegt meist über dem Eingabepreis; lange Antworten, lange Gedankengänge und hohe max_tokens treiben die Kosten.

Der Kontext wird am häufigsten unterschätzt. Mehrstufige Dialoge senden den vollständigen Verlauf in jeder Runde erneut, die Eingabe-Tokens summieren sich; ein ganzes Dokument im Kontext kann pro Anfrage Zehntausende Tokens verbrauchen. Caching mindert die Kosten wiederholter Präfixe, setzt aber stabile Präfixe und eine beobachtbare Trefferquote voraus; „Cache an“ heißt nicht automatisch „günstiger“.

Auch Retries gehören ins Budget. Nach 429, Timeout oder 5xx kann eine erneut gesendete Anfrage Kosten erzeugen, wenn der Upstream sie bereits verarbeitet hat; „Fehler sind kostenlos“ darf nicht als Standardregel gelten. Bei Agenten kommen Schleifen hinzu: Eine Aufgabe kann Dutzende Modellaufrufe auslösen, die Rechnung summiert sich pro Anfrage.

Batch eignet sich für Offline-Aufgaben; der Preis liegt meist unter Online-Aufrufen, die Latenz wird aber in Stunden gemessen. Streaming verbessert die Erfahrung, ändert die Tokenmenge nicht. Für das Budget Anfragen zuerst in online, offline und cachefähig einteilen und getrennt schätzen.

4. Cloud und spezialisierte Plattformen: der Unterschied liegt im Vertrag

Eine Cloud-Rechnung enthält nicht nur Tokenkosten, sondern möglicherweise reservierten Durchsatz, Verbrauchsverpflichtungen, Support-Tarife, regionenübergreifendes Netz und Log-Speicher. Reservierter Durchsatz passt zu stabiler Last: Die Kapazität ist gebunden, wird aber auch bei Leerlauf berechnet; bei stark schwankendem Traffic ist nutzungsbasierte Abrechnung flexibler.

Spezialisierte Inferenzplattformen rechnen direkter, aber ein gleichnamiges Modell ist nicht zwingend dasselbe Produkt. Quantisierungsgenauigkeit, Kontextfenster, Parallelitätsgrenze, Version und dedizierte Instanzen beeinflussen Preis und Ergebnis. Vor Vertragsabschluss mindestens vier Punkte klären: Modellversion, Kontextgrenze, Limitregeln sowie Störungs- und Rückerstattungsklauseln.

Beim Preisvergleich mit eigenen Anfragen einen kleinen Test fahren und Latenz, Fehlerrate, Ausgabequalität und tatsächliche Abbuchung erfassen; nur die Zahlen auf der Preisseite zu lesen, lässt Warteschlange und Retry-Kosten außer Acht.

5. Selbsthosting: GPU-Auslastung statt Token-Stückpreis

Beim Selbsthosting zählt nicht der Token-Stückpreis, sondern wie viele gültige Tokens eine Maschine pro Stunde produziert:

Gesamtkosten pro Stunde = Stundenpreis pro Karte × Kartenzahl + Speicher/Netz + anteiliger Betriebsaufwand
Tatsaechlich verarbeitete Tokens pro Stunde = Spitzendurchsatz × durchschnittliche Auslastung
Kosten pro Million Tokens = Gesamtkosten pro Stunde ÷ tatsaechlich verarbeitete Tokens pro Stunde × 1.000.000

Die Auslastung ist entscheidend. Dieselbe GPU kann bei 20 und bei 80 Prozent Auslastung einen um den Faktor vier unterschiedlichen Token-Preis erzeugen. Bei geringem Volumen oder starken Spitzen stehen GPUs viel leer; gehostete APIs sind dann oft günstiger. Bei stabiler hoher Parallelität und ausreichend Batch-Aufgaben hat Selbsthosting Vorteile.

Der Betrieb muss mitgerechnet werden: Modellupdates, Quantisierungsoptimierung, Monitoring, Failover, Sicherheitspatches und Bereitschaft. Modelle in der Größe von Llama 4 Scout lassen sich mit INT4 auf einer Karte betreiben, Maverick benötigt meist mehrere Karten, abhängig von Quantisierung, Kontextlänge und Inferenzframework. Lizenzseitig erlaubt die Llama Community License üblicherweise kommerzielle Nutzung, enthält aber eine Acceptable-Use-Policy, Schwellen für monatlich aktive Nutzer und Namensnennungspflichten; vor dem Einsatz das Original lesen.

6. Sechs Schritte zu einem belastbaren Budget

  1. Logs der letzten vier Wochen exportieren: Anfragen, Eingabe-/Ausgabe-Tokens, P95-Kontext, Retry-Rate, Spitzenparallelität.
  2. Drei Kandidatenwege wählen und Monatskosten in niedriger, mittlerer und hoher Variante berechnen, nicht nur einen Punkt.
  3. Eine Sensitivitätsanalyse für Cache-Trefferquote, Batch-Anteil und Retry-Rate durchführen und den größten Hebel finden.
  4. Selbsthosting bei 30, 60 und 85 Prozent Auslastung rechnen und Personal, Backup und Skalierung einbeziehen.
  5. Einen Weg zwei Wochen im Pilotbetrieb testen und echte Rechnung, Latenz, Fehlerrate und Qualität erfassen, bevor skaliert wird.
  6. Quartalsweise Modelllebenszyklus, Preise und Vertrag prüfen, um nicht an abgeschaltete Modelle gebunden zu sein.

7. Reihenfolge der Kostenkontrolle

Zuerst unnötigen Verbrauch beseitigen, dann über Stückpreise sprechen: System-Prompt und Verlauf kürzen, lange Dokumente zuerst zusammenfassen oder per Retrieval eingrenzen, max_tokens begrenzen, strukturierte Ausgaben für weniger Rückfragen nutzen, bei 429 und Timeouts exponentielles Backoff setzen, Keys nach Projekt trennen und Budgetwarnungen einrichten.

Zweitens Modelle nach Aufgabe staffeln. Klassifikation, Extraktion und Umschreiben mit kleineren oder schnelleren Modellen, komplexes Reasoning mit größeren; nicht die gesamte Website auf der teuersten Stufe betreiben. Erst drittens kommen Caching, Batch und Vertragsverhandlung. Eine umgekehrte Reihenfolge verhandelt meist Rabatte auf unnötige Anfragen.

Wer mehrere Modelle parallel nutzt, kann mit einem Aggregations-Gateway Guthaben und Verbrauchsansicht vereinheitlichen und den Abgleich vereinfachen. Sie können zunächst das ZSQH AI Gateway registrieren, mit einem kleinen Betrag eine Anfrage testen und dann Keys nach Projekt trennen. Konkrete Preise stehen in den Modellpreisen; sie ändern sich mit den Upstreams.

8. Häufig gestellte Fragen

Lassen sich Llama-Aufrufe noch direkt bei Meta bezahlen?

Die öffentliche Vorschau der Meta-Llama-API wurde am 6. Juli 2026 eingestellt; die alte Schnittstelle bietet keine Inferenz mehr. Die Gewichte bleiben herunterladbar, Aufrufe laufen über Drittanbieter, Cloud, Selbsthosting oder Gateways.

Warum unterscheiden sich die Preise für dasselbe Llama-Modell stark?

Möglich sind unterschiedliche Versionen, Quantisierungsgenauigkeit, Kontextfenster, Limitstrategien oder der Unterschied zwischen dedizierten Instanzen und gemeinsamer Inferenz. Vergleichen Sie mit derselben Version, Kontextlänge und Parallelität.

Ist Selbsthosting immer günstiger als Token-Abrechnung?

Nicht unbedingt. Nur eine stabile hohe Auslastung verteilt GPU- und Personalkosten; bei geringem oder stark schwankendem Volumen treiben leerstehende GPUs den effektiven Preis nach oben.

Verdoppelt sich die Rechnung bei doppeltem Kontext?

Nicht zwingend. Die Eingabe-Tokens wachsen näherungsweise linear mit dem Kontext, Latenz und Limitrisiko steigen ebenfalls; das Ausmaß hängt von Ausgabeanteil, Cache und Retries ab.

Werden fehlgeschlagene Retries doppelt berechnet?

Das hängt davon ab, ob der Upstream die Anfrage bereits verarbeitet hat. Retries nach Limits, Timeouts und 5xx können Kosten erzeugen; Backoff, Idempotenz und eine Obergrenze für Retries setzen und per Request-ID abgleichen.

Nächster Schritt

Der Llama-Preis hängt vom Zugangsweg und der Verbrauchsstruktur ab. Zuerst mit eigenen Logs Eingabe, Ausgabe, Kontext und Retries klären, dann Rechnungen von Hosting, Cloud, Selbsthosting und Gateway vergleichen. Wer einheitliches Guthaben, Yuan-Abrechnung und Multi-Modell-Verwaltung braucht, kann mit der Registrierung beginnen; Preise und Abrechnungsregeln stehen in den Modellpreisen.

Weiterführende Beiträge: