Show HN: Echo — open weight models के साथ Fable-स्तर के नतीजे एक-तिहाई लागत पर हासिल

 (news.ycombinator.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Echo GLM-5.2, Kimi K2.7 जैसे कई open weight models को हर request के हिसाब से मिलाकर इस्तेमाल करता है, ताकि हर काम के लिए एक ही model पर निर्भर रहने की सीमाओं को पूरा किया जा सके
  • हर request के लिए compute की मात्रा और भाग लेने वाले models तय किए जाते हैं, और नतीजों को जोड़ने का तरीका भी समायोजित किया जाता है, ताकि सरल prompts पर कम inference resources इस्तेमाल हों
  • शुरुआती evaluation setup में इसने pool के सबसे अच्छे individual model को लगातार पीछे छोड़ा, और Fable जैसा समग्र परिणाम लगभग एक-तिहाई inference cost पर हासिल किया
  • कुल मिलाकर अपेक्षाकृत कमजोर models भी कुछ खास समस्याओं या combinations में उपयोगी साबित होते हैं क्योंकि उनकी क्षमताएँ एक-दूसरे की पूरक हैं, लेकिन allocation और combination को गलत तय करने वाले मामले अभी भी मौजूद हैं
  • chat interface और OpenAI-compatible API जारी किए गए हैं, और यह भी परखा जा रहा है कि यही approach coding और agent tasks में भी असरदार है या नहीं, जहाँ quality को मापना और कठिन है

मॉडल चयन और परिणाम संयोजन

  • शुरुआती experiments में GLM-5.2, Kimi K2.7 आदि को एक ही evaluation में चलाया गया, और यह मानकर नतीजे मापे गए कि हर समस्या के लिए उपयोगी model और सही output combination method पहले से पता है
    • इस काल्पनिक system ने pool में शामिल किसी भी individual model से कहीं बेहतर performance दी
    • अच्छे फैसले केवल result देखने के बाद ही पहचाने जा सकते हैं, इसलिए इसे वास्तविक deployment में इस्तेमाल नहीं किया जा सकता; Echo बिना पूर्व जानकारी के भी उस लाभ का कुछ हिस्सा वापस पाने की कोशिश है
  • request की प्रकृति के अनुसार जरूरी compute, शामिल models और result combination method चुने जाते हैं
    • सरल prompts के लिए अपेक्षाकृत कम inference आवंटित किया जाता है
    • दूसरी समस्याओं में कई models को अलग-अलग हिस्से संभालने के लिए व्यवस्थित किया जाता है
  • models की क्षमताएँ एक-दूसरे की पूरक हैं, इसलिए कुल performance में स्पष्ट रूप से कमजोर model भी कुछ खास समस्याओं या combinations में बहुत उपयोगी हो सकता है

मूल्यांकन परिणाम और सार्वजनिक परीक्षण

  • पहले evaluation setup में इसने सबसे अच्छे individual model से लगातार बेहतर performance दर्ज की, और तुलना के लिए इस्तेमाल किए गए Fable के लगभग समान समग्र परिणाम लगभग एक-तिहाई लागत पर हासिल किए
  • कुछ requests में यह compute allocation या model combination गलत तय करता है, और फिलहाल ऐसे failure cases का विश्लेषण किया जा रहा है
  • coding और agent tasks में हर फैसले की quality मापना कहीं अधिक कठिन है, इसलिए यह अलग से परखा जा रहा है कि वही approach वहाँ भी बनी रहती है या नहीं
  • बाहरी परीक्षण के लिए Echo chat interface और OpenAI-compatible API उपलब्ध कराए गए हैं
  • यह कैसे काम करता है, इसका परिचय वीडियो और evaluation methodology, individual model results, cost, और वर्तमान सीमाएँ सार्वजनिक किए गए हैं, और असामान्य failures या सहज न लगने वाले resource allocation मामलों पर feedback माँगा गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • पहले Message Echo इनपुट बॉक्स दिखाना, जिससे लगता है कि जवाब मिल सकता है, और फिर signup पेज पर भेज देना एक क्लासिक dark pattern है
    साइट द्वारा प्रेरित पहली ही कार्रवाई में अटक गया, इसलिए तुरंत चला गया और दोबारा नहीं आऊंगा

    • मुझे भी बिल्कुल ऐसा ही लगा, और मुझे ऐसे dark patterns इतने नापसंद हैं कि अब इस product में मेरी कोई दिलचस्पी नहीं रही
    • इसे अभी हटाया जा रहा है
    • दूसरी ओर, login से पहले requests की अनुमति देने पर creator को शुरुआती queries का खर्च उठाना पड़ता है, और abuse से बड़ा bill भी आ सकता है
      AI product बनाने वाले के नज़रिए से यह समझ में आने वाला चुनाव भी है

  • Echo इस्तेमाल करने और feedback देने वाले सभी लोगों का धन्यवाद; इसी वजह से इसे जल्दी launch किया गया
    और कठिन coding व agent benchmarks सहित, मौजूदा state-of-the-art से अंतर को ज्यादा सटीक दिखाने वाले evaluations जारी करते रहेंगे, और public evaluation dashboard को भी expand करेंगे। evaluation dashboard UI और signup flow में मिली समस्याएं production environment में ठीक कर दी गई हैं
    Echo आज़माने के लिए credit card की जरूरत नहीं है, और हर account को API और chat में इस्तेमाल करने के लिए $10 free credits मिलते हैं
    साधारण model routing से आगे बढ़कर, open-weight models के बीच inference resources को efficiently allocate करने के तरीके explore किए जा रहे हैं। सिर्फ कौन-सा model इस्तेमाल करना है यह नहीं, बल्कि request पर कितनी computation लगानी है और intermediate results को कैसे combine करना है, यह भी तय किया जाता है
    ensemble अपने आप में random forests से पहले से जाना जाता है, लेकिन Echo का core यह है कि हर request पर पूरे ensemble की cost चुकाए बिना इसे model और उपयोग किया जाए। Fusion या Fugu से conceptually कुछ समानता हो सकती है, लेकिन architecture और optimization goals अलग हैं

    • छोटा feedback: create password special characters मांगता है, लेकिन Google password manager के default generated password में special characters नहीं होते
      दो अंकों की लंबाई वाला alphanumeric combination काफी लगता है, हालांकि idea खुद शानदार है
    • समझ नहीं आया कि dark pattern क्यों इस्तेमाल किया गया। दिलचस्पी थी, लेकिन अब खत्म हो गई
    • signup की सिर्फ एक कोशिश की थी, फिर भी too many authentication attempts error आया
    • dark pattern हटाना चाहिए
    • लगातार open weights पर जोर दिया जा रहा है, लेकिन कौन-से models इस्तेमाल होते हैं यह बिल्कुल disclose नहीं किया गया
      transparency न हो तो end user को open-weight models इस्तेमाल करने का क्या फायदा है, समझ नहीं आता

  • Fable-स्तर के results एक-तिहाई cost पर वाला description, भारी subsidy वाले $200/month plan users के लिए आकर्षक नहीं लगता
    यह plan कब तक रहेगा पता नहीं, लेकिन तब तक public API prices का एक-तिहाई भी खास आकर्षक नहीं है

    • $200/month plan में weekly Fable usage खत्म करने के बाद promotional credits के $200 से medium-size coding plan चलाया, और 1 घंटे 15 मिनट में $120 खर्च हो गए
      कई sub-agents साथ-साथ चल रहे थे और Claude सस्ते models इस्तेमाल करने का निर्देश भूल गया, जिससे कई Fable instances चले, यह भी वजह थी; लेकिन per-token billing संभालना मुश्किल है। $200/month भी महंगा है, लेकिन एक रात में $200 बेतुका है
    • काम के लिए इस्तेमाल करने वाले enterprise customers subsidized plans का उपयोग नहीं कर सकते, इसलिए कुल usage में ऐसे plans का हिस्सा शायद कम ही होगा
    • यह plan IPO तक तो बना रहेगा, लेकिन उसके बाद ज्यादा लंबे समय तक नहीं चलेगा लगता है
      अगर $200/month user $10,000 के API credits इस्तेमाल करे, तो per-user margin -98% होगा, इसलिए profitability में मदद नहीं करेगा
    • अगर उद्देश्य usage limits या सीमा पार करने पर account suspension से बचना है, तो बात अलग है
    • Anthropic से आज मिले email के अनुसार Fable 5 20 जुलाई से usage credit system पर shift हो जाएगा
      इसे इस्तेमाल करते रह सकते हैं, लेकिन pay-as-you-go credits चाहिए होंगे और यह subscription plan की usage limits में शामिल नहीं होगा

  • आने वाले कुछ वर्षों में best model की अवधारणा niche में सिमट जाए तो आश्चर्य नहीं होगा
    ज्यादातर production systems में यह जानने वाला orchestrator विजेता हो सकता है कि कब सस्ता model इस्तेमाल करना है, कब powerful model पर switch करना है, और कब कई outputs को combine करना है

    • सोच रहा हूं, क्या Gemini CLI का idea यही नहीं है?
    • विकसित होने की दिशाएं बहुत हैं, लेकिन आखिरकार best model के niche concept बनने की दिशा में convergence होगी लगता है
      बड़ा trend on-device models है, और यह भी संभव है कि model chip die में चला जाए और हर कुछ वर्षों में chipset बदलने जैसा model हो। ऐसे माहौल में बड़े cloud providers को नुकसान होगा

  • सबसे दिलचस्प निष्कर्षों में से एक यह है कि model size से ज्यादा model selection महत्वपूर्ण हो सकता है
    industry बड़े models पर focus करती रही है, लेकिन requests को सही specialist models के combination में intelligently route करने से कहीं कम cost पर ज्यादा बड़ा improvement मिल सकता है
    कमजोर models बेकार नहीं हुए हैं; वे अलग-अलग क्षेत्रों में अच्छे हैं, और दूसरे models के साथ combine करने पर उनकी value काफी बढ़ सकती है। हालांकि यह coding और agent tasks में भी लागू होगा या नहीं, जहां सही model selection कहीं ज्यादा मुश्किल है, यह जानने की उत्सुकता है

    • हर task में expertise रखने वाले और कम correlation वाले छोटे models को strong ensemble करने से बहुत दिलचस्प results मिल सकते हैं
      agent और coding tasks granularity के कारण ज्यादा complex हैं। यह तय करना होता है कि हर model को कब, कैसे, और session/goal/task/conversation turn/tool call में से किस abstraction layer पर इस्तेमाल करना है; इस पर अभी active research चल रही है

  • वास्तव में कुछ user experience flaws मिले
    Thinking लगातार दिखता रहता है, जिससे लगता है कि अटक गया है या network problem है, और prompt input वाला left panel expand या resize नहीं किया जा सकता। code generate करने को कहने पर output बार-बार कट जाता है और फिर शुरुआत से शुरू हो जाता है, जिससे पिछली conversation continue नहीं हो पाती

  • अगर समस्या की complexity पहले से पता नहीं हो और यह guarantee न हो कि आगे की conversation उसी model को भेजी जाएगी, तो यह तरीका अच्छी तरह काम नहीं करता
    वही conversation कई models को round robin में भेजने से cache टूट जाता है, इसलिए यह cache-aware system की तुलना में उल्टा ज्यादा महंगा पड़ सकता है

    • Ralph Wiggum technique इस्तेमाल की जा सकती है: https://ghuntley.com/ralph/
    • cache hit को भी strategy में शामिल करना चाहिए

  • Anthropic Opus 4.8 और Fable 5 को कुछ समय तक इस्तेमाल किया और नए OpenAI models भी आज़माए, लेकिन सभी ज़रूरत से ज़्यादा अनावश्यक output पैदा करते हैं
    कीमत नहीं, बल्कि quality की वजह से दूसरे models आज़माने शुरू किए, और मेरे काम के क्षेत्र में GLM 5.2 हर मामले में Fable 5 से कहीं बेहतर रहा। उल्टा, जब वह किसी task को सफलतापूर्वक पूरा नहीं कर पाता तो हैरानी होती है
    Kimi K2.7 को थोड़े और निर्देशों की ज़रूरत पड़ती है, लेकिन Opus 4.8 से बेहतर user experience देता है, और K3 अभी इस्तेमाल नहीं किया है। नए OpenAI models की software design और implementation क्षमता बेहद खराब है
    यह आकलन सिर्फ मेरे काम के क्षेत्र तक सीमित है, जिसमें data analysis, machine learning और software engineering बहुत ज़्यादा शामिल हैं

  • न benchmark हैं, न इस्तेमाल किए गए models की जानकारी, बस AI-generated video और signup page है
    “monolith को microservices में बदलकर हर outage को murder mystery जैसा बना दिया” वाली architecture joke याद आती है

    • public evaluator https://echo.tracerml.ai/eval/ पर है
      फिलहाल 7 benchmark families में सेव की गई 907 rows public हैं, और prompts, outputs, evaluations, cost records देखे जा सकते हैं; आगे और जोड़े जाएंगे
      per-request routing policy खुद product है, इसलिए उसे public नहीं करेंगे, लेकिन per-request secret उजागर किए बिना इस्तेमाल किए जा सकने वाले open-weight models की list का कुछ हिस्सा, version dates, overall allocation ratios और evaluation settings public कर सकते हैं। नया video भी बनाया जा रहा है
    • benchmarks https://echo.tracerml.ai/eval/ पर हैं
      ये अच्छे benchmarks नहीं हैं, लेकिन कम से कम मौजूद तो हैं
    • मूल रूप से यह OpenRouter को दोबारा बनाने की कोशिश लगता है। OpenRouter failover, usage metering, automatic switching आदि के जरिए किसी specific provider को abstract करता है, और यह काफी अच्छी तरह काम करने वाला smart infrastructure abstraction है
      यह वास्तविक समस्या हल करने से ज़्यादा investors से यह कहने की कोशिश जैसा लगता है कि “OpenRouter unicorn बन गया, इसलिए मैं भी vibe coding से वैसा ही कुछ बना सकता हूँ,” जो निराशाजनक है
      इसे Fable-level कहना भी बौद्धिक रूप से आलसी या बेईमान लगता है
    • tenderlove की पंक्ति “microservices function calls को distributed computing problem में बदल देती हैं” याद आती है
    • मेरी समझ में login से protected apps Show HN पर allowed नहीं हैं

  • सोच रहा हूँ कि क्या यह Ask Jeeves, AltaVista, Lycos के results को इकट्ठा करने वाले Dogpile.com को फिर से बनाने जैसा है। लगता है समय चक्रीय है

    • अच्छी ideas आम तौर पर era और tools बदलने के बावजूद अच्छी ही रहती हैं
    • ensemble models ने Kaggle में भी हमेशा सबसे अच्छा performance दिया है
      हमने भी वही तरीका implement किया है: https://trustedrouter.com/blog/prometheus-2-new-draco-state-...
    • यह service के हर काम के लिए वही EC2 instance size इस्तेमाल न करने वाला approach है
    • आप triangular wheel भी बना सकते हैं, लेकिन wheels गोल होने की वजह होती है
    • इसे Mixture of Models कहा जा सकता है
      OpenRouter, JusCode, Fireworks जैसे दूसरे AI gateway products भी हाल में इसी तरह का configuration recommend कर रहे हैं, इसलिए इसमें कुछ उपयोगी बात होने की संभावना काफी है