Beslut, hvor modelpolitikken bor

Fire ting skiller en control plane fra en gateway, en cloud AI-stack eller en intern egenudvikling: din netværksgrænse, de modeller du allerede kører, dine data, og hvor gebyret tages.

Tal med en ingeniør Start gratis

Fire spørgsmål, der skiller tilgangene ad

Hvor FenxARC™ kører, hvad det kan nå, og hvordan FenxLabs bliver betalt, afgøres forskelligt i hver tilgang. Stil alle fire spørgsmål til din egen kortliste.

Kører routeren inde i dit netværk?

Behandlingen af anmodninger i ARC kører i din egen VPC, på din egen hardware eller helt air-gapped. Interne ruter kan blive inde i dit netværk; en godkendt ekstern rute modtager stadig den kontekst, den har brug for.

Self-hosted Licence. Hosted Platform kører på FenxLabs' infrastruktur.

Sender den videre til de modeller, du allerede kører?

Svindelscoring, efterspørgselsprognoser, dokumentklassificering. De machine learning- og deep learning-modeller, du allerede kører, bliver routingdestinationer side om side med dine sprogmodeller.

Self-hosted Licence.

Ligger din vektorlagring bag den?

Forbind vektorlagring direkte til routeren. Den sidder mellem modellerne og dataene, og en model når kun det, den har tilladelse til at se.

Self-hosted Licence.

Hvor tager leverandøren sit gebyr?

Inferens forbliver et direkte forhold mellem dig og dine udbydere, til deres takster. Vi tager ingen margin på det.

FenxLabs videresælger ingen inferens og har intet kommercielt forhold til nogen modelleverandør. Routeren har ingen kommerciel grund til at foretrække én destination frem for en anden.

Tre af de fire hører til Self-hosted Licence. Hvor ARC kører er én beslutning, og hvad det håndhæver er en anden.

Vælg, hvor ARC kører Se Self-hosted Licence Se, hvor FenxLabs tager sit gebyr

ARC styrer modellaget, ikke hele din AI-stack

ARC styrer, hvordan brugere, applikationer og agenter tilgår modeller, tools og godkendte datakilder. ARC styrer ikke en agents ræsonnement, planlægning, applikationslogik, runtime eller forretningsansvar.

Applikationer beholder deres workflows. Udbydere leverer fortsat inferens. ARC vurderer hver styret anmodning op mod den aktive liste, anvender dine regler for tilladelse og privatliv og rangordner derefter det, der er tilbage.

En liste samler de modeller, tools og regler, der er godkendt til et team eller en anvendelse.

Se, hvordan en anmodning håndteres

Fem tilgange

Vælg en driftstilgang

Det, der skiller dem, er hvor den styrende regel bor, og hvem der hænger på at holde den rigtig.

Hvor hver af de fem driftstilgange placerer endpointet, politikken, godkendelsen pr. team, privatlivshåndteringen og forholdet til udbyderen, og hvem der hænger på hver enkelt.
Det der skal til	Direkte udbyderintegrationerUdbyder-SDK'er, kaldt fra din egen kode	Cloud AI-platformFor eksempel AWS Bedrock, Azure AI	Gateway eller routerFor eksempel LiteLLM, Portkey, Helicone	Intern egenudvikling	ARC
Ét endpoint foran hver eneste model	Du bygger det selvHver udbyder integreres for sig, inde i applikationen.	Varierer pr. produktInden for den cloud-udbyders egne tjenester og de endpoints, der er koblet på.	IndbyggetEn fælles anmodningsvej er præcis det, kategorien findes for.	Du bygger det selvDu skriver endpointet, og du holder det kørende.	IndbyggetÉn OpenAI-kompatibel base-URL til alt på listen.
Politik, der bor uden for applikationskoden	Du bygger det selvReglerne sidder i hvert workload, der kalder en udbyder.	Varierer pr. produktOftest delt mellem cloud-tjenester og konfiguration i applikationen.	Varierer pr. produktHvor meget politik gatewayen holder, varierer fra produkt til produkt.	Du bygger det selvDet, dit team bygger, og holder ajour, efterhånden som modellerne skifter.	IndbyggetLister, kundedefinerede tags og routingpolitik, i modellaget.
Et forskelligt godkendt sæt pr. team	Du bygger det selvHåndhævet af den, der skriver hver integration.	Varierer pr. produktAfhænger af, hvordan platformen modellerer tenancy og adgang.	Varierer pr. produktAfhænger af produktet og af, hvor langt dets politikmodel rækker.	Du bygger det selvDit at designe, og dit at holde på linje, når teams ændrer sig.	IndbyggetEn liste bærer de modeller, tools og politikker, der er godkendt til det team.
Privatliv afklaret, før en model vælges	Du bygger det selvDet, hver applikation nu tjekker, før den kalder ud.	Varierer pr. produktAfhænger af de tjenester, der ligger foran modelkaldet.	Varierer pr. produktAfhænger af, om produktet vurderer politik før routing.	Du bygger det selvDit at definere, og dit at bevise over for en revisor.	IndbyggetDine klasser afgør tilladelsen, og rangordningen sorterer kun det, der er tilbage.
Dine egne udbyderaftaler og priser	IndbyggetDu indgår aftale direkte med hver udbyder.	Varierer pr. produktBetalingen for modeller lander som regel på cloud-kontoen.	Varierer pr. produktOm udbyderens afregning går igennem, varierer fra produkt til produkt.	IndbyggetDu indgår aftale direkte med hver udbyder.	IndbyggetInferens forbliver mellem dig og dine udbydere, til deres priser.
Læs detaljen					Se, hvordan en anmodning håndteres

Tilgange, der skal sammenlignes

Vælg en eller to. Svarene vises nedenfor, ét kriterium ad gangen.

Ét endpoint foran hver eneste model

Direkte udbyderintegrationer · Udbyder-SDK'er, kaldt fra din egen kode: Du bygger det selvHver udbyder integreres for sig, inde i applikationen.
Cloud AI-platform · For eksempel AWS Bedrock, Azure AI: Varierer pr. produktInden for den cloud-udbyders egne tjenester og de endpoints, der er koblet på.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone: IndbyggetEn fælles anmodningsvej er præcis det, kategorien findes for.
Intern egenudvikling: Du bygger det selvDu skriver endpointet, og du holder det kørende.
ARC: IndbyggetÉn OpenAI-kompatibel base-URL til alt på listen.

Politik, der bor uden for applikationskoden

Direkte udbyderintegrationer · Udbyder-SDK'er, kaldt fra din egen kode: Du bygger det selvReglerne sidder i hvert workload, der kalder en udbyder.
Cloud AI-platform · For eksempel AWS Bedrock, Azure AI: Varierer pr. produktOftest delt mellem cloud-tjenester og konfiguration i applikationen.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone: Varierer pr. produktHvor meget politik gatewayen holder, varierer fra produkt til produkt.
Intern egenudvikling: Du bygger det selvDet, dit team bygger, og holder ajour, efterhånden som modellerne skifter.
ARC: IndbyggetLister, kundedefinerede tags og routingpolitik, i modellaget.

Et forskelligt godkendt sæt pr. team

Direkte udbyderintegrationer · Udbyder-SDK'er, kaldt fra din egen kode: Du bygger det selvHåndhævet af den, der skriver hver integration.
Cloud AI-platform · For eksempel AWS Bedrock, Azure AI: Varierer pr. produktAfhænger af, hvordan platformen modellerer tenancy og adgang.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone: Varierer pr. produktAfhænger af produktet og af, hvor langt dets politikmodel rækker.
Intern egenudvikling: Du bygger det selvDit at designe, og dit at holde på linje, når teams ændrer sig.
ARC: IndbyggetEn liste bærer de modeller, tools og politikker, der er godkendt til det team.

Privatliv afklaret, før en model vælges

Direkte udbyderintegrationer · Udbyder-SDK'er, kaldt fra din egen kode: Du bygger det selvDet, hver applikation nu tjekker, før den kalder ud.
Cloud AI-platform · For eksempel AWS Bedrock, Azure AI: Varierer pr. produktAfhænger af de tjenester, der ligger foran modelkaldet.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone: Varierer pr. produktAfhænger af, om produktet vurderer politik før routing.
Intern egenudvikling: Du bygger det selvDit at definere, og dit at bevise over for en revisor.
ARC: IndbyggetDine klasser afgør tilladelsen, og rangordningen sorterer kun det, der er tilbage.

Dine egne udbyderaftaler og priser

Direkte udbyderintegrationer · Udbyder-SDK'er, kaldt fra din egen kode: IndbyggetDu indgår aftale direkte med hver udbyder.
Cloud AI-platform · For eksempel AWS Bedrock, Azure AI: Varierer pr. produktBetalingen for modeller lander som regel på cloud-kontoen.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone: Varierer pr. produktOm udbyderens afregning går igennem, varierer fra produkt til produkt.
Intern egenudvikling: IndbyggetDu indgår aftale direkte med hver udbyder.
ARC: IndbyggetInferens forbliver mellem dig og dine udbydere, til deres priser.

Læs detaljen

Se, hvordan en anmodning håndteres

»Indbygget« betyder, at tilgangen leverer det. »Du bygger det selv« betyder, at tilgangen overlader det til dit team. »Varierer pr. produkt« betyder, at det reelt er forskelligt inden for den kategori, og det er et spørgsmål, du skal tage med til en kortliste, ikke et denne side kan svare på for dig.

De samme fem, i fuld længde

Passer bedst til, hvor politikken bor, modelvalg, byrde for teamet og den vigtigste afvejning, for hver af de fem driftstilgange.
Spørgsmål	Direkte udbyderintegrationerUdbyder-SDK'er, kaldt fra din egen kode	Cloud AI-platformFor eksempel AWS Bedrock, Azure AI	Gateway eller routerFor eksempel LiteLLM, Portkey, Helicone	Intern egenudvikling	ARC
Passer bedst til	Et lille antal stabile workloads bundet til én udbyder.	Organisationer, der standardiserer hårdt på én cloud-driftsmodel.	Teams, der mest har brug for et fælles endpoint, abstraktion over udbydere og trafikkontrol.	Teams med usædvanlige krav og kapacitet til at eje et control plane-produkt.	Organisationer, der vil have et styret valg på tværs af modeller, tools, udbydere og miljøer.
Hvor politikken bor	Hver applikation eller hver udbyderkonfiguration.	Cloud-tjenester plus konfiguration i applikationen.	Konfiguration i gatewayen og logik i applikationen.	Din egen kode og dit eget driftsmiljø.	Lister, kundedefinerede tags og routingpolitik i modellaget.
Modelvalg	Begrænset til den tilkoblede udbyder og applikationens egen logik.	Afhænger af platformen og de endpoints, der er koblet på den.	Afhænger af gatewayens routing og understøttelse af udbydere.	Det, dit team integrerer og holder kørende.	De modeller og tools, der er godkendt på den aktive liste.
Byrde for teamet	Integrationer og politik vedligeholdes inde i hvert eneste workload.	Governance rettet ind efter den cloud-udbyders tjenester og grænser.	Routingpolitik defineret, testet og vedligeholdt af dit eget team.	Design, sikkerhed, evaluering, drift og forandring, det hele er dit.	Du ejer politikken og forholdet til udbyderne. ARC anvender den politik på hver styret anmodning.
Vigtigste afvejning	Simpelt i starten. Ændringerne bliver flere, efterhånden som udbydere og teams vokser.	Bred platformsintegration, hvor beslutningerne formes af netop den platform.	Nyttig forbindelse. Dybden i governance og valget af driftsmodel varierer fra produkt til produkt.	Maksimal tilpasning, sat op mod et vedvarende produkt- og driftsejerskab.	Endnu et lag at integrere og styre.
Læs detaljen					Se, hvordan en anmodning håndteres

Tilgange, der skal sammenlignes, i detaljer

Vælg en eller to. Svarene vises nedenfor, ét kriterium ad gangen.

Passer bedst til

Direkte udbyderintegrationer · Udbyder-SDK'er, kaldt fra din egen kode: Et lille antal stabile workloads bundet til én udbyder.
Cloud AI-platform · For eksempel AWS Bedrock, Azure AI: Organisationer, der standardiserer hårdt på én cloud-driftsmodel.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone: Teams, der mest har brug for et fælles endpoint, abstraktion over udbydere og trafikkontrol.
Intern egenudvikling: Teams med usædvanlige krav og kapacitet til at eje et control plane-produkt.
ARC: Organisationer, der vil have et styret valg på tværs af modeller, tools, udbydere og miljøer.

Hvor politikken bor

Direkte udbyderintegrationer · Udbyder-SDK'er, kaldt fra din egen kode: Hver applikation eller hver udbyderkonfiguration.
Cloud AI-platform · For eksempel AWS Bedrock, Azure AI: Cloud-tjenester plus konfiguration i applikationen.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone: Konfiguration i gatewayen og logik i applikationen.
Intern egenudvikling: Din egen kode og dit eget driftsmiljø.
ARC: Lister, kundedefinerede tags og routingpolitik i modellaget.

Modelvalg

Direkte udbyderintegrationer · Udbyder-SDK'er, kaldt fra din egen kode: Begrænset til den tilkoblede udbyder og applikationens egen logik.
Cloud AI-platform · For eksempel AWS Bedrock, Azure AI: Afhænger af platformen og de endpoints, der er koblet på den.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone: Afhænger af gatewayens routing og understøttelse af udbydere.
Intern egenudvikling: Det, dit team integrerer og holder kørende.
ARC: De modeller og tools, der er godkendt på den aktive liste.

Byrde for teamet

Direkte udbyderintegrationer · Udbyder-SDK'er, kaldt fra din egen kode: Integrationer og politik vedligeholdes inde i hvert eneste workload.
Cloud AI-platform · For eksempel AWS Bedrock, Azure AI: Governance rettet ind efter den cloud-udbyders tjenester og grænser.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone: Routingpolitik defineret, testet og vedligeholdt af dit eget team.
Intern egenudvikling: Design, sikkerhed, evaluering, drift og forandring, det hele er dit.
ARC: Du ejer politikken og forholdet til udbyderne. ARC anvender den politik på hver styret anmodning.

Vigtigste afvejning

Direkte udbyderintegrationer · Udbyder-SDK'er, kaldt fra din egen kode: Simpelt i starten. Ændringerne bliver flere, efterhånden som udbydere og teams vokser.
Cloud AI-platform · For eksempel AWS Bedrock, Azure AI: Bred platformsintegration, hvor beslutningerne formes af netop den platform.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone: Nyttig forbindelse. Dybden i governance og valget af driftsmodel varierer fra produkt til produkt.
Intern egenudvikling: Maksimal tilpasning, sat op mod et vedvarende produkt- og driftsejerskab.
ARC: Endnu et lag at integrere og styre.

Læs detaljen

Se, hvordan en anmodning håndteres

Funktionaliteten varierer fra produkt til produkt og ændrer sig over tid. Brug dette til at vælge en driftstilgang, og efterprøv derefter de konkrete krav under evalueringen.

Tilladelsen afgøres før rangordningen, så intet i sorteringstrinnet kan nå en destination, politikken har udelukket.

Se, hvordan en anmodning håndteres

Spørg, før du binder dig

De her spørgsmål skiller en driftstilgang fra en featureliste. Stil dem til hver eneste mulighed på kortlisten, ARC medregnet.

Kan vi styre modeller og tools gennem den samme anmodningspolitik?
Kan hvert team have sit eget godkendte sæt uden at hardkode det i hver applikation?
Kan vi beholde vores direkte aftaler og priser hos udbyderne?
Kan den samme politikmodel køre hosted, managed eller self-hosted?
Hvad skal vores eget team bygge, teste og drive efter den første integration?

ARC er ikke nødvendigt for hvert workload

Én udbyder, én model og kontroller på applikationsniveau kan dække alt, du kan se komme. Et ekstra kontrollag ville så være en omkostning uden afkast.

Ét workload og én udbyder. Endnu intet at sende videre imellem.
Tracing, evaluering og promptversionering. Køb et tool, der er bygget til det.
En rute ændrer, hvilke godkendte destinationer der kører. Den gør ikke nogen model bedre.

ARC er bygget til det tilfælde, hvor workloadkategorier, modelvalg, privatlivshåndtering, adgangspolitik og driftsgrænser skal kunne variere på tværs af teams, uden at hvert workload skrives om.

Se, hvor ARC sidder i rigtige miljøer Vælg, hvor ARC kører Hvad det koster Indlejr ARC i din software

Sammenlign ARC med den tilgang, du bruger i dag

Kom med et workload og en begrænsning. Så siger vi, om routing ændrer noget for dig.

Tal med en ingeniør Start gratis