Edge Deployment

Intelligence at the source. Zero cloud dependency.

Edge deployment means your AI models run where the cameras are — on a device bolted to the wall, mounted in a rack, or embedded in the machine itself. No video leaves your facility. No inference waits for a round-trip to a data centre. No uptime depends on someone else's internet connection.

Athena AI builds computer vision systems engineered from the ground up for edge hardware. Not cloud models squeezed onto a Jets demot demo-grade pipelines that fall apart under sustained load. Production-grade inference, optimised for the specific hardware you're deploying, tested against your actual environment before anything ships.

Why edge over cloud

Cloud-based computer vision is the right choice for some workloads. It's the wrong choice for most operational deployments. Here's the honest comparison:

What you actually get

Where this deploys

• Manufacturing & Robotics. Visual inspection, worker safety zones, AGV navigation, assembly-line defect detection, PLC integration. Sub-50ms latency on Jetson Orin AGX. Deterministic enough for safety-critical actuation.
• Retail & Commerce. Customer flow, dwell-time analytics, loss prevention, self-checkout verification. Low-power Jetson Orin Nano at the shelf or entrance. On-device anonymisation before any data moves.
• Sports & Broadcast. Player and ball tracking, automated highlight detection, biomechanics. Multi-stream on Orin AGX or GPU server. 60fps trajectory smoothness without cloud round-trips.
• Healthcare & Clinical. Patient monitoring, fall detection, equipment localisation. Air-gapped Orin AGX. HIPAA/PHIPA compliance by architecture — no video leaves the clinical environment.
• Security & Surveillance. Perimeter intrusion, cross-camera tracking, audit-grade event logging. On-premise GPU server or Orin AGX cluster. Full pipeline behind a one-way network diode where required.
• Logistics & Warehousing. Dock door monitoring, AGV safety, pallet detection, vehicle tracking. Orin NX or AGX depending on camera count. Integrates with WMS and TMS via event streaming.

Why Athena AI

Edge-first by design

Every system we build is architected for the hardware it will run on. We don't start with a cloud model and try to make it fit. We start with your hardware, your latency requirement, and your camera count, and engineer backward from there.

Proven on real edge deployments

The LEGO sorting system we built for Canada First Bricks runs entirely on NVIDIA Jetson Orin — 96.3% accuracy across 300+ part types, 3,600 parts per hour, sub-100ms end-to-end latency including PLC actuation. No cloud. No human in the loop. That's the standard we hold production deployments to.

Optimisation is the work, not the afterthought

Going from a T4 (320 TOPS) to a Jetson Orin Nano (40 TOPS) is not an 8× slowdown if you architect for it. With correct TensorRT quantisation, model selection, and pipeline tuning, it's 1.2–2×. We do this work. We don't ask you to.

Reference work

Ready to see what this looks like on your hardware?

A discovery call is a one-hour technical conversation against your actual environment — your hardware, your camera count, your latency requirement, your integration surface. We don't pitch. We benchmark. By the end you know whether edge deployment is the right architecture for your operation, and we know whether we can deliver against your requirements.

Book a Discovery Call →

Edge deployment is a hardware-software co-design problem. The choice of Jetson variant, the model architecture, the quantisation strategy, the pipeline topology, and the integration surface are all decisions that interact. Getting any one of them wrong produces a system that performs in a proof-of-concept and degrades under sustained production load.

This tab covers the full stack: hardware selection, the inference optimisation pipeline, the six-stage CV pipeline as it runs on edge hardware, and the deployment topologies we use in production.

Hardware selection

The right hardware is determined by stream count, latency budget, power envelope, and integration requirements. The wrong hardware produces either an over-engineered system that costs more than it should or an under-provisioned system that throttles under real load.

Latency reference: cloud vs. on-prem vs. edge

The inference optimisation pipeline

A model that runs at 30fps in PyTorch may run at 90fps after TensorRT optimisation on the same hardware. The optimisation pipeline is not optional — it's what makes edge deployment viable at production throughput. Here's what we apply, in order:

Combined effect: a YOLOv11-m model running at FP32 in PyTorch on an Orin AGX achieves approximately 35fps on a 1080p stream. After TensorRT FP16 + layer fusion + CUDA stream pinning, the same model achieves 90–110fps. The accuracy delta is less than 1% mAP on your calibration set.

We don't apply optimisation uniformly — each technique has a calibration cost and a latency/accuracy tradeoff. We benchmark each step against your footage and your accuracy threshold before committing to the production configuration.

The CV pipeline on edge hardware

The same six-stage pipeline from our Real-Time Tracking architecture applies here — Detection, Association, Motion Modeling, Re-ID, Cross-camera Handoff, Sensor Fusion — with edge-specific constraints at each layer.

Detection (Layer 1)

Default: YOLOv11 variant selected by hardware budget and throughput target. On Orin Nano: YOLOv11-n/s at INT8, 40–60fps. On Orin AGX: YOLOv11-m/l at FP16, 60–110fps. RT-DETR for transformer-based scenes where global context matters and the hardware budget allows (Orin AGX only — too expensive for Nano/NX).

Edge-specific constraint: anchor-based models (YOLO) are more edge-friendly than anchor-free transformers at equivalent accuracy because their compute graph is more amenable to TensorRT fusion. We choose transformer architectures only when scene density justifies the cost.

Association (Layer 2)

Default: ByteTrack — correct choice for edge because it handles partial occlusions without the re-ID embedding extraction cost that DeepSORT requires. On constrained hardware, removing embedding extraction at the association stage doubles throughput.

When we substitute: StrongSORT or BoT-SORT when re-ID quality justifies the cost (available on AGX, not recommended on Nano). OC-SORT for sports and non-linear motion on AGX.

Motion modeling (Layer 3)

Default: Kalman filter with constant-velocity assumption, tuned per class. Lightweight enough to run on any Jetson variant without GPU allocation — runs on the ARM CPU cores while the GPU handles detection.

Re-ID and cross-camera handoff (Layers 4–5)

On edge hardware, re-ID embedding extraction is the most expensive optional operation in the pipeline. On Orin Nano, we disable it for single-camera deployments entirely — the throughput gain outweighs the accuracy cost in most scenes. On Orin AGX, we run OSNet embeddings at a reduced frame rate (every 5th frame) to maintain re-ID capability at production throughput.

Cross-camera handoff on edge hardware uses homography-based handoff where cameras share a calibrated ground plane (cheaper, deterministic) and feature-based re-ID only where it's architecturally necessary and the hardware budget permits.

Sensor fusion (Layer 6)

BLE / BLE AoA, UWB, RFID, LiDAR, and PLC sensor signals can all be fused on-device. Late fusion (separate trackers, combine outputs) is the standard choice on edge — it's modular and doesn't require tight sensor synchronisation. Tight fusion is available on AGX for deployments where sensor timing is well-controlled and marginal accuracy improvement justifies the engineering cost.

Deployment topologies

Standalone edge node

Single Jetson AGX or NX processing all cameras locally. Output (events, tracks, alerts) delivered via MQTT or REST to downstream systems. Appropriate for single-site deployments up to 8 cameras. Zero cloud dependency. Full data sovereignty.

Edge node + on-prem aggregation

Multiple edge nodes (one per zone or per building) feed a central on-prem GPU server that aggregates events, maintains a global track database, and handles cross-camera re-ID. Each edge node processes its cameras independently; the aggregation layer handles identity continuity across nodes. Right for multi-zone facilities with 8–50+ cameras.

Hybrid (edge + VPC)

Edge nodes handle inference and event generation. A VPC-hosted aggregation layer stores events, runs analytics, and serves dashboards. Video never leaves the site. Only compressed event data transits to the VPC. Bandwidth: under 1 KB/event vs 8 Mbps per raw stream — three orders of magnitude cheaper.

Air-gapped

Full pipeline behind a one-way network diode. No outbound connectivity. Model updates delivered as signed packages on physical media or via a controlled inbound channel. Right for clinical environments, defence, and any regulated facility where no outbound network is permitted.

One architecture, six operational profiles

The hardware and optimisation choices differ by vertical. The underlying CV pipeline is the same system.

[Request Architecture Review →]   [Talk to an Engineer]

Deploying a model on a Jetson is day one. Keeping it accurate, thermally stable, secure, and up to date across a fleet of devices in real environments — that's the actual work. This section covers how Athena AI-built edge systems operate in production.

Fleet management and model updates

OTA model updates.

Models are versioned, signed, and deployed over-the-air to the device fleet via a secure update channel. Canary rollout: new model runs in shadow on a subset of devices, accuracy metrics compared against the production model, promotion gated on regression checks. Rollback is one command.

Air-gapped update path.

For fully air-gapped deployments, model updates are delivered as signed packages on physical media or via a controlled inbound channel (one-way diode). The device verifies the package signature before installation. No manual model file copying. No unsigned updates accepted.

Fleet health monitoring.

Every device reports heartbeat, GPU utilisation, temperature, FPS, and current accuracy metrics at configurable intervals. A central monitoring service (self-hosted or VPC-hosted) aggregates these signals. Alerts fire on: device offline, GPU throttling detected, accuracy drift past threshold, temperature above safe operating range.

Remote diagnostic access.

Secure SSH tunnel or VPN-based remote access for diagnostics and configuration, scoped by role. Air-gapped devices use an out-of-band management network. All access events logged to an immutable audit trail.

Thermal management

Thermal behaviour under sustained load is one of the most common causes of silent performance degradation in edge deployments. An Orin AGX running at full load in a warm industrial environment can throttle within 20 minutes without correct thermal design.

• Hardware: active cooling (fan, heat sink) specified per environment. Industrial environments may require sealed enclosures with external heat exchangers.
• Power mode selection: NVIDIA Jetson supports configurable power modes (5W to 60W on AGX). We select and lock the power mode at deployment, not at demo.
• Thermal monitoring: on-device temperature sensors monitored continuously. Throttle events logged. Alert fires before performance degrades below SLA.
• Load testing: every deployment is stress-tested at sustained full load for 4+ hours before production sign-off. We benchmark thermal steady-state, not burst performance.

If an environment requires sealed enclosures, we specify the enclosure and thermal solution during architecture review — not after the device is installed.

MLOps and drift handling

Drift detection

Per-device accuracy is monitored continuously via sampled frame evaluation. mAP, IDF1, and ID-switch rate are alerted on when they drift past threshold. The alert fires before the customer notices — not after two weeks of silent degradation. Common drift causes on edge: lens fouling, repositioned cameras, seasonal lighting changes, new object classes entering the scene.

Retraining pipeline

Drift alerts trigger a retraining cycle. New training data is sourced from the device (active learning: model surfaces low-confidence frames for human labelling) or from customer-side annotation. Retrained models pass regression checks before promotion. The retraining pipeline is part of the initial deployment scope — not something added later when things go wrong.

Observability

Per-device dashboards: FPS, GPU utilisation, temperature, detection count, track count, ID-switch rate, confidence score distribution, drift alert history. Metrics exported to Prometheus, Datadog, or OpenTelemetry. Logs structured for ingestion into your existing observability stack.

Integration surface

• Event streaming: MQTT, Kafka, or NATS. Per-track lifecycle events (track_start, track_update, track_lost, zone_enter, zone_exit). JSON or Protobuf schemas. Configurable event filtering — push only meaningful events, not every detection.
• Synchronous query: REST and gRPC for current track state, historical trajectory retrieval, and ad-hoc queries.
• PLC integration: Modbus RTU/TCP for real-time actuation signals. Deterministic output path tested end-to-end under sustained load before production sign-off.
• Downstream sinks: SIEM (Splunk, Sentinel, Elastic), data warehouses (Snowflake, BigQuery, on-prem Postgres / ClickHouse), BI tools (Grafana, Superset).
• SDKs: Python, TypeScript, C++. OpenAPI spec, gRPC service definitions, and example clients shipped with every deployment.

Security and data architecture

• Data residency: all inference on customer hardware. No video leaves the device unless you explicitly configure egress.
• Encrypted storage: model weights and event logs encrypted at rest (AES-256, customer-managed keys).
• Encrypted communications: mTLS between edge device and aggregation layer. TLS 1.3 for all external API endpoints.
• Model signing: every model update cryptographically signed. Devices reject unsigned updates.
• RBAC: role-based access to device management console, event data, and model update pipeline.
• Audit logging: every model update, every remote access event, every configuration change logged to an immutable store.
• Air-gapped operation: full pipeline with no outbound network. Update channel via signed packages only.
• Compliance frameworks: HIPAA, PHIPA, GDPR, SOC 2. Specific control mappings available during architecture review.

Build vs buy

What a 6-month internal build looks like

A capable ML team can run a YOLOv11 model on a Jetson and get reasonable results in two weeks. TensorRT optimisation, thermal management, OTA update infrastructure, fleet monitoring, drift detection, and PLC integration are the other 22 weeks. Hidden costs: CUDA expertise, TensorRT calibration, the operational discipline to manage a device fleet in the field.

Where building makes sense

When edge computer vision is a core product differentiator — a robotics OEM, a sports analytics platform, an industrial automation company — and you intend to invest in a permanent embedded CV team. The build amortises.

Where buying makes sense

When edge vision is an enabling capability for a broader product. The build does not amortise, and the ongoing operational cost of maintaining a production edge fleet in-house exceeds the engagement cost of a specialised partner. We've also been hired to take over internal builds that stalled at the optimisation and operations layer.

What we won't do

• Deploy face recognition in jurisdictions without explicit legal basis.
• Ship a model we haven't benchmarked on your hardware at sustained production load.
• Quote latency numbers we haven't measured on your device with your footage.
• Lock you into proprietary device management software or model formats — you own the hardware, you own the models, you own the weights.
• Ignore thermal management and call it 'out of scope.'

Engagement model

Engagements start with a paid technical discovery: 2–4 weeks against your real hardware, your real footage, your real integration surface. By the end you have a hardware specification, a benchmarked accuracy and latency baseline, a thermal assessment, and a go/no-go decision based on actual numbers.

Production engagements run on milestone-based contracts with defined acceptance criteria: accuracy threshold, latency SLA (p99 at sustained load), and thermal steady-state confirmation. Ongoing operations (fleet monitoring, OTA updates, retraining, on-call) run as a separate retainer scoped to your device count and SLA requirements.

[Request Architecture Review →]   [Book a Discovery Call →]