Chris Vela

Chris Vela is a forward deployed engineer at Runpod, where his technical writing addresses the work between choosing an AI model and running it reliably: GPU configuration, model loading, startup delays, and serving performance. His deployment guides explain both how to get a model running and what the configuration costs in latency, infrastructure, and maintenance.

Diffusion-based video compression at IKIN

Vela previously worked as principal data scientist at IKIN. In September 2024, he and Bryan Westcott, the company’s director of applied artificial intelligence, co-authored Diffusion-Based Compression. Their approach used a diffusion model and a compact set of guidance data to reconstruct video at the receiving end, reducing the information that needed to cross the network. The report’s announcement described regenerating images that closely resemble the originals, rather than creating unrelated video from a text prompt. The work applied generative AI to a specific infrastructure problem: delivering high-quality video over limited bandwidth.

Reducing the wait before inference

At Runpod, Vela has written detailed guidance on reducing vLLM cold starts—the delay before a newly started worker can answer its first request. He separates provisioning a GPU and pulling a container image from the subsequent work of loading model weights, compiling kernels, and capturing CUDA graphs for execution. That distinction matters because a configuration change can shorten model initialization without fixing a wait for available hardware.

His article, updated in September 2026, reports a small Runpod Serverless test serving Qwen3-32B-FP8 on two H200 GPUs. Median startup delay fell from 324 seconds across three baseline trials to about 91 seconds across two optimized trials; the optimized configuration’s first-ever boot still took about 284 seconds. The changes preserved compilation artifacts between worker restarts, prefetched model weights, reduced the set of batch sizes used for CUDA-graph capture, and skipped Hugging Face checks once the required files were local. The test request’s execution time remained roughly 0.7 seconds in both configurations: the measured gain was in getting ready to serve it.

Vela treats the improvement as directional rather than a universal benchmark. The reported delay also includes container-image pulls and waits for GPU capacity, which the small sample cannot separate from initialization. His guidance pairs the timing results with operational checks: confirm that each setting changed the worker logs before attributing an improvement to it. He also explains the tradeoffs. Persistent network storage preserves caches but restricts datacenter placement; changing models, hardware, or serving flags can require another compilation. For a team with steady traffic and limited engineering capacity, keeping a worker running may be cheaper than building and maintaining the optimization.

Getting a large model into service

Vela also co-authored a Qwen3.8-Flash-Next deployment guide with Matt Sarrel and Jessica Garson Beauchemin. Their September 2026 testing covered four-H200 configurations, memory planning, and multi-GPU initialization failures. The guide documents a concrete failure and remedy: disabling NVLS allowed the tested GPU workers to initialize instead of repeatedly crashing before downloading the model weights.

The guide also distinguishes a reachable server from a fast one. Skipping compilation and CUDA-graph capture can shorten initialization enough to pass the platform’s health checks, while leaving early requests much slower as kernels compile on first use. By explaining that startup-versus-serving tradeoff alongside the working configuration, the authors give developers a basis for choosing between an autoscaling endpoint, persistent caches, and a continuously running GPU pod.