När skalbar AI diskuteras handlar det nästan alltid om enterprise-bolag med dedikerade plattformsteam. För mindre tillväxtbolag ser verkligheten annorlunda ut. Här finns sällan någon som servar forskarna med färdig infrastruktur – ML-engineers får själva hålla ihop allt från datapipelines till GPU-allokering, ofta vid sidan av sitt egentliga jobb.
Vi pratade med en ML Engineer på ett svenskt SaaS-bolag (anonymiserat på kundens begäran) om hur de strukturerade om sin MLOps-plattform med AiQu, vad som faktiskt fungerade – och vad som inte gjorde det.
1. Utgångsläget: Tre ingenjörer, för många hattar
”Vi är tre ML-engineers. Ingen plattformsroll, ingen DevOps. Vi hanterade allt själva, vilket betydde att en stor del av tiden gick åt till annat än modeller.”
Vi hade ingen enhetlig miljö. Träning skedde dels på en on-prem-server med två A100:or, dels på spot-instanser i molnet när vi behövde mer kapacitet. Olika personer satte upp olika Docker-images. Resultatet:
- Reproducerbarhetsproblem. Inte “fungerar på min maskin” i den klassiska bemärkelsen, utan mer subtilt – små skillnader i CUDA-versioner och torch-builds som gav avvikande resultat mellan körningar.
- Lågt GPU-utnyttjande. Vår on-prem-server stod ofta idle nattetid, samtidigt som någon i teamet startade en molninstans för att hen inte ville vänta. Molnkostnaden blev oförutsägbar.
- Manuellt deploy-arbete. Att flytta en modell från experiment till produktion krävde att den som skrivit modellen själv konfigurerade endpoint, skrev Dockerfile och satte upp monitoring. Vissa modeller fastnade i “snart i produktion”-läge i månader.
2. Vägen till AiQu – och vad som inte gick som planerat
”Vi övervägde att bygga något på Kubernetes själva med Kubeflow eller liknande. Vi insåg ganska snabbt att det skulle ta minst ett kvartal av en av oss på heltid att få det stabilt, och vi hade inte den tiden.”
Vi landade i AiQu, men det fanns saker att lära sig på vägen:
- Första försöket med GPU-sharing fungerade dåligt. Vi försökte dela en A100 mellan flera mindre jobb, men för en del modeller med oregelbundna VRAM-toppar slogs jobben ut. Vi fick gå tillbaka och definiera tydligare resursklasser – mindre flexibelt, men förutsägbart.
- Migreringen tog längre tid än vi trott. Inte plattformen i sig, utan att paketera om våra befintliga skript och miljöer i något standardiserat format. Det fanns en hel del odokumenterade beroenden som vi fick gräva fram.
- Vi behöll vissa lokala flöden. För snabba experiment och prototyper kör en del av teamet fortfarande lokalt. Det är inte värt friktionen att tvinga in allt i pipelinen från dag ett.
3. Tekniska val
”Vi försökte hålla det pragmatiskt och undvika att låsa in oss för hårt.”
Standardiserade bas-images
Vi har nu fyra–fem hårt kontrollerade images (olika kombinationer av PyTorch-version och CUDA) som hela teamet utgår från. Detta enkla beslut löste majoriteten av våra reproducerbarhetsproblem – det är ingen raketforskning, men det krävde att någon ägde det.
Köbaserad GPU-allokering
Istället för att alla skulle försöka boka resurser ad hoc lägger vi jobb i en kö med prioriteter. Den som behöver något akut kan höja prioritet, men default är att jobb kör när kapacitet finns. Det gjorde störst skillnad för natt- och helgutnyttjandet.
CI-trigger för träning, manuell trigger för deploy
Vi automatiserade träningskörningar via commits, men vi valde att inte auto-deploya till produktion. En människa godkänner alltid – för oss var det rätt avvägning mellan hastighet och risk.
4. Resultat – med rimliga reservationer
”Här är vad vi faktiskt sett under det första året. Siffrorna är våra egna och baserade på loggar plus en hyfsat oexakt självskattning av tidsåtgång innan vi började mäta.”
| KPI | Tidigare | Med AiQu | Kommentar |
|---|---|---|---|
| Tid att sätta upp ny träningsmiljö | 1–3 timmar (med felsökning) | 10–20 minuter | Standardiserade images gör mer skillnad än plattformen i sig |
| Tid från färdig modell till produktion | 1–2 veckor i snitt | 1–3 dagar | Manuellt godkännandesteg kvar |
| GPU-utnyttjande (on-prem) | ~25% | ~60% | Mer går säkert att vinna, men vi har inte prioriterat det |
| Frigjord tid per ingenjör | – | ~6–8 timmar/vecka | Variation mellan personer |
Var kommer tiden ifrån?
Främst från sådant som inte syns i en kalender – kontextväxlingar när något kraschar, väntan på miljöer, felsökning av reproducerbarhetsproblem, manuella deploy-steg. Sammanlagt för teamet motsvarar det ungefär en halv heltidstjänst som istället kan läggas på modellarbete.
Det är inte 2 000 timmar och ingen heltidstjänst. Men det är skillnaden mellan att leverera fyra modeller per år och åtta.
5. Lärdomar för mindre team
”Tre saker vi tycker är värda att säga rakt ut:”
- MLOps är inte en plattform – det är en uppsättning vanor. Verktyget hjälper, men disciplinen kring att versionshantera data och modeller måste finnas oavsett. Vi hade kunnat komma halvvägs med bara standardiserade images och en delad konvention.
- Bygg inte själv om ni inte måste. Det är frestande att skriva egna skript för köer och resurser. Det fungerar i tre månader och blir sedan teknisk skuld som ingen vill röra.
- Räkna inte med att hårdvara löser något i sig. En extra GPU hjälper inte om flaskhalsen är att data tar två dagar att förbereda eller att deploy-processen är manuell.
Liknande situation hos er?
Det här är ett av flera sätt att lösa det på. Vill ni bolla er egen setup utan säljpitch – hör av er. Vi visar gärna AiQu konkret och pratar igenom var det passar och var det inte gör det.
