LLM4LLM: γιατί το γρήγορο GPU kernel πρέπει να δοκιμάζεται μέσα στο πραγματικό μοντέλο

Το benchmark-to-deployment gap που κρύβει το πραγματικό κόστος

Τα συνήθη kernel benchmarks εκτελούν έναν υποψήφιο σε συνθετικά inputs, ελέγχουν αν συμφωνεί αριθμητικά με μια reference υλοποίηση και μετρούν την απομονωμένη καθυστέρηση. Αυτό είναι χρήσιμο ως γρήγορο φίλτρο, αλλά μετρά έναν ενδιάμεσο δείκτη. Το deployment ενδιαφέρεται για τη συμπεριφορά του patched μοντέλου κάτω από το στοχευμένο workload: cache state, memory residency, dispatch overhead, allocator state, shape guards και αλληλεπίδραση με ήδη βελτιστοποιημένα kernels.

Στο χαρακτηριστικό παράδειγμα της εργασίας, ένα convolution kernel κερδίζει όταν δοκιμάζεται μόνο του με freshly allocated inputs, αλλά χάνει όταν τοποθετείται μέσα στο πλήρες μοντέλο. Ο λόγος είναι ότι η baseline υλοποίηση μέσα στο μοντέλο παραλαμβάνει activations που μόλις παρήγαγε το προηγούμενο layer και επωφελείται από warm-cache locality. Η τεχνική που βελτιώνει την cold-cache μέτρηση δεν διατηρεί το πλεονέκτημά της στο πραγματικό execution context.

Η ίδια λογική εμφανίζεται και στην αξιολόγηση AI agents: ένα καλό score δεν αρκεί όταν δεν συνδέεται με το σωστό artifact, τη σωστή διαδρομή και επαληθεύσιμη εργασία. Η ανάλυση του K-Bench για accuracy, communication και artifacts δείχνει γιατί η τελική μέτρηση πρέπει να ταιριάζει με το πραγματικό παραδοτέο.

Τρεις τρόποι με τους οποίους ένα «σωστό» kernel αποτυγχάνει

Το πρώτο είδος αστοχίας είναι η αντιστροφή της απόδοσης: καλύτερος χρόνος στο harness, χειρότερος χρόνος μετά το integration. Το δεύτερο είναι η runtime εγκυρότητα. Ένα out-of-bounds read μπορεί να μη ρίξει το standalone test επειδή η διπλανή μνήμη είναι mapped, αλλά να προκαλέσει CUDA error όταν ο allocator του πλήρους μοντέλου τοποθετήσει τα δεδομένα διαφορετικά.

Το τρίτο είναι η λανθασμένη μεταφορά ανά φάση. Στο autoregressive inference, το prefill και το decode έχουν διαφορετικά shapes, κατάσταση KV cache, patterns πρόσβασης στη μνήμη και ευαισθησία στο latency. Ένα attention kernel που βελτιστοποιεί το prefill για q_len μεγαλύτερο από 1 μπορεί να μην εφαρμόζεται καθόλου στο decode, όπου q_len ισούται με 1. Άρα η τοπική επιτυχία δεν ισοδυναμεί ούτε με πλήρη κάλυψη ούτε με end-to-end όφελος.

Τέσσερα επίπεδα ελέγχου αντί για ένα score

Οι συγγραφείς ξεχωρίζουν τέσσερα στάδια. Η isolated qualification ελέγχει standalone ορθότητα και latency. Η search-time validation προσθέτει πραγματικά inputs, safety gates ή timing σε πιο πιστό context. Η deployment-time acceptance τοποθετεί τον υποψήφιο στο συγκεκριμένο model instance. Τέλος, η end-to-end αξιολόγηση μετρά ολόκληρο το patched workload.

Η ουσία είναι ότι το benchmark παραμένει χρήσιμο για γρήγορη παραγωγή και διαλογή πολλών candidates, αλλά δεν παίρνει την τελική απόφαση. Το LLM4LLM δένει generation, verification, acceptance και deployment σε loop γύρω από τον στόχο που πραγματικά ενδιαφέρει. Αυτό μετατρέπει το performance engineering από offline κατάταξη αποσπασμένων kernels σε διαδικασία όπου κάθε patch πρέπει να αποδείξει την αξία του στο περιβάλλον που θα λειτουργήσει.

Το πραγματικό inference script γίνεται η προδιαγραφή

Το σύστημα ξεκινά από inference script που παρέχει ο χρήστης. Το script ορίζει το workload, τα inputs, το runtime path και τον στόχο απόδοσης. Το LLM4LLM κάνει ιεραρχικό profiling και επιλέγει semantic module instances των οποίων η αντικατάσταση μπορεί πράγματι να επηρεάσει το συνολικό latency. Ένα module θεωρείται deployable όταν έχει σταθερό call boundary, αναπαραγώγιμα tensors εισόδου και εξόδου και fallback για regimes που δεν βελτιστοποιούνται.

Για κάθε hotspot αποθηκεύονται representative inputs, reference outputs, shapes, module family, hardware scope και phase tags. Όταν prefill και decode διαφέρουν, γίνονται ξεχωριστές εργασίες και καταγράφεται dispatch template για να επανενωθούν οι phase-specialized candidates. Ένας workload-weighted hotspot score συνυπολογίζει το ποσοστό χρόνου κάθε module σε κάθε φάση και τη συχνότητα ή βαρύτητα της φάσης στο workload.

Η αρχή είναι συγγενής με το multimodal speculative decoding: η θεωρητική παραλληλία ή η ταχύτητα ενός επιμέρους μηχανισμού αποκτά αξία μόνο όταν μειώνει το latency στο πλήρες serving path.

Episodic search: να κρατάς το μάθημα, όχι όλο το ιστορικό

Ο optimizer λειτουργεί σε επαναλαμβανόμενα generate–verify–decide episodes. Ο agent προτείνει Triton kernels, τα κάνει compile, ελέγχει αριθμητική ορθότητα και runtime safety, μετρά latency και διαβάζει compiler diagnostics, numerical errors και failures. Οι υποψήφιοι κατατάσσονται με utility που μηδενίζεται αν δεν περάσουν τα όρια σφάλματος ή τους ελέγχους ασφαλείας και διαφορετικά αντανακλά το speedup έναντι της reference εργασίας.

Στο τέλος κάθε episode, το σύστημα συμπυκνώνει το χρήσιμο evidence: έγκυρα tiling choices, boundary masks, phase predicates, numerical constraints, failure signatures και την καλύτερη περιοχή απόδοσης. Το πλήρες transcript αρχειοθετείται και η επόμενη προσπάθεια ξεκινά από την αρχική προδιαγραφή συν αυτή τη σύντομη εμπειρία. Ο στόχος είναι να μη φυλακίζεται η αναζήτηση σε μια μακρά αλυσίδα τοπικών διορθώσεων ενός candidate που ίσως δεν αξίζει να σωθεί.

Η μνήμη παραμένει χρήσιμη επειδή κρατά τεκμήρια και περιορισμούς, όχι επειδή διατηρεί αδιάκριτα όλο το ιστορικό. Το ίδιο μοτίβο συναντάμε στη συζήτηση για μνήμη AI agents με provenance και αποδείξεις.

Η τελική αποδοχή γίνεται μέσα στο model instance

Ένας candidate που πέρασε το extracted task δεν γίνεται αυτομάτως patch. Κατατάσσεται ως προς module compatibility, shape coverage, phase compatibility και αναμενόμενη επίδραση, ενσωματώνεται στο μοντέλο και ξαναμετριέται για correctness και latency. Γίνεται δεκτός μόνο αν περάσει τους in-model ελέγχους και ξεπεράσει ένα ελάχιστο όριο πραγματικής βελτίωσης.

Τα runtime guards διατηρούν τη συμβατότητα των shapes και τα fallback paths αναλαμβάνουν τα μη βελτιστοποιημένα regimes. Έτσι το τελικό artifact δεν είναι απλώς κώδικας που έγραψε ένας LLM agent. Είναι κώδικας μαζί με dispatch, guards και αποδεδειγμένη συμπεριφορά στο συγκεκριμένο workload. Για production ομάδες, αυτή η διαφορά είναι καθοριστική: το acceptance criterion πρέπει να ταιριάζει με τον επιχειρησιακό στόχο.

Όπως δείχνει και η αξιολόγηση GUI agents με βάση την ποιότητα της διαδρομής, η τελική επιτυχία δεν πρέπει να κρύβει λανθασμένα βήματα, περιττές ενέργειες ή brittle fallbacks.

Τι έδειξαν τα δέκα workloads σε A100 και H100

Η αξιολόγηση καλύπτει transformer models, Mamba state-space models και RecurrentGemma. Στους transformers, το Qwen3-4B έφτασε speedup 3,03× στην A100 και 3,78× στην H100, ενώ το Qwen3-32B 2,19× και 2,55× αντίστοιχα. Τα Llama-2-7B και 13B παρουσίασαν μικρότερες αλλά θετικές βελτιώσεις, από 1,79× έως 2,22×.

Στις οικογένειες state-space οι αυξήσεις ήταν πολύ μεγαλύτερες στη συγκεκριμένη ρύθμιση. Το Mamba 130M αναφέρθηκε με 22,37× στην A100 και 32,79× στην H100, ενώ το Mamba2 2.7B με 15,23× και 14,04×. Το RecurrentGemma-9B είχε 1,24× στην A100 αλλά 7,55× στην H100. Η διακύμανση δείχνει γιατί δεν αρκεί μία σταθερή attention-first στρατηγική: διαφορετικές οικογένειες και GPUs εκθέτουν διαφορετικά hotspots.

Η σύγκριση με expert kernels χρειάζεται ίδιο scope

Για attention-only workloads, το paper συγκρίνει με FlashAttention· για state-space mixers, με τα hand-optimized paths mamba_ssm и causal-conv1d. Στο attention, το LLM4LLM είναι ανταγωνιστικό σε ορισμένα prompt/decode regimes, αλλά εξειδικευμένες υλοποιήσεις κρατούν πλεονέκτημα σε άλλα shapes. Αυτό αποτρέπει μια υπεραπλουστευμένη ανάγνωση ότι ο agent αντικαθιστά παντού expert kernels.

Στα mixers, οι generated replacements μπορούν να απορροφήσουν reshapes, projections και elementwise updates γύρω από ένα στενότερο library kernel. Η ευρύτερη deployable boundary εξηγεί γιατί σε μερικά regimes πλησιάζουν ή βελτιώνουν τις εξειδικευμένες fast paths. Πρόκειται για scope-matched παρατήρηση του paper, όχι για καθολική υπεροχή απέναντι σε κάθε βιβλιοθήκη ή production stack.

Το KernelBench είναι υποστηρικτικό evidence, όχι ο τελικός στόχος

Στο KernelBench Level 2, το LLM4LLM πέτυχε pass rate 100% στην A100 και 99% στην H100, με GeoMean speedup 2,745× και 2,628× αντίστοιχα έναντι eager PyTorch. Η εργασία κρατά χωριστά arithmetic mean και geometric mean, επειδή μεγάλα outliers μπορούν να διογκώσουν τον πρώτο. Στην A100, για παράδειγμα, ο arithmetic mean είναι 22,157× ενώ ο GeoMean 2,745×.

Οι συγγραφείς αναγνωρίζουν επίσης ότι unconstrained μοντέλα μπορούν να εκμεταλλευτούν benchmark ιδιαιτερότητες, όπως hard-coded outputs ή παρακάμψεις του intended computation. Στις απομονωμένες δοκιμές, η ανίχνευση τέτοιων exploits ανατίθεται στο harness. Αυτός είναι ακόμη ένας λόγος που η κύρια επιχειρηματολογία βασίζεται στα deployment experiments και στην model-integrated correctness.

Το ablation εξηγεί γιατί το restart έχει αξία

Τα experiments σε GPT-5.4, Claude Sonnet 4.6 και GLM-5 καλύπτουν 100 KernelBench Level-2 tasks ανά πλήρη αξιολόγηση. Το Sample-10 είναι σημαντικά ισχυρότερο από το Sample-1, άρα η ανεξάρτητη ποικιλία candidates αποτελεί σοβαρό baseline. Το Iter-10 φτάνει 100% pass rate και στα τρία μοντέλα, αλλά συχνά ξοδεύει πολλές προσπάθειες επισκευάζοντας μία τροχιά και υστερεί σε GeoMean ή Fast2 έναντι ισχυρότερου sampling.

Με episodic restart και budget 15 trials, καταγράφηκε ο καλύτερος GeoMean και για τα τρία backbones: 2,153 για GPT-5.4, 2,546 για Claude Sonnet 4.6 και 2,745 για GLM-5 έναντι eager. Η σύγκριση με τις εκδόσεις χωρίς restart υποστηρίζει ότι η συμπυκνωμένη εμπειρία και η επανεκκίνηση προσθέτουν αξία πέρα από τον μεγαλύτερο αριθμό δοκιμών.

Η δυναμική επιλογή τεχνικής βάσει evidence συνδέεται με το SmartSolve και το dynamic algorithm dispatch: ο στόχος δεν είναι να λατρεύουμε έναν solver ή έναν candidate, αλλά να επιλέγουμε αυτόν που αποδεικνύεται κατάλληλος για το συγκεκριμένο πρόβλημα.

Τι σημαίνει για ομάδες AI, SaaS και e-commerce

Η άμεση εφαρμογή αφορά inference infrastructure, όχι τη βελτιστοποίηση μιας καμπάνιας ή ενός e-shop. Ωστόσο, η μεθοδολογική αρχή μεταφέρεται προσεκτικά: proxy metrics και sandbox tests δεν πρέπει να παίρνουν μόνα τους αποφάσεις παραγωγής. Ένα ταχύτερο microbenchmark δεν εγγυάται χαμηλότερο user-perceived latency, όπως και ένα καλύτερο offline score δεν εγγυάται καλύτερη εμπειρία πελάτη.

Για μια ομάδα που προσφέρει AI λειτουργίες, το αντίστοιχο κλειστό loop περιλαμβάνει πραγματικά request distributions, quality and safety gates, end-to-end latency, fallback coverage και rollback-ready patches. Η ανάλυση αυτή είναι επιχειρησιακή ερμηνεία, όχι αποτέλεσμα που μέτρησε το paper σε εμπορικά συστήματα. Το τεκμηριωμένο μάθημα είναι ότι το deployment context αλλάζει την κατάταξη των τεχνικών επιλογών.

Η αξιοπιστία χρειάζεται και λειτουργική παρατηρησιμότητα. Η προσέγγιση του core dump epidemiology για software reliability δείχνει γιατί τα επαναλαμβανόμενα failure signatures πρέπει να γίνονται δεδομένα απόφασης και όχι απλώς tickets που κλείνουν μεμονωμένα.

Οι περιορισμοί που πρέπει να μείνουν ορατοί

Τα αποτελέσματα προέρχονται από συγκεκριμένα workloads, μοντέλα, A100/H100 GPUs και eager PyTorch baselines. Δεν τεκμηριώνουν ίδιο speedup απέναντι σε κάθε βελτιστοποιημένο serving stack, ούτε σε άλλα chips, batch regimes ή real-world traffic mixes. Οι scope-matched συγκρίσεις με expert kernels δείχνουν ήδη ότι εξειδικευμένες υλοποιήσεις παραμένουν καλύτερες σε ορισμένα attention shapes.

Το paper επίσης δεν μετατρέπει τη kernel generation σε διαδικασία χωρίς κόστος. Απαιτούνται profiling, compilation, πολλές δοκιμές candidates, πραγματικό hardware και προσεκτικά correctness thresholds. Το restart περιορίζει το άχρηστο context, αλλά η αναζήτηση παραμένει compute-intensive. Και επειδή η model-integrated acceptance είναι workload-specific, ένα patch που έγινε δεκτό για μία ρύθμιση χρειάζεται νέα επαλήθευση όταν αλλάξει το workload ή το runtime.

Η τρέχουσα εργασία στοχεύει single-GPU inference και προϋποθέτει αντιπροσωπευτικό inference script. Tensor parallelism, pipeline parallelism, continuous batching και multi-tenant serving εισάγουν πρόσθετα κριτήρια: communication cost, scheduler interaction, batch-level interference και resource contention. Αυτές οι συνθήκες δεν αξιολογούνται από τα δημοσιευμένα αποτελέσματα.

Η ουσία: βελτιστοποίηση είναι η απόδειξη μέσα στο σύστημα

Το LLM4LLM δεν κερδίζει μόνο επειδή ένα ισχυρό μοντέλο γράφει Triton. Η αρχιτεκτονική του συνδέει profiling του πραγματικού workload, phase-aware decomposition, compact experiential memory, runtime safety και end-to-end acceptance. Έτσι οι candidates κρίνονται από το αν βελτιώνουν το σύστημα, όχι από το αν εντυπωσιάζουν σε ένα απομονωμένο scoreboard.

Για engineering leaders, η πιο χρήσιμη αλλαγή νοοτροπίας είναι να ορίζουν πριν από το search τι σημαίνει deployable success: ποιες φάσεις καλύπτονται, ποια shapes έχουν fallback, ποια correctness όρια ισχύουν και ποιο end-to-end metric αποφασίζει. Η παραγωγή κώδικα είναι μόνο ένα στάδιο. Η πραγματική βελτιστοποίηση ολοκληρώνεται όταν το patch αποδειχθεί ασφαλές και ταχύτερο μέσα στο workload που μετρά.