Kostenlose LLM-APIs: der echte Vergleich (und die Option locale)

#Warum dieser Vergleich

Bei der Entwicklung eines Prototyps sucht man oft zuerst nach einer kostenlosen LLM-API: Man möchte eine Idee ausprobieren, ohne die Kreditkarte zücken zu müssen, ein Modell in ein Skript einbinden und sehen, ob das Konzept funktioniert. Die gute Nachricht: Kostenlose Angebote gibt es tatsächlich, und manche sind großzügig bemessen. Die schlechte: „Kostenlos“ kann sehr Unterschiedliches bedeuten – einen dauerhaft kostenlosen Tarif, ein zeitlich befristetes Testguthaben oder einen von der Community bereitgestellten Zugang mit gedrosselter Übertragungsrate.

Dieser Leitfaden soll Ihnen nicht sagen: „Lokal ist besser.“ Er soll Ihnen die Zahlen liefern, damit Sie selbst entscheiden können: was jedes kostenlose Angebot tatsächlich erlaubt, was es im Gegenzug verlangt und ab welchem Nutzungsvolumen oder welchen Vertraulichkeitsanforderungen ein lokaler Endpunkt zur rationalen Wahl wird. Oft ist die beste Antwort weder das eine noch das andere, sondern beides, mit einem Routing je nach Aufgabe.

#Kostenlose LLM-APIs im Überblick

Kostenlose Angebote lassen sich in vier Kategorien einteilen. Wer versteht, zu welcher Kategorie ein Angebot gehört, vermeidet böse Überraschungen, wenn der Zähler mitten in einem Sprint auf null fällt.

Dauerhaft kostenloser Tarif

Ein kostenloser Zugang, der nicht abläuft, bei dem aber die Zahl der Anfragen pro Minute und pro Tag begrenzt ist. Das gilt etwa für Google AI Studio (Gemini-API) oder Groq, die offene Modelle (Llama, Qwen, gpt-oss) mit kostenlosem, aber begrenztem Durchsatz anbieten.

Aggregatoren und Modelle mit dem Suffix :free

OpenRouter bietet Dutzende Modelle an, darunter einige mit dem Suffix „:free“. Der Zugang ist tatsächlich verfügbar, doch der Durchsatz hängt von einem gemeinsam genutzten Ressourcenpool ab und kann zu Spitzenzeiten sinken.

Testguthaben

Ein kostenloses Guthaben (oft einige Dollar), das bei der Kontoerstellung gewährt wird und nach einigen Wochen verfällt. Praktisch für einen einmaligen Test, nutzlos für ein längerfristiges Projekt.

Community-Inferenz

Hugging Face Inference und ähnliche Dienste: kostenloser Zugang zu vielen Modellen, aber Kaltstarts (Cold Starts), Warteschlangen und kein garantierter Durchsatz.

#Die tatsächlichen Kontingente, ungeschönt

Das Wort „kostenlos“ verdeckt drei unterschiedliche Obergrenzen, die gemeinsam bestimmen, ob das Angebot für Ihre Nutzung ausreicht. Eine Tarifstufe kann bei einer davon großzügig sein und bei den beiden anderen stark begrenzt.

Anfragen pro Minute (RPM)

Die Anzahl der erlaubten Anfragen pro Minute. Kostenlose Tarife erlauben oft einige Dutzend RPM – mehr als genug für einen Entwickler, der Tests durchführt, aber zu wenig, um mehrere Nutzer gleichzeitig zu bedienen.

Tokens pro Tag (TPD)

Die entscheidende Obergrenze. Ein tägliches Token-Kontingent ist sehr schnell aufgebraucht, sobald man große Prompts oder RAG-Kontext sendet oder einen Datensatz in einer Schleife verarbeitet.

Durchsatz und Latenz

Bei kostenlosen Angeboten mit gemeinsam genutzten Ressourcen ist die Generierungsgeschwindigkeit nie garantiert. Außerhalb der Spitzenzeiten läuft die Generierung flüssig; bei hoher Auslastung steigt die Latenz massiv an oder Anfragen werden abgelehnt (Fehler 429).

Konkret: Für manuelles Prototyping, gelegentliche Anfragen und die kostenlosen Quoten sind sie ausreichend. Sobald Sie ein Batchverarbeitungs-Skript erstellen — beispielsweise tausende Tickets klassifizieren, eine E-Mailbox zusammenfassen, Tests auf einen Repository generieren — stoßen Sie innerhalb weniger Minuten auf die TPD-Grenze, und der begrenzte Durchsatz verwandelt einen Batch von 10 Minuten in eine Stunde mit interverzweigten 429-Fehlern.

#Was Sie tatsächlich bezahlen

Eine kostenlose API ist nicht ohne Kosten: Sie zahlen lediglich nicht mit Geld, sondern in anderen Kategorien. Drei davon fallen bei einem Entwicklungsprojekt besonders ins Gewicht.

Ihre Daten

Bei vielen kostenlosen Tarifen werden Prompts und Antworten gespeichert und können zum Trainieren oder Verbessern der Modelle verwendet werden. Was bei einem Test mit fiktiven Daten akzeptabel ist, ist bei proprietärem Code, Kundendaten oder personenbezogenen Informationen (DSGVO) nicht akzeptabel.

Die Abhängigkeit

Auf ein kostenloses Kontingent zu setzen heißt, auf einem Boden zu bauen, der nachgeben kann: geänderte Bedingungen, ein zurückgezogenes Modell, eine abgeschaffte Tarifstufe. Ihr Code, Ihre Prompts und Ihre Einstellungen sind auf einen Anbieter abgestimmt; eine Migration kostet Zeit, die Sie nicht eingeplant hatten.

Unvorhersehbarkeit

Variable Latenz, Warteschlangen, Unterbrechungen: Es ist schwierig, eine zugesagte Dienstqualität einzuhalten, wenn sich die zentrale Komponente Ihrer Kontrolle entzieht und für das kostenlose Angebot keinerlei Zusagen macht.

#Die lokale Option mit Ollama

Im Gegensatz zum kostenlosen, aber bedingten Angebot gibt es das wirklich kostenlose Angebot: Die lokale Ausführung des Modells auf Ihrer eigenen Maschine. Ollama ist das einfachste Werkzeug dazu. Es ist ein Daemon, der open-weight Modelle herunterlädt und eine lokale HTTP-API auf http://localhost:11434 bereitstellt — mit einem Endpoint, der kompatibel zu OpenAI ist, was bedeutet, dass Code für eine Cloud-API oft nur durch die Änderung der Basis-URL funktioniert.

# Installer Ollama (Linux/macOS)
curl -fsSL https://ollama.com/install.sh | sh

# Tirer et lancer un modèle 7-8B quantifié Q4_K_M
ollama pull qwen2.5:7b
ollama run qwen2.5:7b

# Le daemon écoute sur http://localhost:11434

Im Code lässt sich der OpenAI-kompatible Endpunkt mit drei Zeilen anbinden. Keine API-Schlüssel zu verwalten, keine Kontingente, keine Daten, die den Rechner verlassen.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",  # endpoint local Ollama
    api_key="ollama",  # ignoré en local, mais requis par le client
)

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=[{"role": "user", "content": "Explique la récursion en une phrase."}],
)
print(resp.choices[0].message.content)

Der Preis dafür ist die erforderliche Hardware. Ein lokales Modell benötigt VRAM (oder Unified Memory auf einem Mac mit Apple Silicon). Bei der Quantisierung Q4_K_M lassen sich die Speichergrößen leicht merken: Ein 3B-Modell passt in etwa 2 GB, ein 7B-Modell in etwa 5 GB, ein 14B-Modell in etwa 9 GB, ein 32B-Modell in etwa 19 GB, und ein 70B-Modell benötigt etwa 40 GB. Eine RTX 3060 mit 12 GB führt 7B- bis 14B-Modelle komfortabel aus; eine RTX 4090 mit 24 GB oder ein Mac M4 Pro mit 24–48 GB Unified Memory ermöglicht den Einsatz von 32B-Modellen.

Vollständige Vertraulichkeit

Kein Prompt verlässt den Rechner. Proprietärer Code, Kundendaten, personenbezogene Informationen: Alles bleibt bei Ihnen, was die Einhaltung der DSGVO grundlegend vereinfacht.

Kein Nutzungslimit

Keine RPM- oder TPD-Limits. Sie verarbeiten nachts zehntausend Dokumente in einer Schleife, ohne mitzählen zu müssen und ohne Fehler 429.

Keine Grenzkosten

Sobald die Hardware vorhanden ist, ist jede Anfrage kostenlos. Die Stromkosten einer Desktop-GPU bleiben im Vergleich zu einer nutzungsabhängigen API-Rechnung vernachlässigbar.

Stabilität

Keine sich ändernden Bedingungen, kein zurückgezogenes Modell. Die Version, die Sie heruntergeladen haben, bleibt unverändert, solange Sie sie nicht aktualisieren.

#Der Punkt, an dem sich der Wechsel zum lokalen Betrieb lohnt

Die sinnvolle Frage ist nicht „kostenlos oder lokal?“, sondern „ab wann wird der lokale Ansatz die beste Wahl?“. Vier Signale deuten darauf hin, dass Sie diese Schwelle überschritten haben.

1. 01
   Sie verarbeiten Daten, die Sie nicht offenlegen können

   Sobald der Prompt proprietären Code, Kundendaten oder personenbezogene Informationen enthält, wird die Klausel zur Nutzung für das Training bei einer kostenlosen API zum Ausschlusskriterium. Der lokale Betrieb löst das Problem an der Wurzel: Keine Daten verlassen das System.
2. 02
   Sie stoßen regelmäßig an die Nutzungslimits

   Wenn Ihre Skripte mit 429-Fehlern abbrechen, wenn Sie Ihre Batches aufteilen, um unter dem TPD-Limit zu bleiben, oder wenn Sie zwischen mehreren kostenlosen Konten jonglieren, bezahlen Sie bereits mit Zeit, die Ihnen der lokale Betrieb zurückgeben würde.
3. 03
   Das Volumen ist vorhersehbar und dauerhaft hoch

   Regelmäßiger Einsatz – kontinuierliche Testgenerierung, eine interne RAG-Pipeline, dauerhaft laufende Klassifikation – rechnet sich beim lokalen Betrieb schnell. Die Hardware verursacht Fixkosten, die sich amortisieren; eine nutzungsabhängig abgerechnete API verursacht variable Kosten, die mit dem Erfolg des Projekts steigen.
4. 04
   Sie wollen eine kontrollierte Latenz

   Auf einer dedizierten Maschine hängt die Latenz ausschließlich von Ihnen ab, nicht von der Belastung eines geteilten Dienstes. Für ein internes Tool, das den ganzen Tag genutzt wird, ist diese Vorhersagbarkeit wertvoll.

#Beides behalten: intelligentes Routing

Die sinnvollste Architektur für ein Entwicklungsprojekt legt sich nicht ausschließlich auf eine Lösung fest: Sie leitet jede Aufgabe an den am besten geeigneten Endpunkt weiter. Lokal wird der Großteil des Volumens verarbeitet, ebenso alles Sensible; die Cloud bleibt Aufgaben vorbehalten, die tatsächlich die Leistungsfähigkeit des Rechners übersteigen.

Zu lokalen Systemen

Aufgaben mit hohem Volumen, sensible Daten, Verarbeitungsschleifen, Entwicklungsiterationen, alles, was vertraulich bleiben muss. Ein lokales 7–14B-Modell deckt die überwältigende Mehrheit der üblichen Entwicklungsanforderungen ab.

In die Cloud

Komplexe Denkaufgaben, die ein sehr großes Modell erfordern, eine vorübergehende Lastspitze oder eine lokal nicht verfügbare multimodale Funktion. Dorthin wird nur geschickt, was dies rechtfertigt, und niemals sensible Daten.

Da Ollama eine OpenAI-kompatible API bereitstellt, lässt sich dieses Routing ganz einfach programmieren: zwei Clients und eine Auswahlregel je nach Aufgabe. Für weitergehende Anforderungen bündelt ein Proxy wie LiteLLM mehrere Backends hinter einer einzigen Schnittstelle, mit automatischem Fallback von der Cloud zum lokalen Betrieb (oder umgekehrt) und Kostenverfolgung.

from openai import OpenAI

local = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
cloud = OpenAI(base_url="https://api.exemple.com/v1", api_key="VOTRE_CLE")

def router(sensible: bool, gros_raisonnement: bool):
    # Données sensibles OU volume : local par défaut
    if sensible or not gros_raisonnement:
        return local, "qwen2.5:7b"
    # Sinon, cloud pour un modèle plus puissant
    return cloud, "modele-frontiere"

client, model = router(sensible=True, gros_raisonnement=False)
resp = client.chat.completions.create(
    model=model,
    messages=[{"role": "user", "content": "Résume ce ticket interne..."}],
)

#In lokaler Umgebung in 4 Schritten starten

1. 01
   Ollama installieren

   Ein Befehl unter Linux/macOS (curl -fsSL https://ollama.com/install.sh | sh) oder das offizielle Installationsprogramm unter Windows. Der Daemon startet und lauscht auf http://localhost:11434.
2. 02
   Ein Modell auswählen, dessen Größe zu Ihrer Hardware passt

   Ermitteln Sie Ihren verfügbaren VRAM und wählen Sie ein Modell in Q4_K_M, das hineinpasst und noch Speicherreserve für den Kontext lässt: 7B (~5 GB) für 8–12 GB VRAM, 14B (~9 GB) für 12–16 GB, 32B (~19 GB) für 24 GB. Bei weniger VRAM bleibt ein 3B-Modell (~2 GB) für einfache Aufgaben nützlich.
3. 03
   Modell herunterladen und testen

   ollama pull qwen2.5:7b puis ollama run qwen2.5:7b pour vérifier qu'il répond. Un pull ne se fait qu'une fois ; ensuite le modèle est en cache local.
4. 04
   Ihren Code anbinden

   Richten Sie Ihren bestehenden OpenAI-Client auf http://localhost:11434/v1 aus. Der restliche Code – Nachrichten, Streaming, Function Calling – funktioniert wie mit einer Cloud-API, ohne Schlüssel oder Kontingent.

#Weiterführende Informationen

Sobald Ollama eingerichtet ist, bieten drei Leitfäden dieser Website passende nächste Schritte nach diesem Umstieg. Der Leitfaden zur Integration der REST-API von Ollama in Python erläutert Streaming, JSON-Modus und Function Calling am lokalen Endpunkt. Der Kostenvergleich für einen GPU-Server beziffert die Rentabilitätsschwelle zwischen Hardwarekauf und Cloud-API. Und für ein professionell betriebenes Routing zwischen lokal und Cloud zeigt der LiteLLM-Leitfaden, wie sich beide hinter einem Proxy mit Fallback und Kostenverfolgung vereinheitlichen lassen.