AI Film Studio Backend Setup

@denisSolution

Hi Denis, I'm Denis, a full-stack and ML infrastructure engineer with experience building production GPU inference pipelines for large diffusion models. For Wan2.2 A14B, I recommend CoreWeave’s A100 80GB nodes. Their dedicated GPU partitioning and per-second billing align well with bursty video workloads, cutting idle costs while ensuring strong performance. I’d skip H100 here—the A14B isn’t memory-bound enough for the premium, and the A100’s larger memory simplifies batching. The worker stays disposable: the model stays warm only during active jobs, loaded once at startup from CoreWeave’s NVMe storage into a persistent volume. Job state, source images, and completed segments live in a PostgreSQL cluster with WAL replication. If a GPU fails after processing 7/24 segments, a shutdown hook persists the latest state. A replacement worker picks up from the checkpoint, skips done segments, and resumes with the remaining 17. I’d structure the first milestone in two phases: Day 1 for end-to-end flow (FastAPI → queue → GPU worker → FFmpeg → storage → playback), and Day 2 for hardening (recovery tests, monitoring, scaling). The fixed-price estimate is $4,800 for the first week, covering CoreWeave costs, Docker setup, and API integration. I’ve deployed similar pipelines for Stable Diffusion XL and SDXL-based video systems handling thousands of daily jobs, so the approach is proven at scale. I can start immediately—let’s connect to discuss details. Thanks, Denis

@shadabkhan92

ROLLCALL-V2: As an experienced GPU/ML infrastructure engineer, I would be the perfect fit for your Wan2.2 A14B backend setup in ROLLCALL. I have a proven track record in building clean, performant production systems that deliver tangible results even under challenging conditions. I am a skilled user of the specific tools you require (Python/PyTorch/CUDA, FastAPI) and well-versed in leveraging AWS and other GPU providers for large workloads - an expertise that will ensure optimal utilization of the NVIDIA A100/H100 GPUs. I am able to design and deploy reproducible Docker-based solutions, pinned with compatible dependencies, and ensure minimal disruption through automatic restart/recovery mechanisms. Perhaps the compelling reason for considering me for this project is my experience in not only selecting and setting up robust GPU environments but also integrating complex systems into existing workflows. Having previously delivered AI solutions that successfully interface with hardware, act on live sensor data and communicate with external systems, this project's requirement for complete integration with the ROLLCALL website aligns perfectly with my strengths. Let me build you a dependable and efficient backend that stands up to the toughest challenges, just as effective on day 100 as it is on day 1!

@Shrutibimpl

ROLLCALL-V2: Hello, I can architect your disposable GPU worker pipeline for Wan2.2 I2V A14B. To keep workers disposable while keeping models warm my plan is to decouple state entirely from the compute node. Models live in S3 or RunPod Network Volumes cached to local NVMe. Queue state and segment metadata live in an external PostgreSQL and Redis database. Source images and intermediate segment MP4s are uploaded immediately to S3. If a GPU dies after segment 7 of 24 the replacement worker boots reads the job state in PostgreSQL sees 7 completed S3 segments and resumes generation at segment 8 before FFmpeg concatenation. I recommend RunPod or CoreWeave with H100 GPUs. H100 FP8 execution cuts Wan2.2 A14B generation time by half compared to A100 lowering total cost per video. I can build the Docker containers FastAPI backend Celery queues and FFmpeg validation scripts. In a past project I deployed a video diffusion inference pipeline using PyTorch CUDA Docker and S3 storage. 1) Which object storage provider such as AWS S3 or Cloudflare R2 does the ROLLCALL website currently use? 2) Is your existing frontend connected to PostgreSQL or another database for user job tracking? 3) What specific video resolution and frame rate settings are required for the Wan2.2 A14B outputs? Thanks, Bharat

@gotucat

Hi, I reviewed the request for an AI Film Studio Backend Setup: a ROLLCALL Website → API → persistent job queue → disposable GPU worker running Wan2.2 I2V A14B → FFmpeg/QC → object storage with resumable segment state. I’ll build the REST API (FastAPI/Uvicorn) with immediate job ID creation and explicit queued/generating/processing/completed/failed states stored in a persistent database. GPU workers will be disposable: model residency is maintained by keeping Wan2.2 I2V A14B weights in a mounted persistent model store (S3-compatible) and warming inside the container at worker start, while segment outputs and manifests persist outside the GPU via object storage. Idempotent retries, crash/OOM recovery, and resume-after-replacement are driven by stored segment checkpoints and job locks. For reliability, I’ll enforce reproducible Docker-based Python/PyTorch/CUDA builds, strict ffprobe validation, and cost-aware GPU monitoring/logging for A100/H100-class inference. Let’s discuss here now.

@devendrathakur12

ROLLCALL-V2: Hi, I’m Dev Singh, a senior AI/ML engineer focused on GPU inference and production pipelines. I have gone through your specific requirement for disposable Wan2.2 GPU workers. I have built something close to this for AI video pipelines, including RVC, 3DGS Avatar and ONNX Runtime workloads. I would keep job state in PostgreSQL and media in object storage, because local GPU disks disappear with the worker. I will build the FastAPI service and persistent queue first, then package Wan2.2 inside pinned CUDA/PyTorch Docker images. The worker loads the model once, claims jobs idempotently and checkpoints each segment before storage. If it dies after 7 of 24 segments, those seven remain marked completed and a replacement worker resumes from segment 8. At least that is where I would start. For A14B, I’d use an A100 80GB first rather than H100, since you already proved that footprint. Screenshots and architecture samples I can send. Where is your current ROLLCALL API and storage setup? Are the 24 segments already defined by the existing pipeline? Which output storage is currently connected to the website? Free for a quick call this week? Or answer those three and I will map the first workflow tonight. Dev Singh

@sabaehsan

Greetings, ROLLCALL-V2: You’re looking for a robust backend setup for your AI film platform, ensuring a stable and efficient workflow with Wan2.2 A14B on a disposable GPU worker. My approach would be to implement a strategy that keeps the model warm in memory while using a persistent job queue to track segments and job states. If the GPU fails after completing a few segments, the system would automatically resume work without duplicating efforts, leveraging persistent storage for data integrity. For GPU/cloud provider, I recommend using AWS with A100 instances for their balance of cost and performance. I can ensure a reproducible Docker deployment and effective monitoring for resource usage. My experience with similar large-scale video inference systems positions me well to deliver a strong solution quickly. Best regards, Saba Ehsan

@Muhammadzeesha59

Hello Sir/MAM I am a Skilled Full Stack Developer. Having rich experience in Java , C++ , C , C# , Python , Eclipse , Sql , Mysql , .Net ,Oracle , Object Oriented Programming , Data Structure , Algorithms, Linux , Windows , Cloud , Azure , Ubuntu , OpenAI , Desktop Applications. Web Development I have a perfect grip on “Artificial Intelligence” “Automation” , and work in “Machine Learning” Deep Learning “Computer Vision ” Object Detection”. My track record as demonstrated in my 100% job completion and 5-star review rating showcases My ability to deliver exceptional results on time and with utmost quality I believe that my skill set makes me the ideal candidate for this project Please come on chat we will discuss more about this I will be waiting for your reply . Thanks and Best Regards

@mak94pk

ROLLCALL-V2: I will spin up a Docker‑based FastAPI worker that pulls jobs from a PostgreSQL queue. The worker will mount a shared EFS (or S3) volume for source images, segment outputs, and the final MP4. The model will be loaded once into a persistent Docker image on the GPU node; the node will keep the model resident in RAM while it processes queued jobs. If the GPU instance dies after 7 of 24 segments, the worker will terminate, the queue will retain the 17 remaining segment IDs, and a new GPU node will resume from segment 8, re‑reading completed segments from S3 to avoid duplication. I recommend CoreWeave spot A100s for cost‑efficiency; A100 is sufficient for Wan2.2 A14B, H100 adds ~30% speed but at higher cost. Expected implementation: 5 days for end‑to‑end workflow, 2 days for hardening. Fixed price: $200. I have deployed large diffusion inference pipelines on AWS with 8×A100s for Stable Diffusion XL and a 12‑hour video generation service on Azure with H100s.

@toriquldev123

Hello Dear, I’m an experienced full-stack and ML infrastructure developer with strong expertise in Python, PyTorch, CUDA, Docker, FastAPI, GPU inference and production video pipelines. I understand you need a production-ready Wan2.2 I2V A14B backend with disposable GPU workers, persistent job state, automatic recovery, FFmpeg/QC, object storage and seamless ROLLCALL integration. I’d use A100 80GB initially, with a persistent queue/database and object storage outside the GPU. The model stays warm while the worker is active. If a worker dies after 7/24 segments, the completed 7 remain stored and the replacement worker resumes from segment 8 without duplication. I can deliver the first end-to-end workflow within 1–2 working days, with full production hardening in approximately 4–7 working days. I’ll provide reproducible Docker deployment, pinned Python/PyTorch/CUDA versions, recovery testing, monitoring, cost controls and complete documentation. Wan2.2 I2V A14B officially supports single-GPU inference on GPUs with at least 80GB VRAM, making your validated A100 setup a practical starting point. I’m ready to start immediately and focus first on getting a real MP4 generated, QC-validated, stored and playable through ROLLCALL.

@abdulhamidh2

ROLLCALL-V2: Hello, I understand your need for a robust, production-ready backend for Wan2.2 I2V A14B that’s scalable and fault-tolerant. To keep the GPU worker disposable yet maintain a warm model, I’d use persistent storage (S3 or equivalent) for the model weights and job queue state in a database like PostgreSQL. The GPU worker loads the model once on startup and processes queued jobs, updating job states atomically outside the GPU instance. If the GPU dies after 7 of 24 segments, the new worker resumes from segment 8 without reprocessing completed segments by reading persistent state. I recommend CoreWeave for its optimized A100/H100 instances and cost-effective scaling. Between A100 and H100, H100 offers better performance but at higher cost; A100 balances cost and power well for your workload. Implementation time is about 3–4 days including testing and deployment hardening. Fixed price estimate: $6000. I’ve deployed large-scale PyTorch diffusion pipelines with Kubernetes autoscaling, FastAPI endpoints, reproducible Docker builds, and robust monitoring on AWS and CoreWeave. Would you like me to share a detailed deployment plan? Best regards, AbdulHamid

@sajjadtaghvaeifr

ROLLCALL-V2: I have owrked on comfyui and python and generated video using Wan 2.2 14 billion you don't need a big GPU like H100 let us discuss it and I will answer your question

@starttechno

ROLLCALL-V2: I would make the GPU worker disposable by packaging Wan2.2 I2V A14B, pinned PyTorch/CUDA dependencies, FastAPI worker logic and FFmpeg in Docker. Models would live on persistent volume/object storage and be cached locally; once the worker starts, Wan remains resident during active processing, while PostgreSQL/Redis stores jobs, segment state, leases, retries and idempotency. Source images, completed segments, QC frames, manifests and final MP4s would live in S3-compatible persistent storage. If the GPU dies after 7 of 24 segments, those seven immutable records remain completed; a replacement worker claims only the 17 incomplete segments, validates existing artifacts, and resumes without duplication or regeneration. I recommend RunPod initially for fast disposable A100/H100 provisioning, persistent volumes and scale-to-zero economics. A100 80GB is sufficient and cost-effective; H100 is preferable only if throughput justifies its premium. I’ll deliver the first Website → API → real MP4 → ffprobe/QC → storage → playback flow in 1–2 working days, then harden recovery, monitoring, GPU cost tracking, restart logic and deployment documentation within 5 days. My experience includes production FastAPI/PyTorch GPU services, Docker/Kubernetes deployments and media-processing pipelines; I’ll provide exact image and package versions plus recovery-test evidence. Muhammad Saad

@dataspro

Nice to meet you , My name is Anthony Muñoz, I express my interest in working on your project after carefully reading the requirements and concluding that they match my area of knowledge and skills. I am currently the lead engineer for the IT agency DSPro and I have more than 10 years of experience in the field. I have successfully completed a large number of similar jobs and I consider your project to be a challenge in which I would like to work and be able to make it a reality. Please feel free to contact me, it will be my pleasure to help you. I greatly appreciate the time provided and I remain attentive to any questions or concerns. Greetings

@AndrewJSMAN

ROLLCALL-V2: I’ve run disposable GPU workers at scale for diffusion pipelines, so this is standard. Model lives in S3-compatible storage (Backblaze B2) accessed via NFS mount on the worker, job/segment state in PostgreSQL with advisory locks for idempotency, source images in MinIO buckets, MP4s in Cloudflare R2. Worker loads Wan2.2 A14B once, keeps it resident via CUDA persistent mode, runs FastAPI on Uvicorn, streams segments to R2, updates Postgres on each segment completion. If GPU dies after segment 7, PostgreSQL still has state, new worker resumes from segment 8 without re-encoding completed segments. I’ll use CoreWeave A100-80GB pools: A100 is overkill but cheaper than H100 for Wan2.2 I2V, and CoreWeave’s dedicated A100 clusters give consistent 100Gbps networking for large tensors. Implementation: Docker image with pinned PyTorch 2.2.2+cu121, Wan2.2 A14B Docker layer, FFmpeg 6.1, plus a lightweight Go supervisor for crash recovery and GPU telemetry. End-to-end in 48h. Thanks, Andrii

@alluankit01

ROLLCALL-V2 Hi, I can build the ROLLCALL V2 backend for Wan2.2 I2V A14B with FastAPI, Docker, PyTorch/CUDA, job queue, disposable GPU workers, FFmpeg/QC, persistent storage, and recovery-safe processing. My architecture: * Website calls API and gets job ID immediately * Job/segment state stored in Postgres/Redis * Source images, generated segments, QC frames and final MP4s stored in object storage * GPU worker loads the model once and keeps it warm while active * Worker writes progress after every segment * If GPU dies after 7 of 24 segments, a new worker resumes from segment 8 without regenerating completed files I recommend A100 80GB first because your prototype already proved it works and it is more cost-efficient. H100 can be used later if benchmarks justify the extra cost. Deliverables: * FastAPI backend * Queue/job state system * Disposable GPU worker * Docker deployment * Wan2.2 inference setup * FFmpeg/ffprobe validation * Object storage integration * Logs, retries and OOM recovery * Website playback integration * Exact version documentation Timeline: first website → job → GPU → MP4 → storage → playback workflow in 1–2 working days after access, then production hardening. Best regards Ankit

@carlosv116

Hi. I have extensive experience successfully leading projects that involve building robust GPU/ML infrastructure, and I can execute this project just as effectively. The requirements for a clean production V2 backend for the ROLLCALL platform are well-defined, though clarifying the criteria for choosing a cloud provider, particularly with respect to cost and performance for the Wan2.2 A14B model, will be essential. To construct the project, I would implement a disposable GPU worker that keeps the model warm in memory, utilizing persistent storage for job states and segments. In the event of a GPU failure after processing some segments, the system would resume from the last completed state while ensuring no duplication of work. I recommend AWS for its flexibility and scalability, particularly for large workloads. I would suggest the A100 for its current proven performance with Wan2.2 A14B, although the H100 may be considered for future-proofing if budget allows. I expect the initial implementation to be completed within 1-2 days, with a fixed-price estimate contingent on detailed requirements. I have previously deployed large-scale video inference systems using similar architectures that have proven reliable. What specific metrics or benchmarks would you like to see during the implementation to ensure we meet your expectations? Carlos

@godesignpk

Hi, I've reviewed your requirements for ROLLCALL-V2 and I'm excited about the opportunity to help. To create a disposable GPU worker while keeping the model warm, I would implement a persistent job queue using a database to store job states and segment data. The model would reside in a shared storage solution, allowing it to remain loaded in memory during processing. If the GPU fails after completing 7 out of 24 segments, the job state would allow for resuming from the last completed segment without duplication. For the GPU/cloud provider, I recommend AWS due to its robust support for A100 instances and scalability options. I would suggest the A100 over the H100 for this workload, as it is proven and cost-effective for video generation tasks. I estimate implementation to take around 3 days with a budget of $199. I've previously deployed large-scale diffusion systems that leverage similar architectures, ensuring reliability and performance. Looking forward to your thoughts! Best regards, Waqas & GoDesign Team

@amadorjay

Hi there, ROLLCALL-V2: The challenge is ensuring the GPU worker is disposable while keeping the model warm for efficient processing. I would implement a persistent job queue and database for job states and segment storage, along with a shared memory system to keep the model loaded in RAM during active operations. If the GPU fails after completing 7 of 24 segments, the system would retrieve the last saved state from the database and restart processing from segment 8 without redoing completed work. For the cloud provider, I recommend using CoreWeave for its optimized GPU handling and cost-effectiveness for large workloads. The A100 is suitable for initial stages, but transitioning to the H100 would provide better performance for more demanding tasks. I expect to implement the first end-to-end workflow within 1-2 days, with hardening afterward. As for fixed pricing, let’s discuss the details to align our expectations. Looking forward to discussing the details in chat.

@engruhulajom

Hello There! Hope you are doing fine. I have deployed production video generation pipelines for Wan2.2 on RunPod and Lambda Cloud. I can build your clean V2 backend with disposable GPU workers, persistent state, and zero data loss. I recommend A100 80GB for cost-effectiveness. I will implement a persistent job queue, model warm-up, and failure recovery so if the GPU dies after completing 7 of 24 segments, a new worker resumes from segment 8. I have deployed similar pipelines for Stable Diffusion and Wan2.2. I can share examples. Please start a chat to discuss this project in more detail. Best regards, Ruhul Ajom