Inside NVIDIA’s cuDNN Graph API: Fusion, Autotuning, and Plan Reuse with cuDNN Frontend
MarkTechPost tutorial walks through NVIDIA's cuDNN Frontend graph API, covering kernel fusion, autotuning, plan reuse, and CUDA graph capture on Colab GPUs.
The tutorial explains how to express GPU computations as operation graphs via the cuDNN Frontend graph API, running the five-step build pipeline of validate, build operation graph, create execution plans, check support, and build plans. It progresses from a single fused convolution with bias and ReLU to autotuning across engine configs, FP8-style epilogues, attention, plan serialization, dynamic shapes, and CUDA graph capture. Each kernel is benchmarked against a PyTorch reference on a single Colab GPU to verify correctness and measure cost. The piece also covers practical setup issues like making libcudnn.so visible to the frontend's dynamic loader.
The VMs Powering Mobile Agents (Instinct, Claude Code)
A teardown reveals Claude Code runs in Firecracker microVMs with a Rust PID 1 and MITM'd egress, while Instinct rents E2B sandboxes with git-based memory.
The author inspects the virtual machines hosting cloud agents: Claude Code runs in a Firecracker microVM with a custom Rust init (process_api) as PID 1, a 324 MB Bun harness on a read-only disk, and 443-only MITM'd SSE egress to api.anthropic.com with host-rotated OAuth tokens and no inbound access. Instinct rents E2B sandbox-as-a-service Firecracker microVMs (Ubuntu 22.04, 2 vCPU, 1.9 GB RAM) where agent memory is a git repo of Markdown committed by the agent and pushed to S3 as a single bundle, using short-lived STS credentials. Both platforms rely on Firecracker, differing mainly in fleet operator and guest boot configuration.