See which line of code and which GPU kernel is burning your cloud bill
zymtrace profiles your whole system continuously, from application code down to CUDA kernels, and points straight at the hot path. No flat flamegraph guesswork, no instrumentation to add, just the exact place your GPU spend is going.
Your GPU bills keep climbing. Your profiler shows a flat histogram.
Flat sampling profilers tell you which function ran the most. They cannot tell you which kernel launch pattern is burning 22% of your A100 budget, or which Python call site triggered the unnecessary device sync.
-
01
No per-kernel attribution
Sampling profilers aggregate by function name. You see
aten::mmtook 40% of time -- but not which caller, which batch size, or which launch overhead is the culprit. -
02
Sampling misses short CUDA calls
A 99Hz sampler checks the call stack 99 times per second. A kernel that runs for 0.3ms and fires 400 times per second will be measured accurately only 4% of the time.
-
03
No Python-to-CUDA call path
The Python call stack and the CUDA execution timeline are separate. Nobody shows you which Python function triggered the device synchronization that stalled your pipeline for 1.2ms.
Running in two minutes
No code changes. No restart. Install the agent, point it at your cluster, and the first flamegraph is live before your next iteration finishes.
Install the eBPF agent
The zymtrace agent runs as a daemonset on your nodes. No kernel modules, no code changes, no restarts required.
helm install zymtrace \
oci://ghcr.io/zymtrace/charts/agent \
--set token=YOUR_TOKEN
Attach to running process
Within seconds, zymtrace begins stitching Python call stacks with CUDA kernel timelines. No process restart, no pid injection required.
$ zymtrace query \
--workload inference-prod \
--window 5m
Read the flamegraph
zymtrace highlights the call path consuming the most GPU time and links it to the source line and kernel name. Fix is one diff away.
Hot path: attention_fwd.py:247
Kernel: aten::mm [1.2ms avg]
GPU spend: 22% of total
Numbers that matter to infrastructure teams
The call path your profiler was missing
Sampling profilers show totals. zymtrace shows call paths, kernel attribution, and timeline causality in a single view, correlated from Python frame to CUDA thread block.
Flamegraph from Python to CUDA
A unified call stack from your Python orchestration layer through PyTorch operators down to individual CUDA kernel invocations. One view, no context switching.
Continuous 99Hz sampling
Always-on profiling runs at 99Hz alongside your workloads without any code changes. The profiler is always recording so you query historical snapshots on demand.
Kernel-level attribution
See exactly which CUDA kernel ran, on which SM, for how long. Launch overhead, memory copy stalls, and occupancy breakdowns next to the call path that launched them.
Multi-node cluster view
Aggregate profiles across an entire inference cluster. Compare flamegraphs between nodes to find the outlier GPU dragging down your P99 latency.
Flamegraph diff mode
Load two snapshots and see a visual diff of the call graph. Find the regression in seconds after a model or infrastructure update, correlated to the exact code change.
Zero instrumentation via eBPF
eBPF kernel probes capture stack traces and CUDA API calls without modifying your application code. No library injection, no environment variable setup, no sudo required at runtime.
What GPU infrastructure teams find
"We cut our A100 spend by 31% in three weeks. The flamegraph diff showed the exact kernel at fault. No guessing, no sampling gaps."
"Finally, a profiler that follows the call stack from Python into CUDA. The call-stack continuity is what makes it real. You see exactly where your compute budget lands."
Start free, scale as your cluster grows
Priced per GPU node. No per-seat licenses. See full pricing details
Up to 2 GPU nodes, 7-day history. For individual engineers and small experiments.
- Up to 2 GPU nodes
- 7-day history
- Basic flamegraph viewer
- Community Slack support
Up to 10 GPU nodes, 30-day history. For teams running production inference workloads.
- Up to 10 GPU nodes
- 30-day history
- Flamegraph diffing across deploys
- Cost attribution by code path
- PyTorch and JAX integrations
Up to 30 GPU nodes, 90-day history, SSO. For infrastructure teams running large clusters.
- Up to 30 GPU nodes
- 90-day history
- SAML SSO
- REST API access + RBAC
- Priority Slack channel + SLA
GPU profiling in practice
Profiling a Production LLM Inference Service on H100s
We profiled a large-batch inference workload running on eight H100 GPUs and found 22% of GPU time spent in memory copy operations that no sampling profiler had surfaced before.
What CUDA Kernel Launch Latency Looks Like at Scale
A deep dive into how kernel launch overhead accumulates when running thousands of small kernels per second and what zymtrace shows that NVIDIA Nsight misses.
The Hidden Cost of Missed Kernel Fusion in PyTorch
Operator fusion is well understood in theory. Finding where PyTorch fails to fuse in your specific model at runtime is where most teams hit a wall.
Start profiling free today
No credit card. Connect your first GPU in 3 minutes. The flamegraph will tell you something your current profiler cannot.