„Llama API Key“ ist ein häufig gesuchter Begriff, gehört aber nicht zu einem einheitlichen Produkt. Am 6. Juli 2026 hat Meta die öffentliche Vorschau der Llama API eingestellt; wer Llama weiter nutzen will, geht heute meist über Cloud-Anbieter, Inferenzplattformen, eigene Deployments oder OpenAI-kompatible Gateways. Jeder Weg liefert andere Zugangsdaten: mal ein Bearer-Token, mal temporäre Signaturdaten eines Cloud-Kontos, mal gar keinen Key.

Dieser Beitrag erklärt pro Weg, woher der Key kommt, wie Rechte begrenzt werden, wohin Umgebungsvariablen gehören, wie man 401 eingrenzt und wie nach einem Leak rotiert wird. Modelle und Abrechnung richten sich nach den Modellpreisen auf dieser Website.

Hinweis: Meta und Llama sind Marken von Meta Platforms, Inc.; weitere Plattform- und Modellnamen sind Marken der jeweiligen Inhaber. Dieser Beitrag dient der technischen Erläuterung und begründet keine Zugehörigkeits-, Vertretungs- oder Fürsprachebeziehung zu Meta oder den genannten Plattformen.

1. Zuerst unterscheiden: vier Arten von „Llama API Key“

Weg Form der Zugangsdaten Wo erstellen Geeignet für
Cloud-Hosting IAM-Rolle, temporäre Daten oder Ressourcen-Key AWS IAM, Microsoft Foundry, Google Cloud Console Bestehender Cloud-Vertrag, Audit und regionale Compliance
Inferenzplattform Bearer-API-Key Konsole von Groq, OpenRouter und anderen Schneller Zugang, kein GPU-Betrieb
Eigene Inferenz Eigene Authentifizierung oder intern ohne vLLM, Ollama, llama.cpp Strenge Datengrenzen, vorhandene GPU
Kompatibles Gateway Gateway-API-Key Gateway-Konsole Einheitlicher Multi-Modell-Einstieg, Yuan-Abrechnung

Derselbe Begriff bezeichnet auf verschiedenen Plattformen nicht dasselbe. IAM-Daten eines Cloud-Anbieters lassen sich nicht in api_key des OpenAI SDK einsetzen; der Key einer Inferenzplattform ruft meist keine Modelle eines anderen Anbieters auf. Zuerst den Typ der Zugangsdaten klären, dann über die „Beschaffung“ sprechen.

2. Der offizielle Weg: Der Meta-Llama-API-Key ist Geschichte

Meta hat 2025 eine öffentliche Llama-API-Vorschau mit gehostetem Zugang unter api.llama.com und OpenAI-kompatiblem Pfad eingeführt. Diese Vorschau wurde am 6. Juli 2026 eingestellt; alte Anfragen erhalten einen Hinweis auf das Dienstende oder eine Weiterleitung, alte Keys funktionieren meist nicht mehr. Bei Anleitungen, die „im Meta-Konto einen Llama-API-Key erstellen“ empfehlen, zuerst das Veröffentlichungsdatum prüfen.

Zwei Dinge sind zu trennen: Modellgewichte und gehostete API. Die offenen Llama-Gewichte werden weiterhin unter der Llama Community License angeboten und sind über die Modellseite von Meta und Hugging Face erhältlich; eingestellt wurde die First-Party-Hosting-Schicht von Meta. Die aktuell beworbene Meta Model API bietet Modelle der Muse-Reihe, nicht Llama; beides nicht vermischen.

Daher hat „offizieller Key“ heute nur zwei Bedeutungen: Entweder Sie laden die Gewichte über offizielle Kanäle herunter und betreiben sie selbst, mit eigener Authentifizierung; oder Sie rufen über Cloud-Anbieter oder Hoster auf. Jede Drittseite, die einen „offiziellen Meta-Llama-API-Key“ verspricht, ist zuerst zu prüfen.

3. Cloud-Anbieter: IAM-Daten statt einfügbarem Key

AWS Bedrock. Zuerst in der Konsole Zugriff auf das Modell beantragen, dann dem Aufrufer minimale Rechte wie bedrock:InvokeModel und bedrock:InvokeModelWithResponseStream geben. Aufrufe nutzen SigV4-Signaturen, meist über SDK oder temporäre Daten; ein langfristiger Key gehört nicht in den Code. Bei Llama 4 Scout unterstützt Bedrock derzeit nur Invoke oder Converse, keinen Chat-Completions-Einstieg; Modell-IDs haben die Form meta.llama4-scout-17b-instruct-v1:0, regionenübergreifende Inferenz benötigt ein Präfix wie us., und Verfügbarkeit sowie Lebenszyklus unterscheiden sich je Region.

Microsoft Foundry (früher Azure AI Foundry). Nach dem Deployment eines Llama-Modells im Modellkatalog den Ressourcen-Endpunkt mit Key oder Entra-ID verwenden. Der Key ist an die Ressource gebunden; bei Abo- oder Regionswechsel erneut prüfen.

Google Cloud Vertex AI. Aufruf über Servicekonto oder Standardanmeldedaten der Anwendung, dem Konto die passenden Vertex-AI-Rollen geben und Projekt, Region und Modellversion prüfen. Lebenszyklus beachten: Google hat angekündigt, dass llama-3.3-70b-instruct-maas am 21. Oktober 2026 außer Betrieb geht; wer es noch nutzt, muss migrieren oder selbst deployen.

Gemeinsam ist den Cloud-Wegen die feine Rechtevergabe und vollständige Prüfkette, aber langsame Freischaltung und viele Rechnungspositionen. Keys nicht an Personen verteilen, sondern an Workload-Identitäten binden und Quellnetz sowie Regionen begrenzen.

4. Inferenzplattformen und kompatible Gateways: der häufigste Bearer-Key

Inferenzplattformen wie Groq, OpenRouter und Fireworks sowie inländische OpenAI-kompatible Gateways bieten meist eine Konsole, in der auf der Seite API Keys ein Bearer-Token erstellt wird. Der Ablauf ist ähnlich:

  1. Konto registrieren und je nach Plattform E-Mail, Telefon oder Unternehmensverifizierung abschließen.
  2. Zur Seite API Keys gehen, einen Key anlegen und Name mit Projekt, Umgebung und Nutzer versehen, etwa prod-rag-cn.
  3. Minimale Rechte wählen: nur Inferenz, keine Abrechnung, Mitglieder- oder Key-Verwaltung.
  4. Budget, Rate oder Monatsgrenze setzen, damit ein einzelner Key nicht das Konto ausschöpft.
  5. Den Key sofort in einen Passwortmanager oder Key-Management-Dienst kopieren; die meisten Plattformen zeigen ihn nur einmal.
  6. Mit einer minimalen Anfrage Key, Base URL und Modellname prüfen, dann in die produktive Konfiguration übernehmen.

Der Unterschied bei Gateways: Ein Key kann mehrere Upstream-Modelle abdecken. Beim ZSQH AI Gateway lautet die Base URL https://ai.zhongshangqihang.com/v1; verfügbare Modelle richten sich nach der Konsole und den Modellpreisen. Der Vorteil sind einheitliche Rechnung und Logs, der Preis eine zusätzliche Weiterleitung; bei der Auswahl Datenpfad, Störungsbehandlung und Abrechnungsregeln prüfen.

5. Rechte: ein Key muss nicht alles können

Behandeln Sie den Key wie eine Identität, nicht wie ein Passwort. Produktion, Test und private Experimente erhalten eigene Keys; keine langfristigen Keys in Frontend, Mobile oder öffentlichen Repositories; für direkte Browser-Aufrufe kurzfristige Tokens oder ein Backend-Proxy verwenden. Wo IP-Whitelist, Quell-Domain, Modellbereich oder Budgetgrenze möglich sind, diese Begrenzungen setzen.

Ein verbreitetes Anti-Muster im Team ist „ein Key für alle“. Bei Problemen lässt sich nicht zuordnen, wer aufgerufen hat, und nach einem Leak nicht nur eine Person sperren. Keys nach Projekt trennen, mit Nutzungs-Tags und Alarmen ergänzen; das senkt den Analyseaufwand deutlich.

6. Umgebungsvariablen und Code: Keys gehören nicht in Git

# .env nur lokal oder im Key-Management-Dienst, nicht in Git einchecken
export LLAMA_API_KEY="IHR_KEY"
export LLAMA_BASE_URL="https://api.groq.com/openai/v1"
export LLAMA_MODEL="llama-3.3-70b-versatile"

SDKs für Python, Node und andere lesen ohne explizite Angabe häufig OPENAI_API_KEY. Wer im selben Prozess weitere Anbieter aufruft, sollte api_key explizit übergeben, damit kein Key von Plattform A an Plattform B geht. In Containern und systemd-Diensten prüfen, ob die Variable tatsächlich injiziert wird und nicht nur in der aktuellen Shell gilt.

401 in dieser Reihenfolge prüfen:

  • Lautet der Header Authorization: Bearer <key> mit genau einem Leerzeichen nach Bearer?
  • Stammt der Key von der Plattform, zu der die Base URL gehört? Plattformübergreifend sind Keys nicht austauschbar.
  • Wurde der Key gesperrt, ist er abgelaufen oder nie aktiviert worden?
  • Enthält die Umgebungsvariable Anführungszeichen, Zeilenumbrüche oder beim Kopieren eingefügte Leerzeichen?
  • Liest der Dienst noch alte Variablen? Wurde nach der Änderung neu gestartet?
  • 401 bedeutet fehlgeschlagene Identität, 403 meist gültige Identität ohne ausreichende Rechte; nicht vermischen.

7. Rotation und Sperrung: den Ausstieg vorher planen

  1. In der Plattform einen neuen Key mit Datum im Namen anlegen, etwa prod-2026-10.
  2. Zuerst in einem Testdienst oder einer grauen Instanz ersetzen und 401, 403 sowie Latenz beobachten.
  3. Prüfen, dass keine Authentifizierungsfehler im Log stehen, dann schrittweise weitere Umgebungen ersetzen.
  4. Alten und neuen Key eine Zeit lang überlappen lassen, aber nicht länger als einen Release-Zyklus.
  5. Den alten Key nach Bestätigung, dass keine Aufrufe mehr erfolgen, sperren und die letzte Nutzung auf Auffälligkeiten prüfen.
  6. Das Key-Register aktualisieren: Erstellungszeit, Verantwortlicher, Zweck, nächster Rotationstermin.

Auslöser für eine Rotation sind Personalabgänge, Keys in Logs oder Repositories, Sicherheitsvorfälle beim Anbieter und feste Zyklen. Bei Verdacht auf einen Leak zuerst sperren, dann untersuchen, nicht zuerst den Code ändern; parallel Rechnung und Aufruflogs auf ungewöhnliche Modelle oder Regionen prüfen.

Häufig gestellte Fragen

Lässt sich noch ein offizieller Meta-Llama-API-Key beantragen?

Nein. Die öffentliche Vorschau der Meta-Llama-API wurde am 6. Juli 2026 eingestellt; der alte Einstieg bietet keine Inferenz mehr. Llama-Gewichte bleiben herunterladbar, gehostete Aufrufe laufen über Cloud, Inferenzplattformen oder kompatible Gateways.

Warum gibt es bei Cloud-Anbietern keinen direkt einfügbaren API-Key?

Cloud-Anbieter authentifizieren meist über IAM-Rollen, Servicekonten oder temporäre Daten; Rechte und Audit hängen am Cloud-Konto. Das ist feiner als ein langfristiges Bearer-Token, erfordert aber Rechte- und Signaturkonfiguration; der api_key-Parameter des OpenAI SDK lässt sich nicht direkt übernehmen.

Kann ein Key alle Llama-Modelle aufrufen?

Das hängt von der Plattform ab. Inferenzplattformen und Gateways erlauben mit einem Key meist mehrere freigeschaltete Modelle; Cloud-Anbieter begrenzen über IAM-Rechte, Modellanträge und Regionen. Maßgeblich ist die aktuelle Liste in der Konsole.

Was passiert, wenn der Key im Frontend oder in einer App liegt?

Er gilt als öffentlich. Wer den Traffic abfängt, kann ihn auslesen und Ihr Kontingent verbrauchen. Browser und Mobile sollten das eigene Backend aufrufen; das Backend hält den Key und übernimmt Authentifizierung, Limits und Logging.

Was bei 401 und 403 zuerst prüfen?

Bei 401 zuerst Key, Header-Format und Übereinstimmung mit der Base URL; bei 403, ob Key oder Rolle Rechte für Modell, Projekt oder Region haben. Erst danach die Statusseite des Gateways oder Cloud-Anbieters prüfen.

Nächster Schritt

Zuerst den Zugangsweg festlegen, dann einen dedizierten Key anlegen: Cloud über IAM, Inferenzplattformen und Gateways über Bearer-Token, Selbsthosting mit eigener Authentifizierung. Wer einheitliche Keys, Logs und einen Multi-Modell-Einstieg braucht, kann mit der Registrierung beim ZSQH AI Gateway beginnen; verfügbare Modelle und Abrechnung richten sich nach den Modellpreisen.

Weiterführende Beiträge: