Ένας μεγάλος εταιρικός οργανισμός IT έχει πέντε εφαρμογές generative AI σε production, έντεκα deployments μοντέλων μοιρασμένα σε τρία Azure subscriptions, έναν μηνιαίο λογαριασμό κάπου γύρω στα 38.000 ευρώ, και κανέναν αξιόπιστο τρόπο να απαντήσει ποια από τις πέντε τα ξόδεψε. Τίποτα δεν είναι χαλασμένο. Κάθε εφαρμογή δουλεύει, κάθε ομάδα παρέδωσε, κάθε επιθεώρηση ασφάλειας πέρασε στην ώρα της. Αυτό που δεν υπάρχει είναι ένα και μοναδικό σημείο όπου ένα token μετριέται, ένας καλών ταυτοποιείται, ή ένα μοντέλο αποσύρεται, και αυτή η απουσία είναι αυτό που χτίζει αυτή η σειρά δέκα μερών: ένα GenAI gateway με διακυβέρνηση στο Azure, από το οποίο περνά κάθε εφαρμογή, και το οποίο τίποτα δεν παρακάμπτει.

Η εταιρεία, και τι πραγματικά πληρώνει

Ας πούμε την εταιρεία αυτό που είναι: ένας εδραιωμένος εταιρικός οργανισμός IT, περίπου 400 μηχανικοί σε γύρω στις 40 ομάδες προϊόντος, τα περισσότερα workloads στο Azure, μια ομάδα πλατφόρμας που ήδη κατέχει τα landing zones και τα CI templates. Το generative AI έφτασε όπως φτάνει συνήθως, από τις άκρες προς τα μέσα. Ένας βοηθός εξυπηρέτησης πελατών βγήκε πρώτος επειδή ένας product owner είχε budget. Μετά ένα εργαλείο σύνοψης για IT operations, ένας εσωτερικός βοηθός κώδικα, μια αναζήτηση γνώσης retail πάνω στην τεκμηρίωση προϊόντων, και ένα εργαλείο κειμένων marketing. Πέντε ομάδες, πέντε αποφάσεις, πέντε απευθείας ενσωματώσεις με το Azure OpenAI.

Καθεμία από αυτές τις αποφάσεις ήταν σωστή μεμονωμένα. Μαζί παράγουν ένα συγκεκριμένο και πλέον οικείο σχήμα:

  • Έντεκα deployments μοντέλων σε τρία subscriptions. Δύο από αυτά είναι διπλότυπα του ίδιου μοντέλου στο ίδιο region, δημιουργημένα επειδή μια ομάδα δεν μπορούσε να πάρει quota συνδεδεμένο στον πόρο που ήδη είχε.
  • Γύρω στα 38.000 ευρώ τον μήνα σε δαπάνη μοντέλων που το cost management αναφέρει σε επίπεδο subscription, που σημαίνει ότι μπορεί να πει στο finance το σύνολο και δεν μπορεί να πει σε κανέναν product owner το δικό του νούμερο.
  • Τέσσερις από τις πέντε εφαρμογές κρατούν ένα κλειδί στα application settings. Μία το κρατούσε σε repository μέχρι να το βρει ένας secret scanner. Καμία εφαρμογή δεν μπορεί να ανακληθεί μεμονωμένα χωρίς έναν μηχανικό να επεξεργαστεί τη διαμόρφωση αυτής της εφαρμογής.
  • Μια ειδοποίηση απόσυρσης μοντέλου με προθεσμία 60 ημερών έφτασε με ένα email, και η ομάδα πλατφόρμας ξόδεψε δύο ημέρες κάνοντας grep σε repositories για να βρει ποιες εφαρμογές θα έσπαγαν, επειδή τίποτα δεν κατέγραφε ποια εφαρμογή καλούσε ποια έκδοση μοντέλου.

Και μετά, το περιστατικό που πραγματικά επέβαλε την απόφαση. Ένα batch job στο εργαλείο κειμένων marketing κατανάλωσε το μεγαλύτερο μέρος του tokens-per-minute quota σε ένα κοινόχρηστο deployment για περίπου σαράντα λεπτά. Ο βοηθός εξυπηρέτησης πελατών, που μοιραζόταν αυτό το deployment, άρχισε να επιστρέφει HTTP 429 σε πραγματικούς πελάτες. Καμία από τις δύο ομάδες δεν έκανε κάτι λάθος. Δεν υπήρχε κανένας μηχανισμός στη διαδρομή όπου να μπορεί να εκφραστεί το «ένας καλών δεν πρέπει να εξαντλεί το quota από το οποίο εξαρτάται ένας άλλος», επειδή δεν υπήρχε καθόλου κοινή διαδρομή.

Αυτά είναι τα ειλικρινή επιχειρήματα για ένα gateway. Όχι «ο κεντρικός έλεγχος είναι καλή αρχιτεκτονική». Είναι ότι το quota, η κατανομή κόστους, η εναλλαγή credentials και ο κύκλος ζωής των μοντέλων είναι όλα ιδιότητες της κλήσης, και αν κανένα component δεν βλέπει κάθε κλήση, καμία από αυτές δεν μπορεί να επιβληθεί πουθενά παρά μόνο κατά σύμβαση.

Τι κοστίζει πραγματικά το μοτίβο ανά εφαρμογή

Η απευθείας ενσωμάτωση είναι γνησίως φθηνότερη την πρώτη μέρα. Ένας SDK client, ένα κλειδί, ένα endpoint, καμία ομάδα πλατφόρμας στο κρίσιμο μονοπάτι. Το κόστος φτάνει αργότερα και προσγειώνεται κάπου αλλού από την ομάδα που το επέλεξε, και ακριβώς γι' αυτό το μοτίβο συνεχίζει να επιλέγεται.

Τα κόστη που συσσωρεύονται είναι τρία, και είναι όλα το ίδιο κόστος με διαφορετικά ρούχα. Κόστος αλλαγής: μια απόσυρση μοντέλου, μια αλλαγή τιμής, μια μετακίνηση region, ή μια διακοπή provider πρέπει να αντιμετωπιστεί μία φορά ανά εφαρμογή, από πέντε ομάδες με πέντε backlogs και πέντε διαφορετικά επίπεδα ενδιαφέροντος. Κόστος κατανομής: η δαπάνη είναι ορατή ανά πόρο και αόρατη ανά καταναλωτή, οπότε σε κανέναν δεν μπορεί να δοθεί budget, που σημαίνει ότι σε κανέναν δεν μπορεί να δοθεί όριο. Κόστος διακυβέρνησης: κάθε νέος έλεγχος, καταγραφή prompts, απάλειψη PII, μια απαίτηση διαφάνειας του EU AI Act, πρέπει να υλοποιηθεί πέντε φορές και να επαληθευτεί πέντε φορές, και η προσπάθεια επιθεώρησης κλιμακώνεται με τον αριθμό των εφαρμογών αντί με τον αριθμό των ελέγχων.

Ένα gateway δεν εξαφανίζει αυτά τα κόστη. Τα μεταφέρει σε ένα σημείο όπου μια ομάδα πλατφόρμας μπορεί να τα πληρώσει μία φορά. Αυτό είναι όλο το επιχείρημα, και αξίζει να είσαι καχύποπτος απέναντι σε οποιαδήποτε πλουσιότερη εκδοχή του.

Να το χτίσουμε ή να το αγοράσουμε στο Azure

Η ομάδα αξιολόγησε τρία σχήματα, και η απάντηση δεν είναι αυτή που θα ήθελε ένας μηχανικός.

Το Azure API Management ως AI gateway. Το API Management προσφέρει ένα σύνολο δυνατοτήτων ρητά στοχευμένων στην κίνηση γλωσσικών μοντέλων, και η λίστα είναι μεγαλύτερη από όσο υποθέτουν οι περισσότεροι πριν τη διαβάσουν. Η πολιτική llm-token-limit επιβάλλει tokens-per-minute ή ένα quota tokens ανά ώρα, ημέρα, εβδομάδα, μήνα ή έτος πάνω σε οποιοδήποτε counter key, συμπεριλαμβανομένου ενός subscription key, μιας IP καλούντος, ή μιας αυθαίρετης policy expression, και μπορεί να προϋπολογίζει τα prompt tokens στο gateway ώστε ένα αίτημα πάνω από το όριο να μη φτάνει ποτέ στο backend. Οι πολιτικές llm-semantic-cache-store και llm-semantic-cache-lookup κάνουν caching ολοκληρώσεων με βάση την ομοιότητα διανυσμάτων πάνω σε Azure Managed Redis ή άλλη cache συμβατή με RediSearch. Η πολιτική llm-emit-token-metric εκπέμπει μετρήσεις tokens στο Application Insights με custom dimensions, που είναι η πρώτη ύλη για κατανομή ανά καταναλωτή. Τα backends υποστηρίζουν round-robin, weighted, priority-based και session-aware load balancing, και έναν circuit breaker του οποίου η διάρκεια ενεργοποίησης σέβεται το Retry-After header του ίδιου του backend, ώστε ένα pay-as-you-go endpoint να μπορεί να απορροφά την υπερχείλιση από ένα κορεσμένο deployment Provisioned Throughput Unit χωρίς κανείς να γράψει κώδικα retry.

Η κάλυψη providers μετράει εδώ και είναι εύκολο να την καταλάβεις λάθος. Το API Management διαμεσολαβεί APIs γλωσσικών μοντέλων που ακολουθούν τα σχήματα OpenAI Chat Completions και Responses, το Anthropic Messages API (στα v2 tiers), και το Google Vertex AI API, απέναντι σε μοντέλα deployed στο Microsoft Foundry ή σε providers εκτός Microsoft, συμπεριλαμβανομένου του Amazon Bedrock. Ένα unified model API, σε preview τη στιγμή που γράφονται αυτά, εκθέτει πολλά backends πίσω από ένα μοναδικό endpoint συμβατό με OpenAI και μεταφράζει μορφές, ώστε ένα και μόνο σύνολο πολιτικών διακυβέρνησης να ισχύει σε όλους τους providers. Τα Anthropic Claude, Mistral και Llama είναι προσβάσιμα μέσα από αυτό το επίπεδο αντί να απαιτούν το καθένα ξεχωριστή ενσωμάτωση.

Ένα open-source proxy σε AKS. Το LiteLLM και παρόμοια projects σου δίνουν μετάφραση providers και δρομολόγηση σε ένα container που ελέγχεις πλήρως, με ταχύτερο δρόμο προς ένα feature που θέλεις και καμία εξάρτηση από preview. Κληρονομείς όμως μια βάρδια on-call για ένα component που πλέον κάθεται μπροστά από κάθε αίτημα AI στην εταιρεία, συν τη δουλειά ταυτότητας, δικτύου και audit που το API Management έχει ήδη πιστοποιημένη.

Μια εξατομικευμένη υπηρεσία FastAPI. Μέγιστος έλεγχος, και η μόνη επιλογή όπου κάθε αποτυχία είναι δική σου. Λογική για ένα component με γνησίως ασυνήθιστες απαιτήσεις, κάτι που ένα reverse proxy που μετρά tokens δεν είναι.

Η απόφαση που ακολουθεί αυτή η σειρά: το API Management είναι το data plane, και όσα δεν κάνει το API Management χτίζονται ως ένα μικρό Python control plane σε AKS. Αυτός είναι ο διαχωρισμός που αξίζει να εσωτερικεύσεις, γιατί εκεί πάνε στραβά τα περισσότερα projects gateway. Οι ομάδες είτε προσπαθούν να εκφράσουν τα πάντα ως policy XML, που παράγει ένα μη συντηρήσιμο artifact που κανείς δεν μπορεί να τεστάρει, είτε δρομολογούν την κίνηση μέσα από τη δική τους υπηρεσία και ξαναϋλοποιούν κακώς το rate limiting. Το gateway μεταφέρει το αίτημα. Το control plane μεταφέρει την κατάσταση: ποια μοντέλα υπάρχουν, ποιος επιτρέπεται να τα καλέσει, τι κοστίζει μια κλήση, και τι συμβαίνει όταν ένα μοντέλο αποσύρεται.

Τι εξακολουθείς να χτίζεις

Πέντε πράγματα, και καθένα τους είναι ένα επόμενο μέρος αυτής της σειράς.

  • Ένας κατάλογος μοντέλων και ένας κύκλος ζωής. Ποια λογικά ονόματα μοντέλων υπάρχουν, ποια φυσικά deployments τα υποστηρίζουν, ποια είναι deprecated και πότε εξαφανίζονται. Οι εφαρμογές πρέπει να καλούν chat-default, ποτέ ένα όνομα deployment, αλλιώς το email απόσυρσης των 60 ημερών ξαναγίνεται ένα project μετάβασης 60 ημερών.
  • Ταυτότητα tenant και onboarding. Μια ομάδα παίρνει ένα client credential, ένα quota, ένα allowlist μοντέλων και ένα cost centre, provisioned ως κώδικας αντί ως ticket.
  • Κατανομή κόστους και chargeback. Οι μετρήσεις tokens με διάσταση tenant είναι μόνο η είσοδος. Το να τις μετατρέψεις σε ένα μηνιαίο νούμερο ανά ομάδα που το δέχεται το finance είναι ένα data pipeline με τα δικά του tests.
  • Πύλες αξιολόγησης στο pipeline. Η προαγωγή μιας νέας έκδοσης μοντέλου είναι deployment. Ένα deployment που αλλάζει τη συμπεριφορά του μοντέλου χωρίς συνημμένο αποτέλεσμα eval είναι μια βλάβη που περιμένει να τη βρει ένας πελάτης.
  • Ασύγχρονη και μακράς διάρκειας δουλειά. Η batch σύνοψη των tickets υποστήριξης δεν ανήκει στο ίδιο σύγχρονο μονοπάτι με έναν πελάτη που περιμένει το πρώτο token. Αυτός ο διαχωρισμός είναι μια ουρά, όχι μια ρύθμιση timeout.

Στοχευόμενη αρχιτεκτονική

Η πλατφόρμα είναι σκόπιμα βαρετή και σκόπιμα προσθετική. Αν το control plane πέσει, το data plane συνεχίζει να εξυπηρετεί κίνηση με την τελευταία γνωστή διαμόρφωσή του, επειδή ένα gateway που κλείνει όταν πέφτει το control plane είναι μια βλάβη σε ολόκληρη την εταιρεία.

graph TD
  subgraph consumers["Consumer apps"]
    A1["customer-service assistant"]
    A2["IT-ops summarizer"]
    A3["code assistant"]
    A4["retail knowledge search"]
    A5["marketing copy tool"]
  end

  subgraph gw["Data plane: API Management"]
    POL["policies:
llm-token-limit, semantic cache,
emit-token-metric, JWT validate"]
    LB["backend pool:
priority + weighted, circuit breaker"]
  end

  subgraph cp["Control plane: Python on AKS"]
    CAT["model catalog"]
    TEN["tenant registry"]
    COST["cost attribution job"]
  end

  subgraph models["Model layer"]
    FDRY["Microsoft Foundry:
GPT deployments, PTU + PAYG"]
    ANTH["Anthropic Claude"]
    OSS["Mistral, Llama"]
  end

  ID["Microsoft Entra ID"]
  RED["Azure Managed Redis
semantic cache"]
  SRCH["Azure AI Search
retrieval"]
  MON["Azure Monitor +
Application Insights"]

  A1 --> POL
  A2 --> POL
  A3 --> POL
  A4 --> POL
  A5 --> POL

  ID -. "OAuth2 client credentials" .-> POL
  POL --> LB
  POL <--> RED
  LB --> FDRY
  LB --> ANTH
  LB --> OSS
  POL -- token metrics, prompt logs --> MON
  CAT -. "backend + policy config" .-> gw
  TEN -. "subscriptions, quotas" .-> gw
  MON --> COST
  A4 -. "grounding data" .-> SRCH

Δύο ιδιότητες αυτού του διαγράμματος σηκώνουν το βάρος. Πρώτον, κάθε βέλος προς το επίπεδο μοντέλων ξεκινά μέσα από το API Management, που σημαίνει ότι οι κανόνες δικτύου στους πόρους Foundry αρνούνται οτιδήποτε άλλο: το gateway δεν είναι μια πρόταση, είναι η μόνη διαδρομή που έχει μονοπάτι. Δεύτερον, το control plane γράφει διαμόρφωση μέσα στο gateway και διαβάζει τηλεμετρία από το Azure Monitor, αλλά δεν κάθεται ποτέ στο μονοπάτι του αιτήματος. Μπορεί να γίνει redeploy μέρα μεσημέρι.

Το stack, σε ένα σημείο

Τι αγγίζουν τα δέκα μέρη, ώστε το σχήμα της σειράς να φαίνεται από εδώ. Infrastructure as code σε Terraform, με τη σύγκριση με Bicep και ARM να γίνεται τίμια στο Μέρος 2 αντί να προσπερνιέται ως δεδομένη. Docker images και AKS για το control plane. Azure DevOps για pipelines, versioning και release management. Python παντού όπου ζει η λογική. Microsoft Entra ID με OAuth2 client credentials και API keys όπου ένας legacy καλών δεν μπορεί να κάνει κάτι καλύτερο. Azure AI Search και μια αποκλειστική vector βάση για retrieval, συγκρινόμενες αντί να ανακηρύσσεται νικητής εκ των προτέρων. Azure Managed Redis για semantic caching. Azure Monitor και Application Insights για την τηλεμετρία, δίπλα σε LLM-specific observability με LangSmith και Openlayer, και Dataiku όπου ήδη ζει μια ομάδα data science. LangChain για ενορχήστρωση στο ένα μέρος όπου ένα framework κερδίζει τη θέση του, και στα μέρη όπου δεν την κερδίζει. Streaming πάνω από server-sent events, WebSockets όπου ένα session είναι γνησίως αμφίδρομο, και μια ουρά μηνυμάτων για ό,τι δεν χρειάζεται απάντηση τώρα.

Τα δέκα μέρη, με τη σειρά: τα επιχειρήματα για ένα gateway· Terraform απέναντι σε Bicep και ARM· η αφαίρεση provider και το streaming· ασύγχρονη και event-driven δουλειά· ταυτότητα, quota και chargeback· semantic caching· retrieval με Azure AI Search απέναντι σε μια πραγματική vector βάση· ενορχήστρωση πάνω από το gateway· CI/CD και κύκλος ζωής μοντέλων στο Azure DevOps· και observability με διακυβέρνηση AI.

Πώς μοιάζει το «καλό»

Το τελευταίο μέρος επιστρέφει σε αυτά, που είναι οι τέσσερις αριθμοί από την απογραφή της χειρωνακτικής δουλειάς, μετρήσιμοι πλέον:

  • Κάθε product owner μπορεί να δει τη δική του δαπάνη tokens για τον τρέχοντα μήνα, μέσα σε μία ημέρα από τη στιγμή που προκύπτει, χωρίς να ρωτήσει την ομάδα πλατφόρμας.
  • Καμία εφαρμογή δεν κρατά μακρόβιο credential μοντέλου. Η ανάκληση της πρόσβασης μιας ομάδας είναι μια αλλαγή διαμόρφωσης στο tenant registry, όχι μια επεξεργασία στα app settings αυτής της ομάδας.
  • Μια ειδοποίηση απόσυρσης μοντέλου παράγει ένα query, όχι μια έρευνα: ο κατάλογος ήδη ξέρει ποιοι tenants κατέληξαν σε αυτό το deployment τις τελευταίες 30 ημέρες.
  • Ένας tenant δεν μπορεί να εξαντλήσει το quota ενός άλλου tenant, επαληθευμένο με την αναπαραγωγή του παραπάνω περιστατικού 429 ως load test απέναντι στο gateway.
  • Η διάμεση πρόσθετη καθυστέρηση από το gateway μένει κάτω από 60 milliseconds στο 95ο εκατοστημόριο για μη-cached κλήσεις, και τα semantic cache hits επιστρέφουν σε ένα κλάσμα μιας κλήσης μοντέλου.

Τρόποι αποτυχίας που πρέπει να προσέχεις από την πρώτη μέρα

Τρεις, και αξίζει να ονομαστούν πριν γραφτεί οποιοδήποτε Terraform. Το gateway γίνεται μοναδικό σημείο αποτυχίας τη στιγμή που είναι η μόνη διαδρομή, που είναι άλλωστε και το ζητούμενο, οπότε ο στόχος διαθεσιμότητάς του πρέπει να είναι υψηλότερος από αυτόν της πιο απαιτητικής εφαρμογής πίσω του, και το deployment του πρέπει να είναι zone-redundant από το πρώτο apply αντί μετά το πρώτο περιστατικό. Η εξάπλωση πολιτικών φτάνει αθόρυβα: το policy XML είναι κώδικας, εκτελείται σε κάθε αίτημα, και είναι εύκολο να γραφτεί σε ένα σημείο όπου κανείς δεν το επιθεωρεί. Ανήκει στο version control με την υπόλοιπη πλατφόρμα, εφαρμόζεται από pipeline, και δεν επεξεργάζεται ποτέ στο portal. Και το μονοπάτι παράκαμψης ακυρώνει όλα τα υπόλοιπα, επειδή μία και μόνη ομάδα που κρατά απευθείας κλειδί σε ένα endpoint Foundry κάνει κάθε νούμερο κατανομής και κάθε εγγύηση quota προσεγγιστικά. Αυτό είναι ένας κανόνας δικτύου και ένα alert, όχι ένα έγγραφο πολιτικής.

Διάβασε επίσης

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

Αναφορές