changes

bayarea-ai-server/docker-compose-llama-gemma12b-vulkan.yml

@@ -0,0 +1,62 @@
+# llama.cpp + Gemma-4-12B (Vision) - VULKAN-Backend statt ROCm.
+#
+# Grund fuer den Wechsel: Gemma-4-Vision unter ROCm geraet in eine
+# Endlosschleife (<unused>-Flood, llama.cpp Issue #21416) - ein ROCm-Backend-Bug.
+# Der Report bestaetigt: "With vulkan it works on the same hardware."
+# Gleiche Karte (R9700), gleiches Modell, gleicher Client - nur Backend anders.
+#
+# Wichtige Unterschiede zu ROCm:
+#   - KEIN /dev/kfd noetig (Vulkan nutzt den Grafik-Stack, nicht ROCm-Compute)
+#   - Gruppe 'render' zusaetzlich (Zugriff auf /dev/dri/renderD*)
+#   - --device Vulkan0 explizit, sonst evtl. CPU-Fallback (llvmpipe)
+#
+# Laeuft ALLEIN auf der GPU (Qwen vorher stoppen).
+#
+# Start:  docker compose -f docker-compose-llama-gemma12b.yml up -d
+# Logs:   docker compose -f docker-compose-llama-gemma12b.yml logs -f
+
+services:
+  llamacpp-gemma12b:
+    image: ghcr.io/ggml-org/llama.cpp:server-vulkan
+    container_name: llamacpp-gemma12b
+    restart: unless-stopped
+    init: true
+    devices:
+      - /dev/dri:/dev/dri
+    group_add:
+      - video
+      - "991"  # GID der render-Gruppe (getent group render -> 991)
+    security_opt:
+      - seccomp=unconfined
+    ipc: host
+    environment:
+      # Nur die erste (einzige) GPU sichtbar machen; CPU-Fallback vermeiden
+      - GGML_VK_VISIBLE_DEVICES=0
+    ports:
+      - "8000:8080"
+    volumes:
+      - ~/.cache/llama.cpp:/root/.cache/llama.cpp
+    command:
+      - -hf
+      - unsloth/gemma-4-12b-it-GGUF:UD-Q4_K_XL
+      - --host
+      - 0.0.0.0
+      - --port
+      - "8080"
+      - --device
+      - Vulkan0
+      - -ngl
+      - "99"
+      - --ctx-size
+      - "8192"
+      - --parallel
+      - "1"
+      - --jinja
+      - --reasoning
+      - "off"
+      - --cache-ram
+      - "0"
+      - --ctx-checkpoints
+      - "0"
+      - --alias
+      - gemma-4-12b

bayarea-ai-server/docker-compose-llama-gemma12b.yml

@@ -1,6 +1,13 @@
 # llama.cpp + Gemma-4-12B (Vision) fuer die Buyer-Sheet-Extraktion.
-# Basiert auf dem bewaehrten Qwen-Run (gleiche ROCm-Flags), erweitert um
-# Vision (mmproj laedt -hf automatisch) und --reasoning off (sonst leeres content).
+# Laeuft ALLEIN auf der GPU (Qwen vorher stoppen: docker stop llamacpp-qwen36).
+#
+# Wichtige Stabilitaets-Parameter gegen das kumulative Verklemmen:
+#   --cache-ram 0        Prompt-Cache AUS. Die Vision-Requests teilen keinen
+#                        sinnvollen Prefix; der Cache brachte nur Thrashing
+#                        ("making room ... MiB") bis zum Slot-Deadlock.
+#                        Ohne Cache ist jeder Request wirklich unabhaengig.
+#   --ctx-size 8192      reicht fuer ein Sheet + JSON-Antwort; halber KV-Speicher.
+#   --no-context-shift   sauberes Abschneiden statt fragwuerdigem Shift.
 #
 # Start:  docker compose -f docker-compose-llama-gemma12b.yml up -d
 # Logs:   docker compose -f docker-compose-llama-gemma12b.yml logs -f
@@ -11,7 +18,6 @@ services:
     image: ghcr.io/ggml-org/llama.cpp:server-rocm
     container_name: llamacpp-gemma12b
     restart: unless-stopped
-    # init:true -> haengende Prozesse werden ordentlich eingesammelt (kein Zombie)
     init: true
     devices:
       - /dev/kfd:/dev/kfd
@@ -22,8 +28,6 @@ services:
       - seccomp=unconfined
     ipc: host
     ports:
-      # Achtung: Qwen laeuft schon auf 8080. Gemma bekommt 8000, damit beide
-      # parallel laufen koennen. Client entsprechend auf :8000 zeigen.
       - "8000:8080"
     volumes:
       - ~/.cache/llama.cpp:/root/.cache/llama.cpp
@@ -37,11 +41,14 @@ services:
       - -ngl
       - "99"
       - --ctx-size
-      - "16384"
+      - "8192"
       - --parallel
       - "1"
       - --jinja
       - --reasoning
       - "off"
+      - --cache-ram
+      - "0"
+      - --no-context-shift
       - --alias
-      - gemma-4-12b
+      - gemma-4-12b