एक मॉडल कभी काफ़ी क्यों नहीं होता

एक मॉडल का जाल

हर बड़ा प्रदाता चाहता है कि आप मानें कि उसका प्रमुख मॉडल हर प्रश्न का सही उत्तर है। यह विश्वास उसके लिए व्यापार में सुविधाजनक है और आपके लिए तकनीकी रूप से ग़लत।

लंबे प्रसंग वाली विधिक तर्कणा में चमकने वाला मॉडल दस शब्दों की चित्र-टिप्पणी लिखने के लिए सही नहीं। अत्याधुनिक दृष्टि वाला मॉडल संरचित JSON को फिर से सजाने वाले थोक काम के लिए अनावश्यक है—और संभवतः बहुत महँगा। जिस मॉडल का दाम प्रवाह-क्षमता के हिसाब से बैठा है, वह तब सबसे बुरा चुनाव हो सकता है जब आपको दो सेकंड में उत्तर चाहिए।

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

नाम नहीं, क्षमताएँ

काम की अमूर्तता «कौन-सा मॉडल» नहीं, बल्कि «इस अनुरोध को कौन-सी क्षमताएँ चाहिए» है। इस प्रश्न का सटीक उत्तर है।

पर्दा-चित्र लगी बातचीत के संदेश को दृष्टि चाहिए। बाहरी API पुकारने वाले कार्यप्रवाह के चरण को औज़ार चाहिए। अपने ही निर्गम की जाँच करने वाली कोड-सहायिका को संहिता का निष्पादन चाहिए। रात में चलने वाली सार-शृंखला को तेज़ होने की ज़रूरत नहीं, इसलिए वह थोक दाम बरत सकती है; उत्पाद के भीतर बैठी वह सहायिका जिसका कोई इंतज़ार कर रहा है, नहीं बरत सकती।

जब आप पहले क्षमताओं की माँगें गिनाते हैं, तो मॉडल का चुनाव छानने और क्रम लगाने का काम बन जाता है। दिए गए समुच्चय पर—मान लीजिए पाठ, दृष्टि और संरचित निर्गम—आप वे सारे मॉडल ढूँढ़ते हैं जो तीनों सँभालते हैं, फिर उन्हें मौजूदा अनुरोध के प्रसंग के लिए गुणवत्ता और दाम से क्रम में लगाते हैं। यह क्रम अनुरोध-दर-अनुरोध बदल सकता है, इस पर कि वह व्यक्ति क्या कर रहा है और उसके धन की स्थिति कैसी है।

ToRun की बँटवारे की शृंखला ठीक यही करती है। विधा (बातचीत, कोड, चित्र, अनुसंधान आदि) एक क्षमता-समुच्चय पर बैठती है। वह समुच्चय मॉडल-सूची छानता है। दाम और गुणवत्ता का क्रम विजेता चुनता है। परिणाम यह है कि आप बड़ी मात्रा में संरचित निष्कर्षण के लिए DeepSeek, सूक्ष्म तर्कणा के लिए Claude या GPT-4 श्रेणी के मॉडल, लंबे प्रसंग वाले दस्तावेज़-कार्य के लिए Google Gemini और रचना के लिए कोई विशेषीकृत चित्र-मॉडल बरत सकते हैं—सब एक ही उत्पाद-धरातल से, बिना ख़ुद बाँटने का तर्क लिखे।

विकल्प कोई अच्छी-सी अतिरिक्त बात नहीं

प्रदाताओं की ख़राबियाँ कोई दुर्लभ किनारे की बात नहीं। वे पूरे उद्योग में महीने में कई बार होती हैं। यदि आपका उत्पाद एक ही प्रदाता पर टिका है और उसका API कमज़ोर पड़े, तो आपका उत्पाद भी उसी के साथ कमज़ोर पड़ जाता है।

वैकल्पिक शृंखला संचालन की न्यूनतम शर्त है: जब मुख्य मॉडल किसी अनुरोध पर क्षणिक त्रुटि लौटाए, तो मंच अगले सबसे उपयुक्त मॉडल पर फिर कोशिश करता है। इसके लिए ज़रूरी है कि बँटवारे की परत पहले से जानती हो कि कौन-से मॉडल उपयुक्त हैं—और क्षमता से बँटवारा ठीक यही देता है।

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

व्यावहारिक निष्कर्ष

जब आप मंचों को तौलें, दो प्रश्न पूछिए: वह हर अनुरोध के लिए मॉडल कैसे चुनता है, और जब वह मॉडल उपलब्ध न हो या बहुत महँगा पड़े, तब क्या होता है?

यदि इनमें से किसी का उत्तर «वह सदा मॉडल X लेता है» हो, तो यह रचना की बू है। आज उपलब्ध मॉडल छह महीने बाद के सबसे अच्छे मॉडल नहीं होंगे। नए प्रदाता आते हैं। दाम खिसकते हैं। क्षमता की सीमाएँ बदलती हैं। जो रचना मॉडल के चुनाव को व्यवस्था का निर्णय नहीं, बँटवारे की समस्या मानती है, वह बेहतर बूढ़ी होती है, समय के साथ कम ख़र्च कराती है, और दबाव में अधिक शालीनता से कमज़ोर पड़ती है।

एक मॉडल आरंभ का बिंदु है। बँटवारे की परत ही असली नींव है।