Korab CenajEngineering case study All case studies

Public engineering project · Hosted CI and four-image pipeline verified 23 July 2026

Heterogeneous GPU Inference Orchestrator

A queue-based inference platform that routes vision work toward an Intel OpenVINO worker and language-model work toward an AMD Vulkan worker while keeping API state, model storage, metrics, and hardware-validation boundaries explicit.

Project type
Distributed Application Platform
Domain
Reliability and operations
Language
Python / TypeScript
Status
Validated

Executive summary

Operational problem

Heterogeneous GPUs do not share one runtime, workload shape, or scheduling contract. A useful platform has to route jobs by capability, retain job state, expose progress and failure, isolate model artifacts from images, and avoid claiming hardware performance that hosted CI cannot prove.

Implemented solution

A React dashboard submits work to a FastAPI gateway backed by PostgreSQL. Celery dispatches jobs through Redis to separate vision and LLM queues; the workers select OpenVINO, Vulkan, or documented CPU fallbacks. Prometheus and Grafana cover service signals, while Compose and Kustomize describe local and Kubernetes deployment paths.

Outcome

The latest public commit passed GitHub Actions for four API/queue contract tests, Python lint and compilation, the frontend build, Compose validation, and Kustomize rendering. A separate successful matrix built and published four container images. GPU execution, model provenance, throughput, multi-user security, and a live Kubernetes rollout remain outside the verified result.

Technical and operational context

The project connects API design, asynchronous orchestration, persistence, heterogeneous compute, container builds, Kubernetes configuration, observability, and evidence-led release boundaries in one reviewable system.

Architecture

The control plane separates request handling, durable job state, queue dispatch, and status events from the device-specific data plane. Vision jobs target an Intel/OpenVINO worker, LLM jobs target an AMD/Vulkan worker, model files remain on runtime volumes, and metrics feed an operator dashboard.

  1. React operations dashboard
  2. FastAPI gateway
  3. PostgreSQL job state
  4. Redis and Celery dispatch
  5. Vision / LLM queue split
  6. Intel OpenVINO worker
  7. AMD Vulkan worker
  8. Prometheus and Grafana

Architecture visual

Heterogeneous inference architecture with React and FastAPI, PostgreSQL job state, Redis and Celery queues, Intel OpenVINO and AMD Vulkan workers, runtime model volumes, and Prometheus and Grafana

The control plane, device-specific worker paths, observability, and hosted-CI evidence boundary for the public inference-platform project.

Read the diagram notes

Implementation

A React dashboard submits work to a FastAPI gateway backed by PostgreSQL. Celery dispatches jobs through Redis to separate vision and LLM queues; the workers select OpenVINO, Vulkan, or documented CPU fallbacks. Prometheus and Grafana cover service signals, while Compose and Kustomize describe local and Kubernetes deployment paths.

Key decisions and trade-offs

Capability queues instead of a generic worker pool

Separate vision and LLM queues keep device assumptions and failure modes visible. The trade-off is more deployment configuration and explicit capacity planning for each worker class.

Runtime model volumes instead of model-filled images

Images stay smaller and model acquisition remains an operator decision. Deployments must separately verify model provenance, hashes, licensing, availability, and persistent-volume behavior.

Hosted contract checks separate from hardware proof

CI validates routing, API behavior, frontend compilation, configuration rendering, and image construction without downloading models or pretending hosted runners contain the target GPUs. Hardware execution needs a separate signed benchmark and rollout record.

Security, reliability, and observability

Explicit runtime secrets

Kubernetes deployment requires an operator-created Secret; repository manifests do not contain deployable passwords. Shared environments still need an approved secret-management controller.

Constrained GPU workers

Worker containers disable privilege escalation and drop Linux capabilities while mounting only the required render devices. Host device groups remain a trusted deployment boundary.

Least-privilege automation

The validation workflow has read-only repository permissions, while the image workflow receives package-write permission only for publishing its matrix outputs.

Infrastructure concepts demonstrated

Published evidence

Public CI boundary

Sanitized live output
GitHub Actions CI: passed
hosted API/queue tests: 4 passed
live-cluster smoke tests: 3 present, opt-in, not counted
frontend build: passed
Compose and Kustomize validation: passed
container image matrix: 4 passed
GPU runtime and throughput benchmark: not recorded

Validation

Checks shown here are project-specific; no portfolio-wide claim is applied automatically.

Evidence and links

Links are limited to public-safe source material and sanitized evidence. Credentials, state, plans, identifiers, private topology, and backup contents are intentionally excluded.

Project repository

API, workers, frontend, Compose, Kubernetes, monitoring, tests, and release workflows.

Architecture notes

Control-plane, worker, model-storage, observability, and evidence boundaries.

Validation workflow

Hosted API tests, lint, frontend build, Compose validation, and Kustomize rendering.

Lessons learned

Limitations

  • No live Intel or AMD GPU execution, model-quality result, throughput benchmark, or Kubernetes rollout is claimed from the hosted checks.
  • The API has no production authentication, authorization, tenant isolation, rate limiting, or reviewed TLS ingress and must not be exposed as a shared service.
  • Kubernetes manifests use mutable image tags and a lab storage assumption; signed digest promotion and cluster-specific storage review remain future work.
  • The current CI dependency audit covers the API requirements only, and a transitive diskcache advisory in the LLM stack has no fixed release.
  • Model sources, hashes, licenses, and supply-chain policy require operator review before any non-lab deployment.

Next improvement

Record a reproducible Intel/AMD hardware benchmark and promote signed immutable images only after full worker dependency audit, model provenance checks, authentication, TLS, and a reviewed live rollout.