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

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

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

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

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

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

प्रतिनिधित्व बनाम समर्पण

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

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

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

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 पर निर्भर करता है। यदि प्रदाता फेलओवर मायने रखता है, तो एप्लिकेशन कोड में एक स्पष्ट रीट्राय/फ़ॉलबैक नीति जोड़ें, फ़ॉलबैक राउटर को किसी भिन्न प्रदाता पर रखें, और विफलता पथ का परीक्षण करें। एजेंटों का एक बैग सिर्फ इसलिए सर्किट ब्रेकर नहीं है क्योंकि मॉडलों के अलग-अलग लोगो हैं।

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

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

संसाधन

• Mastra.ai दस्तावेज़ीकरण
• Mastra GitHub भंडार

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

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