Data til træning og kørsel af AI skal ligge så tæt på regnekraften, at de kan læses hurtigt nok, og i en lagerform, der kan levere mange samtidige læsninger. I praksis betyder det objektlager eller hurtigt fællesdrev i samme datacenter eller region som GPU’erne, en klar plan for, hvilke data der ligger hvor, og styret adgang til dem.
Artiklen beskriver en fremgangsmåde for den, der skal bygge infrastrukturen under et AI-projekt. Den bygger på faglig viden og på producenters dokumentation, hvor det står. Valget af model og tjeneste er ikke emnet.
Tre slags data i et AI-projekt
Det er nyttigt at skille data i tre grupper, fordi de stiller forskellige krav.
Rådata. Det, projektet bygger på: dokumenter, billeder, logdata, målinger eller transaktioner. Mængden kan være stor, og den vokser. Data læses mange gange under træning og sjældent bagefter.
Bearbejdede data. Rensede, opdelte og mærkede data, der er klar til brug. De læses intensivt i perioder.
Resultater. Modelfiler, mellemresultater, logs fra kørsler og det, modellen producerer. De skal gemmes, versioneres og kunne findes igen.
Hver gruppe har sin egen placering, lagerform og levetid. Skriv dem ned pr. projekt, før lageret vælges.
Objektlager som grundlag
Objektlager gemmer data som objekter med en adresse og metadata, i modsætning til filer i mapper eller blokke på en disk. Det kan skalere til meget store mængder og læses parallelt. Værktøjer til AI kan læse direkte fra objektlager gennem den grænseflade, der kaldes S3.
S3-kompatibel betyder, at grænsefladen ligner. Funktionerne bag den kan variere. Ceph angiver i sin dokumentation funktion for funktion, hvad der er understøttet og delvist understøttet. Garage oplyser, at endepunkter, der mangler, svarer med fejlen “501 Not Implemented”. Test derfor de funktioner, jeres værktøjer bruger, mod det lager, I vælger. Se S3-kompatibel: hvad der følger med, og hvad der ikke gør.
Hastighed handler om mere end netværket
Hvor hurtigt data kan læses, afhænger af lageret selv og af, hvordan data er organiseret. AWS oplyser for sit objektlager, at det understøtter et vist antal skrivninger og læsninger pr. sekund pr. præfiks, altså pr. del af adressen, og at ydelsen kan øges ved at sprede data over flere præfikser. Det er et eksempel på, at organiseringen af data påvirker, hvor mange GPU’er der kan fodres samtidig. Andre lagre har deres egne grænser. Spørg efter dem.
Lagerklassen betyder også noget. Data i arkivklasser kan tage fra minutter til timer at få tilbage ifølge AWS’ egen dokumentation, afhængigt af klassen og den valgte hastighed. Det er vores læsning, at data, der skal bruges i næste træning, ikke bør ligge i en arkivklasse. Arkiv passer til rådata, der skal gemmes, men sjældent bruges. Mere om tiden til at få data tilbage står i Hvor hurtigt kommer data tilbage fra cloud?
Placering: data og GPU samme sted
Ligger GPU’erne hos én udbyder og data hos en anden, skal data over forbindelsen mellem dem, hver gang de bruges. Det tager tid, og det kan koste betaling for udgående data hos den udbyder, data forlader. Ved løbende brug af to udbydere må udbyderen efter Data Act fortsat tage et gebyr, der dækker omkostningen, også efter januar 2027. Det står i Parallel brug af flere udbydere.
Fremgangsmåden er derfor at lægge de bearbejdede data og GPU’erne samme sted, og lade rådata ligge, hvor de skabes, hvis de kun skal over én gang. Er datamængden stor, kan det være lettere at flytte regnekraften til data end omvendt. Se Datatyngde og svartid.
Adgang og følsomme data
Data til AI kan rumme persondata eller forretningshemmeligheder. Hvem der kan læse lageret, er derfor lige så vigtigt som hvor det står. Giv adgang pr. projekt og pr. gruppe af data, log læsninger, og hold rådata med persondata adskilt fra det, der deles bredt. Kryptering med nøgler, I selv styrer, begrænser, hvad udbyderens folk kan se. Se Nøgler i cloud: BYOK, HYOK og HSM.
Placeringen i et europæisk datacenter siger intet om, hvem der kan få adgang til data fra andre lande. Det afhænger af udbyderen, support og kontrolplan, beskrevet i Kontrolplanen.
Backup og versioner
Resultaterne af en træning er dyre at lave igen. Modelfiler og de data, de er trænet på, skal kunne findes og gendannes. Brug versionering i objektlageret, og hav en kopi et andet sted end der, hvor GPU’erne står. Hvis I vil beskytte kopien mod sletning, kræver en objektlås i S3 ifølge AWS, at versionering er slået til. Se Uforanderlig backup.
Hvad det kræver, og hvad det koster at lade være
Opdelingen i de tre slags data og valget af placering kræver et par dage pr. projekt fra en arkitekt og den ansvarlige for data. En prøve af læsehastigheden fra det valgte lager med den rigtige mængde GPU’er tager en uge og viser, om lageret kan følge med.
Lader I være, står GPU’erne og venter på data. Det er spild, fordi regnekraften betales, uanset om den arbejder. Og data, der ligger forkert, giver løbende trafik og betaling for udgående data.
Det skal I lade være med
- At lægge data og GPU hos hver sin udbyder uden at måle · hver kørsel flytter data.
- At lægge aktive data i arkivklasse · de kan tage timer at få frem.
- At give bred adgang til rådata · de kan rumme det mest følsomme.
Det skal valget kunne vise
- ☐ De tre slags data pr. projekt, med mængde og placering.
- ☐ Målt læsehastighed fra lageret til GPU’erne.
- ☐ Adgang pr. projekt og logning af læsninger.
- ☐ Versionering og kopi af modelfiler et andet sted.
Kilder
- Ceph, Object Gateway S3 API: læst 8. november 2026.
- Garage, S3 compatibility: læst 8. november 2026.
- AWS, optimizing Amazon S3 performance og archive retrieval options.
Senest gennemgået: november 2026.
Næste skridt
Tag jeres første AI-projekt, og skriv de tre slags data op med mængde og nuværende placering.
Læs også: GPU-kapacitet i Europa · Selvdrevet objektlager
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
