Llama API in China: Cloud, Gateway oder Selbstbetrieb (2026)

Wer 2026 über „Llama API in China“ spricht, muss zuerst eine Frage klären: Ist die Meta-eigene Hosting-Schnittstelle gemeint oder „eine API, die Llama-Modelle aufruft“? Erstere ist abgeschaltet, für letztere gibt es weiterhin mehrere Wege. Das beeinflusst Beschaffung, Migration und Compliance unmittelbar.

Dieser Artikel vergleicht Netzwerk, Zahlung und Rechnung, Compliance, Hardware und Failover und liefert eine Prüfliste vor dem Produktivstart.

Hinweis: Meta, Llama und Llama 4 sind Marken von Meta Platforms, Inc.; AWS, Azure, Google Cloud, Oracle und weitere Namen sind Marken ihrer jeweiligen Inhaber. Dieser Artikel dient der technischen Erörterung, begründet keine Zugehörigkeit oder Zusammenarbeit mit diesen Unternehmen und stellt keine Rechtsberatung dar. Modelle, Regionen und Preise richten sich nach den offiziellen Dokumentationen der Plattformen und unserer Preisseite; Preise können sich ändern.

1. Zuerst klären: Was ist 2026 die „Llama API“?

Meta führte 2025 eine öffentliche Vorschau der Llama API ein, die selbst gehostete Schnittstellen zu Llama-Modellen anbot. Diese Vorschau wurde am 6. Juli 2026 eingestellt; Anfragen an die alte Adresse erhalten einen Hinweis auf die Abschaltung. Wichtig: Abgeschaltet wurde die First-Party-Hosting-Schnittstelle von Meta, nicht das Modell selbst.

Die Llama-Gewichte sind weiterhin über die Meta-Llama-Downloadseite und Hugging Face unter der Llama-Community-Lizenz verfügbar; Cloud-Plattformen wie AWS, Azure und Google Cloud sowie mehrere Inferenzanbieter bieten Llama-Modelle weiterhin an. Meta betreibt inzwischen eine Model API für die Muse-Spark-Reihe, die nicht zur selben Produktlinie wie Llama gehört; bei der Beschaffung sollten die Namen nicht vermischt werden.

Wenn chinesische Teams heute „Llama API anbinden“ sagen, wählen sie meist eine von drei Rollen: Cloud-Hosting, Inferenzanbieter bzw. inländisches Gateway oder Selbstbetrieb. Diese Wege folgen nun im Einzelnen.

2. Weg eins: Hosting bei einem Cloud-Anbieter

Die gängigen Optionen sind AWS Bedrock, Azure AI Foundry, Google Cloud Vertex AI Model Garden; einige Teams prüfen auch Oracle OCI Generative AI. Gemeinsam ist ihnen, dass Konten, Rechte, Audits und Abrechnung am Cloud-Konto hängen; geeignet für Teams mit bestehendem Cloud-Vertrag und Nutzungsverpflichtung.

Drei Punkte sind wichtig. Erstens sind Regionen und Modellvarianten nicht überall gleichzeitig verfügbar; wo Llama 4 Scout, Maverick und andere Modelle angeboten werden, steht in der Regionsliste des jeweiligen Cloud-Anbieters. Zweitens sind die Schnittstellen nicht einheitlich: Bedrock nutzt häufig Converse oder InvokeModel, Azure und Vertex haben eigene SDKs; eine OpenAI-kompatible Ebene muss selbst ergänzt oder über ein Gateway bereitgestellt werden. Drittens erfolgt die Zahlung oft in Fremdwährung; Rechnungssteller, Währung und Zahlungsziel hängen von der Vertragsform ab.

Cloud-Anbieter bieten vergleichsweise vollständige Compliance-Unterlagen, Private-Network-Zugang und Enterprise-Support; dafür sind Freischaltung und regionale Datenplanung aufwendiger und müssen früh geklärt werden.

3. Weg zwei: Inferenzanbieter und inländische AI-Gateways

Zu den Inferenzanbietern gehören Groq, Together AI, Fireworks, DeepInfra und OpenRouter. Groq ist für niedrige Latenz bekannt; Together AI, Fireworks und DeepInfra bieten nutzungsbasierte oder dedizierte Deployments; OpenRouter bündelt mehrere Upstreams. Viele Anbieter stellen OpenAI-kompatible Schnittstellen bereit, sodass bei der Migration meist nur Base URL, Key und Modell-ID geändert werden.

Inländische AI-Gateways bündeln diese Upstreams hinter einem Einstiegspunkt und bieten Aufladung in RMB sowie Key-Verwaltung im eigenen Konto. Das ZSQH AI Gateway gehört zu dieser Kategorie; die Registrierung erfolgt über die Registrierungsseite. Verfügbare Modelle, Kontextlängen und Abrechnung entnehmen Sie der Modellliste und der Preisseite. Bei der Gateway-Auswahl sollten Sie fragen: Wer ist der Upstream, wird quantisiert, wie werden fehlgeschlagene Anfragen abgerechnet und wie lange werden Daten aufbewahrt?

4. Weg drei: Selbstbetrieb

Beim Selbstbetrieb ist der Upstream das Modellgewicht, nicht eine bestimmte API. Die Gewichte stammen von der Meta-Llama-Downloadseite oder von Hugging Face; gängige Inferenz-Frameworks sind vLLM, SGLang, TGI, llama.cpp und Ollama. Nach der Veröffentlichung neuer Modelle benötigen die Frameworks meist ein bis zwei Versionen, bis sie unterstützt werden; prüfen Sie vor dem Deployment die Versionshinweise.

Für die Hardware-Schätzung gelten zwei grobe Faustregeln: BF16-Gewichte benötigen etwa 2 GB pro Milliarde Parameter, INT4-Quantisierung etwa 0,5 bis 0,6 GB pro Milliarde Parameter; hinzu kommen KV-Cache, Framework- und Parallelitätsreserve. Meta nennt für Llama 4 Scout eine einzelne H100 im INT4-Betrieb als Referenz, für Maverick einen Multi-H100-Knoten; Llama 3.3 70B benötigt auch in BF16 mehrere Karten. Maßgeblich sind Modellkarte und Dokumentation des Inferenz-Frameworks.

Selbstbetrieb löst die Fragen Datenschutz im eigenen Rechenzentrum, kontrollierbare Versionen und gleichmäßige Last; dafür müssen GPU, Treiber- und Framework-Wartung, Monitoring, Skalierung und Sicherheit selbst getragen werden.

5. Die drei Wege in einer Tabelle

Dimension	Cloud-Hosting	Inferenzanbieter/inländisches Gateway	Selbstbetrieb
Netzwerkzugang	Cloud-Regionsendpunkt, Private Network möglich	Anbietereinstieg; inländische Gateways sind meist aus China erreichbar	Eigenes Rechenzentrum oder Cloud-Host
Freischaltung und Zahlung	Cloud-Konto, Fremdwährung oder Unternehmensvertrag	Registrierung und Aufladung, häufig RMB	GPU-Kauf oder -Miete plus Strom und Betrieb
Rechnung	Nach Cloud-Vertragspartner	Nach Anbieterregeln	Selbst zu organisieren
Daten und Compliance	Regionen, Audits und Vertragsunterlagen vergleichsweise vollständig	Anbieterabhängig, Punkt für Punkt prüfen	Datengrenze am klarsten
Versionskontrolle	Plattform entscheidet über Angebot und Abschaltung	Upstream entscheidet; Mapping prüfen	Eigene feste Gewichtsversion
Betriebsaufwand	Niedrig	Niedrig bis mittel	Hoch
Elastizität	Gut, aber kontingentbegrenzt	Gut, aber durch Upstream-Ratenlimits begrenzt	Abhängig von eigenen GPUs
Geeignete Teams	Bestehender Cloud-Vertrag, hohe Compliance-Anforderungen	Inländische kleine und mittlere Teams, mehrere Modelle	Sensible Daten, stabile Last, GPU-Kompetenz

6. Netzwerk, Zahlung und Rechnung prüfen

„Erreichbar“ bedeutet nicht „stabil aufrufbar“. Grenzüberschreitende Verbindungen zeigen in Stoßzeiten häufig höhere Latenz, gelegentliche Timeouts und Streaming-Abbrüche. Prüfen Sie Time to First Byte, P95-Gesamtdauer, Timeout-Quote und Abbruchquote im Streaming, nicht nur einen einzelnen Ping.

export LLAMA_BASE_URL="https://your-gateway.example.com/v1"
export LLAMA_API_KEY="sk-..."

curl -o /dev/null -sS \
  -w "dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s code=%{http_code}\n" \
  "$LLAMA_BASE_URL/models" \
  -H "Authorization: Bearer $LLAMA_API_KEY"

Führen Sie morgens, mittags und abends je eine Messreihe über mehrere Tage aus. Langsames DNS deutet auf die Auflösung, langsames TCP auf die Leitung, langsames TLS auf den Handshake und ein langsamer erster Byte meist auf eine Warteschlange beim Upstream.

Zahlung und Rechnung sollten vorab geklärt werden: Währung, Kartenart, Rückerstattung von Guthaben, Rechnungsempfänger, Zahlungsziel und Mindestumsatz. Halten Sie dies im Beschaffungsprotokoll fest, damit Finanzprozesse nicht erst nach dem Produktivstart auffallen.

7. Compliance und Lizenz: drei Dinge getrennt betrachten

Erstens die Dienst-Compliance. Für generative KI-Dienste, die der Öffentlichkeit in China angeboten werden, können Registrierungs- oder Sicherheitsbewertungspflichten nach den geltenden vorläufigen Maßnahmen für generative KI-Dienste gelten; interne Entwicklung und externer Betrieb unterliegen unterschiedlichen Anforderungen. Maßgeblich sind die regulatorischen Vorgaben und die rechtliche Bewertung.

Zweitens die Daten-Compliance. Grenzüberschreitende Aufrufe übertragen Prompts und Ausgaben ins Ausland; ob personenbezogene Daten oder wichtige Daten betroffen sind, ob Vertragsklauseln oder eine Ausfuhrbewertung nötig sind, richtet sich nach den einschlägigen Datenschutzregeln. Selbstbetrieb hält Daten im eigenen Rechenzentrum, ist aber nicht automatisch konform.

Drittens die Modelllizenz. Die Llama-Community-Lizenz erlaubt kommerzielle Nutzung, verlangt aber die Einhaltung der Acceptable Use Policy sowie Namens- und Kennzeichnungsvorgaben; bei einer bestimmten Größe monatlich aktiver Nutzer (die Llama-4-Lizenz nennt 700 Millionen) ist eine gesonderte Lizenz erforderlich. Die Bedingungen unterscheiden sich je Version; lassen Sie vor kommerzieller Nutzung den Originaltext rechtlich prüfen.

8. Failover: nicht auf einen einzigen Kanal setzen

Ein einzelner Upstream hat zwangsläufig Wartung, Ratenlimits und Regionsstörungen. Bewährt sind: pro Aufgabentyp ein Haupt- und ein Ersatz-Upstream mit einheitlicher Modell-Mapping-Tabelle; Umschalten bei fehlgeschlagenem Health Check; angemessene Timeouts, exponentielles Backoff mit Jitter; Circuit Breaker gegen Retry-Stürme; bei Bedarf Downgrade auf ein kleineres Modell; pro Anfrage Upstream-Name und Request-ID protokollieren, um Abrechnung und Fehlersuche zu erleichtern.

Beachten Sie, dass Wiederholungen doppelt abgerechnet werden können, Schreibvorgänge idempotent sein müssen und Streaming-Anfragen den bereits ausgegebenen Teil erfassen sollten. Der Umschaltprozess sollte vor einem Störfall geübt werden.

9. Prüfliste vor dem Produktivstart

1. Benötigte Llama-Varianten, Kontextlängen, Tool-Aufrufe und Streaming-Anforderungen auflisten.
2. Bestätigen, dass der Ziel-Upstream in der benötigten Region verfügbar ist, und Modell-ID sowie Version dokumentieren.
3. Schnittstellenprotokoll prüfen: OpenAI-kompatibel, eigenes SDK oder proprietäres Cloud-Protokoll.
4. Mit echten Geschäftssamples eine Testrunde fahren und Genauigkeit, P95-Latenz und Fehlerquote erfassen.
5. Quantisierungsstufe, maximale Ausgabe, System-Prompts und Unterschiede bei Inhaltsfiltern prüfen.
6. Zahlung, Rechnung, Rückerstattung, Ratenlimits und Abrechnung fehlgeschlagener Anfragen bestätigen.
7. Datenaufbewahrung, Logs, grenzüberschreitende Übermittlung und Vertragsbedingungen klären.
8. Haupt-/Ersatzumschaltung, Timeout-Retries, Budgetalarme und Request-Logs konfigurieren.
9. Ein bis zwei Wochen mit kleinem Traffic grau testen, dann schrittweise ausweiten.

10. Häufige Fragen

Kann die Llama API von Meta noch direkt aufgerufen werden?

Nein. Die öffentliche Vorschau der First-Party-Llama-API von Meta wurde am 6. Juli 2026 eingestellt. Die Llama-Gewichte sind weiterhin herunterladbar und können über Drittplattformen, Inferenzanbieter oder Selbstbetrieb genutzt werden.

Müssen chinesische Teams für Llama-Aufrufe eine Registrierung vornehmen?

Das hängt vom Zweck ab. Interne Forschung und interne Tools sowie öffentlich angebotene Dienste unterliegen unterschiedlichen Anforderungen; bei Letzteren können Registrierung oder Sicherheitsbewertung relevant sein. Klären Sie dies bereits in der Auswahlphase mit der Rechtsabteilung.

Wie viele GPUs braucht Selbstbetrieb von Llama mindestens?

Eine pauschale Antwort gibt es nicht; entscheidend sind Modellgröße, Quantisierung, Kontextlänge und Parallelität. Für eine erste Schätzung gelten etwa 2 GB pro Milliarde Parameter in BF16 und 0,5 bis 0,6 GB in INT4, zuzüglich KV-Cache und Framework-Overhead; maßgeblich sind Modellkarte und VRAM-Angaben des Inferenz-Frameworks.

Wie wählt man zwischen Cloud, Gateway und Selbstbetrieb?

Mit bestehendem Cloud-Vertrag und hohen Compliance-Anforderungen bietet sich Cloud an; für RMB-Rechnungen und schnellen Zugang zu mehreren Modellen kommt ein inländisches Gateway infrage; bei sensiblen Daten, stabiler Last und GPU-Betriebskompetenz lohnt Selbstbetrieb. Kombinationen sind möglich.

Unterscheidet sich Llama hinter einem Gateway vom Original?

Möglicherweise. Gleichnamige Modelle können bei verschiedenen Upstreams unterschiedlich quantisiert sein, andere Kontextlängen haben oder zusätzlich feinabgestimmt bzw. inhaltsgefiltert sein. Prüfen Sie vor der Anbindung mit einem Evaluationsset und den Schnittstellen-Metadaten, nicht nur anhand des Modellnamens.

Fazit

Bei der Llama-Anbindung 2026 geht es im Kern darum, Cloud, Gateway und Selbstbetrieb als drei Lieferketten zu verwalten: Netzwerk real messen, Zahlung und Rechnung vorab klären, Compliance und Lizenz getrennt beurteilen und Failover üben. Validieren Sie zuerst mit wenig Traffic und legen Sie dann die langfristige Lösung fest.

Weiterlesen: OpenAI API in China, DeepSeek API in China, Modellpreise. Für einen einheitlichen Einstieg beginnen Sie auf der Registrierungsseite.