ARC
Priser
Discord
Snakk med en ingeniørStart gratis
Start gratis
ARCav FenxLabsCollective Intelligence

Plattform

  • Slik virker det
  • Egen routing og governance
  • Bruksområder
  • Eksempelarkitekturer

Driftsformer

  • Hosted Platform
  • Managed Service
  • Self-hosted Licence
  • For ISV-er
  • Åpne portalen

Tjenester

  • Assessment og planlegging
  • Arkitektur og integrasjon
  • Model Adaptation
  • EU AI Act-readiness
  • Drift i Managed Service

Ressurser

  • Kostnadskalkulator
  • Sammenlign tilnærminger
  • Priser
  • Vanlige spørsmål
  • Åpenhet
  • Kom i gang
  • Discord-fellesskap

Juridisk

  • Personvernerklæring
  • Vilkår og betingelser
  • Underdatabehandlere
  • Tilgjengelighet

For privatpersoner

  • FenxChat

FenxLabs. KvK 91762782.

Herengracht 320, 1016 CE Amsterdam, Netherlands

+31 85 060 5273contact@fenxlabs.ai

© 2026 FenxLabs. Alle rettigheter forbeholdt.

Bestem hvor modellpolicyen bor

Fire ting skiller en control plane fra en gateway, en cloud AI-stack eller egen utvikling: nettverksgrensen din, de modellene du allerede kjører, dataene dine, og hvor gebyret tas.

Snakk med en ingeniørStart gratis

Fire spørsmål som skiller tilnærmingene

Hvor FenxARC™ kjører, hva det kan nå, og hvordan FenxLabs blir betalt, avgjøres ulikt i hver tilnærming. Still alle fire spørsmålene til din egen kortliste.

Kjører routeren inne i nettverket ditt?

Forespørselshåndteringen i ARC kjører inne i din egen VPC, på din egen maskinvare eller helt air-gapped. Interne ruter kan bli værende inne i nettverket ditt; en godkjent ekstern rute får fortsatt den konteksten den trenger.

Self-hosted Licence. Hosted Platform kjører på infrastrukturen til FenxLabs.

Sender den videre til de modellene du allerede kjører?

Svindelscoring, etterspørselsprognoser, dokumentklassifisering. Maskinlærings- og dyplæringsmodellene du allerede kjører, blir routingdestinasjoner ved siden av språkmodellene dine.

Self-hosted Licence.

Ligger vektorlagringen din bak den?

Koble vektorlagring direkte til routeren. Den står mellom modellene og dataene, og en modell når bare det den har tillatelse til å se.

Self-hosted Licence.

Hvor tar leverandøren gebyret sitt?

Inferens forblir et direkte forhold mellom deg og leverandørene dine, til deres priser. Vi tar ingen margin på det.

FenxLabs videreselger ingen inferens og har ingen kommersiell relasjon til noen modelleverandør. Routeren har ingen kommersiell grunn til å foretrekke én destinasjon framfor en annen.

Tre av de fire hører til Self-hosted Licence. Hvor ARC kjører er én beslutning, og hva det håndhever er en annen.

Velg hvor ARC kjørerUtforsk Self-hosted LicenceHvor FenxLabs tar honoraret sitt

ARC styrer modellaget, ikke hele AI-stacken din

ARC styrer hvordan brukere, applikasjoner og agenter når modeller, verktøy og godkjente datakilder. ARC styrer ikke en agents resonnering, planlegging, applikasjonslogikk, runtime eller forretningsansvar.

Applikasjoner beholder arbeidsflytene sine. Leverandører fortsetter å levere inferens. ARC vurderer hver styrte forespørsel mot den aktive listen, anvender reglene dine for tillatelse og personvern, og rangerer deretter det som er igjen.

En liste samler modellene, verktøyene og reglene som er godkjent for et team eller et bruksområde.

Se hvordan en forespørsel håndteres
Fem tilnærminger

Velg en driftstilnærming

Det som skiller dem, er hvor den styrende regelen bor, og hvem som henger på å holde den riktig.

Hvor hver av de fem driftstilnærmingene plasserer endepunktet, policyen, godkjenningen per team, personvernhåndteringen og forholdet til leverandøren, og hvem som henger på hver del.
Det som skal tilDirekte leverandørintegrasjonerLeverandørenes SDK-er, kalt fra din egen kodeCloud AI-plattformFor eksempel AWS Bedrock, Azure AIGateway eller routerFor eksempel LiteLLM, Portkey, HeliconeEgen utviklingARC
Ett endepunkt foran hver eneste modell○Du bygger detHver leverandør integreres for seg, inne i applikasjonen.◐Varierer per produktInnenfor den skyleverandørens egne tjenester og de endepunktene som er koblet på.●InnebygdEn felles forespørselsvei er nettopp det kategorien finnes for.○Du bygger detDu skriver endepunktet, og du holder det i gang.●InnebygdÉn OpenAI-kompatibel base-URL til alt på listen.
Policy som bor utenfor applikasjonskoden○Du bygger detReglene sitter i hvert workload som kaller en leverandør.◐Varierer per produktOftest delt mellom skytjenester og konfigurasjon i applikasjonen.◐Varierer per produktHvor mye policy gatewayen holder, varierer fra produkt til produkt.○Du bygger detDet teamet ditt bygger, og holder oppdatert etter hvert som modellene endrer seg.●InnebygdLister, kundedefinerte tagger og routingpolicy, i modellaget.
Et eget godkjent sett per team○Du bygger detHåndhevet av den som skriver hver integrasjon.◐Varierer per produktAvhenger av hvordan plattformen modellerer tenancy og tilgang.◐Varierer per produktAvhenger av produktet og av hvor langt policymodellen dets rekker.○Du bygger detDitt å utforme, og ditt å holde på linje når teamene endrer seg.●InnebygdEn liste bærer de modellene, verktøyene og policyene som er godkjent for det teamet.
Personvernet avklart før en modell velges○Du bygger detDet hver applikasjon sjekker før den kaller ut.◐Varierer per produktAvhenger av de tjenestene som ligger foran modellkallet.◐Varierer per produktAvhenger av om produktet vurderer policy før routing.○Du bygger detDitt å definere, og ditt å bevise overfor en revisor.●InnebygdKlassene dine avgjør tillatelsen, og rangeringen sorterer bare det som er igjen.
Dine egne leverandøravtaler og priser●InnebygdDu inngår avtale direkte med hver leverandør.◐Varierer per produktModellkostnadene lander som regel på skykontoen.◐Varierer per produktOm leverandørens fakturering går gjennom, varierer fra produkt til produkt.●InnebygdDu inngår avtale direkte med hver leverandør.●InnebygdInferens forblir mellom deg og leverandørene dine, til prisene deres.
Les detaljeneSe hvordan en forespørsel håndteres
Tilnærminger å sammenligne

Velg ett eller to. Svarene vises under, ett kriterium om gangen.

Ett endepunkt foran hver eneste modell

Direkte leverandørintegrasjoner · Leverandørenes SDK-er, kalt fra din egen kode
○Du bygger detHver leverandør integreres for seg, inne i applikasjonen.
Cloud AI-plattform · For eksempel AWS Bedrock, Azure AI
◐Varierer per produktInnenfor den skyleverandørens egne tjenester og de endepunktene som er koblet på.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone
●InnebygdEn felles forespørselsvei er nettopp det kategorien finnes for.
Egen utvikling
○Du bygger detDu skriver endepunktet, og du holder det i gang.
ARC
●InnebygdÉn OpenAI-kompatibel base-URL til alt på listen.

Policy som bor utenfor applikasjonskoden

Direkte leverandørintegrasjoner · Leverandørenes SDK-er, kalt fra din egen kode
○Du bygger detReglene sitter i hvert workload som kaller en leverandør.
Cloud AI-plattform · For eksempel AWS Bedrock, Azure AI
◐Varierer per produktOftest delt mellom skytjenester og konfigurasjon i applikasjonen.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone
◐Varierer per produktHvor mye policy gatewayen holder, varierer fra produkt til produkt.
Egen utvikling
○Du bygger detDet teamet ditt bygger, og holder oppdatert etter hvert som modellene endrer seg.
ARC
●InnebygdLister, kundedefinerte tagger og routingpolicy, i modellaget.

Et eget godkjent sett per team

Direkte leverandørintegrasjoner · Leverandørenes SDK-er, kalt fra din egen kode
○Du bygger detHåndhevet av den som skriver hver integrasjon.
Cloud AI-plattform · For eksempel AWS Bedrock, Azure AI
◐Varierer per produktAvhenger av hvordan plattformen modellerer tenancy og tilgang.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone
◐Varierer per produktAvhenger av produktet og av hvor langt policymodellen dets rekker.
Egen utvikling
○Du bygger detDitt å utforme, og ditt å holde på linje når teamene endrer seg.
ARC
●InnebygdEn liste bærer de modellene, verktøyene og policyene som er godkjent for det teamet.

Personvernet avklart før en modell velges

Direkte leverandørintegrasjoner · Leverandørenes SDK-er, kalt fra din egen kode
○Du bygger detDet hver applikasjon sjekker før den kaller ut.
Cloud AI-plattform · For eksempel AWS Bedrock, Azure AI
◐Varierer per produktAvhenger av de tjenestene som ligger foran modellkallet.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone
◐Varierer per produktAvhenger av om produktet vurderer policy før routing.
Egen utvikling
○Du bygger detDitt å definere, og ditt å bevise overfor en revisor.
ARC
●InnebygdKlassene dine avgjør tillatelsen, og rangeringen sorterer bare det som er igjen.

Dine egne leverandøravtaler og priser

Direkte leverandørintegrasjoner · Leverandørenes SDK-er, kalt fra din egen kode
●InnebygdDu inngår avtale direkte med hver leverandør.
Cloud AI-plattform · For eksempel AWS Bedrock, Azure AI
◐Varierer per produktModellkostnadene lander som regel på skykontoen.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone
◐Varierer per produktOm leverandørens fakturering går gjennom, varierer fra produkt til produkt.
Egen utvikling
●InnebygdDu inngår avtale direkte med hver leverandør.
ARC
●InnebygdInferens forblir mellom deg og leverandørene dine, til prisene deres.
Les detaljene
Se hvordan en forespørsel håndteres
«Innebygd» betyr at tilnærmingen leverer det. «Du bygger det» betyr at tilnærmingen overlater det til teamet ditt. «Varierer per produkt» betyr at det virkelig er forskjellig innenfor den kategorien, og det er et spørsmål å ta med til en kortliste snarere enn ett denne siden kan svare på for deg.

De samme fem, i sin helhet

Passer best for, hvor policyen bor, modellvalg, byrde for teamet og den viktigste avveiningen, for hver av de fem driftstilnærmingene.
SpørsmålDirekte leverandørintegrasjonerLeverandørenes SDK-er, kalt fra din egen kodeCloud AI-plattformFor eksempel AWS Bedrock, Azure AIGateway eller routerFor eksempel LiteLLM, Portkey, HeliconeEgen utviklingARC
Passer best forEt lite antall stabile workloads bundet til én leverandør.Organisasjoner som standardiserer hardt på én skybasert driftsmodell.Team som mest trenger et felles endepunkt, abstraksjon over leverandører og trafikkontroll.Team med uvanlige krav og kapasitet til å eie et control plane-produkt.Organisasjoner som vil ha et styrt valg på tvers av modeller, verktøy, leverandører og miljøer.
Hvor policyen borHver applikasjon, eller hver leverandørkonfigurasjon.Skytjenester pluss konfigurasjon i applikasjonen.Konfigurasjon i gatewayen og logikk i applikasjonen.Din egen kode og ditt eget driftsmiljø.Lister, kundedefinerte tagger og routingpolicy i modellaget.
ModellvalgBegrenset til den tilkoblede leverandøren og applikasjonens egen logikk.Avhenger av plattformen og de endepunktene som er koblet til den.Avhenger av gatewayens routing og støtte for leverandører.Det teamet ditt integrerer og holder i gang.De modellene og verktøyene som er godkjent på den aktive listen.
Byrde for teametIntegrasjoner og policy vedlikeholdes inne i hvert eneste workload.Governance rettet inn etter den skyleverandørens tjenester og grenser.Routingpolicy definert, testet og vedlikeholdt av ditt eget team.Design, sikkerhet, evaluering, drift og endring, alt sammen er ditt.Du eier policyen og forholdet til leverandørene. ARC anvender den policyen på hver styrte forespørsel.
Viktigste avveiningEnkelt i starten. Endringene blir flere etter hvert som leverandører og team vokser.Bred plattformintegrasjon, der beslutningene formes av nettopp den plattformen.Nyttig tilkobling. Dybden i governance og valget av driftsform varierer fra produkt til produkt.Maksimal tilpasning, satt opp mot et vedvarende produkt- og driftseierskap.Enda et lag å integrere og styre.
Les detaljeneSe hvordan en forespørsel håndteres
Tilnærminger å sammenligne, i detalj

Velg ett eller to. Svarene vises under, ett kriterium om gangen.

Passer best for

Direkte leverandørintegrasjoner · Leverandørenes SDK-er, kalt fra din egen kode
Et lite antall stabile workloads bundet til én leverandør.
Cloud AI-plattform · For eksempel AWS Bedrock, Azure AI
Organisasjoner som standardiserer hardt på én skybasert driftsmodell.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone
Team som mest trenger et felles endepunkt, abstraksjon over leverandører og trafikkontroll.
Egen utvikling
Team med uvanlige krav og kapasitet til å eie et control plane-produkt.
ARC
Organisasjoner som vil ha et styrt valg på tvers av modeller, verktøy, leverandører og miljøer.

Hvor policyen bor

Direkte leverandørintegrasjoner · Leverandørenes SDK-er, kalt fra din egen kode
Hver applikasjon, eller hver leverandørkonfigurasjon.
Cloud AI-plattform · For eksempel AWS Bedrock, Azure AI
Skytjenester pluss konfigurasjon i applikasjonen.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone
Konfigurasjon i gatewayen og logikk i applikasjonen.
Egen utvikling
Din egen kode og ditt eget driftsmiljø.
ARC
Lister, kundedefinerte tagger og routingpolicy i modellaget.

Modellvalg

Direkte leverandørintegrasjoner · Leverandørenes SDK-er, kalt fra din egen kode
Begrenset til den tilkoblede leverandøren og applikasjonens egen logikk.
Cloud AI-plattform · For eksempel AWS Bedrock, Azure AI
Avhenger av plattformen og de endepunktene som er koblet til den.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone
Avhenger av gatewayens routing og støtte for leverandører.
Egen utvikling
Det teamet ditt integrerer og holder i gang.
ARC
De modellene og verktøyene som er godkjent på den aktive listen.

Byrde for teamet

Direkte leverandørintegrasjoner · Leverandørenes SDK-er, kalt fra din egen kode
Integrasjoner og policy vedlikeholdes inne i hvert eneste workload.
Cloud AI-plattform · For eksempel AWS Bedrock, Azure AI
Governance rettet inn etter den skyleverandørens tjenester og grenser.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone
Routingpolicy definert, testet og vedlikeholdt av ditt eget team.
Egen utvikling
Design, sikkerhet, evaluering, drift og endring, alt sammen er ditt.
ARC
Du eier policyen og forholdet til leverandørene. ARC anvender den policyen på hver styrte forespørsel.

Viktigste avveining

Direkte leverandørintegrasjoner · Leverandørenes SDK-er, kalt fra din egen kode
Enkelt i starten. Endringene blir flere etter hvert som leverandører og team vokser.
Cloud AI-plattform · For eksempel AWS Bedrock, Azure AI
Bred plattformintegrasjon, der beslutningene formes av nettopp den plattformen.
Gateway eller router · For eksempel LiteLLM, Portkey, Helicone
Nyttig tilkobling. Dybden i governance og valget av driftsform varierer fra produkt til produkt.
Egen utvikling
Maksimal tilpasning, satt opp mot et vedvarende produkt- og driftseierskap.
ARC
Enda et lag å integrere og styre.
Les detaljene
Se hvordan en forespørsel håndteres
Funksjonaliteten varierer fra produkt til produkt og endrer seg over tid. Bruk dette til å velge en driftstilnærming, og etterprøv deretter de konkrete kravene under evalueringen.

Tillatelsen avgjøres før rangeringen, så ingenting i sorteringstrinnet kan nå en destinasjon policyen har utelukket.

Se hvordan en forespørsel håndteres

Spør før du binder deg

Disse spørsmålene skiller en driftstilnærming fra en funksjonsliste. Still dem til hvert eneste alternativ på kortlisten, ARC medregnet.

  • Kan vi styre modeller og verktøy gjennom den samme forespørselspolicyen?
  • Kan hvert team ha sitt eget godkjente sett uten å hardkode det i hver applikasjon?
  • Kan vi beholde de direkte avtalene og prisene våre hos leverandørene?
  • Kan den samme policymodellen kjøre hosted, managed eller self-hosted?
  • Hva må vårt eget team bygge, teste og drifte etter den første integrasjonen?

ARC er ikke nødvendig for hvert workload

Én leverandør, én modell og kontroller på applikasjonsnivå kan dekke alt du kan se komme. Et ekstra kontrollag ville da vært en kostnad uten avkastning.

  • Ett workload og én leverandør. Ennå ingenting å sende videre mellom.
  • Tracing, evaluering og promptversjonering. Kjøp et verktøy bygget for det.
  • En rute endrer hvilke godkjente destinasjoner som kjøres. Den gjør ingen modell bedre.

ARC er bygget for det tilfellet der workloadkategorier, modellvalg, personvernhåndtering, tilgangspolicy og driftsgrenser må kunne variere på tvers av team uten at hvert workload skrives om.

Hvor ARC sitter i virkelige miljøerVelg hvor ARC kjørerHva det kosterBygg ARC inn i programvaren din

Sammenlign ARC med tilnærmingen du bruker i dag

Ta med ett workload og én begrensning. Vi sier deg om routing endrer noe for deg.

Snakk med en ingeniørStart gratis