Für Hardware- und Speicherleitplanken bei lokalen Läufen verweisen wir auf die MLX-LM- und Transformers-Matrix auf dem M4; für konsistente Span-Felder und Sampling-Grenzen auf die OpenTelemetry-GenAI-Observability-Matrix. Retrieval-lastige Evals ordnet ihr parallel zur lokalen RAG-Matrix ein, ohne die Offline-Splits zu vermischen.
Entscheidungsmatrix · Schwellen und Ressourcen · Ausführbarer Ablauf · FAQ
Die häufigsten Brüche sind dreifach: 1) Optimizer und Eval teilen sich Zufall und Datenstand — Regressionen sind nicht reproduzierbar. 2) Primärmetrik steigt, aber Constraint-Verletzungen oder Tail-Latenzen explodieren im produktionsnahen Profil. 3) Das Notebook zeigt Durchsatz, der dedizierte Remote-Knoten mit gleicher Konfiguration aber nicht — Budget und Abnahme basieren auf falschen Annahmen. Dieser Text ersetzt keine Produkt-Dokumentation von DSPy; er strukturiert Abnahme und Kosten für Apple-Silicon-Teams.
Zusätzlich lohnt eine klare Rollentrennung: Wer Prompts „compiliert“, darf nicht dieselben Daten sehen wie das unabhängige Review-Team, das das Offline-Set freigibt — sonst schleichen sich optimistische Labels ein. Für Sicherheit und Nachvollziehbarkeit sollten Artefakte signiert oder mindestens über reproduzierbare Builds erzeugt werden; so lassen sich Abweichungen zwischen Laptop und Remote-Host auf Konfiguration statt auf Magie zurückführen. Ein kurzer Smoke-Test vor dem Soak verhindert, dass teure Nachtläufe an einem falschen Checkpoint scheitern.
Entscheidungsmatrix: Phase, Ziel und Risiko
Trennt bewusst Compiler- bzw. Optimizer-Phasen von deterministischen Replay-Läufen. Teacher-Aufrufe und teure Suche gehören nicht in jeden Merge-Request.
| Phase | Ziel | Typische Budgets | Risiko ohne Gate |
|---|---|---|---|
| Lokal — Compile / Optimizer | Signaturen schärfen, Demonstrationen erzeugen | Hohe CPU-Zeit; manuelle Freigabe | Prompt drift, nicht committete Zwischenstände |
| CI — Offline-Replay | Eingefrorene Prompts gegen fixes Eval-Set | Enges Wall-Clock-Budget; feste Seeds | Flaky Tests bei Daten- oder Modell-Drift |
| Abnahme — Remote-Soak | Gleiche Manifeste auf gemietetem Mac | Mindestens zehn Minuten Lastfenster | Notebook schneller als Produktionsknoten |
Schwellen, Ressourcen-Deckel und Kostenzeile
Die Tabelle ist bewusst ordinal: absolute Zahlen hängen von Modellfamilie, Quantisierung und Kontext ab. Ersetzt Platzhalter durch eure Messreihen und dokumentiert Thermik parallel zu Speicher.
| Metrik | Beispiel-Gate | Apple-Silicon-Hinweis | Kostenfeld Remote |
|---|---|---|---|
| Primärqualität | Mindest-Score vs. Baseline-Prompt | Gleiche Gewichte und Tokenizer-Revision | Tokens pro Stunde × Tarif |
| Constraint-Rate | Obergrenze für Verletzungen pro Split | Keine stillen Truncates im Harness | Zusatzläufe bei Retries |
| Tail-Latenz | p95/p99 bis zum ersten Token | Unified Memory: KV und GUI konkurrieren | Egress nur wenn Logging extern |
| Ressource | CPU-Minuten und RAM-Peak dokumentiert | Swap vermeiden; Soak > Einzelrun | Stundenmiete plus Storage-Snapshot |
Ausführbarer Ablauf in fünf Blöcken
1) Manifest: Jeden Offline-Split mit Hash, Zeilenzahl und Lizenz veröffentlichen; keine stillen Nachimports. 2) Signatur: DSPy-Module als Code versionieren; Optimizer-Runden und Teacher-Budget explizit deckeln. 3) Harness: Pro Beispiel Score, Verletzungsflags und Latenz in einen JSON-Report schreiben; Seeds und Modellpfad im Kopf. 4) Gates: Build bricht bei Schwellenverletzung ab; Management sieht nur die vier Kennzahlen aus dem FAQ-Block. 5) Remote: Identische Umgebung auf einem Miet-Mac mit dokumentiertem Stundenbudget — Vergleich mit lokalem Notebook nur als Hinweis, Abnahme nachhaltige Tokens und Tail auf dem Knoten.
Ergänzend: Legt für jeden Lauf ein Run-Label fest (Git-Commit, Container-Image oder Conda-Env-Hash), damit Auditoren dieselbe Kombination nachstellen können. Dokumentiert bewusst, ob Metal, MPS oder CPU-Fallback aktiv war — sonst vergleicht ihr Äpfel mit Birnen. Wenn ihr mehrere Modelle parallel testet, serialisiert die Jobs oder nutzt strikt getrennte Prozesse, damit Unified Memory nicht durch einen zweiten Worker unbemerkt kollabiert.
Telemetrie-Attribute und Kardinalitätsgrenzen nach der GenAI-Observability-Matrix begrenzen, damit Offline-Run-IDs später mit Produktionsspuren joinen. Grenzwerte gelten erst nach zehn Minuten Soak, nicht nach einem Kurzlauf.
Umgebungs- und Repro-Platzhalter (anpassen):
# Offline-Eval — Seeds und Pfade fixieren
export PYTHONHASHSEED=0
export DSPY_CACHE_DIR=/var/tmp/dspy-eval-cache
export MODEL_PATH=/pfad/zu/gewichten
export EVAL_MANIFEST_SHA256=bitte_eintragen
python run_offline_eval.py \
--manifest eval/manifest.json \
--out reports/eval-$(date +%Y%m%d-%H%M).json \
--seed 42 --max-optimizer-rounds 0- Zitierbar 1: Trennt Prefill- und Decode-Tokens in Logs — sonst verschwinden KV-Effekte im Mittelwert.
- Zitierbar 2: Jede Abnahme nennt Manifest-Hash, Modell-Checkpoint und Tokenizer-Revision in einer Zeile.
- Zitierbar 3: Remote-Kostenzeile enthält Stundenmiete, geschätzte Tokens pro Stunde und Euro pro Million Tokens inklusive Fixkostenanteil.
FAQ
Soll Optimierung in jeder CI-Pipeline laufen? Nein — schwere Compiler-Läufe bleiben geplant; die CI spielt eingefrorene Prompts gegen das Offline-Set.
Warum schlägt der Remote-Mac langsamer zu sein als das lokale Book? Netz, Hintergrunddienste und thermische Grenzen; die Abnahme gilt für den gemieteten Knoten.
Wie vermeidet ihr Vermischung mit RAG-Evals? Separate Manifeste und keine geteilten Embeddings ohne Versionspin — siehe lokale RAG-Matrix.
Welche Artefakte sind für Finance und Engineering gemeinsam lesbar? Ein JSON-Report mit Manifest-Hash, Stundenkosten, Tokens pro Stunde und einem booleschen Gate-Status pro Metrik — ohne Rohprompts in Klartext, wenn Richtlinien das verbieten.
Kurz: DSPy liefert Struktur, Offline-Gates liefern Vertrauen, Remote-Soak liefert Wirtschaftlichkeit auf Apple Silicon. Ohne Manifest und Metrik-Deckel bleibt Prompt-Optimierung ein Workshop-Trick — mit ihnen wird sie abnahmefähig.