AFCUT Research · ProduceHits · 2026-08-08

Segment stem vs full-track GPU run

If a producer only wants the drums from an 8-bar loop inside a 4-minute song, should we crop and stem just that segment — or always run the full track? This report models real Modal T4 money, credit impact, engineering cost, and whether the feature is worth building.

Question loop-only GPU stems Sources Modal pricing · internal credit docs · Demucs scaling · job_queue (30d) Status recommendation ready

Executive verdict

Short answer first. Detail and math below.

Primary finding

Not worth building as a cost-savings project

Absolute GPU savings are real but tiny: roughly $0.003–$0.005 saved per job when a user stems a 16s loop instead of a 3.5-minute track (warm container). At 1,000 stem jobs/month with 40% convertible to loop-only, you save about $1.80/month in Modal spend. That does not pay for engineering time.

The credits doc’s ~$0.05/track figure is a conservative budget line; measured/modeled warm T4 Demucs for a typical track is closer to ~$0.006–$0.02 depending on model (htdemucs vs htdemucs_ft / Standard+ dual pass) and cold start.

When it is worth it

Worth it as a product / conversion feature

Users currently face a 50-credit wall (~$0.24 face value on Producer) to stem a whole song when they may only need one loop. A “stem this selection” path at ~10–20 credits can convert free-tier / hesitant users and feels premium.

Bigger win already exists: full-track stem once → has_stems=true cache forever (0 credits re-run). Protect and market that harder before inventing partial-stem plumbing.

Full track warm GPU
~$0.006
~34s T4 · 3.5 min audio · htdemucs-class
16s loop warm GPU
~$0.001
~7s T4 · fixed overhead still bites
True $ savings / job
~$0.004
Not 16/210 of full cost (~7.6%)
User credit leverage
50 → ~12
If you pass savings to users
Rule of thumb: segment stemming saves compute pennies and credit dollars of user-facing value. Build it only if you want a cheaper entry SKU for “just this loop” — not to cut the Modal bill.

Cost model — how the math works

Demucs is roughly linear in audio length after fixed costs (container, model weights in VRAM, encode/decode). Short loops never get a proportional discount.

Inputs (2026-08)

Modal T4

  • $0.000164 / GPU-second (~$0.59/hr)
  • Pay-per-second, no hourly lock-in
  • Cold start can add ~15–40s wall time (image + model load)
  • Warm reuse keeps fixed cost ~5s overhead

Source: modal.com/pricing

ProduceHits internals

  • 4-stem credit charge: 50 base / 0 cached
  • Budget line in credits doc: ~$0.05 Modal (conservative)
  • BUSINESS_MODEL: ~$0.015–0.02 track (Demucs+Whisper ~30s)
  • Code note (Standard+): ~25s Demucs + ~20s MelBand on T4
  • Producer face value: $12 / 2,500 cr = $0.0048/cr
GPU_seconds ≈ FIXED_overhead + (ratio × audio_seconds)
GPU_$ = GPU_seconds × $0.000164

# Calibrated to ~25–35s warm Demucs-class run on a ~3–3.5 min track
FIXED_warm ≈ 5s · FIXED_cold ≈ 25s · ratio ≈ 0.14 GPU-s per audio-s

Segment length vs GPU cost (warm container)

Scenario Audio GPU time Modal $ vs full track $ saved Naïve % expect
8-bar loop @ 120 BPM 16s 7.2s $0.0012 −79% $0.0044 −92%
16-bar loop @ 120 BPM 32s 9.5s $0.0016 −72% $0.0041 −85%
1-minute segment 60s 13.4s $0.0022 −61% $0.0034 −71%
2-minute segment 120s 21.8s $0.0036 −37% $0.0021 −43%
Full track (baseline) 210s 34.4s $0.0056 — — —
5-minute track 300s 47.0s $0.0077 +37% −$0.0021 +43%
8-minute mix / live cut 480s 72.2s $0.0118 +110% −$0.0062 +129%
Fixed overhead kills proportional dreams. A 16s loop is ~7.6% of a 210s song’s length, but only saves ~79% of warm GPU time — not 92% — because model load / setup still runs. On a cold Modal container the gap narrows further (loop ~$0.0045 vs full ~$0.0089).

Monthly Modal savings at scale

Assume 40% of stem jobs could become loop-only (optimistic), warm containers, $0.0044 saved each:

50 stem jobs / mo
$0.09
200 stem jobs / mo
$0.36
1,000 stem jobs / mo
$1.78
5,000 stem jobs / mo
$8.91
50,000 stem jobs / mo
$89

Even at “we made it” volume, this is a rounding error next to Hetzner base (~€42/mo at rest) or a single day of founder engineering time.

What the last 30 days of job_queue actually shows

CPU fleet economics (cx33 @ €0.025/hr): full_pack avg ~82s wall (~€0.00057 CPU). No high-volume dedicated stem job_type rows in the last 90 days under stem-named types — GPU work is Modal-side and often nested inside pack pipelines. Implication: we are not currently burning a large stem bill that segment mode would rescue. Cache discipline and avoiding duplicate full stems matter more.

Live calculator

Drag the sliders. Defaults match the model above (warm T4, ratio 0.14, $0.000164/s).

210s (3:30)
16s
2.0s (quality pad)
Warm container

Full-track stem

$0.0056
34.4s GPU

Segment stem (w/ pad)

$0.0015
9.1s GPU · audio sent 20s

You save

$0.0042
−74% Modal $ · credit hint below

Suggested credit price

Floor + proportional blend so short jobs still cover fixed cost:

credits = max(10, round(50 × GPU_seg / GPU_full)) → 12 cr

User $ face value (Producer)

Full 50 cr ≈ $0.24 · Segment 12 cr ≈ $0.06 · User “saves” $0.18 of allowance.

Face value is not our cost — it is how much of their monthly grant they burn.

Credit pricing implications

Today the product is value-priced, not cost-priced. Segment mode should stay that way.

Current

Full 4-stem

  • 50 credits base · 0 if has_stems already true
  • Our cost ~$0.006–$0.02 · face $0.24 → ~92–97% margin on face
  • Still the right default for pack building, remix prep, multi-loop kits
Proposed SKU

Segment stem (loop selection)

  • 12–20 credits suggested band (not free, not 50)
  • Does not set full-song has_stems=true
  • Caches under a region key: audio_hash + start_ms + end_ms + model
  • Upgrade CTA: “Stem entire track for 30 more credits” (total 50 parity)
Pricing psychology > GPU math. A producer who only wants one drum loop will feel robbed at 50 credits and delighted at 15. Your cost difference is a few tenths of a cent. The conversion difference can be a paid user.

Recommended credit table row (if you ship it)

Action key Base Cached (same region) Notes
stems_4_segment 15 0 Max selection 60s audio + 2s pad/side; longer → redirect to full
stems_4 (existing) 50 0 Unchanged. Segment users can top-up to full for +35
stems_segment_to_full_upgrade 35 0 Optional: credit the 15 already paid toward full 50

Quality, cache, and product traps

The hidden costs are not Modal seconds — they are architecture and quality edge cases.

Traps
  • Edge bleed: Demucs on a hard crop can smear transients at the cut. Always pad 1–4s and trim after.
  • Cache pollution: Partial stems must never mark full-track has_stems. That would break later full-pack / remix paths.
  • Double pay anger: User stems a loop, then wants the chorus — without an upgrade path they feel charged twice.
  • Storage sprawl: Many micro-stem regions per song if not deduped by quantized region keys.
  • Model context: Very short clips (<4–8s) separate worse; enforce a minimum selection.
Mitigations
  • Crop with pad → stem → trim pad → export only the selection.
  • Region cache key quantized to e.g. 100ms grid + model name + stem layout.
  • UI: “Stem selection (15)” vs “Stem full track (50)” side by side with ETA.
  • If full stems already cached, selection stem is free: just slice the OGGs.
  • Cap selection (e.g. ≤60s) so the cheap SKU can’t be abused for whole songs.
Important free win already available: if full stems exist, “export this loop’s drums” is a CPU crop of cached stems — zero Modal, should cost 0–1 credit (export packaging only). That path is higher ROI than inventing segment GPU jobs.

How long would it take to build?

Rough founder/agent calendar time against the current queue + Modal architecture.

Phase Work Estimate
MVP backend Job type stems_4_segment, crop+pad, Modal call, region assets, credits key, no full-cache flag 1–2 days
Studio UX Waveform region select, cost preview, progress, result pads for selection only 1–2 days
Cache + upgrade path Region dedupe, “upgrade to full track stems”, free slice when full stems exist 1 day
Polish + verify Edge-quality pad tuning, mobile selection, e2e, credit ledger checks 1 day
Total Shippable production feature ~4–6 days

Opportunity cost: 4–6 days of focus is worth far more than ~$2–$20/month of Modal savings at current and near-term volume. Only spend it if the conversion / “I only need this loop” story is a priority product bet.

Recommendation

Decision framework for ProduceHits / AFCUT.

Do this instead of (or before) segment GPU stems

  1. Default to full-track stems once, cache forever. Re-runs already cost 0 credits. This is the real economic engine.
  2. If full stems exist → free/cheap region export. Slice drums/bass/vocals for the selected loop on CPU. No Modal.
  3. Market the cache discount loudly. “Stems ready — this pack is cheaper” converts better than a second job type.
  4. For long audio (DJ mixes, podcasts, 8+ min): segment mode becomes more compelling because variable cost finally dominates fixed overhead.
Ship segment stems if…
  • You see users abandon at the 50-credit stem gate for single-loop goals
  • You want a clear free→paid ladder: detect loop free → stem loop 15 → full pack 50+
  • You process lots of long-form (>5 min) where proportional savings grow
Skip / defer if…
  • Primary goal is “cut the Modal bill” (math doesn’t support it)
  • Pack/kit workflows almost always need multi-section stems anyway
  • Engineering focus is better spent on queue wait, cache hits, or SCNet speed

Bottom line

Always running the full track is fine — and usually smarter — at current scale. The expensive part of stems is not “3.5 minutes of audio”; it is spinning GPU quality models at all, plus product complexity. A drum loop repeating for four minutes does not mean the model can skip work for free without a crop; but cropping only saves pennies unless volume is huge or tracks are very long.

If you want a user-facing “stem just this loop” control, price it as a conversion SKU (~15 credits), implement pad-and-trim quality carefully, never mark full-track cache from partial results, and treat Modal savings as a nice side effect — not the business case.

Appendix — assumptions & sources

This is an economics decision report, not a commit to build. Numbers should be re-measured with one real Modal A/B (16s crop vs full 210s) before locking credit prices — run cost-guard after the first 20 production segment jobs.