Case study — 2026
A.R.G.U.S-V
a video intelligence system that answers questions about videos while they're still processing
- Python
- LangGraph
- vLLM
- Whisper/Canary ASR
- Qwen3-VL
- LanceDB
- Redis
- FastAPI
- DGX H200
built on a shared DGX H200 · 2026
01 — The problem
Watching hours to find one answer doesn't scale.
The goal: paste a YouTube URL, ask questions in natural language, and get grounded answers — without waiting for the whole video to finish processing.
02 — The system
One pipeline, eight GPUs, no idle time.
A single video fans out into parallel download, transcription, and vision pipelines that converge into a queryable vector store — queried by an agent that routes each question to the right model.
- 01
Video URLPasted by the user
- 02yt-dlp
Parallel byte-range downloadFetched in concurrent chunks
- 03
Chunked audioSplit for streaming ingestion
runs in parallel
04:19002ASR microserviceCanary-1B-Flash primary, faster-whisper fallback
- 05keyframes
Scene detection + frame extractionKeyframes for the visual track
- 06:19003
Qwen3-VL embeddingsVision microservice
- 07LanceDB
LanceDB vector store13k+ rows
- 08dual-LLM
LangGraph VideoQAAgentDual-LLM routing — reasoning model + speed model
- 09
AnswerGrounded in retrieved chunks
$ note — A Redis task queue coordinates persistent workers across all 8 GPUs — no per-request process spin-up.
03 — What made it fast
The thesis.
“ASR was never the bottleneck. Pipeline design was.”
13–20s
to first query, from ~2–3 min
~30×
real-time processing, sustained
−28s
per query, LLM critique → rules
Streaming ingestion
The first audio chunk starts processing within seconds, so querying unlocks long before the video has finished.
Parallelism everywhere
Scatter-gather chunking runs against hot, persistent model workers — no per-request cold starts, no idle GPUs.
Cheaper judgment
A rule-based evaluator replaced an LLM critique loop, at no measurable cost to answer quality.
04 — Hard-won lessons
What broke, and what fixed it.
− GPU OOM kills
+ Split ASR and vision into separate FastAPI services, each with its own GPU memory budget.
− Frame I/O bottleneck
+ Extract frames to a RAM disk (/dev/shm) instead of spinning disk.
− Slow queue reads
+ Batch database writes through a sink worker — 128 rows or a 2s flush, whichever comes first.
− Model cold starts
+ Persistent, pre-loaded model workers instead of loading a model per task.
Want the details?