Kan en lokal AI-tjänst växla över till CPU när grafikminnet är fullt?
Ja, men tillförlitlig CPU-failover måste utformas innan GPU-minnet tar slut; de flesta inferensprocesser återhämtar sig inte transparent efter en oväntad OOM.
En AI-server hemma kan svara snabbt på sin GPU tills en längre prompt, större batch, bildförfrågan eller en andra modell förbrukar det återstående VRAM-minnet. Nästa allokering kan misslyckas trots att systemets RAM-minne och CPU är lediga. Om förfrågan överlever beror på körmiljön: vissa kan placera vikter på CPU från början, medan andra behöver en separat CPU-arbetare och en router som försöker igen på ett säkert sätt.
CPU-avlastning och CPU-failover löser olika problem
CPU-avlastning är en strategi för modellplacering. Utvalda lager, tensorer eller pipelinekomponenter ligger i systemets RAM-minne och flyttas till acceleratorn vid behov, vilket minskar mängden VRAM som krävs för en normal förfrågan. CPU-failover är ett beteende hos tjänsten: när GPU-sökvägen inte är tillgänglig eller avvisar en förfrågan tar en annan arbetare emot den och kör en CPU-kompatibel modell utan att jobbet går förlorat.
Hugging Face Accelerate tillhandahåller metoder för CPU-avlastning som avsiktligt flyttar modellstatus mellan CPU-minnet och en exekveringsenhet. Detta är planerad heterogen exekvering, inte en nödlösning efter att ett godtyckligt CUDA-tillstånd har misslyckats. Modellen, enhetskartan, hookarna och minnesbudgeten förbereds innan inferensen börjar.
En delvis avlastad modell kan redan använda CPU samtidigt som den fortfarande är beroende av GPU:n för varje token. Om GPU:n slutar fungera kan processen därför inte nödvändigtvis fortsätta på CPU från den avbrutna token. Äkta failover startar vanligtvis om förfrågan på en CPU-förberedd arbetare. Den skillnaden förklarar varför en applikation kan ange stöd för CPU men ändå returnera ett OOM-fel i stället för att slutföra den aktuella förfrågan.
VRAM kan ta slut efter att en modell har lästs in
Modellvikter är bara en del av minnesbudgeten. Nyckel-värde-cachen växer med aktiv sekvenslängd och samtidighet, temporära kärnor behöver arbetsutrymme, bild- eller ljudkodare lägger till tensorer och en minnesallokerare kan reservera block för återanvändning. En modell som får plats vid starten kan därför misslyckas vid lång kontext eller flera samtidiga användare.
PyTorch använder en cachande minnesallokerare, så minne som rapporteras som reserverat är inte identiskt med minne som används av aktiva tensorer. Fragmentering och allokeringar som görs utanför ramverket kan ytterligare minska det användbara utrymmet. En failover-utlösare bör övervaka nekade allokeringar och arbetarens hälsa, inte bedöma säkerheten utifrån ett enda instrumentpanelsvärde eller det faktum att modellinläsningen lyckades.
Det är också därför en statisk regel om att ”modellstorleken ligger under mängden VRAM” är ofullständig. En tjänst kan reservera en lägre kontextgräns, begränsa antalet samtidiga sekvenser eller lämna en procentandel av VRAM oanvänd för att skydda körmiljöns allokeringar. Dessa kontroller förhindrar fler fel än reaktiv växling till CPU, eftersom de håller GPU-processen i ett känt tillstånd och bevarar förutsägbar fördröjning för accepterade förfrågningar.
Automatiska nya försök är säkra endast när förfrågan kan spelas upp igen
Efter en OOM kan routern markera GPU-arbetaren som ohälsosam, frigöra eller starta om den och spela upp den ursprungliga förfrågan igen på en CPU-arbetare. Detta fungerar för vanlig textgenerering när ingen extern bieffekt har inträffat. Det är svårare för strömmade svar, bildpipelineer med slumpfrön eller agenter som redan kan ha anropat ett verktyg.
Ramverk kan också fördela stora modeller över enheter redan från början. Accelerates inferens med stora modeller stöder enhetskartor samt placering på CPU eller disk när en modell överskrider kapaciteten hos en enhet. Detta kan hålla en förfrågan igång inom en planerad exekveringsgraf, men det innebär en avvägning mellan hastighet och kapacitet och ska inte förväxlas med att dirigera en misslyckad förfrågan till en separat tjänst.
Failover-påståendet gäller inte längre när CPU:n saknar tillräckligt med RAM, körmiljön saknar kompatibla CPU-kärnor, förfrågan redan har utfört en oåterkallelig åtgärd eller den förväntade CPU-fördröjningen överskrider klientens tidsgräns. I sådana fall bör du returnera ett kontrollerat kapacitetsfel eller placera förfrågan i en kö. Tysta nya försök kan duplicera bieffekter eller få användare att vänta långt längre än gränssnittet lovar.
Bevisa failover med ett avsiktligt minnestest
Kör en GPU-arbetare och en CPU-arbetare bakom en router och skicka sedan en förfrågan som överskrider GPU-profilen utan att överskrida systemets RAM-minne. Registrera det första felet, beslutet att försöka igen, CPU-starttiden, det slutliga resultatet och om klientanslutningen överlever. Upprepa först med strömning inaktiverad och testa sedan avbrytning, samtidig trafik och en agentförfrågan med ett simulerat verktyg.
Delvis GPU-körning är en användbar baslinje eftersom körmiljöer som llama.cpp-inferens kan placera en konfigurerbar del av modellens arbete på acceleratorer och samtidigt behålla CPU-körning. Jämför profiler för GPU-resident körning, planerad CPU/GPU-delning och oberoende CPU-reservlösning. En modell för hybrida AI-arbetsbelastningar hjälper till att skilja kapacitetsbaserad reservlösning från vanlig molndirigering.
Kalla designen tillförlitlig endast om det nya försöket slutförs en gång, bevarar förfrågans identitet, undviker dubbla verktygsåtgärder och återställer GPU-arbetaren utan att avbryta orelaterade jobb. Om CPU-slutförandet är för långsamt bör du använda det som en säkerhetsväg som bevarar kön, inte som ett interaktivt likvärdigt alternativ. Det operativa målet är en smidig degradering, inte att låtsas att CPU- och GPU-tjänstenivåer är utbytbara.
| Beteende | Förberett före OOM? | Kan rädda den aktuella förfrågan? |
|---|---|---|
| CPU/GPU-avlastning | Ja | Vanligtvis, inom den planerade grafen |
| Lägre GPU-samtidighet | Ja | Förhindrar att osäkert arbete tas emot |
| Router försöker igen på CPU | Ja | Ja, om den kan spelas upp igen |
| Oplanerad växling i processen | Nej | Vanligtvis inte |
Vanliga frågor
Skapar rensning av GPU-cachen failover?
Nej. Frigörande av cache kan göra oanvända reserverade block tillgängliga, men det skapar inte CPU-körning, reparerar inte ett skadat förfrågningstillstånd och garanterar inte tillräckligt med sammanhängande minne för nästa allokering.
Ger CPU-reservlösningen samma svar?
Det kan den göra när samma vikter, precision, prompt, tokenizer och samplingsstatus används. Olika kärnor, kvantiseringar, frön eller omstartad strömning kan ändå ändra det exakta resultatet.
Är en mindre modell bättre än CPU-failover?
Ofta för interaktiva tjänster. En mindre GPU-modell kan ge förutsägbar fördröjning, medan CPU-failover skyddar tillgängligheten för exceptionella förfrågningar. De två mekanismerna löser olika tjänstemål och kan kombineras.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Hur påverkar nedsampling av tidsserier avvikelsedetektering i smarta hem?
Se hur hinkbredd, aggregering, kantutjämning, saknade data, händelselängd och bevarande i flera skalor påverkar återkallningen av avvikelser i smarta hem.
Hur kombinerar en beläggningskarta svaga signaler från smarta hem?
Lär dig hur rumsliga celler, sensormodeller, log-odds-uppdateringar, avklingning, korrelerade bevis och tröskelvärden omvandlar svaga hemsignaler till uppskattningar av närvaro.
Hur påverkar fotometrisk normalisering klustring av privata ansikten?
Se hur belysningskorrigering förändrar ansiktsbeskärningar, embeddingar, klusteravstånd, tröskelvärden, övernormalisering och utvärdering av privat fotosökning.
