SageMaker contro Bedrock non è un confronto tecnico. È una domanda su se la tua organizzazione impiega persone il cui lavoro è possedere i modelli. Se hai un team che addestra, valuta, ed è reperibile per un artefatto modello, SageMaker descrive un lavoro che già fanno. Se non hai quel team, e la maggior parte delle aziende che spediscono funzionalità AI non ce l'ha, Bedrock non è un compromesso. È una lettura corretta del tuo organigramma.

Il confronto viene solitamente condotto come una matrice di funzionalità: controllo, costo per token, scelta del modello, fine-tuning, latenza. Quelle righe sono reali, ma sono a valle. Ognuna di esse si risolve diversamente a seconda di chi ci si aspetta debba portarne il peso alle 3 del mattino, e questo è un fatto organizzativo, non tecnico.

Cosa chiede davvero ciascuno dei due

Togli il marketing e i due servizi fanno richieste molto diverse.

Bedrock ti chiede di possedere le chiamate. Ottieni un'API, un ID modello, e una bolletta. Sei responsabile di prompt, retrieval, valutazione degli output, e costo. Non sei responsabile della capacità, dell'hardware, degli aggiornamenti del modello, o del deployment dei pesi. L'unità di lavoro è una richiesta.

SageMaker ti chiede di possedere gli artefatti. Ottieni infrastruttura per addestrare, ottimizzare, ospitare, e monitorare un modello di cui sei responsabile. Possiedi la lineage dei dati di addestramento, la suite di valutazione che regola un rilascio, la flotta di istanze dell'endpoint, la policy di autoscaling, il rilevamento del drift, e la decisione di distribuire una nuova versione. L'unità di lavoro è una versione del modello, e le versioni dei modelli hanno proprietari, changelog, e rollback.

Quella seconda lista è un lavoro. Non un task, un lavoro stabile, con reperibilità annessa. La domanda è se quel lavoro esiste oggi nella tua azienda.

L'argomento della topologia di team

Ordina le organizzazioni reali in tre forme.

Team prodotto che consumano intelligenza

Il team spedisce una funzionalità. Nessun titolo contiene la parola "modello". La parte AI della roadmap è "riassumi il ticket" e "estrai questi campi". Per questa forma, Bedrock è la risposta e non è nemmeno vicino a un dubbio. Dare a questo team un endpoint SageMaker gli consegna una superficie operativa che non manterranno: il monitor del drift che nessuno legge, l'endpoint dimensionato durante un lancio e mai più rivisto, la pipeline di addestramento che si rompe quando l'unica persona che la capiva cambia team. La modalità di fallimento di SageMaker in un team prodotto non è un modello scadente. È un modello senza proprietario.

Un team platform che serve i team prodotto

Qui il team platform possiede un gateway, le quote, l'infrastruttura di valutazione, e l'attribuzione dei costi, mentre i team prodotto possiedono prompt e funzionalità. L'istinto del team platform è che possedere i modelli sia il passo successivo naturale. Di solito non lo è. La cosa di valore che forniscono è la giuntura tra i team prodotto e l'inferenza: routing, chiavi, budget, eval, audit. Quella giuntura vale la pena costruirla su Bedrock, ed è esattamente la forma che ho descritto in LLM Gateways: Why Every Platform Team Builds One Eventually. Aggiungere SageMaker significa aggiungere "gestiamo i modelli" a un team che è già il collo di bottiglia per altri sei team.

Un team ML che già possiede i modelli

Il team ha una pipeline di addestramento, un feature store, un registro dei modelli, e un endpoint esistente che li tiene reperibili. Per loro SageMaker non è un nuovo peso, è il peso che già portano, ma attrezzato. La mossa interessante qui di solito non è scegliere, è ammettere che useranno entrambi: SageMaker per i modelli che sono il prodotto, Bedrock per il lavoro linguistico generico attorno ad esso. Nessuno dovrebbe fare fine-tuning di un modello per scrivere riassunti dei commit in un'azienda che gestisce anche un vero modello di ranking.

Le ragioni che forzano davvero SageMaker

Tre, nella mia esperienza, e sono tutte specifiche.

  • Il modello è il prodotto, o il suo elemento distintivo. Fraud scoring, ranking, forecasting, qualsiasi cosa in cui i tuoi pesi codificano qualcosa che un concorrente non può comprare. Non puoi esternalizzare la cosa che stai vendendo.
  • I pesi o i dati non possono lasciare un confine che controlli in un modo che un'API di inferenza gestita non può soddisfare, e hai letto il requisito reale anziché ripeterlo. Questo viene invocato molto più spesso di quanto sopravviva a un esame attento.
  • Ti serve un modello che nessuno ti serve, un checkpoint open-weight specifico o una variante adattata al dominio, e hai misurato un gap reale rispetto alle opzioni gestite anziché darlo per scontato.

Nota cosa non c'è nella lista: il costo. L'autohosting è più economico per token ad alta utilizzazione costante e considerevolmente più costoso in tutti gli altri casi, perché paghi un'istanza indipendentemente dal fatto che serva traffico, e perché ora paghi anche stipendi per la pianificazione della capacità. L'argomento del costo è un argomento di utilizzo travestito, e ha bisogno di un numero allegato prima di contare.

Come la decisione va solitamente storta

Il fallimento comune è un'architettura scelta per un'organizzazione aspirazionale. Un team sceglie SageMaker perché una slide della roadmap dice che costruiranno modelli proprietari l'anno prossimo. Costruiscono la pipeline, spediscono un fine-tune, l'organico per il team ML non arriva mai, e due anni dopo un ingegnere di prodotto sta nervosamente cambiando il tipo di istanza su un endpoint che nessuno sa spiegare. La tecnologia andava bene. L'organizzazione che presupponeva non si è mai presentata.

Il fallimento inverso esiste ma è più mite e più facile da correggere. Un team su Bedrock scopre un bisogno genuino di possedere un modello, e migra quel singolo workload. Spostare un workload da un'API gestita a un artefatto posseduto è un progetto. Ritirare una piattaforma ML senza proprietario è uno scavo archeologico.

Il test

Fai una domanda nel design review: chi viene chiamato quando la qualità di questo modello peggiora, e cosa fa a riguardo?

Se la risposta nomina una persona, descrive una suite di valutazione che regola un rollback, e il manager di quella persona è d'accordo, SageMaker è disponibile per te. Se la risposta è "ci daremmo un'occhiata" o nomina un team che ancora non esiste, hai appena scoperto che la tua organizzazione consuma intelligenza anziché produrla. Costruisci per quello. Non è un'ambizione più piccola, è un'ambizione accurata, e il vincolo che lega quei team non è quasi mai la proprietà del modello. È la valutazione, che è una disciplina di cui hai bisogno in entrambi i percorsi e che sosterrei essere il vero prerequisito per entrambi.

Il punto chiave

Scegli SageMaker quando un team possiede artefatti modello come responsabilità stabile, con reperibilità e una suite di valutazione dietro. Scegli Bedrock quando la tua organizzazione consuma output di modelli per costruire funzionalità, il che vale per la maggior parte delle organizzazioni, la maggior parte delle volte. La modalità di fallimento nello sbagliare questa scelta non è un brutto benchmark. È infrastruttura senza proprietario, che decade silenziosamente finché non fallisce rumorosamente. Scegli in base all'organigramma che hai.

Leggi questo dopo

La versione lato team platform di questo argomento, su chi possiede cluster e pipeline anziché modelli, è su ercan.cloud. L'hub è su ercanermis.com.