Kimi K3 selbst hosten: VRAM, Kosten und Alternativen

Was für das Self-Hosting von Kimi K3 erforderlich ist

Self-Hosting von Kimi K3 bedeutet, Platz für 2.8 Billionen Parameter bereitzustellen. Moonshot hat die Open Weights im Format MXFP4 veröffentlicht. Das entspricht ungefähr einem halben Byte pro Gewicht. Allein die Weights benötigen daher etwa 1.4 TB, bevor Sie auch nur ein einziges Token für den Cache reservieren. Kein heute erhältlicher Accelerator kann diese Datenmenge allein aufnehmen. K3 ist ein Multi-Node-Modell. Auf einem einzelnen Server ist der Betrieb daher nicht möglich.

Das ist das Ergebnis. Im Folgenden wird die zugrunde liegende Berechnung erläutert, denn diese Berechnung können Sie bei der nächsten Version wiederverwenden. Mehrere Infrastruktur-Anbieter veröffentlichten in den Wochen nach der Ankündigung am 17 July 2026 Anleitungen für die Bereitstellung von K3. Jede davon setzte voraus, dass bereits ein Cluster vorhanden ist. Diese Seite geht umgekehrt vor: Welche Kosten entstehen, welche Alternativen Sie betreiben können und woran Sie erkennen, welche dieser beiden Situationen auf Sie zutrifft.

Gesamtparameter und aktive Parameter sind nicht dieselbe Anzahl

K3 ist ein Mixture-of-Experts-Modell. MoE (Mixture of Experts) teilt das Netzwerk in viele Teilnetzwerke auf und lässt einen Router pro Token einige davon auswählen. Im Model-Card sind 2.8T Gesamtparameter und 104B pro Token aktivierte Parameter angegeben. Diese stammen aus 896 gerouteten Experten, von denen für jedes Token 16 aktiviert werden, verteilt auf 93 Layer.

Diese beiden Parameterangaben beantworten unterschiedliche Fragen. Sie zu vertauschen, ist der häufigste Fehler in jedem Thread nach dem Muster „Kann ich das ausführen?“.

Die aktiven Parameter bestimmen den Rechenaufwand. Ein Token wird mit etwa 104B Parametern verarbeitet. Daher ähnelt der erwartete Durchsatz eher dem eines dichten 104B-Modells als dem eines 2.8T-Modells. Genau deshalb werden MoE-Modelle entwickelt.

Die Gesamtparameter bestimmen den Speicherbedarf. Der Router kann für jedes Token einen beliebigen Experten auswählen. Deshalb müssen alle Experten bereits vor dem Eintreffen der ersten Anfrage im Speicher resident sein. Sie können nicht 104B Parameter im VRAM halten und den Rest bei Bedarf nachladen. Das Nachladen müsste innerhalb von Mikrosekunden abgeschlossen sein, während eine PCIe-Verbindung nur einige Dutzend Gigabyte pro Sekunde überträgt. Das wird zwar versucht. Das Streamen von Experten von NVMe-Laufwerken reduziert ein Modell, das eigentlich mehrere Dutzend Token pro Sekunde ausgeben sollte, auf ein Modell, das nur alle paar Sekunden ein Token ausgibt.

Die Berechnung ist also günstig, die Speicherung jedoch teuer. Dimensionieren Sie die Hardware anhand von 2.8T. Richten Sie Ihre Erwartungen an die Geschwindigkeit an 104B aus.

Bytes pro Gewicht und woher die Terabytes kommen

Parameteranzahl multipliziert mit Bytes pro Gewicht. Für die Gewichte ist das die gesamte Formel.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 wurde quantisierungsbewusst trainiert und mit MXFP4-Gewichten sowie MXFP8-Aktivierungen veröffentlicht. Daher ist die Zeile mit 4 Bit die relevante. Die Zeilen darüber dienen als Vergleich: Mit bf16 würde dasselbe Modell 5.6 TB benötigen. MXFP4 speichert außerdem für jeden Block aus 32 Gewichten eine gemeinsame 8-Bit-Skalierung. Das erhöht den Bedarf um etwa 6 Prozent. Das veröffentlichte Repository liegt daher eher bei 1.5 TB als bei den reinen 1.4 TB.

Damit entfällt der übliche Ausweg. „Einfach quantisieren“ hilft hier nicht, weil der veröffentlichte Checkpoint bereits 4 Bit verwendet. Eine Reduzierung auf 2 Bit würde den Speicherbedarf der Gewichte auf 0.7 TB senken. Dafür würde die Genauigkeit sinken, ohne dass dies für diesen Checkpoint jemand gemessen hat. Sie lägen damit weiterhin deutlich über dem Speicher einer einzelnen Karte.

Wie viele GPUs benötigt Kimi K3?

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Betrachten Sie diese Werte als Untergrenze, nicht als Ziel. Sie berücksichtigen nur die Gewichte: keinen KV-Cache, keine Aktivierungspuffer, keine Fragmentierung des Allokators und keinen Spielraum für eine zweite parallele Anfrage. Außerdem wird eine parallele Aufteilung vorausgesetzt, bei der die Anteile gleichmäßig verteilt werden. Das ist bei 93 Layern und 896 Experten nicht immer möglich.

Die veröffentlichten Empfehlungen liegen deutlich über dieser Untergrenze. Im August 2026 empfiehlt Moonshot einen Supernode mit mindestens 64 Beschleunigern. Das SGLang-Cookbook enthält außerdem eine H100-Konfiguration aus vier Knoten mit jeweils 8 GPUs, also 32 GPUs und insgesamt 2,560 GB Speicher. Dem steht eine Untergrenze von 18 Karten gegenüber. Diese Differenz ist keine Verschwendung. Sie wird für den KV-Cache, den Aktivierungsspeicher und den Spielraum benötigt, mit dem der Server viele Anfragen gleichzeitig in Batches verarbeiten kann. Selbst die günstigste Zeile mit 5 GB300-Karten beschreibt eine Maschine, die die meisten Anbieter nicht als einzelne SKU vermieten.

Der KV-Cache ist der Teil, der viele überrascht

Die Gewichte verursachen einen festen Speicherbedarf. Der KV-Cache (Key-Value-Cache) dagegen nicht: Er wächst mit der Kontextlänge und erneut mit jedem gleichzeitig aktiven Benutzer. Für gewöhnliche Attention lautet die Formel bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element. Anschließend multiplizieren Sie mit der Kontextlänge und mit der Anzahl der gleichzeitig aktiven Benutzer.

Hier ist ein durchgerechnetes Beispiel, das nur als Beispiel dient: 64 Layer, 8 KV-Heads, eine Head-Dimension von 128 und fp8. Das ergibt 2 64 8 128 1 = 131,072 Byte, also 128 KiB pro Token.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

Ein Benutzer mit einem Kontext von 128k benötigt 16 GiB. Ein Benutzer mit dem vollständigen Kontext von einer Million benötigt 128 GiB. Das ist mehr, als eine einzelne Karte für eine Unterhaltung aufnehmen kann.

K3 verwendet keine gewöhnliche Attention. Genau deshalb ist die letzte Zahl relevant. Seine 93 Layer bestehen aus 69 KDA-Layern (Kimi Delta Attention) und 24 Gated-MLA-Layern (Multi-Head Latent Attention). KDA verwendet einen rekurrenten Zustand fester Größe anstelle eines Caches, der mit jedem Token wächst. MLA komprimiert Key und Value in einem latenten Vektor mit niedrigem Rang. Dadurch sinkt der tatsächliche Speicherbedarf pro Token deutlich unter den Wert des durchgerechneten Beispiels. Moonshot hat die latenten Dimensionen nicht veröffentlicht. Daher nenne ich für K3 selbst keinen Wert pro Benutzer. Messen Sie den Wert stattdessen selbst: Starten Sie den Server mit einem kleinen --max-model-len, überwachen Sie den Speicher mit nvidia-smi und erhöhen Sie das Limit, bis die Speicherzuweisung fehlschlägt.

Die grundsätzliche Überlegung gilt auch für die nächste Version. Wenn ein Modell einen Kontext von einer Million Tokens angibt und nichts über sein Attention-Design sagt, gehen Sie so lange davon aus, dass der Cache der begrenzende Faktor ist, bis das Gegenteil nachgewiesen wurde.

Stufe 1: Den Cluster stundenweise mieten

Dies ist die einzige Stufe, auf der K3 selbst ausgeführt wird. Sie kaufen die Hardware nicht. Sie mieten sie für die benötigten Stunden und fahren sie anschließend herunter.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

Der Tarif ist eine Annahme und kein Angebot. Die Listenpreise für On-Demand-Beschleuniger in Rechenzentren lagen bis 2026 ungefähr zwischen 2 und 5 USD pro GPU-Stunde. Reservierte Kapazität ist günstiger. Verwenden Sie den tatsächlichen Wert Ihres Anbieters und führen Sie die Multiplikation erneut durch: GPUs mal Stunden mal Tarif. Die Grafik soll das Verhältnis zeigen. Ein 8-GPU-Knoten, der täglich vier Stunden gestartet wird, kostet 2,400 USD pro Monat. Eine dauerhaft laufende Konfiguration mit 32 GPUs für SGLang kostet 57,600 USD.

Beide gängigen Server veröffentlichen auf der Model Card einen Startbefehl.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

Keiner der beiden einfachen Befehle ist für den Betrieb auf einem echten Cluster geeignet. Ergänzen Sie die Parallelismus-Flags, die zu Ihrer Hardware passen: SGLang verwendet --tp-size für Tensor-Parallelismus und --ep-size für Expert-Parallelismus. Das Produkt dieser Werte muss der tatsächlich vorhandenen GPU-Anzahl entsprechen.

Prüfen Sie, ob der Server gestartet ist, bevor Sie echten Datenverkehr senden:

curl http://127.0.0.1:30000/v1/models

Ein gesunder Server antwortet mit einem JSON-Objekt, das die Model-ID enthält. Connection refused bedeutet, dass der Prozess noch Gewichte lädt oder bereits beendet wurde. Lesen Sie daher das Server-Log, bevor Sie den Start wiederholen.

Am ersten Tag tritt häufig ein Problem mit einer älteren Runtime auf. K3 wurde mit KDA und einer neuen MoE-Schicht veröffentlicht, die in den stabilen vLLM- und SGLang-Releases zum Veröffentlichungszeitpunkt noch nicht enthalten war. Das äußert sich darin, dass der Server während des Starts mit einer Zeile der Form Model architectures [...] are not supported for now beendet wird. Keine Konfigurationsänderung behebt das Problem, weil der erforderliche Code zum Ausführen dieser Schichten in Ihrem Build fehlt. Installieren Sie den Nightly-Build, den die Model Card nennt, oder warten Sie auf das Release, das diese Unterstützung enthält.

Ein Kostenpunkt wird häufig übersehen. Die Abrechnung beginnt, sobald die Instanz gestartet wird, nicht erst, wenn das Modell bereit ist. Ein Download von 1.5 TB mit 1 GB/s dauert ungefähr 25 Minuten Clusterzeit, bevor das erste Token erzeugt wird. Speichern Sie die Gewichte auf einem Volume, das die Lebensdauer der Instanz überdauert. Dann startet der zweite Lauf innerhalb weniger Minuten.

Tier 2: Ein kleineres Modell auf einem Accelerator ausführen

In dieser Stufe führen Sie K3 nicht aus. Sagen Sie sich das vor dem Start ausdrücklich, weil die meisten Diskussionen über „K3 lokal ausführen“ hier enden, ohne es zuzugeben.

Die Größenregel ist dieselbe Formel in kleinerem Maßstab: Die Anzahl der Parameter multipliziert mit den Bytes pro Gewicht, plus KV-Cache, plus etwa 2 GB Laufzeit-Overhead, muss in den VRAM passen. Bei 4-bit sind das ungefähr ein halbes Byte pro Parameter. Daraus ergeben sich komfortable Kombinationen:

• 16 GB-Karte: ein 7B-Modell mit 4-bit und genügend Platz für einen langen Kontext
• 24 GB-Karte: ein 14B-Modell mit 4-bit
• 48 GB-Karte: ein 32B-Modell mit 4-bit
• 80 GB-Karte: ein 70B-Modell mit 4-bit oder ein MoE-Modell der 30B-Klasse mit 8-bit

Jede der oben genannten Kombinationen setzt eine Anfrage gleichzeitig voraus. Sobald eine zweite Person eine Eingabe sendet, benötigt jeder parallele Slot einen eigenen KV-Cache. Ollamas Einstellungen NUM_PARALLEL und MAX_QUEUE bilden für Sie den Kompromiss zwischen parallelen Slots, Warteschlangen für Anfragen und dem verbleibenden VRAM.

Ollama ist der kürzeste Weg zu einem funktionierenden Server auf einem VPS mit angeschlossener GPU:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run lädt das Modell bei der ersten Verwendung herunter und zeigt anschließend eine Eingabeaufforderung an. Ein nicht vorhandener Tag gibt Error: model "..." not found zurück. Übernehmen Sie die Tags daher von der Bibliotheksseite, statt sie aus dem Gedächtnis einzugeben. Die vollständige Anleitung einschließlich der systemd-Unit und des Fernzugriffs finden Sie unter Ollama auf einem VPS ausführen.

llama.cpp bietet Ihnen mehr Kontrolle über Quantisierung und Offloading:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 fordert an, jede Schicht auf der GPU auszuführen. Prüfen Sie das Ladeprotokoll. Es gibt aus, wie viele Schichten ausgelagert wurden. Schichten, die in den Systemspeicher überlaufen, laufen mit der Bandbreite des RAM statt mit der Bandbreite des HBM. Sobald das Modell nicht mehr vollständig hineinpasst, sinkt die Generierungsgeschwindigkeit daher um eine Größenordnung. Die Unterschiede zwischen den beiden Tools werden in Ollama und llama.cpp im direkten Vergleich behandelt.

Tier 3: Gehostete API, Self-Hosting der Orchestrierung

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

Der Endpunkt ist mit OpenAI kompatibel. Ein vorhandener Client funktioniert, sobald Sie die Basis-URL ändern.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Ein gültiger Schlüssel liefert ein JSON-Objekt mit einem choices-Array. Ein 401 bedeutet, dass der Schlüssel falsch ist oder der Präfix Bearer fehlt. Ein Fehler wegen eines nicht gefundenen Modells bedeutet meist, dass sich die ID geändert hat, weil Anbieter IDs zwischen Checkpoints ausmustern.

Nun zum Break-even-Punkt mit dem oben angenommenen Mietpreis. Ein dauerhaft aktiver Knoten mit 8 GPUs kostet 14,400 USD pro Monat. Bei 15.00 USD pro 1 Million Ausgabetokens kauft derselbe Betrag ungefähr 960 Millionen Ausgabetokens über die API. Damit sich Self-Hosting bei den Kosten lohnt, müssen Sie nahezu 1 Milliarde Ausgabetokens pro Monat erzeugen, also ungefähr 30 Millionen pro Tag. Außerdem muss der Cluster während dieser Zeit vollständig ausgelastet sein, weil ungenutzte GPUs genauso abgerechnet werden wie ausgelastete GPUs. Bei agentenbasierten Workloads mit vielen Prompts verschiebt sich der Break-even-Punkt noch weiter: Wiederholter Kontext wird bei einer Cache-Trefferrate von 0.30 USD pro 1 Million Tokens statt bei der Cache-Fehlerrate von 3.00 USD abgerechnet.

In dieser Stufe hosten Sie alles rund um das Modell selbst: ein Gateway, das den API-Schlüssel verwahrt, damit er niemals einen Client erreicht, Logs für Anfragen und Antworten, Wiederholungen, Rate-Limits und Budgets pro Benutzer. Das läuft auf einem kleinen VPS vollständig ohne GPU. Dieselbe Aufteilung gilt für geschlossene Gewichte. Dort ist Self-Hosting von Claude auf Modellebene nicht möglich, und nur die Orchestrierung liegt in Ihrer Hand.

Welcher Serving-Stack gehört zu welcher Stufe

Server der Klassen vLLM und SGLang gehören zu Stufe 1. Sie sind dafür ausgelegt, viele Anfragen gleichzeitig zu verarbeiten, mit Continuous Batching und einem paginierten KV-Cache sowie Tensor- und Expertenparallelismus über mehrere Knoten hinweg. Sie setzen Beschleuniger in Rechenzentren und eine schnelle Verbindung zwischen diesen voraus. Auf einer einzelnen Consumer-Karte sind sie aufwendiger zu installieren und bieten nur wenige Vorteile, die Sie tatsächlich bemerken würden.

llama.cpp und Ollama gehören zu Stufe 2. Sie sind für einen einzelnen Rechner, GGUF-Quantisierung, CPU-Offload bei unzureichendem Grafikspeicher und eine geringe Parallelität ausgelegt. llama.cpp kann ein enormes MoE technisch laden, indem die meisten Layer im System-RAM gehalten werden. Bei einem 2.8T-Modell dauert die Verarbeitung auf diesem Weg jedoch Sekunden pro Token. Damit ist nur nachgewiesen, dass die Datei eingelesen werden kann. Es handelt sich nicht um einen Dienst, den Sie Benutzern bereitstellen können. Der vollständige Vergleich steht unter Ollama im Vergleich zu vLLM. Das ändert sich beim Modell nicht: Entscheidend ist immer, ob Sie viele Benutzer auf gemeinsam genutzter Hardware bedienen oder einen Benutzer auf Ihrem eigenen System.

Die vier Zahlen, die diesen Prüfpunkt überdauern

1. Die Gesamtzahl der Parameter multipliziert mit den Bytes pro Gewicht ergibt den Speicherbedarf als Untergrenze. Darunter läuft nichts. Sobald die Veröffentlichung bereits 4-bit-quantisiert ist, lässt sich diese Grenze durch Quantisierungstricks kaum noch verschieben.
2. Die aktiven Parameter bestimmen die Durchsatzklasse. Ein MoE-Modell mit 2.8T Gesamtparametern und 104B aktiven Parametern berechnet wie ein 104B-Modell.
3. Der KV-Cache pro Token multipliziert mit der Kontextlänge und der Anzahl gleichzeitiger Anfragen ergibt die Kosten, die nach dem Bezahlen der Gewichte weiter steigen.
4. Tokens pro Sekunde und Dollar ist die einzige Zahl, die eine Tier-Auswahl ermöglicht. Alles darüber fließt in diese Zahl ein.

Wenden Sie diese vier Werte auf jede Veröffentlichung an. Dann erhalten Sie die richtige Antwort, bevor Sie eine Anbieteranleitung öffnen. Datieren Sie anschließend jede notierte Zahl. Preise und Listen unterstützter Architekturen änderten sich innerhalb der zwei Wochen nach dem Start von K3. Jede Zahl auf dieser Seite wurde im Juli 2026 veröffentlicht.

FAQ

Kann ich Kimi K3 auf einer einzelnen GPU ausführen?

Nein. Die Gewichte umfassen bei der von Moonshot ausgelieferten MXFP4-Präzision etwa 1.4 TB, und der größte einzelne erhältliche Beschleuniger verfügt über 288 GB. Ein MoE-Modell kann seine inaktiven Experten nicht mit nutzbarer Geschwindigkeit von der Festplatte streamen, weil der Router für jedes Token einen beliebigen Experten auswählen kann und ein PCIe-Abruf deutlich länger dauert, als das Token-Zeitbudget erlaubt. Die kleinste sinnvolle K3-Bereitstellung ist ein Knoten mit mehreren GPUs. Veröffentlichten Anleitungen zufolge werden 32 Beschleuniger oder mehr verwendet.

Wie viel VRAM benötigt Kimi K3?

Rechnen Sie allein für die Gewichte zunächst mit 1.4 TB. Das entspricht 18 H100-Karten mit 80 GB oder 5 Karten der GB300-Klasse. Zusätzlich benötigen Sie Speicher für den KV-Cache und die Aktivierungen. Im August 2026 empfiehlt Moonshot 64 oder mehr Beschleuniger. Das SGLang-Kochbuch beschreibt außerdem eine H100-Konfiguration mit 32 GPUs und insgesamt 2,560 GB. Betrachten Sie die Gewichtsgröße daher als Untergrenze und nicht als konkrete Anforderung.

Passt Kimi K3 durch Quantisierung auf einen einzelnen Knoten?

Nicht sinnvoll. Der veröffentlichte Checkpoint verwendet bereits 4-Bit-Quantisierung mit quantisierungsbewusstem Training. Die einfachste Einsparung wurde daher bereits umgesetzt. Eine weitere Reduzierung auf 2 Bit senkt die Gewichtsgröße auf 0.7 TB. Das ist weiterhin mehr als doppelt so viel wie die Kapazität der größten Karte. Die Genauigkeitsverluste von 2 Bit wurden für dieses Modell außerdem nicht vermessen.

Ist das Mieten von GPUs günstiger als die Kimi-K3-API?

Nur bei hohem und gleichmäßigem Volumen. Bei angenommenen Kosten von 2.50 USD pro GPU-Stunde kostet ein dauerhaft aktiver Knoten mit 8 GPUs 14,400 USD pro Monat. Für denselben Betrag erhalten Sie zum veröffentlichten Preis von 15.00 USD pro Million etwa 960 Millionen Ausgabetoken. Zusätzlich zahlen Sie für ungenutzte Stunden, das Herunterladen der Gewichte und die Person, die den Cluster betreibt. Mieten Sie GPUs für kurzzeitige Lastspitzen stundenweise. Vergleichen Sie die Kosten anhand Ihres tatsächlich gemessenen Tokenvolumens und nicht anhand einer Schätzung.

Was bedeutet die Zahl von 104B aktiven Parametern für die Geschwindigkeit?

Die Berechnungen pro Token entsprechen denen eines 104B-Modells. Der Durchsatz liegt daher in dieser Leistungsklasse und nicht in der Klasse eines 2.8T-Modells. Für den Speicherbedarf sagt diese Zahl nichts aus: Alle 2.8T Parameter bleiben im Speicher, weil der Router für jedes Token einen beliebigen Experten aufrufen kann. Verwenden Sie die Zahl der aktiven Parameter zur Schätzung der Token pro Sekunde und die Gesamtzahl zur Dimensionierung des VRAM.