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.
Verified 2026-08-07 against spikersoft-artpipe@7082d26: the spike's deliverable (a comment with the matrix) was never posted — this issue had zero comments. The measurement work is genuinely still outstanding, but the premise has shifted and the migrated issue records that: 23 model dirs are now vendored with vram_mb manifests, TRELLIS is answered for Apple Silicon only (models/TrellisMac, src/artpipe/models/trellis_mac.py), keep-warm is partly settled in production (SafetyCheck runs RESIDENT with a long-lived 1024 MB lease; the modeling models run MODEL-QUEUE), and live the GPU coordinator reports 32768 MB total VRAM across 2 enabled node(s) — so the "single 24 GB host" framing is obsolete and the matrix should be produced per lane.
Status: not started.
Closing here. Work now lives in the repo that holds the fix, so fixes #51 in a PR will auto-close it on merge. The umbrella tracker keeps cross-repo epics only.
— Opus 5 Agent
Migrated to **spikerj/spikersoft-artpipe#51** as part of the umbrella-tracker breakup.
Verified 2026-08-07 against `spikersoft-artpipe@7082d26`: the spike's deliverable (a comment with the matrix) was never posted — this issue had zero comments. The measurement work is genuinely still outstanding, but the premise has shifted and the migrated issue records that: 23 model dirs are now vendored with `vram_mb` manifests, TRELLIS is answered for Apple Silicon only (`models/TrellisMac`, `src/artpipe/models/trellis_mac.py`), keep-warm is partly settled in production (SafetyCheck runs RESIDENT with a long-lived 1024 MB lease; the modeling models run MODEL-QUEUE), and live the GPU coordinator reports `32768 MB total VRAM across 2 enabled node(s)` — so the "single 24 GB host" framing is obsolete and the matrix should be produced per lane.
Status: not started.
Closing here. Work now lives in the repo that holds the fix, so `fixes #51` in a PR will auto-close it on merge. The umbrella tracker keeps cross-repo epics only.
— Opus 5 Agent
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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):
vram_mbinart_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-Motionmodels/trellis.pyis 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?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.
Migrated to spikerj/spikersoft-artpipe#51 as part of the umbrella-tracker breakup.
Verified 2026-08-07 against
spikersoft-artpipe@7082d26: the spike's deliverable (a comment with the matrix) was never posted — this issue had zero comments. The measurement work is genuinely still outstanding, but the premise has shifted and the migrated issue records that: 23 model dirs are now vendored withvram_mbmanifests, TRELLIS is answered for Apple Silicon only (models/TrellisMac,src/artpipe/models/trellis_mac.py), keep-warm is partly settled in production (SafetyCheck runs RESIDENT with a long-lived 1024 MB lease; the modeling models run MODEL-QUEUE), and live the GPU coordinator reports32768 MB total VRAM across 2 enabled node(s)— so the "single 24 GB host" framing is obsolete and the matrix should be produced per lane.Status: not started.
Closing here. Work now lives in the repo that holds the fix, so
fixes #51in a PR will auto-close it on merge. The umbrella tracker keeps cross-repo epics only.— Opus 5 Agent