Fallstudie | CETC Cloud baut mit HAMi eine gemeinsame Ressourcenbasis für heterogene GPUs für eine portable Wissensdatenbank
CETC Cloud (Beijing) Technology betreibt Produktionsmodelle für Textgenerierung, Embedding und Rerank zusammen mit Kubernetes-Entwicklungsumgebungen auf einem einzigen portablen Gerät mit 8 heterogenen GPUs – die Kapazität steigt von 2 auf 30 gleichzeitige Dev-Pods.
Kundenübersicht
CETC Cloud (Beijing) Technology musste seine intelligente Wissensdatenbank zu Projektstandorten bringen – mit Textgenerierung, Embedding, Rerank, Wissensverarbeitung und Entwicklungsaufgaben auf einem Satz portabler Geräte mit heterogenen GPUs. Mit Kubernetes und HAMi wurden diese GPUs, bisher langfristig an einzelne Dienste gebunden, zu Ressourcen, die Produktionsmodelle und Entwicklungsumgebungen bedarfsgesteuert anfordern, teilen und schedulen können.
Portable Appliance für intelligente Wissensdatenbank, eigenständig vor Ort betreibbar
Produktionspipeline und Entwicklungsumgebungen auf einem 8-GPU-Gerät
Kubernetes-native Ressourcendeklaration plus HAMi-GPU-Sharing und einheitliches Scheduling
CETC Cloud (Beijing) Technology Co., Ltd.
Cloud- und Intelligent-Computing-Marke der CETC – verantwortlich für Produktentwicklung und Engineering der portablen Wissensdatenbank: lokaler Betrieb vor Ort, Wissensverarbeitung, Modell-Serving und Entwicklungsumgebungen.
Fallinformationen
Dieser Fall basiert auf der offiziellen CNCF Case Study: CNCF Case Study
Herausforderung: Ein Gerät, zwei GPU-Nutzungspfade
Online-Fragen und -Antworten erfordern Textgenerierung, Vektorrecherche und Rerank; Dokumente durchlaufen Parsing, Chunking, Vektorisierung und Indexaufbau; Entwickler debuggen Modelle in Kubernetes-Dev-Pods. Diese Workloads nutzen GPUs sehr unterschiedlich – und müssen auf demselben portablen Gerät koexistieren.
Sehr unterschiedliche Workload-Profile
Textgenerierung dauerhaft online mit hoher VRAM-Baseline; Embedding mit periodischen Spitzen beim Massenimport; Rerank kurz, aber häufig; Wissensverarbeitung und Index-Neuaufbau als isolierte Batch-Jobs; Dev-Pods periodisch und interaktiv.
Exklusive Kartenbindung erschöpft Geräte schnell
Bleibt jeder Dienst oder jede Entwicklungsumgebung langfristig an eine ganze Karte gebunden, sind die begrenzten Geräte rasch logisch erschöpft – Restkapazität ist nicht wiederverwendbar.
Übertrieben feine Partitionierung schafft neue Risiken
Nur die feinste Partitionierung anzustreben verstärkt VRAM-Knappheit, Scheduling-Jitter und Fehlerausbreitung.
Differenzierte Ressourcenstrategien nötig
Jeder Workload-Typ sollte seinen Bedarf selbst beschreiben; die Plattform platziert Ressourcen anhand von Gerätestatus und Serviceklasse.
Lösung: Ein gemeinsamer Ressourcenvertrag mit HAMi
Der Wert von HAMi liegt nicht nur im Aufteilen einer physischen Karte in mehrere Anteile. Wichtiger ist der gemeinsame Ressourcenvertrag: Workloads deklarieren ihren Bedarf, das Scheduling wählt anhand des Gerätestatus, mehrere Pods teilen sich eine heterogene GPU innerhalb eigener Grenzen – und Pods, Container, Geräte und Scheduling-Ergebnisse sind nachvollziehbar verknüpft.
Kubernetes-nativer Ressourcenvertrag
Das Kubernetes-Liefermodell bleibt erhalten, während die Plattform versteht, ob heterogene GPUs die Anforderungen erfüllen können – und geeignete Entwicklungsumgebungen dieselbe physische GPU wiederverwenden.
Modell-Dienste und Dev-Pods deklarieren Ressourcen selbst – kein langfristiges Karten-Binding mehr
Scheduling anhand des Gerätestatus, nicht nur GPU-Präsenz auf dem Knoten
Pods, Container, Geräte und Scheduling nachvollziehbar verknüpft – Basis für Kapazitätsbeobachtung und Korrektur
Differenzierte Bereitstellung nach Workload-Profil
Das Team erstellte Ressourcenprofile anhand von Modellladung, Spitzennutzung, Nebenläufigkeit und Latenz und übersetzte die validierten Anforderungen in Kubernetes-Ressourcenanforderungen – mit je nach Workload-Typ unterschiedlichen Strategien.
Stabile Grenzen für den Online-Pfad: Textgenerierung, Online-Retrieval und Rerank zuerst
Periodische Aufgaben außerhalb der Spitzen: Vektorisierung, Wissensextraktion und Index-Neuaufbau bei geringer Last
Korrektur anhand realer Last: Granularität aus Baseline und Laufzeitbeobachtung, nicht aus voreingestellter Quote
Dev-Umgebungen teilen eine heterogene GPU
Mehrere Kubernetes-Dev-Pods nutzen eine heterogene GPU per HAMi-Virtualisierung, statt jede Umgebung exklusiv zu belegen; VRAM-Quoten werden aufgabenbezogen angefragt, nicht platformseitig fixiert.
Mehrere Dev-Pods teilen eine GPU – jeweils mit eigenen Ressourcengrenzen
Dieselben Ressourcendeklarationen und Scheduling-Verfahren wie in der Produktion
Validiert mit 30 gleichzeitigen Dev-Pods auf demselben Gerät
Ergebnisse
Auf demselben portablen Gerät mit 8 heterogenen GPUs verglich das Team die Ressourcenkapazität vor und nach HAMi unter einheitlichen Bedingungen:
Dev-Pod-Kapazität
2 → 30
Gleichzeitige Dev-Pods auf demselben Gerät stiegen von 2 auf 30 – das 15-Fache
VRAM freigegeben
87,5 %
Embedding wechselte von einer vollen 64-GB-GPU zu einer 8-GB-Zuweisung – 56 GB wiederverwendbar
Rechenleistung freigegeben
80 %
Embedding erhielt 20 % der GPU-Rechenleistung; die restlichen 80 % bleiben schedulierbar
Leistungseinfluss
< 5 %
Token-Durchsatz innerhalb von 5 % der exklusiven Nutzung; Ladezeit und P95-Latenz praktisch unverändert
Embedding-Modell: Vergleich je Karte
Gleiches Image, gleiche Anfragen und Nebenläufigkeit – exklusive Nutzung vs. HAMi-Partitionierung:
| Metrik | Ohne HAMi | Mit HAMi |
|---|---|---|
| VRAM-Zuweisung | Exklusiv die gesamte 64-GB-GPU | Bedarfsgerecht 8 GB |
| Für andere Aufgaben nutzbares VRAM | 0 GB | 56 GB – 87,5 % der Karte |
| Rechenleistung | Karte exklusiv | 20 % zugewiesen, 80 % schedulierbar |
| Token-Durchsatz (Tokens/s) | Baseline | Innerhalb von 5 % der exklusiven Nutzung |
| Ladezeit / P95-Latenz | Baseline | Praktisch identisch mit exklusiver Nutzung |
Erkenntnisse & nächste Schritte
Heterogenes GPU-Sharing sollte von Workload-Profilen ausgehen, nicht von einer einheitlichen Quote – Produktionsmodelle, Batch-Jobs und Dev-Umgebungen unterscheiden sich in Latenz, VRAM, Durchsatz und Isolation.
Entwicklungsumgebungen sind ein wichtiger Nutzer geteilter GPUs: Dev-Workloads als Kubernetes-Pods betreiben bedeutet dieselben Ressourcendeklarationen und Scheduling-Verfahren wie in der Produktion – ohne exklusive Langzeitbelegung.
Als Nächstes verfeinert CETC Cloud die Kapazitäts- und Integritätsansichten für Produktions- und Entwicklungs-Workloads und ergänzt reproduzierbare Experimentaldaten für verschiedene Modelle, Netzwerke und Aufrufmuster.
Mehr aus begrenzter heterogener Rechenleistung holen
Von exklusiver Nutzung zu bedarfsgesteuertem Sharing: CETC Cloud dient mit Kubernetes und HAMi auf einem einzigen portablen Gerät eine Produktionspipeline und 30 gleichzeitige Dev-Umgebungen – ohne nennenswerte Leistungseinbußen. Derselbe Ressourcenvertrag gilt für jedes Team, bei dem Produktion und Entwicklung auf begrenzter heterogener Rechenleistung koexistieren müssen.