Το πρώτο LLM feature ξεκινά ως άμεση κλήση από μια υπηρεσία προς το Bedrock. Το δέκατο ξεκινά με τον ίδιο τρόπο, από δέκα υπηρεσίες, με δέκα σετ διαπιστευτηρίων, δέκα πολιτικές retry, και κανένα ενιαίο σημείο για να δει κανείς τι ξοδεύει ο καθένας. Εκείνη είναι η στιγμή που μια ομάδα πλατφόρμας ανακαλύπτει ότι χρειάζεται ένα LLM gateway, συνήθως ένα τρίμηνο μετά το σημείο όπου θα ήταν φθηνό να το χτίσει. Το gateway είναι η κοινή είσοδος από την οποία περνά κάθε κλήση μοντέλου, και υπάρχει για να κατέχει τα τέσσερα πράγματα που οι μεμονωμένες ομάδες συνεχίζουν να επανεφευρίσκουν άσχημα: authentication, quota, routing και audit.

Το χρήσιμο reframing είναι ότι το gateway δεν είναι ένα AI feature. Είναι το ίδιο control plane που ήδη βάζεις μπροστά από κάθε κοινόχρηστη, μετρημένη, ακριβή εξάρτηση. Δεν θα άφηνες κάθε υπηρεσία να κρατά τον δικό της κωδικό database admin και να επιλέγει το δικό της όριο σύνδεσης. Η πρόσβαση στο μοντέλο δεν διαφέρει, μόνο που ο λογαριασμός μεγαλώνει πιο γρήγορα και τα failure modes είναι πιο θορυβώδη.

Τι συγκεντρώνει πραγματικά το gateway

Η αξία δεν βρίσκεται στο proxying του αιτήματος. Βρίσκεται στην κατοχή των τεσσάρων εγκάρσιων ζητημάτων που δεν ανήκουν στον κώδικα εφαρμογής:

  • Authentication. Οι καλούντες παρουσιάζουν μια ταυτότητα υπηρεσίας στο gateway. Το gateway κρατά το ένα credential που μιλά με το Bedrock. Καμία εφαρμογή δεν βλέπει ποτέ ένα μακροχρόνιο κλειδί μοντέλου, και η περιστροφή αυτού του κλειδιού είναι μία αλλαγή, όχι είκοσι.
  • Quota. Τα budgets tokens ανά ομάδα και ανά μοντέλο ζουν σε ένα μέρος. Ένα loop που ξεφεύγει σε μια υπηρεσία χτυπά το δικό του όριο αντί να καταναλώνει το κοινόχρηστο όριο tokens-per-minute και να throttle-άρει όλους τους υπόλοιπους.
  • Routing. Το gateway αντιστοιχίζει ένα λογικό όνομα μοντέλου σε μια συγκεκριμένη ανάπτυξη: ποια περιοχή, ποιος πάροχος, ποιο fallback όταν το πρωτεύον throttle-άρει. Οι εφαρμογές ζητούν "τον summarizer", όχι ένα συγκεκριμένο model ID σε συγκεκριμένη περιοχή.
  • Audit. Κάθε αίτημα και απόκριση περνά από ένα σημείο συμφόρησης, οπότε η απόδοση κόστους, το logging prompts και η ανίχνευση κατάχρησης έχουν όλα ένα ενιαίο σημείο σύνδεσης. Χωρίς αυτό, το κόστος ανά feature γίνεται ένα αρχαιολογικό έργο.

Παρατηρήστε ότι κανένα από αυτά δεν είναι πρόβλημα ποιότητας μοντέλου. Είναι προβλήματα πλατφόρμας που φαίνονται καινούργια μόνο επειδή η εξάρτηση είναι ένα μοντέλο.

Build vs LiteLLM vs API Gateway

Υπάρχουν τρία ειλικρινή πρότυπα, και το σωστό εξαρτάται από το πόσα από τα παραπάνω χρειάζεσαι πραγματικά από την πρώτη μέρα.

Υιοθέτησε το LiteLLM (ή αντίστοιχο proxy)

Ένα open-source proxy σαν το LiteLLM σου δίνει ένα ενοποιημένο API σε παρόχους, budgets ανά κλειδί και βασικό routing εξ ορισμού. Είναι ο ταχύτερος τρόπος να αποκτήσεις ένα πραγματικό gateway που ήδη γνωρίζει τα τέσσερα ζητήματα. Το trade-off είναι ότι τρέχεις και κάνεις patch μια stateful υπηρεσία που κάθεται στο κρίσιμο μονοπάτι κάθε AI feature, και οι απόψεις της για routing και logging γίνονται οι δικές σου απόψεις. Για τις περισσότερες ομάδες που στήνουν το δεύτερο ή τρίτο LLM feature, αυτό είναι η σωστή προεπιλογή. Αγοράζεις το control plane αντί να το χτίζεις.

Βάλ' το σε API Gateway και Lambda

Αν είσαι ήδη βαθιά μέσα στο AWS, το Amazon API Gateway μπροστά από ένα μικρό Lambda authorizer και μια proxy function σου δίνει auth, usage plans, throttling και access logs από primitives που ήδη λειτουργείς. Τα usage plans διαχειρίζονται τα per-key rate limits, ο authorizer διαχειρίζεται την ταυτότητα, το CloudWatch διαχειρίζεται το audit trail. Το κόστος είναι ότι η λογική ειδική για το μοντέλο, το streaming, η μέτρηση tokens και το provider fallback είναι κώδικας που γράφεις και κατέχεις. Αυτό το πρότυπο κερδίζει όταν οι απαιτήσεις διακυβέρνησής σου έχουν σχήμα AWS και προτιμάς να επεκτείνεις μια υπάρχουσα πλατφόρμα παρά να εισάγεις νέα εξάρτηση.

Χτίσε μια εξατομικευμένη υπηρεσία

Το να χτίσεις τη δική σου είναι σωστό μόνο όταν οι απαιτήσεις σου για routing ή audit είναι γνήσια ασυνήθιστες: πολύπλοκες πολιτικές επιλογής μοντέλου, αποφάσεις τοποθεσίας δεδομένων ανά αίτημα, ή logging που πρέπει να ικανοποιεί έναν ρυθμιστή σε συγκεκριμένη μορφή. Οι περισσότερες ομάδες που χτίζουν από το μηδέν στην πραγματικότητα ξαναχτίζουν το LiteLLM πιο αργά. Πήγαινε σε αυτό τελευταίο, και μόνο όταν μπορείς να ονομάσεις την απαίτηση που δεν καλύπτει η έτοιμη λύση.

Το failure mode που αποτρέπει ένα gateway

Χωρίς gateway, η αποτυχία δεν είναι δραματική, είναι αργή. Τα διαπιστευτήρια απλώνονται. Κάθε ομάδα ρυθμίζει το δικό της timeout και retry, οπότε ένα προσωρινό πρόβλημα του παρόχου γίνεται μια θύελλα retry που σε σπρώχνει μέσα από το quota tokens σου. Κανείς δεν μπορεί να απαντήσει "πόσο κόστισε το feature support-summarizer τον περασμένο μήνα" χωρίς να κάνει grep σε logs σε όλες τις υπηρεσίες. Έπειτα μια αναθεώρηση ασφαλείας ρωτά ποιος μπορεί να καλέσει ποιο μοντέλο με ποια δεδομένα, και η ειλικρινής απάντηση είναι "δεν είμαστε σίγουροι", που είναι η απάντηση που σταματά μια κυκλοφορία.

Ένα gateway μετατρέπει όλα αυτά σε ρύθμιση. Αυτό είναι όλο το επιχείρημα: μετακίνησε τις εγκάρσιες αποφάσεις από είκοσι codebases σε ένα που μπορείς να κατανοήσεις.

Χάραξε τη γραμμή στο σωστό σημείο

Κράτα το gateway λεπτό. Πρέπει να χειρίζεται ταυτότητα, quota, routing και logging, και να μένει έξω από την κατασκευή prompt και τη λογική επιχείρησης. Τη στιγμή που το gateway αρχίζει να κατέχει prompts, γίνεται μια κοινόχρηστη βιβλιοθήκη με network hop, και κάθε ομάδα μπλοκάρεται στον κύκλο κυκλοφορίας του. Ο διαρκής σχεδιασμός είναι ένα βαρετό proxy με ισχυρές απόψεις για διακυβέρνηση και καμία άποψη για το τι ζητάς από το μοντέλο.

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

Κάθε ομάδα πλατφόρμας που κυκλοφορεί περισσότερα από ένα LLM feature χτίζει τελικά ένα gateway. Η μόνη επιλογή είναι αν θα το χτίσεις σκόπιμα, νωρίς, όσο είναι ένα μικρό proxy, ή κατά λάθος, αργά, ως ένα project καθαρισμού αφού τα διαπιστευτήρια έχουν απλωθεί και ο λογαριασμός έχει γίνει μυστήριο. Υιοθέτησε ένα proxy αν μπορείς, επέκτεινε το API Gateway αν είσαι AWS-native, και χτίσε από το μηδέν μόνο απέναντι σε μια απαίτηση που μπορείς να ονομάσεις. Το gateway δεν είναι εκεί που συμβαίνει το AI. Είναι εκεί που η διακυβέρνηση που θα χρειαζόσουν ούτως ή άλλως βρίσκει επιτέλους ένα σπίτι.

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

Για την πλευρά πλατφόρμας και υποδομής της λειτουργίας ενός κοινόχρηστου control plane σαν αυτό, οι σημειώσεις πεδίου cloud βρίσκονται στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.