{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/de/autor/alexander-bock/"},"categories":["AI Development"],"content":{"markdown":"Über eine API mieten Sie die Antworten eines Modells. Im Eigenbetrieb läuft das Modell auf Hardware, die Sie kontrollieren. Möglich machen das **Modelle mit offenen Gewichten** (Open-Weight-Modelle): Ihre trainierten Parameter — die Gewichte — sind veröffentlicht, jeder kann sie herunterladen und ausführen. Mit den Gewichten übernehmen Sie aber auch alle Aufgaben, die sonst der API-Anbieter erledigt: GPUs, Skalierung, Updates, Sicherheit und Inhaltsfilter.\n\nDies ist Teil 2 von Level 4 (Experte) im Lernpfad AI Development. Sie erfahren, wann sich der Eigenbetrieb lohnt, wie Sie Lizenzen offener Modelle lesen, welche Software aus Gewichten einen Endpunkt macht, wie Sie den GPU-Speicher planen und wie weit offene Modelle in unseren Daten hinter geschlossenen liegen. Der Teil setzt [GPU-Infrastruktur für KI](/de/ai-development/learn/gpu-infrastructure-for-ai/) aus Level 3 fort.\n\n## Wann sich der Eigenbetrieb lohnt\n\nTeams betreiben Modelle aus fünf Gründen selbst:\n\n- **Datenhoheit.** Prompts und Dokumente verlassen Ihr Netz nie. Das zählt bei Gesundheitsdaten, Rechtsakten und im öffentlichen Sektor.\n- **Versionshoheit.** Das Modell ändert sich nur, wenn Sie es ändern. Kein Anbieter kann es abschalten oder sein Verhalten verändern.\n- **Anpassung.** Sie können die Gewichte feintunen oder kleine Adapter je Aufgabe laden. Level 3 vergleicht [Fine-Tuning, RAG und Prompting](/de/ai-development/learn/fine-tuning-vs-rag-vs-prompting/).\n- **Kosten bei Masse.** Bei gleichmäßig hohem Verkehr erzeugt eine gut ausgelastete GPU Tokens günstiger als eine API. Bei unregelmäßigem Verkehr machen ungenutzte GPUs es teurer.\n- **Standort.** Das Modell läuft dort, wo Sie es brauchen: im eigenen Haus, am Edge oder ganz ohne Internetverbindung.\n\nDer Preis ist der Betrieb. Jemand muss Treiber aktualisieren, den Speicher überwachen, Lastspitzen abfangen und nachts auf Alarme reagieren. Und die stärksten Modelle in unseren Daten haben geschlossene Gewichte — für mehr Kontrolle geben Sie unter Umständen etwas Leistung ab.\n\n![Vier-Felder-Matrix mit dem Verkehr auf der waagerechten und dem Bedarf an Kontrolle auf der senkrechten Achse: API bei unregelmäßigem Verkehr und wenig Kontrollbedarf, Eigenbetrieb bei gleichmäßigem Verkehr und hohem Kontrollbedarf, ein kleines Modell, das auf null skaliert, bei unregelmäßigem Verkehr und hohem Kontrollbedarf, und ein Kostenvergleich bei gleichmäßigem Verkehr und wenig Kontrollbedarf](/images/learn/de/self-host-open-weight-models-decide.webp \"Gleichmäßiger Verkehr und hoher Kontrollbedarf sprechen für den Eigenbetrieb, unregelmäßiger Verkehr für eine API.\")\n\n## Offene Gewichte sind nicht immer Open Source\n\n„Offen“ beschreibt die Gewichte, nicht unbedingt Ihre Rechte. Die Open Source Initiative hat im Oktober 2024 ihre Open Source AI Definition 1.0 veröffentlicht. Sie verlangt mehr als die Gewichte: auch den Code und genaue Angaben zu den Trainingsdaten. Viele bekannte Open-Weight-Modelle erfüllen diese Definition nicht. Für Ihr Projekt zählt vor allem die Lizenz — und die Lizenzen unterscheiden sich stark:\n\n- **Übliche Open-Source-Lizenzen** wie Apache 2.0 oder MIT erlauben die kommerzielle Nutzung mit wenigen Auflagen. Mistral 7B zum Beispiel erschien unter Apache 2.0, DeepSeek-R1 unter der MIT-Lizenz.\n- **Eigene Modell-Lizenzen** fügen Bedingungen hinzu. Die Lizenz von Metas Llama 2 etwa verlangte von Unternehmen mit mehr als 700 Millionen monatlich aktiven Nutzern, bei Meta eine gesonderte Lizenz zu beantragen (Quelle: Meta, Llama 2 Community License, 2023). Viele eigene Lizenzen enthalten außerdem Nutzungsrichtlinien (Acceptable Use Policy).\n- **Forschungs- oder nichtkommerzielle Lizenzen** schließen die kommerzielle Nutzung ganz aus.\n\nBevor ein Modell in Produktion geht, beantworten Sie diese Fragen — gemeinsam mit Ihrer Rechtsabteilung:\n\n| Frage | Warum sie zählt |\n|---|---|\n| Ist kommerzielle Nutzung erlaubt? | Manche Gewichte sind nur für die Forschung freigegeben |\n| Gibt es Schwellen für Nutzerzahlen oder Umsatz? | Wachstum kann eine neue Lizenz erfordern |\n| Gibt es Nutzungsrichtlinien? | Sie verbieten bestimmte Einsätze und können sich ändern |\n| Gibt es Regeln für Nennung oder Namen? | Ihr Produkt braucht vielleicht einen Hinweis oder eine Namensregel |\n| Dürfen Sie feingetunte Fassungen weitergeben? | Abgeleitete Modelle können unter dieselbe Lizenz fallen |\n| Dürfen Ausgaben andere Modelle trainieren? | Wichtig, wenn Sie Destillation planen |\n\nPrüfen Sie die Lizenz jeder Version: Die Bedingungen können sich von einer Modellgeneration zur nächsten ändern.\n\n## Serving-Software: von den Gewichten zum Endpunkt\n\nGewichte sind nur große Dateien. Um sie bereitzustellen, brauchen Sie einen Stapel Software zwischen GPU und Ihren Apps:\n\n![Fünf Schichten von oben nach unten: Gateway, API-Server, Inferenz-Engine, Modelldateien und Hardware, daneben ein Kasten für das Monitoring mit Zeit bis zum ersten Token, Tokens pro Sekunde, Warteschlange, GPU-Speicher und Fehlern](/images/learn/de/self-host-open-weight-models-stack.webp \"Der Stack für den Eigenbetrieb: Die Inferenz-Engine entscheidet, wie viele Anfragen eine GPU bedienen kann.\")\n\nHerzstück ist die **Inferenz-Engine**. Bekannte Open-Source-Lösungen sind vLLM, SGLang und TensorRT-LLM von NVIDIA für GPU-Server sowie llama.cpp oder Ollama für Laptops und kleine Server. Mehrere davon bieten eine OpenAI-kompatible API, sodass das Gateway aus [Teil 1](/de/ai-development/learn/production-llm-architecture/) Ihr eigenes Modell wie jeden anderen Anbieter ansteuern kann. Gute Engines stützen sich auf einige Techniken; die ersten beiden kamen in Level 3 schon kurz vor:\n\n- **Continuous Batching:** Neue Anfragen steigen bei jedem Generierungsschritt in den laufenden Stapel ein, statt zu warten, bis der ganze Stapel fertig ist. Die Idee stammt aus dem Orca-Paper (Yu et al., OSDI 2022).\n- **Seitenweiser KV-Cache:** Die Engine verwaltet den Speicher für den KV-Cache in kleinen Seiten, wie den virtuellen Speicher eines Betriebssystems. Das spart Verschnitt und bringt mehr parallele Anfragen auf eine GPU (Kwon et al., „PagedAttention“, SOSP 2023, das Paper hinter vLLM).\n- **Präfix-Caching:** Anfragen, die mit demselben Systemprompt beginnen, nutzen die dafür bereits geleistete Arbeit erneut.\n- **Tensor-Parallelismus:** Ein Modell wird auf mehrere GPUs verteilt, wenn es nicht auf eine passt.\n- **Spekulatives Decoding:** Ein kleines Entwurfsmodell schlägt mehrere Tokens vor, das große Modell prüft sie in einem Schritt (Leviathan et al., ICML 2023).\n\nBehandeln Sie Modelldateien wie fremden Code. Bevorzugen Sie das Format **safetensors**: Es speichert nur Tensoren und einen kleinen Kopfbereich und kann beim Laden keinen Code ausführen, anders als ältere Pickle-Dateien von Python. Legen Sie die genaue Revision fest, und prüfen Sie Prüfsummen vor dem Deployment.\n\n## GPU-Speicher planen: Gewichte plus KV-Cache\n\nLevel 3 hat Ihnen die Faustregel für die Gewichte gegeben: Parameter × Bytes je Parameter. Im Betrieb entscheidet der **KV-Cache**, wie viele Nutzer eine GPU bedienen kann. Die Engine führt ihn für jede laufende Anfrage, und er wächst mit jedem Token:\n\n*KV-Cache je Token = 2 × Schichten × KV-Köpfe × Kopfgröße × Bytes je Wert*\n\nNehmen Sie ein Beispielmodell mit 8 Milliarden Parametern, 32 Schichten und 8 Key-Value-Köpfen der Größe 128 in 16-Bit-Genauigkeit: 2 × 32 × 8 × 128 × 2 Byte ≈ 0,13 MB je Token. Eine Anfrage mit 8.192 Tokens Kontext braucht damit etwa 1,1 GB. Zweiunddreißig solcher Anfragen gleichzeitig brauchen etwa 34 GB — rund doppelt so viel wie die Gewichte.\n\n![Waagerechte Balken für ein Beispielmodell mit 8 Milliarden Parametern: Gewichte plus KV-Cache für eine, acht und 32 parallele Anfragen in 16 Bit sowie für 32 Anfragen mit 4-Bit-Gewichten, verglichen mit GPU-Speichergrößen von 24, 48 und 80 GB](/images/learn/de/self-host-open-weight-models-memory.webp \"Beispielrechnung: Bei vielen parallelen Anfragen braucht der KV-Cache mehr Speicher als die Gewichte. Näherung, keine Messung.\")\n\nDrei Hebel senken den Speicherbedarf:\n\n- **Quantisierung** speichert Gewichte mit weniger Bits. Verbreitete Verfahren sind GPTQ (Frantar et al., 2022) und AWQ (Lin et al., 2023) sowie das GGUF-Format von llama.cpp. Manche Engines können auch den KV-Cache in 8 Bit halten. Prüfen Sie die Qualität immer mit Ihrem eigenen Eval-Satz.\n- **Grouped-Query Attention** (Ainslie et al., 2023) lässt mehrere Attention-Köpfe sich Key-Value-Köpfe teilen und verkleinert so den Cache. Sie ist Teil der Modellarchitektur — ein Blick in die Model Card verrät, ob ein Modell sie nutzt.\n- **Kürzere Kontexte** helfen direkt: Eine Grenze für die Gesprächslänge ist zugleich eine Speichergrenze.\n\n**Mixture-of-Experts-Modelle** (MoE) brauchen besondere Sorgfalt. DeepSeek-V3 zum Beispiel hat insgesamt 671 Milliarden Parameter, aktiv sind je Token aber nur 37 Milliarden (Quelle: DeepSeek-V3 Technical Report, 2024). Der Speicher muss alle aufnehmen, der Rechenaufwand je Token liegt dagegen näher an dem eines deutlich kleineren Modells.\n\nMessen Sie dann: Zeit bis zum ersten Token, Tokens pro Sekunde je GPU und wie viele parallele Anfragen laufen, bevor Ihre Latenzziele reißen. Ein Lasttest mit echten Prompts beantwortet diese Fragen besser als jede Formel.\n\n## Der Abstand zur Spitze: was unsere Daten zeigen\n\nUnsere LLM-Datenbank führt {{\u003c stat \"models-open\" \u003e}} Modelle mit offenen und {{\u003c stat \"models-closed\" \u003e}} mit geschlossenen Gewichten. Das Diagramm vergleicht den besten Gesamtindex (ECI), den jede Gruppe zu jedem Zeitpunkt erreicht hatte:\n\n![Liniendiagramm des bisher besten ECI nach Erscheinungsdatum für Modelle mit geschlossenen und mit offenen Gewichten seit 2023; beide Linien steigen, die offene bleibt unter der geschlossenen, und ein Pfeil markiert den Abstand in Monaten auf der Höhe des heute besten offenen Modells](/images/learn/de/self-host-open-weight-models-gap.webp \"Bisher bester ECI offener und geschlossener Modelle. Daten: Epoch AI, CC BY 4.0.\")\n\nBeide Linien steigen, und die offene folgt der geschlossenen. Der Pfeil zeigt, wie viele Monate früher ein geschlossenes Modell erstmals das Niveau des heute besten offenen Modells erreicht hatte; zu anderen Zeitpunkten gemessen, schwankt dieser Abstand. Das sind einige der stärksten Modelle mit offenen Gewichten in unseren Daten:\n\n{{\u003c llm-models \"kimi-k3 deepseek-v4-1-flash deepseek-v4-pro-0813 glm-5-3-flash qwen-3-8-27b\" \u003e}}\n\nLesen Sie den Index mit zwei Einschränkungen. Der ECI misst breite Fähigkeiten über viele Benchmarks; für eine enge Aufgabe wie Klassifizierung oder Extraktion aus Ihren eigenen Dokumenten kann ein kleineres offenes Modell völlig ausreichen. Und die größten offenen Modelle brauchen Server mit mehreren GPUs — prüfen Sie die Größe, bevor Sie Hardware planen. Alle Modelle und Filter finden Sie in unserer [LLM-Datenbank](/de/llm/).\n\n## Checkliste für den Betrieb\n\nEin Modell zu betreiben ist ein Dienst, kein Download. Planen Sie diese Punkte, bevor die erste Nutzerin kommt:\n\n| Bereich | Was Sie einrichten |\n|---|---|\n| Zugang | Kein direkter Zugriff auf den Inferenz-Server; aller Verkehr über das Gateway; kein Internetzugang nach außen |\n| Versionen | Eine festgelegte Modellrevision; neue Versionen erst nach bestandenen Evals |\n| Skalierung | Autoscaling nach Länge der Warteschlange; Reserve, denn ein großes Modell zu laden dauert Minuten |\n| Monitoring | Zeit bis zum ersten Token, Tokens pro Sekunde, Wartezeit, GPU-Speicher, Speicherüberläufe |\n| Sicherheit | Eigene Eingangs- und Ausgabefilter — eine Schutzschicht des Anbieters gibt es nicht |\n| Fallback | Ein API-Modell als Überlauf, wenn Ihre GPUs ausgelastet sind |\n| Kosten | Kosten je Million Tokens = GPU-Kosten pro Stunde ÷ Millionen Tokens pro Stunde, bei echter Auslastung |\n\nVergleichen Sie die Kostenzeile jeden Monat mit derselben Arbeit über eine API; Teil 5 dieses Levels zeigt weitere Wege, [Kosten und Latenz zu optimieren](/de/ai-development/learn/optimize-llm-cost-and-latency/). Infrastruktur für diesen Aufbau finden Sie in unserem Vergleich. Nach Angaben der Anbieter ist Runpod eine GPU-Cloud für Training und Betrieb von Modellen mit Abrechnung nach Verbrauch. Plesk ist ein Kontrollpanel für die Server, auf denen die App rund um das Modell läuft. Pinecone ist eine Vektordatenbank für den Fall, dass Ihr Modell aus Ihren Dokumenten antwortet:\n\n{{\u003c tools \"runpod plesk pinecone\" \u003e}}\n\nFangen Sie klein an: ein Modell, eine Aufgabe, eine GPU, mit einer API als Fallback. Verlagern Sie mehr Verkehr auf eigene Hardware erst, wenn Ihre Evals und der monatliche Kostenvergleich beide dafür sprechen.","text":"Über eine API mieten Sie die Antworten eines Modells. Im Eigenbetrieb läuft das Modell auf Hardware, die Sie kontrollieren. Möglich machen das Modelle mit offenen Gewichten (Open-Weight-Modelle): Ihre trainierten Parameter — die Gewichte — sind veröffentlicht, jeder kann sie herunterladen und ausführen. Mit den Gewichten übernehmen Sie aber auch alle Aufgaben, die sonst der API-Anbieter erledigt: GPUs, Skalierung, Updates, Sicherheit und Inhaltsfilter.\nDies ist Teil 2 von Level 4 (Experte) im Lernpfad AI Development. Sie erfahren, wann sich der Eigenbetrieb lohnt, wie Sie Lizenzen offener Modelle lesen, welche Software aus Gewichten einen Endpunkt macht, wie Sie den GPU-Speicher planen und wie weit offene Modelle in unseren Daten hinter geschlossenen liegen. Der Teil setzt GPU-Infrastruktur für KI aus Level 3 fort.\nWann sich der Eigenbetrieb lohnt Teams betreiben Modelle aus fünf Gründen selbst:\nDatenhoheit. Prompts und Dokumente verlassen Ihr Netz nie. Das zählt bei Gesundheitsdaten, Rechtsakten und im öffentlichen Sektor. Versionshoheit. Das Modell ändert sich nur, wenn Sie es ändern. Kein Anbieter kann es abschalten oder sein Verhalten verändern. Anpassung. Sie können die Gewichte feintunen oder kleine Adapter je Aufgabe laden. Level 3 vergleicht Fine-Tuning, RAG und Prompting. Kosten bei Masse. Bei gleichmäßig hohem Verkehr erzeugt eine gut ausgelastete GPU Tokens günstiger als eine API. Bei unregelmäßigem Verkehr machen ungenutzte GPUs es teurer. Standort. Das Modell läuft dort, wo Sie es brauchen: im eigenen Haus, am Edge oder ganz ohne Internetverbindung. Der Preis ist der Betrieb. Jemand muss Treiber aktualisieren, den Speicher überwachen, Lastspitzen abfangen und nachts auf Alarme reagieren. Und die stärksten Modelle in unseren Daten haben geschlossene Gewichte — für mehr Kontrolle geben Sie unter Umständen etwas Leistung ab.\nGleichmäßiger Verkehr und hoher Kontrollbedarf sprechen für den Eigenbetrieb, unregelmäßiger Verkehr für eine API. Offene Gewichte sind nicht immer Open Source „Offen“ beschreibt die Gewichte, nicht unbedingt Ihre Rechte. Die Open Source Initiative hat im Oktober 2024 ihre Open Source AI Definition 1.0 veröffentlicht. Sie verlangt mehr als die Gewichte: auch den Code und genaue Angaben zu den Trainingsdaten. Viele bekannte Open-Weight-Modelle erfüllen diese Definition nicht. Für Ihr Projekt zählt vor allem die Lizenz — und die Lizenzen unterscheiden sich stark:\nÜbliche Open-Source-Lizenzen wie Apache 2.0 oder MIT erlauben die kommerzielle Nutzung mit wenigen Auflagen. Mistral 7B zum Beispiel erschien unter Apache 2.0, DeepSeek-R1 unter der MIT-Lizenz. Eigene Modell-Lizenzen fügen Bedingungen hinzu. Die Lizenz von Metas Llama 2 etwa verlangte von Unternehmen mit mehr als 700 Millionen monatlich aktiven Nutzern, bei Meta eine gesonderte Lizenz zu beantragen (Quelle: Meta, Llama 2 Community License, 2023). Viele eigene Lizenzen enthalten außerdem Nutzungsrichtlinien (Acceptable Use Policy). Forschungs- oder nichtkommerzielle Lizenzen schließen die kommerzielle Nutzung ganz aus. Bevor ein Modell in Produktion geht, beantworten Sie diese Fragen — gemeinsam mit Ihrer Rechtsabteilung:\nModelle mit offenen Gewichten selbst betreiben Frage Warum sie zählt Ist kommerzielle Nutzung erlaubt? Manche Gewichte sind nur für die Forschung freigegeben Gibt es Schwellen für Nutzerzahlen oder Umsatz? Wachstum kann eine neue Lizenz erfordern Gibt es Nutzungsrichtlinien? Sie verbieten bestimmte Einsätze und können sich ändern Gibt es Regeln für Nennung oder Namen? Ihr Produkt braucht vielleicht einen Hinweis oder eine Namensregel Dürfen Sie feingetunte Fassungen weitergeben? Abgeleitete Modelle können unter dieselbe Lizenz fallen Dürfen Ausgaben andere Modelle trainieren? Wichtig, wenn Sie Destillation planen Prüfen Sie die Lizenz jeder Version: Die Bedingungen können sich von einer Modellgeneration zur nächsten ändern.\nServing-Software: von den Gewichten zum Endpunkt Gewichte sind nur große Dateien. Um sie bereitzustellen, brauchen Sie einen Stapel Software zwischen GPU und Ihren Apps:\nDer Stack für den Eigenbetrieb: Die Inferenz-Engine entscheidet, wie viele Anfragen eine GPU bedienen kann. Herzstück ist die Inferenz-Engine. Bekannte Open-Source-Lösungen sind vLLM, SGLang und TensorRT-LLM von NVIDIA für GPU-Server sowie llama.cpp oder Ollama für Laptops und kleine Server. Mehrere davon bieten eine OpenAI-kompatible API, sodass das Gateway aus Teil 1 Ihr eigenes Modell wie jeden anderen Anbieter ansteuern kann. Gute Engines stützen sich auf einige Techniken; die ersten beiden kamen in Level 3 schon kurz vor:\nContinuous Batching: Neue Anfragen steigen bei jedem Generierungsschritt in den laufenden Stapel ein, statt zu warten, bis der ganze Stapel fertig ist. Die Idee stammt aus dem Orca-Paper (Yu et al., OSDI 2022). Seitenweiser KV-Cache: Die Engine verwaltet den Speicher für den KV-Cache in kleinen Seiten, wie den virtuellen Speicher eines Betriebssystems. Das spart Verschnitt und bringt mehr parallele Anfragen auf eine GPU (Kwon et al., „PagedAttention“, SOSP 2023, das Paper hinter vLLM). Präfix-Caching: Anfragen, die mit demselben Systemprompt beginnen, nutzen die dafür bereits geleistete Arbeit erneut. Tensor-Parallelismus: Ein Modell wird auf mehrere GPUs verteilt, wenn es nicht auf eine passt. Spekulatives Decoding: Ein kleines Entwurfsmodell schlägt mehrere Tokens vor, das große Modell prüft sie in einem Schritt (Leviathan et al., ICML 2023). Behandeln Sie Modelldateien wie fremden Code. Bevorzugen Sie das Format safetensors: Es speichert nur Tensoren und einen kleinen Kopfbereich und kann beim Laden keinen Code ausführen, anders als ältere Pickle-Dateien von Python. Legen Sie die genaue Revision fest, und prüfen Sie Prüfsummen vor dem Deployment.\nGPU-Speicher planen: Gewichte plus KV-Cache Level 3 hat Ihnen die Faustregel für die Gewichte gegeben: Parameter × Bytes je Parameter. Im Betrieb entscheidet der KV-Cache, wie viele Nutzer eine GPU bedienen kann. Die Engine führt ihn für jede laufende Anfrage, und er wächst mit jedem Token:\nKV-Cache je Token = 2 × Schichten × KV-Köpfe × Kopfgröße × Bytes je Wert\nNehmen Sie ein Beispielmodell mit 8 Milliarden Parametern, 32 Schichten und 8 Key-Value-Köpfen der Größe 128 in 16-Bit-Genauigkeit: 2 × 32 × 8 × 128 × 2 Byte ≈ 0,13 MB je Token. Eine Anfrage mit 8.192 Tokens Kontext braucht damit etwa 1,1 GB. Zweiunddreißig solcher Anfragen gleichzeitig brauchen etwa 34 GB — rund doppelt so viel wie die Gewichte.\nBeispielrechnung: Bei vielen parallelen Anfragen braucht der KV-Cache mehr Speicher als die Gewichte. Näherung, keine Messung. Drei Hebel senken den Speicherbedarf:\nQuantisierung speichert Gewichte mit weniger Bits. Verbreitete Verfahren sind GPTQ (Frantar et al., 2022) und AWQ (Lin et al., 2023) sowie das GGUF-Format von llama.cpp. Manche Engines können auch den KV-Cache in 8 Bit halten. Prüfen Sie die Qualität immer mit Ihrem eigenen Eval-Satz. Grouped-Query Attention (Ainslie et al., 2023) lässt mehrere Attention-Köpfe sich Key-Value-Köpfe teilen und verkleinert so den Cache. Sie ist Teil der Modellarchitektur — ein Blick in die Model Card verrät, ob ein Modell sie nutzt. Kürzere Kontexte helfen direkt: Eine Grenze für die Gesprächslänge ist zugleich eine Speichergrenze. Mixture-of-Experts-Modelle (MoE) brauchen besondere Sorgfalt. DeepSeek-V3 zum Beispiel hat insgesamt 671 Milliarden Parameter, aktiv sind je Token aber nur 37 Milliarden (Quelle: DeepSeek-V3 Technical Report, 2024). Der Speicher muss alle aufnehmen, der Rechenaufwand je Token liegt dagegen näher an dem eines deutlich kleineren Modells.\nMessen Sie dann: Zeit bis zum ersten Token, Tokens pro Sekunde je GPU und wie viele parallele Anfragen laufen, bevor Ihre Latenzziele reißen. Ein Lasttest mit echten Prompts beantwortet diese Fragen besser als jede Formel.\nDer Abstand zur Spitze: was unsere Daten zeigen Unsere LLM-Datenbank führt 172 Modelle mit offenen und 160 mit geschlossenen Gewichten. Das Diagramm vergleicht den besten Gesamtindex (ECI), den jede Gruppe zu jedem Zeitpunkt erreicht hatte:\nBisher bester ECI offener und geschlossener Modelle. Daten: Epoch AI, CC BY 4.0. Beide Linien steigen, und die offene folgt der geschlossenen. Der Pfeil zeigt, wie viele Monate früher ein geschlossenes Modell erstmals das Niveau des heute besten offenen Modells erreicht hatte; zu anderen Zeitpunkten gemessen, schwankt dieser Abstand. Das sind einige der stärksten Modelle mit offenen Gewichten in unseren Daten:\nModelle aus unserer LLM-Datenbank ModellErschienenGewichteECIRang Kimi K3 Moonshot16.07.2026offen157,417 DeepSeek V4.1 Flash DeepSeek09.09.2026offen155,631 DeepSeek V4 Pro 0813 DeepSeek13.08.2026offen155,332 GLM-5.3-Flash Z.ai (Zhipu AI)20.08.2026offen153,245 Qwen 3.8 27B Alibaba14.08.2026offen151,652 ECI = Epoch Capabilities Index, ein Gesamtwert über viele Benchmarks; Rang unter allen Modellen mit ECI. Daten: Epoch AI, abgerufen am 17.10.2026, Lizenz CC BY 4.0. Alle Modelle: LLM-Datenbank.\nLesen Sie den Index mit zwei Einschränkungen. Der ECI misst breite Fähigkeiten über viele Benchmarks; für eine enge Aufgabe wie Klassifizierung oder Extraktion aus Ihren eigenen Dokumenten kann ein kleineres offenes Modell völlig ausreichen. Und die größten offenen Modelle brauchen Server mit mehreren GPUs — prüfen Sie die Größe, bevor Sie Hardware planen. Alle Modelle und Filter finden Sie in unserer LLM-Datenbank.\nCheckliste für den Betrieb Ein Modell zu betreiben ist ein Dienst, kein Download. Planen Sie diese Punkte, bevor die erste Nutzerin kommt:\nModelle mit offenen Gewichten selbst betreiben (2) Bereich Was Sie einrichten Zugang Kein direkter Zugriff auf den Inferenz-Server; aller Verkehr über das Gateway; kein Internetzugang nach außen Versionen Eine festgelegte Modellrevision; neue Versionen erst nach bestandenen Evals Skalierung Autoscaling nach Länge der Warteschlange; Reserve, denn ein großes Modell zu laden dauert Minuten Monitoring Zeit bis zum ersten Token, Tokens pro Sekunde, Wartezeit, GPU-Speicher, Speicherüberläufe Sicherheit Eigene Eingangs- und Ausgabefilter — eine Schutzschicht des Anbieters gibt es nicht Fallback Ein API-Modell als Überlauf, wenn Ihre GPUs ausgelastet sind Kosten Kosten je Million Tokens = GPU-Kosten pro Stunde ÷ Millionen Tokens pro Stunde, bei echter Auslastung Vergleichen Sie die Kostenzeile jeden Monat mit derselben Arbeit über eine API; Teil 5 dieses Levels zeigt weitere Wege, Kosten und Latenz zu optimieren. Infrastruktur für diesen Aufbau finden Sie in unserem Vergleich. Nach Angaben der Anbieter ist Runpod eine GPU-Cloud für Training und Betrieb von Modellen mit Abrechnung nach Verbrauch. Plesk ist ein Kontrollpanel für die Server, auf denen die App rund um das Modell läuft. Pinecone ist eine Vektordatenbank für den Fall, dass Ihr Modell aus Ihren Dokumenten antwortet:\nRunpodInfrastruktur \u0026amp; Hosting · KI ist der KernGPU-Cloud zum Trainieren und Betreiben von KI-Modellen, abgerechnet nach Nutzung. PleskInfrastruktur \u0026amp; Hosting · Software mit KI-FunktionenHosting-Kontrollpanel für Websites, WordPress, E-Mail, DNS und Datenbanken. PineconeInfrastruktur \u0026amp; Hosting · KI ist der KernVektordatenbank für KI-Anwendungen, etwa für Suche und Retrieval. Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.\nFangen Sie klein an: ein Modell, eine Aufgabe, eine GPU, mit einer API als Fallback. Verlagern Sie mehr Verkehr auf eigene Hardware erst, wenn Ihre Evals und der monatliche Kostenvergleich beide dafür sprechen.\n","words":1641},"date":"2026-10-14","description":"Wann sich eigene Open-Weight-LLMs lohnen: Lizenzen, Serving-Software, GPU-Speicher, Betrieb und der Abstand zu geschlossenen Modellen in unseren Daten.","image":"https://abxk.ai/images/cover/self-host-open-weight-models.webp","json":"https://abxk.ai/de/ai-development/learn/self-host-open-weight-models/index.json","kind":"page","language":"de","learning_path":{"category":"ai-development","level":4,"level_name":"Experte"},"modified":"2026-10-14","related_tools":["Runpod","Plesk","Pinecone"],"section":"ai-development","tags":["open-weight-modelle","eigenbetrieb","inferenz","quantisierung","experte"],"title":"Modelle mit offenen Gewichten selbst betreiben","translations":[{"json":"https://abxk.ai/en/ai-development/learn/self-host-open-weight-models/index.json","language":"en","url":"https://abxk.ai/en/ai-development/learn/self-host-open-weight-models/"}],"url":"https://abxk.ai/de/ai-development/learn/self-host-open-weight-models/"}