DanLevy.net

अपने मॉडल से शादी न करें

LLM रूटिंग, अभी बहुत लोकप्रिय है

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

किसी भी समय, एक मॉडल कोड के लिए बेहतर है, दूसरा लंबी‑गंदगी वाली संदर्भ के लिए बेहतर है, और तीसरा सबसे सस्ता, नीरस कार्य‑भारी (जैसे वर्गीकरण) के लिए है। नाम बदलते रहते हैं, समस्या की प्रकृति नहीं बदलती। यदि आप एक मॉडल को सब कुछ कर सकता मान लेते हैं तो या तो आप साधारण कार्यों के लिए अधिक भुगतान कर रहे होते हैं या विशेष कार्यों पर घटिया परिणाम प्राप्त कर रहे होते हैं।

मैंने देखा कि एक टीम ने सेंटिमेंट एनालिसिस को $30‑प्रति‑मिलियन‑टोकन मॉडल से चलाते हुए हजारों डॉलर खर्च कर दिए, जबकि $0.50 मॉडल वही काम उतनी ही अच्छी तरह कर लेता। साधारण JSON फ़ॉर्मेटिंग, बेसिक क्लासिफिकेशन टास्क, सब उनके प्रीमियम प्रदाता के माध्यम से गया। एकमात्र चीज़ जो गर्म हुई वह उनका AWS बिल था।

एक बेहतर तरीका है, और यह विशेष रूप से जटिल नहीं है।

डेलीगेशन ओवर डिवोशन

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

Mastra आपको ठीक ऐसा सिस्टम बनाने देता है। आप विभिन्न प्रकार के कामों के लिए विशेषज्ञ एजेंट सेट‑अप करते हैं, फिर एक सुपरवाइज़र एजेंट बनाते हैं जो तय करता है कि प्रत्येक अनुरोध को कौन‑सा विशेषज्ञ संभालेगा। नीचे दिखाए गए मॉडल आईडी Mastra के वर्तमान provider/model स्ट्रिंग फ़ॉर्मेट का उपयोग करते हैं; वे केवल उदाहरण हैं, लीडरबोर्ड नहीं। इन्हें उन वर्तमान मॉडलों से बदलें जो आपके मूल्यांकन में जीतते हैं और आपके बजट में फिट होते हैं।

इसे इस तरह सोचें: आपकी टीम में तीन विशेषज्ञ हैं।

./src/mastra/index.ts
import { Mastra } from '@mastra/core/mastra';
import { Agent } from '@mastra/core/agent';
import { Memory } from '@mastra/memory';
import { LibSQLStore } from '@mastra/libsql';
export const claudeAgent = new Agent({
id: 'claude-agent',
description: 'Handles implementation, refactoring, and code review tasks.',
instructions: 'You are an expert engineer. Write bugs? You are fired.',
model: process.env.CODE_MODEL ?? 'anthropic/claude-sonnet-4-6',
});
export const geminiAgent = new Agent({
id: 'gemini-agent',
description: 'Handles long-context synthesis and messy document analysis.',
instructions: 'You are a creative writer. Be weird.',
model: process.env.LONG_CONTEXT_MODEL ?? 'google/gemini-2.5-pro',
});
export const gptAgent = new Agent({
id: 'gpt-agent',
description: 'Handles routine classification, formatting, and general Q&A.',
instructions: 'You are a helpful assistant. Be boring.',
model: process.env.GENERAL_MODEL ?? 'openai/gpt-5-mini',
});

हर एक की एक नौकरी है, और description फ़ील्ड रूटिंग सतह का हिस्सा है। आपका कोड एजेंट वह मॉडल होना चाहिए जो आपके रेपो‑विशिष्ट कोडिंग इवैल्युएशन पास करता हो। आपका लंबा‑संदर्भ एजेंट वह होना चाहिए जो आपके वास्तविक दस्तावेज़ों को बिना मध्य को सूप में बदले संभाल ले। आपका सामान्य एजेंट सस्ता, भरोसेमंद, और सबसे बेहतर तरीके से नीरस होना चाहिए।

अब बात दिलचस्प हो जाती है। आप एक हल्का‑फुल्का सुपरवाइज़र जोड़ते हैं जो एक बुद्धिमान प्रॉक्सी की तरह काम करता है:

export const supervisorAgent = new Agent({
id: 'supervisor-agent',
name: 'The Boss',
instructions: `You route work to the right specialist.
Delegate coding work to claude-agent.
Delegate long-context document work to gemini-agent.
Delegate routine classification and formatting to gpt-agent.
Do not do specialist work yourself unless delegation is unnecessary.`,
model: process.env.ROUTER_MODEL ?? 'openai/gpt-5-mini',
agents: {
claudeAgent,
geminiAgent,
gptAgent,
},
memory: new Memory({
storage: new LibSQLStore({ id: 'router-memory', url: 'file:mastra.db' }),
}),
});
export const mastra = new Mastra({
agents: { supervisorAgent, claudeAgent, geminiAgent, gptAgent },
});

सुपरवाइज़र स्वयं हल्के मॉडल पर चल सकता है क्योंकि यह मुख्यतः यह तय करता है कि ट्रैफ़िक कहाँ भेजना है। आप प्रीमियम दरें नहीं दे रहे हैं यह पता लगाने के लिए कि कौन‑सा प्रीमियम मॉडल उपयोग करना है। इसे भी मापें; एक खराब रूटिंग लेयर चुपचाप बचत को गलत रूटिंग में बदल देती है।

जब कोई बबल सॉर्ट इम्प्लीमेंटेशन माँगता है, तो राउटर इसे कोड कार्य के रूप में पहचानता है और आपके कोड विशेषज्ञ को सौंप देता है। रचनात्मक लेखन प्रॉम्प्ट? वह आवाज़ और रेंज के लिए चुने गए मॉडल को जाता है। ऐतिहासिक घटनाओं पर तथ्यात्मक प्रश्न? इसे सामान्य एजेंट को रूट करें, आदर्श रूप से रिट्रीवल के साथ जब ताज़ा जानकारी या उद्धरण महत्वपूर्ण हों।

व्यावहारिक लाभ

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

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

स्थिरता एक अतिरिक्त लाभ बन जाती है। जब OpenAI अपने आवधिक आउटेज में से एक का सामना करता है (और ऐसा होता रहता है), आपका राउटर ट्रैफ़िक को अन्य प्रदाताओं की ओर पुनः निर्देशित कर सकता है। आप एक विशिष्ट API के वापस आने का इंतज़ार करते‑हुए जल में फँसे नहीं रहते।

यह किसी दिखावे के लिए चतुर होने के बारे में नहीं है। यह ऐसे सिस्टम बनाने के बारे में है जो वित्तीय और तकनीकी दोनों रूप से समझ में आते हैं। आप हर निर्माण कार्य के लिए वही हथौड़ा नहीं इस्तेमाल करेंगे, और आपको हर AI कार्य के लिए वही भाषा मॉडल नहीं इस्तेमाल करना चाहिए।

इस दृष्टिकोण की खूबसूरती यह है कि आपके एप्लिकेशन कोड को शाखा‑भरी भूलभुलैया की ज़रूरत नहीं है। आप अभी भी एक एजेंट को कॉल करते हैं। कौन‑सा मॉडल किस कार्य के लिए उपयोग करना है, इसका निर्णय एक ही जगह पर रहता है, एक बार कॉन्फ़िगर किया जाता है, बजाय कोडबेस में कई शर्तीय लॉजिक बिखरे होने के।

संसाधन

श्रृंखला पढ़ें

  1. LLM रूटिंग (यह पोस्ट)
  2. सुरक्षा एवं गार्डरेल्स
  3. MCP एवं टूल इंटीग्रेशन
  4. वर्कफ़्लो एवं मेमोरी