Vom Byte zum Token. Warum Karpathys Blick auf LLMs unser Computer-Denken dreht
LLMs sind nicht einfach «bessere Chatbots». Sie verhalten sich wie eine neue Rechenschicht, mit Tokens als Datenformat und dem Kontextfenster als Arbeitsspeicher.
Wenn du LLMs immer noch wie eine App behandelst, verpasst du den eigentlichen Shift. Andrej Karpathy beschreibt LLMs als neue Art Computer, den man in natürlicher Sprache programmiert. Das ist weniger Science-Fiction als ein pragmatisches Modell, um zu verstehen, was gerade passiert.
Karpathy ist nicht irgendwer in dieser Debatte. Er war Research Scientist und Founding Member bei OpenAI und leitete später bei Tesla die Teams rund um Computer Vision, Daten-Labeling, Training und Deployment für Autopilot. Heute baut er mit Eureka Labs an AI-nativer Bildung und veröffentlicht weiterhin praxisnahe und technische Inhalte zu LLMs.
Sein Kernpunkt ist simpel. Wir bekommen eine neue Computing-Schicht, in der ein Sprachmodell als zentrale Recheneinheit wirkt und «Programme» als Prompts oder Instruktionen daherkommen. Karpathy nennt das auch «Software 3.0», weil du ein Modell in Englisch programmierst, statt in Python oder C++.
Die Metapher «LLM als CPU» ist dabei weniger technisch als nützlich. Klassische CPUs sind deterministisch, sie führen exakt definierte Befehle aus. Ein LLM ist probabilistisch, es produziert Tokens auf Basis von Wahrscheinlichkeiten, die aus Training und Kontext entstehen. Das erklärt, warum zwei identische Anfragen nicht zwingend identische Antworten liefern.
Der zweite Teil der Analogie ist das Datenformat. Während klassische Systeme Bytes verarbeiten, arbeiten LLMs auf Tokens, also Textstücken, die durch Tokenizer erzeugt werden. Tokenisierung ist ein eigener Schritt in der LLM-Pipeline, und viele «seltsame» Modell-Effekte hängen genau damit zusammen. Auch Wikipedia fasst Tokenisierung als zentrale Vorstufe zusammen, damit Text überhaupt als Zahlen verarbeitbar wird.
Und dann kommt der Speicher. Ein LLM «sieht» nur, was im Kontextfenster liegt. Dieses Kontextfenster ist so etwas wie eine temporäre Arbeitsfläche, weil es während der Generierung den relevanten Verlauf, Dokumente oder Tool-Ausgaben trägt. Gleichzeitig ist es keine echte RAM-Analogie mit beliebigem Lesen und Schreiben, sondern eher ein begrenzter Sichtkegel, der mit jeder Antwort neu aufgebaut wird.
Aus dieser Sicht entsteht die Idee eines «LLM OS». Das beschreibt ein System, bei dem Kernfunktionen wie Interaktion, Task-Management und Systemsteuerung stark über ein LLM laufen, und die Bedienung primär über natürliche Sprache erfolgt. Das ist keine neue Linux-Distribution. Es ist eine neue Art, Workflows zu «orchestrieren», über Sprache, Tools und Kontext.
Wichtig ist die Unterscheidung zwischen Konzept und Produkt. Es gibt beispielsweise das Open-Source-Projekt Eclipse LMOS, das Agenten im Enterprise-Kontext orchestriert und mit ADL (Agent Definition Language) sogar eine strukturierte, versionierbare Beschreibung von Agentenverhalten anbietet. Das ist ein konkreter Stack für Agentic AI. Karpathys «LLM als OS»-Denken ist eher das mentale Modell, in das solche Plattformen plötzlich sauber reinpassen.
| Klassische Informatik | LLM-Paradigma | Was das in der Praxis heisst |
| Bytes als Basiseinheit | Tokens als Basiseinheit | Text wird «kompiliert» via Tokenizer. Prompt-Design und Token-Budget werden plötzlich relevant. |
| CPU führt deterministische Befehle aus | Modell generiert probabilistisch Text | Du brauchst Verifikation, Tests, Guardrails, weil «klingt gut» nicht gleich «stimmt». |
| RAM als Arbeitsspeicher | Kontextfenster als temporäre Arbeitsfläche | Gute Systeme managen Kontext aktiv. RAG, Memory-Strategien und Tool-Ausgaben gehören ins Design. |
| OS koordiniert Programme | LLM OS koordiniert Tasks, Tools, Agenten | Natürlichsprachliche Orchestrierung wird zur UX-Schicht. Agenten-Frameworks rücken näher ans «Betriebssystem». |
Der Haken an der neuen Freiheit ist die neue Fehlerklasse. LLMs können plausibel klingende, aber falsche Aussagen produzieren, und sie übernehmen Bias aus Trainingsdaten. Genau darum betont Karpathy in mehreren Kontexten den «Generation-Verification»-Gedanken, also erst erzeugen, dann prüfen, und Menschen sinnvoll im Loop halten.
Das neue Computing ist nicht magisch. Aber es ist anders
Karpathys Perspektive hilft, weil sie nicht versucht, LLMs als «Feature» zu erklären, sondern als neue Rechenschicht. Tokens statt Bytes, Kontextfenster statt klassischer RAM-Logik, probabilistische Outputs statt deterministischer Ausführung.