AIREITERSechs Modelle von 0.9B bis 375B klingen zunächst nach einer lückenlosen Auswahl für jede Deployment-Stufe. Wirtschaftlich ist das Bild weniger einfach. Die Apache-2.0-Lizenz von K2 Horizon spart zwar Modell-Lizenzgebühren, und MoVA reduziert die aktive Rechenarbeit – Kosten für Speicher, KV-Cache, Runtime und Hardware bleiben jedoch bestehen.
Was das Apache-2.0-Release mit sechs Modellen umfasst
IFM stellte K2 Horizon am 3. September 2026 als zusammenhängende Modellfamilie mit sechs Varianten vor: 375B-A23B, 36B-A4B, 32B, 7B, 3.7B und 0.9B. Modelle und Code stehen laut Ankündigung unter Apache 2.0; für die Datensätze gelten jeweils die zugehörigen Lizenzen (IFM announcement).
Eine Modellfamilie, aber nicht überall derselbe Reifegrad
Zur Familie gehören diese sechs Modelle:
| Modell | Architektur | Offizielle Positionierung | In offiziellen Unterlagen genannter Kontext |
|---|---|---|---|
| K2 Horizon 0.9B | Dense | Uhren, Brillen, stark eingeschränkte Edge-Geräte | 128K / 131,072 Token |
| K2 Horizon 3.7B | Dense | Smartphones, Fine-Tuning, schlanke lokale Aufgaben | 512K / 524,288 Token |
| K2 Horizon 7B | Dense | Smartphones, lokale Assistenten, Coding und Agenten | 512K / 524,288 Token |
| K2 Horizon 32B | Dense | Workstations und On-Premises-Server | 512K / 524,288 Token |
| K2 Horizon MoVA 36B-A4B | Sparse MoE + MoVA | Lokales und effizientes Serving | 512K / 524,288 Token |
| K2 Horizon 375B-A23B | Sparse MoE | Enterprise- und Multi-Accelerator-Deployments | 512K / 524,288 Token |
Mit Ausnahme des 0.9B-Modells, das ein kleineres Vokabular verwendet, teilen die Modelle Architektur und Deployment-Tooling. Diese gemeinsame Basis soll Migrationen oder Routing zwischen den Größen vereinfachen (IFM press release).
Beim Reifegrad gibt es allerdings eine wichtige Einschränkung: Die offizielle Karte für K2-Horizon-32B bezeichnet den sichtbaren Checkpoint als Stage1 und kündigt den finalen Checkpoint noch an. Die Karten für MoVA 36B-A4B und 375B-A23B beschreiben ihre finalen Checkpoints dagegen als veröffentlicht. „Sechs angekündigte Modelle“ ist also korrekt, „sechs gleichermaßen finale Produktions-Checkpoints“ jedoch nicht (32B model card, 375B model card).
Was Apache 2.0 einem Self-Hosting-Team tatsächlich bringt
Apache 2.0 erlaubt Teams, das Modell und seinen Code zu verändern, weiterzugeben und kommerziell zu integrieren, ohne Gebühren pro Token zu zahlen. IFM weist darauf hin, dass Datensätze eigenen Bedingungen wie ODC-BY unterliegen und eingeschränkte Quellen nicht direkt weiterverbreitet werden dürfen (IFM announcement).
Die Lizenz beseitigt Lizenzkosten, nicht die Betriebskosten. GPU-Miete oder Abschreibung, Modellspeicher, KV-Cache-Kapazität, Runtime-Engineering, Monitoring und Sicherheitsprüfungen kosten weiterhin Geld. Sowohl das 36B serving recipe als auch die 375B model card verwenden in ihren Beispielen zudem trust_remote_code=True.
Die sechs Größen: Speicher zuerst kalkulieren
Parameterzahlen helfen beim Kapazitätsvergleich, doch für Self-Hosting ist zunächst der Platz für die Rohgewichte entscheidend. Die folgenden Schätzungen rechnen für BF16 mit zwei Byte pro Parameter und für eine idealisierte 4-Bit-Repräsentation mit einem halben Byte. Metadaten, Runtime-Puffer, KV-Cache, Tokenizer-Dateien und Betriebssystemspeicher sind nicht enthalten.
| Modell | Für die Planung verwendete Gesamtparameter | Aktive Parameter pro Token | BF16-Untergrenze für die Planung | Idealisiertes 4-Bit-Minimum | Praktische Klasse |
|---|---|---|---|---|---|
| K2 Horizon 0.9B | 0.9B | 0.9B | ~1.8 GB | ~0.45 GB | Edge- und Embedded-Experimente |
| K2 Horizon 3.7B | 3.7B | 3.7B | ~7.4 GB | ~1.85 GB | Kompakte lokale oder mobile Nutzung |
| K2 Horizon 7B | 7B-Klasse | 7B-Klasse | ~14 GB* | ~3.5 GB* | Erster ernsthafter lokaler Test |
| K2 Horizon 32B | 32B | 32B | ~64 GB | ~16 GB | Workstation oder Server |
| K2 Horizon MoVA 36B-A4B | 36B | ~4B | ~72 GB | ~18 GB | Quantisierte Workstation oder Multi-GPU-Serving |
| K2 Horizon 375B-A23B | 375B | ~23B | ~750 GB | ~187.5 GB | Enterprise- oder Cluster-Größe |
\*Die 7B-Modellkarte nennt das Modell „7B-core“, während die Hugging-Face-Metadaten 9B Parameter anzeigen. Für die Kapazitätsplanung sollten die tatsächlichen Repository-Dateien zählen, nicht nur das Familienlabel (7B model card).
Die konkreten Repositories zeigen, weshalb diese Werte nur Untergrenzen und keine Zusagen sind. Das 0.9B-BF16-GGUF wird mit 2.16 GB aufgeführt, das 3.7B-BF16-GGUF mit 10.1 GB, das 32B-Stage1-BF16-GGUF mit 69.6 GB und das MoVA-36B-BF16-GGUF mit 74.9 GB (0.9B GGUF, 3.7B GGUF, 32B GGUF, 36B GGUF).
Für Edge-Geräte und kleine lokale Setups: 0.9B, 3.7B und 7B
0.9B und 3.7B halten den Speicherbedarf niedrig und passen zu fokussierten Aufgaben auf begrenzter Hardware – weniger zu Agenten, die sich häufig aus Fehlern herausarbeiten müssen (0.9B model card, 3.7B GGUF card).
Als erster lokaler Versuch ist das 7B innerhalb der Familie am ausführlichsten dokumentiert: Die Karte behandelt Reasoning- und Tool-Call-Parser, eine Tensor-Parallel-Konfiguration für ein einzelnes Gerät sowie quantisierte Varianten. Die angezeigte Benchmark-Tabelle nennt 70.6% auf SWE-bench Verified, 39.1% auf Terminal-Bench 2.1 und 25.8% auf tau3-Banking. Alle ausgewiesenen Ergebnisse wurden allerdings mit hohem Reasoning-Aufwand erzielt; außerdem warnt die Karte, dass sich Protokolldetails unterscheiden können (7B model card).
Die 7B-Karte empfiehlt hohen Reasoning-Aufwand und mindestens 32,768 Output-Token. Längeres Reasoning erhöht die Generierungszeit und kann ein Modell, das zwar in den Speicher passt, in Echtzeit trotzdem teuer machen.
Für Workstation und Server: 32B und 36B-A4B
Das 32B ist vollständig dense und damit einfacher einzuordnen. In der Planung zählen jedoch vor allem sein Stage1-Status und das offizielle GGUF mit 69.6 GB (32B Stage1 GGUF).
Das MoVA 36B-A4B stellt eine andere Frage: Kann ein Modell mit deutlich weniger aktiver Rechenarbeit an die Fähigkeiten dichter Modelle herankommen und gleichzeitig eine größere Gesamtkapazität behalten? Die Benchmark-Tabelle des IFM-GGUF nennt 26.8% auf tau3-Banking und 58.6% auf Terminal-Bench 2.1, womit es das dort aufgeführte Vergleichsfeld anführt. Bei allen Wissenschafts-, Faktizitäts- oder Long-Context-Messungen liegt es allerdings nicht vorn (36B GGUF benchmark card).
Sobald die Gewichte im Speicher liegen, kann die geringere Zahl aktiver Parameter den dauerhaften Durchsatz verbessern. Das Ergebnis hängt jedoch von Backend, Batching, Interconnect und Quantisierung ab.
Das Flaggschiff: 375B-A23B
Die offizielle Modellkarte dokumentiert für K2 Horizon 375B-A23B eine validierte SGLang-Konfiguration mit acht H200 GPUs, Tensor Parallelism von 8, Expert Parallelism von 8, BF16 und FlashAttention-3 (375B model card).
Das Verhältnis von Gesamt- zu aktiven Parametern kann den Rechenaufwand gegenüber einem dichten 375B-Modell reduzieren. Die ungefähre BF16-Untergrenze von 750GB bleibt aber die entscheidende Infrastrukturgrenze. Artificial Analysis führt einen Intelligence-Index-Wert von 47 sowie Platz #11 von 112 in der angezeigten Klasse auf, nennt für das Modell jedoch weder eine Output-Geschwindigkeit noch Kosten pro Aufgabe (Artificial Analysis profile).
Auf Basis des derzeit dokumentierten und validierten Acht-H200-Profils gehört dieses Modell in ein Cluster-Deployment.
MoVA spart Rechenarbeit, nicht den Speicher für die Gewichte
MoVA steht für Mixture-of-Value Attention. Herkömmliche Mixture-of-Experts-Architekturen nutzen sparsames Routing meist in Feed-Forward-Layern. IFM beschreibt MoVA als Erweiterung dieses Expert-Routings auf die Value-Komponente der Attention; die Technik bleibt dabei mit Verfahren wie FlashAttention und Grouped-Query Attention kompatibel (IFM architecture explanation).
Was die Bezeichnung 36B-A4B aussagt
„36B-A4B“ nennt zwei verschiedene Größen: Rund 36B Gesamtparameter stehen bereit, während pro Token rund 4B Parameter aktiv sind. Das kann Multiply-and-Accumulate-Arbeit und Speicherverkehr auf dem aktiven Pfad reduzieren – insbesondere bei Workloads mit anhaltender Generierung.
Unbenutzte Experten verschwinden dadurch nicht aus dem Speicher. Das offizielle GGUF ist in BF16 74.9 GB groß. Das vLLM-Rezept beschreibt ein Modell mit 37.44B gespeicherten Parametern einschließlich Embeddings und 5.95B aktiven Parametern pro Token. Das sind unterschiedliche Paketierungs- und Zählweisen derselben Architektur, kein Hinweis auf ein separates 37B-Modell (vLLM recipe).
Als Denkmodell hilft:
- Vorhaltekapazität: Speicher und RAM müssen sämtliche Gewichte aufnehmen, die ausgewählt werden können.
- Aktive Rechenlast: Pro Token wird nur ein gerouteter Teil davon verwendet.
- Runtime-Zustand: KV-Cache, temporäre Puffer, Batching und Framework-Overhead bleiben erhalten.
- Systemkosten: Interconnect, Strom, Host-RAM und Betriebszeit bestimmen die Rechnung.
Warum 512K Kontext keine Ressourcenplanung ersetzt
Die K2-Horizon-Karten werben für die größeren Modelle mit einem nativen Kontext von 524,288 Token. Die veröffentlichten vLLM-Rezepte für MoVA 36B-A4B und 375B-A23B setzen jedoch --max-model-len 131072 – also ein Viertel des beworbenen Maximums (36B vLLM recipe, 375B model card).
Die 131K-Rezepte machen deutlich: Ein nativer 512K-Kontext ist kein kostenloser Serving-Standard. Längere Kontexte beanspruchen KV-Cache, senken die Parallelität und erhöhen die Prompt-Latenz.
Self-Hosting-Szenarien mit Kostenbezug
Für K2 Horizon gibt es keinen transparenten, universellen API-Preis als Vergleichsbasis. Die offizielle MoVA-GGUF-Seite erklärt, dass aktuell kein Inference-Provider das Modell anbietet. Artificial Analysis zeigt für das 375B-Profil zwar $0.00 für Input und Output an, markiert Geschwindigkeit und Kosten pro Aufgabe aber als nicht verfügbar. Das ist kein Beleg für einen kostenlosen Produktionseinsatzpunkt (MoVA GGUF card, Artificial Analysis).
| Szenario | Was es ermöglicht | Größtes wirtschaftliches Risiko | Fazit |
|---|---|---|---|
| GPU der 24GB-Klasse mit passender 4-Bit-36B-Quantisierung | Preiswerte Experimente und Datenschutz | Wenig Reserve für Kontext und Parallelität; Quantisierung und Runtime-Support könnten unausgereift sein | Gut für einen Pilotversuch, nicht als garantiertes Produktionsziel |
| 32B-BF16- oder 36B-BF16-Workstation | Höhere Genauigkeit und einfachere Qualitätsvergleiche | 64–75GB Gewichte vor Cache und Runtime-Speicher | Meist Multi-GPU- oder High-Memory-System |
| 36B-Serving im Stil von zwei H200 | Entspricht dem dokumentierten MoVA-Serving-Profil | Miete, Host, Speicher und Auslastungskosten | Sinnvoll für dauerhaften Service oder kontrollierte Evaluierung |
| 375B-Serving mit acht H200 | Flaggschiff-Kapazität und Enterprise-Durchsatz | Hohe Kapitalbindung oder hohe stündliche Infrastrukturkosten | Nur im Cluster-Maßstab |
Experiment auf einer GPU der 24GB-Klasse
Die idealisierte 4-Bit-Untergrenze für ein 36B-Modell liegt bei rund 18GB. Auf einer 24GB-Karte bleiben damit weniger als 6GB für Quantisierungsmetadaten, Runtime-Puffer und KV-Cache. Diese Rechnung macht einen Test auf Hardware der 24GB-Klasse bei moderatem Kontext plausibel, definiert aber kein allgemeingültiges Minimum: Erst Quantisierung, Backend, Offload-Strategie und Prompt-Länge entscheiden, ob der Lauf brauchbar ist.
Das zitierte offizielle MoVA-GGUF liegt in BF16 vor, nicht als kleine Consumer-Quantisierung. Die Hugging-Face-Collection führt GGUF- und FP8-Varianten über die Familie hinweg auf, doch Konvertierung und Kompatibilitätsarbeit am Release-Tag gehören weiterhin ins Deployment-Budget (K2 Horizon collection).
“I assume they are still uploading other GGUFs--all I see is a BF16 GGUF so far” — u/apoptosist in r/LocalLLaMA.
Zwei H200 für den dokumentierten 36B-Pfad
IFMs MoVA-vLLM-Rezept nutzt Tensor Parallelism von 2, Expert Parallelism, BF16 und ein Serving-Limit von 131,072 Token. In der SGLang-Dokumentation ist die Konfiguration auf 2× H200 validiert. Das ist ein deutlich aussagekräftigeres Hardware-Signal als der Modellname allein (vLLM recipe, official GGUF card).
Die veröffentlichten Provider-Preise zeigen, warum Auslastung zählt. DigitalOcean listet eine dedizierte NVIDIA H200 mit $4.47 pro GPU-Stunde und eine 8×-H200-Konfiguration mit $35.78 pro Stunde. Google Cloud führt eine A3-Ultra-Maschine mit 8× H200 für $84.806908493 pro Stunde auf; angeschlossene vCPUs, Arbeitsspeicher und SSD sind dort im Preis des Maschinentyps enthalten (DigitalOcean pricing, Google Cloud pricing).
Zum angegebenen Preis pro GPU ergeben zwei H200 rund $8.94 pro Stunde beziehungsweise $6,526 pro Monat mit 730 Stunden, noch ohne Host- und Speicherkosten. Das dient nur als auslastungsabhängiger Referenzwert, nicht als Angebot für zwei GPUs.
Acht H200 für 375B-A23B
Das offizielle Serving-Rezept des Flaggschiffs setzt acht H200, TP=8, EP=8 und BF16 ein. Diese Konfiguration passt zur ungefähren BF16-Untergrenze von 750GB für die Rohgewichte und zieht die Enterprise-Grenze klar (375B model card).
Googles gelisteter Preis von $84.81 pro Stunde für eine 8×-H200-Maschine ergibt für 730 Stunden rund $61,909, vor Steuern, Datentransfer, persistentem Speicher und Anwendungsbetrieb. Das ist eine Infrastrukturreferenz, kein Preis für K2 Horizon und keine Zusage einer bestimmten Token-pro-Sekunde-Leistung des veröffentlichten Rezepts.
Was frühe Self-Hosting-Erfahrungen belegen – und was nicht
Frühe Berichte zeigen, dass K2 Horizon lauffähig ist. Unterschiedliche Quantisierungen und Runtimes ergeben aber noch keine allgemeingültige Kosten-Leistungs-Kurve.
Ein ausführlicher Bericht auf X veranschaulicht, wie stark das Backend ins Gewicht fallen kann:
“36B-A4B MoVA does 131-142 tok/s on 2x 5090 with llama.cpp (IFM's fork, Q8_0, 131K ctx) vs 52 on vLLM...” — @abtraore_.
Der nützliche, aber unkontrollierte Bericht zeigt, weshalb „MoVA ist schneller“ ohne Backend und Konfiguration keine ausreichende Aussage ist.
Die Reddit-Diskussion verweist auf offene Fragen zu Quantisierung, wenig VRAM, Vergleichen und Tool Calls – nicht auf validierte Performance (r/LocalLLaMA thread).
Für eine ernsthafte Kaufentscheidung fehlen Messungen zum residenten Speicher je Quantisierung, zum Wachstum des KV-Cache je Kontext, zu Prompt- und Generierungsgeschwindigkeit, zur Zuverlässigkeit von Tool Calls, zur Leistungsaufnahme sowie zu Kosten pro erfolgreich gelöster Aufgabe unter einer kontrollierten Arbeitslast.
Nach Auslastung entscheiden, nicht nach Active-Parameter-Marketing
Welches K2-Horizon-Modell passt, hängt davon ab, wie oft es läuft, wie viel Kontext es benötigt und ob seine Ausgabequalität die Infrastruktur rechtfertigt. Ein kurzer Pilot sollte möglichst leicht rückgängig zu machen sein; ein dauerhaft laufender privater Dienst sollte auf Auslastung und Betriebsstabilität optimiert werden.
| Ihr Workload | Starten mit | Warum | Stoppen oder aufrüsten, wenn |
|---|---|---|---|
| Wearable, Embedded-System oder eng abgegrenzte Klassifizierungsaufgabe | 0.9B | Kleinster Footprint und 128K-Kontextangabe | Tool-Tiefe oder Domain-Abdeckung zum Engpass wird |
| Kompakter lokaler Assistent oder Fine-Tuning-Experiment | 3.7B | Geringe Speicherlast bei breiterem Reasoning als 0.9B | Coding- und Recovery-Fehler überwiegen |
| Erster ernsthafter lokaler Coding-/Agenten-Pilot | 7B | Dokumentiert Parser, Tensor Parallelism und quantisierte Varianten | Lange Aufgaben verlässlichere Planung oder Tool-Nutzung benötigen |
| Leistungsfähige Workstation mit dichtem Baseline-Modell | 32B Stage1, vorsichtig | Dense-Verhalten lässt sich leichter vergleichen, der aktuelle Checkpoint ist aber nicht final | Finaler Checkpoint und gemessene Ergebnisse den Speicherbedarf rechtfertigen |
| Wiederholte lokale/Server-Inferenz, bei der aktive Rechenlast zählt | MoVA 36B-A4B | Weniger aktive Parameter und ein dokumentierter TP=2/EP-Pfad | Kontext, Parallelität oder Runtime-Reibung den Effizienzgewinn aufzehren |
| Enterprise-Reasoning und Agenten mit langem Horizont | 375B-A23B | Kapazitätsstärkstes Familienmitglied und dokumentierter 8×-H200-Pfad | Kosten pro Aufgabe oder Auslastung den Business Case nicht tragen |
Notieren Sie vor einem Modellwechsel für den ersten Pilotversuch fünf Werte: Spitzenwert bei VRAM/RAM, Prompt-Länge, Zeit bis zum ersten Token, generierte Token pro Sekunde und Kosten pro abgeschlossener Aufgabe. Belassen Sie das Kontextlimit bei den dokumentierten 131,072 Token, bis der Workload belegt, dass mehr Kontext den zusätzlichen Cache- und Latenzaufwand wert ist.
Wer wissen möchte, welches Familienmitglied auf eine bestimmte Maschine passt, findet im separaten K2 Horizon model sizing guide die engere Auswahlhilfe. Diese Seite priorisiert dagegen Auslastung und gemessene Kosten pro Aufgabe gegenüber Labels für aktive Parameter.
K2 Horizon-Modelle: FAQ
Bedeutet Apache 2.0, dass jeder K2-Horizon-Datensatz unter Apache 2.0 steht?
Nein. Laut IFM stehen Modelle und Code unter Apache 2.0, während für Datensätze die jeweils geltenden Lizenzen wie ODC-BY maßgeblich sind. Prüfen Sie jedes Repository und jeden Datensatz, bevor Sie Inhalte weitergeben oder kommerziell für Training einsetzen (IFM announcement).
Bedeutet 4B aktiv, dass K2 Horizon MoVA 36B-A4B so viel Speicher wie ein 4B-Modell benötigt?
Nein. Pro Token aktiviert das Modell rund 4B Parameter, sein offizielles BF16-GGUF ist jedoch etwa 74.9GB groß. Gewichtsspeicher, KV-Cache, Runtime-Puffer, Quantisierungs-Overhead und Parallelität bestimmen den tatsächlichen Speicherbedarf.
Kann eine einzelne 24GB-GPU K2 Horizon MoVA 36B-A4B ausführen?
Eine geeignete 4-Bit-Quantisierung kann ein Experiment mit moderatem Kontext plausibel machen, weil die idealisierte Gewichtsuntergrenze für 36B bei rund 18GB liegt. Das offizielle BF16-Artefakt und der validierte Serving-Pfad mit zwei H200 benötigen deutlich mehr Reserven. Ein Ergebnis auf 24GB-Hardware sollte daher als Pilotkonfiguration gelten, nicht als allgemeine Produktionszusage.
Ist der beworbene 512K-Kontext wirtschaftlich zu serven?
Nicht automatisch. Die Modellkarten nennen einen nativen Kontext von 524,288 Token, während die dokumentierten vLLM-Beispiele 131,072 Token verwenden. Mehr Kontext erhöht den Bedarf an KV-Cache und Latenz und reduziert häufig die Parallelität.
Ist K2 Horizon 375B-A23B ein normales Modell für Self-Hosting?
Nein. IFM dokumentiert eine SGLang-Konfiguration mit acht H200, und die BF16-Untergrenze für die Rohgewichte liegt vor Runtime-Overhead bei rund 750GB. Behandeln Sie es als Enterprise- oder Cluster-Deployment, sofern kein Provider eine kleinere validierte Konfiguration veröffentlicht.
Ist der für K2 Horizon 375B angezeigte Preis von $0.00 tatsächlich eine kostenlose API?
Eine solche Schlussfolgerung ist nicht belegt. Artificial Analysis zeigt zwar $0.00 für Input und Output an, führt Geschwindigkeit und Kosten pro Aufgabe jedoch als nicht verfügbar. Die offizielle Modellseite hat zudem keinen Hugging-Face-Inference-Provider. Prüfen Sie Vertrag und Preisliste eines namentlich genannten Providers, bevor Sie diesen Wert in eine Budgetplanung übernehmen.