Snowflake Cortex AI Gateway अब हर काम के लिए सही AI मॉडल चुन सकेगा

Router का लक्ष्य administrator द्वारा मंजूर किए गए models में से ऐसा सबसे किफायती model चुनना है, जो task को भरोसे के साथ पूरा कर सके। नियमित, दोहराए जाने वाले या कम जटिल अनुरोध efficient open models को दिए जा सकते हैं। इसके विपरीत, कठिन reasoning वाले tasks को Anthropic, OpenAI और Google जैसे providers के frontier models तक भेजा जा सकता है।

ग्राहकों के पास पूरा manual control भी रहेगा। वे किसी एक model को pin कर सकते हैं या automatic routing के लिए उपलब्ध models की सूची सीमित कर सकते हैं। Snowflake का कहना है कि routing data-residency requirements और governance policies का पालन कर सकती है तथा हर request के लिए चुने गए model का रिकॉर्ड रख सकती है। इससे यह सुविधा केवल AI खर्च घटाने का साधन नहीं, बल्कि auditable model-selection process का हिस्सा भी बन सकती है।

Routing कैसे काम कर सकती है?

Snowflake ने model चुनने के लिए दो प्रमुख mechanisms बताए हैं।

1. Advisor pattern

इस pattern में पहले एक छोटा model task को हल करने की कोशिश करता है। अगर वह काम पर्याप्त रूप से पूरा नहीं कर पाता, तो वह बड़े model को tool की तरह invoke करके आगे बढ़ सकता है। इसका उद्देश्य सरल requests पर frontier-model की कीमत से बचना है, साथ ही कठिन मामलों के लिए escalation का रास्ता खुला रखना है।

2. Classifier-based routing

एक अलग classifier पुराने queries के patterns का इस्तेमाल करके सीधे पहचान सकता है कि कौन-से requests आसान हैं। ऐसे अनुरोधों को सरल models तक भेजा जा सकता है। इस तरह system के पास दो रास्ते होंगे: पहले छोटे model से शुरुआत करके जरूरत पड़ने पर escalation, या request को पहले classify करके शुरुआत से ही उपयुक्त model चुनना।

हालांकि, operational सवाल यह है कि क्या ये तरीके पूरे task के परिणाम को बेहतर बनाते हैं। पहली कोशिश असफल होने, बड़े model तक escalation करने या retry की जरूरत पड़ने पर अतिरिक्त tokens, latency और engineering complexity जुड़ सकती है।

Snowflake के बताए efficiency results

Snowflake ने बताया कि dynamic routing ने उसके आंतरिक dbt-pipeline workload में frontier models का ही इस्तेमाल करने की तुलना में समान गुणवत्ता बनाए रखते हुए token efficiency को 3 गुना तक बेहतर किया। एक अलग coding-workload test में कंपनी के अनुसार engineering teams ने pull-request throughput बनाए रखा और लगभग 25% कम tokens का इस्तेमाल किया।

इन आंकड़ों को vendor-reported internal evaluations के रूप में देखना चाहिए, न कि स्वतंत्र रूप से सत्यापित customer results के रूप में। परिणाम workload के अनुसार काफी बदल सकते हैं। Repetitive data-engineering या coding tasks पर अच्छा प्रदर्शन करने वाला router लंबे context वाले research tasks, जटिल tool use या high-risk decisions में अलग नतीजे दे सकता है।

इसलिए ग्राहक के लिए सबसे उपयोगी metric केवल “कितने tokens बचे” नहीं है। सही माप होगा—अच्छी गुणवत्ता के साथ सफलतापूर्वक पूरा किए गए और स्वीकार किए गए task की कुल लागत, जिसमें quality, latency, reliability और human rework भी शामिल हों।

DeepSeek और GLM से बढ़ेगा model विकल्पों का pool

Snowflake Cortex AI में उपलब्ध models की सूची में DeepSeek-V4-Flash 0731 और Z.ai का GLM-5.3 जोड़े जा रहे हैं। DeepSeek-V4-Flash 0731 को private preview में घोषित किया गया है, जिसमें CoCo का access भी शामिल है। GLM-5.3 के लिए private preview जल्द आने की बात कही गई है, लेकिन यह model availability पर निर्भर करेगा।

Snowflake के आंतरिक परीक्षण में CoCo को agent harness के रूप में इस्तेमाल करते हुए DeepSeek-V4-Flash ने ADE-bench पर 74.4% score किया। कंपनी ने GLM-5.2 के पुराने परीक्षण का भी उल्लेख किया, जिसमें score 66% और token footprint सबसे कम बताया गया। यह परिणाम GLM-5.2 का है, GLM-5.3 का प्रकाशित evaluation नहीं; इसलिए इसे GLM-5.3 के प्रदर्शन के रूप में नहीं पढ़ना चाहिए।

Open models के विकल्प बढ़ने से routing strategy को मदद मिलती है। बड़ा model pool system को task की जरूरत, लागत और performance के बीच बेहतर match खोजने के अधिक अवसर देता है। इससे ग्राहकों को केवल चर्चित frontier providers पर निर्भर रहने के बजाय अधिक विकल्प मिलते हैं।

Snowflake का governed-data-boundary दावा

Snowflake की सबसे महत्वपूर्ण differentiation claim यह है कि model routing उसके मौजूदा governed-data environment से जुड़ी रहेगी। कंपनी का कहना है कि वह नए open models को खुद serve करती है, केवल third-party API को proxy नहीं करती। उसके अनुसार data, inference compute, model weights और agent orchestration Snowflake के security perimeter के भीतर काम कर सकते हैं। कंपनी existing role-based access control और audit mechanisms का भी हवाला देती है।

यह Snowflake का architectural claim है, हर deployment के लिए सार्वभौमिक गारंटी नहीं। ग्राहकों को अपने environment के लिए deployment region, data residency, contractual terms, logging behavior और किसी workload के लिए eligible models की वास्तविक सूची की पुष्टि करनी होगी।

इस approach का आकर्षण उन संगठनों के लिए अधिक हो सकता है जिनका governed analytical data और AI applications पहले से Snowflake पर केंद्रित हैं। ऐसे मामलों में gateway का मूल्य केवल सस्ता model चुनने तक सीमित नहीं रहता; model selection उसी control और audit framework का हिस्सा बन सकता है, जिसका इस्तेमाल data access के लिए किया जाता है।

AWS, Databricks और neutral gateways से तुलना

Model routing का विचार केवल Snowflake तक सीमित नहीं है। Databricks का Unity AI Gateway models और MCP services के लिए central control plane देता है तथा providers के बीच capacity, availability और spend को manage करने पर जोर देता है।

Amazon Bedrock का Intelligent Prompt Routing एक serverless endpoint के जरिए एक ही model family के भीतर अलग-अलग foundation models के बीच requests भेजता है। इसका लक्ष्य अनुमानित response quality और लागत के आधार पर quality-cost balance सुधारना है।

Google Cloud का API Gateway model routing OpenAI-compatible requests को निर्धारित Gemini Enterprise Agent Platform model endpoints तक भेजने वाली managed traffic layer के रूप में काम करता है। NVIDIA का NeMo Switchyard provider-agnostic routing SDK/layer है, जबकि OpenRouter multi-provider aggregation और provider routing पर अधिक जोर देता है।

इसलिए व्यावहारिक तुलना यह नहीं है कि “किसके पास routing है?” बल्कि यह है कि governance, data access, routing policy, model execution और billing visibility कहाँ manage होते हैं। Snowflake tight in-platform governance पर जोर देता है। Neutral gateways आम तौर पर cross-provider flexibility और portability को प्राथमिकता दे सकते हैं।

खरीदार के लिए मोटे तौर पर:

• Integrated approach तब उपयोगी हो सकता है जब governed data, access controls, agent orchestration और model usage पहले से एक ही data platform पर केंद्रित हों।
• Neutral gateway तब बेहतर fit हो सकता है जब cross-provider portability, independent routing logic या multi-cloud flexibility अधिक महत्वपूर्ण हो।
• Model pool की वास्तविक जाँच जरूरी है; यह मान लेना ठीक नहीं कि हर gateway समान providers, model families, regions या deployment types के बीच routing कर सकता है।

Cost savings को स्वीकार करने से पहले क्या मापें?

Automatic routing की तुलना representative production workloads पर fixed-frontier-model baseline से करनी चाहिए। कम-से-कम इन metrics को track करें:

• केवल चुने गए model की token price नहीं, बल्कि सफलतापूर्वक पूरे हुए task की कुल लागत।
• Router या classifier से जुड़े platform charges, यदि कोई हों।
• Advisor escalation, fallback, retries या असफल tool execution से होने वाली अतिरिक्त calls।
• End-to-end latency, जिसमें routing, retrieval, context assembly और second-pass calls शामिल हों।
• अलग-अलग workload categories में task success rate और output quality।
• छोटे models के कारण hallucinations, policy violations या performance regressions।
• Human review, correction, escalation और rework की लागत।
• Data residency, observability, egress और vendor lock-in से जुड़ी सीमाएँ।

Snowflake का कहना है कि routing decision के लिए अलग से शुल्क नहीं लिया जाता और billing token consumption पर आधारित रहती है। फिर भी escalation और retries कुल token उपयोग तथा latency बढ़ा सकते हैं। इसलिए सही acceptance criterion यह है कि routing application की quality और governance requirements बनाए रखते हुए स्वीकृत, सफलतापूर्वक पूरे किए गए outcome की लागत घटाती है या नहीं।

निष्कर्ष

Snowflake की घोषणा में दो समानांतर बदलाव हैं: approved models के बीच dynamic selection और Cortex AI में उपलब्ध models का विस्तार। Dynamic Model Routing जल्द private preview में आने की उम्मीद है। DeepSeek-V4-Flash 0731 के लिए private preview की घोषणा हो चुकी है, जबकि GLM-5.3 बाद में availability के आधार पर आएगा।

इस पहल का सबसे मजबूत strategic angle केवल यह नहीं है कि आसान requests को सस्ते models तक भेजा जाएगा। असली दावा यह है कि model selection को Snowflake के governed data और security boundary के भीतर रखा जा सकता है। कंपनी का 3 गुना token-efficiency परिणाम आकर्षक है, लेकिन ग्राहकों को अपने workloads पर स्वतंत्र परीक्षण करना चाहिए और सफलता का आकलन token reduction से नहीं, बल्कि end-to-end cost, quality, latency, reliability और human correction के आधार पर करना चाहिए।