हमने Opus 4.8 को Fable 5 से बदल दिया, और Devin का बिल कम हो गया।
Fable 5 की प्रति टोकन लागत Opus 4.8 से दोगुनी है। लेकिन जब हमने अपने नए Fusion आर्किटेक्चर का उपयोग करके FrontierCode 1.1 पर दोनों मॉडलों को चलाया, तो Fable की लागत कम आई। हैरानी की बात नहीं कि इसने उच्च स्कोर भी किया। यह पोस्ट बताती है कि ऐसा क्यों हुआ और इसका एजेंटिक कार्य के मूल्य निर्धारण पर क्या मतलब है।
परिचय
कोडिंग एजेंट चलाने वाला हर कोई जानता है कि मजबूत मॉडल बेहतर परिणाम देते हैं, लेकिन आपको लागत वहन करनी पड़ती है।
जब हमने Devin Fusion पेश किया, तो हमने एक रास्ता दिखाया: एक फ्रंटियर मॉडल को प्रभारी रखें, इसे एक सस्ते और तेज़ साइडकिक को काम सौंपने दें, और आपको 35% कम लागत पर फ्रंटियर-स्तरीय प्रदर्शन मिलता है।
लेकिन एक बार जब लीड मॉडल अधिकांश काम सौंप देता है, तो क्या इसकी प्रति टोकन कीमत अभी भी बिल पर हावी रहती है? Fable 5 की प्रति टोकन लागत Opus 4.8 से दोगुनी है, इसलिए Fable-नेतृत्व वाले एजेंट की लागत अधिक होनी चाहिए। पता लगाने के लिए, हमने FrontierCode 1.1 पर चार कॉन्फ़िगरेशनों में 3,000 मूल्यांकन सत्र चलाए: Fable और Opus मुख्य भूमिका में, प्रत्येक एक ही सस्ते साइडकिक के साथ और बिना।
शुद्ध रन बिल्कुल वैसे ही व्यवहार करते हैं जैसा अंतर्ज्ञान सुझाएगा: Fable Opus से बेहतर स्कोर करता है (60.8 बनाम 55.4) और अधिक खर्च करता है। बेहतर मॉडल, बड़ा बिल।
साइडकिक-सक्षम रनों में चीज़ें दिलचस्प हो जाती हैं।
एक ही साइडकिक देने पर, लागत का क्रम उलट जाता है: Fable + Sidekick की लागत Opus + Sidekick से कम है ($1.86 बनाम $2.04), जबकि स्कोर अधिक है (60.7 बनाम 54.6)। शुद्ध Fable की तुलना में, Fable + Sidekick लागत को 54% तक कम करता है जबकि स्कोर लगभग अपरिवर्तित रहता है।
कॉन्फ़िगरेशन | स्कोर | लागत/रन (माध्य) |
|---|---|---|
Fable 5 (low) + Sidekick | 60.7 | $1.86 |
Opus 4.8 (medium) + Sidekick | 54.6 | $2.04 |
Fable 5 (low) | 60.8 | $4.03 |
Opus 4.8 (medium) | 55.4 | $3.06 |
प्रति टोकन 2x प्रीमियम देखने के लिए गलत संख्या साबित होती है। एक एजेंट की लागत इस बात पर हावी होती है कि लीड मॉडल कितने टर्न लेता है, वह अपने साथ कितना संदर्भ खींचता है, और सबसे बढ़कर, वह क्या नहीं करने का निर्णय लेता है। अंतर प्रबंधन शैली में आता है: Opus एक इंटर्न के साथ माइक्रोमैनेजर की तरह व्यवहार करता है; Fable एक सक्षम इंजीनियर के साथ प्रबंधक है।
सेटअप
Fusion के साइडकिक आर्किटेक्चर के काम करने के तरीके पर एक त्वरित पुनरावृत्ति। लीड एजेंट सत्र का मालिक होता है: वह उपयोगकर्ता से बात करता है, योजना बनाता है, काम की समीक्षा करता है, और कमिट करता है। इसके पास कार्यों को सौंपने के लिए एक स्थायी साइडकिक उप-एजेंट भी होता है। लीड सादी भाषा में एक हैंडऑफ़ ब्रीफ लिखता है, और उप-एजेंट, जो एक बहुत सस्ते मॉडल द्वारा संचालित होता है, इसे अपने संदर्भ में पूरा करता है और रिपोर्ट करता है। लीड परिणाम की समीक्षा करता है और तय करता है कि आगे क्या होगा।
यह पता लगाने के लिए कि लागत कहाँ जाती है, हमने दो काम किए। पहला, हमने सभी 3,000 सत्रों में प्रत्येक LLM कॉल को पार्स किया: कौन सा मॉडल बोल रहा था, उसने किस टूल को कॉल किया, उसने कितने टोकन पढ़े और लिखे, और प्रत्येक कॉल की लागत क्या थी। दूसरा, हमने करीब से देखने के लिए 40 कार्य चुने: वे जहाँ Fable नाटकीय रूप से सस्ता था, वे जहाँ Opus था, और बीच से एक और यादृच्छिक नमूना। प्रत्येक के लिए, हमने Fable-नेतृत्व वाले रन और Opus-नेतृत्व वाले रन का साथ-साथ विश्लेषण किया, प्रक्षेपवक्र की जांच की और देखा कि पैसा कहाँ खर्च हुआ।
एक एजेंट की लागत
यहाँ बताया गया है कि हमारे प्रयोग में लागत लीड और साइडकिक के बीच कैसे विभाजित होती है:
लीड $ | साइडकिक $ | कुल $/रन | लीड टर्न/रन | लीड इनपुट टोकन (संचयी) | |
|---|---|---|---|---|---|
Fable + Sidekick | $1.28 | $0.58 | $1.86 | 11.5 | 545k tok |
Opus + Sidekick | $1.73 | $0.31 | $2.04 | 26.5 | 1,679k tok |
Fable अपने साइडकिक पर Opus से अधिक खर्च करता है — प्रति रन $0.27 अधिक। लेकिन यह अपने ऊपर $0.45 कम खर्च करता है। Fable का लीड प्रति रन 11.5 टर्न लेता है जबकि Opus का 26.5, आउटपुट टोकन का एक तिहाई लिखता है (6.1k बनाम 19.0k), और इनपुट टोकन का एक तिहाई उपभोग करता है। Fable प्रति टोकन काफी अधिक महंगा है, लेकिन संदर्भ प्रबंधन और टर्न गणना पर जीतता है।
Fable की टोकन बचत काम को पूरी तरह से टालने से आती है। दिलचस्प बात यह है कि Fable-नेतृत्व वाले 81% रनों में, लीड कभी भी एक भी कोड संपादन नहीं करता। Opus के लिए, यह केवल 24% रनों में सच है। 13% Fable-नेतृत्व वाले रनों में, लीड स्वयं कभी भी कोई रिपॉजिटरी फ़ाइल नहीं पढ़ता है।
एक इंटर्न के साथ माइक्रोमैनेजर बनाम एक इंजीनियर के साथ प्रबंधक
यहाँ बताया गया है कि अंतर को दिलचस्प क्या बनाता है: दोनों लीड समान संख्या में कार्य सौंपते हैं, प्रति रन लगभग 3 हैंडऑफ़। प्रति-कॉल लॉग इस आसान व्याख्या को खारिज करते हैं कि Fable बस अधिक सौंपता है। जो अलग है वह है कि वे कब और क्या सौंपते हैं। Fable का पहला हैंडऑफ़ जल्दी आता है। Opus अक्सर देर से सौंपता है, एक लंबी एकल अन्वेषण और कार्यान्वयन के बाद; तब तक, डिज़ाइन निर्णय हो चुके होते हैं, महत्वपूर्ण फ़ाइलें इसके संदर्भ में होती हैं, और महंगा काम हो चुका होता है।
GIF
एक विशिष्ट Fable-नेतृत्व वाला रन रिपॉजिटरी पर कुछ टोही कार्रवाई करता है, फिर पूरे इम्प्लीमेंट + टेस्ट + लिंट लूप को सौंपने वाला एक स्पेक-गुणवत्ता वाला ब्रीफ लिखता है। फिर डिफ़ की समीक्षा करने के लिए एक git show, और एक कमिट।
एक विशिष्ट Opus-नेतृत्व वाला रन 20-45 टर्न एकल अन्वेषण, डिज़ाइन और कार्यान्वयन से गुज़रता है, और यांत्रिक पूंछ के लिए एक देर से हैंडऑफ़।
कभी-कभी Fable की एक सत्र में पहली कार्रवाई एक हैंडऑफ़ होती है। उसी कार्य पर, दोनों लीड इस प्रकार खुले:
स्पष्ट समाधान Opus को अधिक अन्वेषण सौंपने के लिए बनाना है, लेकिन उस व्यवहार को बलपूर्वक लागू करने से प्रदर्शन कम हो जाता है। यह जानना कि कोई जांच कब सौंपना सुरक्षित है और कब यह कुछ ऐसा है जो आपको स्वयं करने की आवश्यकता है, अपने आप में एक निर्णय कॉल है। एक मॉडल जिसे सौंपने के लिए मजबूर किया जाता है, वह वह निर्णय प्राप्त नहीं करता; वह बस गलत चीजें सौंपता है।
प्रत्येक मॉडल की प्रबंधन शैली स्वयं हैंडऑफ़ ब्रीफ में भी प्रकट होती है। जब Opus कार्यान्वयन सौंपता है, तो वह निर्देश देता है, जबकि Fable एक डिज़ाइन दस्तावेज़ लिखता है:
प्रतिनिधिमंडल केवल लागत को स्थानांतरित नहीं करता; यह काम की गुणवत्ता को भी बदलता है। ऊपर हैशिंग कार्य एक स्पष्ट उदाहरण है। कार्य विनिर्देश में आवश्यक था कि हैश फ़ंक्शन पॉइंटर की लंबाई में O(1) हो। Opus ने इसे हाथ से लागू किया और उस आवश्यकता को कहीं भी नहीं लिखा। कहीं न कहीं यह बाधा भूल गया और एक रैखिक-समय कार्यान्वयन भेज दिया, जिसने 25 स्कोर किया। इसके विपरीत, Fable ने उच्च-स्तरीय बाधाओं का उपयोग करके प्रतिनिधिमंडल किया। इसके ब्रीफ में कहा गया, "operator() को पॉइंटर लंबाई में O(1) होना चाहिए: कोई पूर्ण टोकन स्कैन नहीं।" साइडकिक ने इसे सफलतापूर्वक लागू किया और 94 का स्कोर प्राप्त किया।
हमने पाया कि यह पैटर्न कार्यों में सामान्यीकृत होता है। Fable के हैंडऑफ़ में बाधाओं, किनारे के मामलों और 'पूर्ण' की परिभाषा की गणना की गई, जिससे स्वयं के प्रयास की बचत हुई जबकि साइडकिक को सस्ते और सही ढंग से कार्यान्वयन पूरा करने में सक्षम बनाया गया।
हैंडऑफ़ के बाद
दूसरा आधा हिस्सा यह है कि लीड एजेंट साइडकिक से वापस आने वाले काम के साथ क्या करता है। दोनों लीड अक्सर एक ही सस्ती जांच चलाते हैं: दो या तीन git diff/git show कॉल। लेकिन Opus वहाँ नहीं रुकता। यह साइडकिक की फ़ाइलों को अपने संदर्भ में 2x अधिक बार खींचता है और लीड कीमतों पर 4x अधिक सुधारात्मक संपादन करता है। चरम मामले में, इसने साइडकिक के काम को वापस ले लिया और इसे हाथ से फिर से लिखा:
Opus का अविश्वास शुद्धता को भी नहीं बढ़ाता है। कुछ मूल्यांकन कार्यों में, Fable की एकल डिफ़ समीक्षा ने वास्तविक साइडकिक बग पकड़े, और एक और सस्ते हैंडऑफ़ का विकल्प चुना, बजाय लीड-स्तरीय पुनर्लेखन के जो Opus अक्सर करता है।
जब प्रतिनिधिमंडल मदद नहीं करता
Fable की प्रतिनिधिमंडल रणनीति सार्वभौमिक रूप से उपयोगी नहीं है; यह विफल हो जाती है जब कार्य में सौंपने योग्य घटक नहीं होते हैं। निम्नलिखित प्रकार के कार्यों को विघटित करना कठिन लगता था:
- छोटे कार्य जिनमें केवल मुट्ठी भर लीड-मॉडल टर्न शामिल होते हैं और निर्णय लेने और भेजने के बीच सौंपने के लिए कुछ नहीं होता।
- सीरियल डिबगिंग कार्य जहां मूल-कारण की खोज निर्णयों की एक लंबी श्रृंखला है। यहाँ, संचित संदर्भ ही काम है।
उल्लेखनीय रूप से, इन कार्यों पर Fable मुश्किल से बिल्कुल भी प्रतिनिधिमंडल नहीं करता। वही निर्णय जो एक अच्छा ब्रीफ लिखता है, यह भी जानता है कि कब एक नहीं लिखना है। लेकिन जब कोई कार्य सौंपने लायक कुछ भी प्रदान नहीं करता है, तो प्रतिनिधिमंडल का लागत पर कोई लाभ नहीं होता है।
उत्पादन में, Fusion इसे दूसरी परत पर संभालता है: प्रतिनिधिमंडल नियंत्रित करता है कि कौन सा काम महंगे मॉडल के पास रहता है, जबकि रूटिंग तय करती है कि महंगा मॉडल बिल्कुल शामिल है या नहीं।
समापन
हमने इस प्रयोग की शुरुआत यह मापने की उम्मीद में की थी कि Fable का 2x प्रीमियम लागत को कितना बढ़ाएगा। हमें यह जानकर आश्चर्य हुआ कि Fable के प्रभावी प्रतिनिधिमंडल ने वास्तव में समग्र लागत को कम कर दिया। इसने कार्यान्वयन को विस्तार से बताने के बजाय बाधाओं और परिणामों को निर्दिष्ट किया, स्वयं सुधार करने के बजाय प्रतिक्रिया दी, और अधिकांश मामलों में कोड को कभी नहीं छुआ। ये एक अच्छे प्रबंधक की आदतें हैं।
जैसे-जैसे साइडकिक मॉडल सस्ते और बेहतर होते जाएंगे, अधिक काम उन्हें सौंपा जा सकता है। फ्रंटियर कीमतों के लायक क्या रहेगा वह है निर्णय: क्या बनाना है, क्या बाधित करना है, और इसे किसे लिखना चाहिए।
