> ## Documentation Index > Fetch the complete documentation index at: https://na-36-changelog-go-livepeer-2026-05-18.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Capacity Planning > Determine the correct -maxSessions value for your orchestrator using livepeer_bench, bandwidth calculations, and NVENC hardware session limits. Covers GPU and CPU transcoding capacity, AI VRAM budgeting, and session limit configuration. > [!TIP] > > Set `-maxSessions` to the minimum of your hardware limit and your bandwidth limit. Too low wastes capacity and limits earnings. Too high pushes transcoding behind live segment cadence – segments pile up, gateways log errors, and your reputation score suffers. *** `-maxSessions` is the ceiling on concurrent transcoding streams your orchestrator accepts. Go-livepeer defaults to 10 sessions. For most hardware, this is either too conservative (leaving GPU capacity unused) or too aggressive (exceeding available bandwidth). The correct value requires measurement. Two constraints determine the session limit independently: * **Hardware limit** – the number of concurrent sessions the GPU transcodes within live segment timing, measured with `livepeer_bench` * **Bandwidth limit** – the number of concurrent sessions your connection carries within available upload bandwidth The session limit is `min(hardware_limit, bandwidth_limit)`. Video transcoding capacity and AI inference capacity use separate limits and separate mechanisms. Video transcoding sessions. AI capacity is configured per pipeline via the `capacity` field in `aiModels.json`. Hardware Limit ## Measuring hardware capacity `livepeer_bench` simulates network workloads with segments arriving at live pace across multiple concurrent sessions. It reports a duration ratio: total transcoding time divided by total source duration. A ratio below 1.0 means the GPU is keeping up. A ratio above 1.0 means it is falling behind. ### Installing livepeer\_bench `livepeer_bench` ships with go-livepeer. Verify it is on PATH: ```bash icon="terminal" title="Check livepeer_bench availability" theme={null} livepeer_bench -help ``` A missing command usually means go-livepeer is installed outside PATH. Add the binary directory to PATH or call the binary directly. The binary sits alongside `livepeer` and `livepeer_cli`. ### Setting up the benchmark ### 1. Download the test stream ```bash icon="terminal" title="Download the benchmark stream" theme={null} wget -c https://storage.googleapis.com/lp_testharness_assets/bbb_1080p_30fps_1min_2sec_hls.tar.gz tar -xvf bbb_1080p_30fps_1min_2sec_hls.tar.gz ls bbb/ # source.m3u8 plus a set of .ts segment files ``` ### 1. Download the rendition config ```bash icon="terminal" title="Download the rendition config" theme={null} wget -O transcodingOptions.json \ https://raw.githubusercontent.com/livepeer/go-livepeer/master/cmd/livepeer_bench/transcodingOptions.json ``` This config defines the four standard output renditions (240p, 360p, 480p, 720p). It is the same rendition set most gateways use on the network. ### 1. Run at increasing concurrency Run the benchmark at increasing `-concurrentSessions` values until the ratio exceeds 0.8: ```bash icon="code" title="session-scaling.sh" theme={null} #!/bin/bash for i in {1..20} do livepeer_bench \ -in bbb/source.m3u8 \ -transcodingOptions transcodingOptions.json \ -nvidia 0 \ -concurrentSessions $i |& grep "Duration Ratio" >> bench.log done ``` For multiple GPUs, pass both IDs: ```bash icon="terminal" title="Run livepeer_bench on multiple GPUs" theme={null} -nvidia 0,1 ``` For CPU-only transcoding, omit the `-nvidia` flag entirely. ### Reading the output The summary table appears after each run: ```text icon="terminal" title="Sample benchmark output" theme={null} *------------------------------*---------------------* | Concurrent Sessions | 4 | | Real-Time Segs Transcoded | 120 | | * Real-Time Segs Ratio * | 1 | | Total Source Duration | 240s | | Total Transcoding Duration | 18.42s | | * Real-Time Duration Ratio * | 0.0768 | *------------------------------*---------------------* ``` Ratio Meaning **\< 1.0** GPU has headroom and handles this session count within live segment pace **= 1.0** Exactly on live pace – no headroom; any spike causes lag **> 1.0** GPU overloaded at this session count – reduce
**Production threshold:** the last concurrent session count where the ratio stays at or below 0.8 is the hardware limit. The 20% headroom absorbs upload/download overhead and transient load spikes. Example output from the scaling script: ```text icon="terminal" title="Benchmark session scaling example" theme={null} | * Real-Time Duration Ratio * | 0.058 | # 1 session | * Real-Time Duration Ratio * | 0.114 | # 2 sessions | * Real-Time Duration Ratio * | 0.421 | # 3 sessions | * Real-Time Duration Ratio * | 0.783 | # 4 sessions — last below 0.8 | * Real-Time Duration Ratio * | 1.102 | # 5 sessions — exceeds threshold ``` Hardware limit in this example: **4 sessions**. ### NVENC hardware session caps Consumer NVIDIA GPUs enforce a hard limit of 3 to 8 concurrent NVENC sessions in the driver, regardless of VRAM or compute capacity. This limit is imposed by NVIDIA in consumer-grade drivers to differentiate from professional-grade Quadro and datacenter cards. The benchmark reflects this cap with a sharp ratio jump at the NVENC ceiling, even when VRAM and compute remain available. Professional GPUs such as the A100 and H100 are outside this consumer driver restriction. ### CPU transcoding For CPU-only setups, omit `-nvidia` from the benchmark command. Start at `-concurrentSessions 1` and increase. CPU transcoding produces significantly higher ratios per session than GPU. Use the benchmark result directly. Treat older rule-of-thumb figures as historical context only, because modern CPUs (Ryzen 9 7950X, Threadripper PRO) handle more sessions than older guidance suggests. Bandwidth Limit ## Calculating bandwidth capacity Every transcoding session consumes upload and download bandwidth. The current standard rendition set totals approximately **5.65 Mbps upload per stream** (sum of all output renditions). Source resolution determines download volume, so budget **\~6 Mbps symmetric** per stream to cover both directions with margin. Available bandwidth Theoretical max (streams) With 20% margin 100 Mbps symmetric \~16 streams \~13 streams 500 Mbps symmetric \~83 streams \~66 streams 1 Gbps symmetric \~166 streams \~133 streams
Use the upload rate as the primary constraint. Residential connections with 100 Mbps download commonly have 20 to 30 Mbps upload, so the upload cap usually dominates. Deriving the Limit ## Setting maxSessions The session limit is `min(hardware_limit, bandwidth_limit)`. Example calculation: Input Value Hardware limit (from benchmark) 12 sessions Available bandwidth 100 Mbps symmetric Bandwidth limit (100 Mbps ÷ 6 Mbps, 20% margin) \~13 sessions **Session limit** **min(12, 13) = 12**
Apply the limit in your startup command: ```bash icon="terminal" title="Set maxSessions at startup" theme={null} livepeer \ -orchestrator \ -transcoder \ -maxSessions 12 \ -network arbitrum-one-mainnet \ ... ``` For a split orchestrator/transcoder setup, set `-maxSessions` on both nodes – the orchestrator uses it to track total capacity; the transcoder uses it to control how many concurrent jobs it accepts. AI VRAM Budget ## AI inference and VRAM capacity AI inference capacity is separate from video transcoding capacity. `-maxSessions` has no effect on AI pipeline concurrency. The `capacity` field in each `aiModels.json` entry controls how many concurrent inference requests that pipeline accepts. VRAM is the binding constraint for AI capacity. A 24 GB GPU holds one large diffusion model warm, or multiple smaller pipelines simultaneously: Pipeline Warm model VRAM Notes `text-to-image` (SDXL-Lightning) \~12–18 GB Lightning models lean toward 12 GB end `image-to-image` (SDXL) \~12–18 GB Same architecture as text-to-image `audio-to-text` (Whisper large-v3) \~3 GB VRAM-efficient; pairs well with other pipelines `image-to-text` (BLIP) \~1–2 GB Entry-level pipeline; runs on 4 GB GPUs `llm` (Llama 3.1 8B quantised) \~8 GB Via Ollama q4 quantisation; accessible on 8 GB GPUs `upscale` (SD x4 upscaler) \~8 GB Smaller than generation models `segment-anything-2` (SAM2 large) \~12–24 GB Depends on model variant
**Beta constraint:** Only one warm model per GPU is supported during the Beta phase. Additional entries with `"warm": true` beyond the number of GPUs will cause a conflict at startup. Keep additional pipelines cold or assign them to separate GPUs. **Video vs AI VRAM:** NVENC and NVDEC use dedicated hardware blocks and consume minimal VRAM for video transcoding. Running video sessions alongside warm AI models on the same GPU is supported, and AI model footprint remains the main VRAM constraint. Tuning Live ## Tuning after going live The benchmark estimate is a starting point. Live network conditions add variables the benchmark omits: * Actual segment sizes and bitrates from gateways vary from the test stream * Upload latency and jitter add overhead beyond raw bandwidth measurements * Reward calls and ticket redemptions consume CPU and network intermittently Monitor these Prometheus metrics after activation: Metric Watch for `livepeer_transcode_duration_seconds` Should stay below 2 seconds per session (the segment duration) `livepeer_real_time_seg_transcoded` Drops below 1 when segments fall behind live segment cadence CPU/GPU utilisation Sustained above 95% signals the limit should be reduced
After 24 hours of clean operation, increment `-maxSessions` by 1 to 2 and observe. A sudden drop in gateway traffic should send you to the logs first; look for `OrchestratorCapped` errors that show the session ceiling is blocking new jobs. ## Related pages > **[AI Inference Operations](/v2/orchestrators/guides/ai-and-job-workloads/ai-inference-operations)** > > Full aiModels.json reference including the `capacity` field for AI pipeline concurrency. > **[Model Management](/v2/orchestrators/guides/config-and-optimisation/ai-model-management)** > > Warm vs cold strategy and VRAM allocation across multiple AI pipelines. > **[Metrics and Alerting](/v2/orchestrators/guides/monitoring-and-tooling/metrics-and-alerting)** > > Prometheus metrics for transcoding throughput, alerting, and session health. > **[GPU Support Reference](/v2/orchestrators/resources/gpu-support)** > > NVENC session caps by GPU tier and supported hardware matrix. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.