4c63a46d2480bc2f6aa772079ec63a2d7238a0cb
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 dev
|
4c63a46d24 |
fix(photo-ai): лестница OOM на CUDA + приёмка face-режима и GPU-оверрайда
Stage 3 закрыт. Face-режим (off/face/all, strength, warnings) был написан в Stage 1;
здесь доведена приёмка и найден баг, который невозможно было увидеть без GPU-прогона.
Главное: realesные OOM никогда не доходили до run_guarded. И realessrgan/utils.py, и
gfpgan/utils.py ловят RuntimeError вокруг вызова сети и идут дальше
(`except RuntimeError as error: print('Error', error)`), поэтому на нехватку памяти
realesrgan падал уже не RuntimeError, а UnboundLocalError на присваивании
output_tile. Наружу уходил голый 500 «Internal Server Error»: ни лестницы тайлов,
ни деградации на CPU, ни внятного текста. В gfpgan это было тихое ухудшение —
при OOM лицо молча оставалось исходным, а задание уходило в «успех».
Починка: guard_forward() оборачивает forward сетей, которые строим мы
(RealESRGANer.model, restorer.gfpgan, CodeFormer net) и превращает OOM-RuntimeError
в TileOOM. TileOOM не наследует RuntimeError, поэтому проглатывающие except его
пропускают; is_oom и обе точки run_guarded ловят его явно. Обёртка вешается на
экземпляр, идемпотентна по флагу _photo_ai_guarded и не трогает класс.
Также добавлены два предупреждения из чек-листа, которых в коде не было: вход меньше
320×320 (лица могут не найтись) и CodeFormer на не-CUDA. Предупреждение «лица не
найдены» и деградация на CPU были на месте и не менялись.
Проверено на RTX 3050 Laptop (4096 МБ, драйвер 615.71.09, CUDA 12.6):
- tile=2048, x2plus face=all, полное фото: до правки 500 + UnboundLocalError,
после 200 за 28.3 с с единственным warning «не хватило памяти при tile=2048»;
- инъекция OOM: лестница 2048 → 1024 → 512, затем переход на CPU (device: cpu,
half: false) и успешный повтор; при повторе уже на CPU — честная 500 с подсказкой
про PHOTO_AI_TILE / PHOTO_AI_MAX_PIXELS;
- 640×480: off 1.0 с / face 3.8 с / all 2.2 с, faces_found=6; фото без лиц даёт
faces_found=0 и байты, равные face=off;
- I1: 6/6 MATCH байт-в-байт против Stage 2 на CPU (jpg/.jpeg/png+70/webp+100/x4v3/anime).
docker-compose.gpu.yml: GPU выдаётся через CDI (device_ids nvidia.com/gpu=all) —
не требует правки /etc/docker/daemon.json и перезапуска демона, в отличие от
классического резервирования driver: nvidia. TORCH_VARIANT cu124 → cu126: в индексе
cu124 последний torch 2.6.0, а cu126 даёт те же 2.14.0/0.29.0, что и CPU-образ, так
что варианты сборки отличаются только CUDA-библиотеками. Образ тегируется отдельно
(whatido-photo-ai:cu126), чтобы сборка GPU-варианта не перетирала CPU-образ
whatido-photo-ai:latest — откат остаётся обычным docker compose up -d photo-ai.
README: раздел «Запуск на NVIDIA GPU» с установкой NVIDIA Container Toolkit и генерацией
CDI-спеки, оговорками про 4 ГБ VRAM (x2plus + gfpgan влезают, general-x4v3 тяжелее,
LOAD_ALL=1 лучше не включать) и описанием параметров /enhance. .env.example: команда
GPU-запуска и рекомендация по PHOTO_AI_TILE. Журналы раздела 3 и GPU-прогона — в
TODO_PHOTO_FACE_AI.md.
worker.js, server.js, схема БД и фронтенд не тронуты — они в Stage 4…6.
|
||
|
dev
|
7367d66ac3 |
build(photo-ai): CPU/GPU сборка, gfpgan+facexlib без dev-зависимостей, healthcheck
Stage 2: photo-ai/Dockerfile получил ARG TORCH_VARIANT/TORCH_INDEX (один образ, cu124 — вариант сборки) и явные пины gfpgan==1.3.8 / facexlib==0.3.0 через --no-deps: tb-nightly и yapf (dev-зависимости gfpgan/basicsr) больше не попадают в рантайм, matplotlib остаётся как зависимость filterpy (требование facexlib). Патч basicsr/data/degradations.py сохранён байт-в-байт — без него basicsr падает на torch >= 2.0. Пин numpy<2 был невыполним: opencv-python-headless 5.0.0.93 требует numpy >= 2. Зафиксирована фактическая версия numpy==2.2.6 в общем вызове pip install, а opencv-python (не-headless) больше не ставится — раньше он приходил через gfpgan и перезаписывал headless-сборку (активным был cv2 с GUI: QT5). I1 после этого перепроверен: 5/5 MATCH байт-в-байт против эталона Stage 0. ENV PHOTO_AI_MODELS_DIR=/models, MODEL_PATH остаётся валидным алиасом. COPY vendor/ ./vendor/ + vendor/.gitkeep — вендоренный CodeFormer (D5) подхватится из sys.path без правок Dockerfile. docker-compose.yml: у photo-ai новые env (DEVICE, TILE, FACE_MODEL, LOAD_ALL, JPEG_QUALITY, MODELS_DIR) и healthcheck со start_period 300s; MAX_INPUT_PIXELS заменён на канонический PHOTO_AI_MAX_PIXELS (старое имя читается app.py как алиас). У app — PHOTO_AI_FACE_MODEL и PHOTO_AI_FACE_TIMEOUT_MS (воркер читает их в Stage 4). Новый docker-compose.gpu.yml (по образцу minio): TORCH_VARIANT=cu124, PHOTO_AI_DEVICE=cuda, deploy.resources.reservations.devices для nvidia. .env.example и таблица переменных README описывают ровно те переменные, которые теперь подставляет compose; блок про GPU и NVIDIA Container Toolkit — Stage 6 (D6). Проверено на живом стеке: сборка EXIT=0 (2.63 ГБ), /health отдаёт device=cpu, face_models=[gfpgan], контейнер healthy, /api/photo-jobs/status отдаёт service.device, I3 (пустой PHOTO_AI_URL -> 503 + 8 маршрутов 200), I4 (PHOTO_AI_DEVICE=cuda без CUDA -> WARN + CPU), docker compose config валиден для базы, minio и gpu. GPU-пуск не выполнялся: nvidia-ctk на хосте отсутствует. |