boc/intelligence/build-a2-vram-konflikt.md

BUILD-A2: VRAM-konflikt GPU-box — Analys & Strategi

Datum: 2026-06-06 21:32 UTC
GPU-box: ubuntu@172.31.36.61 (NVIDIA A10G, 23 028 MiB VRAM)

---

1. Nuläge (faktisk nvidia-smi)

NVIDIA A10G | Persistence-M: On | 30°C | P0 | 60W/300W
Memory: 19699 MiB / 23028 MiB (85,5% VRAM upptaget)

Processes:
  PID   8873  VLLM::EngineCore   19690 MiB

Vad körs exakt (ps aux):

PID 8817: bash -c "source ~/eslm-venv/bin/activate && vllm serve ~/aamos_merged 
           --served-model-name aamos-eslm --host 0.0.0.0 --port 8000 
           --max-model-len 8192 --quantization bitsandbytes --enforce-eager 
           --gpu-memory-utilization 0.85"
PID 8818: /home/ubuntu/eslm-venv/bin/python3 ... (API-servern)
PID 8873: VLLM::EngineCore (den som äger VRAM:en)

Trafikstatus: vLLM servar aktivt — loggarna visar POST-anrop från 172.31.35.76 (red-team-maskinen) med 10-sekunders-mellanrum så sent som 21:01:01 UTC. Red-team är aktivt pågående.

Modell som serveras: ~/aamos_merged — detta är den mergade 4-bit BitsAndBytes-kvantiserade Qwen2.5-7B modellen (ESLM), inte LoRA-adaptern separat.

---

2. Serving-script: inventering

~/start_vllm.sh (600 bytes, skapad 2026-05-30)

#!/bin/bash
FULL_PATH="/home/ubuntu/.cache/huggingface/hub/models--Qwen--Qwen2.5-7B-Instruct/snapshots/a09a35458c702b33eeacc393d103063234e8bc28"

pkill -f "vllm.entrypoints" 2>/dev/null
sleep 2

nohup /home/ubuntu/vllm_env/bin/python3 -m vllm.entrypoints.openai.api_server \
    --model $FULL_PATH \
    --served-model-name aamos-qwen25-7b \
    --host 0.0.0.0 \
    --port 8000 \
    --max-model-len 4096 \
    --gpu-memory-utilization 0.85 \
    --enable-lora \
    --max-lora-rank 64 \
    --lora-extra-vocab-size 256 \
    --dtype bfloat16 \
    > /tmp/vllm.log 2>&1 &
echo "vLLM started PID:$!"

Vad det gör: Servar bas-modellen (Qwen2.5-7B-Instruct från HF-cache) med LoRA-stöd aktiverat. Kan dynamiskt ladda LoRA-adaptrar via API:t. Venv: vllm_env. Nohup + background.

~/start_vllm_lora.sh (422 bytes, skapad 2026-05-30)

#!/bin/bash
/home/ubuntu/vllm_env/bin/python3 -m vllm.entrypoints.openai.api_server \
    --model /home/ubuntu/.cache/huggingface/hub/.../Qwen2.5-7B-Instruct/... \
    --served-model-name aamos-base \
    --host 0.0.0.0 \
    --port 8000 \
    --max-model-len 2048 \
    --enable-lora \
    --max-lora-rank 64 \
    --lora-modules "aamos=/home/ubuntu/aamos_adapter" \
    --dtype bfloat16 \
    --gpu-memory-utilization 0.88

Vad det gör: Servar bas-modellen MED LoRA-adapter inladdad statiskt vid start (aamos_adapter/). Kortare context (2048), lite högre GPU-util (0.88). Kör inte i nohup — förgrundsprocess. Venv: vllm_env.

Aktuell körning (inte något av dessa script)

Den som körs nu startades direkt från eslm-venv, inte vllm_env, och servar ~/aamos_merged (mergad modell). Det är ett tredje sätt att starta — sannolikt manuellt eller via ett okänt script.

Tillgängliga venv:

Venv	Innehåll	Syfte
eslm-venv	vLLM + transformers 5.10.2 + bitsandbytes 0.49.2	Serving (nuvarande)
vllm_env	vLLM + transformers 5.5.0	Serving (start_vllm*.sh)
train_env	unsloth 2026.5.8 + peft + trl + bitsandbytes	Träning (Unsloth/LoRA)

---

3. VRAM-budget-kalkyl

Faktisk fördelning just nu:

Total VRAM:          23 028 MiB  (100%)
vLLM tar nu:         19 699 MiB  (85,5%)
  varav modell:       ~5 200 MiB  (4-bit BnB Qwen2.5-7B ≈ 5.2 GB)
  varav KV-cache:    ~14 500 MiB  (gpu-util 0.85 × 23GB − modell)
Fritt just nu:          3 329 MiB  (14,5%)

Unsloth-träning 7B 4-bit LoRA behöver:

Modell (4-bit weights):           ~5 200 MiB
Gradienter (LoRA-parametrar):     ~  800 MiB   (rank 64, ~1% av params)
Optimizer states (AdamW 8-bit):   ~1 000 MiB
Aktiveringscache (batch_size=4):  ~4 000 MiB
CUDA-overhead + buffers:          ~  500 MiB
                                 ───────────
Minimum rimligt:                  ~11 500 MiB
Mer realistiskt (batch 8):        ~14 000 MiB

Kan BÅDA plats?

vLLM (reducerad gpu-util 0.4):
  Modell:    ~5 200 MiB
  KV-cache:  ~4 000 MiB  (0.4 × 23GB − modell)
  Subtotal:  ~9 200 MiB

Träning (minimal batch=2):        ~10 500 MiB

TOTALT:                           ~19 700 MiB  (86%)

Teoretiskt möjligt på pappret, men extremt riskabelt:

• Minnesallokering är inte deterministisk — fragmentering kan ge OOM
• Unsloth allokerar dynamiskt vid forward pass — spikes uppåt ~3GB
• vLLM pre-allokerar KV-cache vid start, ger inga varningar
• En enkelt batch-spike = CUDA OOM = kraschad träning

SLUTSATS: NEJ, de kan inte köras simultant på ett säkert sätt.

---

4. Strategianalys

Alt A: Stoppa vLLM under träning, starta om efter

• ✅ Enklast — inga konfigurationsändringar
• ✅ Full VRAM för träning (~23GB) — snabbare, lägre OOM-risk
• ✅ Deterministiskt och reproducerbart
• ❌ Red-team-endpointen nere ~1-3h under träning
• Risk: Låg (om red-team koordineras)

Alt B: Reducera vLLM gpu-util + träna med liten batch

• ❌ Extremt riskabelt (se kalkyl ovan)
• ❌ Träning tar 3-5× längre med batch=2
• ❌ Svårt att reproducera (OOM-sannolikhet okänd)
• ❌ Kräver konfigurationsändringar i båda riktningar
• Risk: Hög — rekommenderas inte

Alt C: Red-team FÖRE träning → stoppa vLLM → träna → starta om → red-team igen

• ✅ Bästa alternativet — ger jämförbar baslinje + post-träning
• ✅ Red-team hinner samla baslinje-data utan avbrott
• ✅ Tydlig before/after-struktur för utvärdering
• ✅ vLLM körs med full VRAM i båda faserna (konsistenta resultat)
• ✅ Reproducerbart: samma start_vllm.sh (eller eslm-venv-kommandot) startar om serving
• ⏱️ Kräver koordination: red-team måste veta när fas 1 slutar

---

5. Rekommenderad strategi: Alt C

Motivering:

Red-team körs just nu aktivt (loggarna visar anrop in i 21:01 UTC). Det betyder fas 1 (baslinje) redan är igång. Rätt sekvens:

1. Låt red-team slutföra baslinje-körning mot nuvarande aamos-eslm (kör klart)
2. Stoppa vLLM rent
3. Kör ESLM-omträning med full VRAM (train_env + Unsloth)
4. Starta vLLM med den nya ESLM
5. Kör red-team igen — jämför mot baslinje

---

6. Exakta kommandon

6.1 Stoppa vLLM rent (INGEN mutation nu — bara dokumentation)

ssh -i ~/.ssh/gpu_deploy_key ubuntu@172.31.36.61

# Kontrollera att red-team är klart INNAN du kör detta:
curl -s http://172.31.36.61:8000/v1/models | python3 -m json.tool

# Stoppa vLLM (PID 8817/8818/8873):
kill 8817 8818
sleep 3
# Om inte dött:
pkill -f "vllm serve"
pkill -f "VLLM::EngineCore"
# Verifiera:
nvidia-smi  # ska visa 0 MiB VRAM i use

OBS: PID:arna 8817/8818/8873 är aktuella nu (2026-06-06 21:32). Om servern omstartas kan PID:arna ändras — använd pkill -f som är PID-oberoende.

6.2 Starta ESLM-omträning (efter att vLLM stoppats)

ssh -i ~/.ssh/gpu_deploy_key ubuntu@172.31.36.61
source ~/train_env/bin/activate

# Verifiera GPU är fri:
nvidia-smi

# Starta träning (exakt kommando beror på träningsskript — BUILD-A3 ansvarar)
# Förväntad VRAM-användning: 14-20 GB (Unsloth 4-bit LoRA, batch 4-8)

6.3 Starta om vLLM efter träning

Alternativ 1: Samma konfiguration som nu (rekommenderas — identisk red-team-miljö)

ssh -i ~/.ssh/gpu_deploy_key ubuntu@172.31.36.61

# Starta eslm-venv-versionen (samma som körs nu):
source ~/eslm-venv/bin/activate
export VLLM_ATTENTION_BACKEND=FLASH_ATTN
export VLLM_USE_FLASHINFER_SAMPLER=0

nohup vllm serve ~/aamos_merged \
    --served-model-name aamos-eslm \
    --host 0.0.0.0 --port 8000 \
    --max-model-len 8192 \
    --quantization bitsandbytes \
    --enforce-eager \
    --gpu-memory-utilization 0.85 \
    > ~/vllm-serve.log 2>&1 &

echo "vLLM restarted, PID: $!"
# Vänta ~60s på uppstart:
sleep 60 && curl http://172.31.36.61:8000/v1/models

Alternativ 2: Med inbakad LoRA-adapter (start_vllm_lora.sh — återanvändbart)

ssh -i ~/.ssh/gpu_deploy_key ubuntu@172.31.36.61
nohup ~/start_vllm_lora.sh > /tmp/vllm-lora.log 2>&1 &

Alternativ 3: Med dynamisk LoRA-laddning (start_vllm.sh — återanvändbart)

ssh -i ~/.ssh/gpu_deploy_key ubuntu@172.31.36.61
~/start_vllm.sh

6.4 Verifiera att vLLM är igång

# Från GPU-boxen eller server-2:
curl http://172.31.36.61:8000/v1/models
curl http://172.31.36.61:8000/health

# Kolla VRAM:
nvidia-smi

---

7. Noteringar inför nästa BUILD

start_vllm_lora.sh — återanvändbart ✅

• Laddar ~/aamos_adapter (LoRA) direkt vid uppstart
• Servar bas-modellen med adapter inbakad → rödbräm mot ny adapter efter träning = byt ut ~/aamos_adapter
• Kortare context (2048) vs eslm-venv-varianten (8192) — kan bli begränsande för red-team

Separata venv är en fördel:

• train_env kör aldrig vLLM → ingen versionskollision
• eslm-venv kör aldrig träning → rent

Red-team-trafik-källa:

• Alla anrop kommer från 172.31.35.76 — det är red-team-maskinen/scriptet
• Port 8000 öppen internt på VPC — inga externa anrop

Modell-hierarki på boxen:

~/aamos_adapter/        → LoRA-adapter (161 MB) — senaste tränad ESLM
~/aamos_merged/         → Mergad full modell (5.5 GB) — det som serveras nu
~/.cache/huggingface/   → Qwen2.5-7B-Instruct bas (HF-cache)

---

8. Beslutspunkt för projektet

Innan träning kan starta behöver följande beslutas:

1. Är red-team-baslinjen klar? (kontrollera loggarna på red-team-maskinen)
2. Vad är det exakta träningsskriptet? (train_env är redo med Unsloth, men inget train.py hittades i ~ — BUILD-A3 bör ha det)
3. Ska den tränade adaptern mergas (aamos_merged) eller laddas som LoRA? (påverkar vilken start-variant som används efter)

---

Genererat av BUILD-A2 subagent | Baserat på faktisk nvidia-smi + ps aux output | Inga mutationer gjorda