ome-projects/ome

[ENHANCEMENT] Integrate KEDA operator to enable advanced autoscaling in OME

Open

#155 geöffnet am 9. Juli 2025

Auf GitHub ansehen
 (2 Kommentare) (6 Reaktionen) (1 zugewiesene Person)Go (81 Forks)github user discovery
featurehelp wanted

Repository-Metriken

Stars
 (463 Stars)
PR-Merge-Metriken
 (PR-Metriken ausstehend)

Beschreibung

What would you like to be added?

Support for integrating the KEDA operator to enable advanced, custom metrics-based autoscaling for OME-managed LLM workloads.

Why is this needed?

Current OME lacks native support for autoscaling based on custom or external metrics. Integrating KEDA will allow OME to:

  • Dynamically scale model-serving workloads in response to real-time demand.
  • Optimize GPU and compute resource costs by scaling pods up and down automatically.
  • Support a wider range of scaling triggers beyond standard CPU/memory metrics (e.g., Prometheus queries, external event sources).
  • Improve latency and reliability for LLM inference during traffic spikes. This enhancement would provide greater flexibility and operational efficiency for enterprise users deploying LLMs at scale.

Completion requirements

  • Design doc (if significant feature)
  • API change
  • Docs update
  • Tests

Can you help us implement this enhancement?

  • Yes, I can contribute
  • No, but I'm available for testing
  • No

Contributor Guide

Research-Richtung
Studieren Sie die KEDA Operator Dokumentation und die bestehende Kubernetes Integration von OME. Identifizieren Sie die benutzerdefinierten Metriken, die für LLM Workloads benötigt werden, und implementieren Sie einen KEDA Scaler oder stellen Sie ein KEDA ScaledObject bereit. Stellen Sie sicher, dass das HPA Scaling mit KEDA zusammenarbeitet. Schreiben Sie Tests und aktualisieren Sie die Dokumentation.
Tech Stack
gokubernetes
Domain
backendinfrastructure
Issue Type
Funktion
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
3-5 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
GoKubernetes
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
45