En AI-arbeidsflyt trenger ressurser til sine faktiske verktøy og samtidighet, og tillatelser som forblir håndhevbare utenfor modellen. Ekstern inferens og lokal inferens fører til ulike beslutninger om CPU, minne, lagring og GPU.
Navngi jobben før du velger maskin
En AI-arbeider kombinerer en modell med programvare som mottar oppgaver, samler kontekst og kaller verktøy. En planlagt dokumentklassifiserer, en intern søkeassistent og en nettleserdrevet arbeidsflyt har ulike driftsbehov. Skriv ned inndataene, forventet utdata, systemene den kan kontakte og punktet der et menneske godkjenner en handling med konsekvenser. Denne lille spesifikasjonen sier mer om verten enn etiketten agent.
Start med én repeterbar jobb og en smal konto. En arbeider som utformer et svar, trenger mindre myndighet enn en som sender det. Hold disse trinnene atskilt i applikasjonen. Serveren skal støtte den godkjente arbeidsflyten uten å gjøre hver generert instruksjon om til en kjørbar operasjon. Fullføring betyr et verifisert resultat eller en tydelig feilstatus, ikke en løkke som kjører i det uendelige.
Skill en ekstern modell fra en lokal modell
Når modellen kjører bak en ekstern API, er VPS hovedsakelig vert for køen, applikasjonen, verktøyene og vedvarende tilstand. Minnebehovet kommer fra disse prosessene, inkludert eventuelle nettlesere eller dokumenttolkere. En GPU på denne maskinen akselererer ikke en modell som kjører et annet sted. Registrer hvilket innhold som krysser API-grensen, og vurder den leverandøren uavhengig av hvor arbeideren befinner seg.
Lokal inferens legger til modellagring, modellminne og kjøretidskompatibilitet i budsjettet. Inferensverktøy som Ollama gir informasjon om CPU- eller GPU-plassering og samtidige forespørsler. Test den valgte modellen, kontekstlengden og samtidigheten sammen. En større kontekst eller flere samtidige jobber kan øke minnebehovet; en modellfilstørrelse alene er en ufullstendig dimensjoneringsmetode. Sjekk kjøretidens støttede maskinvare før du velger en GPU-konfigurasjon.
| Arbeidermønster | Hovedspørsmål om ressurser | Grense å gjennomgå |
|---|---|---|
| Ekstern modell API | Applikasjons- og verktøyminne | Innhold sendt til modellleverandøren |
| Lokal modell | Modell, kontekst og arbeidsminne | Kjøretids- og enhetskompatibilitet |
| Nettleserarbeidsflyt | Toppunkt for nettleserprosesser og midlertidige filer | Webinnhold og tillatte handlinger |
Mål en representativ kø
Forbered et lite sett med oppgaver med normale og uvanlig store inndata. Mål toppminne, medgått behandlingstid, midlertidig lagring og antall eksterne kall. Inkluder feiltilfeller: en utilgjengelig API, et feilformet dokument og en verktøytidsavbrudd. Disse målingene er en planleggingsøvelse for programvaren din, ikke en referansemåling eller ytelsesløfte for en SwissOctet-plan.
Sett et maksimalt antall aktive jobber og en maksimal kjøretid. Sett arbeid som ikke kan starte trygt, i kø, og avvis overbelastning på en forutsigbar måte. Å prøve på nytt ved hver feil umiddelbart kan multiplisere både servertrykket og API-forbruket. Bruk en avgrenset retry-policy og en identifikator som hindrer at den samme fullførte handlingen brukes to ganger. Reserver kapasitet til operativsystemet, overvåking og vedlikehold mens jobber er aktive.
Gi verktøyene mindre myndighet enn arbeiderens ambisjon
Dokumenter og nettsider som gis til en modell, kan inneholde instruksjoner ment å omdirigere den. Behandle hentet innhold som inndata, ikke som en kilde til driftsmyndighet. OWASPs veiledning om prompt-injeksjon anbefaler flere lag med kontroll, inkludert begrensede verktøy og sjekker rundt sensitive handlinger. Legg tillatelser i verktøyimplementasjonen og driftsmiljøet, der modellen ikke kan skrive dem om gjennom et svar.
Bruk separate påloggingsdata for separate jobber, med tilgang bare til postene eller katalogene hver av dem trenger. Foretrekk strukturerte parametere fremfor modellgenererte skallkommandoer. Valider filmål og utgående mål. Krev en bevisst godkjenningsgrense for å sende meldinger, publisere endringer eller endre viktige poster. En skrivebeskyttet forskningsarbeider og en produksjonsadministrator bør aldri arve de samme påloggingsdataene bare fordi begge kjører på én vert.
Hold ressurskontroller og gjenoppretting eksplisitt
Containere kan organisere avhengigheter og prosessgrenser, men de krever bevisst konfigurasjon. Docker dokumenterer at containere ikke har ressursgrenser som standard. Sett passende minne- og CPU-grenser, bruk en uprivilegert prosess der det støttes, og monter bare de nødvendige dataene. Hold modellendepunkter og administrasjonsgrensesnitt begrenset i stedet for å eksponere dem bare for å gjøre innledende testing praktisk.
Lagre oppgavetilstanden atskilt fra midlertidige arbeidsfiler. Registrer nok informasjon til å gjenkjenne fullført arbeid etter en omstart uten å lagre hver prompt for alltid. Beskytt påloggingsdata mot logger og genererte artefakter. Definer oppbevaring for inndata, utdata og diagnostiske data. En gjenopprettingstest bør starte arbeideren på nytt og verifisere at ufullførte jobber gjenopptas trygt, at fullførte jobber forblir fullførte og at feil forblir synlige for operatøren.
Gjør den første utrullingen til en akseptansetest
Kjør den smale arbeidsflyten med syntetiske eller godkjente eksempeldata før du gir bredere tilgang. Sjekk nyttige utdata, tillatelser, køatferd og gjenoppretting fra en mislykket avhengighet. Observer hele prosessen, inkludert nettleserunderprosesser og nedlastinger av data. Hvis modellen er lokal, inkluder en kaldstart og det tiltenkte antallet samtidige forespørsler i testen.
Bruk Vector eller Pulse som en spesifikasjonskortliste for vanlige arbeidere, og sammenlign Tensor bare når inferenskjøretiden trenger passende GPU-ressurser. Bekreft kompatibilitet og tilgjengelighet før en reell bestilling. Utvid arbeiderens tillatelser først etter at atferden kan gjennomgås. Målet er en tjeneste med en tydelig driftsramme, et målbart ressursbudsjett og en enkel måte å stoppe og gjenopprette arbeid på.
Din praktiske sjekkliste.
- Beskriv én jobb og dens godkjenningsgrense.
- Skill ekstern API-behandling fra lokal inferens.
- Mål verktøy, nettlesere og toppunkt for samtidighet.
- Bruk grenser for tid, ressurser og tillatelser.
- Test omstarter uten å duplisere fullførte handlinger.
Detaljene som betyr noe.
Trenger hver AI-arbeider en GPU?+
Nei. En arbeider som kaller en ekstern modell API, trenger vanligvis ressurser til orkestrering og verktøy. Lokal inferens har separate krav til maskinvare og kjøretid.
Gjør en container en autonom arbeidsflyt trygg?+
Nei. Konfigurer tillatelsene, monteringene, nettverkstilgangen og ressursgrensene, og sjekk verktøyhandlinger med konsekvenser utenfor modellen.
Holder det å ha arbeideren i Sveits alle prompter der?+
Nei. Eksterne modell-API-er og andre integrasjoner kan behandle innhold andre steder. Kartlegg disse avhengighetene eksplisitt.
Gå til kilden.
Disse referansene støtter de tekniske konseptene i denne veiledningen. Følg gjeldende dokumentasjon før du endrer et produksjonssystem.
- Docker: Ressursbegrensninger docs.docker.com
- OWASP: Forebygging av LLM-prompt-injeksjon cheatsheetseries.owasp.org
- Ollama: FAQ om kjøretid og samtidighet docs.ollama.com
Redaksjonell veiledning av SwissOctet. Eksempler er illustrerende. Tjenestespesifikasjoner, tilgjengelige alternativer og kontraktsvilkår må verifiseres separat.