Autopilot: Geautomatiseerd infrastructuurbeheer voor GenAI

Wat is Autopilot

Machine learning operations (MLOps) omvatten vaak complexe, handmatige processen die tijd en middelen opslokken. Autopilot van TrueFoundry heeft als doel deze operationele lasten weg te nemen, zodat ontwikkelaars zich volledig kunnen richten op het schrijven van code en data scientists op het verfijnen van hun modellen. Autopilot verwerkt automatisch resource-optimalisatie en betrouwbaarheidsfixes en zorgt voor een wrijvingsloze workflow met minimale menselijke tussenkomst.

Waarom hebben we dit nodig

De operationele aspecten van elke softwareontwikkelingslevenscyclus kunnen worden onderverdeeld in drie verschillende fasen -

1. Day 0 – Ontwerp & Planning: Definieer architectuur, provisioningstrategieën, beveiligingsbeleid en schaalbaarheidsframeworks voorafgaand aan de deployment.
2. Day 1 – Deployment & Implementatie: Richt infrastructuur in, deploy applicaties, configureer observability en zet CI/CD-pipelines op.
3. Day 2 – Operations & Onderhoud: Monitor continu, auto-scale resources, pas beveiligingspatches toe en beheer incidenten.

Deze processen zijn in drie verschillende fasen geïmplementeerd, wat heeft geleid tot een evolutie van gefragmenteerde verantwoordelijkheden naar geautomatiseerde efficiëntie.

Fase 1: Gescheiden Dev en Ops

Dit is de fase waarin een team meestal begint. De drie operationele fasen omvatten in deze fase het volgende.

• Day 0: Ontwikkelaars richten zich op het applicatieontwerp, terwijl de operations-teams infrastructuur en beveiliging afhandelen.
• Day 1: Ontwikkelaars verpakken en bereiden de applicaties voor op deployment, terwijl het operations-team zich richt op het provisionen en configureren van resources.
• Day 2: Operations beheert schalen, monitoring en beveiligingspatches, terwijl ontwikkelaars nog steeds problemen oplossen.

Deze scheiding van verantwoordelijkheden creëert onnodige wrijving tussen de Development- en Operations-teams. Het probleem wordt versterkt doordat het delen van context moeilijker wordt gemaakt door de beperkte gedeelde terminologie in sommige gevallen.

Voor een enkele applicatie kan dit zich vertalen in een initiële release-timeline van meerdere weken, waarbij elke opeenvolgende Day 2-operatie een paar dagen duurt, met de onvermijdelijke afstemmingsproblemen tussen de operations- en developmentteams.

Criteria	Wat moet u evalueren?	Prioriteit	TrueFoundry
Latency	Voegt <10ms p95 overhead toe voor time-to-first-token?	Must Have	✅ Ondersteund
Data Residency	Bewaart logs binnen uw regio (EU/US)?	Afhankelijk van use-case	✅ Ondersteund
Op Latency Gebaseerde Routing	Routet automatisch om op basis van realtime latency/storingen?	Must Have	✅ Ondersteund
Sleutelrotatie & Intrekking	Sleutels roteren of intrekken zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & Intrekking	Sleutels roteren of intrekken zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & Intrekking	Sleutels roteren of intrekken zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & Intrekking	Sleutels roteren of intrekken zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & Intrekking	Sleutels roteren of intrekken zonder downtime?	Must Have	✅ Ondersteund

AI Gateway Evaluatie Checklist

Een praktische gids voor platform- & infra-teams

Fase 2: Interne platformcreatie

In fase 2 adopteert een organisatie een intern platform waarmee het developmentteam de meeste operationele knoppen naar eigen inzicht kan configureren en beheren. Het operations-team verschuift meer naar een handhavings- en standaardisatierol, waarbij het platform als orchestratielaag wordt gebruikt.Deze fase heeft een paar nadelen -

• Voor ontwikkelaars betekent deze fase dat ze in de eerste stadia veel keuzes moeten maken met beperkte context of relevante expertise. Dit leidt tot een toename in cognitieve belasting en suboptimale resourceplanning.
• Deze aanpak uit zich in een explosie van de operationele ruimte voor het operations-team. Een typisch team kan te maken krijgen met een veelvuldige toename van het aantal services en infrastructuurkosten door de reeks suboptimale beslissingen.

Hoewel we aanvankelijk snelheid winnen, wordt dit tenietgedaan door de explosie aan complexiteit in het werk van het developmentteam, die onvermijdelijk wordt gevolgd door botsende belangen tussen de twee teams.

Fase 3: Het platform automatiseren

In de derde fase begint het platform zelf alle operationele zaken te automatiseren. Dit neemt de noodzaak weg om in de drie operationele fasen veel beslissingen te moeten nemen.

Dit betekent dat de 3 operationele fasen al op Day 0 kunnen worden bereikt met vrijwel geen operationele keuzes van zowel de development- als de operations-teams. Dit is wat Autopilot probeert te doen.

Waarom nu

Hoewel de behoefte aan meer automatisering al geruime tijd duidelijk is, wordt een systeem als Autopilot nog essentiëler in het huidige scenario waarin de volgende nieuwe paradigma's een rol gaan spelen

Microservices

Met de brede adoptie van de microservices-architectuur is het aantal services in een organisatie explosief gegroeid. Dit gemak om wijzigingen of nieuwe services naar productie te brengen heeft een Keerzijde: moeilijker toezicht. Autopilot is een systeem dat deze services betrouwbaar kan optimaliseren.

Agentic Systems

Agentic systems zijn systemen die autonoom taken uitvoeren. Ze hebben een robuuste, zelfvoorzienende deploymentstrategie nodig met een ondersteunende infrastructuur die flexibel genoeg is om dynamisch op en af te schalen wanneer dat nodig is. Huidige geavanceerde AI-agents vertrouwen op aanpasbare, efficiënte infrastructuur om optimaal te functioneren. Dit zijn dynamische systemen die verschillende niveaus van menselijke betrokkenheid vereisen. De brede uitrol van dergelijke systemen is alleen mogelijk met een systeem waarin alle operationele aspecten zijn geautomatiseerd, en dat is waar Autopilot in beeld komt

Case Study

Voor een van de TrueFoundry-platformgebruikers waren de kosten voor dev-clusters een groot probleem. Met ongeveer 200 gedeployde services was dit een typisch geval van meerdere services met kleine inefficiënties die samen leidden tot een enorme totale kostenstijging. Elke poging tot kostenoptimalisatie zou op het niveau van de individuele service moeten worden gedaan. Deze extreme werkvereiste leidde ertoe dat de kostenoverschrijding verergerde en nooit prioriteit kreeg.

Na het inschakelen van Autopilot kon deze ene klant een kostenbesparing van $1500 realiseren in slechts 2 clusters. Bovendien werden er meer dan 50 betrouwbaarheidsgerelateerde fixes toegepast waarbij workloads te weinig CPU hadden of te maken hadden met geheugentekorten

‍

Wat kan Autopilot momenteel

‍

CPU-, geheugen- en opslagoptimalisatie

Autopilot automatiseert de CPU- en geheugenconfiguratie voor een applicatie. Autopilot doet dit door te kijken naar twee bronnen van invoer -

• Historisch gebruik: Autopilot kijkt naar het historische gebruik van een applicatie om een optimale configuratie voor de toekomst voor te stellen
• Realtime aanpassingen: Autopilot reageert ook op waarschuwingen en andere gebeurtenissen om in realtime maatregelen te nemen en een probleem in de kiem te smoren. Dit leidt tot een verbetering van de MTTR en voorkomt proactief veel problemen die anders veel groter zouden worden.

Cluster Health

Autopilot zorgt ook voor de gezondheid en kosten van de individuele componenten die in een cluster zijn geïnstalleerd, zoals Istio, ArgoCD, Karpenter, enz. Het uitvallen van een van deze componenten kan rampzalige gevolgen hebben voor de workloads die op dat cluster draaien. Autopilot zorgt ervoor dat deze componenten op een kostenefficiënte manier draaien en blijven functioneren door proactief te zoeken naar resource-spikes en deze op te vangen.

Node-capaciteit

Verder kijkend dan services, optimaliseert Autopilot ook ten opzichte van de infrastructuur die ten grondslag ligt aan de draaiende services. Dit betekent dat het de ideale node-capaciteit voor een applicatie aanbeveelt. Dit gebeurt door rekening te houden met de applicatiemetrics, omgeving en andere factoren.

Autoscaling

Veel developmentteams kiezen ervoor om hun applicaties te schalen voor de maximale belasting die een applicatie naar verwachting zal krijgen. Dit leidt tot veel extra kosten wanneer deze extra replica's niet in gebruik zijn. Een voor de hand liggende oplossing is het implementeren van autoscaling, maar zelfs dat is niet toepasbaar wanneer de verkeerspatronen onvoorspelbaar zijn. Autopilot analyseert de historische metrics voor elke service en genereert een aanbeveling voor het in- of uitschakelen van autoscaling op basis van het historische gedrag van de applicatie.

‍

Wat volgt er

Hoewel we nu al grote winsten zien qua kosten en betrouwbaarheid door het gebruik van Autopilot in productie, moet er nog veel meer gebeuren om de eerder neergezette visie van volledige automatisering te realiseren. Enkele operationele aspecten die het waard zijn om als volgende te automatiseren zijn -

• Periodieke autoscaling - Het voorspellen en implementeren van periodieke autoscaling, rekening houdend met historisch verkeer, kan ons in staat stellen autoscaling in te schakelen, zelfs voor piekgevoelige workloads.
• Aanbeveling voor automatische uitschakeling - Het filteren en uitschakelen van services of workloads die niet in gebruik zijn, kan leiden tot enorme kostenbesparingen
• Auto-benchmarking — Hoewel het schatten van de resources van een service al mogelijk is, kan een betere schatting worden gemaakt door benchmarks uit te voeren met live of gesimuleerd verkeer en de beïnvloede zakelijke metrics te observeren. Autopilot wil dit proces automatiseren, wat voor de meeste developmentteams erg tijdrovend kan zijn.
• Optimalisatie van clusterinfrastructuur - De CPU-benutting van clusters in de sector is gemiddeld 10% link . Hoewel verkeerde configuratie van applicaties voor CPU hier een groot deel van uitmaakt, ligt een groot deel ook bij de inefficiënties in de belastingverdeling op de onderliggende infrastructuur. Dit kan de vorm aannemen van veel onderbenutte nodes, te veel kleine nodes die ruimte verspillen aan daemonsets, enz. Het corrigeren van de infra-provisioningconfiguraties en het benutten van tools zoals Karpenter op cloudniveau kan veel helpen om dit aspect te verbeteren.

Conclusie

Autopilot van TrueFoundry is een transformatieve tool in de evolutie van MLOps, die kritieke operationele uitdagingen in de softwareontwikkelingslevenscyclus aanpakt. Autopilot stelt teams in staat zich te richten op innovatie in plaats van operationele overhead door resource-optimalisatie, cluster health management en autoscaling te automatiseren. Naarmate de adoptie van microservices en agentic systems blijft groeien, wordt de noodzaak voor dergelijke automatisering steeds dringender. Met de huidige mogelijkheden en een ambitieuze roadmap is Autopilot klaar om een revolutie teweeg te brengen in hoe organisaties operationele efficiëntie, betrouwbaarheid en kostenoptimalisatie benaderen.

‍