Website besuchen →
← Zurück zum Blog

Self Hosted LLM: Lohnt sich der Betrieb eigener Sprachmodelle?

7. Oktober 2026
Self Hosted LLM: Lohnt sich der Betrieb eigener Sprachmodelle?

Ja, Self-Hosting lohnt sich für datensensible oder hochfrequente Workloads, allerdings nur unter drei Bedingungen: ein quantisiertes Modell passend zur verfügbaren Hardware, ausreichend VRAM oder eine skalierbare Multi-GPU-Architektur, und klare Sicherheitsanforderungen inklusive TEE-Unterstützung bei vertraulichen Daten. Fehlt eine dieser drei Voraussetzungen, bleibt eine Cloud-API meist die wirtschaftlichere Wahl.

Kurz gesagt:

  • Eine selbstgehostete LLM-Inferenz ist nur bei quantisierten Modellen, ausreichendem VRAM oder Multi-GPU-Architekturen sowie klaren Sicherheitsanforderungen wirtschaftlich sinnvoll.
  • Quantisierungsmethoden wie GPTQ und QUIK ermöglichen erhebliche Speicherersparnis, bringen aber nur bei GPU-Kernel-Unterstützung echte Geschwindigkeitsgewinne.
  • Hardwareanforderungen variieren stark je nach Modellgröße, Quantisierungsgrad und Einsatzszenario, wobei Multi-GPU-Setups vor allem bei hohen Durchsatzanforderungen vorteilhaft sind.
  • Für datensensible Anwendungen sind Trusted Execution Environments notwendig, da sie Speicher und Berechnung verschlüsseln, wobei Overheads stets unter 10 Prozent liegen.
  • Bei geringem Anfragevolumen oder niedrigem Datenschutzanspruch bleibt Cloud-API meist günstiger, während Self-Hosting bei hohen und konstanten Lasten die bessere TCO-Option ist.
Nectos
Souveräne KI für sensible Daten
Nectos bietet einen Schweizer KI-Arbeitsbereich mit lokal gehosteten Modellen, Schweizer Servern und Datenschutz nach nLPD.
Nectos kennenlernen

Inhaltsverzeichnis

Die vier Bausteine eines selbst gehosteten LLM-Stacks

Ein lokal betriebenes Sprachmodell besteht aus vier Komponenten, die sich gegenseitig bedingen. Die Runtime lädt das Modell und stellt eine Schnittstelle bereit, meist als Inference-API, Web-Oberfläche oder Embedding-Dienst. Das Modell selbst liegt in einem bestimmten Format vor, etwa GGUF, Safetensors oder ONNX, und dieses Format entscheidet, welche Runtimes es überhaupt laden können. Die Quantisierung komprimiert die Gewichte von 16-Bit- auf 8-Bit- oder 4-Bit-Repräsentationen und senkt damit den Speicherbedarf drastisch. Die Hardware schließlich liefert den Rechen- und Speicherraum, in dem alles läuft.

Diese vier Bausteine greifen ineinander wie Zahnräder. Ein Format, das die Ziel-Runtime nicht unterstützt, blockiert den gesamten Stack, unabhängig davon, wie gut die Hardware ist. Eine Quantisierung ohne passenden GPU-Kernel bringt Speicherersparnis, aber keinen Geschwindigkeitsgewinn. Wer plant, sollte deshalb rückwärts denken: von der Hardware zur Quantisierung, von der Quantisierung zum Format, vom Format zur Runtime.

Typische Runtimes unterscheiden sich stark in ihrem Interface-Angebot:

  • Lokale Oberflächen wie text-generation-webui eignen sich für Experimente und manuelle Tests.
  • Serverorientierte Runtimes stellen eine REST- oder gRPC-Inference-API für Anwendungsintegration bereit.
  • Manche Lösungen bieten zusätzlich einen Embedding-Dienst für Retrieval-Szenarien.

Wer produktiv arbeiten will, sollte früh entscheiden, ob die Runtime als persistenter Dienst mit API-Vertrag läuft oder nur als interaktives Werkzeug gedacht ist. Diese Entscheidung bestimmt später die gesamte Deployment-Architektur.

Modellkompression und Quantisierung: GPTQ, 3-4-Bit-Strategien und QUIK

Quantisierung ist der Hebel, der lokale Inferenz überhaupt erst praktikabel macht. Ohne sie benötigt ein mittelgroßes Modell oft mehr VRAM, als eine einzelne Consumer-GPU bietet.

GPTQ kann sehr große Modelle wie OPT-175B oder BLOOM-176B in etwa vier GPU-Stunden auf 3 bis 4 Bit quantisieren, mit nur geringem Genauigkeitsverlust. Das Verfahren arbeitet als Post-Training-Quantisierung: Es benötigt kein erneutes Training, sondern kalibriert die Gewichte anhand eines kleinen Datensatzes, im GPTQ-Paper etwa 128 zufällige Textsegmente mit 2048 Token. In Experimenten erreichten die quantisierten Modelle End-to-End-Beschleunigungen von etwa dem Zweifachen auf einer A100 und etwa dem Vierfachen auf einer A6000.

Modellkompression und Quantisierung: GPTQ, 3-4-Bit-Strategien und QUIK — overview diagram

Ein neuerer Ansatz, QUIK, quantisiert nicht nur Gewichte, sondern auch Aktivierungen auf 4 Bit. Diese hybride Strategie liefert End-to-End-Durchsatzgewinne bis ungefähr dem 3,4-Fachen gegenüber FP16, allerdings nur dort, wo passende GPU-Kernel vorliegen. Speicherersparnis allein garantiert also keinen Geschwindigkeitsgewinn: Ohne Kernel-Unterstützung bleibt die Rechenzeit annähernd gleich, selbst wenn der Speicherbedarf sinkt.

Bei der Modellwahl helfen folgende Richtwerte:

  • FP16 eignet sich, wenn ausreichend VRAM vorhanden ist und maximale Qualität zählt.
  • 8-Bit-Quantisierung ist ein guter Mittelweg für Produktionssysteme mit moderater Hardware.
  • 4-Bit-Quantisierung passt für Consumer-GPUs oder Edge-Deployments, wenn geringe Qualitätseinbußen akzeptabel sind.

Vor jedem produktiven Einsatz empfiehlt sich ein Regressionstest mit domänenspezifischen Prompts, da Qualitätsverluste je nach Aufgabe und Kalibrierungsdatensatz variieren.

Hardware-Sizing: VRAM, Multi-GPU und Apple Silicon

Die Hardware-Planung beginnt mit einer einfachen Überlegung: Wie viel Speicher benötigt das gewählte Modell bei der gewählten Quantisierung. Ein unquantisiertes Modell in FP16 benötigt grob zwei Byte pro Parameter, ein 4-Bit-Modell etwa ein Viertel davon. Diese Faustregel verschiebt sich je nach Architektur und Kontextlänge, bleibt aber als erste Orientierung brauchbar.

Für Modelle, die nicht auf eine einzelne GPU passen, kommen Multi-GPU-Muster ins Spiel:

  • Tensor-Parallelismus teilt einzelne Schichten über mehrere GPUs auf und eignet sich für hohe Durchsatzanforderungen.
  • Pipeline-Parallelismus verteilt ganze Schichtblöcke sequenziell und reduziert den Kommunikationsaufwand zwischen Karten.
  • ZeRO-ähnliche Sharding-Ansätze verteilen Optimizer-Zustände und Gewichte, was vor allem beim Training, weniger bei reiner Inferenz relevant ist.

Netzwerkengpässe zwischen GPUs werden bei wachsender Modellgröße zum limitierenden Faktor, besonders wenn PCIe statt NVLink die Verbindung herstellt.

Nicht jede Last rechtfertigt GPUs. Bei kleinen Modellen und niedrigen Batchgrößen können CPU-basierte Deployments wirtschaftlich sinnvoller sein, vor allem wenn vertrauliche Verarbeitung gefordert ist. CPU-basierte Trusted Execution Environments erreichen in von der ETH Zürich untersuchten Szenarien Overheads von weniger als zehn Prozent, während konfidentielle GPU-Ansätze mit 4 bis 8 Prozent Overhead ähnlich performant bleiben, jedoch Skalierungsgrenzen zeigen. Für latenzkritische, datensensible Kleinmodelle ist ein CPU-TEE-Setup damit oft die kosteneffizientere Option gegenüber einer vertraulichen GPU.

In der Praxis zeigen sich drei typische Szenarien: Entwicklungsumgebungen kommen mit einer einzelnen Consumer-GPU und einem 4-Bit-Modell aus, kleine und mittlere Produktivbetriebe benötigen meist eine bis zwei Server-GPUs mit 24 bis 48 Gigabyte VRAM, und Umgebungen mit hohem Durchsatz setzen auf Multi-GPU-Cluster mit Tensor-Parallelismus. Apple-Silicon-Systeme mit vereinheitlichtem Speicher bieten für Einzelentwickler eine brauchbare Alternative zu dedizierten GPUs, stoßen bei Batch-Inferenz und Multi-User-Lasten aber schneller an Grenzen als NVIDIA-Server-Hardware.

Runtimes, Orchestrierung und Deployment-Muster für den Produktivbetrieb

Für einen reinen Machbarkeitsnachweis reicht oft eine einzelne virtuelle Maschine mit einer lokalen Runtime. Produktionsreife Systeme benötigen dagegen eine durchdachte Architektur:

  1. Die Runtime läuft als containerisierter Dienst, typischerweise in Docker, mit klar definierten Ressourcenlimits für GPU-Speicher.
  2. Ein API-Gateway liegt vor der Inferenz-Schicht und übernimmt Authentifizierung, Rate-Limiting und Request-Routing.
  3. Bei mehreren Modellinstanzen übernimmt ein Orchestrierungssystem wie Kubernetes das Scheduling und Neustarts bei Ausfällen.
  4. Batching-Logik gruppiert eingehende Anfragen, um die GPU-Auslastung zu erhöhen, ohne die Latenz einzelner Nutzer unverhältnismäßig zu erhöhen.
  5. Observability-Werkzeuge erfassen Latenz, Token-Durchsatz und Fehlerraten pro Endpunkt.
  6. Ein separates Logging-System hält Audit-Trails für Compliance-Zwecke vor, getrennt von den eigentlichen Inhaltsdaten.

Für einen Proof of Concept genügt eine einzelne VM mit lokaler Runtime und einfachem Reverse Proxy. Sobald mehrere Teams oder Anwendungen den Dienst nutzen, wird ein API-Gateway mit Quotenverwaltung notwendig, da sonst einzelne Clients die gesamte Kapazität blockieren können.

Sicherheit, Datenschutz und vertrauliche Verarbeitung

Wer sensible Daten verarbeitet, kommt um Trusted Execution Environments kaum herum. SGX und TDX auf CPU-Seite sowie konfidentielle GPU-Modi verschlüsseln Speicher und Berechnung so, dass selbst ein kompromittierter Host-Hypervisor die Inhalte nicht einsehen kann.

Abgeschirmte Rechenumgebung für vertrauliche LLM-Verarbeitung

Profi-Tipp: Planen Sie TEE-Overhead von Anfang an in die Kapazitätsrechnung ein, statt ihn nachträglich zu kompensieren.

Die Performance-Kosten sind messbar, aber begrenzt: Laut ETH-Zürich-Analyse liegen CPU-TEE-Overheads in untersuchten Szenarien unter 10 Prozent, konfidentielle GPUs bei 4 bis 8 Prozent, allerdings mit Einschränkungen bei der Skalierung auf mehrere Karten. Die Studie weist zudem auf notwendige Anpassungen im Memory-Management hin, etwa bei NUMA-Topologien und Hugepages, ohne die sich die Overheads deutlich erhöhen können.

Für den produktiven Einsatz empfehlen sich folgende Grundsätze:

  • Minimieren Sie die Angriffsfläche, indem Sie nur notwendige Dienste innerhalb der vertraulichen Umgebung laufen lassen.
  • Führen Sie lückenlose Audit-Trails für jeden Zugriff auf Modelloutputs und Trainingsdaten.
  • Trennen Sie Zugriffsrechte strikt nach Rolle, insbesondere zwischen Entwicklungs- und Produktionsumgebung.
  • Verzichten Sie bei Gesundheits- oder Personendaten auf ungeprüfte Drittanbieter-Runtimes ohne dokumentierte Sicherheitsarchitektur.

Bei PHI- oder PII-Workloads gilt grundsätzlich: keine Verarbeitung ohne Verschlüsselung im Ruhezustand und während der Berechnung, keine Protokollierung roher Inhalte in Klartext-Logs, und keine Weitergabe von Rohdaten an externe Modellanbieter ohne vertragliche Grundlage.

Kosten, Betrieb und Skalierung: TCO gegen Cloud-APIs

Die Gesamtbetriebskosten eines selbst gehosteten LLM setzen sich aus mehreren Treibern zusammen:

  • Hardware-Anschaffung oder Leasing von GPU-Servern bildet meist den größten Einzelposten.
  • Energiekosten steigen mit Dauerbetrieb und Auslastung deutlich an.
  • Personalzeit für Betrieb, Monitoring und Sicherheitsupdates wird häufig unterschätzt.
  • Speicher- und Netzwerkkosten fallen bei großen Modellen und häufigen Updates ins Gewicht.

Als Heuristik gilt: Self-Hosting lohnt sich eher bei konstant hohem Anfragevolumen, bei dem die Fixkosten der Hardware über viele Anfragen verteilt werden. Bei schwankender oder geringer Last bleibt eine Cloud-API oft günstiger, da keine Investitionskosten anfallen. Laufende Betriebskosten umfassen zudem regelmäßige Software-Patches, Modell-Updates und wiederkehrende Sicherheitstests, die in keiner TCO-Rechnung fehlen dürfen.

Für einen ersten Proof of Concept empfiehlt sich ein begrenztes Budget mit einer einzelnen GPU-Instanz, bevor eine Skalierung auf Produktionsniveau erfolgt. So lässt sich der tatsächliche Ressourcenbedarf unter realer Last beobachten, bevor größere Investitionen gebunden werden.

Minimaler Praxisleitfaden: In acht Schritten zur lokalen Inferenz-API

Ein reproduzierbarer Aufbau folgt einer festen Reihenfolge:

  1. Modell nach Anwendungsfall und Lizenz auswählen.
  2. Zielquantisierung festlegen, meist 4-Bit für Consumer-Hardware oder 8-Bit für Server-GPUs.
  3. Quantisierungswerkzeug anwenden und mit Kalibrierungsdaten testen.
  4. Passende Runtime installieren und Modell laden.
  5. API-Endpunkt konfigurieren, inklusive Authentifizierung.
  6. Latenz- und Durchsatztests mit realistischen Prompt-Längen durchführen.
  7. Monitoring für Fehlerraten und Ressourcenauslastung einrichten.
  8. Rollback-Mechanismus für fehlerhafte Modellversionen festlegen.
PrüfschrittZiel
LatenztestAntwortzeit unter typischer Last messen
DurchsatztestMaximale Anfragen pro Sekunde ermitteln
RegressionstestQualitätsverlust nach Quantisierung prüfen
SicherheitscheckZugriffsrechte und Logging vor Livebetrieb kontrollieren

Vor dem Livebetrieb sollte jeder dieser vier Prüfschritte mit dokumentierten Ergebnissen abgeschlossen sein, nicht nur stichprobenhaft getestet.

Wartung und Updates lokaler LLM-Installationen

Ein selbst gehostetes Modell ist kein einmaliges Projekt, sondern ein System mit wiederkehrendem Pflegebedarf. Modell-Updates erscheinen in unregelmäßigen Abständen, oft mit verbesserter Genauigkeit oder neuen Fähigkeiten, erfordern aber jedes Mal einen erneuten Regressionstest gegen die bestehende Prompt-Suite. Ein unkontrolliertes Austauschen der Modellversion ohne Vergleichstest kann bestehende Anwendungen unbemerkt verschlechtern.

Software-Updates betreffen die Runtime selbst sowie zugrunde liegende Bibliotheken für Quantisierung und GPU-Treiber. Da sich Inferenz-Engines in diesem Bereich schnell weiterentwickeln, lohnt sich ein fester Update-Rhythmus, etwa quartalsweise, statt ad-hoc-Patches unter Zeitdruck.

Sicherheitsupdates verdienen eine eigene Kategorie, weil sie oft kritischer sind als funktionale Verbesserungen. Dazu zählen Patches für Container-Images, Betriebssystem und API-Gateway. Ein Staging-System, das Updates vor dem Produktionseinsatz durchläuft, reduziert das Risiko unerwarteter Ausfälle erheblich.

Für die Praxis empfiehlt sich ein dokumentierter Wartungsplan mit festen Zeitfenstern, klaren Rollback-Pfaden und einer Versionshistorie der eingesetzten Modelle. Ohne diese Dokumentation wird eine spätere Fehlersuche, etwa bei einer unerwarteten Qualitätsverschlechterung, deutlich aufwendiger.

Modellqualität und Performance: lokal gehostet gegen Cloud-Anbieter

Cloud-Anbieter betreiben in der Regel die größten, nicht quantisierten Versionen ihrer Modelle auf spezialisierter Hardware, was in vielen allgemeinen Aufgaben zu einem Qualitätsvorsprung gegenüber quantisierten, lokal betriebenen Modellen führt. Dieser Unterschied fällt bei komplexen Reasoning-Aufgaben oder langen Kontexten tendenziell stärker aus als bei einfachen Klassifikations- oder Extraktionsaufgaben.

Lokal gehostete, quantisierte Modelle holen den Abstand bei spezialisierten, eng umrissenen Aufgaben oft auf, besonders wenn sie auf eine Domäne feinabgestimmt wurden. Für einen internen Support-Assistenten mit begrenztem Themenfeld kann ein gut abgestimmtes 7- bis 13-Milliarden-Parameter-Modell ausreichen, während eine offene, breite Wissensfrage eher von einem großen Cloud-Modell profitiert.

Die Latenz verhält sich oft umgekehrt: Ein lokal gehostetes Modell ohne Netzwerk-Roundtrip zu einem externen Rechenzentrum kann bei moderater Last schneller antworten als eine Cloud-API, besonders wenn Datenschutzanforderungen zusätzliche Anonymisierungsschritte vor dem Versand an externe Dienste erfordern. Die Entscheidung zwischen beiden Wegen hängt also weniger von einer pauschalen Qualitätsaussage ab als von der konkreten Aufgabe, der Kontextlänge und den Antwortzeitanforderungen.

Skalierungsstrategien und Lastverteilung für lokale LLMs

Mit wachsender Nutzerzahl wird die Lastverteilung zur zentralen Herausforderung. Horizontale Skalierung, also das Hinzufügen weiterer Modellinstanzen hinter einem Load Balancer, funktioniert gut, solange jede Instanz unabhängig auf eigener Hardware läuft. Ein Load Balancer verteilt eingehende Anfragen nach Auslastung oder Round-Robin-Prinzip auf die verfügbaren Instanzen.

Batching ist die zweite zentrale Strategie: Mehrere gleichzeitig eingehende Anfragen werden zu einem gemeinsamen Forward-Pass zusammengefasst, was die GPU-Auslastung erheblich steigert, allerdings auf Kosten einzelner Antwortzeiten bei ungünstigem Timing. Dynamisches Batching, bei dem Anfragen innerhalb eines kurzen Zeitfensters gesammelt werden, bietet hier einen praktikablen Mittelweg zwischen Durchsatz und Latenz.

Für Lastspitzen lohnt sich eine Warteschlange mit Priorisierung, damit kritische Anfragen nicht hinter unkritischen Hintergrundjobs verzögert werden. Autoscaling, wie es Kubernetes mit GPU-Operatoren ermöglicht, hilft bei schwankender Last, setzt aber voraus, dass zusätzliche GPU-Kapazität tatsächlich verfügbar ist, was bei begrenzter eigener Hardware nicht immer gegeben ist.

Wer absehbar über mehrere Standorte oder Rechenzentren skaliert, sollte früh über Modellreplikation statt zentraler Verarbeitung nachdenken, um Netzwerklatenz zwischen Nutzerstandort und Inferenz-Server zu minimieren.

Rechtliche und datenschutzrechtliche Aspekte beim Betrieb

Der Betrieb eines selbst gehosteten Sprachmodells verändert die rechtliche Ausgangslage gegenüber einer Cloud-API grundlegend: Die Datenverarbeitung bleibt vollständig innerhalb der eigenen Infrastruktur, wodurch viele Fragen zur Datenübermittlung an Drittländer entfallen. Das reduziert zwar bestimmte Compliance-Risiken, verschiebt die Verantwortung für Zugriffskontrolle, Verschlüsselung und Protokollierung aber vollständig zum Betreiber selbst.

Je nach Branche und Standort greifen unterschiedliche Vorgaben, etwa zur Aufbewahrungsdauer von Logs oder zur Pseudonymisierung personenbezogener Daten vor der Verarbeitung. Wer mit Gesundheits-, Finanz- oder Personendaten arbeitet, sollte die eigene Architektur gegen die jeweils geltenden branchenspezifischen Vorgaben prüfen, statt sich allein auf die technische Isolation der Infrastruktur zu verlassen.

Ein oft übersehener Punkt ist die Dokumentationspflicht: Auch bei vollständig selbst betriebener Infrastruktur verlangen viele Datenschutzrahmen einen nachweisbaren Überblick darüber, welche Daten wie lange gespeichert, wer Zugriff hat und wie im Falle eines Vorfalls reagiert wird. Ein Audit-Trail, der jeden Zugriff auf Modell-Logs und gespeicherte Anfragen dokumentiert, ist in regulierten Branchen praktisch unverzichtbar.

Wer unsicher ist, ob die eigene Architektur den geltenden Anforderungen entspricht, sollte frühzeitig juristischen Rat einholen, statt sich auf allgemeine Technik-Empfehlungen zu verlassen, da die konkreten Pflichten je nach Branche, Datenkategorie und Standort erheblich variieren.

Nectos-Perspektive: Warum ein souveräner, lokal gehosteter KI-Arbeitsbereich relevant ist

Wir betreiben unseren souveränen KI-Arbeitsbereich mit lokal gehosteten Modellen, ohne Datenweitergabe an US-amerikanische Hyperscaler. Für Organisationen mit Audit-Pflichten oder BYOC-Anforderungen adressieren wir organisatorische Lücken, die ein improvisierter Self-Hosting-Aufbau oft offenlässt: lückenlose Protokollierung und kontrollierte Infrastrukturhoheit.

— Adopt

Nectos für datensensible Self-Hosted-Workflows

Wer die oben beschriebenen Hürden, Hardware-Sizing, TEE-Konfiguration, laufende Wartung, lieber nicht allein stemmen will, kann fertige Wege zum gleichen Ziel finden: Datenhoheit ohne Eigenbetrieb. Unsere BYOC- und On-Premise-Bereitstellung läuft in Ihrer eigenen Infrastruktur, ergänzt durch unser Sicherheits- und Compliance-Paket für Audit-Trails und Zugriffskontrolle.

Nectos

Wer prüfen möchte, ob ein verwalteter, Schweizer-gehosteter Arbeitsbereich die eigene Self-Hosting-Planung ersetzen kann, findet auf unserer Preisseite den passenden Einstieg.

FAQ

Lohnt sich Self-Hosting eines LLM wirtschaftlich?

Self-Hosting lohnt sich vor allem bei konstant hohem Anfragevolumen oder strengen Datenschutzanforderungen, da sich die Hardware-Fixkosten dann über viele Anfragen verteilen. Bei geringer oder stark schwankender Last bleibt eine Cloud-API meist günstiger, da keine Investitionskosten in GPU-Hardware anfallen.

Wie hoch sind die Kosten für den Betrieb eines eigenen LLM?

Die Kosten setzen sich aus Hardware, Energie, Personalzeit für Wartung und Netzwerk- oder Speicherkosten zusammen, wobei Hardware meist den größten Posten bildet. Eine genaue Zahl lässt sich nicht pauschal angeben, da sie stark von Modellgröße, Quantisierung und gewählter GPU-Konfiguration abhängt.

Welches ist das beste selbst gehostete LLM-Modell?

Es gibt kein universell bestes Modell: Die Wahl hängt von Aufgabe, verfügbarem VRAM und gewünschter Quantisierungsstufe ab. Für spezialisierte, eng umrissene Aufgaben reichen oft kleinere, feinabgestimmte Modelle, während breite Wissensfragen von größeren Architekturen profitieren.

Welches LLM kann ich zu Hause betreiben?

Mit einer Consumer-GPU und 4-Bit-Quantisierung, etwa über GPTQ, lassen sich viele mittelgroße offene Modelle lokal betreiben. Die konkrete Modellgröße richtet sich nach dem verfügbaren VRAM der eigenen Grafikkarte und der gewählten Quantisierungsstufe.

Wie sicher ist ein selbst gehostetes LLM für sensible Daten?

Trusted Execution Environments wie SGX oder TDX schützen Daten während der Berechnung und erreichen in untersuchten Szenarien der ETH Zürich Overheads von unter 10 Prozent bei CPU-TEEs. Vollständige Sicherheit erfordert zusätzlich strikte Zugriffskontrolle, Verschlüsselung und lückenlose Audit-Trails.

Quellen

Empfehlungen