Einleitung, Überblick und Definitionen

Dieses Material entstand auf der Grundlage eines Vortrags¹ über Self-Hosting von LLMs, der auf dem Datenfestival des Civic Data Lab gehalten wurde. Es soll den Vortrag zugänglicher machen, umfassend über das Thema informieren und einen praxisorientierten Überblick geben.

Unter Self-Hosting wird der (auf unterschiedlichen Leveln) eigenständige Betrieb von Infrastruktur verstanden, auf der in diesem Fall LLMs und mit diesen zusammenhängende Software läuft.

Warum Self-Hosting?

Die Nutzung proprietärer LLM-Dienste ist mit Abhängigkeiten, Intransparenz und mangelnder Kontrolle verbunden. Bei kommerziellen Anbietern bleibt unklar, wie Daten tatsächlich verarbeitet werden, wie die Modelle trainiert wurden und welche Eigenschaften sie besitzen. Auch die Funktionsweise eingebundener Tools wie Websuche sowie der tatsächliche Ressourcenverbrauch sind nicht nachvollziehbar. Self-Hosting adressiert diese Problematik und trägt zur digitalen Souveränität bei: Organisationen und Privatpersonen erlangen, je nach Art des Selfhostings, mehr Transparenz und Kontrolle über den LLM-Betrieb – von der Datenverarbeitung über die Modellauswahl bis hin zum Energie- und Ressourcenverbrauch.

Aufbau der Dokumentation

Im Verlauf dieses Materials wird aufeinander aufbauend in eine Reihe von Aspekten des Self-Hostings von LLMs eingeführt:

• Im 1. Kapitel werden LLMs an sich behandelt. Was ist ein LLM genau? Das Kapitel erklärt außerdem den Unterschied zwischen Open-Weight- und Open-Source-Modellen, gibt einen Überblick über Lizenzmodelle und deren Implikationen, erläutert Quantisierung als zentrale Optimierungstechnik, stellt Hugging Face als primäre Bezugsquelle vor und beschreibt gängige Metriken und Benchmarks zur Modellbewertung.

• Im 2. Kapitel werden die Fragen beantwortet: Was wird selbst gehostet, wie werden LLMs betrieben und welche Komponenten werden außer dem LLM benötigt? Hier werden konkrete Software-Komponenten für die verschiedenen Teile eines LLM-Systems vorgestellt. Von Inference-Servern über Chat-Interfaces bis zu API-Gateways und Vektor-Datenbanken. Als praktisches Beispiel wird Parrotpark vorgestellt, ein vollständiges self-gehostetes LLM-System, das die Integration verschiedener Open-Source-Komponenten demonstriert.

• Das 3. Kapitel beantwortet die Frage: Worauf wird selbst gehostet? Das Kapitel enthält einen Vergleich zwischen den verschiedenen Infrastrukturoptionen. Außerdem behandelt das Kapitel Hardware-Anforderungen (CPU vs. GPU, VRAM-Größen, GPU-Generationen) sowie Aspekte wie Ressourcenverbrauch.

• In Kapitel 4 werden Alternativen zum vollständigen Self-Hosting vorgestellt, die je nach Anforderung Sinn ergeben können.

1. Die Slides des Vortrags lassen sich hier finden, begleitender Code hier. ↩

Open LLMs

Was ist ein LLM?

LLMs (Large Language Models) sind große neuronale Netzwerke. Das ist eine Struktur aus vielen miteinander verbundenen Schichten aus Modellen biologischer Neuronen (basierend auf dem, was 1943 über Neuronen bekannt war) [mcculloch_logical_1943]. Diese Neuronenmodelle führen einzelne Rechnungen aus, bei denen konfigurierbare Parameter verwendet werden. Beim Training von LLMs werden Millionen oder sogar Milliarden dieser Parameter nach und nach angepasst, bis der Output des Modells den Trainingsdaten entspricht.

Die bekanntesten LLMs sind generativ, haben also als Input und als Output (mindestens) Text. Andere LLMs haben als Output Zahlen in Form von Vektoren, die den Text-Input semantisch repräsentieren sollen, sogenannte Embeddings. Multimodale LLMs können z.B. auch Bilder verarbeiten und deren Inhalt sprachlich repräsentieren.

Generell wird der Output hergestellt durch zahlreiche Matrizenrechnungen, die sich besonders effizient auf spezialisierter Hardware wie GPUs (Graphics Processing Unit/Grafikkarten) ausführen lassen, da sie dort in großer Zahl gleichzeitig passieren können.

Modelle können als Dateien verfügbar gemacht werden, die sowohl die Architektur als auch die trainierten Parameter eines Modells enthalten und somit selbst betrieben werden können. Für das Self-Hosting von LLMs stehen zahlreiche solcher Modelle zur Verfügung. Dieses Kapitel gibt einen Überblick über die wichtigsten Aspekte bei der Modellauswahl und -bewertung.

Open Weight vs. Open Source

Im Kontext von Large Language Models wird häufig von Open-Source-Modellen gesprochen, obwohl die meisten dieser Modelle technisch gesehen Open-Weight-Modelle (hier auch Open Modelle genannt) sind. Der Unterschied mag unwichtig klingen, hat jedoch Bedeutung für die Einordnung dessen, was die Urheber der LLMs wirklich bereitstellen:

• Open-Weight-Modelle stellen die trainierten Modellparameter (Weights) öffentlich zur Verfügung. Nutzer:innen können diese Modelle herunterladen, ausführen und für eigene Zwecke verwenden. Allerdings sind oft weder die Trainingsdaten noch der vollständige Trainingscode verfügbar.

• Open-Source-Modelle im engeren Sinne gehen weiter: Sie veröffentlichen nicht nur die Modellparameter, sondern auch die Trainingsdaten, den Trainingscode und die gesamte Entwicklungspipeline. Dies ermöglicht vollständige Reproduzierbarkeit und Transparenz.

Für Self-Hosting sind beide Varianten geeignet, wobei Open-Weight-Modelle deutlich verbreiteter sind. Die Wahl zwischen beiden hängt davon ab, wie wichtig vollständige Transparenz und Reproduzierbarkeit für den jeweiligen Anwendungsfall sind.

Bekannte Open (Source) Modelle

Die Zahl der Open Modelle nahm in den letzten Jahren rasant zu. Die meisten der größten Tech-Unternehmen haben mittlerweile Open-Modelle entwickelt, darunter Google (Gemma), Microsoft (Phi), Meta (Llama), oder IBM (Granite). Andere bekannte Anbieter und Modelle sind:

• Mistral AI: Mistral Small 3.1

• OpenAI: gpt-oss

• Allen Institute for Artificial Intelligence: Olmo

Hugging Face: Wo findet man Open Modelle und in welchen Varianten gibt es sie?

Hugging Face ist die zentrale Plattform für das Teilen von Open-Weight- und Open-Source-LLMs. Sie fungiert als Repository, Community-Hub und Entwicklungsplattform.

Tausende von Modellen sind verfügbar, von kleinen spezialisierten Modellen bis zu großen Frontier-Modellen. Jedes Modell verfügt über eine Seite mit Beschreibung, Lizenzinformationen, Nutzungsbeispielen und Download-Links. Filter ermöglichen die Suche nach Modellgröße, Aufgabe, Lizenz und weiteren Kriterien.

Modelle können direkt über die Webseite heruntergeladen oder programmgesteuert über die Hugging Face API bezogen werden. Die meisten Inference-Server können Modelle automatisch von Hugging Face laden, indem lediglich der Modellname angegeben wird (z.B. mistralai/Mistral-7B-Instruct-v0.2).

Varianten von Modellen

Die Varianten und damit zusammenhängende Benennung von Modellen kann etwas verwirrend sein.

• mistralai/Mistral-Small-24B-Instruct-2501: Organisation (mistralai) / Modellfamilie (Mistral-Small) / Parameterzahl (24 Milliarden) / Fähigkeit (Instruct für Anweisungen) / Release-Datum (Januar 2025)

• Qwen/Qwen3-VL-2B-Thinking-FP8: Organisation (Qwen/Alibaba) / Familie (Qwen) / Generation (3) / Modalität (VL für Vision-Language) / Parameterzahl (2 Milliarden) / Fähigkeit (Thinking für Reasoning) / Quantisierung (FP8 für 8-bit Floating Point)

Oft werden neben Instruct oder Thinking Varianten auch Base-Varianten veröffentlicht, die noch nicht an das Ausführen von Anweisungen angepasst worden sind, sondern nur Sprache vervollständigen können.

Quantisierung

Das FP8 in Qwen3-VL-2B-Thinking-FP8 steht für das Datenformat der Parameter des Modells. Dieses Modell wurde während oder nach dem Training quantisiert. Quantisierung ist eine Technik zur Reduzierung der Modellgröße und des Speicherbedarfs, die für Self-Hosting von zentraler Bedeutung ist. Bei der Quantisierung werden die Modellparameter von höherer Präzision (z.B. 16-Bit oder 32-Bit Floating Point) in niedrigere Präzision (z.B. 8-Bit, 4-Bit oder sogar 2-Bit) konvertiert. Dies reduziert den benötigten GPU-Speicher (VRAM) erheblich.

Quantisierung führt zu leichten Qualitätseinbußen bei den Modellantworten. Moderne Quantisierungsmethoden minimieren diese Verluste jedoch stark. In vielen Anwendungsfällen ist der Qualitätsunterschied kaum wahrnehmbar, während die Geschwindigkeit deutlich zunimmt.

Für Self-Hosting sind quantisierte Modelle oft die einzige praktikable Option. Die meisten Inference-Server unterstützen verschiedene Quantisierungsformate, und auf Hugging Face sind bereits quantisierte Versionen beliebter Modelle verfügbar.

Auswahl von Modellen - Evaluation von LLMs

LLMs zu evaluieren ist aufgrund der Größe ihres Einsatzgebiets und der Art ihrer Fähigkeiten keine einfache Aufgabe. LLMs sind als Teil des Gebiets des Machine Learning eine KI-Technologie. Künstliche Intelligenz heißt so, weil diese Technologie in Relation zur menschlichen Intelligenz gestellt wird: Es besteht Ähnlichkeit bei Zielen, Herstellung oder Funktionsweise (bei Komponenten) von Intelligenz [unesco_ethik_2023]. Misst man bei der Evaluation von LLMs deren Intelligenz? Das ist mindestens umstritten.

Eine pragmatische Herangehensweise setzt bei der konkreten Aufgabe an, die ein LLM erfüllen soll. Will man es z.B. zur Klassifikation deutscher Texte verwenden, kann man herkömmliche Metriken wie den F-Score nutzen. Hat man bereits klassifizierte Texte, kann man Modelle selbst testen.

Man kann sich jedoch auch an vorhandenen aufgabenbezogenen Benchmarks orientieren. Ein Beispiel dafür ist languagebench, das neben Tasks wie Klassifikation auch zwischen der Performance auf unterschiedlichen Sprachen unterscheidet.

Andere vorhandene Benchmarks testen LLMs auf einem breiteren, mehr mit Intelligenz verbundenen Level. Humanities Last Exam enthält Problemstellungen in akademischen Disziplinen. Auch wenn es sich um einen provokanten Titel handelt, schreiben die Urheber:innen des Tests, dass es sich um keinen generellen Test auf Intelligenz handele, sondern um eine “gezielte Messung von technischem Wissen und Denkvermögen”. Wie man in der Rangliste sieht, sind große, proprietäre Modelle Open Modellen voraus.

Benchmarks sind nützliche Orientierungshilfen, aber nehmen einem nicht vollständig die Entscheidung ab. Sie können anfällig für Overfitting sein (Modelle werden auf Benchmark-Performance optimiert), oder Daten aus Benchmarks sind in den Trainingsdaten enthalten (was die Ergebnisse verfälscht), bilden nicht alle vorstellbaren Aufgaben ab und sagen wenig über das Verhalten in spezifischen Anwendungsfällen aus. Für Self-Hosting-Projekte empfiehlt sich, Modelle auch anhand eigener, anwendungsspezifischer Tests zu evaluieren.

Lizenzen

Bevor man ein selbst gehostetes Modell anderen zur Verfügung stellt oder in manchen Fällen sogar selbst nutzt, sollte man sich mit den Lizenzen von LLMs beschäftigen. Diese unterscheiden sich erheblich und geben vor wie die Modelle genutzt werden dürfen:

• Permissive Lizenzen (z.B. Apache 2.0, MIT): Erlauben kommerzielle Nutzung, Modifikation und Weiterverbreitung mit minimalen Einschränkungen. Beispiele: Viele Modelle von Mistral, Qwen-Modelle oder Modelle aus der GPT-OSS-Familie.

• Restriktive Lizenzen: Erlauben Nutzung und Modifikation, schränken aber kommerzielle Nutzung ein oder verlangen Lizenzgebühren ab einer bestimmten Nutzerzahl. Beispiel: Llama-2-Modelle und Llama-3-Modelle. Sehr restriktiv sind die Lizenzen bei multimodalen Llama-3-Modellen [weatherbed_meta_2024] oder bei allen Llama-4-Modellen [schwarze_meta_2025], da diese nicht in der EU verwendet werden dürfen.

Die Lizenzen sind in der Regel auf den Modell-Seiten bei Hugging Face oder auf den Websites der Entwickler dokumentiert.

Was wird (wofür) selbst gehostet?

Im Falle des Self-Hostings von LLM-Systemen stellt sich die Frage, welche Komponenten man neben dem LLM an sich selbst betreiben will. Dies hängt ähnlich wie die Auswahl des Modells vom konkreten Einsatzzweck ab. Der häufigste Wunsch ist eine Art privates Chat-GPT, also ein KI-Assistent mit unterschiedlichen Fähigkeiten mit dem man über eine grafische Oberfläche chatten kann. Während andere Arten von LLM-Systemen möglich sind, sollen hier die Komponenten eines solchen Assistenten beschrieben werden.

Grundfunktionalitäten solcher KI-Systeme sind oft:

• RAG: Bei RAG wird meistens semantische Suche verwendet. Dabei verarbeitet ein LLM Texte zu sogenannten Embeddings. Embeddings sind Vektoren, die den Textinhalt in numerischer Form repräsentieren. Diese Embeddings ermöglichen es, inhaltlich ähnliche Dokumente zu finden und dem LLM als Kontext bereitzustellen.

• Tools: Hierbei handelt es sich um eine dem LLM externe Code-Komponente, die das LLM über ein spezielles Interface (heutzutage meistens MCP) nutzen kann.

• Multimodalität: Es können auch Bilder oder PDFs hochgeladen werden, die Teil des Inputs an das LLM sind

Zunächst lässt sich zwischen Frontend (die Software, die Nutzer:innen sehen und oft direkt im Browser läuft) und Backend (Software, mit der Nutzer:innen nicht direkt interagieren) unterscheiden.

Frontend: Meistens ein Chat Interface, über das Nutzer:innen Input an das LLM-System senden und Output anzeigen.

Backend:

• Inference-Server: Software, auf der ein LLM betrieben wird. Auf solchen Servern können sowohl generative LLMs als auch Embedding-Modelle betrieben werden.
• Vektor-Datenbank: Wird für RAG (Retrieval-Augmented Generation) benötigt. RAG ergänzt informationsbezogene Anfragen an LLMs mit relevanten Dokumenten aus einem Suchschritt mithilfe einer Datenbank.
• API Gateway: Verwaltet und standardisiert den Zugriff auf die Inference-Server
• MCP-Server: Hier werden die Tools gehostet, die das LLM nutzen kann
• Zusätzliche Dienste wie Authentifizierung und Dateipeicher

Parrotpark

Fig. 1 zeigt ein Beispiel für ein vollständiges Setup. Parrotpark¹ besteht aus zwei Servern:

• Eingangsserver: Permanenter Server, der Proxy, Datenbanken und einen Scheduler hostet
• Ephemerer GPU Server: Wird vom Scheduler regelmäßig neu erstellt und hostet die rechenintensiven LLM-Komponenten

flowchart LR
    Keycloak[Keycloak]
    buckets[S3 Buckets Tools]

    subgraph proxy[Eingangsserver]
        direction TB
        Caddy
        Databases[Vektor-DB und Anwendungs-DB]
        Scheduler
    end

    subgraph gpu[Ephemeral GPU Server]
        direction TB
        vLLM[vLLM Inference-Server]
        LiteLLM[LiteLLM API Gateway]
        LibreChat[LibreChat Chat Interface]
    end

    LibreChat -->|SSO Auth| Keycloak
    LibreChat -->|Speicherung| buckets
    LiteLLM --- Databases
    LibreChat --- Databases
    Caddy -->|Proxy| LiteLLM
    Caddy -->|Proxy| LibreChat
    Scheduler -->|Erstellt periodisch| gpu

Open Source Software für LLM-Assistenten

Im Gegensatz zu den meisten Open LLMs ist die begleitende Software komplett Open Source. Am häufigsten wird solche Software über die ebenfalls Open Source Technologie der Containerisierung (mit Docker und Docker Compose) betrieben. Bei Parrotpark eingesetzt und miteinander verbunden:

• Chat Interface: LibreChat
• Inference-Server: vLLM (für generatives LLM und Embedding-Modell)
• Vektor-Datenbank: pgvector
• API Gateway: LiteLLM – ermöglicht mehr Kontrolle (z.B. Token-Verwaltung) und standardisiert die API
• Authentifizierung: Keycloak für User-Verwaltung und SSO (Single Sign-On)
• Anwendungsdatenbank: Speichert Chatverläufe und Nutzereinstellungen für LibreChat und LiteLLM
• Proxy: Caddy – regelt SSL-Verschlüsselung für HTTPS und leitet Anfragen weiter
• S3-Buckets für Dateispeicherung, Scheduler für automatische Server-Verwaltung

Übersicht weiterer Open-Source-Software

Neben den bei Parrotpark eingesetzten Komponenten gibt es zahlreiche weitere Open-Source-Alternativen für die verschiedenen Bereiche eines selbst gehosteten LLM-Systems:

Chat Interface

• Open WebUI: Vollständiges, selbst-hostbares Web-Interface mit ChatGPT-ähnlicher Oberfläche, Multi-User-Support, Dokumenten-Upload und RAG-Integration
• text-generation-webui: Feature-reiches Interface mit vielen Anpassungsmöglichkeiten, besonders für Power-User

Inference Server

• vLLM: Hochperformanter Inference-Server mit PagedAttention für effizientes Memory-Management.
• Ollama: Einfach zu nutzender Server mit One-Command-Installation und automatischem Modell-Download
• llama.cpp: CPU-optimierter Inference-Server in C++, läuft auch ohne GPU
• LM Studio: Desktop-Anwendung mit GUI für lokales Modell-Management
• TGI (Text Generation Inference): Server von Hugging Face

Vektor Datenbank

• Chroma
• Qdrant
• Milvus
• Weaviate

1. Mehr Informationen zu Parrotpark hier. ↩

Worauf wird gehosted?

Worauf wird selbst gehostet?

LLMs lassen sich prinzipiell auf fast allen Arten von Infrastruktur betreiben – sogar auf einem Raspberry Pi. Die praktisch erreichbare Geschwindigkeit, Modellqualität und Länge des In- und Outputs unterscheiden sich jedoch erheblich abhängig von der Hardware. Dieses Kapitel beschreibt die Hardware-Anforderungen für LLM-Hosting, die verschiedenen Infrastruktur-Optionen von lokal bis Cloud und den damit verbundenen Ressourcenverbrauch.

Self-Hosting kann an verschiedenen Orten erfolgen:

• Lokal (On-Premises): Betrieb auf dem eigenen Laptop oder auf dedizierten Servern, die in den Räumlichkeiten einer Organisation oder Privatperson stehen. Dies bedeutet volle Kontrolle über das Setup, aber auch volle Verantwortung für Hardware und Wartung.
• Cloud: Server werden in verschiedenen Formen von Cloud-Providern zur Miete angeboten – entweder als virtualisierte Maschine (VM) oder als dedizierte physische Maschine (Bare Metal). Flexibel skalierbar, aber mit laufenden Kosten.
• Hybrid (Co-Hosting): Kauf eigener Server, die jedoch in den Räumen eines Cloud-Providers betrieben und gewartet werden. Kombination aus Eigentum und professioneller Infrastruktur.

Hardware-Anforderungen

CPU vs GPU

Für das Hosting von LLMs stellt sich zunächst die grundlegende Frage: CPU oder GPU?

• CPU-Inferenz ist möglich und für sehr kleine Modelle oder Testszenarien praktikabel. Moderne CPUs können kleine quantisierte Modelle durchaus betreiben. Die Inferenz ist deutlich langsamer als auf GPUs, was für produktive Systeme mit Nutzerinteraktion meist inakzeptabel ist.

• GPU-Inferenz ist für Self-Hosting von LLMs praktisch der Standard. GPUs sind für die massiv parallelen Matrizenoperationen optimiert, die bei der LLM-Inferenz anfallen, weswegen die Geschwindigkeitsunterschiede groß sind.

GPUs

Der GPU-Markt für LLM-Inferenz wird dominiert von NVIDIA, deren CUDA-Ökosystem den De-facto-Standard darstellt. Die meisten Inference-Server und ML-Frameworks sind primär für NVIDIA-GPUs optimiert. AMD holt jedoch auf: ROCm (AMDs Alternative zu CUDA) wird zunehmend besser unterstützt, und AMD-GPUs bieten oft ein besseres Preis-Leistungs-Verhältnis. Für kritische Produktivsysteme ist NVIDIA derzeit die sicherere Wahl, für experimentelle Setups kann AMD eine kostengünstige Alternative sein.

GPU-Spezifikationen

Bei der Auswahl von GPUs für LLM-Hosting sind mehrere Faktoren entscheidend:

VRAM-Größe: Der GPU-Speicher (VRAM) ist oft der limitierende Faktor. Ein Modell muss vollständig in den VRAM passen, um effizient zu laufen

Gängige GPU-VRAM-Größen:

• Consumer-GPUs (z.B. GTX 1660 SUPER, RTX 4090): ~6-24 GB
• Professional GPUs (z.B. A100): 40 GB oder 80 GB
• High-End Datacenter GPUs (z.B. H100, H200): 80 GB bzw. 141 GB (H200)

Die H200 mit 141 GB VRAM stellt aktuell das obere Ende des Spektrums dar und ermöglicht den Betrieb sehr großer Modelle auf einer einzelnen GPU.

GPU-Generationen: Neuere GPU-Generationen unterstützen moderne Quantisierungstechniken besser als ältere Generationen. Die Unterstützung für manche Datentypen wurde erst in neueren Generationen eingeführt. Bei der Hardwareauswahl oder der Modell-Suche sollte daher nicht nur die VRAM-Größe, sondern auch die GPU-Generation berücksichtigt werden, da dies direkten Einfluss auf verfügbare Quantisierungsoptionen und Performance hat.

Ressourcenverbrauch

Der Betrieb von LLM-Infrastruktur ist ressourcenintensiv. Die beiden Hauptfaktoren sind Kühlung und Stromverbrauch, die eng miteinander verbunden sind.

Kühlung

Leistungsfähige GPUs erzeugen erhebliche Abwärme, die abgeführt werden muss, um Überhitzung und Hardware-Schäden zu verhindern. Die Wahl des Kühlungssystems hat direkten Einfluss auf Energieeffizienz und Umweltauswirkungen.

Luftkühlung ist der Standard bei den meisten Cloud-Providern und für lokales Hosting. Sie ist technisch einfach und zuverlässig: Ventilatoren transportieren kühle Luft an die Hardware und führen erwärmte Luft ab. Der Nachteil: Luftkühlung ist energieintensiv, da große Luftmengen bewegt werden müssen und die Kühleffizienz begrenzt ist. In Rechenzentren muss zusätzlich die Raumtemperatur reguliert werden, was den Energieaufwand weiter erhöht. Anbieter wie Hetzner setzen ausschließlich auf Luftkühlung.

Wasserkühlung (bzw. Flüssigkeitskühlung) ist deutlich effizienter: Wasser kann Wärme besser transportieren als Luft bei gleichem Volumen. Moderne Flüssigkeitskühlsysteme können Abwärme direkt am Chip abführen und reduzieren den Energieaufwand für Kühlung erheblich. Allerdings verdunstet ein Teil des Kühlwassers, was zu Wasserverbrauch führt.

Transparenz und Nachhaltigkeit: Die Umweltauswirkungen der Kühlsysteme sind oft schwer nachvollziehbar. Life Cycle Assessments (LCAs), wie sie beispielsweise Mistral veröffentlicht hat, bieten einen systematischen Ansatz zur Bewertung von Energieverbrauch und Umweltauswirkungen über den gesamten Lebenszyklus – von der Hardware-Produktion über den Betrieb bis zur Entsorgung.

Strom

CPU, GPU und andere Teile eines Servers, wie das Kühlungssystem, verbrauchen Strom. Besonders hoch ist der Verbrauch bei GPUs. Datacenter-GPUs haben einen erheblichen Energiebedarf.

Bei lokalem Hosting ist der Stromverbrauch ein Kostenpunkt, während bei Cloud-Hosting die Stromkosten in den Mietpreisen enthalten sind.

Alternativen und Vergleich

Alternativen zum vollständigen Self-Hosting

Self-Hosting ist nicht immer die optimale Lösung. Je nach Anforderungen können andere Ansätze sinnvoller sein.

Vor der Entscheidung für Self-Hosting oder Cloud-APIs sollte geprüft werden, ob z.B. ein RAG-System die richtige Technologie ist. Oft reicht eine klassische Volltextsuche mit verbessertem Wissensmanagement.

Managed LLM-Services

DSGVO-konforme Lösungen

• OpenAI auf Azure / Claude auf AWS: State-of-the-Art-Modelle mit EU-Rechenzentren und DSGVO-konformen Verträgen

LLM-Anbieter in der EU

• Scaleway Generative APIs: Open-Weight-Modelle in französischen Rechenzentren
• IONOS Generative APIs: LLM-Services mit Hosting in Deutschland

Kosteneffiziente API-Aggregatoren

• OpenRouter: Große Modellauswahl, sehr wettbewerbsfähige Preise (US-Datenschutz)

Kostenvergleich: Self-Hosting vs. API-Services (Parrotpark)

Self-Hosting: Scaleway GPU-Instanz (L4)

• Automatisierte Bereitstellung nur während Arbeitszeiten (10h/Tag, 5 Tage/Woche)
• Berechnung: $0.75,\text{€/h} \times (10,\text{h} \times 5,\text{Tage} \times 4,\text{Wochen}) = 150,\text{€}$
• Mit MwSt. (19%): 178.50€/Monat

Cloud-API: OpenRouter (gleiches Modell)

• Für 178.50€ erhält man bei 50/50 Input/Output-Split: 3,154M Tokens

Tatsächlicher Verbrauch (2 Wochen Parrotpark-Evaluation)

• Input: 329,503 Tokens | Output: 103,083 Tokens | Gesamt: 432,586 Tokens
• API-Kosten: $0.027 (€0.02)
• Hochgerechnet auf Monat: ca. €0.05

Über das Material

Die Inhalte dieser Seite wurden von Jonas Stettner (CorrelAid e.V., tätig im Civic Data Lab) erstellt.

Der Source Code dieser Seite befindet sich in einem GitHub Repository.

Lizenz

• Attributionsvorschlag: ”LLM-Hosting” von Jonas Stettner (CorrelAid e.V. / Civic Data Lab), abgerufen am DATUM. Lizensiert unter CC-BY 4.0.
• Attributionsvorschlag für einzelne Abschnitte / Unterseiten: ”[Unterseite]” in ”LLM-Hosting” von Jonas Stettner (CorrelAid e.V. / Civic Data Lab), abgerufen am [Datum]. Lizensiert unter CC-BY 4.0.

Beitragen

Du möchtest etwas beitragen zu dieser Website? Darüber freuen wir uns sehr!

Wenn du dich mit Git, GitHub und Markdown auskennst, freuen wir uns über einen Issue und dazugehörigen Pull Request im GitHub Repository. Du hattest beim Lesen des vorherigen Satzes nur Fragezeichen und innere “Hä?”-Momente? Gar kein Problem! Schreib uns gern eine Email an jonas.s@correlaid.org mit deinen Erkenntnissen. Wir kümmern uns dann um die Online-Stellung!

Literaturverzeichnis