SageMaker εναντίον Bedrock δεν είναι τεχνική σύγκριση. Είναι μια ερώτηση για το αν ο οργανισμός σου απασχολεί ανθρώπους των οποίων η δουλειά είναι να κατέχουν μοντέλα. Αν έχεις μια ομάδα που εκπαιδεύει, αξιολογεί, και κρατά εφημερία για ένα model artifact, το SageMaker περιγράφει δουλειά που ήδη κάνουν. Αν δεν έχεις εκείνη την ομάδα, και οι περισσότερες εταιρείες που κυκλοφορούν AI features δεν την έχουν, το Bedrock δεν είναι συμβιβασμός. Είναι μια σωστή ανάγνωση του οργανογράμματός σου.

Η σύγκριση συνήθως τρέχει σαν πίνακας χαρακτηριστικών: έλεγχος, κόστος ανά token, επιλογή μοντέλου, fine-tuning, latency. Αυτές οι γραμμές είναι πραγματικές, αλλά είναι κατάντη. Καθεμία τους λύνεται διαφορετικά ανάλογα με το ποιος αναμένεται να το κρατά στις 3 το πρωί, και αυτό είναι οργανωτικό γεγονός, όχι τεχνικό.

Τι ζητά πραγματικά το καθένα από εσένα

Αφαίρεσε το marketing και οι δύο υπηρεσίες κάνουν πολύ διαφορετικές απαιτήσεις.

Το Bedrock σου ζητά να κατέχεις κλήσεις. Παίρνεις ένα API, ένα model ID, και έναν λογαριασμό. Είσαι υπεύθυνος για prompts, ανάκτηση, αξιολόγηση αποτελεσμάτων, και κόστος. Δεν είσαι υπεύθυνος για χωρητικότητα, hardware, ενημερώσεις μοντέλου, ή την ανάπτυξη των weights. Η μονάδα εργασίας είναι ένα αίτημα.

Το SageMaker σου ζητά να κατέχεις artifacts. Παίρνεις υποδομή για να εκπαιδεύσεις, να συντονίσεις, να φιλοξενήσεις, και να παρακολουθήσεις ένα μοντέλο για το οποίο είσαι υπόλογος. Κατέχεις την προέλευση των δεδομένων εκπαίδευσης, το harness αξιολόγησης που εγκρίνει μια κυκλοφορία, τον στόλο instances του endpoint, την πολιτική autoscaling, την ανίχνευση drift, και την απόφαση να ανεβάσεις μια νέα έκδοση. Η μονάδα εργασίας είναι μια έκδοση μοντέλου, και οι εκδόσεις μοντέλου έχουν owners, changelogs, και rollbacks.

Εκείνη η δεύτερη λίστα είναι μια δουλειά. Όχι ένα task, μια μόνιμη δουλειά, με εφημερία προσαρτημένη. Το ερώτημα είναι αν εκείνη η δουλειά υπάρχει στην εταιρεία σου σήμερα.

Το επιχείρημα της τοπολογίας ομάδων

Ταξινόμησε πραγματικούς οργανισμούς σε τρία σχήματα.

Ομάδες προϊόντος που καταναλώνουν νοημοσύνη

Η ομάδα κυκλοφορεί ένα feature. Κανενός ο τίτλος δεν περιέχει τη λέξη "μοντέλο". Το AI κομμάτι του roadmap είναι "συνόψισε το ticket" και "εξήγαγε αυτά τα πεδία". Για αυτό το σχήμα, το Bedrock είναι η απάντηση και δεν είναι καν κοντά. Το να δώσεις σε αυτή την ομάδα ένα SageMaker endpoint της δίνει μια επιφάνεια λειτουργίας που δεν θα συντηρήσει: τον monitor drift που κανείς δεν διαβάζει, το endpoint που διαστασιολογήθηκε κατά την κυκλοφορία και ποτέ δεν ξαναειδώθηκε, το pipeline εκπαίδευσης που σπάει όταν το ένα άτομο που το καταλάβαινε αλλάζει ομάδα. Το failure mode του SageMaker σε μια ομάδα προϊόντος δεν είναι ένα κακό μοντέλο. Είναι ένα ακατοχύρωτο.

Μια ομάδα πλατφόρμας που εξυπηρετεί ομάδες προϊόντος

Εδώ η ομάδα πλατφόρμας κατέχει ένα gateway, quotas, υποδομή αξιολόγησης, και απόδοση κόστους, ενώ οι ομάδες προϊόντος κατέχουν prompts και features. Το ένστικτο της ομάδας πλατφόρμας είναι ότι το να κατέχει μοντέλα είναι το φυσικό επόμενο βήμα. Συνήθως δεν είναι. Το πολύτιμο πράγμα που παρέχει είναι η ραφή ανάμεσα στις ομάδες προϊόντος και το inference: routing, κλειδιά, budgets, evals, audit. Εκείνη η ραφή αξίζει να χτιστεί πάνω στο Bedrock, και είναι ακριβώς το σχήμα που περιέγραψα στο LLM Gateways: Why Every Platform Team Builds One Eventually. Η προσθήκη του SageMaker σημαίνει η προσθήκη "τρέχουμε τα μοντέλα" σε μια ομάδα που είναι ήδη το σημείο συμφόρησης για έξι άλλες ομάδες.

Μια ομάδα ML που ήδη κατέχει μοντέλα

Η ομάδα έχει ένα pipeline εκπαίδευσης, ένα feature store, ένα model registry, και ένα υπάρχον endpoint για το οποίο κρατά εφημερία. Για αυτούς το SageMaker δεν είναι νέο βάρος, είναι το βάρος που ήδη κουβαλούν, εργαλειοποιημένο. Η ενδιαφέρουσα κίνηση εδώ συνήθως δεν είναι η επιλογή, είναι η παραδοχή ότι θα τρέξουν και τα δύο: SageMaker για τα μοντέλα που είναι το προϊόν, Bedrock για τη γενική γλωσσική δουλειά γύρω του. Κανείς δεν πρέπει να κάνει fine-tune ένα μοντέλο για να γράφει commit summaries σε μια εταιρεία που τρέχει επίσης ένα πραγματικό μοντέλο κατάταξης.

Οι λόγοι που πραγματικά επιβάλλουν το SageMaker

Τρεις, από την εμπειρία μου, και είναι όλοι συγκεκριμένοι.

  • Το μοντέλο είναι το προϊόν, ή η διαφοροποίησή του. Βαθμολόγηση απάτης, κατάταξη, πρόβλεψη, οτιδήποτε όπου τα weights σου κωδικοποιούν κάτι που ένας ανταγωνιστής δεν μπορεί να αγοράσει. Δεν μπορείς να αναθέσεις εξωτερικά αυτό που πουλάς.
  • Τα weights ή τα δεδομένα δεν μπορούν να φύγουν από ένα όριο που ελέγχεις με τρόπο που ένα managed inference API δεν μπορεί να ικανοποιήσει, και έχεις διαβάσει την πραγματική απαίτηση αντί απλώς να την επαναλάβεις. Αυτό διεκδικείται πολύ πιο συχνά απ' όσο επιβιώνει σε έλεγχο.
  • Χρειάζεσαι ένα μοντέλο που κανείς δεν σου εξυπηρετεί, ένα συγκεκριμένο open-weight checkpoint ή μια παραλλαγή προσαρμοσμένη σε τομέα, και έχεις μετρήσει ένα πραγματικό κενό έναντι των hosted επιλογών αντί να το υποθέσεις.

Πρόσεξε τι δεν είναι στη λίστα: το κόστος. Το self-hosting είναι φθηνότερο ανά token σε υψηλή, σταθερή χρήση και σημαντικά ακριβότερο σε όλα τα υπόλοιπα, επειδή πληρώνεις για ένα instance είτε εξυπηρετεί κίνηση είτε όχι, και επειδή τώρα πληρώνεις μισθούς για capacity planning. Το επιχείρημα του κόστους είναι ένα επιχείρημα χρήσης μεταμφιεσμένο, και χρειάζεται έναν αριθμό προσαρτημένο για να μετρήσει.

Πώς η απόφαση συνήθως πάει στραβά

Η κοινή αποτυχία είναι μια αρχιτεκτονική επιλεγμένη για έναν φιλόδοξο οργανισμό. Μια ομάδα επιλέγει το SageMaker επειδή ένα slide του roadmap λέει ότι θα χτίσουν ιδιόκτητα μοντέλα του χρόνου. Χτίζουν το pipeline, κυκλοφορούν ένα fine-tune, το headcount για την ομάδα ML ποτέ δεν προσγειώνεται, και δύο χρόνια αργότερα ένας μηχανικός προϊόντος ανεβάζει νευρικά έναν τύπο instance σε ένα endpoint που κανείς δεν μπορεί να εξηγήσει. Η τεχνολογία ήταν εντάξει. Ο οργανισμός που υπέθετε ποτέ δεν εμφανίστηκε.

Η αντίστροφη αποτυχία υπάρχει αλλά είναι ηπιότερη και ευκολότερο να διορθωθεί. Μια ομάδα στο Bedrock ανακαλύπτει μια γνήσια ανάγκη για ένα μοντέλο που πρέπει να κατέχει, και μεταφέρει εκείνο το ένα workload. Η μεταφορά ενός workload από ένα managed API σε ένα ιδιόκτητο artifact είναι ένα project. Η απόσυρση μιας ακατοχύρωτης πλατφόρμας ML είναι μια αρχαιολογική ανασκαφή.

Το τεστ

Κάνε μία ερώτηση στην αναθεώρηση σχεδιασμού: ποιος καλείται όταν η ποιότητα αυτού του μοντέλου υποβαθμίζεται, και τι κάνει γι' αυτό;

Αν η απάντηση κατονομάζει ένα άτομο, περιγράφει μια σουίτα αξιολόγησης που εγκρίνει ένα rollback, και ο manager εκείνου του ατόμου συμφωνεί, το SageMaker είναι διαθέσιμο σε εσένα. Αν η απάντηση είναι "θα το κοιτάξουμε" ή κατονομάζει μια ομάδα που δεν υπάρχει ακόμα, μόλις ανακάλυψες ότι ο οργανισμός σου καταναλώνει νοημοσύνη αντί να την παράγει. Χτίσε για αυτό. Δεν είναι μικρότερη φιλοδοξία, είναι ακριβής, και ο περιορισμός που δεσμεύει αυτές τις ομάδες σχεδόν ποτέ δεν είναι η κατοχή μοντέλου. Είναι η αξιολόγηση, που είναι μια πειθαρχία που χρειάζεσαι και στους δύο δρόμους και που θα υποστήριζα ότι είναι η πραγματική προϋπόθεση και για τους δύο.

Το συμπέρασμα

Επίλεξε το SageMaker όταν μια ομάδα κατέχει model artifacts ως μόνιμη ευθύνη, με εφημερία και σουίτα αξιολόγησης από πίσω της. Επίλεξε το Bedrock όταν ο οργανισμός σου καταναλώνει έξοδο μοντέλου για να χτίσει features, που είναι οι περισσότεροι οργανισμοί, τις περισσότερες φορές. Το failure mode του να το κάνεις λάθος δεν είναι ένα κακό benchmark. Είναι υποδομή χωρίς owner, που φθείρεται σιωπηλά μέχρι να αποτύχει δυνατά. Επίλεξε για το οργανόγραμμα που έχεις.

Διάβασε αυτό στη συνέχεια

Η εκδοχή αυτού του επιχειρήματος για ομάδες πλατφόρμας, για το ποιος κατέχει clusters και pipelines αντί για μοντέλα, βρίσκεται στο ercan.cloud. Ο κόμβος είναι στο ercanermis.com.