AWS Bedrock und andere Cloud-Anbieter

Das Cloud-Ökosystem von Mistral

Neben Azure und Google Cloud stehen Mistral-Modelle auf mehreren weiteren Plattformen zur Verfügung. Diese Lektion behandelt AWS Bedrock im Detail, da dies die häufigste Alternative darstellt und sich am stärksten von dem unterscheidet, was Sie bisher gelernt haben. Anschließend werden kurz Integrationen mit Snowflake Cortex, IBM watsonx und Outscale vorgestellt.

AWS Bedrock

Amazon Bedrock ist der verwaltete Service von AWS für Foundation Models. Er stellt eine einheitliche API vor mehrere Anbieter – Anthropic, Meta, Mistral und andere – bereit und übernimmt Abrechnung, Sicherheit und Compliance über AWS. Für Teams, die bereits AWS nutzen, bedeutet dies, dass Mistral-Modelle im gleichen IAM-Bereich operieren, dieselben CloudWatch-Logs verwenden und auf derselben Rechnung wie der Rest Ihrer Infrastruktur erscheinen.

Hinsichtlich des Katalogs bietet Bedrock Zugriff auf folgende Modelle. Die genaue Liste hängt von Ihrer Region ab und ändert sich mit neuen Releases; die Seite Modellzugriff in der Konsole ist die einzige gültige Quelle.

Zugriff vorbereiten

Sie müssen vier Bedingungen erfüllen, bevor Sie den ersten Aufruf tätigen:

1. Ein AWS-Konto mit Zugriff auf eine Region, die Bedrock unterstützt
2. Eine IAM-Principal mit den Berechtigungen bedrock:InvokeModel und bedrock:InvokeModelWithResponseStream
3. Konfigurierte AWS CLI und installiertes boto3
4. Mistral-Modelle im Bedrock-Konsole aktivieren (Modellzugriff)

pip install boto3>=1.34.131
aws configure  # Geben Sie Ihre Anmeldeinformationen ein

Die zweite Berechtigung ist diejenige, die Menschen häufig vergessen: Eine Principal, die nur bedrock:InvokeModel besitzt, funktioniert im synchronen Modus, schlägt aber beim ersten Streaming-Aufruf fehl. Schritt 4 ist ähnlich wie das Aktivieren von Modellen im Model Garden von Google: Bis Sie das Modell im Modellzugriff freischalten, funktioniert keine IAM-Berechtigung.

Ein Modell mit boto3 aufrufen

Hier liegt der wesentliche Unterschied zu Azure und Vertex: Auf Bedrock nutzen Sie nicht das Mistral SDK. Alles läuft über das native AWS SDK, boto3, unter Verwendung der converse()-API, die für alle Anbieter auf der Plattform gemeinsam ist.

import boto3
import json

client = boto3.client('bedrock-runtime', region_name='us-west-2')

response = client.converse(
    modelId="mistral.mistral-large-2512-v1:0",
    messages=[
        {
            "role": "user",
            "content": [{"text": "Was sind die Vorteile einer serverlosen Architektur auf AWS?"}]
        }
    ],
    inferenceConfig={
        "temperature": 0.3,
        "maxTokens": 1024
    }
)

texte = response["output"]["message"]["content"][0]["text"]
print(texte)

Streaming folgt der gleichen Logik, verwendet converse_stream() und iteriert über Stream-Events. Beachten Sie, dass Sie nach dem Schlüssel contentBlockDelta suchen müssen: Der Bedrock-Stream enthält zudem Block-Start- und Block-End-Events, die keinen Text enthalten.

response = client.converse_stream(
    modelId="mistral.mistral-large-2512-v1:0",
    messages=[
        {
            "role": "user",
            "content": [{"text": "Beschreiben Sie die Architektur aus Lambda und API Gateway."}]
        }
    ],
    inferenceConfig={"temperature": 0.3, "maxTokens": 1024}
)

for event in response["stream"]:
    if "contentBlockDelta" in event:
        texte = event["contentBlockDelta"]["delta"].get("text", "")
        print(texte, end="", flush=True)

Wenn Sie Code portieren, der für die direkte Mistral-API geschrieben wurde, sollten Sie mit vier Unterschieden rechnen. Erstens ist content kein String mehr, sondern ein Array von {"text": "..."}-Objekten. Zweitens folgt modelId dem AWS-Format mistral.{model}-v{version}:{number}: Im Gegensatz zu den -latest-Aliasen in der direkten API fixieren Sie eine spezifische Version und müssen diese manuell aktualisieren. Drittens sind Inferenzparameter in einem separaten inferenceConfig-Objekt gruppiert, anstatt auf der obersten Ebene übergeben zu werden. Schließlich ist kein Mistral SDK beteiligt: Antworten sind boto3-Dictionaries, keine typisierten Modelle, daher erfolgt der Zugriff über Schlüssel wie oben gezeigt.

Snowflake Cortex

Snowflake integriert Mistral-Modelle, einschließlich Mistral Large, direkt in seine Datenplattform über Cortex AI. Der Hauptvorteil ist einfach: Ihre Daten verlassen Snowflake nie. Der Aufruf des Modells wird zu einer SQL-Funktion, die innerhalb einer Abfrage aufgerufen wird, direkt neben der Tabelle, die Sie bereichern möchten.

-- Direkte Verwendung in einer SQL-Abfrage
SELECT SNOWFLAKE.CORTEX.COMPLETE(
  'mistral-large',
  'Fassen Sie diesen Finanzbericht in drei Schlüsselpunkten zusammen.'
) AS resume;

Stellen Sie sich eine Tabelle mit Tausenden von Berichten vor: Anstatt den Inhalt in ein Python-Skript zu exportieren, die API aufzurufen und die Ergebnisse neu zu importieren, schreiben Sie eine Abfrage, die die Spalte mit der Zusammenfassung direkt erzeugt. Dies ist die offensichtliche Wahl, wenn Ihre Datenpipeline bereits in Snowflake lebt und Governance-Regeln jeglichen Datenexport verbieten.

IBM watsonx

IBM watsonx.ai bietet Mistral-Modelle, einschließlich Mistral Large, in seinem Katalog an. Der Zugriff erfolgt über die watsonx-API unter Verwendung von IBM Cloud-Anmeldeinformationen: Sie instanzen ein ModelInference-Objekt, geben die Modell-ID, Ihre Anmeldeinformationen und das Zielprojekt an. Beachten Sie die regionale URL im Beispiel – sie bestimmt, wo die Inferenz ausgeführt wird, ein Detail, das Sie überprüfen sollten, wenn Sie Anforderungen an die Datenresidenz haben.

from ibm_watsonx_ai import Credentials
from ibm_watsonx_ai.foundation_models import ModelInference

model = ModelInference(
    model_id="mistralai/mistral-large",
    credentials=Credentials(url="https://eu-de.ml.cloud.ibm.com", api_key="..."),
    project_id="your-project-id"
)

response = model.generate_text("Erklären Sie das Konzept des Data Mesh.")

Outscale, die französische Souveräne Cloud

Outscale, eine französische Souveräne Cloud, die als SecNumCloud qualifiziert ist, bietet ebenfalls Mistral-Modelle an. Für Behörden, Verteidigungsorganisationen oder Gesundheitswesen, die strengen regulatorischen Anforderungen unterliegen, garantiert diese Option, dass sowohl Daten als auch Verarbeitung in Frankreich verbleiben. In diesen Kontexten ist dies das einzige Kriterium, das zählt: Die Qualifikation geht vor Integrationsbequemlichkeit oder Entwicklererfahrung.

Den richtigen Anbieter wählen

Die Wahl hängt fast nie von den Modellen selbst ab, da dieselben auf Plattformen weit verbreitet verfügbar sind. Sie hängt davon ab, wo Ihre Daten liegen, Ihr Vertrag und Ihre Compliance-Pflichten.

Eine nützliche Faustregel: Beginnen Sie mit der direkten API, um zu validieren, dass das Modell Ihre Bedürfnisse erfüllt, und migrieren Sie dann zum Anbieter Ihres Ökosystems, wenn das Projekt in die Produktion übergeht. Der Anwendungscode ändert sich kaum; der Großteil der Arbeit betrifft Authentifizierung und Modellbenennung.

Prüfen vor der Bereitstellung

Cloud-Anbieter-Modell-IDs sind versioniert und ändern sich mit jeder Generation (mistral.mistral-large-2512-v1:0 auf Bedrock zum Beispiel). Bevor Sie eine Bereitstellung verkabeln, überprüfen Sie den genauen Wert in der Anbieter-Konsole: Dies ist die einzige gültige Quelle, und eine veraltete ID erzeugt einen Zugriffsfehler, der schwer zu diagnostizieren ist.

Kernaussagen

• AWS Bedrock verwendet boto3 und die converse()-API – nicht das Mistral SDK
• Das Bedrock-Nachrichtenformat unterscheidet sich leicht (Inhalt als Array von Objekten)
• Snowflake Cortex integriert Mistral direkt in SQL-Abfragen
• IBM watsonx und Outscale bieten Alternativen für spezifische Bedürfnisse
• Wählen Sie Ihren Anbieter basierend auf Ihrem bestehenden Cloud-Ökosystem und regulatorischen Einschränkungen