Agents on Call, Μέρος 7. Διαστασιολόγηση: Τα Μαθηματικά των Tokens που Κανείς δεν Κάνει από Πριν

Μία μόνο βαθιά διερεύνηση περιστατικού σε αυτή την πλατφόρμα, οκτώ γύροι κλήσεων εργαλείων μέχρι ο triage agent να έχει αρκετά στοιχεία για να προτείνει μια διάγνωση, κοστίζει 32.950 tokens, και τα 31.600 από αυτά είναι είσοδος, γιατί το Converse API του Bedrock ξαναστέλνει ολόκληρο το διαρκώς αυξανόμενο transcript σε κάθε γύρο. Πολλαπλασίασέ το με πραγματικό όγκο ειδοποιήσεων και ολόκληρος ο μηνιαίος on-demand λογαριασμός μοντέλου της πλατφόρμας βγαίνει περίπου 14 $, μία από τις μικρότερες γραμμές σε ένα συνολικό μηνιαίο κόστος κοντά στα 21 $. Η αγορά Provisioned Throughput από την πρώτη μέρα, αυτό που το Μέρος 1 ρητά ανέβαλε, θα κόστιζε 15.768 $ τον μήνα για ένα φορτίο που τρέχει περίπου στο ένα τετρακοσιοστό της χρησιμοποίησης που χρειάζεται για να ισοφαρίσει. Τίποτα από αυτά δεν είναι προφανές από ένα διάγραμμα. Εμφανίζεται μόνο όταν κάποιος κάνει την αριθμητική, που είναι αυτό που κάνει αυτό το μέρος, από άκρη σε άκρη, με κάθε αριθμό ανιχνεύσιμο είτε σε έναν τιμοκατάλογο Bedrock είτε σε έναν τύπο που δείχνεται πλήρως.

Το Μέρος 1 έστησε το σενάριο, 40 ειδοποιήσεις την εβδομάδα σε 30 λογαριασμούς, και επέλεξε AgentCore συν Strands αντί για τις εναλλακτικές. Το Μέρος 2 έχτισε το όριο λογαριασμού και την καλωδίωση των inference profiles, και ονόμασε το ακριβές ερώτημα που απαντά αυτό το μέρος: το σημείο όπου η ωριαία χρέωση του Provisioned Throughput νικά τη χρέωση ανά token του on-demand. Το Μέρος 3 παρέδωσε τον βρόχο κλήσης εργαλείων του triage agent, το πράγμα του οποίου οι γύροι κοστολογούνται παρακάτω. Το Μέρος 4 μετακίνησε εκείνα τα εργαλεία πίσω από το AgentCore Gateway. Το Μέρος 5 πρόσθεσε τους agents supervisor, runbook και cost που ο μηνιαίος λογαριασμός αυτού του μέρους πρέπει πλέον να καλύψει. Το Μέρος 6 έβαλε Guardrails σε κάθε κλήση, μια απόφαση που αποδεικνύεται ότι μετρά για τον λογαριασμό αυτού του μέρους περισσότερο από το αναμενόμενο. Κάθε αριθμός παρακάτω ζει στο docs/sizing-model.md στο συνοδευτικό repository στο github.com/flightlesstux/agents-on-call, μαζί με μια λίστα ελέγχου για την επανεκτέλεσή του με πραγματικούς αριθμούς αντί για αυτούς της φανταστικής εταιρείας.

Τα μαθηματικά των tokens, λυμένο παράδειγμα

Το Converse API δεν κρατά καμία κατάσταση συνομιλίας στην πλευρά του server. Κάθε γύρος κλήσης εργαλείων ξαναστέλνει το πλήρες transcript μέχρι εκείνο το σημείο: system prompt, tool schemas, κάθε προηγούμενη κλήση εργαλείου και το αποτέλεσμά της. Αυτό σημαίνει ότι τα tokens εισόδου δεν μεγαλώνουν γραμμικά με τους γύρους, μεγαλώνουν με το άθροισμα όλων όσων έχουν ήδη σταλεί, και μια μακρύτερη διερεύνηση πληρώνει την ίδια της την ιστορία ξανά και ξανά. Τα δομικά στοιχεία, δηλωμένα ρητά αντί να υποτίθενται: ένα στατικό πρόθεμα 1.800 tokens (system prompt, tool schemas, ρύθμιση guardrail) πανομοιότυπο σε κάθε κλήση, ένα αρχικό payload alarm 400 tokens, 150 tokens εξόδου assistant ανά γύρο, και 350 tokens αποτελέσματος εργαλείου προσαρτημένα ανά γύρο, 500 tokens αύξησης κάθε γύρο. Το μέγεθος εισόδου του γύρου r είναι S + 400 + 500*(r-1).

Μια ρηχή διερεύνηση που επιλύεται σε 3 γύρους μοιάζει έτσι:

Μια βαθιά διερεύνηση που χρειάζεται 8 γύρους, περισσότερους λογαριασμούς, περισσότερα εργαλεία, περισσότερο πήγαινε-έλα μέχρι τα στοιχεία να βγάλουν νόημα, μοιάζει έτσι:

32.950 tokens συνολικά, απέναντι στα 8.700 μιας ρηχής διερεύνησης, ένα κόστος 3,8x για 2,7x αριθμό γύρων. Εκείνο το χάσμα είναι η ποινή του resend ορατή: το total_input(N) = N*(S+400) + 500*N*(N-1)/2 μεγαλώνει τετραγωνικά με τον αριθμό γύρων, όχι γραμμικά, γιατί ο γύρος 8 πληρώνει τους γύρους 1 έως 7 ξανά από την αρχή.

Τα δεδομένα on-call του Μέρους 1 βάζουν πραγματικό όγκο απέναντι σε αυτό: 40 ειδοποιήσεις την εβδομάδα, μοιρασμένες εδώ 70/30 σε 28 ρηχές και 12 βαθιές διερευνήσεις. Αυτό κάνει 243.600 ρηχά tokens και 395.400 βαθιά tokens την εβδομάδα, 639.000 συνολικά, περίπου 2,77 εκατομμύρια tokens τον μήνα μόνο για τον triage agent. Οι agents runbook, cost-sweep και supervisor προσθέτουν χονδρικά άλλο 1,1 εκατομμύριο, για ένα σύνολο σε επίπεδο πλατφόρμας κοντά στα 3,87 εκατομμύρια tokens τον μήνα. Η πλήρης ανάλυση ανά agent, συμπεριλαμβανομένων των ενισχυμένων με Knowledge Base γύρων του runbook agent και της ημερήσιας σάρωσης του cost agent, είναι στο συνοδευτικό έγγραφο· ο αριθμός που αξίζει να κουβαλήσεις στην επόμενη ενότητα είναι ότι τίποτα από αυτά, σε αυτόν τον όγκο, δεν είναι μεγάλο.

Εκρήξεις περιστατικών απέναντι σε μια σταθερή σάρωση

Ο όγκος του cost agent είναι ομαλός επίτηδες: μία προγραμματισμένη εκτέλεση EventBridge τη μέρα, εκτός ωρών αιχμής, χωρίς ποτέ να μοιράζεται ούτε λεπτό με ένα περιστατικό. Ο όγκος του triage agent δεν είναι ομαλός, και οι μέσοι όροι το κρύβουν. Απλωμένα ομοιόμορφα, 606.000 εβδομαδιαία tokens εισόδου είναι περίπου 60 tokens το λεπτό. Τα πραγματικά περιστατικά συσχετίζονται: μία upstream αποτυχία που ξεδιπλώνεται σε οκτώ alarms μέσα στα ίδια πέντε λεπτά ξεκινά οκτώ sessions triage των οποίων οι πρώτοι γύροι προσγειώνονται στο ίδιο παράθυρο TPM, 8 x 2.200 = 17.600 tokens εισόδου σε εκείνο το ένα λεπτό μόνο από το triage, πριν μετρηθούν οι δικές του κλήσεις αποστολής του supervisor. Αυτό είναι χονδρικά 290 φορές ο εξομαλυμένος μέσος όρος, ακριβώς στα δέκα λεπτά που μια διακοπή είναι σε εξέλιξη και η ικανότητα της πλατφόρμας να συνεχίσει να αποκρίνεται μετρά περισσότερο. Διαστασιολόγησε με βάση την κορυφή, όχι τον μέσο όρο· ο μέσος όρος είναι αυτό που εμφανίζεται στο τιμολόγιο του επόμενου μήνα, η κορυφή είναι αυτό που καθορίζει αν μια καταιγίδα alarms θα πάρει απάντηση ή ένα `ThrottlingException`.

Quotas, throttling, και συναγερμός πριν από τον πόνο

Τα δύο endpoints κλήσης του Bedrock επιβάλλουν quotas διαφορετικά, και η διαφορά αλλάζει το τι χτυπά πραγματικά μια έκρηξη. Το endpoint bedrock-runtime μετρά tokens εισόδου και εξόδου μαζί έναντι ενός ενιαίου quota TPM ανά μοντέλο, και το RPM είναι ανά μοντέλο: κάποια κορυφαία μοντέλα δεν κουβαλούν καθόλου quota RPM, διεπόμενα μόνο από tokens. Το endpoint bedrock-mantle χωρίζει είσοδο και έξοδο σε ξεχωριστά quotas tokens και εγκαταλείπει εντελώς το RPM. Σε κάθε περίπτωση, το quota είναι ανά λογαριασμό και ανά region, κοινόχρηστο σε κάθε agent που τρέχει αυτή η πλατφόρμα, όχι κατανεμημένο ανά agent, οπότε οι κλήσεις αποστολής του supervisor και η οκτάγυρη διερεύνηση του triage agent αντλούν από την ίδια δεξαμενή κατά τη διάρκεια μιας συσχετισμένης καταιγίδας alarms. Τα self-service αιτήματα αύξησης quota καλύπτουν και τα δύο endpoints από μια αλλαγή νωρίτερα φέτος, παλαιότερα το bedrock-mantle χρειαζόταν support ticket· αυτό κλείνει ένα πραγματικό κενό αλλά δεν αφαιρεί την ανάγκη να ξέρεις το ταβάνι πριν το βρει ένα περιστατικό.

Η δική του λογική retry του Bedrock SDK κάνει backoff σε μια απόκριση throttling, αλλά αυτό μόνο εξομαλύνει μια έκρηξη, δεν κάνει το περιθώριο quota να εμφανιστεί. Η πιο χρήσιμη κίνηση είναι πιο πάνω στη ροή από οποιοδήποτε retry: συναγερμός πάνω στην ίδια τη χρησιμοποίηση του quota, όχι στο πρώτο ThrottlingException που ένα retry ήδη απορρόφησε. Ένας συναγερμός χρησιμοποίησης quota που πυροδοτείται στο 70% ενός ταβανιού TPM δίνει στον σχεδιασμό χωρητικότητας μια ειδοποίηση μέρες πριν μια καταιγίδα alarms δώσει στον on-call μηχανικό έναν υποβαθμισμένο triage agent. Το να περιμένεις το σφάλμα throttling να είναι το πρώτο σήμα σημαίνει ότι το περιστατικό που χρειάζεται περισσότερο τη βοήθεια αυτής της πλατφόρμας είναι εκείνο όπου ο δικός της προϋπολογισμός σφαλμάτων ξοδεύεται σε retries αντί για κλήσεις εργαλείων.

Cross-region profiles ως περιθώριο για εκρήξεις

Το Μέρος 2 έβαλε αυτή την πλατφόρμα σε cross-region inference profiles παντού, για αξιοπιστία και χωρίς πρόσθετο κόστος ανά token. Η οπτική διαστασιολόγησης εκείνης της απόφασης: ένα quota TPM έχει εμβέλεια στο endpoint μιας region, και η cross-region δρομολόγηση σημαίνει ότι μια έκρηξη που θα εξαντλούσε το ταβάνι μιας region μπορεί να ξεχειλίσει στο ξεχωριστό ταβάνι μιας αδελφής region αντί να μπει σε ουρά πίσω από το όριο μίας μόνο region. Δεν είναι απεριόριστο περιθώριο, και δεν υποκαθιστά τη γνώση του πραγματικού ταβανιού, αλλά μετατρέπει το quota μιας region σε quota μιας ολόκληρης γεωγραφίας με κόστος μηδέν, που είναι καλύτερη συναλλαγή από τα περισσότερα περιθώρια χωρητικότητας που αγοράζει αυτή η πλατφόρμα.

Τα οικονομικά του Provisioned Throughput: το break-even, και γιατί η αγορά του τώρα είναι λάθος

Ένα Model Unit αγοράζει μια σταθερή, πάντα χρεωνόμενη ωριαία τιμή με αντάλλαγμα ένα σταθερό ταβάνι tokens/λεπτό εισόδου και εξόδου, όποια κι αν είναι η τιμή του μοντέλου και η απόδοση του MU για το επιλεγμένο μοντέλο, κανένα από τα δύο δεν δημοσιεύει η AWS ως σταθερό αριθμό ανεξάρτητο του μοντέλου, οπότε ο τύπος παρακάτω χρησιμοποιεί δηλωμένες τιμές placeholder, όχι γεγονότα AWS, και χρειάζεται τους αριθμούς της ζωντανής κονσόλας πριν κανείς ξοδέψει πραγματικά χρήματα πάνω του:

max_monthly_input  = T_in  * 60 * 730   # 730 hours in an average month
max_monthly_output = T_out * 60 * 730

on_demand_equiv_cost = (max_monthly_input  / 1000) * I
                      + (max_monthly_output / 1000) * O

pt_monthly_cost        = P * 730
break_even_utilization = pt_monthly_cost / on_demand_equiv_cost

Με ενδεικτικά placeholders (200.000 tokens εισόδου και 100.000 tokens εξόδου/λεπτό ανά MU, 0,003 $ και 0,015 $ ανά 1.000 tokens on-demand, 21,60 $/MU-ώρα χωρίς δέσμευση): η 100% χρησιμοποίηση του ταβανιού εκείνου του MU αξίζει 91.980 $ τον μήνα σε on-demand, το ίδιο το PT κοστίζει 15.768 $ τον μήνα, και το break-even προσγειώνεται στο 17,14% διατηρούμενη χρησιμοποίηση. Πάνω από εκείνο το κλάσμα, το PT είναι φθηνότερο. Κάτω από αυτό, κερδίζει το on-demand, και η λέξη που κάνει τη δουλειά είναι το διατηρούμενη: πρόκειται για μηνιαίο μέσο όρο, και το παράδειγμα έκρηξης δύο ενότητες πιο πάνω δείχνει ακριβώς γιατί το να χτυπήσεις ένα ταβάνι για ένα λεπτό δεν είναι το ίδιο πράγμα με το να το διατηρείς.

Ο πραγματικός μηνιαίος όγκος εισόδου αυτής της πλατφόρμας, περίπου 3,65 εκατομμύρια tokens, είναι το 0,042% του μηνιαίου ταβανιού εισόδου εκείνου του MU, χονδρικά 411x κάτω από το σημείο break-even του 17,14%. Η αγορά ενός MU από την πρώτη μέρα, η ακριβής κίνηση που το Μέρος 1 ανέβαλε και το Μέρος 2 σημείωσε ότι χρειάζεται πρώτα αυτά τα μαθηματικά, θα ξόδευε 15.768 $ τον μήνα προστατεύοντας ένα φορτίο του οποίου ολόκληρος ο on-demand λογαριασμός μοντέλου είναι περίπου 14 $. Το λάθος δεν είναι η αριθμητική, είναι το να μην κάνεις καθόλου, και να δεσμευτείς σε μια μηνιαία χρέωση πριν καν μετρηθεί η κατανομή ρυθμού αιτημάτων στους τέσσερις agents. On-demand μέχρι να μετρηθεί, provisioned μόνο μετά, δεν είναι επιφυλακτικότητα για χάρη της επιφυλακτικότητας, είναι αυτό που λέει πραγματικά ο υπολογισμός του break-even.

Τι κάνει το prompt caching στα ίδια μαθηματικά

Το caching μετατρέπει την ποινή του resend από την ενότητα των μαθηματικών των tokens σε ένα ως επί το πλείστον λυμένο πρόβλημα. Ένα cached πρόθεμα διαβάζεται με έκπτωση 90%· νέο περιεχόμενο που γράφεται στην cache κοστίζει 1,25x την κανονική τιμή εισόδου, χωρίς ξεχωριστή χρέωση πέρα από αυτόν τον πολλαπλασιαστή. Εφαρμοσμένο γύρο προς γύρο, ο γύρος 1 γράφει την πλήρη είσοδό του στην cache, και κάθε επόμενος γύρος διαβάζει ολόκληρη την είσοδο του προηγούμενου γύρου στο 10% της κανονικής τιμής, πληρώνοντας πλήρη-συν-25% μόνο στα νεοπροσαρτημένα 500 tokens:

billing_input(1) = input(1) * 1.25
billing_input(r) = input(r-1) * 0.10 + 500 * 1.25   # r >= 2

Για τη ρηχή διερεύνηση, η cached ισοδύναμη χρέωσης είσοδος πέφτει από 8.100 σε 4.490 tokens, μείωση 44,6%. Για τη βαθιά διερεύνηση, πέφτει από 31.600 σε 9.715, μείωση 69,3%, μεγαλύτερη επειδή η ποινή resend που ακυρώνει συσσωρεύεται με κάθε επιπλέον γύρο: το caching βοηθά περισσότερο ακριβώς εκεί όπου το uncached κόστος πονά περισσότερο. Σε δολάρια, το συνολικό κόστος ενός βαθιού περιστατικού (είσοδος συν έξοδος, η έξοδος ανεπηρέαστη από το caching) πέφτει από 0,1151 $ σε 0,0494 $, μείωση 57,1%. Εφαρμοσμένο σε ολόκληρο το εβδομαδιαίο μείγμα του triage agent, το μηνιαίο κόστος μοντέλου μόνο για εκείνον τον agent πέφτει από 10,02 $ σε 5,29 $, εξοικονόμηση 4,73 $, 47,2%. Ο ίδιος μηχανισμός ισχύει για τους δικούς τους πολύγυρους βρόχους των agents runbook και cost-sweep σε μικρότερη απόλυτη κλίμακα, αφού τρέχουν πολύ πιο σπάνια· το συνοδευτικό έγγραφο κουβαλά τον πλήρη επανυπολογισμό μόνο για το triage, τον agent με τον υψηλότερο όγκο και τους περισσότερους γύρους, όπου το αποτέλεσμα είναι μεγαλύτερο.

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

Βάζοντας κάθε κατηγορία μαζί, χρησιμοποιώντας τις τεκμηριωμένες τιμές AgentCore και Guardrails απέναντι στους όγκους tokens παραπάνω, με τη γραμμή των tokens μοντέλου να δείχνεται τόσο με όσο και χωρίς caching στον triage agent:

Δύο πράγματα αξίζει να κάτσεις μαζί τους. Τα Runtime, Gateway και Memory είναι σφάλματα στρογγυλοποίησης σε αυτόν τον όγκο: η χρέωση ανά δευτερόλεπτο και η μη χρέωση του αδρανούς χρόνου αναμονής του μοντέλου σημαίνουν ότι η διαχειριζόμενη υποδομή μετά βίας καταγράφεται μέχρι η ταυτοχρονία και η διάρκεια session να ανέβουν κατά τάξεις μεγέθους. Τα Guardrails δεν είναι σφάλμα στρογγυλοποίησης: στο χονδρικά 30% του συνόλου χωρίς caching, κοστίζουν περισσότερο από Runtime, Gateway και Memory μαζί κατά περίπου 15x, και αφού το caching συρρικνώσει τη γραμμή του μοντέλου, είναι σχεδόν τα δύο τρίτα του μεγέθους του λογαριασμού μοντέλου που σαρώνουν. Μια άσκηση διαστασιολόγησης που σταματά στη μέτρηση tokens για το μοντέλο χάνει το ένα τρίτο του πραγματικού λογαριασμού, που κάθεται σε μια υπηρεσία που οι περισσότεροι διαστασιολογούν για συμμόρφωση, όχι για κόστος.

Σωστή διαστασιολόγηση μοντέλου ανά agent

Τα μαθηματικά των tokens παραπάνω υποθέτουν ένα μοντέλο για κάθε agent, που είναι η εύκολη προεπιλογή και όχι η σωστή τελική κατάσταση. Οι τέσσερις agents ζητούν γνήσια διαφορετικά πράγματα από ένα μοντέλο. Το triage κάνει δομημένη διάγνωση από έξοδο εργαλείων, στοιχεία μέσα, ένα οριοθετημένο σύνολο εύλογων βασικών αιτιών έξω, δουλειά που ένα μικρότερο, φθηνότερο μοντέλο χειρίζεται καλά μόλις το system prompt και τα tool schemas του σφίξουν, ακριβώς το φορτίο για το οποίο η ρύθμιση χαμηλής θερμοκρασίας του Μέρους 3 ήταν ήδη συντονισμένη. Η ημερήσια σάρωση του cost agent είναι κυρίως συνάθροιση και σύγκριση κατωφλίων πάνω σε αριθμούς που ένα εργαλείο έχει ήδη φέρει, ακόμα καλύτερο ταίριασμα για το μικρότερο μοντέλο που ακολουθεί αξιόπιστα τη μορφή εξόδου. Ο runbook agent είναι το ένα σημείο όπου ένα ισχυρότερο μοντέλο κερδίζει την υψηλότερη τιμή του ανά token: συντάσσει το ακριβές SSM document και τις παραμέτρους που ένας άνθρωπος πρόκειται να εγκρίνει πίσω από την πύλη έγκρισης του Μέρους 4, και ένα λάθος εκεί είναι λάθος με πραγματική ακτίνα έκρηξης, όχι λάθος σε μια διάγνωση που κάποιος άλλος ούτως ή άλλως διπλοελέγχει. Το ταίριασμα του μεγέθους μοντέλου με το τι κοστίζει πραγματικά ένα λάθος, αντί να προεπιλέγεται το ίδιο μοντέλο για κάθε agent, είναι το ίδιο ένστικτο πίσω από το prompt caching και το PT: μην ξοδεύεις σε ικανότητα που η εργασία δεν χρειάζεται, και ξόδεψε εκεί όπου μια λάθος απάντηση είναι ακριβή. Το eval harness του Μέρους 8 είναι αυτό που μετατρέπει το «το χειρίζεται καλά» από εικασία σε αριθμό που αξίζει εμπιστοσύνη.

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

Τέσσερα πράγματα αξίζει να ξέρεις πριν αυτό το μοντέλο τρέξει ενάντια σε πραγματικό λογαριασμό. Πρώτον, κάθε ποσό σε δολάρια παραπάνω εξαρτάται από δύο εισόδους placeholder, την τιμή on-demand ανά token και το ταβάνι απόδοσης MU του Provisioned Throughput, που αυτή η σειρά σκόπιμα δεν καρφιτσώνει ποτέ σε ένα ονομασμένο μοντέλο Bedrock· αντικατέστησε με τη ζωντανή σελίδα τιμολόγησης πριν εμπιστευτείς ένα σύνολο, αφού ένα μπαγιάτικο placeholder παράγει έναν με βεβαιότητα λάθος λογαριασμό, όχι έναν προφανώς λάθος. Δεύτερον, η υπόθεση των 350 tokens ανά αποτέλεσμα εργαλείου είναι σχεδόν σίγουρα συντηρητική: ένα πραγματικό dump μετρικών CloudWatch ή ένα απόσπασμα log μπορεί να τρέξει 5 έως 10x αυτού, και αφού είναι ο όρος που συσσωρεύεται τετραγωνικά στους γύρους, μια υποεκτίμηση εκεί υποτιμά κάθε επόμενο αριθμό αναλογικά, όχι κατά ένα σταθερό offset. Τρίτον, ο υπολογισμός break-even είναι μηνιαίος μέσος όρος· μια πλατφόρμα της οποίας η πραγματική κίνηση μοιάζει με την ενότητα των εκρήξεων, μεγάλα ήσυχα διαστήματα με απότομες συσχετισμένες αιχμές, μπορεί να μην πλησιάζει πουθενά το break-even στα χαρτιά ενώ ακόμα δέχεται throttling στα δέκα λεπτά που μετρούν, που συνηγορεί σε cross-region περιθώριο και συναγερμούς quota αντί για αγορά PT σε κάθε περίπτωση. Τέταρτον, η εξοικονόμηση του prompt caching εξαρτάται από το να πετυχαίνουν πράγματι τα cache hits, ένα system prompt ή ένα tool schema που επεξεργάστηκε κάποιος στη μέση του μήνα ακυρώνει το cached πρόθεμα και επαναφέρει για λίγο το πλήρες uncached κόστος μέχρι η cache να ξαναγεμίσει, κάτι που αξίζει παρακολούθηση μετά από κάθε αλλαγή prompt, όχι να το θεωρείς δεδομένο.

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

• Μέρος 6, Guardrails: Το Κομμάτι που Όλοι Προσπερνούν, για την τιμολόγηση ανά μονάδα των Guardrails στην οποία στηρίζεται το μηνιαίο μοντέλο κόστους αυτού του μέρους, και το μοτίβο κλήσεων που αποφασίζει πόσο κείμενο σαρώνεται πραγματικά.
• Μέρος 8, Παραγωγή: Observability, Evals, και η Μέρα που Θα Πει Ψέματα, όπου οι αποφάσεις σωστής διαστασιολόγησης μοντέλου παραπάνω δοκιμάζονται απέναντι σε πραγματικά traces αντί να θεωρούνται σωστές.
• The AWS Well-Architected Framework: A Key to Cloud Success στο ercan.cloud, για τον πυλώνα Cost Optimization του οποίου αυτό το μέρος είναι στην πραγματικότητα ένα μακρύ λυμένο παράδειγμα: μέτρησε πριν δεσμευτείς.

Το πλήρες docs/sizing-model.md, συμπεριλαμβανομένης της ανάλυσης ανά agent για τους agents runbook και cost-sweep που κόπηκε από τους πίνακες παραπάνω και μιας λίστας ελέγχου για την επανεκτέλεση κάθε αριθμού απέναντι σε πραγματικό λογαριασμό, ζει στο συνοδευτικό repository στο github.com/flightlesstux/agents-on-call. Για την πλευρά βάσεων δεδομένων και υποδομής της λειτουργίας πλατφορμών σαν αυτή σε κλίμακα, οι σημειώσεις πεδίου είναι στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.