ARC
Preise
Discord
Techniker sprechenGratis starten
Gratis starten
ARCvon FenxLabsCollective Intelligence

Plattform

  • So funktioniert es
  • Individuelles Routing und Governance
  • Anwendungsfälle
  • Beispielarchitekturen

Betriebsmodelle

  • Hosted Platform
  • Managed Service
  • Self-hosted Licence
  • Für ISVs
  • Portal öffnen

Leistungen

  • Assessment und Planung
  • Architektur und Integration
  • Model Adaptation
  • EU-AI-Act-Readiness
  • Betrieb im Managed Service

Ressourcen

  • Kostenrechner
  • Ansätze vergleichen
  • Preise
  • FAQ
  • Transparenz
  • Loslegen
  • Discord-Community

Rechtliches

  • Datenschutzerklärung
  • Allgemeine Geschäftsbedingungen
  • Unterauftragsverarbeiter
  • Barrierefreiheit

Für Privatpersonen

  • FenxChat

FenxLabs. KvK 91762782.

Herengracht 320, 1016 CE Amsterdam, Netherlands

+31 85 060 5273contact@fenxlabs.ai

© 2026 FenxLabs. Alle Rechte vorbehalten.

Entscheiden Sie, wo die Modellrichtlinie liegt

Vier Dinge trennen eine Control Plane von einem Gateway, einem Cloud-KI-Stack oder einer Eigenentwicklung: Ihre Netzgrenze, Ihre vorhandenen Modelle, Ihre Daten und die Stelle, an der die Gebühr anfällt.

Techniker sprechenGratis starten

Vier Fragen, die die Ansätze trennen

Wo FenxARC™ läuft, was es erreichen kann und wie FenxLabs bezahlt wird, entscheidet jeder Ansatz anders. Prüfen Sie alle vier an Ihrer eigenen engeren Auswahl.

Läuft der Router in Ihrem Netz?

Die Verarbeitung von ARC-Anfragen läuft in Ihrer VPC, auf Ihrer eigenen Hardware oder vollständig ohne Netzverbindung. Interne Routen können in Ihrem Netz bleiben; eine freigegebene externe Route erhält weiterhin den Kontext, den sie braucht.

Self-hosted Licence. Die Hosted Platform läuft auf der Infrastruktur von FenxLabs.

Routet er zu den Modellen, die Sie bereits betreiben?

Betrugsbewertung, Bedarfsprognose, Dokumentenklassifikation. Die Machine-Learning- und Deep-Learning-Modelle, die Sie bereits betreiben, werden neben Ihren Sprachmodellen zu Routing-Zielen.

Self-hosted Licence.

Liegt Ihr Vektorspeicher dahinter?

Binden Sie den Vektorspeicher direkt an den Router an. Er steht zwischen den Modellen und den Daten, und ein Modell erreicht nur das, wofür es eine Berechtigung hat.

Self-hosted Licence.

Wo nimmt der Anbieter seine Gebühr?

Inferenz bleibt eine direkte Beziehung zwischen Ihnen und Ihren Anbietern, zu deren Konditionen. Wir nehmen darauf keine Marge.

FenxLabs verkauft keine Inferenz weiter und unterhält keine Geschäftsbeziehung zu einem Modellanbieter. Der Router hat keinen geschäftlichen Grund, ein Ziel einem anderen vorzuziehen.

Drei dieser vier gehören zur Self-hosted Licence. Wo ARC läuft, ist die eine Entscheidung, was es durchsetzt, die andere.

Wählen, wo ARC läuftSelf-hosted Licence ansehenWo FenxLabs seine Gebühr erhebt

ARC regelt die Modellebene, nicht Ihren gesamten KI-Stack

ARC regelt, wie Nutzer, Anwendungen und Agenten auf Modelle, Tools und freigegebene Datenquellen zugreifen. Nicht geregelt werden das Schlussfolgern eines Agenten, seine Planung, die Anwendungslogik, die Laufzeitumgebung und die geschäftliche Verantwortung.

Anwendungen behalten ihre Abläufe. Anbieter liefern weiterhin Inferenz. ARC prüft jede geregelte Anfrage gegen die aktive Liste, wendet Ihre Regeln zu Zulässigkeit und Datenschutz an und bringt dann in eine Rangfolge, was diese Prüfung übersteht.

Eine Liste bündelt die Modelle, Tools und Regeln, die für ein Team oder einen Anwendungsfall freigegeben sind.

So wird eine Anfrage behandelt
Fünf Ansätze

Wählen Sie einen Betriebsansatz

Sie unterscheiden sich darin, wo die maßgebliche Regel liegt und wer dafür einsteht, dass sie stimmt.

Wo jeder der fünf Betriebsansätze den Endpunkt, die Regeln, die Freigabe je Team, die Datenschutzbehandlung und die Anbieterbeziehung verortet, und wer jeweils dafür einsteht.
Worauf es ankommtDirekte AnbieterintegrationenAnbieter-SDKs, aus Ihrem eigenen Code aufgerufenCloud-KI-PlattformZum Beispiel AWS Bedrock, Azure AIGateway oder RouterZum Beispiel LiteLLM, Portkey, HeliconeEigenentwicklungARC
Ein Endpunkt vor jedem Modell○Sie bauen esJeder Anbieter wird einzeln in der Anwendung integriert.◐Je nach ProduktInnerhalb der Dienste dieser Cloud und der daran angebundenen Endpunkte.●EingebautEin gemeinsamer Anfrageweg ist der Zweck dieser Kategorie.○Sie bauen esSie schreiben den Endpunkt und halten ihn am Laufen.●EingebautEine OpenAI-kompatible Base-URL für alles auf der Liste.
Regeln, die außerhalb des Anwendungscodes liegen○Sie bauen esDie Regeln stecken in jedem Workload, der einen Anbieter aufruft.◐Je nach ProduktMeist geteilt zwischen Cloud-Diensten und Anwendungskonfiguration.◐Je nach ProduktWie viel Regelwerk das Gateway hält, unterscheidet sich je Produkt.○Sie bauen esWas Ihr Team baut und aktuell hält, während sich Modelle ändern.●EingebautListen, kundendefinierte Kennzeichen und Routing-Regeln, auf der Modellebene.
Eine eigene freigegebene Menge je Team○Sie bauen esDurchgesetzt von dem, der die jeweilige Integration schreibt.◐Je nach ProduktHängt davon ab, wie diese Plattform Mandanten und Zugriff abbildet.◐Je nach ProduktHängt vom Produkt ab und davon, wie weit sein Regelmodell reicht.○Sie bauen esVon Ihnen zu entwerfen und im Gleichschritt zu halten, wenn sich Teams ändern.●EingebautEine Liste trägt die für dieses Team freigegebenen Modelle, Tools und Regeln.
Datenschutz geklärt, bevor ein Modell gewählt wird○Sie bauen esWas jede Anwendung prüft, bevor sie nach außen ruft.◐Je nach ProduktHängt von den Diensten vor dem Modellaufruf ab.◐Je nach ProduktHängt davon ab, ob das Produkt Regeln vor dem Routing prüft.○Sie bauen esVon Ihnen zu definieren und einem Prüfer zu belegen.●EingebautIhre Klassen entscheiden über die Zulässigkeit, die Rangfolge ordnet nur, was übrig bleibt.
Ihre eigenen Anbieterkonten und Preise●EingebautSie schließen mit jedem Anbieter direkt ab.◐Je nach ProduktModellkosten landen meist auf dem Cloud-Konto.◐Je nach ProduktOb die Anbieterabrechnung durchgereicht wird, unterscheidet sich je Produkt.●EingebautSie schließen mit jedem Anbieter direkt ab.●EingebautDie Inferenz bleibt zwischen Ihnen und Ihren Anbietern, zu deren Preisen.
Details lesenSo wird eine Anfrage behandelt
Zu vergleichende Ansätze

Wählen Sie eine oder zwei. Die Antworten erscheinen darunter, ein Kriterium nach dem anderen.

Ein Endpunkt vor jedem Modell

Direkte Anbieterintegrationen · Anbieter-SDKs, aus Ihrem eigenen Code aufgerufen
○Sie bauen esJeder Anbieter wird einzeln in der Anwendung integriert.
Cloud-KI-Plattform · Zum Beispiel AWS Bedrock, Azure AI
◐Je nach ProduktInnerhalb der Dienste dieser Cloud und der daran angebundenen Endpunkte.
Gateway oder Router · Zum Beispiel LiteLLM, Portkey, Helicone
●EingebautEin gemeinsamer Anfrageweg ist der Zweck dieser Kategorie.
Eigenentwicklung
○Sie bauen esSie schreiben den Endpunkt und halten ihn am Laufen.
ARC
●EingebautEine OpenAI-kompatible Base-URL für alles auf der Liste.

Regeln, die außerhalb des Anwendungscodes liegen

Direkte Anbieterintegrationen · Anbieter-SDKs, aus Ihrem eigenen Code aufgerufen
○Sie bauen esDie Regeln stecken in jedem Workload, der einen Anbieter aufruft.
Cloud-KI-Plattform · Zum Beispiel AWS Bedrock, Azure AI
◐Je nach ProduktMeist geteilt zwischen Cloud-Diensten und Anwendungskonfiguration.
Gateway oder Router · Zum Beispiel LiteLLM, Portkey, Helicone
◐Je nach ProduktWie viel Regelwerk das Gateway hält, unterscheidet sich je Produkt.
Eigenentwicklung
○Sie bauen esWas Ihr Team baut und aktuell hält, während sich Modelle ändern.
ARC
●EingebautListen, kundendefinierte Kennzeichen und Routing-Regeln, auf der Modellebene.

Eine eigene freigegebene Menge je Team

Direkte Anbieterintegrationen · Anbieter-SDKs, aus Ihrem eigenen Code aufgerufen
○Sie bauen esDurchgesetzt von dem, der die jeweilige Integration schreibt.
Cloud-KI-Plattform · Zum Beispiel AWS Bedrock, Azure AI
◐Je nach ProduktHängt davon ab, wie diese Plattform Mandanten und Zugriff abbildet.
Gateway oder Router · Zum Beispiel LiteLLM, Portkey, Helicone
◐Je nach ProduktHängt vom Produkt ab und davon, wie weit sein Regelmodell reicht.
Eigenentwicklung
○Sie bauen esVon Ihnen zu entwerfen und im Gleichschritt zu halten, wenn sich Teams ändern.
ARC
●EingebautEine Liste trägt die für dieses Team freigegebenen Modelle, Tools und Regeln.

Datenschutz geklärt, bevor ein Modell gewählt wird

Direkte Anbieterintegrationen · Anbieter-SDKs, aus Ihrem eigenen Code aufgerufen
○Sie bauen esWas jede Anwendung prüft, bevor sie nach außen ruft.
Cloud-KI-Plattform · Zum Beispiel AWS Bedrock, Azure AI
◐Je nach ProduktHängt von den Diensten vor dem Modellaufruf ab.
Gateway oder Router · Zum Beispiel LiteLLM, Portkey, Helicone
◐Je nach ProduktHängt davon ab, ob das Produkt Regeln vor dem Routing prüft.
Eigenentwicklung
○Sie bauen esVon Ihnen zu definieren und einem Prüfer zu belegen.
ARC
●EingebautIhre Klassen entscheiden über die Zulässigkeit, die Rangfolge ordnet nur, was übrig bleibt.

Ihre eigenen Anbieterkonten und Preise

Direkte Anbieterintegrationen · Anbieter-SDKs, aus Ihrem eigenen Code aufgerufen
●EingebautSie schließen mit jedem Anbieter direkt ab.
Cloud-KI-Plattform · Zum Beispiel AWS Bedrock, Azure AI
◐Je nach ProduktModellkosten landen meist auf dem Cloud-Konto.
Gateway oder Router · Zum Beispiel LiteLLM, Portkey, Helicone
◐Je nach ProduktOb die Anbieterabrechnung durchgereicht wird, unterscheidet sich je Produkt.
Eigenentwicklung
●EingebautSie schließen mit jedem Anbieter direkt ab.
ARC
●EingebautDie Inferenz bleibt zwischen Ihnen und Ihren Anbietern, zu deren Preisen.
Details lesen
So wird eine Anfrage behandelt
„Eingebaut“ heißt, der Ansatz liefert es mit. „Sie bauen es“ heißt, der Ansatz überlässt es Ihrem Team. „Je nach Produkt“ heißt, dass es innerhalb der Kategorie tatsächlich abweicht; das ist eine Frage für Ihre engere Auswahl und keine, die diese Seite für Sie beantworten kann.

Dieselben fünf, ausführlich

Beste Eignung, Ort der Regeln, Modellauswahl, Aufwand für das Team und wichtigster Kompromiss, für jeden der fünf Betriebsansätze.
FrageDirekte AnbieterintegrationenAnbieter-SDKs, aus Ihrem eigenen Code aufgerufenCloud-KI-PlattformZum Beispiel AWS Bedrock, Azure AIGateway oder RouterZum Beispiel LiteLLM, Portkey, HeliconeEigenentwicklungARC
Passt am besten zuWenige stabile Workloads, an einen Anbieter gebunden.Unternehmen, die sich konsequent auf ein Cloud-Betriebsmodell festlegen.Teams, die vor allem einen gemeinsamen Endpunkt, Anbieterabstraktion und Verkehrssteuerung brauchen.Teams mit ungewöhnlichen Anforderungen und der Kapazität, ein Control-Plane-Produkt selbst zu verantworten.Unternehmen, die eine geregelte Auswahl über Modelle, Tools, Anbieter und Umgebungen hinweg wollen.
Ort der RegelnJede Anwendung oder jede Anbieterkonfiguration.Cloud-Dienste plus Konfiguration in der Anwendung.Gateway-Konfiguration und Anwendungslogik.Ihr Code und Ihre Betriebsumgebung.Listen, kundendefinierte Tags und Routing-Richtlinien auf der Modellebene.
ModellauswahlBeschränkt auf den angebundenen Anbieter und die Logik der Anwendung selbst.Hängt von der Plattform und den daran angebundenen Endpunkten ab.Hängt vom Routing des Gateways und den unterstützten Anbietern ab.Alles, was Ihr Team integriert und am Laufen hält.Die auf der aktiven Liste freigegebenen Modelle und Tools.
Aufwand für das TeamIntegrationen und Regeln werden in jedem Workload gepflegt.Governance richtet sich nach den Diensten und Grenzen dieser Cloud.Routing-Regeln werden von Ihrem Team definiert, getestet und gepflegt.Design, Sicherheit, Bewertung, Betrieb und Änderungen, alles bei Ihnen.Die Richtlinien und die Anbieterbeziehungen bleiben bei Ihnen. ARC wendet diese Richtlinien bei jeder geregelten Anfrage an.
Wichtigster KompromissZunächst einfach. Änderungen vervielfachen sich, wenn Anbieter und Teams wachsen.Breite Plattformintegration, wobei die Plattform die Entscheidungen prägt.Nützliche Anbindung. Governance-Tiefe und Betriebsoptionen unterscheiden sich je Produkt.Maximale Anpassbarkeit gegen dauerhafte Produkt- und Betriebsverantwortung.Eine weitere Ebene, die integriert und geregelt werden muss.
Details lesenSo wird eine Anfrage behandelt
Zu vergleichende Ansätze im Detail

Wählen Sie eine oder zwei. Die Antworten erscheinen darunter, ein Kriterium nach dem anderen.

Passt am besten zu

Direkte Anbieterintegrationen · Anbieter-SDKs, aus Ihrem eigenen Code aufgerufen
Wenige stabile Workloads, an einen Anbieter gebunden.
Cloud-KI-Plattform · Zum Beispiel AWS Bedrock, Azure AI
Unternehmen, die sich konsequent auf ein Cloud-Betriebsmodell festlegen.
Gateway oder Router · Zum Beispiel LiteLLM, Portkey, Helicone
Teams, die vor allem einen gemeinsamen Endpunkt, Anbieterabstraktion und Verkehrssteuerung brauchen.
Eigenentwicklung
Teams mit ungewöhnlichen Anforderungen und der Kapazität, ein Control-Plane-Produkt selbst zu verantworten.
ARC
Unternehmen, die eine geregelte Auswahl über Modelle, Tools, Anbieter und Umgebungen hinweg wollen.

Ort der Regeln

Direkte Anbieterintegrationen · Anbieter-SDKs, aus Ihrem eigenen Code aufgerufen
Jede Anwendung oder jede Anbieterkonfiguration.
Cloud-KI-Plattform · Zum Beispiel AWS Bedrock, Azure AI
Cloud-Dienste plus Konfiguration in der Anwendung.
Gateway oder Router · Zum Beispiel LiteLLM, Portkey, Helicone
Gateway-Konfiguration und Anwendungslogik.
Eigenentwicklung
Ihr Code und Ihre Betriebsumgebung.
ARC
Listen, kundendefinierte Tags und Routing-Richtlinien auf der Modellebene.

Modellauswahl

Direkte Anbieterintegrationen · Anbieter-SDKs, aus Ihrem eigenen Code aufgerufen
Beschränkt auf den angebundenen Anbieter und die Logik der Anwendung selbst.
Cloud-KI-Plattform · Zum Beispiel AWS Bedrock, Azure AI
Hängt von der Plattform und den daran angebundenen Endpunkten ab.
Gateway oder Router · Zum Beispiel LiteLLM, Portkey, Helicone
Hängt vom Routing des Gateways und den unterstützten Anbietern ab.
Eigenentwicklung
Alles, was Ihr Team integriert und am Laufen hält.
ARC
Die auf der aktiven Liste freigegebenen Modelle und Tools.

Aufwand für das Team

Direkte Anbieterintegrationen · Anbieter-SDKs, aus Ihrem eigenen Code aufgerufen
Integrationen und Regeln werden in jedem Workload gepflegt.
Cloud-KI-Plattform · Zum Beispiel AWS Bedrock, Azure AI
Governance richtet sich nach den Diensten und Grenzen dieser Cloud.
Gateway oder Router · Zum Beispiel LiteLLM, Portkey, Helicone
Routing-Regeln werden von Ihrem Team definiert, getestet und gepflegt.
Eigenentwicklung
Design, Sicherheit, Bewertung, Betrieb und Änderungen, alles bei Ihnen.
ARC
Die Richtlinien und die Anbieterbeziehungen bleiben bei Ihnen. ARC wendet diese Richtlinien bei jeder geregelten Anfrage an.

Wichtigster Kompromiss

Direkte Anbieterintegrationen · Anbieter-SDKs, aus Ihrem eigenen Code aufgerufen
Zunächst einfach. Änderungen vervielfachen sich, wenn Anbieter und Teams wachsen.
Cloud-KI-Plattform · Zum Beispiel AWS Bedrock, Azure AI
Breite Plattformintegration, wobei die Plattform die Entscheidungen prägt.
Gateway oder Router · Zum Beispiel LiteLLM, Portkey, Helicone
Nützliche Anbindung. Governance-Tiefe und Betriebsoptionen unterscheiden sich je Produkt.
Eigenentwicklung
Maximale Anpassbarkeit gegen dauerhafte Produkt- und Betriebsverantwortung.
ARC
Eine weitere Ebene, die integriert und geregelt werden muss.
Details lesen
So wird eine Anfrage behandelt
Fähigkeiten unterscheiden sich je Produkt und ändern sich mit der Zeit. Nutzen Sie diese Übersicht, um einen Betriebsansatz zu wählen, und prüfen Sie die konkreten Anforderungen in der Evaluierung.

Die Zulässigkeit wird vor der Rangfolge geprüft, deshalb kann der Ordnungsschritt kein Ziel erreichen, das die Richtlinie ausgeschlossen hat.

So wird eine Anfrage behandelt

Fragen Sie, bevor Sie sich festlegen

Diese Fragen trennen einen Betriebsansatz von einer Funktionsliste. Stellen Sie sie jeder Option Ihrer engeren Auswahl, ARC eingeschlossen.

  • Können wir Modelle und Tools über dieselbe Anfrageregel steuern?
  • Kann jedes Team eine freigegebene Menge haben, ohne sie in jeder Anwendung fest zu verdrahten?
  • Können wir unsere direkten Anbieterbeziehungen und Preise behalten?
  • Läuft dasselbe Regelmodell Hosted, Managed und Self-hosted?
  • Was muss unser Team nach der ersten Integration bauen, testen und betreiben?

ARC ist nicht für jeden Workload nötig

Ein Anbieter, ein Modell und Kontrollen auf Anwendungsebene decken vielleicht alles ab, was Sie absehen können. Eine zweite Kontrollebene wäre dann Kosten ohne Gegenwert.

  • Ein Workload und ein Anbieter. Noch gibt es nichts zu routen.
  • Tracing, Evaluierung und Prompt-Versionierung. Kaufen Sie ein Werkzeug, das dafür gebaut ist.
  • Eine Route ändert, welche freigegebenen Ziele laufen. Sie macht kein Modell besser.

ARC ist für den Fall gebaut, in dem sich Workload-Kategorien, Modellauswahl, Datenschutzverarbeitung, Zugriffsregeln und Betriebsgrenzen über Teams hinweg ändern müssen, ohne jeden Workload neu zu schreiben.

Wo ARC in echten Umgebungen sitztWählen, wo ARC läuftWas es kostetARC in Ihre Software einbetten

ARC gegen Ihren heutigen Ansatz vergleichen

Bringen Sie einen Workload und eine Randbedingung mit. Wir sagen Ihnen, ob Routing für Sie etwas ändert.

Techniker sprechenGratis starten