Αρχιτεκτονική Ενοποίησης AI μετά την κυκλοφορία του YaFF από την Yandex
Η Yandex έκανε open-source το YaFF στις 20 Ιουνίου 2026, προσφέροντας στις ομάδες C++ μια μορφή wire format zero-copy για το Protobuf, η οποία διαβάζει κρίσιμα δεδομένα πολύ ταχύτερα από την τυπική ανάλυση (parsing). Για τις ομάδες που σκέφτονται την αρχιτεκτονική ενοποίησης AI, η πραγματική είδηση δεν είναι ο τίτλος των benchmarks, αλλά το μοντέλο διάθεσης: ένα κρίσιμο μονοπάτι τη φορά, με το Protobuf να παραμένει στα άκρα. Σύμφωνα με την κάλυψη της κυκλοφορίας από το MarkTechPost, η Yandex αναφέρει ότι η βιβλιοθήκη προσφέρει ήδη εξοικονόμηση CPU στην παραγωγή για τη στοίβα συστάσεων διαφημίσεων.
Η Yandex κάνει open-source το YaFF για zero-copy αναγνώσεις Protobuf
Η ανακοίνωση είναι ξεκάθαρη. Το YaFF είναι μια βιβλιοθήκη C++ με άδεια Apache 2.0 που διατηρεί το αρχείο .proto ως πηγή αλήθειας, αλλάζοντας τη μορφή wire format στη μνήμη. Αυτό έχει σημασία γιατί οι περισσότερες ομάδες backend δεν θέλουν ένα δεύτερο σύστημα σχήματος μόνο και μόνο για να κυνηγήσουν την ταχύτητα σειριοποίησης.
Το πλησιέστερο σημείο σύγκρισης είναι το FlatBuffers, το οποίο προσφέρει ήδη αναγνώσεις zero-copy. Ωστόσο, το FlatBuffers συνήθως απαιτεί ξεχωριστό σχήμα και επίπεδο μετατροπής. Η πρόταση του YaFF είναι πιο περιορισμένη και πρακτική: διατηρήστε τη σημασιολογία του Protobuf, δημιουργήστε ένα API παρόμοιο με το proto και παρακάμψτε το βήμα ανάλυσης στη διαδρομή ανάγνωσης.
Πιστεύω ότι γι' αυτό το θέμα αντιμετωπίζεται ως αρχιτεκτονική ιστορία και όχι ως περιέργεια του runtime της γλώσσας. Στα πραγματικά συστήματα, το εμπόδιο σπάνια είναι το "μπορεί αυτό να αποδώσει ταχύτερα στα benchmarks;". Είναι το "μπορώ να το εισαγάγω χωρίς να σπάσω δώδεκα downstream υπηρεσίες και τους επόμενους έξι μήνες προγραμματισμού κυκλοφοριών;"
Το MarkTechPost παραφράζει τη θέση της Yandex με σαφήνεια: οι ομάδες μπορούν να εισαγάγουν το YaFF σε ένα κρίσιμο μονοπάτι και να αφήσουν την υπόλοιπη εφαρμογή στο Protobuf. Αυτό είναι το σημείο που πρέπει να υπογραμμίσουν οι διαχειριστές συστημάτων.
Πώς το YaFF διατηρεί τη σημασιολογία του Protobuf χωρίς parsing
Η σχεδιαστική επιλογή που ξεχωρίζει είναι η συμβατότητα ορίων. Μια υπηρεσία μπορεί να σειριοποιήσει ένα υπάρχον μήνυμα Protobuf σε ένα buffer YaFF, να διαβάσει πεδία απευθείας από τη μνήμη και στη συνέχεια να μετατρέψει ξανά σε ένα κανονικό μήνυμα Protobuf όταν ένας άλλος καταναλωτής αναμένει την παλιά διαδρομή. Αυτό δεν είναι κομψό σε θεωρητικό επίπεδο, αλλά είναι ακριβώς ο τρόπος με τον οποίο συνήθως επιτυγχάνεται η σταδιακή υιοθέτηση στο backend.
Αν διαβάσετε τα benchmarks και την τεκμηρίωση του YaFF, η βιβλιοθήκη προσφέρει τέσσερις διατάξεις: Fixed, Flat, Sparse και Dynamic. Το Dynamic είναι το προεπιλεγμένο, επειδή επιλέγει μεταξύ Flat και Sparse ανάλογα με τους περιορισμούς του σχήματος. Αυτό μου δείχνει ότι το έργο είναι βελτιστοποιημένο για μικτές συνθήκες παραγωγής, όχι μόνο για ιδανικά microbenchmarks.
Λάβετε μία πρακτική σημείωση για προγράμματα AI την εβδομάδα. Εγγραφείτε στο newsletter της Encorp.
Το μάθημα για την αρχιτεκτονική ενοποίησης AI είναι οικείο: διατηρήστε το συμβόλαιο, αλλάξτε τη διαδρομή εκτέλεσης πίσω από αυτό. Έχω δει το ίδιο μοτίβο να λειτουργεί σε API gateways, υπηρεσίες ανάκτησης διανυσμάτων και προσαρμογείς εξυπηρέτησης μοντέλων. Οι ομάδες που κινούνται ταχύτερα είναι αυτές που αποφεύγουν τις ριζικές ανακατασκευές.
Υπάρχει επίσης συνάφεια με εργασίες υλοποίησης όπως ο Αυτοματισμός Επιχειρηματικών Διαδικασιών AI, όπου το χρήσιμο ερώτημα δεν είναι αν ένα νέο στοιχείο είναι εντυπωσιακό, αλλά αν μπορεί να εισαχθεί σε μια μετρήσιμη ροή εργασίας με σαφή δεδομένα πριν και μετά. Αιτιολόγηση καταλληλότητας υπηρεσίας: αυτή η σελίδα είναι η πλησιέστερη αντιστοιχία, επειδή η ιστορία του YaFF αφορά την ενσωμάτωση ενός στοιχείου εστιασμένου στην απόδοση σε μια υπάρχουσα ροή παραγωγής με σταδιακό και ασφαλή τρόπο.
Πού ταιριάζει το YaFF σε μια εταιρική στοίβα
Η Yandex αναφέρει ότι το YaFF εκτελείται στο σύστημα συστάσεων διαφημίσεων και αναφέρει 10–20% εξοικονόμηση CPU σε κλίμακα παραγωγής. Στην υποδομή adtech και συστάσεων, αυτό είναι σημαντικό. Εάν το parsing καταναλώνει διψήφιο ποσοστό CPU σε μια κρίσιμη διαδρομή αιτημάτων, η μείωση κατά 10% μπορεί να σημαίνει λιγότερους πυρήνες, χαμηλότερη διακύμανση καθυστέρησης ή περιθώριο για περισσότερη λογική κατάταξης.
Τα πρώτα μέρη που θα κοιτούσα είναι:
- αγωγοί συστάσεων με στενό fan-out και υψηλό όγκο αναγνώσεων
- backend εξυπηρέτησης διαφημίσεων όπου ένα αίτημα αγγίζει πολλά σειριοποιημένα αντικείμενα
- ευρετήρια αντιστοιχισμένα στη μνήμη για αναζήτηση ή ανάκτηση ροών
- καταστήματα χαρακτηριστικών (feature stores) με έντονη ενίσχυση αναγνώσεων
Το κοινό χαρακτηριστικό είναι ο έλεγχος τόσο του παραγωγού όσο και του καταναλωτή. Αυτό έχει μεγαλύτερη σημασία από τον πίνακα benchmarks. Εάν πέντε εξωτερικοί συνεργάτες γράφουν επίσης στη μορφή payload, το κόστος μετανάστευσης αυξάνεται γρήγορα.
Υπάρχει ένας άλλος πρακτικός περιορισμός: το YaFF είναι επί του παρόντος προσανατολισμένο σε C++ και server-side. Αυτό περιορίζει αμέσως το κοινό του. Οι ομάδες που χρησιμοποιούν Java, Go, Python και προγράμματα περιήγησης μπορεί να μάθουν από το μοτίβο, αλλά δεν θα υιοθετήσουν αυτή τη βιβλιοθήκη αύριο.
Το χάσμα των benchmarks έχει σημασία, αλλά μόνο στο σωστό μέρος
Στο δημοσιευμένο benchmark της Yandex, η διάταξη YaFF Flat διαβάζει μια κρίσιμη ιεραρχική περίπτωση σε 9,79 ns, έναντι 37,30 ns για το FlatBuffers και 219,35 ns για το Protobuf, μετρημένα με το google/benchmark σε έναν AMD EPYC 7713 και Clang 20.1.8. Η βασική γραμμή για το raw C++ struct είναι 8,14 ns.
Αυτοί οι αριθμοί είναι εντυπωσιακοί, αλλά δεν θα τους αντέγραφα σε μια επιχειρηματική πρόταση χωρίς πλαίσιο. Τέτοια benchmarks είναι καλά για κατάταξη, όχι για προϋπολογισμό. Το χρήσιμο σήμα είναι η σχετική συμπεριφορά:
- Το YaFF Flat είναι περίπου 3,8 φορές ταχύτερο από το FlatBuffers στην περίπτωση hot-read.
- Το YaFF Flat είναι περίπου 22 φορές ταχύτερο από το αναλυμένο Protobuf στην ίδια περίπτωση.
- Το YaFF Flat παραμένει εντός περίπου 1,2 φορές της βασικής γραμμής ενός raw struct.
Αυτό το τελευταίο σημείο είναι αυτό που ενδιαφέρει τις ομάδες υποδομής. Υποδηλώνει ότι το overhead πλησιάζει το κόστος πρόσβασης στη μνήμη αντί για το κόστος του parser.
Σε μια συνεργασία με πελάτη πέρυσι, βρήκαμε μια υπηρεσία κατάταξης όπου η σειριοποίηση και η πρόσβαση σε πεδία κατανάλωναν αρκετή CPU ώστε το μοντέλο να κατηγορηθεί για αιχμές καθυστέρησης που δεν προκαλούσε στην πραγματικότητα. Το μάθημα ήταν απλό: κάντε profiling πριν βελτιστοποιήσετε το λαμπερό μέρος. Το YaFF ταιριάζει στο ίδιο μοτίβο. Αν το flame graph σας δεν δείχνει overhead parsing σε μια κρίσιμη διαδρομή, αυτή πιθανότατα δεν είναι η επόμενη κίνησή σας.
Η λεπτομέρεια του compiler aliasing είναι πιο σημαντική από όσο ακούγεται
Το λιγότερο προφανές μέρος της ιστορίας του YaFF είναι η συμπεριφορά του compiler. Τόσο το YaFF όσο και το FlatBuffers διαβάζουν πεδία ερμηνεύοντας ξανά την ακατέργαστη μνήμη ως τυποποιημένα δεδομένα. Αυτό ωθεί την τεκμηρίωση του LLVM για το Alias Analysis σε μια συντηρητική θέση, η οποία μπορεί να αναγκάσει τον compiler να επανεξετάσει τις αλυσίδες πρόσβασης αντί να επαναχρησιμοποιήσει με ασφάλεια προηγούμενες αναγνώσεις.
Ο ισχυρισμός της Yandex είναι ότι οι παραγόμενες σημειώσεις βοηθούν τον compiler να καταλάβει πότε η επαναλαμβανόμενη πρόσβαση μπορεί να επαναχρησιμοποιηθεί, εφόσον η μνήμη δεν τροποποιήθηκε μεταξύ των αναγνώσεων. Για τους περισσότερους αναγνώστες, αυτό ακούγεται σαν μια μικρή λεπτομέρεια codegen. Για όποιον έχει κοιτάξει την έξοδο assembly ή έχει δει έναν "απλό accessor" να κυριαρχεί σε ένα profile, δεν είναι καθόλου μικρή.
Εδώ είναι που τα benchmarks γίνονται πιο πιστευτά. Αν η βιβλιοθήκη ισχυριζόταν μόνο μια καλύτερη διάταξη, θα ήμουν επιφυλακτικός. Η εξήγηση για το aliasing δίνει έναν εύλογο λόγο για τον οποίο οι επαναλαμβανόμενες ιεραρχικές αναγνώσεις γίνονται ουσιαστικά καλύτερες. Αυτό δεν εγγυάται το ίδιο κέρδος σε κάθε φόρτο εργασίας, αλλά εξηγεί γιατί ένα κρίσιμο backend με ευαισθησία σε διακλαδώσεις θα μπορούσε να δει πραγματικά οφέλη.
Τι πρέπει να κάνουν οι ομάδες πριν υιοθετήσουν το YaFF
Αν το αξιολογούσα για μια υπηρεσία παραγωγής, θα κρατούσα τη λίστα ελέγχου σύντομη.
Πρώτον, επιβεβαιώστε ότι το parsing του Protobuf ή η επαναλαμβανόμενη πρόσβαση σε πεδία είναι όντως κορυφαίος καταναλωτής CPU. Χρησιμοποιήστε perf, εργαλεία eBPF ή τον υπάρχοντα profiler σας πριν αγγίξετε τη διαδρομή δεδομένων.
Δεύτερον, δοκιμάστε μια περιορισμένη διαδρομή όπου ο παραγωγός και ο καταναλωτής είναι και οι δύο υπό τον έλεγχό σας. Μην ξεκινήσετε με ένα κοινόχρηστο μήνυμα που χρησιμοποιείται από δέκα ομάδες.
Τρίτον, κάντε benchmark στο hardware σας με τα δικά σας σχήματα αντικειμένων. Τα αποτελέσματα του AMD EPYC της Yandex είναι χρήσιμα, αλλά η συμπεριφορά της cache και η πυκνότητα του σχήματος μπορούν να αλλάξουν το αποτέλεσμα.
Τέταρτον, κρατήστε το Protobuf στα όρια μέχρι το σχέδιο επαναφοράς να είναι απλό. Το γεγονός ότι το YaFF υποστηρίζει αμφίδρομη μετατροπή δεν είναι δευτερεύον χαρακτηριστικό, είναι το δίχτυ ασφαλείας της λειτουργίας.
Αυτό που πρέπει να παρακολουθήσετε στη συνέχεια είναι αν το YaFF θα παραμείνει ένα ισχυρό εξειδικευμένο εργαλείο για backend C++ ή αν θα εξελιχθεί σε ένα ευρύτερο μοτίβο που θα αντιγράψουν άλλοι σε γειτονικά runtimes. Το πιο σημαντικό σήμα δεν θα είναι τα αστέρια στο GitHub, αλλά οι αναφορές από τους διαχειριστές που δείχνουν πού η υποσχόμενη εξοικονόμηση 10–20% CPU ισχύει και πού όχι σε ζωντανά συστήματα.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation