Simon Willison legt den Konflikt hinter günstigem LLM-Relay-Zugang offen
Simon Willison hat einen Relay-Markt ins Rampenlicht gerückt, in dem vergünstigter LLM-Zugang von gebündelten Zugangsdaten, offengelegten Bots und Zahlungsbetrug abhängen kann. Sein Beitrag vom 26. Juli verweist Leser auf eine Untersuchung des Softwareingenieurs Matt Lenhard. Darin wird eine kommerzielle Lieferkette beschrieben, die Entwickler, Start-ups und andere Käufer vor allem über chinesischsprachige Communities bedient.
Der Konflikt besteht nicht einfach zwischen offiziellen APIs und günstigeren Wettbewerbern. Es geht um den Gegensatz zwischen legitimer Gateway-Technologie und einem Wiederverkaufsmarkt, dessen Betreiber möglicherweise verschleiern, woher ihre Rechenkapazität stammt. Käufer sehen einen kompatiblen Endpunkt und bequeme Abrechnung. Sie können jedoch kaum überprüfen, ob der Upstream-Zugang rechtmäßig erworben, aus einer anderen Anwendung abgeschöpft oder über betrügerische Konten beschafft wurde.
Diese Unsicherheit setzt drei Gruppen gleichzeitig unter Druck. Modellanbieter tragen die Kosten unautorisierter Nutzung und von Rückbuchungen. Anwendungsentwickler riskieren, dass offengelegte Endpunkte zu Relay-Bestand werden. Käufer senden Prompts, Quellcode und Geschäftsdaten durch Vermittler, deren Identität und Datenpraktiken unklar sein können.
Simon Willison macht eine verborgene Relay-Ökonomie sichtbar
Die wichtige Veränderung ist die Sichtbarkeit: Ein verstreutes Missbrauchsproblem erscheint nun als organisierter Markt mit spezialisierten Lieferanten, Infrastruktur und Kunden.
Willison führte die zugrunde liegende Recherche nicht selbst durch. Seine Relay-Warnung verstärkte Lenhards Erkenntnisse und verknüpfte sie mit einem praktischen Problem für Anwendungsentwickler. Eine offengelegte LLM-Funktion zieht nicht mehr nur opportunistischen Missbrauch an. Sie kann ein nachgelagertes Geschäft versorgen, das unautorisierten Zugang monetarisiert.
Lenhard veröffentlichte seine Untersuchung am 28. Juni, nachdem er ein chinesischsprachiges Forum analysiert hatte, in dem Betreiber über Relay-Terminologie und -Methoden diskutierten. Seinem Bericht zufolge entstand sein Interesse bei der Arbeit an einem KI-Gateway, das wiederholt durch Missbrauch von Gratisguthaben und Support-Bots betroffen war. Gespräche mit anderen Unternehmen überzeugten ihn, dass das Muster über einen einzelnen Dienst hinausgeht.
Die wichtigste Forumsquelle des Berichts lief vom 5. März bis zum 23. Juni. Laut Lenhard zog die Diskussion rund 35.000 Aufrufe und 190 Antworten an. Diese Zahlen zeigen Interesse innerhalb einer Community, belegen jedoch nicht die Gesamtgröße des breiteren Marktes.
Ein Relay, manchmal auch Transferstation genannt, bietet Kunden einen API-Endpunkt, der der Schnittstelle eines großen Modellanbieters ähnelt. Kunden ändern die Basis-URL einer Anwendung und übermitteln eine vom Relay ausgestellte Zugangsdatenkennung. Das Relay leitet dann jede Anfrage an ein Upstream-Konto oder einen weiteren Vermittler weiter.
Dieses Design verbirgt erhebliche Komplexität. Ein Kunde sieht einen vertrauten Modellnamen, ein Nutzungsguthaben und ein bekanntes Anfrageformat. Hinter dieser Schnittstelle kann der Betreiber Zugangsdaten rotieren, Ratenlimits umgehen, fehlgeschlagene Aufrufe wiederholen oder ein angefordertes Modell einem anderen zuordnen.
Lenhard beschreibt vier breite Ebenen. Karten- und Kontohändler beschaffen Zahlungsinstrumente oder registrierte Konten. Kontopools bündeln Zugangsdaten und verwalten deren Limits. Kundenorientierte Relays verpacken diese Kapazität in einen komfortablen Dienst. Entwickler und kommerzielle Nutzer kaufen den daraus resultierenden Zugang.
Diese Rollen können sich überschneiden. Ein Betreiber kann sowohl den Kontopool als auch das Frontend kontrollieren. Ein anderes Relay kann Kapazität aus einem separaten Pool einkaufen, ohne den Ursprung jeder Zugangsdatenkennung zu kennen. Diese Trennung erschwert die Nachverfolgung von Verantwortung, wenn ein Anbieter Missbrauch feststellt.
Der Markt scheint zudem über Infrastruktur für Verbraucher jenseits einzelner Verkäufer zu verfügen. Lenhard berichtet von Preisvergleichsseiten, Partnerprogrammen, Kundensupport-Gruppen und spezialisierten Gateway-Produkten. Die zehn meistbesuchten Relays, die sein Team verfolgte, hätten zusammen 3,6 Millionen monatliche Besuche erhalten.
Diese Traffic-Schätzung stammt aus Lenhards Recherche und sollte als zugeschriebene Messung behandelt werden. Sie zeigt nicht, wie viele Besucher zu zahlenden Kunden wurden. Ebenso kann sie nicht zwischen legitimem Zugang und Zugang unterscheiden, der letztlich durch Betrug bereitgestellt wurde.
Dennoch ist die umgebende Infrastruktur relevant. Vergleichsseiten und Partnerprogramme verringern den Aufwand, ein Relay zu finden. Standardsoftware senkt den Aufwand, eines zu betreiben. Kontopools begrenzen den Schaden, wenn einzelne Upstream-Zugangsdaten nicht mehr funktionieren.
Deshalb verdient Willisons Eingreifen Aufmerksamkeit. Er rahmte den Relay-Markt als Anwendungssicherheitsproblem ein, nicht bloß als Streit über Modellpreise oder geografische Verfügbarkeit. Jedes Produkt, das kostspielige Inferenz bereitstellt, kann zum unfreiwilligen Lieferanten werden.
Die wichtigste Lehre ist zugleich die einfachste. Ein LLM-Endpunkt muss den Schlüssel seines Anbieters nicht preisgeben, um ein Risiko zu schaffen. Wenn Außenstehende darüber ungemessene Anfragen senden können, wird der Endpunkt selbst faktisch zu einer wiederverwendbaren Zugangsdatenkennung.
Günstige Tokens erzeugen Druck entlang der KI-Lieferkette
Die Nachfrage nach Relays macht jede schwache Ausgabenkontrolle, jeden offenen Chatbot und jede unzureichend geschützte Anwendung zu potenziellem Bestand.
Der unmittelbarste Druck trifft Modellanbieter und die Unternehmen, die ihre Rechnungen bezahlen. Kostenlose Testphasen schaffen einen Kanal zur Kundengewinnung, doch automatisierte Registrierungen können diese Guthaben in Wiederverkaufskapazität verwandeln. Rückbuchungen können bereits verbrauchte Inferenzkosten auf Anbieter oder Händler zurückverlagern.
Gestohlene Karten schaffen eine direktere Form des Verlusts. Das Konto kann lange genug aktiv bleiben, damit ein Relay seine verfügbare Kapazität verbraucht. Bis Karteninhaber oder Herausgeber die Transaktionen anfechten, wurde die Modellausgabe bereits nachgelagert bereitgestellt.
Prepaid- und virtuelle Karten erschweren Risikobewertungen, ohne für sich allein Fehlverhalten zu belegen. Viele legitime Kunden nutzen beide Produkte. Anbieter müssen daher Zahlungssignale mit Kontoalter, Anfrageverhalten, Geräteinformationen und Netzwerkmustern kombinieren.
Anwendungsunternehmen stehen vor einem anderen Problem. Ein öffentlicher Support-Assistent, eine Schreibfunktion oder ein Endpunkt zur Dokumentenanalyse kann Anfragen über ein vom Unternehmen kontrolliertes Konto weiterleiten. Fehlen diesem Endpunkt Authentifizierung oder strenge Limits, kann ein Angreifer ihn in einen weiteren Dienst einbinden.
Der Angreifer muss den zugrunde liegenden Schlüssel nicht extrahieren. Stattdessen bildet er das Anfrageformat der Anwendung nach und sendet unabhängige Prompts über deren Backend. Die Anwendung wird zum Proxy, während ihr Betreiber die Rechnung erhält.
Willison zufolge macht ihn diese Möglichkeit vorsichtiger beim Veröffentlichen eigener LLM-gestützter Anwendungen. Er wünscht sich anbieterseitige Kontrollen, die eine Anwendung stoppen, wenn die Ausgaben einen vom Entwickler definierten Schwellenwert erreichen. Warnungen sind hilfreich, doch eine Warnung nach einem Burst verhindert den Verlust nicht.
Diese Sorge wächst, da KI-Agenten das Anfragevolumen und die Parallelität erhöhen. Ein interaktiver Chatbot sendet nach einer Nutzeraktion möglicherweise eine Anfrage. Ein Coding-Agent kann wiederholt Aufrufe tätigen, umfangreichen Kontext anhängen und mit begrenzter Aufsicht weiterarbeiten.
Parallelität kann auch eine einfache Guthabenprüfung aushebeln. Mehrere Anfragen können beginnen, während ein Konto noch unter seinem Limit liegt. Wenn das System ihre Kosten erst nach Abschluss verbucht, kann die kombinierte Nutzung die vorgesehene Obergrenze überschreiten.
Ein sichereres Design reserviert Budget für jede laufende Anfrage. Es wendet außerdem Limits nach Konto, Zugangsdatenkennung, Endpunkt und Zeitfenster an. Diese Kontrollen begrenzen den Schaden durch Relay-Missbrauch ebenso wie durch Denial-of-Wallet-Angriffe.
Denial of Wallet beschreibt Anfragen, die darauf abzielen, das kostenpflichtige API-Kontingent einer anderen Partei zu verbrauchen. Anders als beim Wiederverkauf hat der Angreifer möglicherweise keinen nachgelagerten Kunden. Die technische Schwachstelle bleibt ähnlich, weil das Ziel kostspielige Arbeit ohne ausreichende Autorisierung oder Limits annimmt.
Der Druck verlagert sich dann auf kleinere Anwendungsteams. Große Modellanbieter können Zahlungssicherheitsysteme, Betrugsteams und umfangreiche Verhaltens-Telemetrie unterhalten. Ein Start-up, das eine einzelne KI-Supportfunktion ergänzt, verfügt möglicherweise über keines davon.
Entwickler müssen jede öffentliche KI-Funktion als gemessene finanzielle Schnittstelle behandeln. Authentifizierung allein reicht nicht aus, wenn Angreifer viele Konten erstellen können. Limits pro Nutzer reichen nicht aus, wenn Anfragen ein gemeinsames Organisationsbudget beanspruchen.
Eingabebeschränkungen können helfen, müssen jedoch serverseitig durchgesetzt werden. Eine Browseroberfläche, die nur Supportfragen akzeptiert, kann dennoch ein Backend aufrufen, das beliebigen Text verarbeiten kann. Angreifer können die Oberfläche umgehen und die zugrunde liegende Anfrage direkt auslösen.
Teams sollten außerdem experimentelle Zugangsdaten von Produktionskonten trennen. Eine geleakte Testroute sollte nicht die gesamte Ausgabenkapazität einer Organisation offenlegen. Eng begrenzte Berechtigungen, Modellbeschränkungen und unabhängige Budgets verringern die Folgen einer übersehenen Kontrolle.
Diese Arbeit schafft Reibung für legitime Nutzer. Strenge Identitätsprüfungen können Kunden blockieren, denen unterstützte Dokumente oder Zahlungsmethoden fehlen. Aggressive Netzwerkfilter können Reisende, gemeinsam genutzte Büros und datenschutzbewusste Nutzer benachteiligen.
Dieser Zielkonflikt hilft, die anhaltende Nachfrage nach Relays zu erklären. Manche Käufer wollen niedrigere Betriebskosten. Andere wollen Modelle, die über lokale offizielle Kanäle nicht verfügbar sind. Einige suchen einen OpenAI-kompatiblen Endpunkt, der mit bestehenden Entwicklertools funktioniert.
Diese Bedürfnisse machen nicht jeden Käufer zu einem Beteiligten an Upstream-Betrug. Ein ungewöhnlich günstiger Dienst mit unklaren Eigentumsverhältnissen überträgt jedoch erhebliche Risiken auf den Kunden. Bequemlichkeit kann unzuverlässigen Zugang, ersetzte Modelle oder ungeschützte Daten verschleiern.
Ein API-Endpunkt kann Hunderte Zugangsdaten verbergen
Der Relay-Mechanismus funktioniert, weil Standard-Gateway-Funktionen die Kundenerfahrung von der Quelle jeder Upstream-Anfrage trennen können.
Lenhard zufolge nutzten die meisten von ihm untersuchten Relays one-api oder new-api. Beide sind Open-Source-Gateways, die mehrere Modellanbieter hinter einer einzigen kompatiblen Schnittstelle bündeln können. Es handelt sich um legitime Produkte mit üblichen internen und unternehmensweiten Einsatzmöglichkeiten.
Die Gateway-Software unterstützt mehrere Anbieter, Tokenverwaltung, Kanalgruppen, Modellzuordnung, Wiederholungsverhalten und Lastverteilung. Ein Unternehmen kann diese Funktionen nutzen, um Zugangsdaten zu zentralisieren und Mitarbeitern zugleich enger gefasste Zugriffstokens bereitzustellen.
Die Dokumentation weist Nutzer außerdem an, die Bedingungen der Anbieter und geltende Gesetze einzuhalten. Die Software ist daher kein Beleg für Betrug. Die relevante Frage ist, wie ein Betreiber die Upstream-Konten beschafft, die er in seinen Kanälen einsetzt.
New API erweitert dieselbe allgemeine Architektur. Das Projekt beschreibt sich als Gateway für Aggregation, organisatorische Authentifizierung, Nutzungsanalyse und private Bereitstellung. Sein Gateway-Fork ergänzt Zahlungs-, Abrechnungs-, Berechtigungs- und Routing-Funktionen, die für autorisierte Dienstbetreiber nützlich sind.
New API erklärt außerdem, dass Upstream-Schlüssel und -Konten rechtmäßig beschafft werden müssen. Es warnt Betreiber öffentlicher Dienste und Wiederverkäufer, Autorisierungs-, Lizenzierungs-, Protokollierungs-, Identitäts-, Zahlungs- und regulatorische Pflichten zu erfüllen. Diese Hinweise unterscheiden die vorgesehenen Einsatzzwecke der Software von missbräuchlichen Bereitstellungen.
Ein Relay-Betreiber beginnt mit der Konfiguration von Kanälen. Jeder Kanal verweist auf einen Modellanbieter, einen Anwendungsdienst oder einen anderen Pool. Das Gateway weist diesen Kanälen Zugangsdaten zu und wählt eine davon aus, wenn ein Kunde eine Anfrage übermittelt.
Routing verwandelt unzuverlässige Zugangsdaten in ein stabileres Produkt. Wenn ein Konto ein Ratenlimit erreicht oder gesperrt wird, kann das System einen anderen Kanal versuchen. Gewichtetes Routing kann Quellen bevorzugen, die günstiger oder zuverlässiger erscheinen.
Das Gateway erfasst anschließend die Nutzung zulasten des Relay-Guthabens des Kunden. Diese Abrechnungsebene offenbart nicht, was der Upstream-Anbieter berechnet hat. Sie bildet lediglich die eigenen Regeln, Multiplikatoren und Modellzuordnungen des Betreibers ab.
Diese Trennung schafft die zentrale Informationslücke. Ein Kunde, der ein namentlich genanntes Frontier-Modell anfordert, kann nicht unabhängig feststellen, welches Upstream-Konto den Aufruf verarbeitet hat. Möglicherweise kann der Kunde auch kaum bestätigen, dass das angeforderte Modell die Antwort erzeugt hat.
Modellzuordnungen sind in legitimen Bereitstellungen nützlich. Ein Unternehmen kann Datenverkehr zwischen kompatiblen Systemen verschieben oder einen stabilen internen Modellnamen bereitstellen. Ein unehrlicher Betreiber kann dieselbe Funktion nutzen, um ein günstigeres Modell zu ersetzen und dabei ein Premium-Label beizubehalten.
Einfache Tests der Ausgabe lösen dieses Problem nicht vollständig. Eng verwandte Modelle können auf gängige Prompts ähnlich reagieren. Anbieter können Modelle aktualisieren, ohne jede öffentliche Bezeichnung zu ändern. Relay-Betreiber können zudem nur ausgewählte Anfragen an das versprochene Modell weiterleiten.
Der Proxy sieht die vollständige Anfrage, weil er sie an den Upstream-Anbieter weiterleiten muss. Bei Coding-Tools kann die Nutzlast Repository-Dateien, Architekturhinweise, Debugging-Protokolle und Systemanweisungen enthalten. Bei Geschäftsanwendungen kann sie Kundendaten oder interne Dokumente umfassen.
Ein legitimes Enterprise-Gateway arbeitet unter der Kontrolle und gemäß den Sicherheitsrichtlinien der Organisation. Ein unbekanntes Relay schafft einen weiteren Datenverarbeiter außerhalb dieser Grenze. Käufer müssen seinen Angaben zu Aufbewahrung, Zugriff, Verschlüsselung, Reaktion auf Sicherheitsvorfälle und Löschung vertrauen.
Das Relay kann Anfragen auch über mehrere Anbieter weiterleiten. Failover verbessert die Verfügbarkeit, erweitert jedoch die Zahl der Systeme, die den Prompt möglicherweise erhalten. Ohne präzise Offenlegungen zu Routing und Datenverarbeitung können Kunden dieses Risiko nicht bewerten.
Diese Unterscheidung ist für Debatten über Open-Source-Richtlinien wichtig. one-api oder new-api die Schuld zu geben, würde Fähigkeiten mit Verhalten verwechseln. Auch Webserver, Zahlungssysteme und Load Balancer unterstützen sowohl rechtmäßige Unternehmen als auch missbräuchliche Aktivitäten.
Die bessere Reaktion konzentriert sich auf die Herkunft von Zugangsdaten, Autorisierung und beobachtbares Verhalten. Anbieter können zusammenhängende Konten, ungewöhnliche Anfrageprofile, Zahlungsanomalien und schnellen Verbrauch nach der Registrierung erkennen. Anwendungsbetreiber können einschränken, was ihre eigenen Endpunkte akzeptieren.
Open-Source-Maintainer können defensive Administration unterstützen, ohne jede Bereitstellung überwachen zu wollen. Sichere Standardwerte, auffällige Einrichtungswarnungen, Audit-Logs, Ausgabenkontrollen und klare Aufzeichnungen zum Modell-Routing machen den legitimen Betrieb sicherer. Sie beseitigen entschlossenen Missbrauch nicht.
Gerade die Neutralität der Software macht die Geschichte wichtig. Relay-Betreiber benötigen keine spezialisierte Untergrundinfrastruktur. Sie können Schaufenster mit denselben Gateway-Mustern aufbauen, die Unternehmen für Governance und Kostenkontrolle einsetzen.
Der Rabatt kann Betrug, Ersetzung und Datenexposition verschleiern
Ein Relay-Kunde kauft nicht nur unsichere Kapazität; er vertraut einem Vermittler Modellidentität, Verfügbarkeit und jeden übermittelten Prompt an.
Lenhard nennt mehrere gemeldete Quellen für Relay-Kapazitäten. Dazu gehören massenhaft erstellte Testkonten, Chargeback-Aktivitäten, gestohlene Zahlungskarten, Prepaid-Konten und offene Anwendungsendpunkte. Die Mischung dürfte je nach Betreiber und Zeitpunkt variieren.
Seine Untersuchung beweist nicht unabhängig, dass jedes erfasste Relay diese Methoden nutzt. Auch das Vorhandensein eines Rabatts belegt keinen Betrug. Autorisierte Wiederverkäufer, regionale Anbieter und Unternehmen mit ausgehandelten Kapazitäten können legitime Einsparungen anbieten.
Das Ausmaß einiger gemeldeter Rabatte wirft dennoch eine Frage nach der Herkunft auf. Ein nachhaltiger Dienst erfordert, dass jemand für Rechenressourcen bezahlt, geringere Margen akzeptiert oder Kapazität über eine Sondervereinbarung erhält. Käufer sollten fragen, welche Erklärung zutrifft.
Ein glaubwürdiger Vermittler sollte seine juristische Person nennen und klare Nutzungsbedingungen bereitstellen. Er sollte erklären, welche Anbieter die Modelle liefern und ob der Weiterverkauf autorisiert ist. Er sollte die Prompt-Aufbewahrung, Unterauftragsverarbeiter, Meldung von Sicherheitsvorfällen und Kontokündigung dokumentieren.
Käufer sollten außerdem eine verlässliche Modellverifizierung verlangen. Eine Anzeige in einem Relay-Dashboard reicht nicht aus. Die Ausgabequalität kann sinken, wenn der Betreiber ein kleineres Modell einsetzt, überlastete Kanäle nutzt oder Anbieter ohne Ankündigung wechselt.
Modellersetzung schafft mehr als ein Leistungsproblem. Teams können eine Anwendung mit einem Modell bewerten und unwissentlich mit einem anderen bereitstellen. Sicherheitsverhalten, Kontextverarbeitung, Tool-Nutzung und strukturierte Ausgabe können sich dann ohne Code-Update ändern.
Die Verfügbarkeit bringt eine ähnliche Unsicherheit mit sich. Pools aus Zugangsdaten können Ausfälle zunächst verschleiern, weil der Verkehr auf überlebende Konten verlagert wird. Koordinierte Durchsetzung durch Anbieter kann jedoch viele zusammenhängende Konten gleichzeitig deaktivieren.
Ein Relay kann mitsamt seinen Kundenguthaben und seiner Betriebshistorie verschwinden. Käufer haben möglicherweise nur begrenzte vertragliche Rechtsmittel, insbesondere über verschiedene Rechtsräume hinweg. Dadurch lassen sich die scheinbaren Einsparungen nur schwer mit den Kosten einer Unterbrechung oder Migration vergleichen.
Der Datenschutz ist das größte Anliegen. Jeder Prompt durchläuft Infrastruktur, die vom Relay oder seinem Upstream-Pool kontrolliert wird. Verschlüsselung schützt den Verkehr während der Übertragung, aber der Proxy muss auf den Anfrageinhalt zugreifen, um ihn weiterzuleiten oder zu transformieren.
Entwickler, die Coding-Agenten nutzen, können mehr als einzelne Ausschnitte offenlegen. Agent-Sitzungen können vollständige Dateien, Abhängigkeitsinformationen, interne URLs, Datenbankstrukturen und Authentifizierungslogik umfassen. Selbst harmlose Debugging-Anfragen können offenlegen, wie ein System organisiert ist.
Eine akademische Studie zu Credential-Leaks aus dem Jahr 2026 verdeutlicht die umfassendere Schwachstelle bei LLM-verbundenen Anwendungen. Forschende untersuchten 444 iOS-Apps und fanden in 282 von ihnen ausnutzbare Zugangsdaten.
Die Forschenden identifizierten drei Leak-Muster. Die Offenlegung JWT-basierter Tokens machte 48 Prozent aus, nicht authentifizierte Backend-Proxys 33 Prozent und API-Schlüssel im Klartext 19 Prozent. Diese Kategorien zeigen, dass ein Angreifer Kapazität erhalten kann, ohne einen herkömmlichen Anbieter-Schlüssel zu finden.
Nach einer verantwortungsvollen Offenlegung überprüften die Forschenden die verwundbaren Anwendungen drei Monate später erneut. Nur 28 Prozent hatten das gemeldete Problem behoben, während 72 Prozent weiterhin ausnutzbar blieben. Anhaltende Probleme bei Backend- und Token-Design verlangsamten die Behebung.
Diese Studie beweist nicht, dass die Relay-Betreiber in Lenhard’s Bericht genau diese Apps ausgenutzt haben. Sie belegt jedoch einen beträchtlichen Pool technisch ausnutzbarer LLM-Kapazität. Nicht authentifizierte Proxys sind besonders relevant, weil sie ohne Offenlegung eines Rohschlüssels aufgerufen werden können.
Käufer sehen sich zudem rechtlicher und vertraglicher Unsicherheit gegenüber. Ein Kunde weiß möglicherweise nicht, dass seine Anfragen gegen die Bedingungen eines Upstream-Anbieters verstoßen. Eine Unterbrechung kann den Kunden dennoch treffen, unabhängig davon, wer die Vereinbarung ursprünglich verletzt hat.
Geografische Beschränkungen verkomplizieren das Bild. Einige Nutzer wenden sich an Relays, weil direkter Modellzugang in ihrer Region nicht verfügbar ist. Relays verwandeln diese ungedeckte Nachfrage in einen funktionierenden Endpunkt, beseitigen jedoch keine Export-, Vertrags- oder regulatorischen Einschränkungen.
Modelldestillation fügt eine weitere umstrittene Dimension hinzu. Lenhard zitiert Forenteilnehmer, die behaupteten, einige kommerzielle Käufer nutzten weitergeleitete Ausgaben, um inländische Modelle zu trainieren. Diese Kommentare wurden aus einer Betreiber-Community übersetzt und nicht unabhängig überprüft.
Destillation selbst ist eine breit angewandte technische Praxis. Ein kleineres Modell lernt Muster aus den Ausgaben eines anderen Systems oder aus verwandten Trainingssignalen. Ob eine bestimmte Nutzung zulässig ist, hängt von den Zugangsbedingungen, Datenrechten und der genauen Methode ab.
Die am besten vertretbare Schlussfolgerung ist enger gefasst als die spektakulärste Behauptung. Ein Relay schafft einen undurchsichtigen Kontrollpunkt zwischen Nutzern und Modellanbietern. Diese Intransparenz ermöglicht mehrere Risiken, selbst wenn der Kunde nie beabsichtigte, an Betrug teilzunehmen.
Der zentrale Konflikt lautet legitimer Zugang versus verborgene Herkunft
Der bestimmende Konflikt des Relay-Markts ist nicht Open Source versus Closed Source; es geht um bequemen Zugang versus überprüfbare Autorisierung.
Offizielle APIs geben Kunden eine direkte vertragliche Beziehung zu einem Modellanbieter. Diese Beziehung beseitigt nicht jede Sorge um Datenschutz oder Zuverlässigkeit. Sie schafft jedoch klarere Verantwortlichkeiten für Abrechnung, Modellzugang, Sicherheitsdokumentation und Support.
Ein Relay fügt mindestens eine weitere Partei ein. Kontohändler und Pools können weitere hinzufügen. Jede Ebene kann die Verfügbarkeit oder lokale Nutzbarkeit verbessern, doch jede Ebene erschwert die Prüfung von Herkunft und Rechenschaftspflicht.
Diese Gegenüberstellung erklärt, warum der Preis allein ein schlechter Vergleichsmaßstab ist. Ein offizieller Endpunkt und ein undurchsichtiges Relay können syntaktisch ähnliche Antworten zurückgeben. Sie bieten nicht dieselbe Nachweiskette für Zugangsdaten, Prompts, Modellidentität oder Kundengelder.
Autorisierte Gateways nehmen eine legitime Zwischenposition ein. Ein Unternehmen kann genehmigte Konten zentralisieren, um Budgets durchzusetzen und die Nutzung zu überwachen. Ein regionaler Anbieter kann Kapazität im Rahmen einer dokumentierten Vereinbarung weiterverkaufen. Eine Enterprise-Plattform kann zwischen Modellen routen, die ihr Kunde ausgewählt hat.
Das Unterscheidungsmerkmal sind Belege. Autorisierte Betreiber können ihre Upstream-Beziehungen, vertragliche Rolle, Sicherheitskontrollen und Datenpraktiken offenlegen. Kunden können diese Angaben anhand von Vereinbarungen, Audit-Berichten, Dokumentation und Support-Kanälen bewerten.
Undurchsichtige Betreiber verlangen von Käufern, Legitimität aus Verfügbarkeit oder dem Ruf in der Community abzuleiten. Keines der beiden Signale beweist eine Autorisierung. Ein großer Pool an Zugangsdaten kann die Verfügbarkeit aufrechterhalten, selbst wenn einzelne Konten wiederholt gesperrt werden.
Community-Bewertungen können offensichtliche Betrugsfälle identifizieren, aber Rezensenten können nicht jede Upstream-Anfrage beobachten. Ein Relay kann während der Tests ehrlich arbeiten und seine Beschaffung später ändern. Es kann auch autorisierte Kapazität mit fragwürdigen Fallback-Kanälen kombinieren.
Anbieter stehen daher vor einer schwierigen Durchsetzungsentscheidung. Aggressive Kontokontrollen können die Kosten des Missbrauchs erhöhen. Dieselben Kontrollen können legitime Entwickler ausschließen, insbesondere solche mit gemeinsam genutzten Netzwerken, internationalen Zahlungsmethoden oder automatisierten Workflows.
Identitätsprüfung erzeugt einen weiteren Verlagerungseffekt. Wenn direkte Konten schwieriger zu erstellen sind, können Angreifer nach offengelegten Anwendungsendpunkten oder etablierten Konten suchen. Lenhard prognostiziert, dass eine stärkere Verifizierung durch Anbieter den Missbrauch in die Anwendungsebene verlagern wird.
Diese Prognose sollte nicht als garantiert gelten. Bessere Kontrollen können den Missbrauch insgesamt reduzieren, wenn Anbieter Signale teilen und Ausgabenlimits verbessern. Angreifer weichen dennoch aus, wenn ein Weg weniger profitabel wird; daher bleibt Verlagerung eine ernste Möglichkeit.
Anwendungsbetreiber benötigen Abwehrmaßnahmen, die davon ausgehen, dass ihr Endpunkt getestet wird. Sie sollten Anfragen authentifizieren, enge Schemata durchsetzen, Parallelität begrenzen, Ausgaben für laufende Anfragen reservieren und Prompts ablehnen, die nicht zur vorgesehenen Aufgabe gehören.
Das Verhaltensmonitoring sollte Kontoalter, Anfragezeitpunkt, Modellauswahl, Netzwerksignale und abrupte Volumenänderungen prüfen. Kein einzelner Indikator ist ausschlaggebend. Kombinierte Signale können gewöhnliche Nutzung von automatisierter Extraktion oder Weiterverkaufsverkehr unterscheiden.
Teams sollten Notfallkontrollen außerhalb der betroffenen Anwendung vorhalten. Ein kompromittierter Dienst sollte nicht online bleiben müssen, bevor Administratoren Ausgaben stoppen können. Sperren auf Anbieterebene und unabhängige Budgetkontrollen bieten eine letzte Grenze.
Organisationen benötigen außerdem durchsuchbare Betriebsaufzeichnungen. Ingenieure, die verdächtige Nutzung untersuchen, müssen Bereitstellungsänderungen, Warnmeldungen, Rechnungen und Endpunktprotokolle schnell verknüpfen. Eine strukturierte Engineering-Wissensdatenbank kann diese Untersuchung verkürzen, ohne Sicherheitstelemetrie zu ersetzen.
Käufer tragen ebenfalls Verantwortung. Sie sollten erfassen, welche Anwendungen Relay-Endpunkte nutzen und welche Daten diese Anwendungen übertragen. Geheimnisse, proprietärer Code, personenbezogene Daten und Kundendokumente sollten keinen nicht verifizierten Proxy passieren.
Sie sollten außerdem einen Ausstieg einplanen. Ein kompatibler Endpunkt erleichtert die erste Einführung, doch Modellverhalten und Authentifizierungsdetails können sich dennoch unterscheiden. Das Testen eines direkten Anbieters oder einer autorisierten Alternative verringert die Abhängigkeit von einem einzelnen Vermittler.
Das Ziel besteht nicht darin, Gateways abzuschaffen. Gateways lösen reale Probleme rund um Authentifizierung, Budgets, Routing und Beobachtbarkeit. Ziel ist vielmehr, Herkunft und Autorisierung so sichtbar zu machen, dass Käufer Infrastruktur von Arbitrage auf Basis von Missbrauch unterscheiden können.
Drei Signale werden zeigen, ob der Markt weiter wächst
Die nächste Phase wird durch durchsetzbare Ausgabenkontrollen, eine Verlagerung hin zu Anwendungsendpunkten und klarere Nachweise der Modellherkunft entschieden.
Das erste Signal ist, ob große Modellanbieter strikte, sofort wirksame Ausgabensperren einführen. Eine sinnvolle Sperre muss neue Anfragen stoppen, sobald ein festgelegtes Budget ausgeschöpft ist. Sie sollte außerdem Kapazität für bereits laufende Anfragen reservieren.
Willison plädiert ausdrücklich für Schlüssel, die ab einem von Entwicklern gewählten Schwellenwert nicht mehr funktionieren. Diese Funktion würde die schlimmsten Folgen einer kompromittierten Anwendung verringern. Sie würde außerdem Denial-of-Wallet-Angriffe und versehentliche Agentenschleifen begrenzen.
Warnmeldungen allein bestehen diesen Test nicht. Anbieter benötigen harte Limits auf sinnvollen Ebenen, einschließlich Projekt, Schlüssel, Modell und Zeitfenster. Kunden sollten sie konfigurieren können, ohne ein separates System zur Abrechnungskontrolle bauen zu müssen.
Wenn strikte Sperren zum Standard werden, wird die Grundlage für vermeidbare Verluste schwächer. Relay-Betreiber könnten weiterhin kostenlose Konten oder gestohlene Zugangsdaten ausnutzen, doch jedes Konto würde weniger nutzbare Kapazität bieten. Pools bräuchten mehr Bestand und einen höheren operativen Aufwand.
Das zweite Signal ist ein Anstieg von Angriffen auf Endpunkte der Anwendungsebene. Anbieter verstärken Identitäts-, Zahlungs- und Verhaltenskontrollen rund um direkte Konten. Angreifer werden prüfen, ob Support-Bots, mobile Backends und öffentliche KI-Funktionen weiterhin leichtere Ziele darstellen.
Forscher können diese Verschiebung anhand von Offenlegungen, Honeypots, Zugangsdaten-Telemetrie und Missbrauchsmeldungen messen. Anwendungsunternehmen können zudem irrelevante Prompts, ungewöhnliche Parallelität, kontinuierlichen Datenverkehr oder Anfragen beobachten, die unmittelbar nach der Registrierung eintreffen.
Ein deutlicher Anstieg würde Lenhards Warnung vor einer Verlagerung stützen. Stagnierender oder rückläufiger Missbrauch von Anwendungen würde sie abschwächen, insbesondere wenn Anbieter auch weniger betrügerische Konten melden. Öffentliche Daten werden unvollständig bleiben, da viele Betroffene Verluste nicht offenlegen.
Das dritte Signal ist, ob Käufer überprüfbares Routing und Autorisierung verlangen. Relay-Verzeichnisse konkurrieren derzeit stark über Zugang und Zuverlässigkeit. Der Markt könnte sich verändern, wenn Unternehmenskunden auf signierten Anbieterbeziehungen, Modellattestierungen und prüfbaren Datenrichtlinien bestehen.
Werkzeuge zur Modellherkunft müssen nicht jedes geheime Zugangstoken offenlegen. Sie könnten signierte Routing-Aufzeichnungen, stabile Modellkennungen oder für Kunden sichtbare Audit-Trails bereitstellen. Unabhängige Bewertungen könnten überprüfen, ob ein Betreiber seine erklärte Routing-Richtlinie einhält.
Wenn sich diese Praktiken verbreiten, lassen sich legitime Aggregatoren leichter von undurchsichtigen Relays unterscheiden. Wenn Käufer weiterhin Endpunkte ohne Herkunftsprüfung wählen, behalten niedrigschwellige Wiederverkäufer ihren Informationsvorsprung.
Entwickler sollten handeln, bevor diese Marktsignale eindeutig werden. Prüfen Sie jeden öffentlichen LLM-Endpunkt, einschließlich Support-Tools und mobiler Backends. Wenden Sie überall dort harte Parallelitätslimits und unabhängige Ausgabenkontrollen an, wo der Anbieter sie ermöglicht.
Unternehmenskäufer sollten jeden KI-Anfragepfad von der Benutzeroberfläche bis zum endgültigen Modellanbieter nachverfolgen. Kann ein Vermittler seine Rolle nicht erklären, sollte diese Ungewissheit als Sicherheitsbefund behandelt werden.
Simon Willisons Warnung macht aus einer fernen Graumarktgeschichte eine unmittelbare Frage für die Technik. Kann Ihre Anwendung Missbrauch stoppen, bevor ihre Zugangsdaten, Prompts oder ihr Budget zum Bestand anderer werden?
