Severity: Low · Area: Infra + config · Category: improvement
Location: services/text-to-image/Dockerfile:63
What's wrong
Every other GPU service pins its device via a compose env var (CHATTERBOX_GPU, CUDA_VISIBLE_DEVICES=3 for face-recognition, =4 for vllm-vision), but text-to-image hard-codes --default-device 3 in the Dockerfile CMD while compose sets NVIDIA_VISIBLE_DEVICES=all. Changing the GPU requires editing the Dockerfile and rebuilding, and the choice is invisible from compose.yaml. GPU 3 is also one of vLLM's tensor-parallel shards (gpu-memory-utilization 0.79) and hosts face-recognition, so ComfyUI model loads land on the most contended card.
How it fails
An image-generation request loads an SDXL/Flux checkpoint (7-12 GB) onto GPU 3, which already holds ~19 GB of vLLM KV/weights plus InsightFace; CUDA OOM either kills the ComfyUI generation or destabilizes the vLLM shard mid-chat-turn, and the operator finds no GPU assignment for text-to-image anywhere in compose.yaml or .env when debugging.
Suggested fix
Drop --default-device 3 from the Dockerfile CMD and pin via compose like the other services: environment: - CUDA_VISIBLE_DEVICES=${COMFYUI_GPU:-3} (ComfyUI then sees the card as device 0), documenting the variable in .env.example.
Adversarial verification — both skeptics confirmed
Skeptic 1 (confirmed) — Verified against the code, git history, and the live host. Dockerfile line 63 does bake --default-device 3 into the CMD; compose.yaml gives text-to-image NVIDIA_VISIBLE_DEVICES=all with no CUDA pin, while all other GPU services (chatterbox, face-recognition, vllm-vision, embeddings) pin via env vars; no doc or config file mentions the…
Skeptic 2 (confirmed) — Verified in full. services/text-to-image/Dockerfile:63 hard-codes --default-device 3 in the CMD; the compose block (compose.yaml:250-287) has no command override, no CUDA_VISIBLE_DEVICES pin, and sets NVIDIA_VISIBLE_DEVICES=all with count:all reservations, so the container sees all 5 GPUs and ComfyUI targets host GPU 3. Every other GPU…
Filed from a multi-agent audit of 855f5cc: 16 reviewers over ~42k lines produced 170 raw findings; each was handed to 2 independent agents prompted to refute it, and only findings both confirmed were kept (19 refuted, 10 split-verdict, 127 unique confirmed). Line numbers are 1-indexed against 855f5cc and will drift as the code changes.
Severity: Low · Area: Infra + config · Category:
improvementLocation:
services/text-to-image/Dockerfile:63What's wrong
Every other GPU service pins its device via a compose env var (CHATTERBOX_GPU, CUDA_VISIBLE_DEVICES=3 for face-recognition, =4 for vllm-vision), but text-to-image hard-codes
--default-device 3in the Dockerfile CMD while compose sets NVIDIA_VISIBLE_DEVICES=all. Changing the GPU requires editing the Dockerfile and rebuilding, and the choice is invisible from compose.yaml. GPU 3 is also one of vLLM's tensor-parallel shards (gpu-memory-utilization 0.79) and hosts face-recognition, so ComfyUI model loads land on the most contended card.How it fails
An image-generation request loads an SDXL/Flux checkpoint (7-12 GB) onto GPU 3, which already holds ~19 GB of vLLM KV/weights plus InsightFace; CUDA OOM either kills the ComfyUI generation or destabilizes the vLLM shard mid-chat-turn, and the operator finds no GPU assignment for text-to-image anywhere in compose.yaml or .env when debugging.
Suggested fix
Drop
--default-device 3from the Dockerfile CMD and pin via compose like the other services:environment: - CUDA_VISIBLE_DEVICES=${COMFYUI_GPU:-3}(ComfyUI then sees the card as device 0), documenting the variable in .env.example.Adversarial verification — both skeptics confirmed
Filed from a multi-agent audit of
855f5cc: 16 reviewers over ~42k lines produced 170 raw findings; each was handed to 2 independent agents prompted to refute it, and only findings both confirmed were kept (19 refuted, 10 split-verdict, 127 unique confirmed). Line numbers are 1-indexed against855f5ccand will drift as the code changes.