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)
```bash
#!/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)
```bash
#!/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)

```bash
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)

```bash
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ö)**
```bash
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)**
```bash
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)**
```bash
ssh -i ~/.ssh/gpu_deploy_key ubuntu@172.31.36.61
~/start_vllm.sh
```

### 6.4 Verifiera att vLLM är igång
```bash
# 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*