Skip to main content

EDGE AI INFRASTRUCTURE

Bring AI applications to production hardware faster

Production-ready Linux, supported accelerators, prebuilt AI packages, and repeatable deployment workflows, so AI workloads move from development into the field.

A trusted partner to

The gap

Prototypes don't survive the move to production

The hard part of edge AI is not getting a model to run once. It is keeping that workload buildable, shippable, and updatable on hardware you do not control.

Prototype environment

Vendor SDKs and desktop distros get a demo running fast, then stop being the thing you can ship.

The image

A vendor BSP you can't rebuild

The SDK image that made the demo work was flashed once. Nothing records how it was built, so nobody can reproduce it.

The AI stack

Libraries pinned by hand

Runtimes, drivers, and Python packages installed by hand on whichever machine was nearby. Every box drifts from the last.

The lifecycle

No path after the demo

No way to get a better model onto a device already in service, and OS maintenance and CVE response land on your team.

Production reality

Avocado gives the same workload a maintained base you can build, ship, and update.

The image

One declarative build

The same configuration produces the same image on every machine, including the one that builds your release.

One image

The AI stack

The stack is part of the image

Declare the accelerator runtime and the AI libraries beside the rest of the system. The build resolves them once and records the result.

Dependencies

The lifecycle

Updates are a service

Ship models and applications over the air from Connect, on a base that someone else patches.

In the field

Supported hardware

From a 0.5 TOPS microNPU to a 275 TOPS Jetson

Pick the silicon your product needs. Every target below builds from the same declarative configuration and the same CLI. There is no per-vendor toolchain to stand up first.

NVIDIA Jetson
NXP i.MX
Renesas RZ
Synaptics
  • NVIDIA

    Orin Nano

    67 TOPS · Ampere GPU, 1024 CUDA cores

  • NVIDIA

    Orin NX

    100 TOPS · Ampere GPU, 1024 CUDA cores

  • NVIDIA

    Jetson AGX

    275 TOPS · Ampere GPU, 2048 CUDA cores

  • NXP

    i.MX 8M Plus

    2.3 TOPS · Integrated NPU

  • NXP

    i.MX 93

    0.5 TOPS · Arm Ethos-U65 microNPU

  • NXP

    i.MX 95

    eIQ Neutron NPU

  • Renesas

    RZ/V2H

    Integrated AI accelerator

  • Synaptics

    Grinn AstraSOM-1680

    Integrated NPU

No board yet? Build against QEMU (virtual), then change one line to a real target.

View all supported hardware

Dependencies

Use the libraries and packages your workload needs

Declare the AI stack alongside the rest of the system. The build resolves it once, records it in the image, and produces the same result on every machine.

Declare once

Put the AI stack and the rest of the workload in one manifest.

Resolve at build

The build pulls from pinned feeds and records what landed in the image.

Same everywhere

Every machine gets the same resolved result, no device-side installs.

One image

Build on the same image you ship

Local iteration and the production artifact are the same declarative build. The AI stack your application was developed against is the one that boots in the field.

One declarative build

Declared in one config, not assembled by hand on each machine. How Avocado OS builds the image

Reproducible months later

Packages resolve from pinned feeds, so the same config rebuilds the same image.

Bench hardware is ship hardware

Flash the signed image to your dev kit, then to the units you ship.

01

Declare the workload

Name the accelerator, the AI packages, and your application. Nothing about the stack is left to a machine’s history.

Local to hardware
$ avocado install
avocado build
avocado provision
02

Build it, then run it on hardware

Three commands take the declared config to a signed image, then onto the dev kit in front of you.

03

Update it in the field

Models and applications move over the air, and only the layer that changed gets pushed. See how Connect ships updates

In the field

Deploy and operate AI workloads after launch

A model that improves is only useful if you can get it onto hardware already in service. Peridio Connect handles the rollout, the segmentation, and the access.

01

Model and application updates

Ship a new model or a new application version without rebuilding and reflashing the whole system.

avocadoconnect uploaddone

Composed image

Application + modelchanged
CUDA · TensorRTunchanged · deduplicated
Avocado OS baseunchanged · deduplicated
100%

Device partitions · A/B

Slot A

v1.2.2

standby

Slot B

v1.2.3

active

02

Fleet segmentation

Roll out to a cohort first (canary, staging, then production) instead of every device at once.

avocadoconnect deploydone
canarypromoted
stagingpromoted
production100 devices
03

Rollout visibility

Watch an update land device by device, and stop or roll back when a cohort reports trouble.

rollout · v1.2.3done
v1.2.3production
Rollout complete
  • dev-01

    Updated

  • dev-02

    Updated

  • dev-03

    Rolled back

  • dev-04

    Updated

04

Remote diagnostics

Open a tunnel to a specific device to inspect a failing inference run on the hardware it happened on.

avocadoconnect tunneldone

Secure session

youedge-cam-04
Device
edge-cam-04
Target
jetson-orin-nano
Tunnel
wireguard · encrypted
Session
logged
Fault
/dev/video0 busy