{"id":38885,"date":"2026-08-20T14:52:37","date_gmt":"2026-08-20T14:52:37","guid":{"rendered":"https:\/\/lamarr-institute.org\/?post_type=blog&p=38885"},"modified":"2026-08-20T14:56:32","modified_gmt":"2026-08-20T14:56:32","slug":"echtzeit-ki-assistenzsystem-im-krankenhaus","status":"publish","type":"blog","link":"https:\/\/lamarr-institute.org\/de\/blog\/echtzeit-ki-assistenzsystem-im-krankenhaus\/","title":{"rendered":"From Cloud to Edge: Ein Echtzeit-KI-Assistenzsystem im Schockraum"},"content":{"rendered":"\n

Stellen Sie sich folgende Situation vor: Ein Patient in kritischem Zustand wird in ein Krankenhaus eingeliefert. Im Schockraum versuchen rund ein Dutzend \u00c4rzt*innen und medizinische Fachkr\u00e4fte, seinen Zustand zu stabilisieren. Dabei besprechen sie dringende Fragen und versuchen gleichzeitig, sich gegenseitig auf dem Laufenden zu halten. Selbst unter optimalen Bedingungen ist es schwierig, dabei den \u00dcberblick zu behalten \u2013 erst recht am Ende einer zw\u00f6lfst\u00fcndigen Schicht.<\/p>\n\n\n\n

Als Entwicklungspartner von T-Systems haben wir ein agentisches System konzipiert und implementiert, das medizinisches Personal genau in dieser Situation unterst\u00fctzen soll: den TraumaAgent. Er verfolgt den gesamten Behandlungsverlauf und stellt in Echtzeit eine strukturierte \u00dcbersicht \u00fcber den Zustand des Patienten und die durchgef\u00fchrten Behandlungsma\u00dfnahmen bereit. So soll er \u00c4rzt*innen dabei helfen, auch in extrem stressigen Situationen den \u00dcberblick zu behalten und zugleich die Dokumentation nach der Behandlung unterst\u00fctzen.<\/p>\n\n\n\n

F\u00fcr den produktiven Einsatz ist es unerl\u00e4sslich, dass ein solches System die geltenden Datenschutzbestimmungen erf\u00fcllt \u2013 schlie\u00dflich verarbeitet es h\u00f6chst sensible personenbezogene Daten. Gleichzeitig darf dies nicht zulasten der Genauigkeit und Leistungsf\u00e4higkeit des Systems passieren. Um ein H\u00f6chstma\u00df an Datenschutz zu gew\u00e4hrleisten, betreiben wir das System deshalb vollst\u00e4ndig on-premises, also lokal vor Ort. Das bringt jedoch eine Reihe von Herausforderungen mit sich, die wir in diesem Blogbeitrag beschreiben. Wir hoffen, dass unsere Erfahrungen all jenen hilfreiche Anhaltspunkte bieten, die ebenfalls eine lokale Bereitstellung eines agentischen Systems in Betracht ziehen und abw\u00e4gen m\u00fcssen, was dabei f\u00fcr ihren jeweiligen Anwendungsfall zu beachten ist.<\/p>\n\n\n\n

Zwei zentrale Backend-Komponenten erm\u00f6glichen dabei den Betrieb des TraumaAgenten: ein Modell zur automatischen Spracherkennung (Automatic Speech Recognition, ASR) und ein Large Language Model (LLM). Beide basieren auf der Transformer-Architektur und einige der in diesem Beitrag beschriebenen Herausforderungen gelten f\u00fcr beide Komponenten gleicherma\u00dfen. Wir konzentrieren uns im Folgenden jedoch vor allem auf das Large Language Model, das s\u00e4mtliche textbasierten agentischen Workflows steuert.<\/p>\n\n\n\n

Eine kurze Einf\u00fchrung in die LLM-Inferenz<\/h2>\n\n\n\n

Bevor wir ins Detail gehen, folgt zun\u00e4chst eine kurze Einf\u00fchrung in die LLM-Inferenz (einen ausf\u00fchrlichen \u00dcberblick bietet z.B. dieser Artikel auf Huggingface<\/a>). <\/p>\n\n\n\n

Vereinfacht gesagt generiert ein LLM jeweils ein sogenanntes Token \u2013 also beispielsweise einen Teil eines Wortes. Im Durchschnitt besteht ein Wort aus etwa 1,3 Tokens. In einem Chatbot verarbeitet das LLM zun\u00e4chst die Eingabe des Nutzers und erzeugt anschlie\u00dfend schrittweise weitere Tokens, aus denen sich die Antwort zusammensetzt.<\/p>\n\n\n\n

Bei der Inferenz lassen sich daher zwei Phasen unterscheiden: die Verarbeitung des Prompts und die Generierung der Antwort. Die erste Phase ist vergleichsweise einfach umzusetzen: Die gesamte Sequenz der Prompt-Tokens kann parallel verarbeitet werden. GPUs, die f\u00fcr den Betrieb von LLMs eingesetzten Grafikprozessoren, sind f\u00fcr solche parallelen Berechnungen besonders gut geeignet.<\/p>\n\n\n\n

\"-
Phasen der LLM-Inferenz und Interaktion mit dem KV-Cache. <\/figcaption><\/figure>\n\n\n\n

Die Antwortgenerierung l\u00e4sst sich dagegen nicht auf dieselbe Weise parallelisieren, da jedes neu erzeugte Token von den zuvor generierten Tokens abh\u00e4ngt. Damit nicht f\u00fcr jedes neue Token s\u00e4mtliche vorherigen Tokens erneut verarbeitet werden m\u00fcssen, werden Zwischenergebnisse der Berechnungen im GPU-Speicher abgelegt. Dieses Verfahren wird als KV-Caching bezeichnet. Dadurch l\u00e4sst sich die Token-Generierung erheblich beschleunigen. Gleichzeitig erfordert sie jedoch eine hohe Speicherbandbreite der GPU, da f\u00fcr jedes Token wiederholt auf den KV-Cache zugegriffen und in ihn geschrieben werden muss.<\/p>\n\n\n\n

Von cloudbasierten LLMs zur lokalen Bereitstellung<\/h2>\n\n\n\n

Auf einem gro\u00dfen kommerziellen GPU-Server k\u00f6nnen beide Phasen schnell ausgef\u00fchrt werden: Die Hardware erm\u00f6glicht sowohl eine schnelle Prompt-Verarbeitung als auch \u2013 dank hoher Speicherbandbreite \u2013 eine schnelle Token-Generierung.<\/p>\n\n\n\n

Dank unseres Zugangs zur Open Telekom Cloud (OTC) konnten wir diese Leistungsf\u00e4higkeit nutzen, unser hochperformantes Agentensystem entwickeln und unter idealen Bedingungen erproben. Die Herausforderung des Datenschutzes blieb jedoch bestehen.<\/p>\n\n\n\n

\u00dcber T-Systems erhielten wir Zugang zu NVIDIA DGX Spark-Systemen. NVIDIA bewirbt den DGX Spark als Desktop-Supercomputer. Das kompakte System basiert auf einem hochmodernen GPU-Chip mit 128 GB Speicher. Dadurch lassen sich auch gr\u00f6\u00dfere Sprachmodelle mit hoher Geschwindigkeit betreiben, ohne daf\u00fcr eine vollst\u00e4ndige Server-Infrastruktur aufbauen zu m\u00fcssen \u2013 theoretisch also ideal f\u00fcr unseren Anwendungsfall.<\/p>\n\n\n\n

In der Praxis stie\u00dfen wir jedoch auf zwei zentrale Herausforderungen:<\/p>\n\n\n\n

    \n
  1. Ein noch nicht vollst\u00e4ndig ausgereiftes Software-\u00d6kosystem<\/li>\n\n\n\n
  2. Eine begrenzte Speicherbandbreite<\/li>\n<\/ol>\n\n\n\n

    Das Software-\u00d6kosystem<\/p>\n\n\n\n

    Als LLM haben wir uns f\u00fcr OpenAIs Open-Weight-Modell GPT-OSS-120b entschieden. Mit 120 Milliarden Parametern handelt es sich um ein mittelgro\u00dfes Modell, das grunds\u00e4tzlich f\u00fcr Edge Deployment (die dezentrale Datenverarbeitung am Rande des Netzwerks) geeignet ist und gleichzeitig \u00fcber starke Reasoning- und agentische F\u00e4higkeiten verf\u00fcgt.<\/p>\n\n\n\n

    Beim Betrieb in der OTC erwies sich das Modell f\u00fcr unser Agentensystem als sehr geeignet \u2013 unter anderem aufgrund des konfigurierbaren Reasoning Effort. Damit l\u00e4sst sich festlegen, wie intensiv das Modell gewisserma\u00dfen \u201enachdenkt\u201c, bevor es eine Antwort zur\u00fcckgibt oder eine Aktion ausf\u00fchrt.<\/p>\n\n\n\n

    Ein weiterer besonders n\u00fctzlicher Vorteil des Modells ist die native Gewichtsquantisierung auf MXFP4. Im Vergleich zu einem regul\u00e4ren Sprachmodell ben\u00f6tigt es dadurch nur etwa ein Viertel des GPU-Speichers und erm\u00f6glicht auf aktuellen GPU-Architekturen schnellere Berechnungen.<\/p>\n\n\n\n

    Ein regul\u00e4res 120B-Modell w\u00fcrde mindestens 240 GB Speicher ben\u00f6tigen, w\u00e4hrend dieses Modell mit rund 60 GB betrieben werden kann. Die GB10-GPU im DGX Spark ist daher grunds\u00e4tzlich in der Lage, beide Vorteile zu nutzen.<\/p>\n\n\n\n

    An dieser Stelle stie\u00dfen wir jedoch auf das erste Problem: NVIDIA stellt mit dem DGX Spark kompatible Versionen g\u00e4ngiger Inferenz-Frameworks bereit \u2013 in unserem Fall verwenden wir vLLM<\/a> . Diese funktionieren zwar, sind jedoch noch nicht vollst\u00e4ndig darauf optimiert, diese spezielle Form der Quantisierung auszunutzen.<\/p>\n\n\n\n

    Das Ergebnis: Sowohl die Prompt-Verarbeitung als auch die Token-Generierung sind langsamer, als sie theoretisch sein k\u00f6nnten. F\u00fcr unseren Anwendungsfall ist das ein erheblicher Nachteil, denn niedrige Latenzen sind entscheidend daf\u00fcr, dass das System in der Praxis einen Mehrwert bietet.<\/p>\n\n\n\n

    Allerdings gibt es M\u00f6glichkeiten, dieses Problem zu umgehen. Rund um den DGX Spark hat sich eine Community gebildet, die erhebliche Arbeit in st\u00e4rker optimierte Versionen von Inferenz-Frameworks investiert. Ein gutes Beispiel daf\u00fcr ist dieses hier auf GitHub<\/a>, mit dem wir die Geschwindigkeit der Token-Generierung um 50 Prozent steigern konnten.<\/p>\n\n\n\n

    Die Speicherbandbreite<\/h2>\n\n\n\n

    W\u00e4hrend der GB10-Chip bei der Prompt-Verarbeitung eine hohe Leistung erreicht, verf\u00fcgt der verwendete Speicher \u00fcber eine deutlich geringere Bandbreite als der Speicher von Server-GPUs.<\/p>\n\n\n\n

    Wie oben beschrieben, wirkt sich dies insbesondere auf die Geschwindigkeit der Token-Generierung aus. Diesen Effekt konnten wir auch praktisch beobachten: Der von uns gemessene Durchsatz bei der Token-Generierung betr\u00e4gt lediglich etwa ein Viertel dessen, was mit einer einzelnen Server-GPU erreicht werden kann.<\/p>\n\n\n\n

    Die Auswirkungen wurden unmittelbar deutlich, als wir unsere Anwendung im Simulations-Schockraum der Klinik in K\u00f6ln-Merheim einsetzten: Informationen, die aus den Gespr\u00e4chen der \u00c4rzt*innen extrahiert wurden, erschienen zu sp\u00e4t auf dem Dashboard.<\/p>\n\n\n\n

    Um diese Latenz zu reduzieren, verringerten wir den Reasoning-Effort des Modells. Das Modell erzeugte dadurch weniger Tokens f\u00fcr seinen Reasoning-Prozess. Auf diese Weise konnten wir die Latenz wieder auf ein akzeptables Niveau senken \u2013 allerdings auf Kosten der Genauigkeit der auf dem Dashboard dargestellten Informationen.<\/p>\n\n\n\n

    \"-
    TraumaAgent-Dashboard w\u00e4hrend einer simulierten Behandlung im Simulationsraum der Klinik K\u00f6ln-Merheim. \u00a9 Deutsche Telekom\/J\u00f6rg Heupel<\/figcaption><\/figure>\n\n\n\n

    Der Grund daf\u00fcr liegt in der Art der Kommunikation im Schockraum: Relevante Informationen werden h\u00e4ufig nicht ausdr\u00fccklich ausgesprochen, sondern durch die intensive Verwendung von Fachsprache schwerer zug\u00e4nglich gemacht oder bleiben schlicht implizit.<\/p>\n\n\n\n

    Eine weitere verbreitete Methode, mit begrenzter Speicherbandbreite umzugehen, besteht darin, auch den KV-Cache zu quantisieren. Die gespeicherten Zwischenergebnisse werden dabei in einem Datentyp mit geringerer Pr\u00e4zision abgelegt. Dadurch k\u00f6nnen die Daten f\u00fcr jede verarbeitete Sequenz schneller gelesen und geschrieben werden.<\/p>\n\n\n\n

    Theoretisch kann dies allerdings zulasten der Qualit\u00e4t gehen, da es sich um eine verlustbehaftete Quantisierung handelt. In unserem Fall entschieden wir uns f\u00fcr FP8 als Datentyp und beobachteten dabei lediglich einen zu vernachl\u00e4ssigenden Qualit\u00e4tsverlust.<\/p>\n\n\n\n

    Der Einsatz mehrerer DGX Sparks<\/h2>\n\n\n\n

    Zus\u00e4tzlich zu den beschriebenen Optimierungen und Workarounds besteht grunds\u00e4tzlich die M\u00f6glichkeit, zwei DGX-Spark-Systeme miteinander zu verbinden. Dadurch kann der verf\u00fcgbare GPU-Speicher effektiv gemeinsam genutzt und die Berechnung auf beide GPUs verteilt werden.<\/p>\n\n\n\n

    Die zuvor beschriebenen Einschr\u00e4nkungen gelten allerdings weiterhin. In unserem Szenario mit einzelnen, nicht parallel ausgef\u00fchrten Anfragen f\u00fchrt die Verdopplung der Ger\u00e4tezahl daher keineswegs zu einer Halbierung der Latenz. Tats\u00e4chlich steigt der Durchsatz bei der Token-Generierung lediglich um etwa 30 Prozent.\u00b9<\/p>\n\n\n\n

    Das ist zwar kein grundlegender Leistungssprung, sorgt aber dennoch f\u00fcr eine sp\u00fcrbare Verbesserung.<\/p>\n\n\n\n

    \u00dcbertragung auf allgemeinere Anwendungsf\u00e4lle<\/h2>\n\n\n\n

    Ein solches Cluster-Setup bietet dar\u00fcber hinaus weitere Vorteile. Um diese zu verdeutlichen, lohnt sich ein Blick auf allgemeinere Anwendungsf\u00e4lle, bei denen die Latenz m\u00f6glicherweise weniger kritisch ist, w\u00e4hrend die F\u00e4higkeit des Modells, sehr komplexe Aufgaben zu l\u00f6sen, eine gr\u00f6\u00dfere Rolle spielt.<\/p>\n\n\n\n

    Denkbar sind beispielsweise ein Coding-Assistent f\u00fcr vertrauliche Codebasen oder ein umfangreicheres agentisches System zur Analyse sensibler Vertr\u00e4ge \u2013 jeweils ebenfalls unter hohen Datenschutzanforderungen.<\/p>\n\n\n\n

    Hinzu kommt, dass solche Anwendungen h\u00e4ufig nicht nur von einer einzelnen Person, sondern von einem ganzen Team genutzt werden. Dadurch ver\u00e4ndern sich auch die Anforderungen an die Hardware.<\/p>\n\n\n\n

    Im Vergleich zum Echtzeit-Single-User-Szenario des TraumaAgent bietet ein Cluster aus mehreren DGX-Spark-Systemen gerade f\u00fcr solche Anforderungen Vorteile.<\/p>\n\n\n\n

    Zum einen steht doppelt so viel nutzbarer Speicher zur Verf\u00fcgung. Dadurch k\u00f6nnen Modelle mit mehr Parametern und potenziell gr\u00f6\u00dferer Leistungsf\u00e4higkeit betrieben werden, beispielsweise das verbreitete DeepSeek-V4-Flash mit 284 Milliarden Parametern.<\/p>\n\n\n\n

    Zum anderen erm\u00f6glicht mehr Arbeitsspeicher die Speicherung eines gr\u00f6\u00dferen KV-Caches. Da jeder Konversations-Thread mit dem Modell zu einer KV-Cache-Auslastung f\u00fchrt, die proportional zur Anzahl der Token in der Konversation ist, bedeutet dies, dass mehr Nutze*innen gleichzeitig mit einer akzeptablen Geschwindigkeit bedient werden k\u00f6nnen.<\/p>\n\n\n\n

    Ganz grunds\u00e4tzlich gibt es verschiedene M\u00f6glichkeiten, LLMs vollst\u00e4ndig lokal zu betreiben.<\/p>\n\n\n\n

    Eine Option ist eine klassische Server-Infrastruktur on-premises. Diese bietet deutlich h\u00f6here Leistungsreserven, geht jedoch mit wesentlich h\u00f6heren Kosten einher und erfordert zus\u00e4tzlichen Platz, K\u00fchlung, Wartung und weitere Infrastruktur.<\/p>\n\n\n\n

    Alternativ kommen Desktop-Systeme f\u00fcr KI-Anwendungen infrage. Apple Mac mini oder Ger\u00e4te auf Basis von AMD Strix Halo sind beispielsweise verbreitete Alternativen zum DGX Spark.<\/p>\n\n\n\n

    Jede dieser Optionen bringt Vor- und Nachteile mit sich. Wir hoffen, dass dieser Beitrag einige der m\u00f6glichen Einschr\u00e4nkungen und Herausforderungen verdeutlicht und Leser*innen damit dabei unterst\u00fctzt, eine fundierte Entscheidung f\u00fcr ihren jeweiligen Anwendungsfall zu treffen.<\/p>\n\n\n\n

    Fazit<\/h2>\n\n\n\n

    Noch vor ein oder zwei Jahren w\u00e4re der lokale Betrieb komplexer LLM-basierter Anwendungen ohne hohe Anfangsinvestitionen in KI-Hardware kaum denkbar gewesen. Heute ist dies durchaus m\u00f6glich.<\/p>\n\n\n\n

    Da Open-Weight-LLMs immer leistungsf\u00e4higer und kompakte KI-Hardware zunehmend leistungsst\u00e4rker werden, d\u00fcrfte die Einstiegsh\u00fcrde weiter sinken.<\/p>\n\n\n\n

    Der Wechsel von der Cloud auf Edge-Hardware ist derzeit allerdings noch keineswegs vollst\u00e4ndig unkompliziert und mit verschiedenen Einschr\u00e4nkungen verbunden. Unser spezieller, aber zugleich hochrelevanter Anwendungsfall zeigt, dass diese Einschr\u00e4nkungen ganz konkrete praktische Auswirkungen haben \u2013 aber auch, dass sich viele davon durch gezielte Ma\u00dfnahmen abmildern lassen.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Kann Echtzeit-KI im Schockraum Datenschutz, geringe Latenz und hohe Qualit\u00e4t miteinander vereinen? TraumaAgent zeigt, welche Herausforderungen der Wechsel von der Cloud zum lokalen Betrieb mit sich bringt.<\/p>\n","protected":false},"author":14,"featured_media":38873,"template":"","meta":{"_acf_changed":false,"footnotes":""},"blog-category":[1416,546,1664],"blog-tag":[1488,1516,1526,1522,1551,1559,1598],"class_list":["post-38885","blog","type-blog","status-publish","has-post-thumbnail","hentry","blog-category-alle-blogbeitraege","blog-category-anwendung","blog-category-ki-in-gesundheit-medizin","blog-tag-foundation-modelle","blog-tag-gpt-de","blog-tag-ki-in-der-medizin","blog-tag-ki-agenten","blog-tag-large-language-models-llms-de","blog-tag-nlp-de","blog-tag-sprachmodelle"],"acf":[],"publishpress_future_workflow_manual_trigger":{"enabledWorkflows":[]},"_links":{"self":[{"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/blog\/38885","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/users\/14"}],"version-history":[{"count":0,"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/blog\/38885\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/media\/38873"}],"wp:attachment":[{"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/media?parent=38885"}],"wp:term":[{"taxonomy":"blog-category","embeddable":true,"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/blog-category?post=38885"},{"taxonomy":"blog-tag","embeddable":true,"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/blog-tag?post=38885"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}