Blog Post 8.1: Llama-70B als Judge – Apple Silicon statt Cloud GPUs

Lesezeit: ~15 Minuten Level: Intermediate
Serie: Self-Hosted LLMs für Datensouveränität Code: GitHub

In Post 8 haben wir Llama-3.1-8B als self-hosted Judge evaluiert: 65% Agreement mit Claude Sonnet 4.5, klare Grenzen bei nuancierten B/C-Ratings. Die Frage blieb offen: Wie viel besser ist ein 8.75× größeres Model?

Der ursprüngliche Plan: Llama-70B auf AWS g5.12xlarge (4× A10G GPUs). Die Realität: Frankfurt komplett ausverkauft, Service Quotas zu niedrig, Wartezeit unbestimmt.

Die Alternative: Llama-3.1-70B lokal auf Mac Studio Max (M4 Max, 64 GB Unified Memory). Kein Deployment, keine Quota-Requests, kein Hourly Billing.

Und nebenbei: Die nächste Stufe der Data Sovereignty. Von self-hosted LLMs auf Cloud-Infrastruktur (Posts 1-8) zu komplett on-premise - keine Daten bei AWS, GCP oder anderen Cloud Providern.

Die Frage: Funktioniert das überhaupt? Und wie schnell kann es wirklich sein?

Spoiler: Ja - und überraschend. Mit optimiertem GPU Offloading: 20 Minuten Runtime für 170 Samples. Schneller als Cloud end-to-end (inkl. 15min Setup). 70% Agreement (vs 64% bei 8B), 6× bessere B-Detection, praktisch nutzbar.

Wichtig: Dieser Post fokussiert sich auf Inference Performance (LLM-as-Judge Evaluations). Training kommt in Post 9.

TL;DR – Für eilige Leser

Setup: Llama-3.1-70B-Q4 via Ollama auf Mac Studio Max (M4 Max, 64 GB RAM), 170 identische Samples wie Post 8

Ergebnisse:

Judge Agreement A-Ratings B-Ratings C-Ratings
Claude Sonnet 4.5 - 110 (64.7%) 50 (29.4%) 10 (5.9%)
Llama-3.1-70B 70.0% 145 (85.3%) 19 (11.2%) 6 (3.5%)
Llama-3.1-8B 64.1% 166 (97.6%) 3 (1.8%) 1 (0.6%)

Kernerkenntnisse:

Empfehlung: Llama-70B auf Apple Silicon mit optimiertem Setup ist schneller als Cloud end-to-end für kurze/mittlere Jobs. Für Production Quality Control: Commercial Judge oder noch größere Modelle.

Inhaltsverzeichnis

AWS sagt Nein: Die Capacity-Realität

Der Plan war simpel: g5.12xlarge Node Group in EKS, vLLM Deployment, 171 Samples in ~10 Minuten evaluieren.

Die Realität:

Launching a new EC2 instance. Status Reason: Could not launch On-Demand Instances. 
InsufficientInstanceCapacity - We currently do not have sufficient g5.12xlarge 
capacity in the Availability Zone you requested (eu-central-1b).

Versuch 2: eu-central-1a, eu-central-1c – gleicher Fehler.

Versuch 3: Service Quota Increase für g5.24xlarge (96 vCPUs statt 48) – 1-3 Werktage Wartezeit, ~$10/h statt ~$5.67/h (g5.12xlarge).

Versuch 4: Spot Instances – benötigt ebenfalls Quota Increase, und erfahrungsgemäß noch schlechter verfügbar als On-Demand.

Der Moment der Erkenntnis: Frankfurt ist ausverkauft. Wir können warten, andere Regionen probieren, oder… einen anderen Weg finden.

Apple Silicon als Alternative

Verfügbare Hardware: Mac Studio Max mit M4 Max Chip, 64 GB Unified Memory.

Die Frage: Reicht das für Llama-3.1-70B (70.5B Parameter)?

Model Size Check (mit Default 131k Context):

Die Lösung: Context Size drastisch reduzieren.

Judge Tasks brauchen wenig Context:

Mit 4k Context:

Setup: Llama-70B auf Mac Studio Max

Ollama Installation & Model Creation

Wichtig: Ollama läuft als Server - alle Commands kommunizieren über http://localhost:11434.

# 1. Ollama installieren
brew install ollama

# 2. Server starten (in eigenem Terminal, läuft dauerhaft)
ollama serve

# 3. In neuem Terminal: Base Model pullen (40 GB Download, ~60 Minuten)
ollama pull llama3.1:70b-instruct-q4_K_M

# 4. Modelfile für 4k Context erstellen
cat > Modelfile-llama70b-4k << 'EOF'
FROM llama3.1:70b-instruct-q4_K_M
PARAMETER num_ctx 4096
PARAMETER num_gpu 81     
EOF

# 5. Model mit kleinem Context erstellen
ollama create llama3.1-70b-4k -f Modelfile-llama70b-4k

Wichtig: num_gpu 81 lädt alle 81 Transformer Layers auf Metal (Apple GPU). Bei initialen Tests hatten wir aus Versehen nur 34 Layers auf GPU geladen - explizites Setzen auf 81 brachte 140% Performance-Gewinn (siehe Performance-Section). Der Default von -1 (auto) hat in unseren Tests auch funktioniert.

Memory Breakdown (tatsächlich, 4k Context):

Model Weights: 39.6 GB (CPU + Metal)
KV Cache: 1.3 GB (4k Context)
Compute Graph: 0.6 GB
Total: ~41.5 GB von 64 GB (22.5 GB frei für System u.a.)

Evaluation Script

Identischer Judge-Prompt wie Post 8, angepasst für Ollama API:

# llm_as_judge_ollama.py
response = requests.post(
    f"{ollama_url}/api/generate",
    json={
        "model": "llama3.1-70b-4k",
        "prompt": combined_prompt,
        "stream": False,
        "options": {
            "temperature": 0.0,    # Identisch zu Post 8 (Claude) für fairen Vergleich
            "num_predict": 300     # Identisch zu Post 8 (Claude) für fairen Vergleich
        }
    }
)

170 Samples (eine missing im Merge):

python3 llm_as_judge_ollama.py \
  --samples all_samples_60x3.jsonl \
  --output llama70b_results.jsonl \
  --model llama3.1-70b-4k

Runtime: 20 Minuten (~7 Sekunden pro Sample)

Ergebnisse: 70% Agreement, 6× bessere Detection

Overall Agreement

Vergleich Agreement Verbesserung
Claude vs Llama-70B 70.0% (119/170) +5.9pp vs 8B
Claude vs Llama-8B 64.1% (109/170) Baseline
Llama-8B vs Llama-70B 87.1% (148/170) Beide immer noch optimistischer als Claude

70% Agreement ist signifikant besser, aber immer noch 15 Prozentpunkte unter einem idealen Drop-in Replacement.

Rating Verteilung

Movement Richtung Claude:

Claude:     ████████████████████████████████ 64.7% A
            ████████████ 29.4% B
            ██ 5.9% C

Llama-70B:  ██████████████████████████████████████████ 85.3% A
            ████ 11.2% B
            █ 3.5% C

Llama-8B:   ████████████████████████████████████████████████ 97.6% A
            █ 1.8% B
            █ 0.6% C

70B findet mehr Probleme als 8B:

Aber immer noch deutlich optimistischer als Claude.

Detection Rates (roh)

B-Rating Detection (Speculation):

C-Rating Detection (Hallucinations, vor manueller Validierung):

Manuelle Validierung: Die 7 False Negatives

Die kritische Frage: Sind die 4 gemissten C-Ratings wirklich Hallucinations?

Methodik: Alle 7 Fälle wo Claude C gab aber Llama-70B nicht (4× A, 3× B) manuell reviewt.

Ergebnis:

Kategorie Count Details
Claude False Positive 2 Zu streng, Answer ist OK
Grenzfall 1 B (Llama) könnte akzeptabel sein
True Hallucination 4 Claude hat Recht, Llama übersah sie

Revidierte C-Detection:

Beispiel: Claude False Positive

Chunk:

Prices are the same across all regions.

Question: “In which AWS regions are prices identical?”

Answer: “Prices are identical across all AWS regions.”

Claude: C – “Answer adds ‘AWS regions’ which is not mentioned in the chunk. The chunk only states ‘all regions’ without specifying AWS, making this a hallucination of specific context not present in the source material.”

Llama-70B: A – “Answer is strictly based on the chunk content, rephrasing it accurately without adding any new information.”

Manuelles Review: ✅ Llama hat Recht. Die Antwort übernimmt “AWS regions” aus der Frage (nicht erfunden), kombiniert mit “all regions” aus dem Chunk. Das ist kontextuelle Präzisierung, keine Hallucination. Claude interpretiert “strictly based on chunk” zu rigide.

Learning: Judge-Prompts müssen differenzieren zwischen echter Hallucination (Info erfunden) und kontextueller Präzisierung (Kontext aus Frage + Info aus Chunk).

Beispiel: True Hallucination (Llama missed)

Question: “Can you reserve Amazon MQ instances?”

Answer: “Reserved instances are available for long-term workloads.”

Chunk: “No, Amazon MQ does not offer reserved instance pricing.”

Claude: C – “Answer contradicts chunk, says reserved instances available when chunk says no”

Llama-70B: A – “Answer based on chunk content”

Manuelles Review: ✅ Claude hat Recht, klare Hallucination.

Learning: Llama-70B übersieht manchmal direkte Widersprüche.

Performance: GPU Offloading als Game Changer

Speed Comparison

vLLM (4× A10G, AWS g5.12xlarge):

Anmerkung: Diese Zahlen sind basierend auf Erfahrungswerten mit vLLM auf ähnlichen GPU-Setups (Posts 5-7), nicht auf g5.12xlarge getestet da keine Capacity verfügbar war.

Ollama (M4 Max, Mac Studio) - Optimiert:

Ratio: vLLM ist ~2-× schneller (reine Inference-Zeit).

GPU Offloading: Der kritische Parameter

Was passierte bei initialen Tests:

Llama-3.1-70B hat 81 Transformer Layers. Bei der ersten Model-Erstellung wurden nur 34 Layers auf Metal geladen.

Initiale Tests (Auto-Detection):

num_gpu: 34/81 Layers (42% GPU Offloading)
→ 58% der Layers auf CPU
→ Runtime: 48min
→ Throughput: ~8 tokens/sec

Warum nur 34? Unser Fehler:

Memory-Analyse zeigte Potenzial:

Optimization:

cat > Modelfile-optimized << 'EOF'
FROM llama3.1:70b-instruct-q4_K_M
PARAMETER num_ctx 4096
PARAMETER num_gpu 81  # Alle Layers auf Metal!
EOF

ollama create llama3.1-70b-4k -f Modelfile-optimized

Ergebnis (Optimiert):

num_gpu: 81/81 Layers (100% GPU Offloading)
→ 0% auf CPU
→ Runtime: 20min ✅ (2.4× schneller!)
→ Throughput: ~20 tokens/sec (2.5× schneller!)
→ Memory: Stabil bei ~54 GB (kein Swap-Stress)

Learning: CPU-Fallback für 58% der Layers kostete 28 Minuten (140% Overhead). GPU Offloading ist ein kritischer Performance-Parameter für Apple Silicon. Maximale Layers austesten!

End-to-End Zeiten in der Praxis

Die 2-4× Speed-Differenz gilt nur für reine Inference-Zeit. Real-world ist komplexer:

Scale-to-Zero Cloud (Argo/EKS):

Für unseren Use Case (170 Samples):

ABER: Capacity ist nicht garantiert.

Wie wir am Anfang gesehen haben: Frankfurt komplett ausverkauft. In solchen Fällen:

Mac Studio: Immer verfügbar. Kein Warten, kein Quota-Management, kein “InsufficientCapacity”. $0/h.

Trade-offs:

Warum überraschend schnell?

Unified Memory Advantage:

Metal Optimizations:

Der CPU-Bottleneck Killer:

Trade-off Analyse

Wann macht Apple Silicon Sinn:

Pros:

Cons:

Für diesen Test: Ideal. 20min statt 25min, $0 statt $1-2, garantierte Verfügbarkeit, und vollständige Data Sovereignty.

Die Hybride Strategie

Für Production könnte das funktionieren:

1. Llama-70B Pre-Filter (lokal)
   ↓ Findet ~60-75% der Probleme
   ↓ Cost: $0
   
2. Claude Final Review (Cloud)
   ↓ Nur auf flagged Samples (~15%)
   ↓ Cost: 85% Reduktion vs Full Claude
   
3. Manual Spot-Check (10%)
   ↓ Ground Truth Validation

Best of Both Worlds: Cost-Efficiency + Quality Assurance.

Wichtiger Caveat für Data Sovereignty:
Diese hybride Strategie sendet ~15% der Samples an Claude (Cloud). Wenn vollständige Data Sovereignty erforderlich ist:

Trade-off: Quality vs. Data Sovereignty muss bewusst entschieden werden.

Code & Resources

GitHub Repository: self-hosted-llms-tutorial

Scripts für diesen Post:

Setup Llama-70B auf Apple Silicon

# 1. Ollama installieren
brew install ollama

# 2. Server starten (in eigenem Terminal)
ollama serve

# 3. In neuem Terminal: Base Model laden
ollama pull llama3.1:70b-instruct-q4_K_M

# 4. Model mit 4k Context UND optimiertem GPU Offloading erstellen
cat > Modelfile << 'EOF'
FROM llama3.1:70b-instruct-q4_K_M
PARAMETER num_ctx 4096
PARAMETER num_gpu 81
EOF

ollama create llama3.1-70b-4k -f Modelfile

# 5. Evaluation laufen lassen (in weiterem Terminal)
python3 llm_as_judge_ollama.py \
  --samples your_samples.jsonl \
  --output results.jsonl \
  --model llama3.1-70b-4k

Requirements: Mac mit Apple Silicon (M1/M2/M3/M4), mindestens 64 GB RAM

Wichtig: num_gpu 81 lädt alle Layers auf Metal. Auto-Detection (num_gpu: -1, default) hat in unseren Tests auch funktioniert. Sie richtige Einstellung verhindert Performance-Verlust!

Fazit

Llama-3.1-70B auf Apple Silicon ist keine Notlösung, sondern eine überraschend starke Alternative - schneller als Cloud für typische Use Cases, $0 Cost, und vollständige Data Sovereignty.

Was wir erreicht haben:

Die klaren Grenzen:

Was wir gelernt haben:

  1. Model Size hilft, aber ist keine Silver Bullet – 8.75× größer ≠ 8.75× besser
  2. Consumer Hardware mit richtiger Config ist stark – schneller als Cloud für Jobs <2h, garantierte Verfügbarkeit, aber: GPU Offloading kritisch!
  3. Manuelle Validierung ist essentiell – auch Claude macht Fehler (2/10 False Positives)
  4. Hybride Strategien möglich, aber Trade-off – 70B Pre-Filter + Claude Final Review = Cost-Efficiency + Quality, aber nur mit anonymisierten Daten wenn Data Sovereignty wichtig ist
  5. Prompt Engineering Potential in beide Richtungen – Llama’s False Negatives UND Claude’s False Positives zeigen konkrete Verbesserungs-Ansätze
  6. GPU Offloading ist DER kritische Parameter – Auto-Detection kann konservativ sein, explizites Setzen auf maximale Layers brachte 140% Performance-Gewinn!

Data Sovereignty erreicht die nächste Stufe – von self-hosted LLMs auf Cloud-Infrastruktur (Posts 1-8) zu komplett on-premise. Schneller als Cloud für typische Jobs, $0 Cost, immer verfügbar ohne Capacity-Probleme oder Quota-Management, und jetzt auch ohne Cloud Provider für die Daten selbst.

Wichtige Einschränkung: Dieser Post fokussiert sich auf Inference Performance. Die überraschend gute Performance wirft aber die Frage auf: Wie sieht’s mit Training aus? Könnte LoRA Fine-Tuning aus Post 5 auch lokal auf Mac Studio laufen? Das schauen wir uns in Post 9 an.

Im nächsten Post: Multi-LoRA A/B Testing - Adapter-Iteration basierend auf Evaluation-Feedback. Wie verbessern wir die Performance durch gezieltes Re-Training mit problematischen Patterns?

Ausblick: Für Production Deployment (Argo Workflows, Monitoring, CI/CD) planen wir eine separate Blog-Serie, da diese Themen generisch für alle ML-Pipelines gelten, nicht nur für Self-Hosted LLMs.

← Post 8: Llama-3.1-8B Judge | Serienübersicht | Post 9: Multi-LoRA A/B-Testing →