SHEBANG
Alla tjänster

AI-infrastruktur

Vi bygger plattformen för inferens, finjustering på era data och träning över flera GPU:er, från en server till en miljö som flera team delar.

Arbetslasten formar plattformen

  • Inferens: svarstid, genomströmning, tillgänglighet och minne för modell och kontext.
  • Finjustering: schemalagda jobb, dataset och spårbara experiment. Avbrutna jobb återstartas från checkpoint.
  • Distribuerad träning: GPU-kommunikation, nätverksfabric, checkpoint-lagring och återstart efter fel.
  • API med autentisering och skydd, servingmotor som vLLM eller SGLang, modellversioner och routing.
  • Kvoter mellan team, jobbplanering och insyn i GPU-användning, svarstid, fel och köer.
Modell-API: Autentisering, nätverksskydd, routing och versioner.. Servingmotor: Exempelvis vLLM eller SGLang med kapacitetskontroll.. Kvoter och schemaläggning: Separera team och planera jobb och GPU:er.. Observability: GPU, svarstid, fel och köer med larm.. Data och modeller: Dataset, modellfiler, experiment och checkpoints.. GPU-stöd: Kubernetes-plugin, GPU Operator, Linux eller VM.. GPU-servrar: Validerade drivrutiner och container-runtime.. GPU-minne: Modell och kontext per anrop.
  1. Modell-APIAutentisering, nätverksskydd, routing och versioner.
  2. ServingmotorExempelvis vLLM eller SGLang med kapacitetskontroll.
  3. Kvoter och schemaläggningSeparera team och planera jobb och GPU:er.
  4. ObservabilityGPU, svarstid, fel och köer med larm.
  5. Data och modellerDataset, modellfiler, experiment och checkpoints.
  6. GPU-stödKubernetes-plugin, GPU Operator, Linux eller VM.
  7. GPU-servrarValiderade drivrutiner och container-runtime.
  8. GPU-minneModell och kontext per anrop.

Vad styr dimensioneringen?

Minnesbilden är schematisk, inte skalenlig, och utgår från lång kontext. Den visar mekanismer, inte ett kapacitetslöfte.

  • Modellstorlek avgör vikternas minne och eventuell uppdelning över GPU:er.
  • Samtidiga anrop påverkar genomströmning, köer och minne.
  • Längre kontext kräver mer minne per anrop och påverkar svarstid.
  • Lägre precision kan minska minnesbehovet, men kvalitet måste testas.
  • Jämn last, toppar och batchjobb styr kvoter och delning.
Modellstorlek
Samtidiga anrop
Precision
Modellvikter. Kontext per anrop. GPU-minne. Ryms i en GPU
  1. Modellvikter
  2. Kontext per anrop
  3. GPU-minne
  4. Ryms i en GPU

Linux, Kubernetes eller virtuell maskin

  • Linux direkt på server för en modell eller ett jobb per server.
  • Kubernetes på Talos för delade GPU:er, flera modeller, team och jobb.
  • Proxmox-VM med GPU-passthrough när GPU-arbetslasten ska samsas med virtuella maskiner.
  • Ny hårdvara dimensioneras efter arbetslasten och leverantörernas förslag jämförs.
Linux. Kubernetes. Proxmox VE. GPU-servrar
  1. Linux
  2. Kubernetes
  3. Proxmox VE
  4. GPU-servrar

Från dimensionering till mätning

  • Kartlägg modeller, anrop och data. Leverera arbetslastprofil och hårdvarubehov.
  • Specificera GPU, CPU, minne, lagring, fabric och GPU-länkar samt rack, ström och kylning vid behov.
  • Ni och era leverantörer köper och installerar hårdvaran.
  • Konfigurera drivrutiner, container-runtime, GPU-stöd, kvoter, jobbmiljö, servingmotor, API och nätverk.
  • Mät svarstid, genomströmning, minne och beteende vid fel och återstart med era anrop och data före produktion.

Ni kan driva plattformen

  • Kod, arbetslastprofil, designbeslut, kompatibilitetsmatris och mätrapport är era.
  • Runbooks för drift, uppgraderingar och återstart, med konton, nycklar och namngivna ägare.
  • Teamet levererar ny modellversion via API, återstartar träning från checkpoint och uppgraderar drivrutiner i test.

Relaterade tjänster

Infrastrukturplanering & hårdvaraInferens & modellservingModelloptimeringMLOpsProxmox VEAWS

Prata med oss om AI-infrastruktur

Så arbetar viMöt teamet

Vi använder informationen endast för att kontakta dig kring det du skrivit om. Läs mer i vår integritetspolicy och cookiepolicy.