एक क्लाइंट ने मुझे गुरुवार को सुबह 8 बजे फोन किया। उनका AI-चालित दस्तावेज़ सारांशकर्ता मध्यरात्रि के बाद से 503 त्रुटि दे रहा था क्योंकि OpenAI के gpt-4o एंडपॉइंट पर आंशिक विफलता हुई थी। वे £40,000 प्रति माह की SaaS कॉन्ट्रैक्ट पर थे और उनका एंटरप्राइज ग्राहक चिल्ला रहा था। मेरे दिमाग में एक ही सवाल था: किसी ने इसमें Anthropic को फॉलबैक के रूप में करने के लिए रिट्राई क्यों नहीं बनाया?
वह आठ महीने पहले की बात है। Vercel AI Gateway वह सबसे क्लोज़ चीज़ है जो मैंने उस सटीक समस्या का तैयार समाधान देखी है। लेकिन "सबसे क़रीबी चीज़" उस वाक्य में काफी मेहनत कर रही है। मैं आपको बताता हूँ कि यह वास्तव में क्या करता है, संख्याएँ कैसी दिखती हैं, और आपको कहाँ अभी भी संदेह होना चाहिए।
---
Vercel AI Gateway वास्तव में क्या है
अधिकतर लोग नाम देखते हैं और मानते हैं कि यह कुछ अच्छी लॉगिंग वाला प्रॉक्सी है। यह उससे थोड़ा अधिक है, लेकिन मार्केटिंग कॉपी का मतलब जितना नहीं है।
अपने मूल में, Vercel AI Gateway आपके एप्लिकेशन कोड और कई LLM प्रोवाइडर्स के बीच बैठता है: OpenAI, Anthropic, Mistral, Google Gemini, और अन्य। आप गेटवे एंडपॉइंट को एक एकल अनुरोध भेजते हैं। गेटवे तय करता है कि कौन सा मॉडल/प्रोवाइडर कॉल करना है, रिट्राई को संभालता है, सिमांटिक रिस्पांस को कैश करता है, और परिणाम देता है। आप चार API डैशबोर्ड के बजाय एक बिल लाइन आइटम पाते हैं।
SDK इंटीग्रेशन वास्तव में टिड़ा है। अगर आप पहले से ही Vercel AI SDK का उपयोग कर रहे हैं, तो आप अपने प्रोवाइडर इंपोर्ट को गेटवे क्लाइंट से स्वैप करते हैं और एक प्रोवाइडर्स कॉन्फ़िग पास करते हैं। मौजूदा प्रोजेक्ट पर शायद पंद्रह मिनट का काम।
यह अपने आप में कोई जादुई लागत कम करने वाला नहीं है। बचत तीन विशिष्ट व्यवहारों से आती है: लागत के आधार पर राउटिंग, दोहराए गए प्रॉम्प्ट को कैश करना, और प्रोवाइडर विफलताओं के बाद कोल्ड रीस्टार्ट से बचना। यदि आप इन तीनों में से कम से कम एक से मूल्य नहीं पा रहे हैं, तो गेटवे बिना लाभ के ओवरहेड जोड़ता है।
---
राउटिंग लॉजिक कैसे काम करता है
प्रोवाइडर प्राथमिकता और भारित राउटिंग
आप प्रोवाइडर्स की एक सूची को प्राथमिकता क्रम के साथ या भार वितरण के साथ कॉन्फ़िगर करते हैं। प्राथमिकता राउटिंग सरल है: प्रोवाइडर A को आज़माएँ, और यदि यह 429 या 5xx देता है, तो प्रोवाइडर B पर गिरें। भारित राउटिंग प्रतिशत के आधार पर ट्रैफ़िक को विभाजित करता है, इसलिए आप कह सकते हैं "70% OpenAI, 30% Mistral" और पूर्ण माइग्रेशन के बिना वास्तविक ट्रैफ़िक में लागत अंतर का परीक्षण करें।
मैंने एक सामग्री-जनन उपकरण पर भारित राउटिंग का उपयोग किया जो Seahawk ने पिछली तिमाही में एक मीडिया कंपनी के लिए बनाया था। हमने gpt-4o-mini को 60% पर mistral-medium के विरुद्ध 40% पर एक महीने के लिए चलाया। उस समय Mistral प्रति मिलियन टोकन लगभग 34% सस्ता आया, लेकिन संरचित JSON निष्कर्षण के लिए आउटपुट गुणवत्ता में काफी कमजोरी थी। हम OpenAI के पक्ष में 80/20 पर पहुँचे। मुद्दा यह है: गेटवे ने उस A/B परीक्षण को सहज बना दिया। इसके बिना हम दो अलग-अलग SDK क्लाइंट्स को वायर करते और एप्लिकेशन लॉजिक में स्प्लिट को संभालते।
फेलओवर व्यवहार
फेलओवर हेडलाइन फीचर है और यह ज्यादातर विज्ञापन के अनुसार काम करता है। जब OpenAI 5xx देता है, गेटवे अगले कॉन्फ़िगर्ड प्रोवाइडर पर मेरी परीक्षा में लगभग 800ms के भीतर रिट्राई करता है। स्ट्रीमिंग रिस्पांस के लिए यह थोड़ा गड़बड़ है: स्ट्रीम फॉलबैक प्रोवाइडर से चुपचाप रीस्टार्ट हो सकता है, और यदि आप क्लाइंट साइड पर स्ट्रीम को सही तरीके से हैंडल नहीं कर रहे हैं तो आप एक डुप्लिकेट ओपनिंग चंक पा सकते हैं। यह हमें एक बार परेशान किया।
एक बात जानने योग्य है: गेटवे सिमांटिक फेलओवर नहीं करता। यह नहीं जानता कि आपका Anthropic claude-3-5-sonnet रिस्पांस शब्दों को OpenAI के समकक्ष से अलग तरीके से कह सकता है। आप प्रोवाइडर्स में प्रॉम्प्ट संगतता के लिए जिम्मेदार हैं। अधिकांश चैट-शैली इंटरफेस के लिए यह ठीक है। कठोर स्कीमा वाले संरचित आउटपुट के लिए, लाइव जाने से पहले अपनी फेलओवर चेन में प्रत्येक प्रोवाइडर की स्वतंत्र रूप से परीक्षा करें।
---
कैशिंग लेयर: जहाँ असली पैसा है
यह वह हिस्सा है जिसे अधिकतर लोग कम आंकते हैं। Vercel AI Gateway सिमांटिक कैशिंग को शामिल करता है, केवल सटीक-मेल कैशिंग नहीं।
सटीक-मेल कैशिंग दांव पर लगा हुआ है: यदि वही प्रॉम्प्ट स्ट्रिंग गेटवे को दो बार मारती है, तो कैश किया गया रिस्पांस देता है। सिमांटिक कैशिंग आगे जाता है। एम्बेडिंग समानता का उपयोग करके, यह पहचानता है कि "इस पैराग्राफ को तीन वाक्यों में सारांशित करें" और "इस पैराग्राफ का तीन-वाक्य सारांश दें" एक ही अनुरोध हैं और कैश किए गए परिणाम को सेव करता है।
दस्तावेज़ सारांशकार परियोजना के लिए (जिसने मेरे क्लाइंट को लगभग दिल का दौरा दिला दिया), हमने 0.92 कोसाइन समानता थ्रेशोल्ड के साथ सिमेंटिक कैशिंग सक्षम करने के बाद कैश हिट रेट को मापा। दो सप्ताह की प्रोडक्शन ट्रैफ़िक में: 41% कैश हिट रेट। GPT-4o पर 1K आउटपुट टोकन के लिए £0.015 पर, यह दैनिक 2 मिलियन आउटपुट टोकन में मामूली नहीं है।
नैपकिन के गणित को स्वयं करें:
- 2,000,000 आउटपुट टोकन/दिन
- 41% कैश से परोसे गए = 820,000 टोकन बिल नहीं किए गए
- £0.015/1K पर यह प्रति दिन £12.30 बचत है
- एक महीने में: मोटे तौर पर £370
बड़े एंटरप्राइज़ के लिए जीवन परिवर्तनकारी नहीं। इंडी SaaS ऑपरेटर के लिए मार्जिन देख रहे हैं यह महत्वपूर्ण है। और यह एक परियोजना है, एक महीना है।
OpenAI प्रॉम्प्ट कैशिंग फ़ीचर अब नेटिव रूप से प्रीफ़िक्स कैशिंग को संभालता है, इसलिए लंबे सिस्टम प्रॉम्प्ट के लिए आप पहले से ही इसका कुछ हिस्सा मुफ्त में प्राप्त कर रहे हैं। Vercel का सिमेंटिक कैश इसके अतिरिक्त है, उपयोगकर्ता-टर्न सामग्री में भिन्नता को संभालता है।
---
Observability: Better Than Nothing, Not Good Enough Alone
गेटवे के माध्यम से प्रत्येक अनुरोध लॉग किया जाता है: लेटेंसी, टोकन काउंट, प्रदाता का उपयोग किया गया, कैश हिट/मिस, लागत का अनुमान। आप इसे Vercel डैशबोर्ड में देखते हैं। यह साफ और पठनीय है।
यहाँ बात यह है। यदि आप एक गंभीर प्रोडक्शन सिस्टम चला रहे हैं, तो आपके पास पहले से ही Datadog, Grafana, या न्यूनतम LangSmith जैसा कुछ है आपकी ट्रेस पाइपलाइन में। Vercel डैशबोर्ड आपको गेटवे-स्तरीय दृश्यता देता है। यह आपकी पूर्ण एप्लिकेशन में स्पैन-स्तरीय ट्रेस नहीं देता। आप यह नहीं देख सकते कि एक विशेष उपयोगकर्ता का अनुरोध 4.2 सेकंड में क्यों लगा क्योंकि उनके 3.1 सेकंड आपके retrieval स्टेप में बिताए गए थे LLM को बुलाए जाने से पहले भी।
इसलिए मैं गेटवे की built-in observability को पहले फ़िल्टर मानता हूँ: समस्या LLM कॉल स्तर पर है या कहीं और? गहरे किसी भी चीज़ के लिए, मैं अभी भी एक उचित ट्रेसिंग टूल में export करता हूँ।
जानने योग्य एक विशिष्ट संख्या: गेटवे EU-region डिप्लॉयमेंट पर मेरे मापन से प्रति अनुरोध औसतन लगभग 15-30ms लेटेंसी जोड़ता है। real-time voice या sub-100ms UX आवश्यकताओं के लिए, यह मायने रखता है। async दस्तावेज़ प्रोसेसिंग के लिए, यह नहीं करता।
---
इसे वास्तव में चलाने की लागत क्या है
Vercel AI Gateway Pro plan में शामिल है (लिखने के समय £17/month) और उच्चतर। Vercel से कोई per-request surcharge नहीं है। आप अभी भी अंतर्निहित प्रदाता की टोकन लागत सीधे देते हैं।
छिपी हुई लागत परिचालनात्मक है: आप अब अपने inference पथ में Vercel को निर्भरता के रूप में जोड़ रहे हैं। यदि Vercel के edge नेटवर्क में समस्या है, तो आपके LLM कॉल विफल होते हैं चाहे OpenAI पूरी तरह स्वस्थ हो। मैंने यह पिछले छह महीनों में एक बार देखा है, EU-West region में Vercel के edge पर ~12 मिनट का आंशिक outage। अधिकांश apps के लिए यह स्वीकार्य है। SLA commitments के साथ कुछ भी जो nines में मापा जाता है: इसे ध्यान में रखें।
डेटा residency का प्रश्न भी है। आपके prompts और completions Vercel के infrastructure के माध्यम से जाते हैं। अधिकांश consumer apps के लिए: irrelevant। Healthcare, finance, या कुछ भी GDPR-sensitive personal data को अर्थपूर्ण तरीके से छूना: गेटवे के माध्यम से कुछ भी pipe करने से पहले data processing agreement को ध्यान से पढ़ें। मुझे दो fintech clients को गेटवे को पूरी तरह छोड़ने के लिए कहना पड़ा है और इसके बजाय in-application routing को संभालना है।
---
इसे कब उपयोग करें और कब छोड़ें
मैं इसके बारे में सीधा कहूँ क्योंकि AI tooling के चारों ओर developer marketing अक्सर oversell करता है।
Vercel AI Gateway का उपयोग करें यदि:
- आप पहले से ही Vercel पर हैं और AI SDK का उपयोग कर रहे हैं (शून्य अतिरिक्त friction)
- आपके पास multi-provider strategy है और retry logic लिखे बिना failover चाहते हैं
- आपकी app में caching के लिए भुगतान करने के लिए पर्याप्त repeated या semantically similar prompts हैं
- आप separate provider billing integrations सेट अप किए बिना cost dashboard चाहते हैं
इसे छोड़ दें या सावधानी से सोचें अगर:
- आपके पास कड़ी डेटा रेसिडेंसी आवश्यकताएं हैं (GDPR, HIPAA)
- आपको 50ms से कम कुल inference latency की जरूरत है और हर hop मायने रखता है
- आप Vercel के अलावा किसी अन्य infrastructure पर चल रहे हैं और उनके edge को जोड़ना इससे ज्यादा complexity का परिचय देता है कि यह समस्या का समाधान करता है
- आपके prompt की विविधता बहुत अधिक है और semantic cache hit rate लगभग शून्य होगी
2022 में हमने City of London की एक फर्म के लिए self-hosted stack पर एक कानूनी दस्तावेज़ विश्लेषण टूल बनाया था। भले ही Vercel AI Gateway उस समय मौजूद होता, यह तुरंत मेज़ से हट जाता। Prompts में विशेषाधिकार प्राप्त क्लाइंट जानकारी थी और फर्म की IT compliance टीम कभी भी किसी तीसरे पक्ष के proxy को मंजूरी नहीं देती। हमने लगभग चार घंटे की मेहनत में अपना provider abstraction layer बनाया। इसने एक सरल priority queue के साथ दो providers में failover को संभाला। शानदार नहीं। बिल्कुल पर्याप्त।
---
व्यावहारिक सेटअप (संक्षिप्त संस्करण)
अगर आप तय कर चुके हैं कि यह आपके प्रोजेक्ट के लिए सही है, तो यह वह क्रम है जिसका मैं पालन करता हूँ:
- अपने Vercel प्रोजेक्ट सेटिंग्स में "AI" टैब के अंतर्गत gateway सक्षम करें
aiऔर@ai-sdk/openai(और अन्य सभी provider packages जिन्हें आपको चाहिए) को नवीनतम संस्करण में install या update करें@vercel/ai-gatewayसे gateway client के साथ direct provider client instantiation को replace करें (सटीक import path के लिए official docs देखें क्योंकि यह पहले ही एक बार बदल चुका है)- अपने gateway config object में priority order में provider list को define करें
- अपना semantic cache similarity threshold निर्धारित करें: मैं 0.90 से शुरू करता हूँ और एक सप्ताह के traffic के बाद देखे गए hit rates के आधार पर समायोजन करता हूँ
- एक staging environment में ship करें और deliberately provider failures को trigger करें ताकि failover chain आपकी अपेक्षा के अनुसार काम करे
- पहले दो हफ्तों के लिए cache hit rate और latency p95 को monitor करें, फिर निष्कर्ष निकालें
बस। सच में जटिल नहीं।
---
FAQ
क्या Vercel AI Gateway streaming responses को सपोर्ट करता है?
जी, streaming gateway के माध्यम से काम करता है। एक gotcha है failover mid-stream: अगर primary provider streaming response के दौरान गिरता है, तो gateway अगले provider पर retry करेगा, लेकिन stream restart होगी। इस बात पर निर्भर करता है कि आपका client-side UI partial content को कैसे handle करता है, यह एक visible flicker या एक duplicated first sentence का कारण बन सकता है। Ship करने से पहले अपने UI में इसे explicitly test करें।
क्या मैं Vercel AI Gateway को Vercel AI SDK के बिना use कर सकता हूँ?
तकनीकी रूप से आप HTTP के माध्यम से directly gateway endpoint को hit कर सकते हैं, लेकिन SDK integration वह जगह है जहां यह ergonomic बन जाता है। SDK के बिना आप gateway URL के चारों ओर अपने fetch wrappers लिख रहे हैं, streaming को manually manage कर रहे हैं, और retries को manually handle कर रहे हैं। उस बिंदु पर आप भी अपना प्रदाता abstraction बना सकते हैं। Gateway की value SDK के साथ तंग रूप से जुड़ी हुई है व्यावहारिक रूप से।
क्या semantic caching sensitive या personalised data को handle करता है?
यह automatically नहीं करता। अगर आप ऐसे prompts भेज रहे हैं जिनमें user-specific data शामिल है (नाम, account numbers, session context), तो cache semantically similar prompts को match करने का प्रयास करेगा भले ही वह डेटा users के बीच अलग हो। यह personalised workflows में incorrect cache hits का कारण बन सकता है। आप या तो उन routes के लिए semantic caching को disable कर सकते हैं या एक user-scoped cache key को include कर सकते हैं अगर gateway आपकी plan tier में उसे support करता है।
अगर Vercel के पास कोई outage है तो मेरे requests का क्या होता है?
वे fail हो जाते हैं। Gateway critical path में है। अगर आपको genuine multi-cloud resilience की जरूरत है, तो आपके पास application layer पर एक circuit-breaker होना चाहिए जो gateway को bypass करके directly providers को hit कर सके। मैं किसी भी app में provider SDK clients को initialised रखता हूँ जहां uptime सच में मायने रखता है।
---
ईमानदारी से कहूँ तो: Vercel AI Gateway एक अच्छी तरह से बना हुआ infrastructure है जो Vercel-native AI stack में अपनी जगह रखता है। यह आपकी unit economics को revolutionary तरीके से नहीं बदलेगा, लेकिन सही workload पर 35-40% cache hit rate और automatic failover सब कुछ manually wire करने से बेहतर operational improvement है। बस commit करने से पहले जान लीजिए कि यह क्या नहीं कर सकता। सुबह 8 बजे किसी घबराए हुए client का फोन कॉल — यह पता लगाने का सबसे बुरा तरीका है कि आपकी assumptions कहाँ गलत थीं।
