One Person, One DGX Spark: The AI Experiments I Got Working (Checklist + Numbers)

Let me start with the inventory: one person, one DGX Spark (128GB unified memory), no cloud GPUs rented. I recently got five AI experiment tracks working — video generation, speech and knowledge base, music, websites, and quant. For each track I'll cover only three things: what I did, the key numbers, and the lesson.

Track	Flagship	Key numbers
Video generation	Sol-H3 pipeline	237.3 s for a 5-second clip
Speech	SenseVoiceSmall	RTF≈0.05 on pure CPU
Music	YuE2	5 songs batched in 12 minutes
Websites	craft.cosmocat.dev	3 minutes from decision to live
Quant	Stock assistant	5225 stocks updated daily

Track 1: Video generation — 5-second clip in 237 s, 60-second clip in 14 minutes

The model is MiniMax H3 (video and native audio generated in one pass), running on local ComfyUI; acceleration comes from the Sol-H3 pipeline NVIDIA built for DGX Spark.

• Single 5-second clip (1344×768, with audio): 237.3 s end to end (85.2 s in the draft stage, 130.3 s in the refinement stage)
• Pre-quantized weight caching cut draft-stage model loading from minutes to 10~17 s
• Pipeline memory dropped from 116.9G to 50~55G — by making three resident processes serial, holding only one stage in memory at a time
• A 60-second final cut = 12 five-second segments stitched together; reusing text encoding, the batch renders in 826.5 s (about 13.8 minutes)

Spin-off workflow: Blender white-model previz → H3 reference-to-video, reaching zero artifacts by the 17th version (full pipeline in this other post).

Lesson: the bottleneck in batch inference isn't VRAM, it's the compiler. 12 prompts of varying length (151~186 tokens) tripped the recompilation limit (default 16), and the 4th one failed hard; raising it to 128 made all of them pass.

Track 2: Speech and knowledge base — pure-CPU transcription, RTF 0.05

The intake for the knowledge base is ASR: video and audio have to become text before they can be filed (the base is already 5000+ pages).

• FunASR SenseVoiceSmall, pure-CPU transcription: 34 min 26 s of audio done in 115 s (RTF≈0.05); 8.6 hours of audio in about 12 minutes with 4 parallel processes
• Why I stick to CPU: on a unified-memory machine, starting GPU inference under memory pressure triggers allocation failure, which cascades into a full machine freeze — this has happened several times

Lesson: long audio must be chunked — a single 600-second segment produced only 1375 characters, while 30-second chunks produced 4071. Capping each segment at 30 seconds (VAD max_single_segment_time=30000) restored normal output. Don't be greedy with parallelism either: 8 parallel processes blew out memory, so the ceiling is 3~4.

Track 3: Music — two tracks released, 5-song batch in 12 minutes

Songs are generated by the local open-source model YuE2; two originals are already live on Qishui Music (ByteDance), with AI disclosure filled in honestly.

• About 120 seconds to generate one song
• Batch test: 5 songs in different styles (Chinese traditional / nostalgic / healing / children's / pop), unattended, all rendered in 12 minutes — 5/5 succeeded, zero truncation
• The pipeline is fully scripted: generate → truncation self-check → fade-out → mastering → ASR quality check

Honest numbers: 4 plays and ¥0.00 revenue on Qishui; 41 plays and a 71.9% two-second bounce rate on the Douyin MV. Still in the validation phase, no glossing over. The full log and 5 pitfalls are in this post.

Lesson: max_duration is a ceiling, not a target. The first two songs happened to die right at the limit (90.0 and 100.0 seconds) and were hard-cut; after loosening it, the same seeds ended naturally at 164 and 137 seconds.

Track 4: Websites — 3 minutes from decision to live

The first tool site went live: craft.cosmocat.dev, a Chinese-language directory for the Craft app series (13 apps plus Launcher, 6 filter categories, with search).

• 3 minutes from decision to live — the template library (zero dependencies, SEO-ready) and deploy pipeline were built in advance
• Domain strategy: the main domain hosts the blog, tool sites run on subdomains first, and get their own domain once there's a signal

Lesson: when Cloudflare Pages has no 404 page, unknown paths fall back to the homepage and return 200 — so robots.txt and sitemap.xml may be HTML fake-200s. Adding 404.html fixed it.

Track 5: Quant — a 5225-stock data lake plus three daily shifts

This track is me building my own trading operating system: research, signals, execution, and review all turned into rules; the machine handles only discipline and arithmetic — no order placement, no stock picks.

• Data lake: 5225 stocks of daily bars (38 minutes for the first load, 4~6 minutes for daily increments) + 8 indices + 25 ETFs of daily bars
• Three daily shifts: a battle plan at 8:40 pre-market, a risk radar every 10 minutes during the session (alerts only when triggered), and a review at 15:30 post-market
• Research discipline: run a "minimal test" before engineering anything — chasing momentum showed a monthly spread of -1.43% in A-shares (t=-2.93), falsified in a single afternoon

Lesson: free quote feeds return a 0 value pre-market — on launch day the radar falsely reported a "-100% unrealized loss", and the same day it crashed because total market cap was 0. The fix: validate price > 0 before computing, and run the radar only during trading hours.

(The above is only a record of system building and does not constitute any investment advice.)

The Takeaway Checklist

1. Serialize large-memory tasks — peak dropped from 116.9G to the 50G range, through queuing rather than optimization
2. Check three limits before batching — compilation cache, prompt length variance, parallelism
3. Leave headroom in generative tasks — don't write the ceiling right at the target, and self-check for truncation after rendering
4. Chunk long audio — ≤30 seconds per segment, ≤4 in parallel
5. Guard free data sources — compute only when price > 0, and run tasks only in the hours they should run
6. Minimal test first, then engineering — falsifying a direction in an afternoon beats writing code and then reworking it

The most valuable thing across all five tracks isn't any model, it's reproducibility: the numbers have logs, the pitfalls have fixes, and next time I can just copy the homework.