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.
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.
React operations dashboard
FastAPI gateway
PostgreSQL job state
Redis and Celery dispatch
Vision / LLM queue split
Intel OpenVINO worker
AMD Vulkan worker
Prometheus and Grafana
Architecture visual
The control plane, device-specific worker paths, observability, and hosted-CI evidence boundary for the public inference-platform project.
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.
Routes vision and LLM jobs to separate Celery queues and worker contracts
Persists job state and exposes health, metrics, and real-time status events
Selects OpenVINO, Vulkan, or bounded CPU fallbacks without presenting them as equivalent performance
Keeps model weights on runtime volumes instead of embedding them in container layers
Provides Compose and Kustomize deployment descriptions with explicit Secret and GPU-node prerequisites
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
Deployments and StatefulSets
Kustomize
Node affinity
GPU device mounts
PersistentVolumeClaims
Secrets
Health probes
Prometheus metrics
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.
Latest GitHub Actions CI run passed on 23 July 2026
Four hosted API and queue-routing tests passed; three live-cluster smoke tests remain opt-in and were not counted as hosted evidence
Ruff lint, Ruff formatting check, and Python compilation passed for service and test code
React and TypeScript frontend built from a clean npm installation
Docker Compose configuration and Kubernetes Kustomize rendering passed
A separate successful matrix built and pushed API, vision-worker, LLM-worker, and frontend images
The current CI audits the API dependency set; full vision and LLM dependency auditing remains incomplete
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.
Deployment scope, reporting path, and current dependency exception.
Lessons learned
Heterogeneous compute is a scheduling and evidence problem as much as a device-access problem.
Queue contracts keep device-specific failures from leaking into one opaque worker pool.
A successful container build proves packaging, not model correctness, hardware acceleration, or production readiness.
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.