BLOG | BÜRO DES CTO

KI-Inferenzmuster

Chris Hain Miniaturbild
Chris Hain
Veröffentlicht am 11. Juni 2024

Da KI- und maschinelle Lernfunktionen in Unternehmen jeder Größe zunehmend als entscheidend für die Förderung von Innovation und Effizienz angesehen werden, müssen Organisationen entscheiden, wie sie ihren Anwendungsentwicklern am besten Zugriff auf diese Funktionen ermöglichen. In vielen Fällen wird ein KI-Inferenzdienst verwendet. Dabei handelt es sich um „einen Dienst, der KI-Modelle aufruft, um auf der Grundlage einer gegebenen Eingabe eine Ausgabe zu erzeugen“ (beispielsweise eine Klassifizierung vorherzusagen oder Text zu generieren). In den meisten Fällen wird dies als Reaktion auf einen API-Aufruf von einem anderen Anwendungscode durchgeführt.

Diese Inferenzdienste können auf vielfältige Weise erstellt und genutzt werden (sogar innerhalb einer einzelnen Organisation). Diese Dienste können vollständig intern entwickelt oder als SaaS genutzt werden, Open-Source-Projekte nutzen und offene oder kommerzielle Modelle verwenden. Sie sind möglicherweise Teil einer voll funktionsfähigen „Plattform für maschinelles Lernen“, die umfassendere Datenwissenschafts- und Modellerstellungsbemühungen unterstützt, oder sie bieten Ihnen lediglich einen API-Endpunkt zum Aufrufen der Modelle. Sie können in einem privaten Rechenzentrum, in einer öffentlichen Cloud, in einer Colocation-Einrichtung oder in einer Mischung dieser Einrichtungen ausgeführt werden. Größere Organisationen verlassen sich wahrscheinlich auf mehr als eine einzige Option für KI-Inferenz (insbesondere bei niedrigeren organisatorischen Reifegraden in diesem Bereich). Zwar gibt es keinen einheitlichen Ansatz, der für alle funktioniert, doch zeichnen sich einige gemeinsame Muster ab.

Musterübersicht

Wir untersuchen drei allgemeine Nutzungsmuster für KI-Inferenzen sowie ihre verschiedenen Stärken und Schwächen:

  1. KI-Inferenz als SaaS – Anwendungen stellen eine Verbindung zu einem externen dedizierten KI-Inferenz-Dienstanbieter her.
  2. Cloudverwaltete KI-Inferenz – Anwendungen stellen eine Verbindung zu vollständig verwalteten KI-Inferenzdiensten her, die in der öffentlichen Cloud ausgeführt werden.
  3. Selbstverwaltete KI-Inferenz – Anwendungen nutzen KI-Inferenz, die von der Organisation selbst verwaltet wird, entweder als Teil eines zentralisierten Dienstes oder direkt auf Anwendungsebene.

Wichtige Entscheidungspunkte

Bei der Bewertung der Vor- und Nachteile der folgenden Betriebsmuster müssen einige wichtige Faktoren berücksichtigt werden:

Betriebsbezogene Überlegungen

  • Skalierbarkeit – Wer ist dafür verantwortlich und wie gut lässt sich eine bestimmte Option nach oben und unten skalieren, wenn sich der Kapazitätsbedarf im Laufe der Zeit ändert? Gibt es Maßstabsgrenzen oder Kapazitätsobergrenzen?
  • Kosten – Vollständig verwaltete Dienste mögen auf den ersten Blick teurer erscheinen, aber wenn man die Gesamtbetriebskosten (einschließlich Spezialhardware und Personal) berücksichtigt, ist die Entscheidung möglicherweise weniger eindeutig. Wie steigen die Betriebskosten bei steigender oder sinkender Kapazität, gibt es Kostenuntergrenzen?
  • Wartung/Support – Wer ist für die Wartung des Inferenzdienstes verantwortlich? Muss Ihr Unternehmen Mitarbeiter einstellen oder Berater mit Fachkenntnissen auf diesem Gebiet bezahlen oder wäre ein Managed-Service-Angebot sinnvoller?

Überlegungen zur Entwicklung

  • Einfache Workload-Integration – Wie schnell kann der KI-Dienst in die verbrauchenden Workloads integriert werden? Funktioniert das Serviceangebot mit Ihrem erwarteten Nutzungsmuster (z. B. Offline-/Batch-Inferenz) und Ihren Betriebsumgebungen?
  • Agilität – Wie schnell kann die Gesamtanwendung an veränderte Geschäftsanforderungen angepasst werden? Welche Aspekte der Architektur sind stärker verankert und könnten nur schwer geändert werden?

Überlegungen zur Leistung

  • Leistung – Ist der physische Standort des Dienstes (im Verhältnis zu den Dienstkonsumenten) und die Latenz der Inferenz für Ihre Anwendungsfälle von Bedeutung?
  • Hardwareverfügbarkeit – Gibt es für den Dienst besondere Hardwareanforderungen und verfügen Sie ggf. über die Kapazität, die erwarteten Anforderungen zu erfüllen (gilt sowohl für lokale als auch für Cloudumgebungen)?

Überlegungen zu Daten

  • Datenleck – Besteht die Sorge, dass vertrauliche Daten an den Inferenzdienst gesendet werden oder im Inferenzergebnis vorhanden sein könnten? Wenn ja, kann der Verkehr kontrolliert und können Leitplanken angebracht werden?
  • Data GovernanceWohin werden die Anwendungsdaten geografisch gesendet (und wie)? Bleibt die direkte Kontrolle innerhalb der Organisation oder wird sie an Dritte übertragen? Gibt es besondere Vorschriften oder Compliance-Richtlinien , die für den Umgang mit den Daten gelten?

SaaS-Muster

Saas-Musterdiagramm

Organisationen können sich dafür entscheiden, Dienste von einem dedizierten SaaS-Anbieter zu nutzen, der sich auf das Hosten von KI-Modellen für Inferenzen konzentriert (wie OpenAI oder Cohere). In diesem Fall nutzen Workloads, die auf der Infrastruktur einer Organisation (sei es ein privates Rechenzentrum, eine Colocation-Umgebung oder eine öffentliche Cloud) ausgeführt werden, vom SaaS-Anbieter veröffentlichte APIs. Bei diesem Muster liegt die Last im Zusammenhang mit dem Betrieb der zum Hosten der Modelle erforderlichen Infrastruktur vollständig beim SaaS-Anbieter, und die Einrichtung und Inbetriebnahme kann sehr schnell erfolgen. Diese Vorteile gehen jedoch auf Kosten der Kontrolle, da dieses Muster von den Mustern, die wir behandeln, das am wenigsten „flexible“ ist. Ebenso ist die Kontrolle über vertrauliche Daten bei diesem Modell typischerweise am geringsten, da für die Verbindung mit dem Dienst normalerweise das öffentliche Internet verwendet wird und der externe SaaS-Anbieter weniger in der Lage ist, strenge Anforderungen hinsichtlich der Einhaltung gesetzlicher Vorschriften zu erfüllen.

Gut geeignet für

  • Markteinführungszeit: Schnelles Prototyping, MVP-Releases.
  • Organisationen ohne nennenswerte interne Expertise/Erfahrung im Bereich KI-Inferenz.
  • Anwendungen ohne erhebliche oder strenge Anforderungen an Datensicherheit/Datenverwaltung.

Stärken

  • Kurze Markteinführungszeit: Ein einfaches Betriebsmodell kann zu kurzen Integrationszeiten führen.
  • Fokussierte Dienstanbieter sind für die Herausforderungen der Inferenzskalierung gut gerüstet.
  • Erfordert keine Investition in spezielle Hardware oder Personal.

Herausforderungen

  • Bedenken hinsichtlich Latenz und Konnektivität im Zusammenhang mit Diensten, die mit App-Workloads zusammengelegt sind.
  • Bedenken hinsichtlich Datenschutz, Governance und Sicherheit hängen von einem externen SaaS-Anbieter ab (oder sind möglicherweise mit diesem nicht kompatibel).
  • Bei größeren Modellen können die Betriebskosten höher sein als bei Self-Hosting-Modellen.
  • Das Hosten benutzerdefinierter Modelle und die Anpassung benutzerdefinierter Modelle werden möglicherweise nicht unterstützt.

Cloud-verwaltetes Muster

Cloud Manged-Diagramm

In diesem Muster nutzen Organisationen verwaltete Dienste, die von öffentlichen Cloud-Anbietern bereitgestellt werden (z. B. Azure OpenAI, Google Vertex, AWS Bedrock). Wie beim ersten Muster liegt die operative Last für die Bereitstellung, Skalierung und Wartung der KI-Modelle beim Cloud-Anbieter und nicht bei der nutzenden Organisation. Der Hauptunterschied zwischen diesem Muster und dem obigen SaaS-Muster besteht darin, dass in diesem Fall die Endpunkte der Inferenz-API im Allgemeinen über private Netzwerke zugänglich sind und KI-Consumer-Workloads mit dem KI-Modelldienst zusammengelegt werden können (z. B. dieselbe Zone, Region). Daher werden die Daten normalerweise nicht über das öffentliche Internet übertragen, die Latenz ist wahrscheinlich geringer und die Mechanismen zum Herstellen einer Verbindung mit diesen Diensten ähneln denen für andere von Cloud-Anbietern verwaltete Dienste (z. B. Dienstkonten, Zugriffsrichtlinien, Netzwerk-ACLs). Organisationen, die Multi-Cloud-Netzwerke nutzen, können möglicherweise einige dieser Vorteile auch dann erzielen, wenn Workloads und KI-Inferenzdienste in verschiedenen Clouds gehostet werden.

Gut geeignet für

  • Organisationen mit bestehenden öffentlichen Cloud-Investitionen.
  • Anwendungen, die in anderen Cloud-verwalteten Diensten ausgeführt werden oder mit diesen verbunden sind.

Stärken

  • Viele Organisationen sind bereits mit der Verbindung ihrer Workloads mit den verwalteten Diensten anderer Cloud-Anbieter (z. B. Datenbanken, Objektspeicher usw.) vertraut.
  • Die Betriebs- und Infrastrukturlast für den Betrieb und die Skalierung von Modellen liegt in erster Linie beim Cloud-Anbieter.
  • Latenzprobleme und einige Datenschutzbedenken lassen sich möglicherweise leichter lösen.

Herausforderungen

  • Für die Verbindung und Sicherung von Multi-/Hybrid-Cloud-Anwendungen ist zusätzlicher Aufwand erforderlich.
  • Ein Mangel an Einheitlichkeit bei den in der Cloud verwalteten Diensten und APIs kann zu einer Abhängigkeit von einem bestimmten Anbieter führen.
  • Für Unternehmen ohne umfassende Präsenz in der öffentlichen Cloud kann es zu Schwierigkeiten kommen.
  • Bei größeren Modellen können die Betriebskosten höher sein als bei Self-Hosting-Modellen.
  • Das Hosten benutzerdefinierter Modelle und die Anpassung benutzerdefinierter Modelle werden möglicherweise nicht unterstützt.

 

Selbstverwaltetes Muster

Selbstverwaltungsdiagramm

Für das selbstverwaltete Modell besprechen wir zunächst den Fall, in dem die KI-Modellinferenz als zentraler „gemeinsam genutzter Dienst“ ausgeführt wird. Anschließend untersuchen wir den Fall, in dem kein zentraler Dienst vorhanden ist und betriebliche Belange den einzelnen Anwendungsteams überlassen werden.

Selbstverwalteter, gemeinsam genutzter Dienst

In der „Shared Service“-Variante des Self-Managed-Musters kann eine Organisation über dedizierte Teams verfügen, die für die Wartung der Inferenzinfrastruktur, der darauf ausgeführten Modelle, der zur Verbindung mit ihr verwendeten APIs und aller betrieblichen Aspekte des Inferenzdienst-Lebenszyklus verantwortlich sind. Wie bei den anderen Mustern würden die Workloads von KI-Anwendungen Inferenzdienste über API-Aufrufe nutzen. Die Modell-Serving-Infrastruktur kann in privaten Rechenzentren, einer öffentlichen Cloud oder einer Colocation-Einrichtung ausgeführt werden. Die für den Betrieb des Inferenzdienstes verantwortlichen Teams können selbstgehostete Plattformen für maschinelles Lernen (wie Anyscale Ray oder MLFlow) nutzen. Alternativ könnten sie auf stärker fokussierte Inferenztools wie den Text Generation Inference-Server von Hugging Face oder intern entwickelte Software zurückgreifen. Bei der selbstverwalteten Inferenz sind Organisationen auf die Verwendung von Modellen beschränkt, die sie entweder selbst trainiert haben oder die für die lokale Ausführung verfügbar sind (proprietäre Modelle von einem SaaS-orientierten Dienst sind daher möglicherweise keine Option).

Gut geeignet für

  • Reife Organisationen mit umfassender Erfahrung im Infrastrukturmanagement.
  • Organisationen mit hohen Inferenzanforderungen, die die Gesamtbetriebskosten eines selbstverwalteten Dienstes rechtfertigen.
  • Anwendungen mit strengsten Datenschutz- und Compliance-Anforderungen.

Stärken

  • Organisationen haben die vollständige Kontrolle über alle Aspekte des Inferenzdienstes.
  • Herausforderungen im Bereich des Datenschutzes lassen sich normalerweise am einfachsten mit selbstgehosteten Modellen bewältigen.
  • Im großen Maßstab sind die Kosten möglicherweise geringer als bei cloudverwalteten oder auf SaaS basierenden Inferenzdiensten.

Herausforderungen

  • Organisationen haben die vollständige Kontrolle über alle Aspekte des Inferenzdienstes (wahrscheinlich sind große Investitionen in die Infrastruktur und das Personal erforderlich, außerdem müssen laufende Wartungs-, Entwicklungs- und Skalierbarkeitsprobleme gelöst werden).
  • Normalerweise nicht kosteneffizient für Organisationen mit minimalem Inferenzbedarf und minimalen Datenschutzbedenken.
  • Kein Zugriff auf geschlossene/proprietäre Modelle, die möglicherweise als SaaS oder Cloud Managed Services verfügbar sind.

Selbst verwaltet, kein gemeinsam genutzter Dienst

Organisationen ohne zentrales Team, das für die Ausführung von KI-Inferenzdiensten für zu nutzende Anwendungen verantwortlich ist, stellen die andere Variante des selbstverwalteten Musters dar. In dieser Version können einzelne Anwendungsteams ihre Modelle auf derselben Infrastruktur ausführen, die ihnen für die Anwendungsarbeitslast zugewiesen wurde. Sie können auf diese Modelle entweder über die API zugreifen oder sie direkt „offline“ nutzen. Mit diesem Muster können Entwickler möglicherweise einige der gleichen Vorteile wie mit dem selbstverwalteten „Shared Service“-Modell in kleinerem Maßstab erzielen.

Gut geeignet für

  • Anwendungen, die Stapelverarbeitung und Offline-Inferenz erfordern.
  • Organisationen mit sehr geringem Inferenzverbrauch, aber strengen Datenschutz- und Compliance-Anforderungen.

Stärken

  • Größte Flexibilität für Anwendungsentwickler, da zahlreiche Möglichkeiten zur Integration mit Workloads bestehen.
  • Kann Datenschutz- und Latenzziele in kleinem Maßstab erreichen.
  • In manchen Fällen (z. B. bei einem einzelnen Team mit hohem Verbrauchsbedarf) kann es kostengünstiger sein als die anderen besprochenen Modelle.

Herausforderungen

  • Die operative Last für den Modelllebenszyklus wird auf einzelne Anwendungsteams übertragen.
  • Schöpft keine Vorteile aus Skaleneffekten, wenn die Nutzung von KI-Inferenzen in einem Unternehmen zunimmt (mangelnde Konsistenz, ineffiziente Ressourcennutzung usw.)

Zusammenfassung der Musterkompromisse

SaaS-Diagramm

Sicherung von KI-Apps und Modellinferenzdiensten

Im Kern ähneln KI-Anwendungen vielen anderen modernen Apps. Sie bestehen aus einer Mischung von benutzerorientierten und Backend-Komponenten, basieren häufig auf externen Datenspeichern, nutzen häufig API-Aufrufe usw. Diese Anwendungen unterliegen den gleichen Sicherheitsherausforderungen wie alle modernen Apps und benötigen die gleichen Schutzmaßnahmen in der gleichen Weise (z. B. AuthNZ, DDoS-Schutz, WAF, sichere Entwicklungspraktiken usw.). Allerdings unterliegen KI-Apps, insbesondere jene, die generative KI nutzen, auch einer Reihe besonderer Probleme, die für andere Anwendungen möglicherweise nicht gelten (siehe beispielsweise „OWASP Top 10 für LLMs “). Die im Allgemeinen unvorhersehbare Natur dieser Modelle kann zu neuartigen Problemen führen, insbesondere in Anwendungsfällen, in denen den Modellen eine erhebliche Einflussnahme zugeschrieben wird.

Glücklicherweise sind viele Organisationen aufgrund der starken Abhängigkeit von API-gesteuerten Interaktionen mit KI-Modellinferenz in den oben diskutierten Mustern bereits gut aufgestellt, um diese neuen Sicherheitsmaßnahmen zu implementieren. Beispielsweise könnte ein API-Gateway, das herkömmliche Funktionen zur Ratenbegrenzung, Authentifizierung, Autorisierung und Verkehrsverwaltung bereitstellt, erweitert werden, um tokenbasierte Ratenbegrenzungen zu unterstützen und so die Kostenkontrolle zu erleichtern (entweder ausgehend auf App-Ebene zu einem vom SaaS/Anbieter verwalteten Dienst oder eingehende RBAC-Autorisierung als Schutz vor einem selbstverwalteten Inferenzdienst). Ebenso könnte eine Infrastruktur, die derzeit herkömmliche WAF-Dienste (Web Application Firewall) ausführt, etwa die Prüfung auf SQL-Injection oder XSS, ein logischer Ort für den Einbau von Schutzmaßnahmen gegen Prompt-Injection und ähnliche Angriffe sein. Die meisten modernen Verfahren zur Observability sind direkt auf API-gesteuerte, KI-Inferenz-spezifische Anwendungsfälle anwendbar und die Teams sollten in der Lage sein, in diesem Bereich vorhandene Tools und Verfahren gut zu nutzen.

Abschluss

Während die Begeisterung für KI-gestützte Anwendungen und Inferenzdienste sicherlich neu ist, gibt es die grundlegenden Prinzipien, die bei ihrer Bereitstellung und Sicherung eine Rolle spielen, schon seit langem. Unternehmen müssen bei der Entscheidung, wie sie KI-Funktionen am besten nutzen, Kompromisse abwägen – ähnlich wie bei der Nutzung jeder anderen Technologie – und zwar basierend auf ihren spezifischen Anwendungsfällen, den verfügbaren Ressourcen und den langfristigen Zielen. Auch wenn die Anwendungsfälle der KI (und insbesondere der generativen KI) einige neuartige Sicherheitsherausforderungen mit sich bringen, stellen die Anforderungen, die sie mit anderen modernen Anwendungen teilen, und die starke Abhängigkeit von API-gesteuerter Modellinteraktion eine großartige Gelegenheit dar, vorhandene Muster, Praktiken und Werkzeuge zu verwenden und zu erweitern. Unabhängig davon, ob es sich um einen selbst gehosteten oder verwalteten Dienst handelt, ist es für die Maximierung des Werts und der Wirkung Ihrer KI-Investitionen von entscheidender Bedeutung, sicherzustellen, dass Entwickler Zugriff auf eine sichere, skalierbare und leistungsfähige Lösung haben, die Ihren spezifischen Geschäftsanforderungen entspricht.