Chimeraforge

Ein lokaler, modell-agnostischer LLM-Bereitstellungsplaner. Er verwandelt „welches Modell, welche Quantisierung, welche GPU und welches Backend – wie viele, passt es, erreicht es mein SLO, was kostet es" in eine schnelle, ehrliche, gemessene Antwort – aus deiner Shell, deinem Python oder deinem KI-Assistenten.

uvx chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"

Das Vertrauensprinzip

Jede Zahl ist als measured, estimated oder unknown gekennzeichnet, und das Tool weigert sich, diejenigen zu fälschen, hinter denen es nicht stehen kann. VRAM und KV-Cache werden aus der realen Architektur eines Modells berechnet (exakt). Durchsatz ist ein gemessener Lookup, wenn verfügbar, andernfalls eine explizite Bandbreiten-Roofline-Schätzung – niemals als Daten präsentiert, die es nicht sind. Qualität unterhalb des gebündelten Korpus meldet unknown, nicht eine erfundene Punktzahl. Ein Plan mit 0 Ergebnissen nennt das genaue Gate, das jeden Kandidaten abgelehnt hat, statt eines generischen „nichts gefunden". Keine Telemetrie, kein Phone-Home, funktioniert air-gapped.

Gib ihm ein Modell – eine Größenklasse, ein Hugging-Face-Repository, ein Ollama-Tag oder manuelle Overrides für ein unveröffentlichtes Modell – und er durchsucht den (Modell x Quantisierung x Backend x GPU-Anzahl x Tensor/Pipeline-Parallelismus)-Raum gegen VRAM, Qualität, Latenz, Kosten, Energie und ein optionales Sicherheits-Gate und gibt dann die günstigste Konfiguration zurück, die dein SLO erfüllt.

12 Befehle, ein Tool: plan - suggest - measure - validate - catalog - safety - bench - eval - compare - refit - report - mcp.

Der empirische Korpus geht auf die Technical Reports TR108-TR137 zurück (~204.000 reale Messungen auf Consumer-GPUs). Siehe CHANGELOG für die vollständige Feature-Historie.

Related MCP server: infra-advisor-mcp

Installation

Teste es ohne Installation:

uvx chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"
pipx run chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"

Richtig installieren:

pip install chimeraforge            # planner + model resolution (HF/Ollama) + suggest/measure/safety/bench
pip install chimeraforge[bench]     # + GPU environment metadata for benchmarks (pynvml)
pip install chimeraforge[mcp]       # + MCP server so Claude/GPT/Cursor can call the planner
pip install chimeraforge[eval]      # + quality evaluation (BERTScore, ROUGE-L)
pip install chimeraforge[refit]     # + coefficient refitting (numpy, scipy)
pip install chimeraforge[all]       # everything

Python 3.10+. Die Kerninstallation umfasst den Planer und die netzwerkfähigen Befehle (httpx ist eine Kern-Abhängigkeit). plan / suggest / catalog laufen vollständig offline; bench / measure / safety benötigen ein laufendes Backend (Ollama, vLLM oder TGI). Windows / macOS / Linux.

Schnellstart

# Plan a registry size class on your GPU
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2.0

# Plan ANY model -- a Hugging Face repo or an Ollama tag
chimeraforge plan --model Qwen/Qwen2.5-7B-Instruct --hardware "RTX 4090 24GB"
chimeraforge plan --model ollama:qwen3:14b --ollama-url http://localhost:11434

# Split a model too big for one GPU across several (tensor parallelism)
chimeraforge plan --model meta-llama/Llama-3.3-70B-Instruct --hardware "H100 80GB" --tp 4

# Shrink the KV-cache, print the cost/latency/quality trade-off menu
chimeraforge plan --model-size 8b --hardware "RTX 4080 12GB" --kv-quant q8 --pareto

# Benchmark a live model and plan on the MEASURED numbers
chimeraforge plan --model qwen3:14b --measure

# Discover + rank what fits your GPU and budget
chimeraforge suggest --source ollama --hardware "RTX 4090 24GB" --budget 500

MCP-Server – gib Claude / GPT / Cursor dieselben Zahlen

GPU-Sizing ist genau der Punkt, an dem Assistenten versagen: Hardware-Preise und -Spezifikationen aus dem Trainings-Cutoff sowie fehleranfällige KV-Cache/Batching-Arithmetik aus dem Gedächtnis. chimeraforge mcp startet einen stdio-MCP-Server, sodass ein Assistent den echten Planer gegen gemessene Daten aufruft, statt zu raten.

pip install "chimeraforge[mcp]"

Claude Code:

claude mcp add --transport stdio chimeraforge -- uvx --from "chimeraforge[mcp]" chimeraforge mcp

Claude Desktop / Cursor (zur MCP-Konfigurationsdatei hinzufügen):

{
  "mcpServers": {
    "chimeraforge": {
      "command": "uvx",
      "args": ["--from", "chimeraforge[mcp]", "chimeraforge", "mcp"]
    }
  }
}

Das --from "chimeraforge[mcp]" zieht das MCP-SDK hinzu; uvx startet den Server in einer eigenständigen Umgebung. Wenn du bereits pip install "chimeraforge[mcp]" in die Umgebung installiert hast, die dein Client startet, kannst du stattdessen "command": "chimeraforge", "args": ["mcp"] verwenden.

Stellt drei Tools bereit: chimeraforge_plan (die vollständige Gate-Suche), chimeraforge_resolve_model (verankert eine Modell-ID in ihren realen Parametern/Architektur) und chimeraforge_list_hardware. Jedes Ergebnis trägt dieselbe measured / estimated / unknown-Herkunft wie die CLI, und die Tool-Beschreibungen sagen dem Modell, diese seinem eigenen Wissen vorzuziehen. chimeraforge_plan gibt außerdem ein launch-Feld zurück – den Serve-Befehl für die empfohlene Konfiguration –, sodass der Assistent „und wie führe ich es aus" beantworten kann, ohne Flags zu erfinden.

Befehle

plan – prädiktiver Kapazitätsplaner

chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2.0
chimeraforge plan --model Qwen/Qwen2.5-7B-Instruct --hardware "RTX 4090 24GB"   # any HF repo
chimeraforge plan --model ollama:qwen3:14b --ollama-url http://localhost:11434  # any Ollama tag
chimeraforge plan --model meta-llama/Llama-3.3-70B-Instruct --hardware "H100 80GB" --tp 4   # multi-GPU
chimeraforge plan --model-size 3b --kv-quant q4 --pareto                       # smaller KV cache, trade-off menu
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --launch          # + the serve command to actually run it
chimeraforge plan --model-size 3b --workload agent --safety-target 0.85 --json

• Plant jedes Modell: Registry-Größenklasse, HF-Repo (org/name), Ollama-Tag oder manuelle Overrides (--params-b/--n-layers/...).

• Durchsucht den (Modell x Quantisierung x Backend x N-Replikate x Batch/GPU)-Raum durch eine 5-Gate-Pipeline: VRAM -> Qualität -> Sicherheit (optional) -> Latenz -> Budget.

• Modelliert reale Serving-Physik: Continuous Batching (vLLM/TGI), Prefill/Decode-Aufteilung (TTFT + TPOT), KV-Cache-gebundene Nebenläufigkeit und varianzbewusstes Queueing (--workload).

• Passt Modelle, die zu groß für eine GPU sind: --tensor-parallel/--tp {N|auto} verteilt Gewichte + KV auf N GPUs (Megatron-Stil, mit Kommunikationsmodellierung); --pipeline-parallel/--pp {N|auto} teilt stattdessen Schichten auf N Stufen auf (günstiger bei langsamen Interconnects, benötigt Batching, um die Pipeline zu füllen). Noch nicht kombinierbar.

• Serviert, was das Backend serviert: GGUF-Quantisierungen werden auf Ollama angeboten; vLLM/TGI erhalten FP16 und FP8 (nur auf GPUs mit FP8-Tensor-Cores – Ada/Hopper/Blackwell/CDNA3). Der Planer schlägt kein GGUF-Checkpoint auf vLLM mehr vor, das mit einem llama.cpp-Speedup bepreist wird.

• KV-Cache-Quantisierung (--kv-quant {fp16,q8,q4}) verkleinert den Cache und erhöht die maximale Nebenläufigkeit – größter Gewinn bei langem Kontext.

• Kostenrealismus (--duty-cycle, --gpu-price-multiplier): Die Schlagzeilen-$/1M-tok-Preise setzen eine gesättigte Flotte voraus. Du zahlst auch für bereitgestellte Reserve und für jede Leerlaufstunde, daher liegt der effektive Wert bei einem 8B bei 2 req/s bei $2,71/1M bei voller Auslastung und $9,04/1M bei 30 %, gegenüber $0,92 bei Kapazität. Spot-/Reserved-Preise sind deine Eingabe, keine gebündelte Schätzung.

• Self-Host vs. API-Break-even (--compare-api): bepreist deine Workload gegen gehostete APIs und meldet das monatliche Volumen, ab dem Self-Hosting sich lohnt. Preise sind ein datierter Schnappschuss mit einer Quell-URL pro Anbieter, nach 90 Tagen als veraltet markiert – niemals als Live-Angebot präsentiert – und ein Frontier-API wird als andere Qualitätsstufe gekennzeichnet, statt als gleichwertig ausgegeben zu werden.

• Prefix-Caching (--prefix-cache-hit-rate): Chatbot- und Agent-Traffic nutzt ein langes System-Prompt wieder, daher ist der meiste Prefill bereits gecacht. Bei einem 4k-Prompt und einer Trefferquote von 90 % sinkt die TTFT eines 8B von 166 ms auf 17 ms. Standardwert 0 und wird nie inferiert, und das KV, das ein gemeinsames Präfix spart, wird bewusst nicht abgezogen – KV zu klein zu dimensionieren ist das, was aus „es passt" einen OOM macht.

• Reasoning-Modelle (--reasoning-tokens N): Versteckte Denk-Tokens werden von der GPU dekodiert und im KV gehalten, auch wenn der Aufrufer sie nie sieht. Nur sichtbare Ausgabe zu zählen, unterschätzt den Decode um das Reasoning-Verhältnis – 1000 versteckte Tokens brachten in unserem eigenen Check einen 8B-Plan von 363 ms auf 6128 ms p95. Standardwert 0 und wird nie inferiert: Das Verhältnis ist eine Eigenschaft deiner Workload, nicht der Gewichte.

• Aufmerksamkeitsform-bewusstes KV: MLA (DeepSeek-V2/V3) cached ein komprimiertes Latent statt K/V pro Kopf – es als GQA zu dimensionieren, überschätzt DeepSeek-V3s Cache um 57x – und Sliding-Window-Modelle stoppen das Cache-Wachstum nach dem Fenster. Ein Fenster, dessen Schichtmuster nicht deklariert ist, wird nicht angewendet, denn KV zu klein zu dimensionieren ist das, was aus „es passt" einen OOM macht.

• Mixture-of-Experts-bewusst: VRAM wird auf Gesamt-Parametern dimensioniert (jeder Experte bleibt resident), während Durchsatz und TTFT aktive Parameter verwenden (ein Token liest nur die Experten, zu denen es geroutet wird). Ein MoE-Modell als dicht zu behandeln, unterschätzt seinen Durchsatz um 3,6x bei Mixtral-8x7B und ~18x bei DeepSeek-V3. Aktive Zählungen werden aus der realen Experten-Geometrie des Modells abgeleitet und stimmen mit veröffentlichten Werten überein.

• Energie (--electricity-rate): monatliche kWh-Kosten, $/1M-tok (+energy) und tok/s-pro-Watt, separat (nicht eingerechnet) zum Budget-Gate gemeldet.

• Launch-Befehl-Export (--launch): gibt den vllm serve / ollama run / TGI docker run-Befehl für die Gewinnerkonfiguration aus, mit der eigenen Kontextlänge des Plans, TP/PP-Grad, Batch-Größe und KV-Datentyp ausgefüllt – die Flags, die fehleranfällig von Hand zu berechnen sind. Es erfindet nichts, was es nicht ableiten kann: Ein GGUF-Quantisierungslevel wird zu einer Notiz, das native äquivalente Checkpoint zu servieren, nicht zu einem erfundenen --quantization-Flag.

• Pro-Vorhersage-Herkunft (measured / estimated / unknown); erklärt das bindende Gate, wenn nichts passt.

• Auf Registry-Daten validiert: VRAM R^2=0,968, Durchsatz R^2=0,859, Qualität RMSE=0,062, Latenz MAPE=1,05 % (schlägt analytisches M/D/1 um 20,4x, TR133). Kein ML – empirische Lookup-Tabellen mit First-Principles-Interpolation (Roofline für Modelle außerhalb der Registry).

suggest – Modelle entdecken & bewerten

chimeraforge suggest --source ollama --hardware "RTX 4090 24GB" --budget 500
chimeraforge suggest --source hf --hf-limit 8 --hardware "RTX 4080 12GB"
chimeraforge suggest --source catalog --hardware "RTX 4080 12GB"   # offline, after `catalog --build`

Zieht Kandidaten aus einem Live-Ollama (/api/tags), dem HF Hub (Top-Textgenerierung) und/oder dem lokalen Katalog; löst jeden zu realen Parametern/Architektur auf, führt dieselbe Gate-Suche aus und zeigt die beste Konfiguration pro Modell.

measure – live benchmarken, mit echten Zahlen planen

chimeraforge measure --model qwen3:14b --ollama-url http://localhost:11434
chimeraforge plan --model qwen3:14b --measure   # measure then plan in one step

Benchmarkt das Live-Modell (echter N=1-Durchsatz, Servicezeit, Nebenläufigkeitsskalierung) und führt es in einen lokalen Korpus ein. plan / suggest bevorzugen dann automatisch die gemessenen Zahlen (Herkunft wechselt zu measured).

catalog – lokaler Modellkatalog

chimeraforge catalog --build         # resolve a curated seed (+ --with-ollama) and cache specs
chimeraforge catalog                 # list the cached catalog

Persistiert aufgelöste Spezifikationen, sodass suggest --source catalog einen bekannten, guten Satz vollständig offline bewertet.

safety – Live-Refusal-Screening

chimeraforge safety --model llama3.2-3b --prompts harmful.txt --quant Q4_K_M --safety-target 0.85

Wo plan --safety-target aus gebündelten TR134/TR142-Daten entscheidet, misst safety: Es führt deine Probe-Prompts gegen ein Live-Modell aus, klassifiziert Refusals (regelbasiert – die TR134-Regex-Baseline), meldet die gemessene Refusal-Rate gegen die gebündelten Gate-Daten (erwartet, Drift, RTSI-Risikostufe) und beendet mit Exit-Code 1 unter --safety-target. Du stellst die Prompts bereit (--prompts, eine pro Zeile) – kein Angriffskorpus wird mit dem Paket ausgeliefert; richte es auf HarmBench / AdvBench / deinen eigenen Satz. Benötigt ein laufendes Ollama.

bench – Live-Inferenz-Benchmarking

chimeraforge bench --model llama3.2-3b --runs 5
chimeraforge bench --model llama3.2-3b --all-quants --context 512,1024,2048,4096 --json
chimeraforge bench --model llama3.2-3b --backend vllm --base-url http://localhost:8000

Drei Workload-Profile (einzeln / Batch / Server-Poisson); misst Durchsatz, TTFT und Latenz mit p50/p90/p95/p99; CV-basierte Stabilitätswarnungen; JSON-Ausgabe.

eval – Qualitätsbewertung

chimeraforge eval --task general_knowledge --json
chimeraforge eval --predictions preds.txt --references refs.txt --model llama3.2-3b

Metriken: Exact Match, ROUGE-L (LCS-Fallback), BERTScore, Kohärenz -> Composite (0.2*EM + 0.3*ROUGE + 0.3*BERT + 0.2*Kohärenz). Qualitätsstufen aus TR125; 3 eingebaute Aufgaben (general_knowledge, summarization, code). Übergib --fp16-baseline, um die Drop-Stufe zu klassifizieren.

compare – Benchmark-Läufe vergleichen

chimeraforge compare --baseline run1.json --candidate run2.json,run3.json --json

Matcht Konfigurationen nach (Modell, Backend, Quantisierung, Workload, Kontextlänge); berechnet Durchsatz-/TTFT-/Dauer-Deltas mit einer aggregierten Verbesserungs-/Regressions-Zusammenfassung.

refit – Planer-Koeffizienten aktualisieren

chimeraforge refit --bench-dir ./results/ --output fitted_models.json --validate

Bayessches Blending (schlüsselweise Konfidenzgewichtung), Hardware-Offsets, Power-Law-Nachanpassung und eine Validierungssuite mit 10 Checks, die den Write absichert (--validate).

report – Berichte generieren

chimeraforge report --results-dir ./results/ --format markdown --output report.md

Markdown (GitHub-kompatibel) und eigenständiges, XSS-sicheres HTML; statistische Analyse (RMSE, MAE, MAPE, R^2) mit Per-Konfiguration-Perzentiltabellen.

mcp – den Planer für KI-Assistenten bereitstellen

chimeraforge mcp

Startet den oben beschriebenen stdio-MCP-Server. Erfordert pip install "chimeraforge[mcp]".

Was modelliert wird

Hardware: 22 GPUs – Consumer-Ada + Blackwell (RTX 30/40/50-Serie), Rechenzentrum (A100 40/80GB, H100, H200, B200, L4, T4) und AMD MI300X – jeweils mit VRAM, Bandbreite, FP16-TFLOPS, TDP und Interconnect (NVLink/Infinity Fabric/PCIe).

Bekannte Grenzen (ehrlich): Speculative Decoding ist noch nicht modelliert. Prefix Caching modelliert die Prefill-Ersparnis, aber nicht die KV-Ersparnis (bewusst konservativ). Reasoning-Tokens werden modelliert, aber das Verhältnis ist Ihre Eingabe (--reasoning-tokens), nie abgeleitet. Bei MoE werden aktive-vs-gesamte Parameter modelliert, aber Expertenparallelismus und Lastverteilungs-Routing sind es nicht. Quant-Abdeckung für vLLM/TGI ist FP16 + FP8 (AWQ/GPTQ noch nicht); FP8-Qualität ist geschätzt, nicht gemessen. TP- und PP-Durchsatz sind kommunikationsmodellierte Schätzungen, nicht gemessen, und können nicht in einem Plan kombiniert werden. Queueing ist analytisch (varianzbewusst), kein diskreter Ereignissimulator. Der gebündelte Korpus ist primär auf einem Rig (RTX 4080 12GB) gefittet; andere GPUs skalieren über Bandbreite/Compute, bis Sie auf Ihrer eigenen messen. Der MCP-Server ist nur stdio-fähig (Claude Code/Desktop, lokaler Cursor) – noch kein gehosteter Remote-Transport.

Was die Forschung entschieden hat

Phase 2 (TR123–TR133, ~106.000 Messungen) destilliert in ein artefaktgestütztes Deployment-Framework – dieselben Regeln, die der Planer anwendet:

Kernergebnisse (volle Daten in den TRs): Rust schlägt Python im Single-Agent-Betrieb (+15,2 % Durchsatz, -58 % TTFT, -67 % Speicher – TR112); duales Ollama erreicht nahezu perfekte Multi-Agent-Parallelität (~99 %) gegenüber 82,2 % auf einer Instanz (TR110/TR113/TR114); vLLMs Continuous Batching bringt einen 2,25-fachen Vorteil bei N=8, begrenzt durch GPU-Speicherbandbreite, nicht durch den Stack (TR130–TR132).

Vollständige Forschung: docs/archive/technical_reports.md indexiert alle 32 Berichte; das vollständige Archiv mit Methodik und Rohdaten-Referenzen liegt in outputs/publish_ready/reports/.

So entstehen die Zahlen

• ~204.000 Primärmessungen über 32 technische Berichte (TR108–TR137 plus die TR142/TR146-Sicherheits-Herkunft), auf einem RTX-4080-Laptop (12 GB). Dedupliziert: TR137/TR142 sind Synthesen bereits gezählter Daten.

• Strenge Methodik: Frischer Prozess pro Lauf (kein Warm-Cache-Bias), erzwungene Kaltstarts, 3–5 Läufe pro Konfiguration für statistische Konfidenz, strukturiertes JSON/CSV-Logging mit vollständiger Herkunft. Jede Behauptung führt auf Rohdaten zurück, die Sie erneut ausführen können.

• Programmkontext: ChimeraForge ist die handlungsorientierte CLI-Variante des übergeordneten Banterhearts-Programms (~1.337.000 Primär- + Judge-Messungen über 54 TRs); die Sicherheits-Angriffsflächen- und Serving-Stack-Forschung lebt in Schwester-Repos.

• 549 automatisierte Tests (pytest tests/) decken die Planer-Modelle, Gate-Suche, Resolver, Discovery, Sicherheit, Bench-Backends und den MCP-Server ab – GPU-entkoppelt, kein Live-Backend für die Kern-Suite erforderlich.

Reproduzieren Sie jede Zahl: Finden Sie die Behauptung in einem Bericht unter outputs/publish_ready/reports/, folgen Sie der Referenz zum Datenordner, prüfen Sie das CSV/JSON und führen Sie die bereitgestellten Skripte oder Notebooks erneut aus. Siehe docs/archive/methodology.md.

Repository-Struktur

Dokumentation

• docs/README.md – Dokumentationsindex und Navigation

• docs/quick_start.md – Erster Benchmark-Lauf (Python + Rust)

• docs/API.md – Python-API-Referenz für das Paket

• docs/archive/technical_reports.md – Index aller 32 technischen Berichte

• docs/archive/dual_ollama_setup.md – Voraussetzungen zur Reproduktion der Multi-Agent-Ergebnisse

• docs/archive/methodology.md / docs/archive/rust_vs_python.md – Methodik und der vollständige Sprachvergleich

Mitwirken

Beiträge willkommen – siehe CONTRIBUTING.md. Gute Bereiche: zusätzliche Benchmark-Konfigurationen, neue Optimierungsstrategien, weitere Modelle/Hardware, Dokumentation und Analysetools.

Lizenz

MIT – siehe LICENSE.

Danksagungen

Durchgeführt im Rahmen des Banterhearts-LLM-Performance-Forschungsprogramms: Phase 1 (TR108–TR122) etablierte die Messmethodik und den sprachübergreifenden Vergleich, Phase 2 (TR123–TR133) erzeugte das Deployment-Framework und den Kapazitätsplaner, und Phase 3 (TR134–TR137) maß die Sicherheitskosten der Inferenzoptimierung – heute das Opt-in-Sicherheitsgate des Planers.

Repository: https://github.com/Sahil170595/Chimeraforge – PyPI: https://pypi.org/project/chimeraforge/ – Status: Beta, aktiv entwickelt