Επιτάχυνση ροών εργασίας με πράκτορα με το WebSocket στο Responses API

Όταν ζητάτε από το Codex να διορθώσει ένα σφάλμα, σαρώνει τη βάση κώδικά σας για σχετικά αρχεία, τα διαβάζει για να αποκτήσει το απαραίτητο θεματικό πλαίσιο, κάνει αλλαγές και εκτελεί δοκιμές για να επαληθεύσει ότι η διόρθωση είχε αποτέλεσμα. Στο παρασκήνιο, αυτό συνεπάγεται δεκάδες αμφίδρομα αιτήματα στο Responses API: να καθοριστεί η επόμενη ενέργεια του μοντέλου, να εκτελεστεί ένα εργαλείο στον υπολογιστή σας, να σταλεί η έξοδος του εργαλείου πίσω στο API και να επαναληφθεί η διαδικασία.

Όλα αυτά τα αιτήματα μπορούν να αθροιστούν σε λεπτά που οι χρήστες αφιερώνουν περιμένοντας να ολοκληρώσει το Codex σύνθετες εργασίες. Από την άποψη της καθυστέρησης απόκρισης, ο βρόχος του πράκτορα Codex αφιερώνει τον περισσότερο χρόνο του σε τρία κύρια στάδια: εργασία στις υπηρεσίες API (για την επικύρωση και επεξεργασία αιτημάτων), εξαγωγή συμπερασμάτων του μοντέλου και χρόνος στην πλευρά του πελάτη (εκτέλεση εργαλείων και δημιουργία του θεματικού πλαισίου του μοντέλου). Η εξαγωγή συμπερασμάτων είναι το στάδιο κατά το οποίο το μοντέλο εκτελείται σε GPU για να δημιουργήσει νέα token. Στο παρελθόν, η εκτέλεση εξαγωγής συμπερασμάτων LLM σε GPU ήταν το πιο αργό μέρος του βρόχου του πράκτορα, επομένως η επιβάρυνση της υπηρεσίας API ήταν εύκολο να αποκρυφτεί. Καθώς η εξαγωγή συμπερασμάτων γίνεται ταχύτερη, η σωρευτική επιβάρυνση του API από μια κυκλοφορία με πράκτορα γίνεται πολύ πιο αισθητή.

Σε αυτή την ανάρτηση, θα εξηγήσουμε πώς κάναμε τους βρόχους πρακτόρων που χρησιμοποιούν το API 40% ταχύτερους από άκρο σε άκρο, επιτρέποντας στους χρήστες να βιώσουν την αύξηση στην ταχύτητα εξαγωγής συμπερασμάτων από 65 σε σχεδόν 1.000 token ανά δευτερόλεπτο. Αυτή η προσέγγιση έγινε μέσω της προσωρινής αποθήκευσης (caching), εξαλείφοντας τα περιττά ενδιάμεσα βήματα δικτύου, βελτιώνοντας τη στοίβα ασφάλειάς μας ώστε να επισημαίνει γρήγορα προβλήματα και —το σημαντικότερο— δημιουργώντας έναν τρόπο για τη δημιουργία μόνιμης σύνδεσης με το Responses API, αντί να χρειάζεται να πραγματοποιείται μια σειρά από σύγχρονες κλήσεις API.

Στο Responses API, προηγούμενα κορυφαία μοντέλα όπως τα GPT‑5 και GPT‑5.2 λειτουργούσαν με περίπου 65 token ανά δευτερόλεπτο (TPS). Για την κυκλοφορία του GPT‑5.3‑Codex‑Spark, ενός γρήγορου μοντέλου προγραμματισμού, στόχος μας ήταν να είμαστε κατά μία τάξη μεγέθους ταχύτεροι: πάνω από 1.000 TPS, χάρη σε εξειδικευμένο υλικό Cerebras βελτιστοποιημένο για εξαγωγή συμπερασμάτων LLM. Για να διασφαλίσουμε ότι οι χρήστες θα μπορούσαν να βιώσουν την πραγματική ταχύτητα αυτού του νέου μοντέλου, έπρεπε να μειώσουμε τον φόρτο του API. 

Γύρω στον Νοέμβριο του 2025, ξεκινήσαμε ένα σπριντ επιδόσεων στο Responses API, υλοποιώντας πολλές βελτιστοποιήσεις στην καθυστέρηση της κρίσιμης διαδρομής για ένα μεμονωμένο αίτημα: 

• Αποθήκευση στη μνήμη cache των token που έχουν αποδοθεί και της διαμόρφωσης του μοντέλου, ώστε να παραλείπονται η δαπανηρή μετατροπή σε token και οι κλήσεις δικτύου για αποκρίσεις πολλαπλών γύρων
• Μείωση της καθυστέρησης μεταπήδησης δικτύου εξαλείφοντας τις κλήσεις προς ενδιάμεσες υπηρεσίες (π.χ. για ανάλυση επεξεργασίας εικόνας) και καλώντας απευθείας την υπηρεσία εξαγωγής συμπερασμάτων
• Βελτιώνουμε τη στοίβα ασφαλείας μας, ώστε να μπορούμε να εκτελούμε ορισμένα εργαλεία ταξινόμησης για να επισημαίνουμε συνομιλίες ταχύτερα

Με αυτές τις βελτιώσεις, είδαμε βελτίωση σχεδόν 45% στον χρόνο μέχρι το πρώτο token (TTFT) —που αντικατοπτρίζει το πόσο άμεσα ανταποκρίνεται το API— αλλά αυτές οι βελτιώσεις εξακολουθούσαν να μην είναι αρκετά γρήγορες για το GPT‑5.3‑Codex‑Spark. Ακόμη και με αυτές τις βελτιώσεις, η επιβάρυνση του Responses API ήταν υπερβολικά μεγάλη σε σχέση με την ταχύτητα του μοντέλου — δηλαδή, οι χρήστες έπρεπε να περιμένουν τις CPU που εκτελούσαν το API μας προτού μπορέσουν να χρησιμοποιήσουν τις GPU που εξυπηρετούσαν το μοντέλο.

Το βαθύτερο πρόβλημα ήταν δομικό: αντιμετωπίζαμε κάθε αίτημα του Codex ως ανεξάρτητο, επεξεργαζόμενοι την κατάσταση της συνομιλίας και άλλο επαναχρησιμοποιήσιμο θεματικό πλαίσιο σε κάθε επακόλουθο αίτημα. Ακόμη κι όταν το μεγαλύτερο μέρος της συνομιλίας δεν είχε αλλάξει, πληρώναμε και πάλι για εργασία που συνδεόταν με το πλήρες ιστορικό. Καθώς οι συνομιλίες γίνονταν μεγαλύτερες, η επαναλαμβανόμενη επεξεργασία γινόταν πιο δαπανηρή.

Για να βελτιώσουμε τον σχεδιασμό, επανεξετάσαμε το πρωτόκολλο μεταφοράς: θα μπορούσαμε να διατηρήσουμε μια μόνιμη σύνδεση και να αποθηκεύσουμε την κατάσταση στην προσωρινή μνήμη, αντί να δημιουργούμε κάθε φορά νέα σύνδεση μέσω HTTP και να στέλνουμε ολόκληρο το ιστορικό συνομιλιών με κάθε επόμενο αίτημα; Η ιδέα ήταν να αποστέλλονται μόνο νέες πληροφορίες που απαιτούν επικύρωση και επεξεργασία, ενώ η επαναχρησιμοποιήσιμη κατάσταση να αποθηκεύεται στην προσωρινή μνήμη για όλη τη διάρκεια της σύνδεσης. Αυτό θα μείωνε τον φόρτο από περιττή εργασία.

Εξετάσαμε μερικές διαφορετικές προσεγγίσεις, συμπεριλαμβανομένων των WebSocket και του αμφίδρομου streaming του gRPC. Καταλήξαμε στα WebSocket, επειδή, ως ένα απλό πρωτόκολλο μεταφοράς μηνυμάτων, οι χρήστες δεν θα χρειάζονταν να αλλάξουν τα σχήματα εισόδου και εξόδου του Responses API. Ήταν φιλικό προς τους προγραμματιστές και ταίριαζε με την υπάρχουσα αρχιτεκτονική μας, με ελάχιστη αναστάτωση.

Το πρώτο πρωτότυπο WebSocket άλλαξε όσα θεωρούσαμε δυνατά για την καθυστέρηση του API Responses. Ένας μηχανικός της ομάδας Codex, με βαθιά εξειδίκευση στη στοίβα API, δημιούργησε ένα πρωτότυπο εκτελώντας έναν πράκτορα Codex κατά τη διάρκεια της νύχτας.

Σε εκείνο το πρωτότυπο, οι εκτελέσεις πρακτόρων μοντελοποιήθηκαν ως μία ενιαία απόκριση μεγάλης διάρκειας. Χρησιμοποιώντας τις δυνατότητες του asyncio, το Responses API θα μπλόκαρε ασύγχρονα στον βρόχο δειγματοληψίας μετά τη δειγματοληψία μιας κλήσης εργαλείου και το Responses API θα έστελνε ένα συμβάν response.done πίσω στον πελάτη. Μετά την εκτέλεση της κλήσης εργαλείου, οι πελάτες θα έστελναν πίσω ένα συμβάν response.append με το αποτέλεσμα του εργαλείου, το οποίο ξεμπλόκαρε τον βρόχο δειγματοληψίας και επέτρεπε στο μοντέλο να συνεχίσει.

Μια αναλογία εδώ είναι να θεωρείτε την τοπική κλήση εργαλείου ως φιλοξενούμενη κλήση εργαλείου. Όταν το μοντέλο καλεί αναζήτηση στο web, ο βρόχος εξαγωγής συμπερασμάτων μπλοκάρει, καλεί μια υπηρεσία αναζήτησης στο web και εισάγει την απόκριση της υπηρεσίας στο περιβάλλον του μοντέλου. Στον σχεδιασμό μας, κάναμε το ίδιο, αλλά αντί να καλέσουμε μια απομακρυσμένη υπηρεσία, στείλαμε την κλήση εργαλείου του μοντέλου πίσω στον πελάτη μέσω του WebSocket. Όταν ο πελάτης απάντησε, τοποθετήσαμε την απόκριση της κλήσης εργαλείου του πελάτη στο πλαίσιο και συνεχίσαμε τη δειγματοληψία.

Αυτός ο σχεδιασμός ήταν εξαιρετικά αποτελεσματικός, επειδή εξάλειψε την επαναλαμβανόμενη εργασία σε επίπεδο API κατά τη διάθεση ενός πράκτορα. Θα μπορούσαμε να κάνουμε την εργασία πριν από την εξαγωγή συμπερασμάτων μία φορά, να κάνουμε παύση για την εκτέλεση εργαλείων και να κάνουμε την εργασία μετά την εξαγωγή συμπερασμάτων μία φορά στο τέλος.

Δυστυχώς, αυτό είχε ως τίμημα μια λιγότερο οικεία και πιο περίπλοκη μορφή API. Θέλαμε οι προγραμματιστές να μπορούν να προσθέτουν υποστήριξη WebSocket χωρίς να χρειάζεται να ξαναγράψουν την ενσωμάτωση του API τους γύρω από έναν νέο τρόπο αλληλεπίδρασης.

Για την έκδοση που κυκλοφορήσαμε, επιστρέψαμε σε μια οικεία μορφή: συνεχίσαμε να χρησιμοποιούμε το response.create με το ίδιο σώμα αιτήματος και χρησιμοποιήσαμε το previous_response_id για να συνεχίσουμε το θεματικό πλαίσιο της συνομιλίας από την κατάσταση της προηγούμενης απόκρισης.

Σε μια σύνδεση WebSocket, ο διακομιστής διατηρεί μια ενδομνήμη cache με εμβέλεια σύνδεσης για την προηγούμενη κατάσταση απόκρισης. Όταν ένα επακόλουθο response.create περιλαμβάνει previous_response_id, ανακτούμε αυτήν την κατάσταση από την κρυφή μνήμη αντί να αναδομούμε ολόκληρη τη συνομιλία από την αρχή.

Αυτή η κατάσταση cache περιλαμβάνει:

• Το προηγούμενο αντικείμενο response
• Προηγούμενα στοιχεία εισαγωγής και αποτελέσματος
• Ορισμούς εργαλείων και χώρους ονομάτων
• Στοιχεία δειγματοληψίας με δυνατότητα επαναχρησιμοποίησης, όπως token που έχουν αποδοθεί προηγουμένως

Με την επαναχρησιμοποίηση της κατάστασης της προηγούμενης απόκρισης στη μνήμη, επιτύχαμε αρκετές σημαντικές βελτιστοποιήσεις:

• Επεξεργασία ορισμένων από τα εργαλεία ταξινόμησης ασφαλείας και τα εργαλεία επικύρωσης αιτημάτων μας μόνο τις νέες εισαγωγές, και όχι κάθε φορά ολόκληρο το ιστορικό
• Διατήρηση μιας μνήμης cache με αποδοσμένα token, στην οποία προσθέτουμε ώστε να μπορούμε να παραλείπουμε τη μη απαραίτητη μετατροπή σε token
• Επαναχρησιμοποίηση της επιτυχημένης λογικής επίλυσης/δρομολόγησης μοντέλου σε όλα τα αιτήματα 
• Επικάλυψη μη αποκλειστικών εργασιών μετά την εξαγωγή συμπερασμάτων, όπως η χρέωση, με επόμενα αιτήματα

Ο στόχος ήταν να προσεγγίσουμε όσο το δυνατόν περισσότερο το πρωτότυπο με την ελάχιστη δυνατή επιβάρυνση, αλλά με μια μορφή API που οι προγραμματιστές κατανοούσαν ήδη και είχαν ήδη χρησιμοποιήσει.

Μετά από ένα δίμηνο σπριντ για την ανάπτυξη της λειτουργίας WebSocket, κυκλοφορήσαμε μια έκδοση alpha με σημαντικές startup που αναπτύσσουν πράκτορες για σύνταξη κώδικα, ώστε να μπορούν να την ενσωματώσουν στην υποδομή τους και να αυξήσουν με ασφάλεια την κίνηση. Οι χρήστες της έκδοσης alpha το λάτρεψαν, αναφέροντας βελτιώσεις έως και 40%⁠(ανοίγει σε νέο παράθυρο) στις ροές εργασίας πρακτόρων τους. Δεδομένων των θετικών σχολίων από την έκδοση alpha, ήμασταν έτοιμοι να προχωρήσουμε σε κυκλοφορία.

Τα αποτελέσματα της κυκλοφορίας ήταν άμεσα. Το Codex μετέφερε γρήγορα το μεγαλύτερο μέρος της κίνησης του Responses API σε λειτουργία WebSocket, καταγράφοντας σημαντικές βελτιώσεις στον χρόνο απόκρισης. Για το GPT‑5.3‑Codex‑Spark, πετύχαμε τον στόχο μας για 1.000 TPS και είδαμε αιχμές έως και 4.000 TPS, δείχνοντας ότι το Responses API μπορούσε να ανταποκριθεί σε πολύ ταχύτερη εξαγωγή συμπερασμάτων σε πραγματική κίνηση παραγωγής. Ο αντίκτυπος ήταν γρήγορα εμφανής και στην κοινότητα των προγραμματιστών:

• Το Codex μετέφερε γρήγορα το μεγαλύτερο μέρος της κίνησής του στα WebSocket. Χρήστες του Codex που εκτελούν τα πιο πρόσφατα μοντέλα, όπως το GPT‑5.3‑Codex⁠(ανοίγει σε νέο παράθυρο), το GPT‑5.4⁠(ανοίγει σε νέο παράθυρο), και όχι μόνο, επωφελούνται από την επιτάχυνση της λειτουργίας WebSocket.
• Η Vercel ενσωμάτωσε τη λειτουργία WebSocket στο AI SDK και είδε την καθυστέρηση να μειώνεται έως και 40%⁠(ανοίγει σε νέο παράθυρο).
• Οι ροές εργασίας πολλαπλών αρχείων της Cline είναι κατά 39% ταχύτερες⁠(ανοίγει σε νέο παράθυρο).
• Τα μοντέλα της OpenAI στην Cursor έγιναν έως και 30% ταχύτερα⁠(ανοίγει σε νέο παράθυρο).

Η λειτουργία WebSocket είναι μία από τις σημαντικότερες νέες δυνατότητες στο Responses API από την κυκλοφορία της τον Μάρτιο του 2025. Μεταβήκαμε από την ιδέα στην παραγωγική λειτουργία μέσα σε λίγες μόλις εβδομάδες, χάρη στη στενή συνεργασία μεταξύ των ομάδων API και Codex της OpenAI. Όχι μόνο βελτιώνει δραματικά την καθυστέρηση διάθεσης του πράκτορα, αλλά υποστηρίζει επίσης μια αυξανόμενη ανάγκη για τους δημιουργούς: καθώς η εξαγωγή συμπερασμάτων του μοντέλου γίνεται ταχύτερη, οι υπηρεσίες και τα συστήματα που την περιβάλλουν πρέπει επίσης να επιταχυνθούν, ώστε να μεταφερθούν αυτά τα οφέλη στους χρήστες.