MiniMax M2.7 Q8_0 128K auf 2x3090 mit CPU-Offloading – Benchmarks und Konfiguration aus der Praxis

In einem aktuellen r/LocalLLaMA-Beitrag berichtet ein Benutzer von seinen Erfahrungen mit dem MiniMax M2.7-Modell (in Q8_0-Quantisierung) bei 128K Kontext auf einem 2x3090-Setup mit 256 GB DDR4 und einer gebrauchten 10900X-CPU. Die größte Herausforderung: ein großes MoE-Modell mit unquantisiertem KV-Cache auf relativ schwacher Hardware für diese Klasse auszuführen.
Leistungszahlen
Der Benutzer berichtet:
- Prompt-Verarbeitung: ~50 Tokens pro Sekunde
- Token-Generierung: ~10 Tokens pro Sekunde
- Beschrieben als „sehr langsam, aber für Coding-Agent-Workflows nutzbar“
Konfiguration
Er verwendet ik-llama-cuda (einen llama.cpp-Fork) mit den folgenden Flags (aus seiner NixOS-Konfiguration):
${ik-llama-cuda}/bin/llama-server \
-m ${modelPath} \
--host 0.0.0.0 \
--port ${toString cfg.port} \
-c ${toString cfg.contextLength} \
-ngl 999 \
--cpu-moe \
-sm graph \
-fa on \
-t 16 \
-tb 16 \
-b 4096 \
-ub 4096 \
-np 1 \
-muge \
-ger \
--jinja \
--metrics \
--temp 1.0 \
--top-p 0.95 \
--top-k 40 \
--min-p 0.01Bemerkenswerte Flags:
--cpu-moe– verlagert MoE-Expertenberechnungen auf die CPU-sm graph– aktiviert grafikbasiertes Scheduling-fa on– Flash Attention-t 16/-tb 16– 16 Threads für Berechnung bzw. Batch-b 4096/-ub 4096– Batch- und Ubatch-Größe-muge– speichernutzungsgesteuertes Expertenladen (vermutlich)-ger– GPU-Experten-Routing
Kontext & Motivation
Der Benutzer gibt an, dass Q8_0 gewählt wurde, um „seltsames Verhalten“ bei niedrigeren Quantisierungen zu vermeiden. Er merkt an, dass das Draft-Modell des Modells für spekulative Dekodierung nicht für M2.7 veröffentlicht wurde, was die Geschwindigkeit hätte verbessern können. Ihm geht es hauptsächlich um Genauigkeit statt Geschwindigkeit, solange die Generierung nicht „buchstäblich den ganzen Tag“ dauert.
Fazit für Entwickler
Dies ist ein praktischer Datenpunkt für alle, die große MoE-Modelle auf Multi-GPU-Setups mit System-RAM betreiben. Der --cpu-moe-Ansatz ermöglicht es, den Kontext weit über die VRAM-Grenzen hinaus zu skalieren, wenn auch mit reduzierter Geschwindigkeit. Für Coding-Agent-Workflows, bei denen Latenz weniger kritisch ist, kann dieser Kompromiss akzeptabel sein.
📖 Lese die vollständige Quelle: r/LocalLLaMA
👀 Siehe auch

OpenClaw auf M4 Pro: An Grenzen stoßen mit Browser-Nutzung, Computer-Nutzung und Codex
Ein Benutzer berichtet, dass Agents in Endlosschleifen stecken, auf Websites blockiert werden und Codex-Ausgaben fehlerhaft sind. Er sucht nach Konfigurationsanpassungen für den Automatisierungsbrowser, macOS-GUI-Steuerung und Unterbrechungsschleifen.

Hohe CPU/RAM-Auslastung und Gateway-Neustarts in OpenClaw? IPv6 für Telegram deaktivieren
Wenn Sie in Ihrem Telegram-Bot-Konfiguration autoSelectFamily: false und dnsResultOrder: 'ipv4first' setzen, werden ENETUNREACH-Fehler vermieden, die hohe CPU-Auslastung, Event-Loop-Einfrierungen und Gateway-Neustarts verursachen.

Biss- vs. Knabber-Ansätze für KI-Codierungsagenten
Ein NLP-Forscher erklärt zwei mentale Modelle für die Arbeit mit KI-Codierungsagenten: den 'Biss'-Ansatz mit umfassenden Anleitungsdateien wie claude.md und den 'Knappern'-Ansatz mit schrittweiser Verbesserung durch mehrere Durchgänge.

Jeden MCP-Server bei jeder Eingabeaufforderung zu laden, zerstört leise das Token-Budget
Ein Benutzer mit 5–6 MCP-Servern stellte fest, dass jeder Prompt alle Server lud, was zu massiver Token-Verschwendung führte. Die Implementierung einer Routing-Schicht, die nur die relevanten Server pro Prompt lädt, reduzierte den Token-Verbrauch drastisch und verbesserte die Antwortzeiten.