> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livepeer.org/llms.txt
> Use this file to discover all available pages before exploring further.

# AI and Job Pipelines Overview

> What a gateway pipeline is, the three job types your gateway can route (video transcoding, AI inference, BYOC), and how pipeline selection maps to gateway type.

export const LinkArrow = ({href, label, description, newline = true, borderColor, className = '', style = {}, ...rest}) => {
  const linkArrowStyle = {
    display: 'inline-flex',
    alignItems: 'center',
    justifyContent: 'center',
    gap: "var(--lp-spacing-1)",
    width: 'fit-content',
    ...borderColor && ({
      borderColor
    })
  };
  return <span className={className} style={style} {...rest}>
      {newline && <br />}
      <span style={linkArrowStyle}>
        <a href={href} target="_blank" rel="noopener noreferrer">
          {label}
        </a>
        <Icon icon="arrow-up-right" size={14} color="var(--lp-color-accent)" />
      </span>
      {description && description}
      {description && <div style={{
    height: "var(--lp-spacing-3)"
  }} />}
    </span>;
};

export const TableCell = ({children, align = "left", header = false, style = {}, className = "", ...rest}) => {
  const Component = header ? "th" : "td";
  return <Component className={className} style={{
    padding: "0.75rem 1rem",
    textAlign: align,
    border: header ? "none" : "1px solid var(--lp-color-border-default)",
    ...style
  }} {...rest}>
      {children}
    </Component>;
};

export const TableRow = ({children, header = false, hover = false, style = {}, className = "", ...rest}) => {
  const rowId = `table-row-${Math.random().toString(36).substr(2, 9)}`;
  return <>
      {hover && <style>{`
          #${rowId}:hover {
            background-color: var(--lp-color-bg-card);
          }
        `}</style>}
      <tr id={rowId} className={className} style={{
    ...header && ({
      backgroundColor: "var(--lp-color-accent-strong)",
      color: "var(--lp-color-on-accent)",
      fontWeight: "bold"
    }),
    ...style
  }} {...rest}>
        {children}
      </tr>
    </>;
};

export const StyledTable = ({children, variant = "default", style = {}, className = "", ...rest}) => {
  const wrapperVariants = {
    default: {
      border: "1px solid var(--lp-color-border-default)",
      backgroundColor: "var(--lp-color-bg-card)",
      overflow: "hidden"
    },
    bordered: {
      border: "2px solid var(--lp-color-accent)",
      backgroundColor: "var(--lp-color-bg-page)",
      overflow: "hidden"
    },
    minimal: {
      border: "none",
      backgroundColor: "transparent",
      overflow: "visible"
    }
  };
  return <div data-docs-styled-table-shell className={className} style={{
    width: "100%",
    padding: 0,
    margin: 0,
    ...wrapperVariants[variant],
    ...style
  }} {...rest}>
      <table data-docs-styled-table style={{
    width: "100%",
    borderCollapse: "collapse",
    borderSpacing: 0,
    margin: 0,
    backgroundColor: "transparent"
  }}>
        {children}
      </table>
    </div>;
};

export const CustomDivider = ({color = "var(--lp-color-border-default)", middleText = "", spacing = "default", style = {}, className = "", ...rest}) => {
  const spacingPresets = {
    default: {
      margin: "24px 0"
    },
    overlap: {
      margin: "-1rem 0 -1rem 0"
    },
    tight: {
      margin: "0 0 -1rem 0"
    },
    section: {
      margin: "0 0 -2rem 0"
    },
    sectionOverlap: {
      margin: "-1rem 0 -2rem 0"
    },
    deepOverlap: {
      margin: "-1rem 0 -1.5rem 0"
    }
  };
  const spacingStyle = spacingPresets[spacing] || spacingPresets.default;
  return <div role="separator" aria-orientation="horizontal" className={className} style={{
    display: "flex",
    alignItems: "center",
    ...spacingStyle,
    fontSize: style?.fontSize || "16px",
    height: "fit-content",
    ...style
  }} {...rest}>
      <span style={{
    marginRight: "var(--lp-spacing-px-8)",
    opacity: 0.2
  }}>
        <Icon icon="/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg" />
      </span>
      <div style={{
    flex: 1,
    height: "1px",
    background: "var(--lp-color-border-default)",
    opacity: 0.4
  }}></div>
      {middleText && <>
          <Icon icon="circle" size={2} />
          <span style={{
    margin: "0 8px",
    fontWeight: "bold",
    color: color,
    opacity: 0.7
  }}>
            {middleText}
          </span>
          <Icon icon="circle" size={2} />
        </>}
      <div style={{
    flex: 1,
    height: "1px",
    background: "var(--lp-color-border-default)",
    opacity: 0.4
  }}></div>
      <span style={{
    marginLeft: "var(--lp-spacing-px-8)",
    opacity: 0.2
  }}>
        <span style={{
    display: "inline-block",
    transform: "scaleX(-1)"
  }}>
          <Icon icon="/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg" />
        </span>
      </span>
    </div>;
};

<CustomDivider style={{margin: "-1rem 0 -1rem 0"}} />

A Gateway's **node type** determines which workloads it can route:

* <Badge color="blue">Video</Badge> transcoding,
* <Badge color="purple">AI</Badge> inference (batch and real-time), or
* <Badge color="green">Dual</Badge> (both pipelines on a single node).

Each pipeline is the control-plane path between an application request and Orchestrator execution.

## Gateway Role

<Note>
  This explains how pipelines work from the Gateway operator's perspective. For Orchestrator-side configuration (running AI workers, hosting models), see the Orchestrators section.
</Note>

<CardGroup cols={2}>
  <Card title="Gateway responsibilities" icon="server">
    Accepts requests, matches Orchestrator capabilities, enforces price and latency policy, handles retries and failover, returns outputs to the client.
  </Card>

  <Card title="Orchestrator responsibilities" icon="microchip">
    Runs GPU inference or transcoding, hosts model weights, executes compute, returns results to the Gateway.
  </Card>
</CardGroup>

<CustomDivider style={{margin: "0 0 -2rem 0"}} />

## Node Types

<Badge color="blue">Video</Badge> <Badge color="purple">AI</Badge> <Badge color="green">Dual</Badge>

Livepeer Gateways route four categories of work. Each has different ingest patterns, payment models, and Orchestrator requirements. A <Badge color="green">Dual</Badge> node runs both video and AI pipelines on a single node.

```mermaid theme={"theme":{"light":"github-light","dark":"dark-plus"}}
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#18794E', 'primaryTextColor': '#fff', 'primaryBorderColor': '#3CB540', 'lineColor': '#3CB540', 'mainBkg': '#18794E', 'nodeBorder': '#3CB540', 'clusterBkg': 'transparent', 'clusterBorder': '#3CB540', 'titleColor': '#3CB540', 'edgeLabelBackground': 'transparent', 'textColor': '#3CB540', 'nodeTextColor': '#fff'}}}%%
flowchart LR
    A["Client App"] --> GW["Gateway"]
    GW --> VT["Video Transcoding <br/> RTMP/HTTP segments"]
    GW --> AI["Batch AI Inference <br/> HTTP request/response"]
    GW --> RT["Real-time AI <br/> Live stream frames"]
    GW --> BC["BYOC <br/> Custom containers"]
    VT --> OV["Orchestrators <br/> (Video)"]
    AI --> OA["Orchestrators <br/> (AI models)"]
    RT --> OR["Orchestrators <br/> (ComfyStream)"]
    BC --> OB["Orchestrators <br/> (BYOC capability)"]

    classDef default fill:#1a1a1a,color:#fff,stroke:#2d9a67,stroke-width:2px
```

### Video Transcoding

The Gateway ingests a live or recorded video stream via RTMP or HTTP, segments it, and distributes transcoding work to Orchestrators. Orchestrators return multiple encoded renditions, which the Gateway assembles for HLS delivery.

On-chain video Gateways use the Livepeer probabilistic micropayment (PM) system: each segment carries a payment ticket redeemed on Arbitrum One. An ETH deposit and reserve balance on the TicketBroker contract are required.

**Ports:** RTMP ingest on `:1935`, HTTP ingest and API on `:8935`, CLI on `:5935`.

### Batch AI Inference

The Gateway accepts HTTP requests for AI pipelines (text-to-image, audio-to-text, LLM, and others), routes each request to an Orchestrator advertising the requested pipeline and model, and returns the inference result. This is a request/response pattern - the Gateway sends a request and waits for the result.

Off-chain AI Gateways require no ETH deposit. The Gateway targets Orchestrators directly via `-orchAddr`. For on-chain AI (dual node type), the PM system applies.

**Port:** HTTP API on `:8935` (set via `-httpAddr`, enabled by `-httpIngest`).

See <LinkArrow href="/v2/developers/build/model-support" label="Model Support" newline={false} /> for all supported batch AI pipeline types and model architectures.

### Real-time AI

Real-time AI processes live video streams frame-by-frame through AI models with strict latency targets. Unlike batch inference (request/response), real-time AI maintains a persistent stream connection - frames flow in continuously and transformed frames flow out.

The primary framework is **ComfyStream**, an open-source ComfyUI plugin that enables developers to build real-time AI video workflows (style transfer, avatars, live effects, real-time agents). **Daydream** is the hosted reference implementation - developers can use it without running their own Gateway.

Real-time AI runs on <Badge color="purple">AI</Badge> or <Badge color="green">Dual</Badge> nodes. It uses the `live-video-to-video` pipeline type and the trickle streaming protocol instead of the REST AI Jobs API. Billing is per-second, not per-pixel.

**Port:** HTTP API on `:8935` (set via `-httpAddr`, enabled by `-httpIngest`).

[//]: # "REVIEW: Confirm whether real-time AI still accounts for roughly 72 percent of current network fees."

<CardGroup cols={2}>
  <Card title="ComfyStream" icon="wand-magic-sparkles" href="/v2/developers/build/comfystream">
    Build real-time AI video workflows with ComfyUI nodes.
  </Card>

  <Card title="Daydream" icon="cloud" href="/v2/solutions/daydream/overview">
    Hosted real-time AI video - no Gateway required.
  </Card>
</CardGroup>

### BYOC Pipelines

BYOC (Bring Your Own Container) allows any workload that can be containerised to run on Livepeer Orchestrators. The Gateway routes by capability descriptor (`image-to-image`, `depth`, `segmentation`) instead of by model name.

BYOC supports **both GPU and CPU** containers. GPU workloads (diffusion models, vision models, video-to-video) are the primary use case, but CPU-only deployments are also supported - see the BYOC CPU tutorial for a passthrough pipeline example.

**What fits well:** frame-based or stream-based workloads, custom ML models, enterprise-specific processing, novel applications (e.g. Embody AI avatars).

**What does not fit:** long-running training or fine-tuning jobs, workloads requiring large persistent state, high-latency multi-minute jobs. The network assumes short, stateless, repeatable units of work. Containers that maintain long-lived state between requests break retry and failover semantics.

<Note>
  BYOC requires a Gateway - applications cannot interact with Orchestrators directly. The Gateway handles discovery, capability matching, and payment; the Orchestrator runs your container.
</Note>

BYOC follows the same payment model as AI inference.

See <LinkArrow href="/v2/developers/build/workload-fit" label="Workload Fit" newline={false} /> to evaluate whether your workload belongs on Livepeer.

<CustomDivider style={{margin: "-1rem 0 -2rem 0"}} />

## Pipeline Matrix

Not all pipeline types are available on every node type. Use this table to confirm which pipelines apply to your setup.

<StyledTable variant="bordered">
  <thead>
    <TableRow header>
      <TableCell header>Pipeline</TableCell>
      <TableCell header><Badge color="blue">Video</Badge></TableCell>
      <TableCell header><Badge color="purple">AI</Badge></TableCell>
      <TableCell header><Badge color="green">Dual</Badge></TableCell>
      <TableCell header>On-chain ETH required</TableCell>
    </TableRow>
  </thead>

  <tbody>
    <TableRow>
      <TableCell>Video transcoding</TableCell>
      <TableCell>Yes</TableCell>
      <TableCell>No</TableCell>
      <TableCell>Yes</TableCell>
      <TableCell>Yes</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>Batch AI inference</TableCell>
      <TableCell>No</TableCell>
      <TableCell>Yes</TableCell>
      <TableCell>Yes</TableCell>
      <TableCell>No</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>Real-time AI (live-video-to-video)</TableCell>
      <TableCell>No</TableCell>
      <TableCell>Yes</TableCell>
      <TableCell>Yes</TableCell>
      <TableCell>No (off-chain) / Yes (dual on-chain)</TableCell>
    </TableRow>

    <TableRow>
      <TableCell>BYOC</TableCell>
      <TableCell>No</TableCell>
      <TableCell>Yes</TableCell>
      <TableCell>Yes</TableCell>
      <TableCell>No</TableCell>
    </TableRow>
  </tbody>
</StyledTable>

[//]: # "REVIEW: Confirm whether dual Gateways use on-chain payment for real-time AI workloads."

<Tip>
  Running both video and AI workloads from a single node is possible with a <Badge color="green">Dual</Badge> Gateway. The Gateway itself does not need a GPU - Orchestrators provide the compute. However, dual nodes manage two independent session managers simultaneously, which increases operational complexity.
</Tip>

<CustomDivider style={{margin: "0 0 -2rem 0"}} />

## Orchestrator Discovery

How your Gateway finds Orchestrators depends on your operational mode and business model. There is no single discovery pattern - most production Gateways use direct relationships instead of automatic pooled discovery.

<AccordionGroup>
  <Accordion title="On-chain discovery (automatic)" icon="link">
    On-chain Gateways query the Livepeer subgraph on Arbitrum for registered, active Orchestrators. The Gateway refreshes this list periodically and selects Orchestrators based on capability, price, latency, and stake weight.

    This is the default for on-chain Gateways and requires no manual Orchestrator configuration. Best suited for public Gateways routing to the open network pool.
  </Accordion>

  <Accordion title="Direct configuration (-orchAddr)" icon="server">
    Off-chain Gateways (and some on-chain Gateways) specify Orchestrator addresses directly using the `-orchAddr` flag. This bypasses on-chain discovery entirely.

    Most production Gateways use this pattern. Operators build relationships with specific Orchestrators who run the models and capabilities their applications need. This gives predictable performance, pricing, and availability.
  </Accordion>

  <Accordion title="Webhook discovery" icon="webhook">
    Gateways can call an external service via `-orchWebhookUrl` to receive a dynamic Orchestrator list. This enables custom filtering, whitelisting, or load balancing without modifying the Gateway itself.

    Used by platform builders (NaaP) and operators with Orchestrator tiering or geographic routing requirements.
  </Accordion>

  <Accordion title="Own orchestrators" icon="microchip">
    Some operators run their own Orchestrators alongside their Gateway. The Gateway points to these dedicated Orchestrators via `-orchAddr`. This provides full control over compute, models, and pricing.

    Common for enterprise integrators, content providers with SLA requirements, and operators running custom BYOC or real-time AI workloads.
  </Accordion>
</AccordionGroup>

<Note>
  Automatic on-chain discovery selects from the public Orchestrator pool based on capability, price, latency, and performance history. For AI workloads - especially real-time AI and BYOC - direct Orchestrator relationships are more common because applications need specific models, GPU configurations, or custom containers that not all Orchestrators provide.
</Note>

<CustomDivider style={{margin: "-1rem 0 -1rem 0"}} />

## Related Resources

<CardGroup cols={2}>
  <Card title="Video Transcoding Pipeline" icon="film" href="/v2/gateways/guides/node-pipelines/video-pipelines">
    How video jobs flow through your Gateway - ingest, segmentation, Orchestrator selection, and payment.
  </Card>

  <Card title="AI Inference Pipeline" icon="brain" href="/v2/gateways/guides/node-pipelines/ai-pipelines">
    How AI inference requests are routed - Orchestrator discovery, model matching, pipeline types, and platform limits.
  </Card>

  <Card title="BYOC Pipelines" icon="box" href="/v2/gateways/guides/node-pipelines/byoc-pipelines">
    Routing custom container workloads by capability - operator responsibilities, model fit, and health tracking.
  </Card>

  <Card title="Pipeline Configuration" icon="sliders" href="/v2/gateways/guides/node-pipelines/pipeline-configuration">
    Transcoding profiles, AI routing flags, and per-pipeline tuning.
  </Card>

  <Card title="Workload Fit" icon="bullseye" href="/v2/developers/build/workload-fit">
    Decision framework for evaluating whether your AI workload belongs on Livepeer.
  </Card>

  <Card title="Model Support" icon="microchip-ai" href="/v2/developers/build/model-support">
    Full compatibility matrix - supported pipeline types, model architectures, and VRAM requirements.
  </Card>
</CardGroup>

{/*
PURPOSE:
Journey step: "What workloads can my gateway route?"
Entry point for the AI & Job Pipelines guide section. Explains what a job pipeline
IS from the gateway operator's perspective: the control-plane path between an app
request and orchestrator execution.

Covers the three pipeline types (video, AI, BYOC), the gateway's role in each
(routing, auth, pricing policy, QoS, retries, failover), and how pipeline choice
maps to gateway type (video-only, AI-only, dual).

SECTION HOME: Guides → AI and Job Pipelines

JOURNEY POSITION:
1. Pipeline Overview (this page) - "What workloads can my gateway route?"
2. Video Transcoding Pipeline - "How do video jobs flow?"
3. AI Inference Pipeline - "How do AI jobs flow?"
4. BYOC Pipelines - "Custom containers on the network"
5. Pipeline Configuration - "Configure transcoding profiles and AI routing"

RELATED FILES (draw from):
- all-resources/v2-guidesres--overview.mdx                - PRIMARY (95%): Existing pipeline overview. 67 lines, complete. Job pipeline responsibilities, 3 pipeline types, gateway vs orchestrator roles.
- all-resources/v2-orch--job-types.mdx                    - PRIMARY (80%): 3 job categories from orchestrator POV (Transcoding, Realtime AI, Batch AI). Reframe for gateway operator.
- all-resources/v2-dev--ai-pipelines-overview.mdx          - SECONDARY (40%): 3 integration patterns (Standard API, ComfyStream, BYOC). Developer-focused but useful for pattern descriptions.
- all-resources/v2-run--transcoding.mdx                    - Placeholder (5%): Reserved page, planned structure only.

CROSS-REFS:
- Setup → Configuration (video, AI, dual) - "how to set up" vs this section's "how it works"
- Concepts → Capabilities - high-level capability overview
- Concepts → Architecture - network architecture context
- Resources → Technical Architecture - architecture diagrams
*/}