Livepeer
Livepeer Routes Video and AI Jobs to Independent GPU Providers
Livepeer is an open video infrastructure network that routes transcoding and AI inference requests through gateways to independent GPU operators. It fits workloads that can use supported pipelines, tolerate provider-dependent capacity and latency, and verify returned output before production use. LPT staking coordinates operator selection and incentives, while any charges for completed compute follow the chosen access path.
Last updated:The fit decision begins with workload compatibility, a gateway route, and acceptable price and latency boundaries. A production plan also needs separate answers for storage, delivery, authentication, and recovery because the compute network doesn't supply every part of a media product.
From request to returned media
A request moves from an application to a gateway, then to an orchestrator with suitable compute. The gateway manages discovery, routing, session state, and payments. The orchestrator performs the requested work locally or hands it to an attached worker, then returns the output through the gateway.
The request path
The request path separates application-facing coordination from GPU execution. That division lets a gateway choose among available operators without making every application manage the underlying protocol or run compatible hardware.
Gateway selection
A gateway first needs a request it understands: a supported transcoding profile or AI pipeline, valid input, and an allowed price. Its selection logic can then consider advertised capability, availability, location, price, and prior performance. A candidate with substantial stake still needs the right software and free capacity for the specific job.
GPU execution
An orchestrator receives the work and sends it to compatible compute. For streaming transcoding, the network handles successive media segments and returns requested renditions. For AI inference, the worker runs the selected model or pipeline and sends its response back. The application should verify a decodable rendition for transcoding or valid output for AI inference, along with a successful request or session status.
Workload choices start with compatibility
Compatibility determines whether the network can process a workload at all. Video transcoding changes properties such as resolution, bitrate, or encoding profile so one source can serve different playback conditions. The chosen gateway and orchestrator must support the requested input and output combination.
AI inference follows a model-specific path. Video generation, analysis, transformation, and related media operations can require different runners, model weights, VRAM, and request formats. Availability therefore belongs to the exact pipeline and model, not to a broad claim of AI support. Changing the model can alter capacity and response time even when the source media stays the same.
Gateway access shapes the operating model
A gateway determines how much protocol work the application must manage. Hosted access can present ordinary API authentication and provider billing while handling orchestrator discovery and settlement behind the service. That route is easier to integrate, though its limits, retention rules, pricing, and recovery behavior come from the provider.
A self-run gateway gives the operator direct control over routing and protocol configuration. Onchain operation needs chain connectivity, a funded account, and sufficient deposit and reserve for jobs. The gateway itself doesn't require a GPU because it coordinates work rather than performing it. Its availability, account security, pricing limits, and monitoring still become part of the application's operating burden.
Can Livepeer meet a latency-sensitive video path?
A latency-sensitive path can fit when the gateway finds available compute near enough to return the requested output inside the application's deadline. Stake alone can't establish that fit.
Streaming delay includes ingest, segment formation, gateway routing, GPU processing, result transfer, and playback buffering. AI inference adds model availability and execution time. A cold or busy model path may behave differently from a ready worker, even when both advertise the same capability.
A tighter completion window doesn't change the requested computation, but it reduces the number of acceptable routes. Capacity also moves as operators take other jobs, so one successful response isn't a permanent service-level promise.
Production evaluation should use representative inputs and observe returned media, request status, and end-to-end timing. The relevant proof is whether the chosen gateway repeatedly meets the application's boundary, not whether the network can perform the workload somewhere.
Compute prices follow the requested work
The compute price is separate from the market price of LPT. In the transcoding protocol, orchestrators advertise a price per unit of pixel work, and gateways can apply a maximum acceptable price. More output pixels or additional renditions increase the work requested. AI gateways can use capability-specific pricing because different models and pipelines consume different resources.
Livepeer's payment channel uses probabilistic tickets that orchestrators redeem on Arbitrum when they win. This keeps most job-level payment traffic away from individual onchain transfers. Redemption overhead can affect an orchestrator's advertised rate, while a restrictive gateway ceiling can leave fewer operators eligible. A hosted service may translate these mechanics into its own invoice, so protocol pricing and the application's final bill aren't necessarily identical.
LPT ties stake to service
LPT supplies the economic coordination layer rather than the video-processing medium itself. LPT is an ERC-20 token used for network staking. Orchestrators stake it, and delegators can place stake behind operators. Under the current protocol, the combined stake can influence access to work and the distribution of rewards.
Operators earn fees for completed compute and may share fees and protocol rewards with delegators under their configured terms. Those terms, inflation settings, and governance parameters can change. They aren't fixed yields. Staking also doesn't reserve a particular GPU, guarantee output quality, or grant ownership of any media the network processes.
Operating a node demands more than spare GPU time
Node operation requires compatible software, dependable networking, funded protocol accounts, and sustained service availability. A powerful card doesn't help if the node can't advertise, receive, process, and return the requested workload reliably.
Transcoding capacity
A transcoding operator must match the GPU build, driver, and CUDA requirements of the installed go-livepeer release when using NVIDIA acceleration. The operator also configures service reachability, supported transcoding options, pricing, and attached workers. Concurrent stream capacity depends on the hardware and requested profiles, so it needs workload testing rather than a universal stream count.
AI inference capacity
An AI operator needs compatible model runners, enough VRAM for the advertised pipeline, locally available model weights, and permission to use any gated model. Keeping a model ready can reduce startup delay, while loading or replacing it consumes time and memory. The operator should advertise only capabilities the node can actually serve under its current configuration.
Capacity-miss recovery boundaries
A capacity miss calls for a small, reversible test before any price or output requirement changes. Hold the model, input, and requested output constant. If a tighter deadline causes the same job to fail, the changed acceptance window may have excluded an otherwise functional route.
- Confirm the gateway advertises the exact pipeline, model, or transcoding profile.
- Record the price ceiling and latest acceptable return time before submitting work.
- Use one representative, non-sensitive input and retain it unchanged for the retry.
- After a discovery or capacity error, allow one orchestrator swap or choose another compatible route if the access path permits it.
- Accept completion only when the output is usable and the request or session status shows success.
A successful unchanged request on the second route points toward temporary capacity or routing trouble on the first. Another failure calls for inspection of the specific response and input constraints. Raising the price ceiling, switching models, or relaxing the output profile would change the test and should be a separate decision.
Media privacy sits outside staking
Privacy depends on the path carrying the media. Video segments and inference inputs travel to a gateway and operator for offchain processing, while blockchain records coordinate protocol state and payments. Onchain settlement doesn't encrypt source footage, erase provider logs, or establish a retention policy.
Sensitive media therefore needs an access route with suitable transport security, authentication, storage behavior, and data-handling terms. A self-run gateway controls one part of that path, though remote orchestrators still receive the data needed for computation. Model licenses and rights to source or generated material also remain separate from protocol staking and settlement.
The rest of the media stack still matters
A production media stack needs more than distributed compute. Live ingest, durable storage, playback delivery, access control, observability, and content policy may come from the application or a gateway service. The protocol's role is to coordinate supported video and AI work across independent operators, then return output to the requesting path.
This separation suits teams that want to choose their own application layer while drawing compute from an open network. It also means a protocol integration shouldn't inherit assumptions from a bundled platform. An HLS rendition ladder is a concrete example: GPUs create the requested encodes, while the application still owns ingest, playback, storage, access control, and delivery.
Common questions, answered
Is Livepeer a blockchain or a video API?
Livepeer is a protocol and compute network with blockchain-based coordination, while applications usually reach it through gateways and APIs. Video transcoding and AI inference run offchain on operator hardware. Onchain components handle staking, protocol state, and settlement. A hosted gateway may hide those details behind ordinary API credentials and provider billing, so the visible workflow depends on the chosen access path.
Can a gateway route work without a local GPU?
Yes. A gateway accepts requests, discovers or selects orchestrators, manages sessions and payments, and returns output. The GPUs sit with orchestrators or their attached workers. Running your own gateway still requires dependable networking, chain connectivity for onchain use, funding, and operational monitoring, but it doesn't require a local GPU unless the same system also performs compute.
Are the same AI models available from every gateway?
No. Model availability depends on what the gateway exposes and which orchestrators have compatible runners, loaded weights, sufficient VRAM, and free capacity. A model's license may also require acceptance before an operator can serve it. Check the exact pipeline, model identifier, input constraints, and output shape; a generic claim of AI support doesn't establish those details.
What does an insufficient-capacity response indicate?
An insufficient-capacity response means the chosen route couldn't place the request on eligible compute at that moment. It doesn't prove the model is permanently unsupported. Busy workers, an unloaded model container, a restrictive price ceiling, or discovery trouble can produce a similar symptom. Keep the input and parameters fixed for one bounded route change, then use the next response to narrow the cause.
Does a prototype require an onchain gateway?
No. Livepeer supports offchain development or local operation, and hosted gateways provide another entry path. An offchain prototype can validate request construction and output handling before wallet, deposit, and reserve setup. It doesn't establish that production capacity, settlement, authentication, or latency will behave identically, so repeat the preflight against the intended production gateway before committing traffic.
Why doesn't high delegated stake guarantee service quality?
Delegated stake is an economic signal, not a complete service benchmark. A job also depends on advertised capability, location, price, capacity, software configuration, and operator performance. A heavily staked orchestrator may still lack the requested model or have no available worker. Compare the conditions attached to the exact workload and require valid output instead of treating stake as a quality guarantee.
When is LPT involved in a video request?
LPT enters through staking, delegation, rewards, and governance rather than as the universal per-job payment. An application using a hosted gateway may never handle LPT directly. A self-run onchain gateway instead needs payment funding and chain transactions under its current configuration. Holding the token alone neither pays every compute request nor reserves a particular model or GPU.