DeepSeek V4.1 Flash 1017 is live at 50% off
    InferX Platform Own your inference stack

    Your GPUs. Production inference.

    Deploy InferX inside your own infrastructure — Kubernetes, bare metal, private cloud, or GPU cloud. Fast cold starts, scale-to-zero, isolated workloads, and OpenAI-compatible APIs. Reduce inference infrastructure costs by 30–70%*.

    *Savings depend on workload patterns, model size, traffic shape, and existing GPU utilization.

    ArchitectureInstalled inside your boundary
    InferX Platform
    Runtime, orchestration, and serving, installed inside your boundary and operated on the hardware you already run.
    Consumed by
    OpenAI-compatible APIYour tools & agentsApplications
    inferx_client.py
    from openai import OpenAI
    
    # the standard client, pointed at your own deployment
    client = OpenAI(
        base_url="http://inferx.internal/v1",
        api_key="YOUR_INFERX_KEY",
    )
    
    stream = client.chat.completions.create(
        model="gpt-oss-20b",
        messages=[{"role": "user", "content": "Summarize this ticket."}],
        stream=True,
    )
    
    for chunk in stream:
        print(chunk.choices[0].delta.content or "", end="")
    Same OpenAI-compatible surface, served from inside your network
    Deploys on
    • Kubernetes
    • EKS
    • GKE
    • AKS
    • OpenShift
    • On-prem
    • Bare metal
    • Private cloud
    • GPU cloud
    01 The problem

    Owning GPUs is not the same as operating inference.

    Provisioned capacity sits idle between workloads, cold paths add latency before traffic is served, and every new model means another serving stack to operate. The hardware is not the bottleneck — the runtime is.

    Traditional inference
    ~20%

    Average GPU utilization. Models hold memory even when they aren’t serving.

    →
    With InferX
    80%

    Up to 80% GPU utilization. Capacity follows demand instead of sitting reserved.

    4×more useful work from the GPUs you already own — same hardware, more models, more concurrent workloads.
    01

    Idle GPU capacity

    Provisioned capacity waits between workloads.

    02

    Slow model activation

    Cold paths add latency before traffic is served.

    03

    Low utilization

    Useful work is separated from available hardware.

    04

    Fragmented serving stacks

    Teams operate separate serving paths per model.

    05

    Security and isolation

    Controls get harder as deployments spread.

    02
    Ownership
    boundary

    You bring the GPUs. InferX does the rest.

    Nothing moves. InferX installs inside your existing environment and operates the inference layer on top of the hardware and policies you already run.

    You bring
    • —GPU infrastructure
    • —Networking
    • —Storage
    • —Your models
    • —Your environment
    • —Infrastructure policies
    InferX brings
    • +Inference platform
    • +Secure container runtime
    • +Model serving
    • +Scheduling & orchestration
    • +Scaling & recovery
    • +Production APIs (OpenAI-compatible)

    Your infrastructure. Your models. Your data. InferX turns it into a production inference service.

    03
    The InferX
    Platform

    High-performance inference with built-in security.

    A complete inference layer, deployed on your GPUs — from the API your applications call, down to the isolation boundary beneath each workload.

    Applications & agentsYour tools and workflows
    Inference APIsOpenAI-compatible
    InferX PlatformScheduling · Lifecycle · Scaling · Recovery
    InferX Secure Container RuntimeVM-level · GPU · NCCL-level isolation
    NVIDIA GPU infrastructureYour GPUs · Your environment
    +
    Fast deployment
    +
    VM-level isolation
    +
    NCCL-level isolation
    +
    Multi-GPU support
    +
    Flexible scaling
    +
    High availability
    Secure inference down to the NCCL layer.
    Isolation beyond the traditional container boundary — enforced beneath the workload, not around it.
    04 How it works

    How InferX fits into your environment.

    A request arrives at an OpenAI-compatible endpoint inside your boundary. InferX restores model-ready state, attaches GPU capacity, serves the response, and releases the GPU when the workload goes quiet.

    Step 1 of 7

    Application requests

    A service running inside your environment calls one of your endpoints.

    05 Same platform

    One node or 1,000.

    The same inference platform operates across a single GPU server or an entire estate. Start with one, expand without migrating.

    01
    Start small
    Bring up a single node or a limited GPU pool.
    02
    Scale to the fleet
    Add capacity across the approved boundary.
    Fleet1 node

    Bare metal · Kubernetes · Private cloud · GPU cloud

    06 Why InferX

    Production inference without the limits.

    01

    Sub-second cold starts

    A snapshot-based runtime restores model-ready state instead of reloading weights from scratch.

    02

    Multi-GPU at scale

    Tensor parallelism across 2, 4, and 8 GPUs, plus data parallelism with NCCL.

    03

    Higher density

    Share GPUs across multiple models and workloads instead of reserving capacity per model.

    04

    Secure by design

    An isolated container runtime with GPU and NCCL-level protection beneath every workload.

    05

    Run anywhere

    On-prem, private cloud, or public cloud — the same platform across every environment.

    06

    OpenAI-compatible

    Integrate with your existing tools, agents, and workflows without rewriting clients.

    07 Deployment environments

    Deploy where your infrastructure already lives.

    InferX runs inside the environment you already operate. No migration, no separate control plane, no new cloud.

    Kubernetes

    EKS, GKE, AKS, OpenShift, and on-prem Kubernetes distributions.

    Bare metal GPU servers

    Dedicated GPU servers without moving existing workloads.

    Private cloud

    Keep model traffic and operations inside your own network.

    On-prem enterprise environments

    Deployment planning for regulated environments.

    GPU cloud providers

    An inference layer across rented GPU capacity.

    Restricted environments

    Reviewed during discovery where applicable.

    08
    Security &
    data control

    Your models, traffic, and infrastructure stay under your control.

    A private platform install runs entirely inside your boundary. Nothing is routed to an InferX-controlled cloud.

    ✓Data stays inside customer-controlled deployment for private platform installs
    ✓Isolated runtime per workload
    ✓Customer-owned infrastructure boundary
    ✓Customer-controlled data retention for private platform installs
    ✓Trust Center available
    View Trust Center →
    — Proof

    Built for production inference workloads.

    01

    Fast cold starts from restored runtime state

    02

    Scale-to-zero when idle

    03

    OpenAI-compatible APIs

    04

    Production endpoint experience from hosted InferX runtime

    05

    Real enterprise/private deployment conversations

    09
    Deployment
    playbook

    How deployment works.

    Deployment starts on a limited GPU pool and expands across the boundary once the runtime has been validated against your own workloads.

    01

    Discovery

    Map workloads, models, GPUs, access, and security requirements.

    02

    Pilot

    Install InferX on a limited GPU pool, alongside your existing serving paths.

    03

    Validation

    Measure cold starts, latency, utilization, and API compatibility on your own workloads.

    04

    Production rollout

    Expand across the approved deployment boundary.

    05

    Ongoing support

    Support, monitoring, upgrades, and capacity planning.

    10 Pricing shape

    Platform pricing that matches your infrastructure.

    InferX platform pricing is structured around a platform license, a deployment and support package, and cluster size or GPU footprint — so it tracks the infrastructure you actually run.

    Platform license
    Deployment & support
    Cluster / GPU footprint
    Contact Sales →
    11
    Frequently
    asked
    No. For a private platform install, models, traffic, and inference data stay inside your infrastructure boundary — InferX runs in your environment and nothing is routed to an InferX-controlled cloud. Hosted endpoints are a separate product line and are governed by our zero-data-retention policy.
    EKS, GKE, and AKS, plus OpenShift and on-premises Kubernetes distributions. Support for a specific distribution and version is confirmed during discovery.
    Yes. InferX deploys directly onto dedicated GPU servers as well as Kubernetes, so existing workloads don’t need to move in order to be served.
    It depends on cluster access, networking, and model readiness — those are the variables that set the schedule, not the install itself. A pilot begins on a limited GPU pool and expands only after validation. The deployment playbook above covers the sequence.
    No. InferX runs alongside existing serving paths and exposes OpenAI-compatible APIs, so applications can move over incrementally rather than in a single cutover.
    NVIDIA GPUs. Multi-GPU configurations are supported, including tensor parallelism across 2, 4, and 8 GPUs and data parallelism with NCCL.
    Pricing depends on how you run inference. Hosted endpoints use model-specific pay-per-usage pricing; dedicated and on-premises deployments are structured around a platform license, a deployment and support package, and cluster size or GPU footprint.
    Yes. Hosted InferX endpoints expose the same OpenAI-compatible API surface as a private platform install, so teams can build and validate against them before a deployment is scheduled.
    Next step

    Turn your GPU capacity into a production inference platform.

    Tell us what you’re running today — clusters, GPU types, and the models you need in production. We’ll map the deployment.

    Talk to the Platform Team →