Die Open-weight-AI-Debatte lässt sich nicht mehr sinnvoll als “offen gegen geschlossen” führen. Für Unternehmen zählt eine praktischere Frage: Welche Workloads gehören zu geschlossenen APIs, welche zu Open-weight-Modellen, wann reicht managed inference und wann lohnt self-hosting?

Entscheidungsbaum für Open-weight-AI, managed inference, Self-hosting und Closed APIs

Am 27. Juli veröffentlichte Dario Amodei Anthropics Position, nachdem dem Unternehmen unterstellt wurde, es wolle Open-weight-Modelle verbieten. Der Hacker-News-Thread wurde riesig; Firebase zeigte 914 Punkte und 1.332 Kommentare. Dazu kamen Kimi K3, Briefe von Startups und großen Tech-Unternehmen gegen breite Beschränkungen sowie Entwicklerberichte über praktisch nutzbare offene Modelle.

Anthropics Position ist enger als die Social-Media-Version. Amodei schrieb, Anthropic habe nie ein Verbot von open-weights models gefordert. Modelle ohne gefährliche Fähigkeiten seien ein public good. Die Sorgen betreffen mächtige Modelle in autoritären Staaten, Cyber- oder Bio-Missbrauch, Alignment-Probleme, industrielle Distillation und Gewichte, die nach Veröffentlichung nicht zurückgeholt werden können.

Builders verteidigen open weights aus praktischen Gründen: Kosten, Kontrolle, Latenz, Anpassung und weniger Abhängigkeit von einem API-Anbieter. Ein managed open-weight endpoint kann billiger sein. Ein self-hosted model kann Daten in der eigenen Umgebung halten. Ein kleines fine-tuned model kann in einem engen Workflow besser sein als eine Frontier-API.

Kostenlos ist das nicht. Open weights verlagern Arbeit in MLOps: GPUs, Serving, Quantisierung, Logging, Evaluation, Patches, Zugriffskontrolle, Provenance und Fallback. Die Rechnung wandert von API usage zu Infrastruktur und Engineering-Zeit.

Geschlossene APIs passen weiter für breites Reasoning, allgemeine Assistenten, kleine Experimente und regulierte Workflows mit wichtigen Vendor-Kontrollen. Managed open-weight inference passt zu kostensensiblen Produkten und Portabilität. Self-hosting braucht starke Gründe wie data residency, latency, privacy oder TCO.

Governance beginnt mit provenance und license. Danach kommen interne Evals: Qualität, hallucinations, refusal behavior, Latenz, Kosten und Fehlerfälle. Ebenso wichtig: Welche Daten darf das Modell sehen, wo läuft inference, wer liest Logs und wie lange bleiben sie erhalten?

Die sinnvolle Antwort ist weder reflexhaftes Verbot noch blinde Zustimmung. Open-weight AI ist procurement, Architektur und Betrieb. Die Entscheidung fällt workload für workload.