Coding-Agenten, die vor dem Implementieren recherchieren, finden bessere Lösungen als solche, die sofort Code schreiben. Das klingt trivial, ist aber ein fundamentaler Unterschied im Agent-Design: Die meisten Coding-Agent-Workflows beginnen mit Codeanalyse und enden mit Code-Änderungen. SkyPilot hat an llama.cpp demonstriert, dass eine vorgelagerte Recherche-Phase -- Papers lesen, konkurrierende Projekte studieren, alternative Implementierungen analysieren -- den Unterschied zwischen marginalen und signifikanten Verbesserungen ausmacht.
Das Experiment
Ziel war die Optimierung der CPU-Inferenzgeschwindigkeit von llama.cpp (TinyLlama 1.1B). Der Agent arbeitete in einem strukturierten Fünf-Phasen-Workflow:
- Research: Papers und konkurrierende Projekte studieren
- Analyse: CUDA- und Metal-Backends vergleichen, um Muster zu identifizieren
- Hypothesen bilden: Aus den Erkenntnissen konkrete Optimierungsideen ableiten
- Experimentieren: Änderungen implementieren und benchmarken
- Validieren: Ergebnisse gegen Baseline prüfen
Das Setup war schlank: ein Ziel-Repository mit Benchmark, eine experiment.yaml (SkyPilot-Template für die Cloud-VM-Orchestrierung) und eine instructions.md mit dem Forschungsauftrag.
Ergebnisse
Von über 30 Experimenten waren 5 erfolgreich -- eine Trefferquote von unter 17%. Die erfolgreichen Optimierungen waren aber substantiell:
| Plattform | Textgenerierung | Prompt Processing |
|---|---|---|
| x86 | +15,1% | +1,2% |
| ARM | +5,0% | +1,9% |
Die Gesamtkosten lagen bei rund $29 ($20 für VMs, $9 für API-Calls) bei einer Laufzeit von etwa drei Stunden.
Welche Optimierungen funktionierten
Die fünf erfolgreichen Änderungen folgten einem gemeinsamen Muster: Sie reduzierten Speicherdurchläufe statt Rechenoperationen.
- Softmax Fusion: Drei separate Speicherdurchläufe (Subtract Max, Exp, Normalize) zu einem einzigen verschmolzen
- RMS Norm Fusion: Ähnliches Prinzip bei der Normalisierung
- Adaptive Parallelisierung: Thread-Scheduling an die tatsächliche Workload angepasst
- Graph-Level Fusion: Optimierung auf der Berechnungsgraph-Ebene statt auf Einzeloperationen
- Flash Attention KQ Fusion: Key-Query-Multiplikation mit Attention-Berechnung verschmolzen
Das kritische Learning: Domänenwissen von außen
Ohne die Recherche-Phase verfolgte der Agent Mikro-Optimierungen mit Verbesserungen von 0,6 bis 0,9%. Erst das Verständnis eines zentralen Zusammenhangs aus externer Recherche führte zum Durchbruch: Textgenerierung bei CPU-Inferenz ist memory-bandwidth-bound, nicht compute-bound. Der Agent musste also Speicherzugriffe reduzieren, nicht Rechenoperationen beschleunigen.
Dieses Wissen steckte nicht in der llama.cpp-Codebase. Es steckte in Papers, in Diskussionen um CUDA-Backends und in der Architektur konkurrierender Projekte. Ohne externen Kontext blieb der Agent in einem lokalen Optimum gefangen.
Was funktionierte und was nicht
Produktiv: Konkurrierende Projekte studieren war ergiebiger als ArXiv-Suche. Die Cross-Backend-Analyse -- also der Vergleich, wie dasselbe Problem in CUDA, Metal und CPU gelöst wird -- zeigte Patterns, die in einer einzelnen Implementierung unsichtbar sind. Wenn das CUDA-Backend eine Fusion bereits hat, die CPU-Implementierung aber nicht, ist das ein direkter Hinweis auf eine fehlende Optimierung.
Gescheitert: 25 von über 30 Experimenten brachten keine Verbesserung. Die häufigsten Ursachen:
- Der Compiler optimierte die Änderung bereits selbst weg
- Benchmark-Fehler propagierten und täuschten Verbesserungen vor
- Cloud-VM-Varianz von bis zu 30% machte kleine Gewinne unmessbar
- Theoretisch korrekte Optimierungen, die in der Praxis an Cache-Effekten scheiterten
Übertragung auf den eigenen Workflow
Das Pattern ist nicht llama.cpp-spezifisch. Es lässt sich auf jeden Coding-Agent-Workflow übertragen:
- Vor der Implementierung: Den Agenten anweisen, nicht nur die eigene Codebase zu analysieren, sondern wie andere das gleiche Problem gelöst haben. Konkurrierende Projekte, Stack-Overflow-Diskussionen, relevante Papers.
- Domänenwissen explizit machen: Wenn der Agent nicht weiß, dass ein Problem I/O-bound statt CPU-bound ist, wird er die falschen Optimierungen versuchen. Dieses Wissen muss von außen kommen.
- Fehlerquote einplanen: Unter 17% Trefferquote ist kein Versagen, sondern der Normalfall bei Optimierung. Das Experiment-Setup muss günstig genug sein, damit sich das lohnt -- $29 für 15% Speedup ist ein guter Trade.
- Cross-Projekt-Analyse: Äquivalente Implementierungen in anderen Sprachen, Frameworks oder Backends vergleichen. Patterns, die dort existieren, aber im eigenen Code fehlen, sind die wertvollsten Hinweise.
Der Kern ist einfach: Ein Coding-Agent braucht Domänenwissen, das nicht in der Codebase steckt. Recherche vor Implementierung ist kein Luxus, sondern der Unterschied zwischen lokalen und globalen Optima.