La tassa DevOps: il vero costo dell'AI self-hosted non è la GPU.

Burn-in.

Dimostrate che la scheda e l'host sono sani prima che qualcosa dipenda da loro: carico sostenuto, temperature, memoria, alimentazione. Una scheda che va in throttling al primo batch reale è un problema che volete trovare il primo giorno, non il giorno del lancio.

Allineamento di driver e toolkit.

Kernel, driver, toolkit CUDA, container runtime e framework di serving devono tutti andare d'accordo tra loro. Vanno d'accordo il giorno in cui li fissate. Ogni aggiornamento a uno qualsiasi di essi riapre la questione.

Packaging del modello.

Pesi, tokenizer, quantizzazione e il budget di VRAM che ne consegue. La scelta della quantizzazione decide se il modello ci sta, quanto in fretta risponde e quanta qualità cede, e i numeri pubblicati sono un punto di partenza, non una garanzia per il vostro hardware.

Tuning del serving stack.

Batching, lunghezza del contesto, dimensionamento della KV-cache e concorrenza, ottimizzati sul vostro obiettivo di latenza e non sui valori predefiniti del framework. È qui che vive la maggior parte del throughput, ed è lavoro che nessuno vede quando è fatto bene.

Cablaggio dell'endpoint.

TLS, autenticazione, un percorso di rete privato verso l'applicazione che lo chiama, e la decisione su cosa è raggiungibile da dove. Un endpoint di inference raggiungibile dalla rete internet pubblica è una passività prima di essere una funzionalità.

Osservabilità.

Salute della scheda, pressione sulla VRAM, profondità della coda e percentili di latenza, con qualcuno che li guarda davvero. Una GPU che gira silenziosamente a metà velocità ha esattamente l'aspetto di una sana su un dashboard che controlla solo se il processo è su.

Aggiornamenti, con una via di ritorno.

Aggiornamenti di modello, driver e stack applicati secondo un calendario, testati prima di arrivare, con un rollback che è stato provato. Saltare gli aggiornamenti compra quiete per un po' e poi una settimana molto rumorosa.

Test di carico.

Dimostrate che l'endpoint regge la vostra concorrenza al vostro obiettivo di latenza prima che qualcosa dipenda da lui. La prima volta che l'endpoint vede traffico reale non dovrebbe essere la prima volta che qualcuno lo ha misurato.

Reperibilità.

Quando si rompe alle 3 di notte, qualcuno deve farsene carico. Non su un turno in un foglio di calcolo: un ingegnere che conosce lo stack, sveglio, con gli accessi.