मैंने हर काम के लिए Opus का उपयोग बंद कर दिया है। अभी भी Claude, Kimi, GPT का उपयोग कर रहा हूँ। AI की लागत रातों-रात 43% कम हो गई

एक सत्र की लागत, दोनों तरीकों से मापी गई

तीन कार्यों वाला एक Droid सत्र लें: पासवर्ड सिस्टम रीसेट करना, कॉपीराइट हेडर जोड़ना, और बिलिंग सर्विस को रीफैक्टर करना। इन सभी को Opus जैसे फ्रंटियर Claude मॉडल पर चलाएं और इनकी लागत क्रमशः $0.84, $0.62, और $1.41 होगी, जो सत्र के लिए कुल $2.87 है।

इसके बजाय उन्हें जटिलता के अनुसार रूट करें। पहले दो नियमित हैं, इसलिए वे कुशल मॉडलों पर $0.09 और $0.12 पर आ जाते हैं, जबकि रीफैक्टर फ्रंटियर मॉडल पर $1.41 पर रहता है। सत्र का कुल $1.62 है, 43% कम लागत पर समान आउटपुट, और एकमात्र चर जो बदला वह यह था कि किस मॉडल ने कौन सा कार्य संभाला।

अधिकांश इंजीनियरिंग टीमें एक मॉडल चुनती हैं और उसे वहीं छोड़ देती हैं। इसलिए नहीं कि यह इष्टतम है। बल्कि इसलिए कि सत्र के बीच में स्विच करने का मतलब है संदर्भ खोना, अतिरिक्त घर्षण, एक ऐसा निर्णय जो कोई भी दिन में 40 बार नहीं लेना चाहता। इसलिए वे सब कुछ सबसे सक्षम मॉडल पर डाल देते हैं जो वे खरीद सकते हैं और बिल को देखना बंद कर देते हैं।

उस डिफ़ॉल्ट की एक कीमत है। महँगा मॉडल सुरक्षित विकल्प नहीं है। यह सिर्फ महँगा है। और नियमित काम पर गुणवत्ता का अंतर इतनी तेज़ी से बंद हुआ है कि गणित अब मान्य नहीं रहा।

Factory Router उनके Droids प्लेटफॉर्म के अंदर बैठता है और प्रत्येक कार्य को स्वचालित रूप से रूट करता है: नियमित काम को कुशल मॉडलों पर, जटिल काम को फ्रंटियर मॉडलों पर, प्रत्येक स्विच पर पूरा संदर्भ ले जाता है। ऊपर दिए गए सत्र संख्याएँ उनके लॉन्च बेंचमार्क से हैं। Factory मॉडल नहीं बेचता, जिसका अर्थ है कि उनके पास आपको महँगे रास्ते पर रखने के लिए कोई संरचनात्मक प्रोत्साहन नहीं है। संख्याओं को पढ़ते समय यह ध्यान देने योग्य है।

जिस समस्या को कोई नहीं मापता

प्रत्येक Droid सत्र एक मॉडल पर चलता है, और अधिकांश टीमें Opus चुनती हैं और कभी उस विकल्प पर दोबारा विचार नहीं करतीं। उस डिफ़ॉल्ट की लागत अदृश्य है क्योंकि यह कभी गलती के रूप में नहीं दिखती। काम हो जाता है, आउटपुट अच्छा होता है, और बिल बस चुपचाप आवश्यकता से अधिक होता है।

ऊपर का एकल सत्र लगभग $1.25 बर्बाद करता है। यह तब तक कुछ नहीं लगता जब तक आप इसे गुणा नहीं करते। प्रति माह 10,000 सत्रों पर, वही डिफ़ॉल्ट $16,400 के आवश्यक खर्च को $28,700 के वास्तविक खर्च में बदल देता है, जो प्रति वर्ष $147,600 है जो नियमित काम को फ्रंटियर मॉडल के माध्यम से रूट करने पर खर्च होता है जिसकी कभी आवश्यकता नहीं थी।

अधिकांश टीमें पाती हैं कि उनके 30 से 50 प्रतिशत सत्र नियमित काम हैं जो उनके सबसे महँगे मॉडल पर चल रहे हैं। वह अंतर पूरा अवसर है, और नीचे तीन खंडों में इस अंतर को बंद करने के लिए पंद्रह नियम दिए गए हैं।

→ नियम 1: सबसे पहले अपने कार्य प्रकारों को वर्गीकृत करें:

text

1अपने पिछले 30 Droid कार्यों को देखें। उन्हें दो समूहों में बाँटें:
2
3Frontier-योग्य: सिस्टम आर्किटेक्चर, प्रमाणीकरण, भुगतान, सुरक्षा,
4क्रॉस-सर्विस निर्भरताएँ, ऐसा कुछ भी जहाँ गलत होने पर डीबग या रिवर्ट करने में समय लगता है।
5100 लाइनों से अधिक के जटिल बिज़नेस लॉजिक रीफैक्टर।
6
7नियमित: दस्तावेज़ अपडेट, कॉन्फ़िग बदलाव, मौजूदा फ़ंक्शन में टेस्ट जोड़ना,
8स्पष्ट स्पेक वाले छोटे बग फिक्स, कॉपीराइट हेडर, README संपादन,
9बॉयलरप्लेट जनरेशन, सरल माइग्रेशन।
10
11प्रत्येक समूह को गिनें।
12
13Factory के सेशन-लेवल डेटा के आधार पर:
14"पासवर्ड रीसेट करें" प्रकार के कार्य: Opus $0.84 बनाम रूटेड $0.09। 89% सस्ता।
15"कॉपीराइट हेडर जोड़ें" प्रकार के कार्य: Opus $0.62 बनाम रूटेड $0.12। 81% सस्ता।
16
17अपनी नियमित कार्य संख्या को उस अंतर से गुणा करें।
18वह अंतर आपका वर्तमान मॉडल चयन कर है।

→ नियम 2: वास्तविक खर्च को मापें, अनुमान को नहीं:

text

1अपने पिछले महीने के Droid सेशन लॉग निकालें।
2
3प्रत्येक सेशन के लिए:
4- कार्य प्रकार (नियम 1 वर्गीकरण से)
5- उपयोग किया गया मॉडल
6- लागत
7
8गणना करें:
9- फ्रंटियर मॉडल का उपयोग करने वाले नियमित कार्यों पर कुल खर्च
10- कुशल मॉडलों पर उन कार्यों की लागत कितनी होगी (80-90% कटौती लागू करें)
11- रूटिंग से उपलब्ध मासिक बचत
12
13Factory Router को सक्षम करने से पहले यह आपका आधार रेखा है।
14अधिकांश टीमें पाती हैं कि 30-50% सेशन फ्रंटियर मॉडल पर चलने वाले नियमित कार्य हैं।

→ नियम 3: कार्य विवरण लिखें जो जटिलता का संकेत दें:

text

1जिस तरह से आप किसी कार्य का वर्णन करते हैं, वह किसी भी रूटिंग सिस्टम को इसकी जटिलता का संकेत देता है।
2
3कम-जटिलता संकेत (कुशल मॉडलों पर रूट करता है):
4- "सरल कॉन्फ़िग अपडेट, कोई बिज़नेस लॉजिक नहीं: config.yaml में टाइमआउट को 30 से 60 में बदलें"
5- "/helpers में यूटिलिटी फ़ंक्शन में गुम JSDoc टिप्पणियाँ जोड़ें"
6- "नए डिप्लॉयमेंट चरणों को दर्शाने के लिए README अपडेट करें"
7
8उच्च-जटिलता संकेत (फ्रंटियर पर रूट करता है):
9- "3 सेवाओं में हमारे नए SSO एकीकरण का समर्थन करने के लिए auth मिडलवेयर को रीफैक्टर करें"
10- "पेमेंट प्रोसेसर में रेस कंडीशन को डीबग करें जो केवल समवर्ती लोड के तहत दिखाई देती है"
11- "प्रति-टेनेंट थ्रेशोल्ड को संभालने के लिए रेट लिमिटिंग सिस्टम को फिर से डिज़ाइन करें"
12
13विशिष्ट, संदर्भ-समृद्ध कार्य विवरण रूटिंग सटीकता में सुधार करते हैं।
14अस्पष्ट विवरण रूढ़िवादी रूप से फ्रंटियर मॉडलों पर रूट होते हैं।

→ नियम 4: अपने वार्षिक रूटिंग ROI की गणना करें:

text

1Factory Router बचत का अनुमान लगाने का फॉर्मूला:
2
3मासिक सत्र: [N]
4रूटिंग के बिना प्रति सत्र औसत लागत: [Opus बेसलाइन $ में]
5नियमित कार्य प्रतिशत: [आपके नियम 1 ऑडिट से %]
6नियमित लागत में कमी: 80-90%
7
8मासिक बचत अनुमान:
9N × बेसलाइन × नियमित% × 0.85 = मासिक रूप से वसूले गए डॉलर
10
11वार्षिक: 12 से गुणा करें।
12
13$2.87 औसत और 40% नियमित कार्य के साथ प्रति माह 5,000 सत्र चलाने वाली टीम के लिए:
145,000 × $2.87 × 0.40 × 0.85 = $4,879/माह = $58,548/वर्ष
15
16यह न्यूनतम है। मिशन (लंबे समय तक चलने वाले स्वायत्त कार्य) बचत को और बढ़ाते हैं।

→ नियम 5: दस्तावेज़ित करें कि आपके कोडबेस के लिए फ्रंटियर-मात्र का क्या अर्थ है:

text

1रूटिंग सक्षम करने से पहले, परिभाषित करें कि आपके कोडबेस के लिए फ्रंटियर मॉडल पर क्या रहना चाहिए।
2
3इसे एक बार लिखें। इसे अपने रूटिंग गाइडेंस बेसलाइन के रूप में पेस्ट करें:
4
5"निम्नलिखित के लिए हमेशा फ्रंटियर मॉडल की आवश्यकता होती है:
6- [प्रमाणीकरण/भुगतान/सुरक्षा परत] को छूने वाले कोई भी बदलाव
7- [N] से अधिक फ़ाइलों वाले क्रॉस-सर्विस रीफैक्टर
8- CI/CD पाइपलाइन कॉन्फ़िगरेशन में बदलाव
9- डेटाबेस स्कीमा माइग्रेशन
10- हमारे इश्यू ट्रैकर में [P0/क्रिटिकल] के रूप में चिह्नित कुछ भी
11
12बाकी सब कुछ कुशल मॉडलों पर रूटिंग के लिए पात्र है।"
13
14यह आपकी रूटिंग नीति दस्तावेज़ बन जाता है।
15आप इसे अपडेट करते हैं क्योंकि आप सीखते हैं कि आपके विशिष्ट कोडबेस में फ्रंटियर उपचार की क्या आवश्यकता है।

10 डेवलपर्स की टीम, 1,000 सत्र/माह, 40% नियमित: प्रति वर्ष $13,776 की बचत 50 डेवलपर्स की टीम, 5,000 सत्र/माह, 40% नियमित: प्रति वर्ष $58,548 की बचत एंटरप्राइज़ (Nvidia, Adobe पैमाना): छह-अंकीय वार्षिक बचत

बचने की गलती: Router को सक्षम करने से पहले प्रत्येक कार्य को मैन्युअल रूप से वर्गीकृत करने का प्रयास न करें। Router वर्गीकरण को संभालता है। आपका काम उन कठिन नियमों को परिभाषित करना है जो फ्रंटियर पर रहना चाहिए, और बाकी सब कुछ सिस्टम को संभालने देना है।

0:28

→ नियम 6: Factory Router को एक चरण में सक्षम करें:

text

1Factory CLI या डेस्कटॉप ऐप में:
2
31. मॉडल पिकर खोलें
42. "Factory Router" चुनें
53. हो गया।
6
7शुरू करने के लिए किसी कॉन्फ़िगरेशन की आवश्यकता नहीं है। Router तुरंत डिफ़ॉल्ट रूटिंग लॉजिक का उपयोग करता है।
8
9यह सत्यापित करने के लिए कि यह सक्रिय है:
10एक सरल कार्य चलाएँ ("इस फ़ाइल में एक टिप्पणी अपडेट करें")।
11मॉडल एट्रिब्यूशन के लिए सेशन लॉग देखें।
12आपको इसे Opus नहीं, बल्कि एक कुशल मॉडल द्वारा संभालते हुए देखना चाहिए।
13
14यदि आप किसी सरल कार्य पर Opus देखते हैं, तो सत्यापित करें कि Router चुना गया है न कि कोई विशिष्ट मॉडल ओवरराइड।

→ नियम 7: अपने कोडबेस के लिए रूटिंग गाइडेंस सेट करें:

text

1रूटिंग गाइडेंस सलाहकार है। यह Router को आपके विशिष्ट कोडबेस के लिए बेहतर निर्णय लेने में मदद करता है।
2यह किसी मॉडल को बाध्य नहीं करता।
3
4अपने रूटिंग गाइडेंस शुरुआती बिंदु के रूप में इसे पेस्ट करें और अपने स्टैक के लिए संपादित करें:
5
6"प्रमाणीकरण, भुगतान और सुरक्षा बदलाव: फ्रंटियर मॉडल।
7डेटाबेस माइग्रेशन और स्कीमा बदलाव: फ्रंटियर मॉडल।
8बाहरी उपभोक्ताओं को प्रभावित करने वाले API कॉन्ट्रैक्ट बदलाव: फ्रंटियर मॉडल।
9
10दस्तावेज़ अपडेट: कुशल मॉडल।
11मौजूदा फ़ंक्शन में टेस्ट जोड़ना: कुशल मॉडल।
12कॉन्फ़िग और एनवायरनमेंट वेरिएबल बदलाव: कुशल मॉडल।
13बॉयलरप्लेट जनरेशन और स्कैफोल्डिंग: कुशल मॉडल।
14कोड टिप्पणियाँ और JSDoc: कुशल मॉडल।
15README और चेंजलॉग अपडेट: कुशल मॉडल।
16
17बाकी सब कुछ: Router कार्य संदर्भ के आधार पर निर्णय लेता है।"

→ नियम 8: एंटरप्राइज़ गवर्नेंस के लिए रूटिंग गाइडेंस कॉन्फ़िगर करें:

text

1पैमाने पर एजेंट चलाने वाली टीमों के लिए, रूटिंग गाइडेंस एक गवर्नेंस दस्तावेज़ बन जाता है।
2
3विनियमित उद्योगों (बैंकिंग, हेल्थकेयर, एंटरप्राइज़ SaaS) के लिए मानक टेम्पलेट:
4
5"उच्च-संवेदनशीलता रूटिंग नियम:
6- [PII / वित्तीय डेटा / प्रमाणीकरण] को छूने वाला कुछ भी = केवल फ्रंटियर
7- कोई भी बाहरी API बदलाव = केवल फ्रंटियर
8- प्रोडक्शन डिप्लॉयमेंट स्क्रिप्ट = केवल फ्रंटियर
9- इंसीडेंट रिस्पॉन्स कार्य = केवल फ्रंटियर
10
11मानक रूटिंग:
12- विकास, स्टेजिंग और परीक्षण वातावरण = Router निर्णय लेता है
13- आंतरिक टूलिंग और ऑटोमेशन = कुशल मॉडल पसंदीदा
14- दस्तावेज़ीकरण, रिपोर्टिंग और संचार = कुशल मॉडल
15
16ओवरराइड नीति:
17कोई भी डेवलपर किसी कार्य के लिए फ्रंटियर का अनुरोध कर सकता है।
18Router इसे सलाहकार के रूप में नहीं, बल्कि एक कठिन ओवरराइड के रूप में मानता है।
19मासिक समीक्षा के लिए सभी फ्रंटियर ओवरराइड लॉग करें।"
20
21इसे अपने प्रोजेक्ट रूट में ROUTING_POLICY.md के रूप में सहेजें।
22अपनी CLAUDE.md या समकक्ष संदर्भ फ़ाइल में इसका संदर्भ दें।

→ नियम 9: रूटिंग सक्षम के साथ मिशन चलाएँ:

text

1मिशन Factory के लंबे समय तक चलने वाले स्वायत्त कार्य हैं।
2घंटों या दिनों का काम। किसी पर्यवेक्षण की आवश्यकता नहीं।
3
4Factory Router सक्षम होने पर, मिशन उसी रूटिंग लॉजिक से लाभान्वित होते हैं।
5एक मिशन में प्रत्येक चरण को उचित रूप से रूट किया जाता है।
6एक जटिल मिशन में सरल चरण कुशल मॉडलों पर चलते हैं।
7मिशन फ्रंटियर दरों का भुगतान तभी करता है जब वास्तव में फ्रंटियर तर्क की आवश्यकता होती है।
8
9कॉन्फ़िगर करने के लिए:
10कोई भी मिशन शुरू करने से पहले Factory Router सक्षम करें।
11ऐसी रूटिंग गाइडेंस जोड़ें जो मिशन की जटिलता प्रोफ़ाइल को दर्शाती हो:
12
13"इस मिशन में [उच्च-जटिलता कोर कार्य] और [नियमित सहायक कार्य] शामिल हैं।
14कोर कार्य (आर्किटेक्चरल निर्णय, सुरक्षा विश्लेषण): फ्रंटियर।
15सहायक कार्य (दस्तावेज़ीकरण, कॉन्फ़िग, बॉयलरप्लेट): कुशल मॉडल।
16किसी भी ऐसे चरण के लिए सबसे कुशल उपलब्ध मॉडल का उपयोग करें
17जिसके लिए ऊपर निर्दिष्ट तर्क की आवश्यकता नहीं है।"
18
19लंबे मिशनों में आनुपातिक रूप से अधिक बचत देखी जाती है क्योंकि वे अधिक नियमित चरण जमा करते हैं।

→ नियम 10: प्रदाता फेलओवर नीति सेट करें:

text

1Factory Router विश्वसनीयता के लिए प्रदाताओं के बीच रूट करता है।
2यदि एक प्रदाता पथ खराब होता है, तो सत्र एक स्वस्थ प्रदाता के माध्यम से जारी रहते हैं।
3
4अपटाइम आवश्यकताओं वाली एंटरप्राइज़ टीमों के लिए:
5
6"विश्वसनीयता रूटिंग नीति:
7- प्रति मॉडल प्राथमिक प्रदाता: [अपने पसंदीदा प्रदाता सूचीबद्ध करें]
8- फेलओवर ट्रिगर: कोई भी अनुरोध विफल होना या [N] सेकंड विलंबता से अधिक होना
9- फेलओवर व्यवहार: यदि उपलब्ध हो तो समान मॉडल, भिन्न प्रदाता।
10  यदि समान मॉडल अनुपलब्ध है, तो अगले फ्रंटियर मॉडल पर एस्केलेट करें।
11- समर्पित TPM: अपने टियर के लिए Factory खाता टीम से पुष्टि करें।
12- लक्ष्य: 99.9%+ अनुरोध विश्वसनीयता।
13
14सभी फेलओवर ईवेंट लॉग करें। प्रदाता स्वास्थ्य पैटर्न के लिए साप्ताहिक समीक्षा करें।"

टर्मिनल-बेंच 2: 20% कम लागत पर Opus की 99% पास दर लीगेसी-बेंच: 25% कम लागत पर Opus की 96% पास दर प्रदाता रूटिंग के माध्यम से 99.9%+ अनुरोध विश्वसनीयता

3 / 3 | प्रणाली: Factory को उस पैमाने पर चलाना जहाँ बचत चक्रवृद्धि होती है

लागत बचत की कहानी व्यक्तिगत डेवलपर स्तर पर दिलचस्प है। यह टीम स्तर पर महत्वपूर्ण हो जाती है। एंटरप्राइज़ पैमाने पर, यह एक बजट लाइन है।

Nvidia. Adobe. EY. Palo Alto Networks. Adyen। ये Factory के एंटरप्राइज़ ग्राहक हैं।

5,000 सत्र प्रति माह चलाने वाली एक टीम 40% नियमित कार्य दर पर अकेले रूटिंग से प्रति वर्ष $58,548 की बचत करती है। 50,000 सत्रों पर एक टीम $585,480 की बचत करती है। गणित मात्रा के साथ रैखिक रूप से बढ़ता है। एंटरप्राइज़ टोकन बिल रैखिक नहीं हैं।

गहरा मुद्दा आर्किटेक्चर के बारे में है। अधिकांश AI एजेंट प्लेटफ़ॉर्म एकल-मॉडल धारणा पर बनाए गए हैं। एक टीम, एक मॉडल, एक विक्रेता। Factory का प्लेटफ़ॉर्म डिज़ाइन द्वारा मॉडल-अज्ञेयवादी है: कोई भी LLM (Claude, GPT, Gemini, Llama, ओपन सोर्स), कोई भी इंटरफ़ेस (CLI, डेस्कटॉप, VS Code, Slack, GitHub, Linear, Jira, CI पाइपलाइन), सॉफ़्टवेयर लाइफसाइकल का कोई भी चरण।

Router उस आर्किटेक्चर की एक परत है। यह लागत नियंत्रण परत है। वही Droid संदर्भ जो आपके टर्मिनल में काम करता है, Slack में काम करता है। वही रूटिंग नीति जो व्यक्तिगत सत्रों पर लागू होती है, दिनों तक चलने वाले मिशनों पर लागू होती है।

अंतिम पाँच नियम Router के आसपास पूर्ण Factory सिस्टम का निर्माण करते हैं।

→ नियम 11: रूटिंग बचत को साप्ताहिक मापें:

text

1Router प्रदर्शन को ट्रैक करने के लिए एक साप्ताहिक दिनचर्या सेट करें।
2
3Factory सेशन लॉग में जाँच करें:
41. इस सप्ताह कुल सत्र
52. मॉडल वितरण (कितने प्रतिशत प्रत्येक मॉडल पर गए)
63. रूटिंग के साथ लागत बनाम बेसलाइन (हर चीज़ पर Opus)
74. कोई भी सत्र जहाँ Router ने फ्रंटियर पर एस्केलेट किया (गुणवत्ता संकेत)
8
9रिपोर्ट प्रारूप:
10> सत्र: [N]
11> कुशल मॉडल उपयोग: [%]
12> फ्रंटियर मॉडल उपयोग: [%]
13> वास्तविक खर्च: $[राशि]
14> बेसलाइन (सभी Opus) होता: $[गणना]
15> साप्ताहिक बचत: $[राशि]
16> फ्रंटियर पर एस्केलेशन: [N] (रूटिंग गाइडेंस में सुधार के लिए समीक्षा करें)
17
18यदि एस्केलेशन दर 10% से ऊपर है, तो अपनी रूटिंग गाइडेंस की समीक्षा करें।
19बहुत अधिक एस्केलेशन का मतलब है कि नियमित कार्यों को जटिल के रूप में वर्णित किया जा रहा है।

→ नियम 12: पूर्ण रोलआउट से पहले एजेंट तत्परता मूल्यांकन:

text

1अपनी पूरी टीम के लिए Factory Router तैनात करने से पहले, Factory का एजेंट तत्परता मूल्यांकन चलाएँ।
2
3यह 100+ संकेतों का मूल्यांकन करता है:
4- कोडबेस स्वास्थ्य (टेस्ट कवरेज, CI विश्वसनीयता, दस्तावेज़ीकरण)
5- वर्कफ़्लो परिपक्वता (PR प्रक्रिया, कोड समीक्षा मानक, डिप्लॉयमेंट पाइपलाइन)
6- टीम तत्परता (एजेंटिक टूल्स से परिचित होना, मौजूदा ऑटोमेशन)
7
8आउटपुट का उपयोग यह प्राथमिकता देने के लिए करें कि कौन से वर्कफ़्लो पहले रूट करने हैं।
9
10उच्च-तत्परता वर्कफ़्लो: तुरंत Router तैनात करें, पूर्ण रूटिंग सक्षम।
11मध्यम-तत्परता वर्कफ़्लो: रूढ़िवादी गाइडेंस के साथ Router तैनात करें, अधिक फ्रंटियर कार्य।
12निम्न-तत्परता वर्कफ़्लो: रूटिंग से पहले तत्परता का निर्माण करें।
13अपरिपक्व कोडबेस पर एजेंटिक टूल त्रुटियों को सुधारने में फ्रंटियर मॉडल पर अधिक समय बिताते हैं।
14
15Router बचत उच्च-तत्परता वातावरण में सबसे अधिक होती है।

→ नियम 13: अपना मॉडल पूल जानबूझकर बनाएँ:

text

1Factory Router फ्रंटियर और कुशल मॉडलों के एक पूल से खींचता है।
2आपके द्वारा कॉन्फ़िगर किया गया पूल उपलब्ध रूटिंग विकल्पों को प्रभावित करता है।
3
4अनुशंसित प्रारंभिक पूल:
5
6फ्रंटियर टियर (जटिल कार्य):
7- Claude Opus (नवीनतम संस्करण)
8- GPT-5.2 (यदि आपके अनुमोदित विक्रेता सूची में है)
9
10कुशल टियर (नियमित कार्य):
11- Kimi K2.6 (कोड कार्यों के लिए प्रति F1 बिंदु सर्वोत्तम मूल्य)
12- MiniMax M2.7 (सरल कार्यों के लिए सबसे कम लागत)
13
14अपने कोडबेस पर प्रदर्शन को मान्य करने के बाद मॉडल जोड़ें।
15दो-टियर संरचना से शुरू करें।
16एक बार रूटिंग डेटा होने पर तीन टियर (फ्रंटियर / मध्य / कुशल) तक विस्तार करें।
17
18दस्तावेज़ित करें कि कौन से मॉडल किन अनुपालन आवश्यकताओं के लिए स्वीकृत हैं।
19यदि आपका एंटरप्राइज़ कुछ मॉडल प्रदाताओं को प्रतिबंधित करता है, तो पूल को तदनुसार कॉन्फ़िगर करें।
20डेटा निवास की आवश्यकता वाले वातावरण के लिए US-होस्टेड ओपन-सोर्स मॉडल Factory के माध्यम से उपलब्ध हैं।

→ नियम 14: रूटिंग को अपनी CI पाइपलाइन में एकीकृत करें:

text

1Factory CI पाइपलाइनों में काम करता है। रूटिंग वहाँ भी लागू होती है।
2
3अपने GitHub Actions वर्कफ़्लो में Factory Router जोड़ें:
4
5पुल रिक्वेस्ट समीक्षा के लिए:
6"PR समीक्षा कार्यों को फ़ाइल परिवर्तन दायरे के अनुसार रूट करें।
7- सुरक्षा और प्रमाणीकरण फ़ाइल बदलाव: फ्रंटियर मॉडल
8- टेस्ट फ़ाइलें: कुशल मॉडल
9- दस्तावेज़ीकरण बदलाव: कुशल मॉडल
10- मिश्रित PR: यदि संभव हो तो अनुभाग दर अनुभाग रूट करें, अन्यथा पूर्ण समीक्षा के लिए फ्रंटियर"
11
12स्वचालित QA के लिए:
13"QA कार्यों को टेस्ट जटिलता के अनुसार रूट करें।
14- क्रिटिकल पथ एंड-टू-एंड टेस्ट: फ्रंटियर मॉडल
15- यूनिट टेस्ट जनरेशन: कुशल मॉडल
16- रिग्रेशन टेस्ट सूट: कुशल मॉडल"
17
18CI रूटिंग बचत को चक्रवृद्धि करता है क्योंकि यह प्रत्येक कमिट पर चलता है।
19प्रतिदिन 100 कमिट पर टेस्ट जनरेशन में Opus और Kimi K2.6 के बीच लागत का अंतर महत्वपूर्ण है।

→ नियम 15: मासिक रूटिंग नीति समीक्षा सेट करें:

text

1रूटिंग गाइडेंस को आपके कोडबेस और टीम के बढ़ने के साथ विकसित होना चाहिए।
2
3मासिक समीक्षा एजेंडा (30 मिनट):
4
51. लागत रिपोर्ट: वास्तविक बनाम बेसलाइन, बचत प्रवृत्ति
62. एस्केलेशन विश्लेषण: कौन से कार्य एस्केलेट हुए और क्यों
73. रूटिंग गाइडेंस अपडेट: क्या वर्तमान गाइडेंस अभी भी कोडबेस जटिलता को दर्शाती है?
84. नए मॉडल मूल्यांकन: पूल में जोड़ने लायक कोई नया मॉडल?
95. टीम प्रतिक्रिया: क्या डेवलपर बार-बार Router को ओवरराइड कर रहे हैं? क्यों?
10
11प्रश्न जो संकेत देते हैं कि आपकी रूटिंग गाइडेंस को अपडेट करने की आवश्यकता है:
12- एस्केलेशन दर 15% से ऊपर: गाइडेंस कुशल मॉडलों की ओर बहुत आक्रामक है
13- एस्केलेशन दर 2% से नीचे: गाइडेंस बहुत रूढ़िवादी हो सकती है, बचत को छोड़ रही है
14- डेवलपर ओवरराइड दर 20% से ऊपर: Router डेवलपर अपेक्षाओं से मेल नहीं खा रहा है
15
16प्रत्येक समीक्षा के बाद ROUTING_POLICY.md अपडेट करें।

Factory Router के बिना: प्रत्येक सत्र फ्रंटियर पर चलता है, कार्य प्रकार की परवाह किए बिना Factory Router के साथ: नियमित कार्य कुशल मॉडलों पर, जटिल कार्य फ्रंटियर पर परिणाम: 96-99% फ्रंटियर बेंचमार्क प्रदर्शन बनाए रखते हुए 20-43% लागत में कमी

निष्कर्ष

यहाँ गणित कहाँ उतरता है।

अधिकांश टीमों पर 40-60% इंजीनियरिंग Droid सत्र नियमित कार्य होते हैं Opus पर उन सत्रों की औसत लागत: $2.87 प्रति सत्र रूटिंग के साथ उन सत्रों की औसत लागत: $1.62 10,000 सत्र प्रति माह पर: प्रति वर्ष $147,600 की बचत

बेंचमार्क संख्याएँ कायम हैं: 20% कम लागत पर टर्मिनल-बेंच 2 पर Opus की 99% पास दर। 25% कम लागत पर लीगेसी-बेंच पर 96%। मॉडल स्विच के बीच प्रॉम्प्ट कैश बरकरार रहता है, इसलिए जब राउटर सत्र के बीच में मॉडल बदलता है तो गुणवत्ता नहीं गिरती। प्रदाता फेलओवर सत्रों को 99.9%+ विश्वसनीयता पर चालू रखता है।

Factory Router निजी शोध पूर्वावलोकन में है। आप इसे मॉडल पिकर में एक बार चुनते हैं। कोई अतिरिक्त सेटअप नहीं।

मैं अभी भी समझने की कोशिश कर रहा हूँ: विभिन्न कोडबेस प्रकारों में सलाहकार रूटिंग गाइडेंस कितनी अच्छी तरह काम करती है। "प्रमाणीकरण बदलाव = फ्रंटियर, दस्तावेज़ ट्वीक = नियमित" जैसे नियम निर्धारित करना कागज पर साफ लगता है। क्या होता है जब कोई कार्य बीच में बैठता है? यह देखने लायक एज केस है क्योंकि अधिक टीमें इसका उपयोग करना शुरू करती हैं।

उपरोक्त 15 नियम सेटअप सिस्टम हैं। नियम 1 और 6 से शुरू करें।

factory.com

p.s. वह पंक्ति जिसे अधिकांश लोग स्किम करेंगे: Factory मॉडल नहीं बेचता। वे आपके टोकन बिल से लाभ नहीं कमाते। वह संरचनात्मक अंतर ही है कि इस तरह की रूटिंग प्रणाली पहले स्थान पर मौजूद है। यह देखना उत्सुकतापूर्ण है कि जैसे-जैसे पूल में अधिक मॉडल जोड़े जाते हैं, क्या होता है।

इसे बुकमार्क करें इससे पहले कि यह दब जाए

अगर यह उपयोगी था, तो इसे एक ऐसे व्यक्ति के साथ साझा करें जिसे इसकी आवश्यकता है