Amazon Bedrock eller Microsoft Foundry: modellprisen er bare starten

For en norsk RAG-tjeneste er Amazon Bedrock det nærliggende valget når dokumenter, tilgangsstyring og drift allerede ligger i AWS. Microsoft Foundry passer tilsvarende best når Azure og Microsofts datatjenester er hovedmiljøet. Den økonomiske forskjellen avgjøres av hele kjeden fra dokument til svar: modellkall, embedding, søkeindeks, sikkerhetskontroller og kapasitet som står klar mellom forespørslene.

Sammenligningen må bruke samme dokumenter, spørsmålsvolum, svartidskrav og krav til databehandling i Norge eller en aktuell EØS-region. Ellers kan en lav tokenpris fremstå som en besparelse selv om søk eller reservert kapasitet gjør løsningen dyrere i drift. Regionvalget kan også snevre inn hvilke modeller og utrullinger som faktisk er aktuelle.

Modellvalget bestemmer bare én del av prisen

AWS' Bedrock-priser skiller mellom modell, leverandør og prismodus; batchinferens koster 50 prosent mindre enn behovsbasert inferens for utvalgte modeller. Batch passer arbeid som kan vente, for eksempel større dokumentjobber, mens en samtaletjeneste må prises etter en utrulling som dekker kravet til svartid. Samme prisoversikt har egne poster for Knowledge Bases, Guardrails og modelltilpasning.

Microsofts Foundry-priser beskriver plattformen som gratis å utforske, men hvert produkt som tas i bruk, har sin egen prismodell. Modellbruk, Foundry IQ og verktøy for tilpasning må derfor behandles som forskjellige budsjettposter. En gratis inngang til plattformen innebærer ingen gratis drift av en ferdig RAG-tjeneste.

Sammenlign inngangs- og utgangstokener hver for seg. En modell som trenger lengre instruksjoner eller flere hentede tekstutdrag, kan bruke flere inngangstokener per svar. Mål også hvor mange svar som må kjøres på nytt før de er brukbare; den effektive kostnaden per godt svar kan avvike fra listeprisen per million tokener. Dette er en vurdering av arbeidsmengden i den konkrete løsningen, ikke en generell rangering av modellene.

RAG gir indeksen sin egen regning

Dokumentene må deles opp, representeres som søkbare data og oppdateres når innholdet endres. Deretter utløser hvert spørsmål både et søk og et modellkall. I Bedrock kan en administrert Knowledge Base samle lagring og uthenting, med administrert embedding og omrangering inkludert. Velges egne modeller eller et annet vektorlager, endres postene i regnestykket. Det er derfor nødvendig å oppgi hvilken Knowledge Base-variant som faktisk sammenlignes.

Foundry IQ bygger på Azure AI Search, der dedikert kapasitet beregnes som replikaer multiplisert med partisjoner og faktureres per time, også uten spørsmål. En serverløs utviklervariant bruker målt databehandling og indeksert lagring, men er i forhåndsvisning uten tjenestenivåavtale og anbefales ikke for produksjon. Den er derfor ikke et likeverdig nullpunkt for et produksjonsbudsjett med krav til tilgjengelighet.

Hvis brukere bare skal se dokumenter de har tilgang til, må rettighetene også gjelde treffene som sendes videre til modellen. Ved feilsøking må man kunne undersøke hvilke utdrag søket faktisk fant, ikke bare modellens endelige svar. En erfaringsrapport fra en RAG-utvikler beskriver Bedrock som mer modent for finstyring av uthenting og Foundry som enklere for eksperimentering og feilsøking. Det er én brukers vurdering, ikke et kontrollert mål på kvalitet eller kostnad.

Sikkerhetsfilter og finjustering påvirker ulike poster

Et sikkerhetsoppsett kan vurdere brukerens spørsmål, modellens svar og om svaret støttes av hentede kilder. Bedrock Guardrails prises etter hvilke filtre som er aktivert og hvor mye tekst de behandler. I et Foundry-oppsett må tilsvarende kontroller spesifiseres før prisen sammenlignes; samme filterdekning kan ikke forutsettes ut fra navnet på plattformen. Regn antall kontroller per spørsmål og svar, og før eventuelle ekstra modellkall som egne kostnader.

Finjustering er en annen beslutning enn å gjøre ferske dokumenter søkbare. Trening, lagring eller hosting av en tilpasset modell og senere inferens kan ha ulike målere, avhengig av valgt modell og utrulling. Hvis problemet er at riktig dokument ikke blir hentet, er indeks, tilgangsregler og omrangering mer direkte kostnadsdrivere å undersøke. Hvis svarene har feil format selv med riktige kilder, kan finjustering være relevant, men den bør sammenlignes mot enklere endringer i instruksjoner og hentede utdrag.

Norge-regionen må fungere for hele kjeden

Microsofts regionoversikt for Foundry lister Norway East som mulig prosjektregion, men modelltilgang, utrullingstype, kvote og tilknyttede tjenester varierer etter region. Et prosjekt plassert i Norge er dermed ikke i seg selv en garanti for at modellbehandling og søk følger samme geografiske avgrensning. Regionen for hver tjeneste må stå i samme ark som prisen.

For Bedrock kan Stockholm og Frankfurt være EØS-kandidater, men modell og øvrige komponenter må passe i det valgte oppsettet. For Foundry kan en modellutrulling i en annen region enn prosjektet endre databehandlingen og svartiden. I begge tilfeller skal man regne med eventuell dataoverføring og nettverkstrafikk som arkitekturen faktisk krever. Først når begge forslag oppfyller samme geografiske og tekniske krav, gir en prissammenligning mening.

Samme belastning, to totalregnestykker

Bruk en hypotetisk måned for begge plattformer: 10 000 spørsmål, 2 000 inngangstokener inkludert hentede utdrag og 500 utgangstokener per svar. Anta at 50 000 tekstutdrag på 300 tokener indekseres én gang, og at hvert spørsmål bruker 100 tokener til søkeembedding. Dette gir 20 millioner inngangstokener, 5 millioner utgangstokener, 15 millioner tokener ved første dokumentembedding og 1 million tokener til søkeembedding. Tallene beskriver en felles belastning, ikke en lovet månedspris.

• Modell: Multipliser inngangs- og utgangstokener med satsene for valgt modell, prismodus og region. Legg til gjentatte kall dersom arbeidsflyten faktisk bruker dem.
• Embedding og innlesing: Før opp første indeksering, endrede dokumenter og embedding av spørsmål hver for seg. En inkludert administrert funksjon skal ikke prises en gang til som separat modell.
• Søk og lagring: Bruk faktisk indeksstørrelse og antall uthentinger. Dedikert søk må regnes for alle timene kapasiteten står aktiv, også ved null trafikk; serverløs forhåndsvisning må vurderes med sine driftsbegrensninger.
• Styring og drift: Legg inn filtre, eventuell kildekontroll, logging, nettverk og reservert kapasitet når den valgte arkitekturen krever det. Finjustering føres bare i alternativet som bruker en tilpasset modell.

Fyll så inn regionale satser for samme prisperiode og samme abonnementsvilkår. Regn også en rolig måned med få spørsmål, men uendret indeks og tilgjengelighetskrav. Da blir tomgangskostnaden synlig: En løsning med lavere modellpris kan fortsatt få høyere totalpris når søk og reservert kapasitet tas med. Den beste plattformen er den som oppfyller kravene til data, tilgang og svartid til lavest samlet kostnad for det faktiske bruksmønsteret.

Les også:

• Lokal eller skybasert språkmodell: personvern har en driftspris
• n8n eller Make: selvdrift sparer lisens, men flytter hele driftsjobben
• Fabric IQ kobler Copilot til styrte data – 20 millioner modeller er grunnlaget