[ArtStudio Spike] Model × VRAM fit matrix on the 24 GB host — which ProArt backends we enable per stage #354

Open
opened 2026-07-04 05:12:17 +00:00 by spikerj · 0 comments
Owner

Spike for epic #346. Should run before/alongside #348 — its outcome picks the default model per stage.

Question: which of art_pipe's per-stage backends actually fit our single 24 GB card at acceptable latency and quality for students, and what's the keep-warm vs load-per-job strategy?

Investigate (time-boxed, on the GPU host):

  • Per candidate backend, record: VRAM peak (vs manifest vram_mb in art_pipe/models/*/artpipe.json), cold-start (venv + weight load), warm run time, output quality on 3 student-realistic prompts. Candidates — modeling: TRELLIS, Hunyuan3D-2, SF3D, TripoSR, TripoSG, InstantMesh, Shap-E; concept: SDXL-Lightning, SD-Turbo, FLUX.schnell; texturing: Hunyuan3DPaint, SD-Turbo-tex; animation: MDM, HY-Motion
  • TRELLIS reality check: art_pipe's models/trellis.py is stubbed "until CUDA exts build" — what does it take to build the CUDA extensions in our worker image, or do we standardize on Hunyuan3D-2/TripoSR for launch?
  • Keep-warm strategy: which (if any) model stays resident vs load-per-job, given other GPU tenants (Embeddings, QuizGeneration, Ocr, LessonVideoProcessor) share the card through GpuCoordinator leases; does art_pipe's Blender daemon pool earn its residency?
  • Weight storage: total HF cache size for the chosen set; volume layout on SERVER
  • Expected student wait time end-to-end (concept→export) per asset type with the chosen defaults — feeds the quota numbers in #352 and the UX expectations in #351

Deliverable: a comment on this issue with the matrix + a recommended default and fallback model per stage, keep-warm policy, and disk budget. Update #348/#349/#350 model choices accordingly.

Spike for epic #346. **Should run before/alongside #348** — its outcome picks the default model per stage. **Question:** which of art_pipe's per-stage backends actually fit our single 24 GB card at acceptable latency and quality for students, and what's the keep-warm vs load-per-job strategy? **Investigate (time-boxed, on the GPU host):** - [ ] Per candidate backend, record: VRAM peak (vs manifest `vram_mb` in `art_pipe/models/*/artpipe.json`), cold-start (venv + weight load), warm run time, output quality on 3 student-realistic prompts. Candidates — modeling: TRELLIS, Hunyuan3D-2, SF3D, TripoSR, TripoSG, InstantMesh, Shap-E; concept: SDXL-Lightning, SD-Turbo, FLUX.schnell; texturing: Hunyuan3DPaint, SD-Turbo-tex; animation: MDM, HY-Motion - [ ] TRELLIS reality check: art_pipe's `models/trellis.py` is stubbed "until CUDA exts build" — what does it take to build the CUDA extensions in our worker image, or do we standardize on Hunyuan3D-2/TripoSR for launch? - [ ] Keep-warm strategy: which (if any) model stays resident vs load-per-job, given other GPU tenants (Embeddings, QuizGeneration, Ocr, LessonVideoProcessor) share the card through GpuCoordinator leases; does art_pipe's Blender daemon pool earn its residency? - [ ] Weight storage: total HF cache size for the chosen set; volume layout on SERVER - [ ] Expected student wait time end-to-end (concept→export) per asset type with the chosen defaults — feeds the quota numbers in #352 and the UX expectations in #351 **Deliverable:** a comment on this issue with the matrix + a recommended default and fallback model per stage, keep-warm policy, and disk budget. Update #348/#349/#350 model choices accordingly.
spikerj added the questionenhancement labels 2026-07-04 05:12:17 +00:00
Sign in to join this conversation.