हमने LLM लागतों को नियंत्रित करने के लिए एक डैशबोर्ड बनाया — और इसने हमारी अभ्यास-प्रणाली बदल दी
हर योग कक्षा में एक ऐसा क्षण आता है जब कोई छात्र किसी आसन को जबरन करने की कोशिश छोड़ देता है और बस ध्यान देता है कि शरीर क्या कर रहा है। कूल्हा कसा हुआ है। साँस उथली है। कंधा भरपाई कर रहा है। यह जागरूकता का क्षण — निष्पक्ष, सटीक — वही जगह है जहाँ परिवर्तन शुरू होता है। ज़ोर लगाने में नहीं। ध्यान देने में।
हमने AI Model Pricing Dashboard बिल्कुल इसी कारण बनाया। इसलिए नहीं कि हम Large Language Models पर अधिक खर्च करना चाहते थे, बल्कि इसलिए कि हम ईमानदारी और सटीकता से यह बता ही नहीं सकते थे कि हम पहले से कितना खर्च कर रहे हैं। टीम में किसी को पता नहीं था। बिल आते थे, और कोई भी सरल सवाल का जवाब नहीं दे पाता था: हम वास्तव में किन मॉडलों का उपयोग कर रहे हैं, और प्रति प्रदाता लागत कितनी है?
अंदर की गड़बड़
अगर आपने कई प्रदाताओं के साथ AI workloads चलाए हैं, तो आप इस परेशानी को जानते होंगे। OpenRouter एक दर पर प्रति-टोकन शुल्क लेता है। OpenAI इनपुट और आउटपुट टोकनों को अलग-अलग कीमतों पर अलग करता है। Anthropic की अपनी संरचना है। Kilo AI Gateway subscription plans पर overage गणना के साथ काम करता है। हर प्रदाता टोकनों की गणना अलग तरीके से करता है। हर प्रदाता अपनी pricing sheet को बिना किसी release note के बदल देता है।
यह कुछ-कुछ वैसा है जैसे पाँच अलग-अलग भाषाओं में लिखी पाँच अलग-अलग किताबें पढ़कर योग का अभ्यास करना, जिनमें से कोई भी इस बात पर सहमत नहीं है कि "Downward Dog" का मतलब क्या है। आप किसी तरह काम चला सकते हैं। लेकिन आप भरपाई करेंगे। और भरपाई की एक लागत होती है — infrastructure पक्ष पर पैसे में, और mat पर alignment में।
डैशबोर्ड क्या करता है
AI Model Pricing Dashboard एक open-source tool है — BSD 3-Clause, MIT-friendly — जिसे FastAPI backend और Next.js frontend के साथ बनाया गया है। यह 10+ LLM providers में pricing को एकत्र करता है, हर चीज़ को dollars per million tokens में normalize करता है, और आपको एक एकल, filterable, sortable table देता है जो तुलना को आसान बना देता है।
लेकिन असली मूल्य table में नहीं है। असली मूल्य वह है जो table उजागर करता है:
Input बनाम output token गणना। अधिकांश टीमें "per-call cost" के रूप में सोचती हैं। लेकिन आधुनिक LLM उपयोग का बड़ा हिस्सा output tokens — यानी model की प्रतिक्रियाएँ — होता है। जो model $2 प्रति million input tokens और $15 प्रति million output tokens लेता है, उसका cost profile उस model से पूरी तरह अलग है जो क्रमशः $5 और $6 लेता है। डैशबोर्ड इसे तुरंत दृश्य बना देता है।
Context window का संदर्भ। 128K context window वाला model 4K window वाले model की तुलना में प्रति-token अधिक महंगा लग सकता है। लेकिन यदि लंबे prompts को संभालने के लिए आप अभी सस्ते model पर कई calls chain कर रहे हैं, तो बड़े context window वाला महँगा model वास्तव में सस्ता पड़ता है — और बेहतर परिणाम देता है।
Trend tracking. कीमतें बदलती हैं। डैशबोर्ड 30-दिन का price history सहेजता है। इसका मतलब है कि provider की price moves आपको आपके अगले invoice से पहले दिखाई देती हैं।
Kilo plan projection. यदि आप Kilo AI Gateway के user हैं, तो डैशबोर्ड वास्तविक usage को हर tier के मुकाबले map करता है और बताता है कि overages सहित आपकी कुल लागत को कौन-सा plan न्यूनतम करता है।
नीचे की architecture
सिस्टम Postgres और Redis पर चलता है, और production deployment के लिए Kubernetes manifests का उपयोग करता है। FastAPI backend 900-second Redis cache के साथ pricing aggregation संभालता है — real-time dashboard उपयोग के लिए तेज़, provider APIs पर पर्याप्त कोमल। CronJobs हर 15 मिनट में pricing refresh करते हैं और 9 AM UTC पर daily email reports भेजते हैं।
Local development के लिए, पूरा stack docker-compose.yml के साथ — Postgres, Redis, API, और Next.js frontend — दो मिनट से कम समय में चालू हो जाता है।
हमने Kubernetes इसलिए नहीं चुना कि dashboard को भारी scale चाहिए, बल्कि इसलिए कि deployment pattern boring होना चाहिए। Ingress के लिए Traefik, TLS के लिए cert-manager, और API तथा web replicas के लिए horizontal pod autoscaling। Boring भरोसेमंद होता है। और जब यह tool बजट संबंधी निर्णयों को सूचित कर रहा हो, तब भरोसेमंद वही है जिसकी आपको जरूरत होती है।
जहाँ योग और डैशबोर्ड मिलते हैं
यह वह हिस्सा है जो कोई architecture blog आपको नहीं बताएगा: cost optimization और योग पहला कदम साझा करते हैं।
योग में हम कहते हैं जागरूकता परिवर्तन से पहले आती है। यदि आपको पता ही नहीं कि कूल्हा गलत संरेखित है, तो आप उसे ठीक नहीं कर सकते। यदि आपने कभी यह देखा ही नहीं कि जबड़ा लगातार कसा हुआ है, तो आप उसे नरम नहीं कर सकते। ध्यान देना ही अभ्यास है। ध्यान देना ही वह जगह है जहाँ agency शुरू होती है।
डैशबोर्ड इसलिए मौजूद है क्योंकि हमने ध्यान दिया। पहली बार, हमारे पास इस बात की सटीक, ईमानदार तस्वीर थी कि हमारे AI workloads वास्तव में कितने महंगे हैं — कोई अनुमान नहीं, कोई धुंधली-सी अनुभूति नहीं कि "यह महँगा लग रहा है," बल्कि एक संख्या। और जब आपके पास संख्या होती है, आप निर्णय ले सकते हैं। क्या हम इस workload के लिए प्रदाता बदलें? क्या गैर-आवश्यक कार्यों के लिए सस्ता model उपयोग करें? क्या caching अधिक आक्रामक तरीके से करें? क्या बड़े context window वाला model चुनकर call chaining हटाएँ?
इनमें से कोई भी निर्णय पहले दिखाई नहीं देता था। इसलिए नहीं कि data मौजूद नहीं था, बल्कि इसलिए कि वह पाँच provider dashboards, तीन billing pages, और एक spreadsheet में बिखरा हुआ था जिसे कोई update नहीं करता था।
हमने scraper बनाया। हमने normalizer बनाया। हमने dashboard बनाया। और जिस पहले सप्ताह हमने इसे इस्तेमाल किया, उसमें हमें $40/month की एक inefficiency मिली जो चार महीनों से चल रही थी। इसका मतलब है कि हमने $160 इसलिए खर्च कर दिए क्योंकि हम देख नहीं रहे थे। Dashboard को सेट अप करने में एक शाम से भी कम लागत आई।
डेटा से हम क्या सीख रहे हैं
Dashboard लागू करने के बाद, हमारे काम करने के तरीके में तीन चीज़ें बदली हैं:
कार्य के अनुसार rightsizing। अब हम वास्तविक cost-per-task के आधार पर विशिष्ट tasks को विशिष्ट models सौंपते हैं, brand preference के आधार पर नहीं। बार-बार दोहराए जाने वाले, कम-जटिलता वाले कार्य सस्ते, तेज़ models को दिए जाते हैं। जटिल reasoning tasks वहाँ जाते हैं जहाँ quality कीमत को उचित ठहराती है। यह कोई नया विचार नहीं है — यह उसी सिद्धांत जैसा है जैसे उस दिन आपके शरीर को वास्तव में जो चाहिए, उसके आधार पर restorative practice या power flow चुनना।
Pranayama के रूप में caching। योग में pranayama (साँस नियंत्रण) हर साँस को महत्वपूर्ण बनाने का अभ्यास है — कम मात्रा, अधिक मंशा, बेहतर oxygen exchange। LLM responses को cache करना वही अवधारणा है। यदि वही prompt वही output देता है, तो आप उसे store करते हैं। आप एक ही computation के लिए दो बार भुगतान नहीं करते। Dashboard की 900-second TTL वाली Redis cache ने हमारे repeat-token खर्च को लगभग 30% कम किया है। कम साँसें, अधिक प्राप्ति।
Trend awareness। 30 दिनों में pricing trends को track करने से हमें provider price drops उनके बारे में blog posts देखने से पहले दिख जाते हैं। जब कोई provider अपनी दर 20% घटाता है, तो हमें एक घंटे के भीतर पता चल जाता है। जब कोई provider rates बढ़ाता है, तो हम अगले billing cycle से पहले पुनर्मूल्यांकन कर सकते हैं। जागरूकता। Agency। निर्णय।
Open source, क्योंकि उपकरणों को जमा करना खराब योग है
यह project GitHub पर BSD 3-Clause licensed है: github.com/andreab67/ai-models-pricing। Kubernetes manifests शामिल हैं। API documentation FUNCTIONAL.md में है। SBOM — हर dependency, उसका license, उसकी security notes — SBOM.md में है।
हमने इसे open-source इसलिए किया क्योंकि यह समस्या केवल हमारी नहीं है। Multi-provider AI workloads चलाने वाली हर टीम को यह समस्या है। और उपयोगी tools को जमा करके रखना, योग की उपमा लें तो, ऐसा है जैसे किसी छात्र को वह आसन सिखाने से इनकार करना जो उसकी मदद कर सकता हो। साझा करने से अभ्यास कम नहीं होता। वह गहराता है।
इस सप्ताह के लिए एक कदम
यदि आपकी टीम LLM workloads चलाती है और आप तुरंत यह उत्तर नहीं दे सकते कि "हम प्रति task प्रति provider कितना खर्च कर रहे हैं" — तो आप भरपाई कर रहे हैं। बुरी तरह नहीं। बस महँगे तरीके से।
Dashboard को स्थानीय रूप से सेट अप करें। Docker के साथ इसमें दो मिनट लगते हैं। इसे चलाएँ। संख्याएँ देखें। संख्याओं को आपको कुछ ऐसा बताने दें जो आपने नहीं देखा था।
फिर निर्णय लें।
यही वही अभ्यास है जो हम mat पर करते हैं: पहुँचो, ध्यान दो, चुनो। उपकरण बदलते हैं। सिद्धांत नहीं बदलता।
AI Model Pricing Dashboard open source है: github.com/andreab67/ai-models-pricing। production instance हमारे Kubernetes cluster पर चलता है। यदि आप इसे deploy करने या अपने cost-alerting pipeline के साथ integrate करने में मदद चाहते हैं, संपर्क करें.