SageMaker versus Bedrock ist kein technischer Vergleich. Es ist die Frage, ob Ihre Organisation Menschen beschäftigt, deren Job es ist, Modelle zu verantworten. Wenn Sie ein Team haben, das ein Modellartefakt trainiert, evaluiert und dafür Bereitschaftsdienst übernimmt, beschreibt SageMaker Arbeit, die dieses Team bereits leistet. Wenn Sie dieses Team nicht haben, und die meisten Unternehmen, die KI-Funktionen ausliefern, haben es nicht, ist Bedrock kein Kompromiss. Es ist eine korrekte Lesart Ihres Organigramms.

Der Vergleich wird meist als Feature-Matrix geführt: Kontrolle, Kosten pro Token, Modellauswahl, Fine-Tuning, Latenz. Diese Zeilen sind real, aber sie sind nachgelagert. Jede von ihnen löst sich unterschiedlich auf, je nachdem, wer erwartungsgemäß um 3 Uhr morgens den Pager trägt, und das ist eine organisatorische Tatsache, keine technische.

Was jedes der beiden Systeme wirklich von Ihnen verlangt

Entfernen Sie das Marketing, und die beiden Dienste stellen sehr unterschiedliche Anforderungen.

Bedrock verlangt, dass Sie Aufrufe verantworten. Sie erhalten eine API, eine Modell-ID und eine Rechnung. Sie sind verantwortlich für Prompts, Retrieval, die Bewertung von Ausgaben und Kosten. Sie sind nicht verantwortlich für Kapazität, Hardware, Modell-Updates oder das Deployment der Gewichte. Die Arbeitseinheit ist ein Request.

SageMaker verlangt, dass Sie Artefakte verantworten. Sie erhalten Infrastruktur, um ein Modell zu trainieren, zu tunen, zu hosten und zu überwachen, für das Sie rechenschaftspflichtig sind. Sie besitzen die Herkunft der Trainingsdaten, den Evaluierungs-Harness, der eine Freigabe absichert, die Instanzflotte des Endpunkts, die Autoscaling-Policy, die Drift-Erkennung und die Entscheidung, eine neue Version auszurollen. Die Arbeitseinheit ist eine Modellversion, und Modellversionen haben Owner, Changelogs und Rollbacks.

Diese zweite Liste ist ein Job. Keine Aufgabe, sondern ein fester Job, mit Bereitschaftsdienst. Die Frage ist, ob dieser Job in Ihrem Unternehmen heute existiert.

Das Argument der Teamtopologie

Sortieren Sie reale Organisationen in drei Formen.

Produktteams, die Intelligenz konsumieren

Das Team liefert ein Feature aus. Niemandes Titel enthält das Wort "Modell". Der KI-Teil der Roadmap lautet "das Ticket zusammenfassen" und "diese Felder extrahieren". Für diese Form ist Bedrock die Antwort, und das ist nicht knapp. Diesem Team einen SageMaker-Endpunkt zu geben, gibt ihm eine operative Fläche, die es nicht pflegen wird: den Drift-Monitor, den niemand liest, den Endpunkt, der beim Launch dimensioniert und nie wieder angefasst wurde, die Trainingspipeline, die zusammenbricht, wenn die eine Person, die sie verstand, das Team wechselt. Der Fehlermodus von SageMaker in einem Produktteam ist kein schlechtes Modell. Es ist ein unbesessenes.

Ein Plattformteam, das Produktteams bedient

Hier besitzt das Plattformteam ein Gateway, Quoten, Evaluierungsinfrastruktur und Kostenzuordnung, während Produktteams Prompts und Features besitzen. Der Instinkt des Plattformteams ist, dass das Besitzen von Modellen der natürliche nächste Schritt sei. Meist ist es das nicht. Das Wertvolle, das sie liefern, ist die Nahtstelle zwischen Produktteams und Inferenz: Routing, Keys, Budgets, Evals, Audit. Diese Nahtstelle lohnt sich, auf Bedrock zu bauen, und genau das ist die Form, die ich in LLM Gateways: Why Every Platform Team Builds One Eventually beschrieben habe. SageMaker hinzuzufügen bedeutet, "wir betreiben die Modelle" zu einem Team hinzuzufügen, das für sechs andere Teams bereits der Engpass ist.

Ein ML-Team, das bereits Modelle besitzt

Das Team hat eine Trainingspipeline, einen Feature Store, eine Modellregistry und einen bestehenden Endpunkt, für den es Bereitschaftsdienst hat. Für dieses Team ist SageMaker keine neue Last, sondern die Last, die es bereits trägt, nur mit Werkzeug versehen. Der interessante Schritt hier ist meist nicht die Wahl, sondern das Eingeständnis, dass beides betrieben wird: SageMaker für die Modelle, die das Produkt sind, Bedrock für die generische Sprachaufgabe drumherum. Niemand sollte ein Modell für Commit-Zusammenfassungen fine-tunen, in einem Unternehmen, das auch ein echtes Ranking-Modell betreibt.

Die Gründe, die SageMaker wirklich erzwingen

Drei, meiner Erfahrung nach, und sie sind alle spezifisch.

  • Das Modell ist das Produkt oder sein Differenzierungsmerkmal. Betrugserkennung, Ranking, Forecasting, alles, wo Ihre Gewichte etwas kodieren, das ein Wettbewerber nicht kaufen kann. Sie können nicht das auslagern, was Sie verkaufen.
  • Die Gewichte oder die Daten dürfen eine Grenze, die Sie kontrollieren, nicht verlassen, auf eine Weise, die eine verwaltete Inferenz-API nicht erfüllen kann, und Sie haben die tatsächliche Anforderung gelesen statt sie nur nachzuerzählen. Das wird weit häufiger behauptet, als es der Prüfung standhält.
  • Sie brauchen ein Modell, das niemand für Sie bereitstellt, einen bestimmten Open-Weight-Checkpoint oder eine domänenangepasste Variante, und Sie haben eine echte Lücke gegenüber den gehosteten Optionen gemessen, statt sie anzunehmen.

Beachten Sie, was nicht auf der Liste steht: Kosten. Self-Hosting ist bei hoher, gleichmäßiger Auslastung günstiger pro Token und bei allem anderen erheblich teurer, weil Sie für eine Instanz zahlen, ob sie Traffic bedient oder nicht, und weil Sie jetzt Gehälter für Kapazitätsplanung bezahlen. Das Kostenargument ist ein Auslastungsargument in Verkleidung, und es braucht eine angehängte Zahl, um zu zählen.

Wie die Entscheidung meist schiefgeht

Der häufige Fehlschlag ist eine Architektur, die für eine aspirative Organisation gewählt wurde. Ein Team entscheidet sich für SageMaker, weil eine Roadmap-Folie sagt, dass es nächstes Jahr proprietäre Modelle bauen wird. Sie bauen die Pipeline, liefern ein Fine-Tune aus, der Headcount für das ML-Team kommt nie, und zwei Jahre später verstellt ein Produktentwickler nervös einen Instanztyp an einem Endpunkt, den niemand erklären kann. Die Technologie war in Ordnung. Die Organisation, die sie voraussetzte, ist nie aufgetaucht.

Der umgekehrte Fehlschlag existiert auch, ist aber milder und leichter zu beheben. Ein Team auf Bedrock entdeckt einen echten Bedarf an einem Modell, das es besitzen muss, und migriert genau diesen einen Workload. Einen Workload von einer verwalteten API zu einem besessenen Artefakt zu verschieben, ist ein Projekt. Eine unbesessene ML-Plattform stillzulegen, ist eine archäologische Grabung.

Der Test

Stellen Sie eine Frage im Design-Review: Wer wird gepiept, wenn sich die Qualität dieses Modells verschlechtert, und was tut diese Person dann?

Wenn die Antwort eine Person nennt, eine Evaluierungs-Suite beschreibt, die einen Rollback absichert, und der Vorgesetzte dieser Person zustimmt, steht Ihnen SageMaker offen. Wenn die Antwort lautet "das würden wir uns anschauen" oder ein Team nennt, das noch nicht existiert, haben Sie gerade entdeckt, dass Ihre Organisation Intelligenz konsumiert statt sie zu produzieren. Bauen Sie dafür. Das ist keine kleinere Ambition, sondern eine akkurate, und die Einschränkung, die diese Teams bindet, ist fast nie Modell-Ownership. Es ist Evaluierung, eine Disziplin, die Sie ohnehin brauchen, und die ich als die eigentliche Voraussetzung für beide Wege bezeichnen würde.

Die Quintessenz

Wählen Sie SageMaker, wenn ein Team Modellartefakte als feste Verantwortung besitzt, mit Bereitschaftsdienst und einer Evaluierungs-Suite dahinter. Wählen Sie Bedrock, wenn Ihre Organisation Modellausgaben konsumiert, um Features zu bauen, was für die meisten Organisationen die meiste Zeit zutrifft. Der Fehlermodus, das falsch zu entscheiden, ist kein schlechter Benchmark. Es ist Infrastruktur ohne Owner, die still verfällt, bis sie laut versagt. Entscheiden Sie nach dem Organigramm, das Sie haben.

Weiterlesen

Die plattformteam-Version dieses Arguments, darüber, wer Cluster und Pipelines statt Modelle besitzt, finden Sie unter ercan.cloud. Der Hub ist unter ercanermis.com.