Ich habe Karpathys Autoresearch auf einem MacBook für 1.299 Dollar ausgeführt – das ist dabei herausgekommen
Karpathys Autoresearch auf einem M2 MacBook Pro: Reale Zahlen, reale Grenzen
Was passiert, wenn man eine KI-Forschungsinfrastruktur mit 700 Experimenten auf einem 2.000-Dollar-Laptop statt auf einem 80.000-Dollar-GPU-Cluster ausführt?
14 Min. Lesezeit | KI-Entwicklung & ML-Experimente
Als Andrej Karpathy am 7. März 2026 autoresearch veröffentlichte, war die Prämisse unwiderstehlich: ein autonomer Agent, der ML-Experimente in einer Schleife entwirft, durchführt und auswertet. Ein Problem eingeben, schlafen gehen und mit einem besseren Modell aufwachen. Er führte in zwei Tagen 700 Experimente auf einem H100 durch, fand 20 Verbesserungen und erzielte eine Geschwindigkeitssteigerung von 11 %. Shopify-CEO Tobi Lutke ließ es über Nacht mit Unternehmensdaten laufen und erzielte einen Gewinn von 19 %. Das Repo überschritt 21.000 GitHub-Sterne, noch bevor die meisten Leute die README-Datei zu Ende gelesen hatten.
Ich habe keinen H100. Ich habe ein M2 MacBook Pro mit 16 GB Unified Memory. Also tat ich, was jeder vernünftige Ingenieur tun würde: Ich führte die Experimente trotzdem durch und maß alles.
Dieser Beitrag enthält den vollständigen Bericht. Zwei Community-Forks, fünf Stabilitätsläufe, eine Agent-Schleife mit vier Experimenten und eine Kostenanalyse, die erklärt, warum dies selbst bei einer ~96-fachen Verlangsamung gegenüber einem H100 von Bedeutung ist. Jede Zahl hier stammt aus tatsächlichen Läufen auf meinem Rechner.
🧪 Der Aufbau: Zwei Forks, zwei Ansätze
Die ursprüngliche Codebasis von Autoresearch zielt auf CUDA ab. Sie läuft auf Apple Silicon nicht ohne Weiteres. Doch innerhalb weniger Tage nach der Veröffentlichung produzierte die Community zwei macOS-Forks, die jeweils einen anderen Ansatz für das Portabilitätsproblem verfolgten.
MLX-Fork (thenamangoyal/autoresearch)
Dieser Fork schreibt die Trainingsschleife in MLX neu, Apples nativem ML-Framework für Apple Silicon. MLX arbeitet direkt auf der Unified-Memory-Architektur – ohne Treiber-Übersetzungsschicht, ohne CPU-Fallback. Die Modellarchitektur ist ein kompaktes Netzwerk mit 11,5 Millionen Parametern: Tiefe 4, 256 Einbettungsdimensionen, 2 Attention-Heads, unter Verwendung von SSSL-Attention (eine für kleine Modelle optimierte Sliding-Window-Variante).
MPS-Fork (miolini/autoresearch-macos)
Dieser Fork behält PyTorch bei, leitet die Berechnungen jedoch über Apples Metal Performance Shaders (MPS)-Backend. Er verwendet eine andere Architektur: Full-Context-Attention (mit dem Label „L“), den Muon + AdamW-Optimierer und trainiert in float32. Das Modell unterscheidet sich architektonisch so stark, dass direkte Leistungsvergleiche zwischen den Forks irreführend sind – was an sich schon eine interessante Erkenntnis ist.
Der Einstieg in den MLX-Fork dauert etwa zwei Minuten:
curl -LsSf https://astral.sh/uv/install.sh | sh git clone https://github.com/thenamangoyal/autoresearch.git && cd autoresearch uv sync uv run prepare.py uv run train.py
Das war’s. Kein CUDA-Toolkit, kein Treiber-Debugging, keine Docker-Container. uv löst die Abhängigkeiten auf, prepare.py lädt den Datensatz herunter und tokenisiert ihn, und train.py führt eine vollständige Trainingsschleife aus. Die gesamte Pipeline von der Einrichtung bis zum ersten Ergebnis dauert weniger als fünf Minuten.
🔬 Kopf-an-Kopf: MLX vs. MPS auf derselben Hardware
Ich habe beide Forks auf demselben Rechner unter identischen Bedingungen ausgeführt. Hier sind die Zahlen.
| Metrik | MLX-Fork | MPS-Fork |
|---|---|---|
| val_bpb | 2,352 | 1,773* |
| tok/sec (Steady State) | ~17.000–18.000 | ~14.000–15.000 |
| Schritte in 5 Min. | 81 | 76 |
| Spitzen-Speicherbedarf | 11.024 MB (~10,8 GB) | Ähnlich |
| Gesamtlaufzeit | 5 min 40 s | 13 min 27 s |
| Trainingszeit | 302 s | 302 s |
| Auswertungszeit | 30 s | 505 s |
| Kompilierungsaufwand | 4 s | N/A |
| MPS-CPU-Fallback-Warnungen | N/A | 0 |
| Präzision | Gemischt | float32 |
| Attention-Typ | SSSL (Sliding Window) | Vollkontext „L“ |
| Optimierer | Standard | Muon + AdamW |
*Der niedrigere val_bpb-Wert des MPS-Fork ist NICHT direkt vergleichbar – er verwendet eine grundlegend andere Architektur, einen anderen Optimierer und einen anderen Aufmerksamkeitsmechanismus. Der Vergleich dieser beiden Zahlen wäre so, als würde man die Rundenzeiten eines Go-Karts und einer Limousine auf unterschiedlichen Rennstrecken vergleichen.
Was uns die Zahlen verraten
Durchsatz. MLX ist beim reinen Token-Durchsatz etwa 20 % schneller (17–18K gegenüber 14–15K Token/Sek.). Das macht Sinn – MLX kommuniziert direkt mit Apple Silicon, ohne die MPS-Übersetzungsschicht. Bei keinem der beiden Forks gibt es Warnungen wegen CPU-Fallback, was bedeutet, dass beide wirklich GPU-beschleunigt sind.
Reale Zeit. Der MLX-Fork ist in 5 Minuten und 40 Sekunden fertig. Der MPS-Fork benötigt 13 Minuten und 27 Sekunden. Die Trainingsphase ist identisch (302 Sekunden), doch bei der Auswertung gibt es einen dramatischen Unterschied: 30 Sekunden bei MLX gegenüber 505 Sekunden bei MPS. Die Auswertungs-Pipeline des MPS-Forks ist der Engpass – sie ist 16-mal langsamer als die von MLX. Bei einer Agent-Schleife, die Dutzende von Experimenten durchführt, vergrößert sich dieser Abstand noch. Mit MLX lassen sich pro Stunde etwa 2,4-mal mehr Experimente durchführen.
Speicher. Mit einem Spitzenwert von 10,8 GB beansprucht der MLX-Fork den größten Teil des 16 GB großen einheitlichen Speichers. Das ist knapp bemessen. Sie werden nebenbei keinen Browser mit 40 Tabs, Slack und Spotify laufen lassen können. Schließen Sie alles Unwichtige, bevor Sie den Fork starten.
Stellen Sie sich den MLX-Fork wie ein Formel-E-Auto vor – speziell für die Rennstrecke entwickelt, auf der es fährt. Der MPS-Fork ist eher so, als würde man Standard-PyTorch über einen Kompatibilitäts-Shim laufen lassen. Beide funktionieren. Der eine ist nativ.
🔁 Stabilität: Kann man Nachtläufen vertrauen?
Bevor ich die Kontrolle für eine ganze Nacht an einen Agenten übergab, musste ich eine Frage beantworten: Wird das Ding um 3 Uhr morgens abstürzen?
Ich habe den MLX-Fork fünf Mal hintereinander ausgeführt. Gleiche Konfiguration, gleiche Startbedingungen, direkt nacheinander. Hier sind die Ergebnisse.
| Lauf | val_bpb | Spitzen-Speicherverbrauch | Gesamtlaufzeit |
|---|---|---|---|
| 1 | 2,291 | 11.024 MB | 5m 37s |
| 2 | 2,355 | 11.024 MB | 5m 38s |
| 3 | 2,320 | 11.024 MB | 5m 36s |
| 4 | 2,347 | 11.024 MB | 5m 37s |
| 5 | 2,308 | 11.024 MB | 5m 38s |
val_bpb-Streuung: 0,064 (2,291 bis 2,355)
Speicher: konstant 11.024 MB über alle Durchläufe hinweg. Kein Speicherleck. Der Allokator verhält sich vorbildlich – der Speicherverbrauch steigt während des Trainings an und geht danach sauber wieder zurück. Dies ist für Übernacht-Läufe von enormer Bedeutung. Ein langsames Speicherleck, das pro Experiment 100 MB hinzufügt, würde den Rechner nach 50 Durchläufen zum Absturz bringen.
Realtime: konstant ~5m 37s. Keine thermische Drosselung. Der M2 lief bei allen fünf Durchläufen mit konstanter Geschwindigkeit. Das hat mich überrascht – anhaltende Rechenlasten auf Laptops zeigen oft eine Leistungsminderung, wenn sich das Gehäuse erwärmt. Das thermische Design des M2 bewältigt diese Rechenlast ohne Drosselung.
Keine Abstürze. Keine NaN-Werte. Jeder Lauf wurde fehlerfrei abgeschlossen und lieferte gültige Metriken.
Das Fazit: Der MLX-Fork ist stabil genug für unbeaufsichtigte Übernachtläufe. Ich schätze, man kann sicher mehr als 100 Experimente ohne Eingreifen hintereinander ausführen. Die einzige Einschränkung ist die Stromversorgung – schließe das Ladegerät an.
🤖 Die Agent-Schleife: Vier Experimente, eine Frage
Hier wird es interessant. Der Sinn von Autoresearch besteht nicht darin, einen einzelnen Trainingsjob auszuführen – vielmehr soll ein Agent Modifikationen vorschlagen, Experimente durchführen, Ergebnisse bewerten und entscheiden, was beibehalten werden soll. Ich habe mithilfe des MLX-Fork eine Schleife mit vier Experimenten eingerichtet, um zu testen, ob ein Mac sinnvoll an diesem Optimierungszyklus teilnehmen kann.
Baseline: val_bpb = 2,559
Der Agent generierte vier Hypothesen:
Experiment 1: Full-Context-Attention „L“
Hypothese: Das Ersetzen der SSSL-Sliding-Window-Attention durch Full-Context-Attention könnte Abhängigkeiten über größere Entfernungen erfassen.
Ergebnis: val_bpb = 2,582 (um 0,023 schlechter)
Entscheidung: VERWERFEN. Die Full-Context-Attention verursachte zusätzlichen Rechenaufwand, ohne die Qualität zu verbessern. Bei dieser Modellgröße ist der Sliding-Window-Ansatz parameter-effizienter. Interessantes Ergebnis – der MPS-Fork verwendet standardmäßig Full-Context-Attention, was sein abweichendes Leistungsprofil erklären könnte.
Experiment 2: Höhere Lernrate + Warmup
Hypothese: Erhöhen der Matrix-Lernrate von 0,04 auf 0,06 und Hinzufügen von 10 % Warmup-Schritten.
Ergebnis: val_bpb = 2,551 (Verbesserung um 0,008)
Entscheidung: BEHALTEN. Geringe, aber konsistente Verbesserung. Das Warmup verhindert frühe Instabilität bei der höheren Lernrate. Dies ist die Art von Optimierung, die sich mit anderen Änderungen summiert.
Experiment 3: SwiGLU-Aktivierung
Hypothese: SwiGLU hat bei größeren Transformern Vorteile gezeigt. Wenden Sie es auf die Feed-Forward-Schichten an.
Ergebnis: val_bpb = 2,563 (Verschlechterung um 0,004)
Entscheidung: VERWERFEN. SwiGLU fügt Parameter in der FFN-Schicht hinzu, und bei insgesamt 11,5 Millionen Parametern ist das Modell zu klein, um diesen Aufwand zu verkraften. Die zusätzliche Ausdruckskraft gleicht den verbrauchten Parameter-Budget nicht aus. Dies ist ein nützliches negatives Ergebnis – es zeigt, dass SwiGLU eine minimale effektive Modellgröße hat.
Experiment 4: Halbierung der Batch-Größe
Hypothese: Reduzierung der Batch-Größe von 2^16 auf 2^15, um mehr Gradientenaktualisierungen pro Epoche zu erhalten.
Ergebnis: val_bpb = 2,432 (Verbesserung um 0,127)
Entscheidung: BEHALTEN. Das ist der große Gewinn. Die Halbierung der Batch-Größe führte zu einer Verbesserung von 5 % bei val_bpb – der größte Einzelgewinn in allen vier Experimenten. Die Intuition: Auf einem Gerät mit begrenztem Speicher bedeuten kleinere Batches häufigere Aktualisierungen, und das Modell profitiert mehr von den zusätzlichen Optimierungsschritten, als es durch verrauschte Gradienten einbüßt.
Endergebnis
2,559 zu 2,432 = 5,0 % Verbesserung in 4 Experimenten.
Vier Experimente, etwa 25 Minuten Rechenzeit und eine bedeutende Verbesserung. Der Agent identifizierte korrekt zwei Beibehaltungen und zwei Verwerfungen. Das Muster ist hier entscheidend: Der Mac findet andere Optimierungen als der H100. Karpathys Cluster-Experimente optimieren den Durchsatz bei Skalierung. Die Mac-Experimente zeigen natürlich Verbesserungen bei der Schritt-Effizienz – Optimierungen, die mehr Lernen pro Gradientenaktualisierung herausholen, anstatt mehr Aktualisierungen pro Sekunde.
Das ist keine Schwäche. Es ist eine komplementäre Suchrichtung.
💰 Die Wirtschaftlichkeit: 0 $ Rechenkosten, echte Ergebnisse
Sprechen wir darüber, was das kostet.
| Ansatz | Rechenkosten | Agent-API-Kosten | Experimente/Stunde | Über Nacht (~8 Std.) |
|---|---|---|---|---|
| M2 MacBook Pro | 0 $ | 2–5 $ | ~12 | ~100 |
| H100-Cloud (Lambda/RunPod) | 16–24 $ | 2–5 $ | ~1.100+ | ~9.000+ |
| H100 im Eigenbesitz | 80.000 $+ Kapital | 2–5 $ | ~1.100+ | ~9.000+ |
Das M2 ist beim reinen Durchsatz etwa 96-mal langsamer als ein H100. Das klingt verheerend, bis man den Kontext berücksichtigt.
Für die Erkundung und Prototypenentwicklung benötigen Sie keine 9.000 Experimente. Man benötigt 50–100, um den Suchraum zu verstehen, den Ansatz zu validieren und zu erkennen, welche Richtungen eine Skalierung wert sind. Der Mac erledigt das in einem einzigen nächtlichen Durchlauf ohne Rechenkosten.
Für die Weiterbildung und das Verständnis gibt es keinen Ersatz dafür, Experimente selbst durchzuführen. Die Trainingskurven zu beobachten, zu sehen, welche Modifikationen funktionieren und welche nicht, ein Gespür für die Sensitivität der Hyperparameter zu entwickeln – das kann man nicht durch das Lesen von Fachartikeln erlangen. Der Mac ermöglicht es, dies kostenlos zu iterieren.
Für kostenbewusste Teams ist die Rechnung klar. Ein Cloud-H100 für 8 Stunden kostet 16–24 $ vor Abzug der Agent-API-Gebühren. Wenn Sie ein Einzelentwickler, ein kleines Start-up oder ein Student sind, summiert sich das schnell. Die Durchführung erster Erkundungen auf Ihrem Mac und die Skalierung in die Cloud erst für die abschließenden Optimierungsläufe ist die vernünftige Strategie.
Es ist wie das Prototyping einer Schaltung auf einem Steckbrett, bevor man eine Leiterplatte bestellt. Das Steckbrett ist langsamer und unordentlicher, aber es ist kostenlos und steht auf deinem Schreibtisch. Du brauchst keine Fertigungsanlage, um dein Design zu validieren.
Die Kosten für die Agent-API (2–5 $ pro Sitzung) entstehen durch die LLM-Aufrufe, die Experimente vorschlagen und auswerten. Diese sind unabhängig von der Hardware gleich. Die Rechenleistung ist kostenlos. Die Intelligenz kostet Geld. Dieses Verhältnis spricht für den Mac – man zahlt denselben Preis für das Agent-Gehirn, egal ob es Experimente in 5 Minuten oder 5 Sekunden durchführt.
⚠️ Ehrliche Einschränkungen
Ich möchte konkret darauf eingehen, wo diese Konfiguration Schwächen aufweist, denn die Einschränkungen sind genauso wichtig wie die Ergebnisse.
16 GB sind das Minimum, aber nicht komfortabel. Bei einer maximalen Speicherauslastung von 10,8 GB bleiben etwa 5 GB für das Betriebssystem und Hintergrundprozesse übrig. Das System hat während meiner Tests nie ausgelagert, aber ich hatte alle Anwendungen geschlossen. Wenn Sie zu den Nutzern gehören, die 30 Chrome-Tabs offen halten, kommt es zur Auslagerung, und die Trainingsleistung bricht ein. 32 GB oder 64 GB Unified Memory wären deutlich komfortabler. Die 8-GB-M2-Modelle können dies überhaupt nicht ausführen.
96-mal langsamer ist real. Ein H100 arbeitet Experimente in einem Tempo ab, mit dem der Mac einfach nicht mithalten kann. Für die Produktionsoptimierung – den letzten Schub für die letzten paar Prozentpunkte an Leistung – benötigen Sie Cloud-GPUs. Der Mac ist für die Erforschung gedacht, nicht für die Nutzung.
Nur kleine Modelle. Das hier verwendete Modell mit 11,5 Millionen Parametern passt mit reichlich Spielraum in den Arbeitsspeicher. Ein Modell mit 100 Millionen Parametern würde das nicht. Der Designraum von Autoresearch ist bewusst auf kleine Modelle ausgerichtet, was dem Mac zugute kommt, aber extrapolieren Sie diese Ergebnisse nicht auf größere Architekturen.
Keine Skalierung über mehrere GPUs. Ein H100-Cluster kann die Arbeit auf mehrere GPUs verteilen. Der Mac hat eine GPU, Punkt. Parallelität ist nicht möglich.
Das Wärmemanagement ist entscheidend. Mein Stabilitätstest mit fünf Durchläufen zeigte keine Drosselung, aber das war in einem klimatisierten Raum. Ein nächtlicher Lauf in einer warmen Wohnung, wobei der Laptop auf einer weichen Oberfläche steht, könnte zu anderen Ergebnissen führen. Verwenden Sie eine harte, flache Oberfläche mit guter Luftzirkulation.
🧭 Wann Sie Ihren Mac und wann Cloud-GPUs nutzen sollten
Aufgrund meiner Experimente lautet hier meine ehrliche Empfehlung:
Nutzen Sie Ihren Mac, wenn:
- Sie einen neuen Suchraum erkunden und 50–100 Experimente brauchen, um ein Gefühl dafür zu bekommen
- Sie lernen, wie Autoresearch funktioniert, und ohne Kostendruck iterieren wollen
- Sie Experimentkonfigurationen prototypisieren, bevor Sie in die Cloud skalieren
- Sie ein Einzelentwickler oder Student sind und sich die Kosten von 20 $ pro Nacht für Cloud-Rechenleistung summieren
- Sie Übernachtläufe ohne Kosten pro Experiment wünschen
Skalieren Sie in die Cloud, wenn:
- Sie vielversprechende Richtungen identifiziert haben und mehr als 500 Experimente durchführen möchten, um zu konvergieren
- Sie Modelle mit mehr als ~15 Millionen Parametern benötigen
- Sie für die Produktion optimieren und jeder Bruchteil eines Prozentsatzes zählt
- Sie stehen unter Termindruck und können nicht auf 5-minütige Experimentzyklen warten
Der optimale Workflow: Prototypen auf dem Mac erstellen, in der Cloud validieren, auf dem Mac iterieren, aus der Cloud bereitstellen. Jede Phase nutzt Hardware, die den Anforderungen an Kosteneffizienz und Durchsatz dieser Phase entspricht.
🛠️ Erste Schritte: Die 5-Minuten-Version
Wenn Sie ein MacBook Pro mit Apple Silicon (M1/M2/M3/M4, 16 GB+ RAM) besitzen, ist dies der schnellste Weg zu Ihrem ersten Ergebnis:
# 1. Installieren Sie uv (Python-Paketmanager) curl -LsSf https://astral.sh/uv/install.sh | sh # 2. Klonen Sie den MLX-Fork git clone https://github.com/thenamangoyal/autoresearch.git cd autoresearch # 3. Installieren Sie die Abhängigkeiten uv sync # 4. Laden Sie den Datensatz herunter und bereiten Sie ihn vor uv run prepare.py # 5. Führen Sie Ihr erstes Trainingsexperiment durch uv run train.py
Erwartete Ausgabe: ~81 Schritte in 5 Minuten, val_bpb um 2,35, Spitzen-Speicherbedarf ~10,8 GB. Gesamtzeit von Null bis zum ersten Ergebnis: unter 10 Minuten einschließlich Downloads.
Für die Agent-Schleife (autonome Experimentiteration) müssen Sie einen LLM-API-Schlüssel konfigurieren und den Agent-Wrapper ausführen. Die Einzelheiten variieren je nach verwendetem Agent-Framework, aber das Kernkonzept lautet: Der Agent liest die Trainingsausgabe, schlägt eine Änderung an der Konfiguration vor, führt eine weitere Trainingsschleife durch und bewertet, ob die Änderung geholfen hat.
Wenn Sie daran interessiert sind, wie autonome Agent-Loops auf einer tieferen Ebene funktionieren – was machbar ist, was fehlschlägt und wie man Sicherheitsvorkehrungen dafür entwirft –, habe ich eine detaillierte Analyse in The Agent Harness Inflection Point: What's Actually Feasible verfasst.
🔮 Was dies für den Engpass in der ML-Forschung bedeutet
Karpathys „Autoresearch“ enthält ein implizites Argument: Der Engpass in der ML-Forschung sind nicht die Ideen – es ist der Experimentdurchsatz. Wenn man 700 Experimente in zwei Tagen statt 10 Experimente in einer Woche durchführen kann, verkürzt man den Forschungszyklus um ein Vielfaches.
Der Mac ändert nichts an diesem Argument. Er ändert lediglich, wer daran teilnehmen kann.
Vor der Einführung von Autoresearch erforderte die Durchführung von ML-Experimenten entweder institutionellen Rechenzugang oder erhebliche Cloud-Ausgaben. Jetzt kann jeder mit einem MacBook mit angemessener Ausstattung über Nacht 100 Experimente durchführen – für die Kosten von ein paar Dollar an API-Aufrufen. Die Experimente sind langsamer. Die Erkenntnisse sind echt. Die Eintrittsbarriere ist gerade um eine Größenordnung gesunken.
Dies knüpft an ein Muster an, das ich immer wieder in der Robotik und im ML beobachte: Die wertvollsten Experimente sind selten diejenigen, die die meiste Rechenleistung erfordern. Es sind diejenigen, die die richtige Hypothese testen. Ein H100, auf dem 700 schlecht konzipierte Experimente laufen, liefert weniger Erkenntnisse als ein MacBook, auf dem 50 gut konzipierte Experimente laufen. Die Hardware beschleunigt die Ausführung. Der Mensch beschleunigt das Verständnis.
Autoresearch auf einem Mac wird keine Geschwindigkeits-Benchmarks gewinnen. Aber es macht den Experimentierzyklus für jeden zugänglich, der bereit ist, seine Chrome-Tabs zu schließen und sein Ladekabel anzuschließen. Das ist eine bedeutende Veränderung.
Was das bedeutet
Das M2 MacBook Pro ist eine vollwertige Autoresearch-Plattform. Nicht die schnellste, nicht die leistungsstärkste, aber stabil, kostenlos zu betreiben und gut genug für Erkundung und Prototyping. Die Zahlen lügen nicht: 5 % Verbesserung in 4 Experimenten, null Abstürze in 5 Stabilitätsläufen, ~12 Experimente pro Stunde ohne Rechenkosten.
Der praktische Arbeitsablauf ist klar: Erkunden Sie auf Ihrem Mac, skalieren Sie in die Cloud, wenn Sie etwas gefunden haben, das es wert ist, optimiert zu werden. Der Mac verkürzt den Zyklus von der Idee zum Experiment. Die Cloud verkürzt den Zyklus vom Experiment zum Ergebnis. Nutzen Sie beides.
Wenn Sie prüfen möchten, ob Autoresearch – oder allgemeiner gesagt autonome Agent-Loops – für den ML-Workflow Ihres Teams sinnvoll sind, helfe ich Unternehmen dabei, genau diese Machbarkeit zu bewerten. Und wenn Sie einen technischen Partner benötigen, der Sie bei der übergeordneten KI-Strategie begleitet – von solchen Experimenten bis hin zur Produktionsbereitstellung –, dann ist das Fractional-CTO-Engagement genau das Richtige.
Die Rechenleistung ist günstig. Die Experimente sind kostenlos. Das Schwierige ist, zu wissen, welche Experimente durchgeführt werden sollen.
- Agentic AI Assessment: /services/agentic-ai-assessment
- Fractional CTO: /services/fractional-cto
