Un flusso di lavoro AI necessita di risorse per i suoi strumenti effettivi e la concorrenza, e di permessi che rimangano applicabili al di fuori del modello. L'inferenza remota e quella locale portano a decisioni diverse su CPU, memoria, storage e GPU.
Definisci il lavoro prima di scegliere una macchina
Un worker AI combina un modello con software che riceve attività, raccoglie contesto e chiama strumenti. Un classificatore di documenti pianificato, un assistente di ricerca interno e un flusso di lavoro guidato dal browser hanno esigenze operative diverse. Annota l'input, l'output previsto, i sistemi che può contattare e il punto in cui una persona approva un'azione consequenziale. Questa piccola specifica ti dice più sull'host dell'etichetta "agent".
Inizia con un lavoro ripetibile e un account ristretto. Un worker che redige una risposta necessita di meno autorità di uno che la invia. Mantieni queste fasi separate nell'applicazione. Il server dovrebbe supportare il flusso di lavoro approvato senza trasformare ogni istruzione generata in un'operazione eseguibile. Il completamento significa un risultato verificato o uno stato di errore chiaro, non un ciclo in esecuzione indefinita.
Separa un modello remoto da un modello locale
Quando il modello viene eseguito dietro un API esterno, il VPS ospita principalmente la coda, l'applicazione, gli strumenti e lo stato persistente. La sua domanda di memoria deriva da quei processi, inclusi eventuali browser o parser di documenti. Una GPU su questa macchina non accelera un modello in esecuzione altrove. Registra quali contenuti attraversano il confine API e valuta quel provider indipendentemente dalla posizione del worker.
L'inferenza locale aggiunge al budget storage del modello, memoria del modello e compatibilità runtime. Strumenti di inferenza come Ollama espongono informazioni sul posizionamento di CPU o GPU e sulle richieste concorrenti. Testa insieme il modello scelto, la lunghezza del contesto e la concorrenza. Un contesto più ampio o più job simultanei possono aumentare la domanda di memoria; la sola dimensione del file del modello è un metodo di dimensionamento incompleto. Controlla l'hardware supportato dal runtime prima di selezionare una configurazione GPU.
| Pattern del worker | Domanda principale sulle risorse | Confine da riesaminare |
|---|---|---|
| Modello remoto API | Memoria dell'applicazione e degli strumenti | Contenuto inviato al provider del modello |
| Modello locale | Modello, contesto e memoria di lavoro | Compatibilità runtime e dispositivo |
| Flusso di lavoro del browser | Processi browser di picco e file temporanei | Contenuto web e azioni consentite |
Misura una coda rappresentativa
Prepara un piccolo insieme di attività con input normali e insolitamente grandi. Misura la memoria di picco, il tempo di elaborazione trascorso, lo storage temporaneo e il numero di chiamate esterne. Includi casi di errore: un API non disponibile, un documento malformato e un timeout di uno strumento. Queste misurazioni sono un esercizio di pianificazione per il tuo software, non un benchmark o una promessa di prestazioni per un piano SwissOctet.
Imposta un numero massimo di job attivi e un tempo massimo di esecuzione. Metti in coda il lavoro che non può iniziare in sicurezza e rifiuta il sovraccarico in modo prevedibile. Riprovare immediatamente ogni errore può moltiplicare sia la pressione sul server sia la spesa API. Usa una politica di retry limitata e un identificatore che impedisca di applicare due volte la stessa azione completata. Riserva capacità per il sistema operativo, il monitoraggio e la manutenzione mentre i job sono attivi.
Concedi agli strumenti meno autorità dell'ambizione del worker
I documenti e le pagine web forniti a un modello possono contenere istruzioni intese a reindirizzarlo. Tratta il contenuto recuperato come input, non come fonte di autorizzazione operativa. Le linee guida di OWASP sul prompt injection raccomandano diversi livelli di controllo, inclusi strumenti limitati e verifiche attorno alle azioni sensibili. Metti i permessi nell'implementazione degli strumenti e nell'ambiente operativo, dove il modello non può riscriverli tramite una risposta.
Usa credenziali separate per job separati, con accesso solo ai record o alle directory di cui ciascuno ha bisogno. Preferisci parametri strutturati ai comandi shell generati dal modello. Convalida le destinazioni dei file e gli obiettivi in uscita. Richiedi un confine di approvazione deliberato per inviare messaggi, pubblicare modifiche o modificare record importanti. Un worker di ricerca in sola lettura e un amministratore di produzione non dovrebbero mai ereditare le stesse credenziali solo perché entrambi vengono eseguiti su un unico host.
Mantieni espliciti i controlli delle risorse e il ripristino
I container possono organizzare dipendenze e confini di processo, ma necessitano di una configurazione deliberata. Docker documenta che i container non hanno limiti di risorse per impostazione predefinita. Imposta limiti adeguati di memoria e CPU, usa un processo non privilegiato ove supportato e monta solo i dati necessari. Mantieni gli endpoint del modello e le interfacce di amministrazione limitati invece di esporli semplicemente per rendere comodo il test iniziale.
Persisti lo stato delle attività separatamente dai file di lavoro temporanei. Registra informazioni sufficienti a riconoscere il lavoro completato dopo un riavvio senza conservare ogni prompt per sempre. Proteggi le credenziali da log e artefatti generati. Definisci la conservazione per input, output e dati diagnostici. Un test di ripristino dovrebbe riavviare il worker e verificare che i job non completati riprendano in sicurezza, i job completati rimangano completati e gli errori rimangano visibili all'operatore.
Fai del primo deployment un test di accettazione
Esegui il flusso di lavoro ristretto con dati sintetici o campioni approvati prima di concedere un accesso più ampio. Controlla l'output utile, i permessi, il comportamento della coda e il ripristino da una dipendenza non riuscita. Osserva l'intero processo, inclusi i processi browser figli e i download di dati. Se il modello è locale, includi nel test un avvio a freddo e il numero previsto di richieste concorrenti.
Usa Vector o Pulse come shortlist di specifiche per worker ordinari, e confronta Tensor solo quando il runtime di inferenza necessita di risorse GPU adeguate. Conferma compatibilità e disponibilità prima di un ordine reale. Espandi i permessi del worker solo dopo che il suo comportamento può essere riesaminato. L'obiettivo è un servizio con un chiaro involucro operativo, un budget di risorse misurabile e un modo semplice per fermare e ripristinare il lavoro.
La tua checklist pratica.
- Descrivi un lavoro e il suo confine di approvazione.
- Separa l'elaborazione remota API dall'inferenza locale.
- Misura strumenti, browser e concorrenza di picco.
- Applica limiti di tempo, risorse e permessi.
- Testa i riavvii senza duplicare le azioni completate.
I dettagli che contano.
Ogni worker AI necessita di una GPU?+
No. Un worker che chiama un modello remoto API di solito necessita di risorse per l'orchestrazione e gli strumenti. L'inferenza locale ha requisiti hardware e runtime separati.
Un container rende sicuro un flusso di lavoro autonomo?+
No. Configura i suoi permessi, mount, accesso alla rete e limiti di risorse, e verifica le azioni consequenziali degli strumenti al di fuori del modello.
Ospitare il worker in Svizzera mantiene lì ogni prompt?+
No. Le API dei modelli remoti e altre integrazioni possono elaborare contenuti altrove. Mappa esplicitamente quelle dipendenze.
Vai alla fonte.
Questi riferimenti supportano i concetti tecnici di questa guida. Segui la documentazione corrente prima di modificare un sistema di produzione.
- Docker: vincoli sulle risorse docs.docker.com
- OWASP: prevenzione del prompt injection negli LLM cheatsheetseries.owasp.org
- Ollama: FAQ su runtime e concorrenza docs.ollama.com
Guida editoriale di SwissOctet. Gli esempi sono illustrativi. Le specifiche di servizio, le opzioni disponibili e le condizioni contrattuali devono essere verificate separatamente.