← Insights

EN — English version

Was nach 60.000 Tokens passiert: MiniMax M2.7 unter langer Agentenlast

· Filip

83 bis 90 Token pro Sekunde im Single-Stream, rund 181 Token pro Sekunde über vier parallele Requests und ein Modell, das bei kurzen Aufgaben ausgesprochen stark wirkte: Unser Hybrid-AWQ von MiniMax M2.7 sah zunächst nach einer sehr gelungenen Verbindung aus Geschwindigkeit und Qualität aus. Für einen lokalen Betrieb auf acht Consumer-GPUs waren das Zahlen, mit denen wir gut arbeiten konnten.

Dann wurden die Sitzungen länger.

Unsere eigentlichen Aufgaben bestehen selten aus einer einzelnen Frage und einer kurzen Antwort. Agenten lesen Dateien, rufen Werkzeuge auf, vergleichen Ergebnisse, korrigieren Zwischenschritte und tragen den bisherigen Verlauf weiter. Bei einer Bewertung von elf Profilen samt Rangliste, Markdown-Bericht und mehreren formularartigen Dokumenten wächst der aktive Kontext unauffällig in den Bereich von 60.000 bis über 100.000 Tokens. Genau dort änderte sich das Verhalten von MiniMax: Reasoning-Schleifen wurden länger, Bewertungen schwankten zwischen identischen Läufen und gelegentlich erschienen chinesische oder andere fremdsprachige Fragmente in einer deutschen Ausgabe.

Damit verschob sich auch unsere Leitfrage. Die Maximalgröße eines Kontextfensters war nur noch eine Kapazitätsangabe. Für den Betrieb mussten wir wissen, wie schnell, kohärent und urteilsstabil ein Modell nach 60.000, 80.000 oder 100.000 tatsächlich aktiven Tokens noch arbeitet.

Dieser Artikel beschreibt unsere praktischen Läufe auf genau einem Rig und mit den jeweils dokumentierten Quants, Engines und Startparametern. Die Ergebnisse sind keine universellen Modellbenchmarks. Sie zeigen, wie sich diese Konfigurationen unter unserer langen Agentenlast verhielten und an welchen Stellen Modell, Quantisierung, Runtime und Hardware kaum noch sauber voneinander zu trennen waren.

Acht Consumer-GPUs sind kein einheitlicher Speicherblock

Unser lokales LLM-Rig besteht aus sieben RTX 3090 und einer RTX 3090 Ti. Zusammen stellen die Karten rund 192 GB VRAM bereit. Sie hängen an einer Consumer-PCIe-Topologie ohne NVSwitch und in unserem Aufbau auch ohne nutzbaren NVLink-Verbund. Große Modelle passen damit in den Speicher, müssen ihre Arbeit aber über acht eigenständige GPUs und mehrere PCIe-Root-Complexes verteilen.

Für jeden ernsthaften Versuch wirkten deshalb vier Größen zusammen:

  • die Verteilung von Modellgewichten und KV-Cache auf die Karten,
  • der Kommunikationsaufwand über PCIe,
  • Quantisierungsformat und Engine,
  • der Decode-Durchsatz bei langem aktivem Kontext.

Der letzte Punkt fiel in kurzen Benchmarks kaum auf. Ein kurzer Prompt misst vor allem, wie schnell die Engine Gewichte bewegt und einen kleinen KV-Cache verarbeitet. Ein langer Agentenlauf verlangt bei jedem neuen Token zusätzlich Arbeit über eine große aktive Historie. Diese Kosten wachsen je nach Attention-Architektur sehr unterschiedlich.

Der Hybrid-AWQ löste das Quantproblem, zunächst jedenfalls

Im vorherigen Artikel über unsere Quantisierungsversuche haben wir ausführlich beschrieben, weshalb eine nominelle Bitzahl bei MiniMax wenig erklärt. Unser schneller Produktionskandidat war schließlich ayysasha/MiniMax-M2.7-AWQ-G32-STRIX-2H: INT4-Experten sparen den größten Teil des Speichers, während Attention, Router und weitere empfindliche Bereiche in höherer Präzision bleiben.

Die relevanten Eckdaten unseres ersten produktiven Pfads waren:

Bestandteil Konfiguration
Expertentensoren INT4
Attention BF16
Router/Gate BF16 beziehungsweise hochpräzise
KV-Cache int8_per_token_head
Parallelisierung TP=8 plus Expert Parallelism
Engine vLLM
Single-Stream, kurzer Kontext ungefähr 83 bis 90 tok/s
vier parallele Requests, synthetisch ungefähr 181 tok/s aggregiert

Bei kurzen technischen Spezifikationen war die Ausgabe kohärent, und auch Tool-Calls funktionierten. Damit war die Quantisierungsfrage für diesen Pfad praktisch beantwortet: Das Modell war schnell, und seine Fähigkeiten waren nicht auf dieselbe offensichtliche Weise beschädigt wie beim pauschalen W4A16-Quant. Offen blieb, ob es diese Qualität über eine lange, werkzeuglastige Sitzung halten konnte.

Ein Kontextfenster kann groß und trotzdem kaum nutzbar sein

Zwischen einem Server, der einen langen Prompt annimmt, und einem Modell, das darin weiter verlässlich arbeitet, liegt eine erhebliche Lücke. Das konfigurierte Maximum beschreibt zunächst, ob Gewichte, KV-Cache und Laufzeitpuffer in den Speicher passen. Es sagt wenig darüber aus, wie sich drei andere Größen im Verlauf entwickeln:

  1. Wie stark fällt die Decode-Rate, wenn jedes neue Token eine sehr lange Historie berücksichtigen muss?
  2. Bleiben Reasoning, Sprache und Werkzeugaufrufe stabil?
  3. Liefert das Modell bei wiederholten Bewertungsaufgaben vergleichbare Urteile?

Gerade der dritte Punkt ist für Agentenarbeit wichtiger als ein spektakulärer Einzeloutput. Ein Modell kann alle Dateien korrekt schreiben und den Prozess formal erfolgreich beenden. Wenn dieselben Kandidaten bei identischer Aufgabe mehrere Rangplätze springen, ist der Lauf technisch abgeschlossen, die Entscheidung aber nicht belastbar.

Bei MiniMax trat die Verschlechterung im Bereich von 60.000 bis über 100.000 aktiven Tokens in mehreren Formen auf:

  • Das Reasoning wiederholte dieselbe Analyse mit leicht veränderter Formulierung.
  • Einzelne Denkblöcke wuchsen auf viele Tausend Tokens.
  • Deutsche Ausgaben enthielten chinesische Tokens oder andere mehrsprachige Fragmente.
  • Tool-Calls endeten nicht sauber oder liefen in wiederholte write– beziehungsweise edit-Versuche.
  • Identische Bewertungsaufgaben erzeugten deutlich verschiedene Ranglisten.

Nicht jeder Lauf zeigte alle Symptome. Genau das machte die Diagnose schwieriger. Ein deterministischer Absturz lässt sich einer Schicht vergleichsweise gut zuordnen. Eine Sitzung, die vierzig Minuten arbeitet, sechs korrekte Dateien ablegt und darin zu einem grundlegend anderen Urteil kommt als am Vortag, ist operativ höflicher und fachlich problematischer.

vLLM 0.25.1 beseitigte die gröbsten Schleifen, nicht die Instabilität

Wir aktualisierten den MiniMax-Pfad auf vllm/vllm-openai:v0.25.1, verwendeten den nativen minimax_m2-Parser für Reasoning und Tool-Calls und stellten den KV-Cache auf int8_per_token_head. Dazu kam dieses Sampling-Rezept:

{
  "temperature": 0.6,
  "top_p": 0.95,
  "top_k": 40,
  "min_p": 0.01,
  "repetition_penalty": 1.1,
  "frequency_penalty": 0.4
}

Die Änderung half sichtbar. Das frühere reine Garbling und die schlimmsten wörtlichen Reasoning-Schleifen wurden seltener. Auch die Parser-Regression eines zwischenzeitlich getesteten Stands war in 0.25.1 behoben. Der verbleibende Fehler war weniger auffällig: sehr große Reasoning-Blöcke, Probleme beim Abschluss einzelner Tool-Calls und vor allem schwankende Bewertungen.

Für einen kontrollierten Vergleich ließen wir dieselbe Aufgabe mit elf Profilen fünfmal auf demselben vLLM-Stack laufen. Alle fünf Wiederholungen erzeugten die sechs erwarteten Artefakte. Nach einem rein operativen Kriterium lag die Erfolgsquote also bei fünf von fünf.

Die Inhalte erzählten eine andere Geschichte:

Beobachtung über fünf Wiederholungen Ergebnis
vollständige Deliverables 5 von 5
höchste vergebene Gesamtpunktzahl je Lauf 158, 79, 75, 105, 80
Platz 1 person_11 dreimal, außerdem person_09 und person_06
Beispiel für die Platzierung eines einzelnen Profils 5 -> 6 -> 3 -> 1 -> 7
Reasoning-Tokens je Lauf ungefähr 6.700 bis 12.900
größter einzelner Reasoning-Block ungefähr 10.070 Tokens
Laufzeit je Wiederholung ungefähr 18 bis 38 Minuten

Die konkrete Rangfolge darf bei einer stochastischen Generierung variieren. Hier bewegten sich jedoch Sieger, Punkteskala und einzelne Kandidaten so stark, dass aus den fünf Läufen keine stabile fachliche Reihenfolge entstand. Das Modell beherrschte Dateierzeugung und Workflow; seine Bewertung war unter dieser langen Last nicht reproduzierbar genug.

Ein Gegenversuch mit SGLang änderte daran nichts. Im kurzen Decode-Mikrobenchmark war SGLang etwa 26 Prozent schneller, im realen High-Context-Lauf wegen eager Prefill jedoch langsamer und zugleich anfälliger für Runaways. Damit ließ sich die Instabilität nicht auf vLLM allein reduzieren. Unterschiede bei Engine, KV-Format und Parser beeinflussten das Fehlerbild, beseitigten die langen Schleifen und schwankenden Urteile aber nicht.

Der rekonstruierte IQ5_K-Pfad war langsamer, aber erstaunlich solide

Parallel existierte ein älterer Fallback mit dem 5-Bit-GGUF ubergarm/MiniMax-M2.7-GGUF in IQ5_K und ik_llama.cpp. Die Unterschiede zum Hybrid-AWQ behandelt Post 2 im Detail; für den Betrieb zählen hier nur zwei Punkte. Der Quant war qualitativ brauchbar, und seine Leistung hing erstaunlich stark am exakten Startrezept.

Zwischenzeitlich hielten wir diesen Pfad für nicht mehr reproduzierbar. Aus einer lokalen OpenCode-Sitzungsdatenbank rekonstruierten wir später den tatsächlich verwendeten Befehl. Mehrere vermeintlich kleine Abweichungen hatten unsere Nachbauten verfälscht:

  • q4_0 statt q8_0 für Key- und Value-Cache,
  • der balancierte Tensor-Split,
  • kein versehentlich aktivierter Graph-Split,
  • die ursprünglichen mmap- und Cache-Einstellungen,
  • das Image ik-llama-cuda:main-20260612-full.

Mit diesem Aufbau kehrten die früheren Werte zurück:

  • ungefähr 49,5 tok/s bei kurzem Kontext,
  • ungefähr 350 tok/s Prompt-Verarbeitung bei rund 80.000 Tokens,
  • ungefähr 13,1 tok/s Decode bei rund 80.000 Tokens aktivem Kontext,
  • kohärente und in den beobachteten Aufgaben brauchbare Ausgabe.

Der Pfad war damit deutlich langsamer als der Hybrid-AWQ auf vLLM. Er zeigte aber, wie schnell eine falsche Rekonstruktion zu einer falschen Aussage über Modell oder Quant führen kann. In einem verteilten Inferenzsystem ist „dasselbe Modell“ keine vollständige Versuchsbeschreibung.

--max-gpu war messbar und blieb ein Feintuning-Hebel

Der ik_llama-Fork besitzt für den Graph-Modus unter anderem --max-gpu N und -grt. --max-gpu 4 beschränkt den Lauf nicht auf vier Karten. Alle acht GPUs können global Teile des Modells tragen; ein einzelner Layer wird jedoch auf höchstens vier Karten bearbeitet. Dadurch sinkt theoretisch der Teilnehmerkreis für layerlokale Reduktionen. Bei acht KV-Heads klang eine Vierergruppe auf unserem Rig durchaus plausibel.

Wir verglichen den MiniMax-IQ5_K-Pfad mit --max-gpu 4 und --max-gpu 2. Beide Varianten booteten sauber und lagen praktisch gleichauf. Im jeweiligen A/B-Vergleich stieg der kurze Durchsatz von etwa 49,5 auf rund 50,3 tok/s. Bei ungefähr 80.000 aktiven Tokens erreichten die Varianten etwa 13,07 beziehungsweise 13,08 tok/s gegenüber rund 12,3 tok/s im zugehörigen Basislauf. Abhängig vom Messpunkt lag der Gewinn damit ungefähr zwischen einem und sechs Prozent.

Das ist ein echter Effekt, nur kein struktureller Durchbruch. Der Schalter verschob eine Grenze geringfügig; er machte aus einem Decode im niedrigen zweistelligen Bereich keinen 40-tok/s-Langkontextpfad.

HY3 trennte Qualitätsproblem und Geschwindigkeitsproblem deutlicher

Um herauszufinden, welche Symptome MiniMax-spezifisch waren, testeten wir Tencent HY3, ein 295B-A21B-MoE mit 80 Layern und acht KV-Heads. Zwei Quants führten zu sehr verschiedenen Grenzen.

GPTQ Int4 auf vLLM: schnell genug, aber kaum Kontextreserve

Der erste Versuch verwendete AngelSlim/Hy3-GPTQ-Int4 auf vLLM 0.25.1 mit TP=8. Das Modell erreichte bei kurzem Kontext ungefähr 56,3 tok/s. Nach dem Laden blieben pro TP-Rank beziehungsweise GPU allerdings nur rund 0,47 GiB nutzbarer KV-Speicher. vLLM schätzte den maximalen Kontext in dieser Konfiguration auf etwa 12.400 Tokens.

Für unsere langen Agentensitzungen war der Pfad damit erledigt. Die Decode-Rate war nicht das Problem; die Sitzung passte schlicht nicht in den verbleibenden KV-Cache. Ein nominelles --max-model-len 262144 vergrößerte den verfügbaren Speicher erwartungsgemäß nicht.

UD128 auf llama.cpp: guter Lauf, steile Kontextkosten

Mehr Spielraum bot der GGUF YanissAmz/Hy3-295B-A21B-GGUF in der Variante UD128. Unser älteres llama.cpp-Image kannte die Architektur zunächst nicht und brach mit unknown model architecture: 'hy_v3' ab. Nach dem Wechsel auf ein neueres ghcr.io/ggml-org/llama.cpp:server-cuda startete das Modell mit 262.144 Tokens konfiguriertem Kontext, q8_0-KV, Flash Attention und gleichmäßigem Tensor-Split über alle acht GPUs.

Die damalige Non-MTP-Baseline ergab:

aktiver Prompt-Kontext Prompt-Verarbeitung Decode
kurz – ungefähr 44,8 tok/s
ungefähr 100.024 Tokens ungefähr 643 tok/s ungefähr 12,3 tok/s
ungefähr 200.024 Tokens ungefähr 216 tok/s ungefähr 4,6 tok/s

Diese Zahlen gelten für den unten dokumentierten Lauf ohne aktivierte Multi-Token Prediction. Sie sind weder ein allgemeines Urteil über HY3 noch eine Aussage über jede spätere Runtime-Optimierung.

Inhaltlich war HY3 der aufschlussreichere Gegenversuch. In einem realen Lauf um 90.000 Tokens blieb das Modell kohärent, schrieb korrektes Deutsch und fand fehlende Punkte in der laufenden Analyse. Das Fehlerprofil unterschied sich damit deutlich von unseren MiniMax-Läufen: Die Ausgabe blieb überzeugend, während der Decode-Durchsatz mit wachsendem Kontext stark einbrach.

Auch der Split-Modus war messbar. Layer-Split erreichte bei kurzem Kontext rund 40 tok/s, Tensor-Split etwa 45,7 tok/s, also ungefähr 14 Prozent mehr. HY3 besitzt acht KV-Heads, was für eine Verteilung über acht GPUs günstig ist. Der Tensor-Split nutzte die aggregierte Speicherbandbreite besser, obwohl dafür Reduktionen über PCIe anfielen. f16– und bf16-KV passten in diesem Tensor-Pfad selbst bei deutlich kleiner getesteten Kontexten nicht; für den 262k-Aufbau war q8_0 die funktionierende Wahl.

HY3 beantwortete damit eine wichtige Diagnosefrage. Ein großes Full-Attention-Modell kann bei langem Kontext qualitativ stabil bleiben und trotzdem betrieblich zu langsam werden. Bei MiniMax kamen zu diesen Kontextkosten zusätzlich Schleifen, Sprachlecks und instabile Urteile.

Qwen3.5-122B machte die Architekturkosten sichtbar

Unsere Kontrollgruppe war RedHatAI/Qwen3.5-122B-A10B-FP8-dynamic, eine dynamisch quantisierte Variante des offiziellen Qwen3.5-122B-A10B. Das Modell lief ebenfalls auf vLLM 0.25.1 und demselben 8×3090-Rig.

Zwei Topologien zeigten den üblichen Tausch zwischen Single-Stream-Geschwindigkeit und KV-Reserve:

Topologie kurzer Decode gemeldeter KV-Pool rechnerische 262k-Sitzungen
TP=8 ungefähr 104,9 tok/s 474.777 Tokens ungefähr 1,81
TP=2 + PP=4 ungefähr 72,6 tok/s 1.551.018 Tokens ungefähr 5,9

Der große Pool erweitert den Kontext eines einzelnen Requests nicht über die Modellgrenze von 262.144 Tokens. Er erlaubt mehrere lange Sitzungen nebeneinander. Für einen Agentenserver ist das häufig nützlicher als die höchste Zahl eines einzelnen Kurzbenchmarks.

Entscheidend war die Architektur. Qwen verwendet 48 Sprachmodell-Layer, von denen nur jeder vierte vollständige Attention ausführt. Die übrigen Layer arbeiten mit linearer beziehungsweise rekurrenter Attention. Außerdem besitzt das Modell nur zwei KV-Heads. MiniMax und HY3 führen dagegen in sämtlichen Layern Full Attention mit jeweils acht KV-Heads aus.

Modell Full-Attention-Layer KV-Heads Head-Dimension relative BF16-KV-Arbeit pro Token
Qwen3.5-122B-A10B 12 von 48 2 256 1x
MiniMax M2.7 62 von 62 8 128 ungefähr 10,3x
HY3 80 von 80 8 128 ungefähr 13,3x

Die letzte Spalte ist eine architekturbasierte Vergleichsgröße, kein gemessener Durchsatz. Sie erklärt jedoch die Richtung unserer Beobachtungen. Bei MiniMax und HY3 muss jedes generierte Token durch alle Full-Attention-Layer über eine wachsende Historie arbeiten. Qwen trägt einen großen Teil der Historie in kompakterem Zustand und bezahlt die volle KV-Rechnung nur in einem Viertel der Layer.

Dadurch fühlte sich Qwen in langen Sitzungen weniger empfindlich an. Es war nicht in jeder Aufgabe das stärkste Modell und auch nicht frei von Verbosität. Es blieb auf unserem Rig jedoch wesentlich leichter planbar: hoher kurzer Durchsatz, viel KV-Reserve in der PP-lastigen Topologie und weniger dramatischer Decode-Verlust bei langem aktivem Kontext.

Hardwarefehler schrieben ihre eigenen Modellbewertungen

Ein Teil unserer vermeintlichen Softwareprobleme entstand außerhalb der Software. Während verschiedener Läufe verschwanden unterschiedliche GPUs aus dem PCIe-Baum. Nach Änderungen an der Stromverteilung wanderte der Ausfall zu einer anderen Karte oder trat zunächst nicht mehr auf. In anderen Zuständen kamen Karten nur mit Gen1-Verbindung zurück. HY3 mit achtfachem Tensor-Split konnte dabei einen GPU-Ausfall provozieren, während Qwen3.6-35B-A3B auf TP4+PP2 stundenlang lief. Die beiden Konfigurationen belasteten den Aufbau verschieden; ihr unterschiedliches Verhalten war daher kein sauberer Beleg für einen Modellfehler.

Die Diagnose führte zu Stromverteilung, transienten Lastspitzen, Riserkontakten und degradierten PCIe-Links. Wir haben die zeitliche Fehlersuche im Hardwareartikel „Wenn die GPU vom Bus überfahren wird“ ausführlich dokumentiert. Für die Modellversuche war vor allem die Reihenfolge wichtig:

  • Zuerst verschwand GPU 1 an 41:00.0 beziehungsweise SLOT2.
  • Nach Änderungen an der Stromzuordnung traf es unter anderem GPU 6 an c1:00.0 beziehungsweise SLOT3.
  • Bei anderer Lastverteilung fielen mehrere Karten desselben Versorgungszweigs aus.
  • Nach Umbauten erschienen einzelne Verbindungen zeitweise nur als Gen1 x8, Gen1 x4 oder Gen1 x16.

Solche Fehler sehen oberhalb des Treibers wie tote Worker, RPC-Timeouts, CUDA-Probleme oder eine abgestürzte Engine aus. Sie können außerdem Messwerte verfälschen, ohne sofort einen harten Fehler auszulösen. Ein auf Gen1 zurückgefallener PCIe-Link und thermisch eingebrochener GDDR6X-Speicher sind durchaus in der Lage, eine vermeintliche Engine-Regression zu produzieren.

Deshalb trennen wir seitdem drei Prüfungen, bevor wir ein Modell bewerten: Sind alle acht Karten vorhanden? Arbeiten ihre Links unter Last mit plausibler Bandbreite? Bleiben Strom, Temperaturen, Takte und AER-Zähler während des gesamten Laufs unauffällig? Erst danach bekommt die Inferenzsoftware Gelegenheit, selbst schuld zu sein.

Was wir für den Betrieb geändert haben

Aus den Versuchen folgen für unseren Alltag einige nüchterne Regeln.

Wir messen am Zielkontext

Ein Kurzbenchmark bleibt nützlich, weil er grobe Kernel- und Split-Unterschiede sichtbar macht. Für die Auswahl eines Agentenmodells ergänzen wir ihn um Messpunkte bei ungefähr 60k, 80k, 100k und, soweit sinnvoll, 200k aktivem Kontext. Dazu gehören Decode-Rate, Time to First Token, Prompt-Durchsatz und eine qualitative Aufgabe, die das Modell über mehrere Werkzeugschritte trägt.

Wir behandeln formalen Erfolg und fachliche Stabilität getrennt

Dateien, Exit-Codes und abgeschlossene Tool-Calls beantworten die Betriebsfrage. Wiederholte identische Läufe beantworten die Vertrauensfrage. Bei Bewertungen und Ranglisten reichen einzelne erfolgreiche Ausgaben nicht. Wir vergleichen Sieger, Punkteskalen, Rangbewegungen und Begründungen über mehrere Wiederholungen.

Wir begrenzen lange Bewertungsaufgaben, wenn das Modell im Grenzbereich driftet

Für MiniMax ist eine Aufteilung der elf Profile in zwei oder drei Gruppen eine praktikable Gegenmaßnahme. Der aktive Kontext bleibt damit eher unter der beobachteten Degradationszone. Das ersetzt keinen stabileren Modellpfad, verhindert aber, dass eine einzelne Sitzung zugleich sämtliche Profile, Zwischenanalysen, Formulare und Reasoning-Tokens tragen muss.

Wir bewahren funktionierende Starts als vollständige Artefakte

Modellname und Quant reichen nicht. Zu einem reproduzierbaren Lauf gehören Image-Tag oder Digest, kompletter Startbefehl, KV-Dtype, Kontextgröße, Split-Modus, Tensor-Split, Cache-Optionen, Containername, Port und Messprotokoll. Der wiedergefundene IQ5_K-Start war dafür die nachdrücklichste Erinnerung: Unser Gedächtnis hatte ein plausibles Kommando rekonstruiert. Der Rechner bevorzugte das tatsächliche.

Wir ziehen erst nach einem Hardware-Stresstest Modellschlüsse

Wandernde GPU-Ausfälle, AER-Fehler, Gen1-Retraining und thermische Takteinbrüche machen jeden Modellvergleich wertlos. Ein kurzer gesunder Lauf genügt nicht, wenn die spätere Aufgabe einen langen Prefill, acht parallele GPU-Pfade und mehrere Kilowatt Lastwechsel erzeugt.

Reproduzierbarkeit: die entscheidenden Starts

Die folgenden Angaben gehören unmittelbar zu den Messwerten dieses Artikels. Wo kein vollständiger Docker-Start aus der Dokumentation vorlag, nennen wir die exakt gespeicherten Serverargumente statt eine plausible Hülle zu ergänzen.

MiniMax Hybrid-AWQ auf vLLM 0.25.1

Merkmal Wert
Container minimax_m27_awq_upgrade
Image vllm/vllm-openai:v0.25.1
Compose-Profil ayysasha_upgrade
Host-/Server-Port 8000
maximaler Modellkontext 180000
KV-Cache int8_per_token_head
Split TP=8 plus Expert Parallelism

Gespeicherte Serverargumente:

/models/MiniMax-M2.7-AWQ 
  --served-model-name MiniMax-M2.7-AWQ-hybrid-int8kv mm minimax-m2.7-awq 
  --tensor-parallel-size 8 
  --enable-expert-parallel 
  --max-model-len 180000 
  --kv-cache-dtype int8_per_token_head 
  --attention-backend TRITON_ATTN 
  --disable-custom-all-reduce 
  --gpu-memory-utilization 0.95 
  --max-num-seqs 4 
  --max-num-batched-tokens 4096 
  --generation-config auto 
  --override-generation-config '{"temperature":0.6,"top_p":0.95,"top_k":40,"repetition_penalty":1.1,"frequency_penalty":0.4}' 
  --enable-prefix-caching 
  --reasoning-parser minimax_m2 
  --tool-call-parser minimax_m2 
  --enable-auto-tool-choice 
  --trust-remote-code 
  --compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY","max_cudagraph_capture_size":16}' 
  --host 0.0.0.0 
  --port 8000

Zugehörige Umgebungsvariablen:

VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS=0
NCCL_P2P_DISABLE=1
NCCL_IB_DISABLE=1
NCCL_CUMEM_ENABLE=0
VLLM_ALLREDUCE_USE_SYMM_MEM=0
VLLM_WORKER_MULTIPROC_METHOD=spawn
VLLM_ENABLE_CUDA_COMPATIBILITY=0

Das oben separat wiedergegebene JSON-Sampling-Rezept enthält zusätzlich min_p: 0.01 und beschreibt die Parameter der fünf Agentenläufe. Die gespeicherte serverseitige Override-Zeile enthielt diesen Wert nicht; wir führen beide Ebenen deshalb getrennt auf.

MiniMax IQ5_K auf ik_llama

docker run -d --name minimax_iq5k --gpus all --ipc=host --shm-size=64g 
  -e NVIDIA_DISABLE_REQUIRE=1 
  -p 8088:8080 
  -v /bigData/llama-models/ubergarm/MiniMax-M2.7-GGUF:/models 
  --entrypoint /app/llama-server 
  ik-llama-cuda:main-20260612-full 
  --model /models/IQ5_K/MiniMax-M2.7-IQ5_K-00001-of-00005.gguf 
  --alias MiniMax-M2.7-IQ5_K 
  --host 0.0.0.0 --port 8080 
  -c 163840 
  -fa 1 -ngl 999 
  -ts 1,1.008,1,1.008,1.008,1.008,1,0.97 
  -ctk q4_0 -ctv q4_0 
  -muge -gr 
  -b 2048 -ub 256 
  --threads 1 --parallel 1 
  --no-mmap --jinja 
  --cache-ram 32768 --prompt-cache-all

Die --max-gpu-Vergleiche verwendeten denselben Start mit --max-gpu 4 auf Host-Port 8089 beziehungsweise --max-gpu 2 auf 8090. Alle übrigen Parameter blieben gleich.

HY3 GPTQ Int4 auf vLLM 0.25.1

docker run -d --name hy3_gptq_int4 --gpus all --shm-size 32g --ipc host 
  -e NVIDIA_VISIBLE_DEVICES=all 
  -e NVIDIA_DISABLE_REQUIRE=1 
  -e CUDA_DEVICE_ORDER=PCI_BUS_ID 
  -e NCCL_P2P_DISABLE=1 
  -e NCCL_IB_DISABLE=1 
  -e NCCL_CUMEM_ENABLE=0 
  -e VLLM_ALLREDUCE_USE_SYMM_MEM=0 
  -e VLLM_WORKER_MULTIPROC_METHOD=spawn 
  -e VLLM_ENABLE_CUDA_COMPATIBILITY=0 
  -e VLLM_FLASHINFER_ALLREDUCE_BACKEND=trtllm 
  -v /bigData/hf-cache/AngelSlim-Hy3-GPTQ-Int4:/models/AngelSlim-Hy3-GPTQ-Int4 
  -v /bigData/vllm/data/torch-extensions-v024:/root/.cache/torch_extensions 
  -v /bigData/vllm/data/triton-v024:/root/.triton 
  -v /bigData/vllm/data/cuda-cache-v024:/root/.cache/cuda 
  -v /bigData/vllm/data/vllm-cache-v024:/root/.cache/vllm 
  -p 8005:8000 
  vllm/vllm-openai:v0.25.1 
  /models/AngelSlim-Hy3-GPTQ-Int4 
  --served-model-name hy3-gptq-int4 
  --tensor-parallel-size 8 
  --max-model-len 12000 
  --gpu-memory-utilization 0.92 
  --max-num-seqs 8 
  --max-num-batched-tokens 4096 
  --disable-custom-all-reduce 
  --enable-prefix-caching 
  --tool-call-parser hy_v3 
  --reasoning-parser hy_v3 
  --enable-auto-tool-choice 
  --trust-remote-code 
  --host 0.0.0.0 
  --port 8000

HY3 UD128 auf llama.cpp, Non-MTP-Baseline

docker run -d --name hy3_ud128_ctx --entrypoint /app/llama-server 
  --gpus all --ipc host --shm-size 64g 
  -p 8005:8005 
  -v /bigData/llama-models/YanissAmz-Hy3-UD128:/models 
  ghcr.io/ggml-org/llama.cpp:server-cuda 
  --model /models/Hy3-UD128-00001-of-00003.gguf 
  --host 0.0.0.0 
  --port 8005 
  --ctx-size 262144 
  --flash-attn on 
  --n-gpu-layers 999 
  --cache-type-k q8_0 
  --cache-type-v q8_0 
  --batch-size 2048 
  --ubatch-size 512 
  --split-mode tensor 
  --tensor-split 1,1,1,1,1,1,1,1 
  --threads 24 
  --parallel 1 
  --chat-template-file /models/hy3-chat-template.jinja

Qwen3.5-122B-A10B-FP8-dynamic auf vLLM 0.25.1, TP=8

docker run -d --name qwen122b_fp8dyn_tp8 --gpus all --shm-size 32g --ipc host 
  -e NVIDIA_VISIBLE_DEVICES=all 
  -e NVIDIA_DISABLE_REQUIRE=1 
  -e CUDA_DEVICE_ORDER=PCI_BUS_ID 
  -e NCCL_P2P_DISABLE=1 
  -e NCCL_IB_DISABLE=1 
  -e NCCL_CUMEM_ENABLE=0 
  -e VLLM_ALLREDUCE_USE_SYMM_MEM=0 
  -e VLLM_WORKER_MULTIPROC_METHOD=spawn 
  -e VLLM_ENABLE_CUDA_COMPATIBILITY=0 
  -v /bigData/hf-cache/Qwen3.5-122B-A10B-FP8-dynamic:/models/Qwen3.5-122B-A10B-FP8-dynamic 
  -v /bigData/vllm/data/torch-extensions-v024:/root/.cache/torch_extensions 
  -v /bigData/vllm/data/triton-v024:/root/.triton 
  -v /bigData/vllm/data/cuda-cache-v024:/root/.cache/cuda 
  -v /bigData/vllm/data/vllm-cache-v024:/root/.cache/vllm 
  -p 8004:8000 
  vllm/vllm-openai:v0.25.1 
  /models/Qwen3.5-122B-A10B-FP8-dynamic 
  --served-model-name qwen3.5-122b-fp8dyn 
  --tensor-parallel-size 8 
  --max-model-len 262144 
  --gpu-memory-utilization 0.92 
  --max-num-seqs 8 
  --max-num-batched-tokens 4096 
  --disable-custom-all-reduce 
  --enable-prefix-caching 
  --reasoning-parser qwen3 
  --language-model-only 
  --enable-auto-tool-choice 
  --tool-call-parser qwen3_coder 
  --trust-remote-code 
  --host 0.0.0.0 
  --port 8000

Die TP=2-plus-PP=4-Variante verwendete dieselben Modellgewichte und denselben maximalen Kontext, verteilte das Modell jedoch mit --tensor-parallel-size 2 --pipeline-parallel-size 4. Sie lieferte die oben genannten 72,6 tok/s und den deutlich größeren KV-Pool.

Die betriebliche Grenze ist die eigentliche Modellgröße

Nach diesen Versuchen betrachten wir ein Modell nicht mehr als einsatzbereit, sobald sein Server einen großen Kontext reserviert und einen kurzen Prompt schnell beantwortet. Einsatzbereit ist es erst, wenn es unter der vorgesehenen Last weiter brauchbare Entscheidungen trifft: nach vielen Tool-Calls, mit einem großen aktiven KV-Cache, auf der realen PCIe-Topologie und während die Stromversorgung acht Consumer-GPUs durch den gesamten Lauf trägt.

MiniMax M2.7 zeigte uns, dass hoher kurzer Durchsatz und beeindruckende Einzelantworten mit instabilem Langzeitverhalten zusammenpassen können. HY3 isolierte die andere Hälfte des Problems: Ein Modell kann inhaltlich sauber bleiben und an den Decode-Kosten seiner Full-Attention-Architektur scheitern. Qwen machte sichtbar, wie stark wenige Full-Attention-Layer und nur zwei KV-Heads diese Rechnung verändern.

Die Konsequenz ist keine neue Lieblingszahl in einer Benchmarktabelle. Wir wählen das Modell inzwischen nach der Länge und Form der Arbeit aus. Kurze, anspruchsvolle Aufgaben dürfen andere Stärken belohnen als eine sechsstündige Agentensitzung. Und sobald Bewertungen reale Folgen haben, zählt die Rangliste aus dem fünften identischen Lauf mindestens so viel wie die Tokenrate aus dem ersten kurzen Prompt.

Modelle und Engines

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Der erste Kommentar wird manuell freigegeben.