The qualified Ariadne Mark 0.7.2a1 image/video workflow runs on Linux x86-64 CPU with Python 3.12. You can evaluate it on an ordinary backend worker; a GPU is not required for the tested workflow. Provision the runtime and models first through the release quickstart.
What hardware was actually tested?
The current complete-SDK measurements used an AWS EC2 m6a.large with two vCPUs and 8 GiB host RAM. Each benchmark container was limited to two CPUs and 4 GiB memory. Those are test conditions, not a minimum specification or a guarantee of capacity for any input.
Check image dimensions, video duration/FPS/codec, concurrency and service overhead for your own workload. The measurement page reports session cgroup memory peaks, which differ from process RSS and total host-RAM requirements. The smaller hosted image playground is a separate application and does not establish memory requirements for your full deployment kit.
Keep models resident between jobs
- Install the pinned runtime and models during setup.
- Start a bounded worker process and construct its SDK after startup.
- Reuse that SDK for jobs instead of rebuilding the models on each request.
- Close it during shutdown. Create a new SDK inside each process after a fork; do not inherit a live model or video worker across the fork.
The Python example provides a reusable export function. A Node.js or Next.js application can keep its existing queue and delegate work to that Python worker. Calling the CLI for each file is a simple boundary, but can pay a new-process startup cost.
Choose threads, workers and video profiles separately
The documented image example uses two image threads. Control product-level concurrency through your queue rather than assuming that more threads always produce proportionate throughput. Separate processes load their own models; budget additional memory before adding workers.
Economy5s and Economy2s reduce selected-frame inference. Resilient computes a fresh signal on every frame. All profiles still decode and encode the full video, so sparse marking does not remove the media-processing cost. Use the profile guide with the measured timings and cost calculation.
What should happen if a worker crashes?
Publish the returned final file only after a successful export. Keep receipts and the registry on persistent storage. Use unique output paths and your own job idempotency rules; the SDK will not overwrite an existing output.
An export failure should remain a failed job. Do not make unmarked input the automatic publication fallback. Reconcile job state and staging files before retrying, including cases where a batch completed earlier jobs before a later failure. The stock-product example illustrates queue and retry boundaries.
Deploy SDK + verifier + registry · Supported formats and platforms · Runtime troubleshooting