Kategorie: Erklärer

Ein Team arbeitet monatelang an einer KI-Anwendung. Sie läuft stabil. Dann kommt ein neues Modell – schneller, billiger, besser im Reasoning. Das Product-Team will es sofort testen. Von außen scheint es ein simpler Austausch: Modellnamen ändern, Evaluierungen laufen lassen. Aus Plattform-Perspektive ist das selten so einfach. Das neue Modell kommt über einen Provider, den die Anwendung nicht unterstützt. Dann wartet ein weiteres SDK, andere Authentifizierung, abweichendes Anfrageformat, neues Fehlermodell, eigene Umgebungsvariablen und provider-spezifisches Verhalten. Die Herausforderung ist nicht der Zugang zu mehr Modellen, sondern dass jedes neue Modell zum eigenen Infrastrukturprojekt werden kann.

Der Autor eines aktuellen Blogbeitrags beschreibt dieses Dilemma präzise. Er argumentiert, dass Teams, die ihre Anwendung direkt mit einem LLM-Provider verbinden, sich auf mehr verlassen als nur auf das Modell: SDK, Credentials, Request/Response-Schemata, Streaming, Tool-Aufrufe, Rate-Limits, Retry-Logiken, Modell-IDs und Nutzungsdaten. Sobald provider-spezifische Logik im Code ist, infiziert sie Secrets-Management, Observability, Testing, Deployment-Pipelines und Incident-Response. Mit zwei Providern ist das beherrschbar. Doch mit neuen Anbietern, deprecated Modellen, API-Änderungen und verschiedenen Workloads wird es unübersichtlich. Das Team wartet keine KI-Anwendung mehr – es pflegt eine interne Provider-Kompatibilitätsschicht.

Diese Situation ist nicht neu. Softwareteams kennen das Problem aus der Zeit vor reproduzierbaren Paketmanagement- und containerisierten Umgebungen. Damals brachen Anwendungen wegen inkompatibler Bibliotheken, Laufzeiten und Betriebssysteme. Ein Update einer Abhängigkeit konnte eine andere Komponente zerstören. Deployments in verschiedene Umgebungen führten zu unterschiedlichen Ergebnissen. Wir nannten das „Dependency Hell“. Die Herausforderung lag nicht in Abhängigkeiten an sich, sondern in der engen Kopplung von Code an Systeme, die sich unabhängig entwickeln. Die Lösung: stabile Grenzen wie Paketmanager, Lockfiles, Container und konsistente Schnittstellen. Heute sehen wir dasselbe Muster mit LLM-Providern. Jeder hat eigenes SDK, APIs, Credentials, Modelle, Tools, Abrechnung. Wenn wir Anwendungen direkt verbinden, reproduzieren wir die Kopplung, die wir woanders beseitigt haben.

Die entscheidende Einsicht: Der Lebenszyklus der Anwendung muss vom Lebenszyklus des Modells entkoppelt werden. Ein neues Modell sollte eine Konfigurationsänderung sein, keine Anwendungsneuschreibung. Anwendungen und Modelle haben unterschiedliche Release-Zyklen. Änderungen an der Anwendung erfordern Code-Review, Sicherheitschecks, Integrationstests, gestaffelte Deployments und Produktionsfreigaben. Neue Modelle erscheinen kontinuierlich und müssen oft schnell evaluiert oder umgeleitet werden. Otari bietet einen stabilen OpenAI/Anthropic-kompatiblen Endpunkt zwischen Anwendungen und Providern. Die Anwendung sendet eine Anfrage mit einem einzigen API-Key, während Provider-Auswahl, upstream-Credentials, Routing-Richtlinien und Fallback-Verhalten hinter dem Gateway bleiben. Es unterstützt derzeit mehr als 40 Provider. Die Integration der Anwendung bleibt stabil.

Diese Trennung erlaubt der Anwendung, das Produktverhalten zu besitzen, während die Plattform Modellzugriff und Betriebsrichtlinien übernimmt. Statt „Welcher Code muss geändert werden?“, fragt das Team „Welches Modell soll diesen Workload bedienen?“. Otari ersetzt nicht das ingenieurmäßige Urteilsvermögen. Teams müssen weiterhin Qualität, Latenz, Datenschutz, Zuverlässigkeit und Preis bewerten. Der Dienst entfernt lediglich die wiederholte Integrationsarbeit.

Ein kleineres Modell sollte nicht gleich eine kleinere Plattform bedeuten. Modellfähigkeit und Plattformfähigkeit sind nicht dasselbe. Leichtere oder Open-Weight-Modelle können wegen Kosten, Latenz, Datenschutz oder Deployment-Anforderungen besser geeignet sein. Aber ihnen fehlen oft die verwalteten Fähigkeiten von Frontier-Modell-APIs. Otari hilft, diese Lücke zu schließen, indem es modellagnostische Werkzeuge wie Websuche und sandboxed Code-Ausführung über dasselbe Gateway bereitstellt. Sobald Werkzeuge vom Provider entkoppelt sind, werden kleinere Modelle interessanter.

Fragmentierung geht über die Integration hinaus. Direkte Provider-Integrationen fragmentieren Code, verteilen Credentials über Systeme und teilen finanzielle Transparenz über mehrere Konten und Abrechnungs-Dashboards. Otari speichert upstream-Provider-Credentials zentral; Anwendungen verwenden workspace-bezogene API-Keys. Die Anwendung benötigt nie direkten Zugriff auf das Provider-Secret. Das schafft eine sauberere Sicherheitsgrenze. Credentials können zentral verwaltet und rotiert werden, Anwendungszugriff kann getrennt skaliert werden, der Schaden durch einen geleakten Key ist begrenzt. Kosten und Nutzung werden konsolidiert: Otari zeichnet Requests und Kosten über alle Provider hinweg auf und unterstützt Budgets, Transparenz und Ausgabenkontrollen. So wird Kostenmanagement näher an den Request herangerückt. Statt unerwartete Nutzung erst nach mehreren Rechnungen zu entdecken, können Teams Limits definieren und Ausgaben durch dieselbe Kontrollebene verfolgen, die den Modellzugriff autorisiert.

Bau das Produkt, nicht eine weitere Provider-Abstraktion. Die Modellwahl ändert sich ständig. Teams werden neue Modelle übernehmen, ältere ausmustern und Workloads routen. Einen permanenten Provider vorherzusagen, ist keine realistische Plattformstrategie. Ebenso wenig ist es nachhaltig, provider-spezifische Logik in jeder Anwendung neu zu erfinden. Der tragfähige Ansatz: der Anwendung einen stabilen Vertrag geben und die Modellschicht dahinter evolvieren lassen. Modelle müssen getestet werden. Kosten gemessen. Zuverlässigkeit und Sicherheit designt. Aber diese Entscheidungen in einer dedizierten Kontrollebene, nicht durch Rewrites im Anwendungscode. Hör auf, neuen Provider-Integrationen hinterherzurennen. Bau das Produkt gegen eine stabile Schnittstelle und lass das Modell-Ökosystem sich dahinter verändern. Otari zeigt mit seinem Multi-Provider-Routing-Guide, wie eine einzige Integration Requests routen, Credentials zentralisieren, Fallback-Verhalten hinzufügen und Nutzung sowie Kosten in eine operative Ansicht bringen kann.

Das ist keine Zukunftsmusik. Es ist eine Lektion aus Jahrzehnten Software-Engineering. Wir haben gelernt, Abhängigkeiten hinter stabilen Schnittstellen zu verstecken. Jetzt wenden wir das auf KI-APIs an. Was bedeutet das? Dass du deine Produktentwicklung nicht jedes Mal unterbrechen musst, wenn ein neues Modell erscheint. Dass du betriebliche Komplexität an eine zentrale Stelle delegieren kannst. Dass du die Innovationskraft des Modell-Ökosystems nutzen kannst, ohne in provider-spezifischem Code zu ertrinken. Die Zukunft der KI-Anwendungen liegt nicht darin, jeden neuen Anbieter einzeln zu integrieren, sondern eine stabile Basis zu haben, während das Modell-Layer sich im Hintergrund entwickelt.

Quelle: blog.mozilla.ai

Du arbeitest an einem Projekt, bei dem die Datenbank täglich um Millionen neuer Vektoren wächst. Anfangs passt alles in den Arbeitsspeicher – Antwortzeiten sind niedrig, Kosten überschaubar. Doch der Index wird größer, die monatliche Cloud-Rechnung steigt. Irgendwann kostet der reine RAM für deinen Vektorindex mehrere tausend Euro pro Monat. Wie optimiert man die Vektorsuche, wenn RAM zur teuren Ressource wird?

Die Antwort liegt in der Architektur der Approximate Nearest Neighbor (ANN) Algorithmen, genauer in der Entscheidung zwischen In-Memory und On-Disk Indizes. Eine Vektordatenbank besteht aus drei Komponenten: den Embeddings (numerische Repräsentationen des Text- oder Bildkorpus), dem Suchalgorithmus samt Indexstruktur (Qualität und Geschwindigkeit) und der Speicherung (RAM, Festplatte oder hybrid). Embeddings sind in der Literatur ausführlich behandelt. Der Fokus liegt hier auf den Suchalgorithmen – speziell den ANN-Verfahren.

Exakte Suche vs. Approximate Nearest Neighbor

Zwei grundlegende Ansätze: Die exakte Suche (kNN) durchläuft alle Einträge und berechnet für jeden den Abstand zur Anfrage. Sie liefert perfekte Ergebnisse, aber die Latenz skaliert linear mit der Indexgröße. Bei einer Million Vektoren wird es langsam, bei einer Milliarde unpraktikabel. Viele moderne Vektordatenbanken verzichten bei kleinen Sammlungen auf den Indexbau und fallen auf kNN zurück – der Overhead für ein paar tausend Vektoren lohnt nicht.

ANN-Algorithmen vermeiden den vollständigen Scan, indem sie Abkürzungen im Datenraum schaffen. Die meisten modernen Vertreter – HNSW oder DiskANN – nutzen eine Graphstruktur für schnelle Sprünge zu den nächsten Nachbarn. Die Kunst liegt in der Balance: Ein guter ANN-Algorithmus opfert ein wenig Genauigkeit, um Latenz und Skalierbarkeit drastisch zu verbessern.

Zwei Welten: In-Memory vs. On-Disk ANN

Der Artikel unterscheidet zwei Gruppen von ANN-Algorithmen: solche, die den gesamten Index oder große Teile im RAM halten (In-Memory), und solche, die RAM sparen, indem sie Daten auf der Festplatte belassen und nur eine schlanke Routing-Schicht im Speicher vorhalten (On-Disk). Beide können prinzipiell sowohl im RAM als auch auf der Festplatte betrieben werden, liefern aber die besten Ergebnisse, wenn man sie wie vorgesehen einsetzt.

Die bekannteste In-Memory-ANN ist HNSW (Hierarchical Navigable Small World). Sie verwendet einen mehrschichtigen Graphen: Eine Anfrage startet in der obersten, dünn besetzten Ebene, hangelt sich von Knoten zu Knoten zum nächsten Nachbarn, steigt dann in die nächsttiefere Ebene ab und wiederholt das Spiel, bis sie in der dichten unteren Ebene landet. Solange der gesamte Graph im RAM liegt, liefert HNSW extrem niedrige Latenzen – oft einstellige Millisekunden. Der Haken: Sobald der Index zu groß wird, um in den RAM zu passen – oder die RAM-Kosten explodieren –, bleibt nur der Umzug auf die Festplatte. Und da zeigt HNSW seine Schwäche: Die Graphstruktur erzeugt viele nicht-sequentielle Festplattenzugriffe bei jedem Hop. Die Folge: Latenzen steigen von Millisekunden auf Hunderte von Millisekunden oder mehr.

Genau hier setzen On-Disk-ANN-Algorithmen an. Der Autor stellt zwei prominente Vertreter vor: SPANN und DiskANN.

SPANN: Cluster-basierte On-Disk-Suche

SPANN folgt dem Vorbild des invertierten Index (IVF): Die Vektoren werden in Cluster gruppiert, jedes Cluster wird durch einen Zentroiden repräsentiert. Die Zentroiden – quasi die Routing-Information – bleiben im RAM, während die eigentlichen Vektoren eines Clusters auf der Festplatte hintereinander abgelegt werden. Das sorgt für sequentielle Lesevorgänge. Bei der Suche findet die Anfrage zunächst die vielversprechendsten Cluster über ihre Zentroiden und lädt dann die Vektoren dieser Cluster von der Festplatte als Block. Dadurch reduziert sich die Anzahl der I/O-Operationen drastisch. Der Autor verweist auf Turbopuffer, eine Datenbank, die auf SPFresh aufbaut (einem Nachfolger von SPANN), oder auf Chroma DB in der Cloud-Version.

DiskANN: Single-Layer-Graph mit Quantisierung

DiskANN verwendet einen anderen Ansatz: einen einschichtigen Graphen namens Vamana. Die Idee ist, die Anzahl der Hops und damit die Anzahl der zufälligen Festplattenzugriffe zu minimieren, indem der Graph bewusst einige längere Kanten enthält – nicht nur die nächsten Nachbarn. Zusätzlich werden die Vektoren stark quantisiert (auf wenige Bits) im RAM gehalten, während die vollen Float-Präzisionsvektoren auf der Festplatte liegen. So kann die Routing-Schicht schnell entscheiden, welche Knoten besucht werden müssen, und lädt dann nur deren vollständige Vektoren bei Bedarf. DiskANN findet sich beispielsweise in Milvus oder in einer PostgreSQL-Erweiterung (pg_diskann).

Die Kostenfrage: RAM vs. Festplatte

Eine Rechnung: Cloud-RAM kostet etwa 5 US-Dollar pro Gigabyte und Monat, EBS (Remote Disk) liegt bei rund 0,08 – 0,10 $, lokale NVMe-SSDs bei 0,20 – 0,25 $. RAM ist etwa 50‑mal teurer als Remote Disk. Für einen Index mit 100 Millionen Vektoren in 1024 Dimensionen (Float32) benötigt man bei einer Replikation von 3 etwa 1,2 TB Speicher. Nicht quantisiert im RAM: rund 6000 $ pro Monat. Mit skalare Quantisierung (25 % Speicher) immer noch 1500 $. Dagegen: Remote Disk knapp 120 $, lokale Disk etwa 300 $. Das Verhältnis wird extremer, wenn der Index auf eine Milliarde Vektoren wächst – dann kostet RAM nicht quantisiert etwa 60.000 $.

Diese Zahlen zeigen: On-Disk-Verfahren sind nicht nur eine Notlösung, sondern oft die einzige wirtschaftlich sinnvolle Option, sobald die Indizes in den Milliardenbereich gehen.

Der Preis der Ersparnis: Latenz

Die Kostensenkung ist nicht kostenlos. On-Disk-ANN-Indexe müssen die Daten von der Festplatte laden, das ist immer langsamer als ein RAM-Zugriff. Die tatsächliche Latenz hängt stark von der Hardware und dem Cache-Status ab. Der Autor zitiert Zahlen aus dem SPANN-Paper: 90 % Recall bei etwa einer Millisekunde mittlerer Latenz auf einer einzelnen Maschine mit lokaler SSD. In der Praxis, etwa bei Turbopuffer, misst man bei warmem Index auf schnellem Speicher etwa 14 Millisekunden (p50), bei kaltem Index aus dem Objektspeicher dagegen 874 Millisekunden – ein Faktor 60 allein durch den Cache. Generell gilt: On-Disk-ANN ist langsamer als HNSW im RAM, aber für viele Anwendungen (etwa RAG, wo die Ergebnisse ohnehin an ein Reranking und ein LLM weitergereicht werden) sind 100 Millisekunden Aufschlag völlig unkritisch. Nur wenn es auf jede Millisekunde ankommt – etwa bei agentischen Gedächtnissystemen mit vielen Abfragen pro Anfrage –, sollte man besser beim teuren RAM bleiben.

Wähle mit Bedacht

Die Entscheidung zwischen In-Memory- und On-Disk-ANN ist eine Abwägung von Kosten, Latenz und Skalierungsanforderungen. Für kleine bis mittlere Indizes (bis zu einigen zehn Millionen Vektoren) ist HNSW im RAM die beste Wahl – schnell, ausgereift, und die Kosten sind noch überschaubar. Sobald die Indizes jedoch in die Hunderte Millionen oder Milliarden gehen, werden On-Disk-Algorithmen wie SPANN oder DiskANN wirtschaftlich. Selbst wenn die Latenz etwas höher ist: Wenn man die Daten richtig organisiert – lokale SSDs statt Remote Disk, mit Quantisierung und warmem Cache –, kommt man in Bereiche, die für die meisten KI-Anwendungen völlig akzeptabel sind.

RAM ist schnell, aber teuer. Festplatte ist langsam, aber günstig. Die moderne Vektorsuche bietet clevere Algorithmen, die den Unterschied überbrücken – wenn man die Trade-offs versteht und die richtige Architektur für den eigenen Anwendungsfall wählt.

Quelle: towardsdatascience.com

Warum deine KI plötzlich rechnen kann – und wie du die Kontrolle behältst

Du arbeitest mit einem KI-Assistenten wie Claude, Gemini oder ChatGPT und möchtest, dass er echte Berechnungen durchführt – etwa Zahlen aus deiner Datenbank addieren oder Benutzerdaten abrufen. Das ist mit dem Model Context Protocol (MCP) schon heute möglich. MCP ist ein offener Standard, der KI-Anwendungen den Zugriff auf externe Werkzeuge erlaubt – ähnlich wie ein Betriebssystem Treiber für Hardware bereitstellt. In diesem Beitrag bauen wir einen eigenen MCP-Server mit einem Taschenrechner-Tool, hosten ihn auf Cloudflare Workers und rüsten eine OAuth 2.1-Authentifizierung nach. Am Ende verstehst du die Zusammenhänge und hast einen einsatzbereiten Prototypen.

Das Fundament: Ein Cloudflare Worker als MCP-Server

Der Autor beginnt mit einem fast leeren Cloudflare Worker, den man über die Kommandozeile mit dem Hello World-Template für TypeScript anlegt. Nach der Einrichtung liegt der Code in src/index.ts. Um daraus einen MCP-Server zu machen, installiert er drei Abhängigkeiten: das offizielle @modelcontextprotocol/sdk, Cloudflares agents-Bibliothek (die einen Adaptor für MCP bereitstellt) und zod zur Validierung von Eingaben. Diese Pakete übernehmen den Großteil der Implementierung – du konzentrierst dich auf die eigentlichen Werkzeuge, sogenannte Tools.

Das erste Tool: Ein Calculator mit Persönlichkeit

Ein MCP-Tool ist wie ein kleiner API-Endpunkt. Es besteht aus Namen, Beschreibung, Eingabe-Schema (definiert mit Zod) und einer Handler-Funktion. Der Autor zeigt das an einem Taschenrechner-Tool, das Addition, Subtraktion, Multiplikation und Division zweier Zahlen beherrscht. Die Handler-Funktion ermittelt anhand eines übergebenen Operators die richtige Operation und gibt das Ergebnis als Text zurück. Fehler wie eine Division durch Null werden abgefangen. Wichtig: Für jede eingehende Anfrage wird eine neue Instanz des MCP-Servers erzeugt – das verhindert, dass Daten zwischen Sitzungen durchsickern.

Damit der Worker die MCP-Anfragen annimmt, wird der MCP-Server an die fetch-Funktion des Workers angebunden. Der Pfad lautet /mcp. Fertig ist der erste funktionsfähige MCP-Server. Der Autor testet ihn direkt mit Claude Desktop, indem er in den Einstellungen einen neuen Connector anlegt – Name: „Calculator“, URL: die Adresse des laufenden Workers plus /mcp. Der lokale Worker läuft meist unter http://localhost, und nicht jeder KI-Client akzeptiert unsichere Verbindungen. Abhilfe schaffen ein HTTPS-Tunnel via ngrok oder das Deployment des Workers über pnpm run deploy. Nach dem Einrichten fragt der Autor Claude: „Addiere 5 und 8“. Claude erkennt das Tool, ruft es mit den richtigen Argumenten auf, der Server antwortet mit 13, und Claude präsentiert das Ergebnis – ein Kreislauf, der auf klaren Protokollen beruht.

Hinter den Kulissen: JSON-RPC im Detail

Die Kommunikation zwischen KI-Client und MCP-Server läuft über JSON-RPC, ein schlankes Protokoll für entfernte Prozeduraufrufe. Der Autor zeigt die tatsächlichen Anfragen, die Claude sendet. Zuerst fragt der Client tools/list ab: Der Server antwortet mit Namen, Beschreibung und Eingabe-Schema des verfügbaren Tools. Anhand dieser Metadaten entscheidet die KI, wann und wie das Tool einzusetzen ist. Bei der eigentlichen Aktion schickt Claude einen tools/call-Request mit den konkreten Parametern – in unserem Fall die Zahlen und die gewünschte Operation. Der Server führt die Berechnung aus und sendet das Ergebnis zurück. Dieses Zusammenspiel ist erweiterbar: Neue Tools lassen sich durch Hinzufügen weiterer Definitionen integrieren.

Warum ein offener MCP-Server riskant sein kann

Bisher kann jeder, der die URL kennt, den Taschenrechner benutzen. Für öffentliche Daten wie Wetter- oder Dokumentations-APIs ist das in Ordnung. Sobald persönliche oder geschäftskritische Daten ins Spiel kommen, brauchst du eine Zugriffskontrolle. Der Autor zeigt, was passiert, wenn der Server einfach einen 401 Unauthorized zurückgibt: Claude reagiert mit mehreren Folgeanfragen – es versucht den Protected Resource Metadata Endpoint, dann den Authorization Server Metadata Endpoint und schließlich eine Dynamic Client Registration. All das sind erratische Versuche, die fehlschlagen, weil die entsprechenden Endpunkte nicht existieren. Ein schlichter 401 reicht nicht; der Server muss dem Client mitteilen, wo er gültige Zugangsdaten bekommt.

OAuth 2.1 als Türsteher für deine KI-Tools

Hier kommt OAuth 2.1 ins Spiel, der aktuelle Standard für sichere Autorisierung. Der MCP-Server muss dem Client über den HTTP-Header WWW-Authenticate mitteilen, wo sich die Protected Resource Metadata (PRM) befindet. Diese PRM wiederum enthält die URL des Authorization Servers. Der Autor nutzt für diesen Teil PropelAuth, einen Dienst, der mit wenigen Klicks einen vollständigen OAuth 2.1-konformen Autorisierungsserver bereitstellt. Nach der Aktivierung der MCP-Unterstützung in der PropelAuth-Oberfläche legt der Autor anwendungsspezifische Scopes an – etwa op:add, op:sub, op:mult und op:div. Scopes sind wie Berechtigungsstempel: Ein Client kann nur dann eine bestimmte Rechenoperation ausführen, wenn der Benutzer dem entsprechenden Scope zugestimmt hat.

Den MCP-Server mit dem Authorization Server verbinden

Jetzt wird der MCP-Server mit dem PropelAuth-Authorization Server verknüpft. Dazu implementiert der Autor den PRM-Endpunkt, der die Adresse des Authorization Servers sowie die unterstützten Scopes auflistet. Außerdem korrigiert er den 401-Header, sodass Claude den PRM-Endpunkt direkt findet – ohne Rätselraten. Nach dem Neustart des Connectors in Claude Desktop öffnet sich ein Browserfenster mit dem PropelAuth-Login. Nach erfolgreicher Anmeldung wird der Benutzer aufgefordert, den angeforderten Scopes zuzustimmen. Erst nach dieser Zustimmung erhält der Client ein Access Token, das er bei jeder weiteren Anfrage mitschickt.

Der letzte Schritt ist die Validierung des Tokens auf Serverseite. Der Autor implementiert eine Funktion, die das Access Token aus dem Authorization-Header extrahiert und an den Token Introspection Endpoint von PropelAuth sendet. Dieser Endpunkt prüft, ob das Token gültig ist, wem es gehört und welche Scopes der Benutzer freigegeben hat. Der MCP-Server extrahiert diese Informationen in ein benutzerdefiniertes User-Objekt und leitet es an die Tool-Handler weiter. Innerhalb des Calculator-Tools wird dann geprüft, ob der Benutzer den erforderlichen Scope für die gewünschte Operation besitzt – etwa op:add für Addition. Fehlt die Berechtigung, lehnt der Server die Anfrage ab.

Der vollständige authentifizierte Workflow

Mit allen Komponenten ergibt sich ein klarer Ablauf: Ein Benutzer verbindet Claude Desktop mit dem MCP-Server. Claude fragt /mcp ab und erhält einen 401 mit dem PRM-Link. Daraufhin lädt Claude die PRM, identifiziert den Authorization Server und startet den OAuth-Flow über den Browser des Benutzers. Nach Login und Zustimmung erhält Claude ein Token. Mit diesem Token ruft Claude tools/list auf – der Server validiert das Token und gibt die Liste erlaubter Tools zurück. Schließlich ruft Claude tools/call für die gewünschte Rechnung auf, das Token wird erneut geprüft, und nur wenn die Scopes passen, darf gerechnet werden. Der gesamte Vorgang ist für den Benutzer weitgehend unsichtbar, bis auf den Login-Schritt.

Was bedeutet das für dich?

Der Autor zeigt, dass die Kombination aus MCP, Cloudflare Workers und einem modernen Autorisierungsdienst wie PropelAuth eine schlanke, aber leistungsfähige Plattform für KI-gestützte Tools ergibt. Du musst kein OAuth-Experte sein, um geschützte MCP-Server zu betreiben – die Spezifikationen sind ausgereift, die Bausteine liegen bereit. Wichtig ist, dass du die Prinzipien verstehst: Jeder MCP-Client muss sich über OAuth 2.1 authentifizieren, und jeder Tool-Zugriff kann feingranular über Scopes gesteuert werden. Das ist eine solide Basis für Produktivumgebungen. In Zukunft werden immer mehr KI-Clients MCP unterstützen, und wer heute die Grundlagen beherrscht, ist für die nächste Welle der Mensch-Maschine-Interaktion gerüstet. Bau dir deinen eigenen MCP-Server, mach ihn sicher und lass die KI für dich rechnen – aber nur mit deiner Erlaubnis.

Quelle: propelauth.com

Ein Gerücht machte auf dem Schulhof die Runde: Der größte Junge will den besten Roboterbauer kaufen. Niemand wusste, ob es stimmt. Ähnlich verhält es sich gerade in der KI-Welt. Am Wochenende verbreitete sich auf X (ehemals Twitter) das Gerücht, Anthropic – Entwickler des Sprachmodells Claude – wolle das Robotik-Startup Physical Intelligence übernehmen. Der Hype war stark, selbst CEO Hausmans vorsichtiges Dementi konnte ihn nicht stoppen. Was ist dran? Und warum ist das relevant für uns, die täglich mit KI arbeiten? Hier sind die Hintergründe eines Deals, der die Robotik verändern könnte.

Auslöser war ein Blogbeitrag von Connie Loizos auf TechCrunch. Die erfahrene Silicon-Valley-Journalistin beschreibt, wie ein Post des Tech-Bloggers Robert Scoble auf X die Diskussion auslöste. Scoble behauptete, Anthropic stehe kurz vor der Übernahme von Physical Intelligence. Das Startup, vor zwei Jahren gegründet von Lachy Groom, ehemaligen Google-Forschern und Stanford/Berkeley-Professoren, hat über eine Milliarde Dollar eingesammelt. Es entwickelt mit π0.5 eines der meistgenutzten Roboter-Gehirne in der Forschung. Die Nachricht verbreitete sich schnell, auch nachdem CEO Karol Hausman per Slack ein Dementi schickte. Laut Loizos gab es aber tatsächlich Gespräche im Frühjahr, wie „The Information“ berichtete. Scoble irrte nur im Timing.

Warum ist diese Übernahme so wichtig? Ein Blick auf die strategische Lage: Anthropic und OpenAI, die beiden führenden KI-Unternehmen, bereiten sich auf Börsengänge vor. Anthropic reichte am 1. Juni einen IPO-Antrag ein, OpenAI eine Woche später. Es könnten zwei der größten Börsendebüts in den USA werden. Im Wettlauf um Marktanteile und Investorengelder geht es nicht nur um Sprachmodelle. Es geht um die nächste Stufe: Superintelligenz. Robotik spielt dabei eine zentrale Rolle. Viele Experten glauben: Echte Superintelligenz entsteht nicht nur aus Internettexten. Sie braucht ein Verständnis der physikalischen Welt – Bewegung, Interaktion, Bruch. Robotik ist der Schlüssel.

OpenAI machte diese Erfahrung bereits. Früher baute es eine Roboterhand, die einen Zauberwürfel löste, schloss 2021 aber die gesamte Robotik-Sparte. Mitbegründer Wojciech Zaremba erklärte, dem Ansatz habe das nötige Verständnis für echte Superintelligenz gefehlt. 2024 kehrte das Team zurück, baute ein humanoides Robotiklabor in San Francisco auf. CEO Sam Altman machte Ende Mai offiziell: „OpenAI Robotics“ stellte ein und kündigte Roboter für Infrastrukturarbeit als kurzfristiges Ziel an, langfristig einen persönlichen Roboter für jeden. Anthropic dagegen hat kein vergleichbares Hardwarelabor. Stattdessen veröffentlichte die interne Gruppe Sicherheitsstudien. Im November testete Project Fetch, wie gut Claude Nicht-Experten beim Programmieren eines Roboterhundes half. Eine zweite Phase im Juni ergab, dass ein neueres Modell die Aufgaben etwa 20-mal schneller erledigte als das beste menschliche Team mit Claude aus dem Vorjahr. Ein Kauf von Physical Intelligence würde Anthropic Jahre an Forschung und Entwicklung ersparen – und den direkten Einstieg in die physische KI-Ebene ermöglichen.

Es gibt einen Haken. Physical Intelligence hat eine Investorenliste, die der von OpenAI ähnelt: Khosla Ventures, Thrive Capital und Founders Fund. Letzterer ist auch ein großer OpenAI-Investor und war an den jüngsten Finanzierungsgesprächen beteiligt. Noch wichtiger: OpenAI selbst ist Investor bei Physical Intelligence. Das bedeutet: OpenAIs größter Rivale wollte ein Unternehmen kaufen, an dem OpenAI beteiligt ist. Das wirft Fragen auf: Hat OpenAI bei seiner Investition Informationsrechte oder ein Vorkaufsrecht bekommen für den Fall eines Verkaufs an einen Wettbewerber? Solche Klauseln sind bei strategischen Investoren üblich. Sollte Physical Intelligence zum Verkauf stehen, könnte OpenAI den besseren Anspruch haben – bereits Aktionär, Groom nahestehend, und dabei, Anthropic in der Robotik zu übertrumpfen. Loizos fragte OpenAI, erhielt aber keine Antwort.

Was bedeutet das für uns? Die Gerüchte um Anthropic und Physical Intelligence sind kein belangloses Silicon-Valley-Gerede. Sie zeigen, wohin die KI-Reise geht: weg von reinen Textwelten, hinein in die physische Realität. Wer heute KI nutzt – Chatbots, Bildgeneratoren, Sprachassistenten – wird morgen Roboter sehen, die von denselben Modellen gesteuert werden. Die Frage ist nicht mehr, ob KI die reale Welt erobert, sondern wann und von wem. Anthropic und OpenAI liefern sich ein Wettrennen um die nächste Milliarde Nutzer. Während wir über KI nachdenken, bauen die Firmen bereits die Infrastruktur: Roboter, die uns bald im Haushalt oder Straßenbau helfen. Die Investitionen in Robotik sind ein klares Signal: Die Zukunft ist digital und analog. Unternehmen, die diese Brücke schlagen, werden die nächste Dekade dominieren.

Wird Anthropic Physical Intelligence kaufen? Vielleicht, vielleicht nicht. Sicher ist: Die Gerüchte haben ein Fenster geöffnet. KI und Robotik sind untrennbar verwoben. Für uns als Beobachter und Nutzer heißt das: hinschauen, verstehen, mitreden. Die nächste Generation von KI-Anwendungen wird unsere Arbeit, unser Leben und unsere Interaktionen grundlegend verändern. Wenn wir verstehen, warum ein Twitter-Gerücht über einen Milliarden-Deal die Runde macht, verstehen wir auch, wohin die Reise geht.

Quelle: techcrunch.com

Du arbeitest an einem Softwareprojekt und wünschst dir einen Assistenten, der nicht nur Code vorschlägt, sondern eigenständig komplexe Aufgaben über mehrere Stunden löst. Daran arbeitet das Team um Eiso Kant bei Poolside AI. Das Unternehmen hat mit Laguna S 2.1 ein Modell veröffentlicht, das Modelle fast zehnmal seiner Größe übertrifft – nach nur acht Wochen Entwicklungszeit. Die Antwort liegt in einer Systematik, die Kant selbst als „Model Factory“ bezeichnet.

Eiso Kant ist kein Unbekannter in der KI-Szene. 2015 ließ er sich von Andrej Karpathys Artikel über rekurrente neuronale Netze inspirieren und gründete das Open-Source-Startup Sourced, das Sprachmodelle für Code entwickelte. Das war lange bevor GPT die Welt veränderte. Kant investierte vier Jahre und zwölf Millionen Dollar in diese Vision – und scheiterte. „Das war der größte Fehlschlag meiner Karriere“, sagt er. Die Welt war noch nicht bereit für Code-Modelle. Als ChatGPT kam, fühlte sich Kant bestätigt. Er kehrte mit Poolside zurück, diesmal mit der Überzeugung, dass der richtige Weg über offene Gewichte und reproduzierbare Forschung führt.

Warum setzt Poolside auf Offenheit? Kant argumentiert: Ein Ökosystem mit hundert Foundation-Modell-Unternehmen ist einem Oligopol von fünf weit überlegen – selbst wenn Poolside nicht zu den fünf gehören würde. Offene Gewichte bedeuten Transparenz und ermöglichen es anderen, auf den Ergebnissen aufzubauen. Die Forschung bleibt offen: Poolside veröffentlicht technische Berichte mit einem Detailgrad, der in der Branche selten geworden ist. Das Unternehmen hat ein globales Forschungsteam aufgebaut, abseits des Talentkriegs im Silicon Valley. Weniger als siebzig Forscher führen monatlich zwischen zehntausend und zwanzigtausend Experimente durch. Möglich macht es die Infrastruktur.

Die Model Factory ist das Herz von Poolside. Eine Produktionsstraße, die nicht Autos, sondern Intelligenz herstellt. Der Prozess beginnt mit dem Streaming von Daten direkt ins Training, ohne Zwischenspeicher und manuelle Schritte. Jedes Experiment ist reproduzierbar, weil Code und Daten versioniert und unveränderlich gespeichert werden. Kant betont: Modellbau besteht zu neunzig Prozent aus Engineering – nicht aus Wissenschaft im Elfenbeinturm. Die Factory ermöglicht es, von der Vorschulung bis zur Veröffentlichung eines Modells in fünf bis acht Wochen durchzulaufen. Eine radikale Beschleunigung gegenüber den sechsmonatigen Zyklen, die früher üblich waren.

Technisch ist Laguna S 2.1 ein Mixture-of-Experts-Modell mit 118 Milliarden Gesamtparametern, von denen pro Token nur 8 Milliarden aktiv sind. Der Kontext umfasst bis zu einer Million Token, und das Modell kann zwischen einem Denkmodus und einem schnellen Modus wechseln. Ein so vergleichsweise kleines Modell kann mit riesigen Modellen wie denen von Thinking Machines mithalten. Kant erklärt: Ausdauer, Verifikation und Rückverfolgung sind oft wichtiger als rohe Intelligenz. Kleinere Modelle erledigen mehr Wissensarbeit, als man annimmt – wenn sie richtig trainiert werden.

Ein zentraler Punkt in Kants Philosophie ist die Rolle des Reinforcement Learning. Er sieht, dass RL in Zukunft früher in die Vorschulung einziehen wird, fast wie eine Form des Curriculums. Die bloße Vorhersage des nächsten Tokens schöpft nicht genug Wissen aus dem Web. Poolside setzt hier an: Die Modelle werden nicht nur mit Code, sondern mit langfristigen Softwareaufgaben trainiert. Ein Agent schreibt Code, startet Jobs, evaluiert Ergebnisse und modifiziert die Pipelines, die zum Training zukünftiger Modelle verwendet werden. Das ist der Kreislauf, der das System verbessert.

Kant kritisiert aktuelle Ansätze wie MCP und traditionelle Tool Calls. Er nennt sie „stupid“. Statt einem Modell eine Auswahl vorgefertigter Werkzeuge zu geben, soll der Agent selbst Skripte schreiben und ausführen. Das minimiert die Abhängigkeit von vordefinierten Schnittstellen und gibt dem Modell maximale Freiheit. Kant plädiert für minimale Harness-Systeme, in denen das Modell mit Containern und einer Shell kommuniziert – mehr braucht es nicht. Der Weg zur AGI führt über langfristige Softwareentwicklungsaufgaben, nicht über Chatbots oder Bildgenerierung.

Poolside hat sich auf Code spezialisiert, arbeitet aber auch an Bildverarbeitung. Audio steht vorerst nicht auf der Roadmap. Sprache bleibt die recheneffizienteste Modalität, um Wissen und Logik zu kodieren. Kant rechnet vor: Der finale Trainingslauf eines großen Modells ist oft antiklimatisch, weil der eigentliche Aufwand in den tausenden Experimenten davor steckt. Die Kosten für die Entwicklung eines Modells liegen im Bereich von Hunderten Millionen Dollar, verteilt über viele Versuche. Poolside hat 500 Millionen Dollar eingesammelt, zu einer Zeit, als Investoren noch bezweifelten, ob AGI realisierbar sei.

Was bedeutet das für die Zukunft der KI? Kant malt ein Bild, in dem Intelligenz zur meistgefragten und gleichzeitig am meisten kommoditisierten Ressource wird. Offene Modelle könnten irgendwann zu leistungsfähig sein, um sie uneingeschränkt zu veröffentlichen. Gleichzeitig warnt er: Einseitige Sicherheitsmaßnahmen funktionieren in einem global wettbewerblichen Umfeld nicht. Regulierung könnte unbeabsichtigt ein Oligopol von zwei oder drei Unternehmen zementieren – genau das, was Kant vermeiden will. Hardware-Hürden bei NVIDIA und TSMC sowie der Engpass durch Reinforcement Learning in Echtzeit sind weitere Herausforderungen.

Poolside gibt Anlass zur Hoffnung, dass auch kleinere Akteure mit klarer Strategie und exzellenter Technik mithalten können. Die Model Factory zeigt: Systemdenken und Ingenieurskunst machen den Unterschied. Nicht die Größe des Modells allein entscheidet, sondern die Fähigkeit, schnell zu experimentieren, zu lernen und zu verbessern. Für Entwickler und Unternehmen heißt das: Wer intelligente Software bauen will, sollte sich nicht nur auf die großen Anbieter verlassen. Mit den richtigen Werkzeugen und einer durchdachten Infrastruktur lassen sich eigene Modelle trainieren – schneller als gedacht.

Quelle: latent.space