SaoudYahya

A self-hosted, on-premise machine learning platform for the College of Computing, built on Kubernetes and reconciled by ArgoCD across seven namespaces that cover the whole ML lifecycle: data pipelines, notebooks, experiment tracking, distributed training, model registry and serving. Everything a researcher needs, without a cloud bill.

7

GitOps-managed namespaces

5

core services integrated

Per-user

IAM scoping and isolation

• Platform services. Apache Airflow on the KubernetesExecutor, MLflow v3 as the experiment tracker and model registry, MinIO for object storage, and JupyterHub with per-researcher IAM scoping and namespace isolation.
• Training at scale. Ray clusters for distributed workloads and FLAML for AutoML and hyperparameter search, so a researcher can go from a notebook to a multi-node job without leaving the platform.
• Observability everywhere. Prometheus and Grafana with custom ServiceMonitors for Airflow, MLflow, MinIO, Ray and the serving pods; logs shipped remotely to MinIO.
• GitOps from day one. Every namespace, chart and secret reference lives in Git and ArgoCD keeps the cluster matching it.

Internal platform; no public repository.

A production-style MLOps pipeline on Azure Kubernetes Service that forecasts electricity demand. Airflow pulls fresh data from the EIA API every week, Pandera validates it before anything downstream sees it, MinIO stores it, and the training and forecasting steps run as Kubernetes jobs. More than 95% of the workflow needs no human touch.

95%+

of the workflow automated

Weekly

scheduled data extraction

AKS

Azure Kubernetes Service

• Validated at the door. Pandera schemas reject bad rows from the API before they can poison a training run.
• Orchestrated, not scripted. Every stage is an Airflow task with retries, alerts and lineage.

Eight microservices in Java and Go talking over Kafka behind an Istio mesh, with a Next.js storefront and a React admin dashboard. Everything is declared in Terraform and Helm and reconciled by ArgoCD, so a deploy is a merged pull request and the whole environment stands up from one command.

8

microservices

70%

fewer client API calls

<200 ms

response time

1

command to deploy

• GitOps end to end. ArgoCD watches a dedicated deployment repo; rollouts are zero-downtime and every change is a reviewed diff.
• Event-driven. Services publish to Kafka instead of calling each other, which is where the 70% cut in client-facing traffic came from.
• Portable. The same charts run on a local kind cluster and on EKS, so the production migration was configuration, not a rewrite.
• Observable from sprint one. Prometheus and Grafana for metrics, ELK for logs.

Four services in Go and Java pull articles from RSS and NewsAPI, run a custom Naive Bayes sentiment model, and stream high-confidence signals to clients over WebSockets. FluxCD reconciles the cluster and Flagger runs every release as a canary against ten-plus quality gates before it takes real traffic.

45 ms

per-article processing

10+

canary quality gates

0.8+

signal confidence threshold

15–17

EKS nodes, Terraform-managed

• Progressive delivery. Flagger shifts traffic in steps and rolls back automatically when latency or error metrics slip.
• Infrastructure as code. EKS, four RDS PostgreSQL databases, ElastiCache Redis and an S3 data lake, all in Terraform.
• One pipeline per service. Jenkins builds the image, pushes to Docker Hub and opens the GitOps pull request.
• Mesh observability. Kiali for the service graph, Prometheus and Grafana for the numbers, Flagger's own metrics per rollout.

Twenty screenshots of the cluster, mesh and pipelines

Three Flask services, each wrapping a different model: an LSTM fake-news classifier, an S&P 500 prediction pipeline, and GPT-2 text generation. Each is containerised, deployed with kubectl, scaled independently and watched through Prometheus and Grafana, so "is the model still up and how fast is it answering?" has a dashboard instead of a guess.

• Independent scaling. Replicas and resource limits sized per model, not one setting for all three.
• Metrics from day one. Latency and error rates exported from each service and graphed in Grafana.
• Fault tolerant. Liveness and readiness probes restart or withhold traffic from unhealthy pods.

A loyalty and rewards backend split into services behind a Spring Cloud API gateway. Eureka handles discovery and load balancing, RabbitMQ carries asynchronous work, Zipkin traces a request across every hop, and Jenkins builds and ships each service.

• Service discovery and gateway routing so services find each other without hard-coded addresses.
• Distributed tracing with Zipkin, which turns "it's slow somewhere" into a specific span.
• Jenkins pipelines from commit to container for every service.

Named-entity recognition usually needs a large hand-annotated corpus per domain, which for biology literature runs to tens of thousands of dollars and months of expert time. This work learns animal entities and their relationships directly from unlabelled PDFs using contrastive objectives and an aggressive filtering stage, and outperforms a BERT baseline on the same task.

• No annotation budget. The model builds its own training signal from document structure and co-occurrence.
• Strict filtering drops low-confidence candidates so precision stays high without a human in the loop.
• Generalises because nothing in the pipeline is specific to animal names.

Sixteen configurations from 13.1M to 597.3M parameters, comparing how dense and sparsely-activated architectures scale, then sparse autoencoders to look at what the models learned. The two families scale with opposite-signed coefficients, and Switch-Large reached the best perplexity of the study.

16

model configurations

597M

largest model, parameters

120.91

best perplexity, Switch-Large

• Architecture-dependent scaling. Coefficients of −0.0381 for dense and +0.0173 for Switch on the same data.
• SAE-based superposition analysis with a scoring method that gives consistent sparsity patterns across sizes.
• Practical output: guidelines for picking an architecture when compute is the constraint, plus an open framework to reproduce the runs.

Glasses with a camera, a phone app, and a containerised backend for visually impaired users. YOLOv9 detects objects, a ViT-GPT2 model captions the scene, Whisper transcribes the wearer's questions, and the answer comes back as speech. Recognised with accessibility innovation awards.

• Two backends, one API shape. A Flask prototype and a faster FastAPI service with faster-whisper.
• Hardware plus software. The companion app talks to the glasses and to the inference server.

Takes an ordinary drone video, estimates a depth map for each frame with MiDaS, recovers the camera's path, and blends the frames into a navigable 3D terrain in the browser. Draw a flight path over the terrain, adjust its height and angle, and fly it in first-person or follow mode.

• Frame blending smooths transitions between depth maps so the terrain reads as one surface.
• Four render modes: mesh, point cloud, hybrid and wireframe, with a live performance readout.

A content generation system where a graph of agents decides what to retrieve, when to retrieve more, and when to answer. Retrieval runs against a vector database, orchestration lives in LangGraph, and the whole thing ships as containers so it scales horizontally.

• Agents that plan. Routing and retry decisions are explicit graph nodes, not hidden in a prompt.
• Context management keeps retrieved material relevant and inside the model's window.