Jeg ønsket en enkel, repeterbar måte å besvare et praktisk spørsmål på:

“Hvis vi måtte kjøre en privat modell på AWS, hva er den operasjonelle virkeligheten på Inf2 / Trn3?”

Dette innlegget dokumenterer ett lite praktisk eksperiment (Inf2) pluss de nøyaktige oppfølgingskontrollene jeg ville kjørt på Trn3.

Eksperimentoppsett (Inf2) Lenke til overskrift

Dette var en rask “kan vi få det til å fungere ende-til-ende?"-test, ikke en full benchmark-suite.

  • Dato for kjøring: 2026-02-01
  • Instans testet: inf2.xlarge
  • Region: us-east-2
  • Modell: meta-llama/Llama-4-Maverick-17B-128E-Instruct
  • Serving layer: vLLM på Neuron
  • API surface: OpenAI-kompatible endepunkter (/v1/chat/completions, /v1/completions)
  • Port: 8080

Hva fungerte (og hvorfor det er viktig) Lenke til overskrift

Kjernepunktet: vLLM på Neuron fungerer, og det OpenAI-kompatible API-et gjør det enkelt å koble til verktøy uten å skrive egne klienter.

Når det er sagt, var det noen veldig “virkelige” operasjonelle lærdommer som betyr mer enn rå tokens/sek.

1) Første gangs Neuron-kompilering er kostbar Lenke til overskrift

Første gang du kjører en spesifikk modellkonfigurasjon, kan Neuron-kompileringen ta ~15–30 minutter.

Dette er ikke i seg selv et problem, men det endrer brukeropplevelsen for:

  • rullende omstarter
  • autoskalering
  • spot-avbrudd

2) Vedvarende cacher eller omstarter vil skade Lenke til overskrift

Den praktiske løsningen er enkel: vedvarende HuggingFace-cache og Neuron-kompilerte artefakter på vertsdisk, slik at omstarter blir raske (ofte < 1 minutt når de er varmet opp).

Hvis du behandler instansen som engangs uten vedvarende cacher, vil du betale kompileringskostnaden gjentatte ganger.

3) Disk er den første feilmodusen Lenke til overskrift

For denne typen eksperiment fylles disken opp før CPU-en gjør det.

Tommelfingerregel fra denne kjøringen:

  • 200 GB minimum
  • 500 GB anbefalt for “ekte testing” (modellvekter + kompilerte artefakter + Docker-lag + logger)

“Privat modell på EC2” testflyt (repeterbar) Lenke til overskrift

Her er den minimale flyten jeg brukte og ville brukt igjen:

  1. Start EC2 (Inf2 eller Trn3) med stor gp3 EBS og fornuftig IAM/SSM-tilgang.
  2. Koble til via SSM (foretrukket) i stedet for å åpne SSH for verden.
  3. Start vLLM (Neuron)-containeren med vertsvedvarende cacher.
  4. Røyktest det OpenAI-kompatible API-et (models, chat, completion).
  5. Observer logger og maskinvaremålinger mens du kjører en liten forespørselsløkke.

Spot-instanser: gjør det rimelig (med én regel) Lenke til overskrift

For benchmarks og eksperimenter gjør Spot dette dramatisk billigere enn On-Demand.

Den ene regelen: design oppsettet for avbrudd.

  • Bruk Spot for kjøringen.
  • Anta at den vil bli avbrutt.
  • Hold cacher på EBS (og snapshot/backup hvis du ønsker raskere gjenoppretting).
  • Foretrekk kapasitetsoptimalisert allokering når du kan.

Hva med Trn3/Trn4? Lenke til overskrift

Vi testet kraften til Inf2, men Trn3/Trn4 er foreløpig kun tilgjengelig på forespørsel.

Inf2 kunne gi oss hastigheten til de offentlige modellleverandørene, og sammen med modellutviklingen og veksten vil det kreve mindre og mindre ressurser i fremtiden.

Men hovedpoenget er uavhengighet fra Nvidia- og AMD-brikkene – de er begrenset og etterspørselen er høy.

Konklusjon Lenke til overskrift

For mine nåværende (bursty) arbeidsmengder trenger jeg ikke privat modellhosting akkurat nå: offentlige API-er er billigere og krever betydelig mindre operasjoner.

Men hvis du har strenge krav (private/proprietære modeller eller strenge datagrenser), er Inf2/Trn3 + vLLM (Neuron) en pragmatisk AWS-vei – bare planlegg for kompileringstid, vedvarende cacher og store disker.