Lokala språkmodeller eller molnmodeller – hur väljer man?

En lokal språkmodell ger större teknisk kontroll över var data behandlas. En extern modell via moln eller API kan ge högre kapacitet och snabbare tillgång till nya funktioner. Inget alternativ är automatiskt säkrast eller bäst.

Valet bör följa informationsklass, uppgift, kvalitetskrav, svarstid, kostnad och organisationens förmåga att drifta lösningen. Ofta blir resultatet en hybrid där olika modeller används för olika typer av data.

Tre vanliga sätt att köra språkmodeller

Extern API-tjänst

Extern API-tjänst innebär att applikationen skickar en begäran till en modell som leverantören driver. Organisationen slipper modellservrar och får snabbt tillgång till uppdateringar. Kontroll och villkor beror på den exakta företags- eller API-tjänsten.

Privat molnmiljö

Privat molnmiljö innebär att tjänsten körs inom ett mer avgränsat molnupplägg med avtalad region, identitet och nätverkskontroller. Modellen kan fortfarande vara en hanterad tjänst, men applikation och dataflöde integreras i organisationens molnarkitektur.

Lokal eller dedikerad drift

Lokal eller dedikerad drift innebär att modell och kringkomponenter körs på infrastruktur som organisationen eller dess driftpartner kontrollerar. Det kan vara i eget datacenter, svensk driftmiljö eller en dedikerad instans.

Gränserna är inte absoluta. En lösning kan använda lokalt dokumentindex men en extern modell, eller lokala modeller för känslig data och externa modeller för öppet material.

När är en lokal modell relevant?

Lokal drift är särskilt relevant när informationen inte får lämna en kontrollerad miljö, när organisationen behöver full kontroll över retention eller när nätverksisolering är ett krav. Den kan också ge förutsägbar tillgång vid stora, stabila volymer.

Fördelarna kommer med ansvar. Organisationen behöver hantera modellfiler, patchning, GPU-kapacitet, skalning, övervakning och säkerhetsuppdateringar. En öppen modell kan dessutom ha licensvillkor och begränsningar som måste granskas.

Lokal drift löser inte automatiskt säkerheten i dokumentindex, loggar eller användargränssnitt. Hela kedjan måste omfattas av identitet, behörighet, kryptering, backup och incidenthantering.

När passar en molnmodell bättre?

Molnmodeller passar när hög kvalitet, bred språkförmåga, multimodalitet eller snabb tillgång till nya funktioner väger tungt. De kan skala utan att organisationen dimensionerar egen hårdvara och prissätts ofta per användning.

Företagserbjudanden kan ge villkor om att kunddata inte används för träning. OpenAI, Microsoft, Google Cloud och AWS publicerar separata beskrivningar av datahantering för sina företags- och molntjänster.[1–4] Dessa behöver läsas för den exakta produkten och kontrolleras mot avtal och konfiguration.

En extern tjänst är mindre lämplig om region, underleverantörer eller retention inte kan förenas med informationsklassningen. Den kan också skapa kostnadsrisk vid mycket stora volymer eller leverantörsberoende om applikationen byggs tätt mot unika funktioner.

Rätt modell är inte en varumärkesfråga. Det är en konsekvens av data, uppgift och krav.

Datahantering och leverantörsvillkor

Bedöm inte bara om indata används för modellträning. Kartlägg var prompt, dokument, metadata, utdata och loggar behandlas och lagras. Kontrollera region, retention, underbiträden, supportåtkomst, radering och export.

För personuppgifter behöver organisationen fastställa ändamål, rättslig grund och ansvar. IMY betonar dataskydd genom hela livscykeln.[5] Lokal drift förändrar leverantörskedjan men tar inte bort GDPR eller kraven på dataminimering och säkerhet.

Kvalitet, kapacitet och svarstid

Större modeller ger ofta högre generell kapacitet men kan vara långsammare och dyrare. Mindre modeller kan fungera mycket bra i avgränsade uppgifter, särskilt tillsammans med RAG, strukturerad utdata och tydliga instruktioner.

Testa modeller på verksamhetens egna representativa uppgifter. Mät korrekthet, källförankring, rätt avslag, språk, svarstid och kostnad. Ett standardiserat jämförelsetest från leverantören säger lite om hur modellen hanterar era tabeller, facktermer eller säkerhetskrav.

Kapacitetsplanering för lokal drift behöver ta hänsyn till samtidiga användare, kontextlängd och toppbelastning. För API-tjänster behöver ni hantera kvoter, nätverksberoende och leverantörens tillgänglighetsnivåer.

Kostnad och driftansvar

Jämför total kostnad, inte bara pris per token eller server. Lokal drift omfattar hårdvara eller driftmiljö, energi, licenser, driftkompetens, övervakning och reservkapacitet. Molndrift omfattar användning, dataöverföring, loggning, avtal och kostnadskontroll.

Kostnadsbilden förändras med volym. En lokal modell kan bli ekonomisk vid hög och jämn belastning, medan API passar bättre vid varierande användning. Modellstorlek, kontext och utdatalängd påverkar båda alternativen.

Hybrid och modellneutral arkitektur

En modellneutral arkitektur separerar applikationens arbetsflöde från en enskild modell. Då kan organisationen dirigera uppgifter efter informationsklass och krav, samt testa en ny modell innan den ersätter den gamla.

Det kräver ett gemensamt abstraktionslager, versionshanterade prompts, ett testbibliotek och uppföljning per modell. Byte är inte kostnadsfritt: utdataformat och beteende förändras. Regressionstest måste därför vara en del av modellen som livscykelkomponent.

Tolv frågor för modellval

1. Vilken informationsklass ska behandlas?

2. Finns personuppgifter eller sekretesskrav?

3. Vilken kvalitet krävs och hur mäts den?

4. Behövs flera språk, bild eller ljud?

5. Hur många samtidiga användare och vilken svarstid krävs?

6. Kan verksamheten acceptera internet- eller leverantörsberoende?

7. Vilka regioner och underleverantörer är tillåtna?

8. Vilken retention och loggning behövs?

9. Finns kompetens och budget för lokal drift?

10. Hur varierar användningsvolymen?

11. Hur byter eller återställer vi modell?

12. Hur testas säkerhet och kvalitet efter varje förändring?

Källor

1. OpenAI, Enterprise privacy:
   https://openai.com/enterprise-privacy/

2. Microsoft, Azure OpenAI data privacy:
   https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy

3. Google Cloud, Zero data retention:
   https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/zero-data-retention

4. AWS, Data protection in Amazon Bedrock:
   https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html

5. IMY, Vägledning om GDPR och AI:
   https://www.imy.se/verksamhet/dataskydd/innovationsportalen/vagledning-om-gdpr-och-ai/