🤖 AI

LLM-Rosetta: A Hub-and-Spoke Intermediate Representation for Cross-Provider LLM API Translation

LLM-Rosetta एक ओपन-सोर्स, हब-एंड-स्पोक इंटरमीडिएट रिप्रजेंटेशन फ्रेमवर्क है जो प्रमुख LLM API प्रदाताओं के बीच लॉसलेस, द्विदिश अनुवाद को सक्षम बनाता है, जो न्यूनतम ओवरहेड के साथ विविध सिंटैक्टिक प्रारूपों को एक एकीकृत सिमेंटिक कोर में मैप करके $O(N^2)$ एडैप्टर समस्या को प्रभावी ढंग से हल करता है।

मूल लेखक: Peng Ding

प्रकाशित 2026-04-13

📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Peng Ding

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आप एक यात्री हैं जो चार अलग-अलग देशों की यात्रा कर रहे हैं: OpenAI, Anthropic, Google, और OpenAI की नई "Responses" सेवा।

प्रत्येक देश में, स्थानीय लोग एक ही भाषा की थोड़ी अलग बोली बोलते हैं। वे सभी "messages," "tools," और "thinking" के बारे में बात करना चाहते हैं, लेकिन वे अपने वाक्यों को अलग तरह से लिखते हैं।

OpenAI में, आप कह सकते हैं, "यहाँ संदेशों की एक सूची है।"
Anthropic में, आप कह सकते हैं, "यहाँ कंटेंट ब्लॉक्स की एक सूची है।"
Google में, आप कह सकते हैं, "यहाँ बातचीत के भाग हैं।"

यदि आप इन चारों देशों में काम करने वाला एक ट्रैवल ऐप बनाना चाहते हैं, तो वर्तमान में आप एक दुस्वप्न का सामना कर रहे हैं। अपने ऐप को हर जगह काम करने के लिए, आपको देशों के हर एक जोड़े के लिए एक विशिष्ट अनुवादक (translator) बनाना होगा।

OpenAI $\leftrightarrow$ Anthropic
OpenAI $\leftrightarrow$ Google
Anthropic $\leftrightarrow$ Google
...और इसी तरह।

यदि 100 देश हैं, तो आपको हजारों अनुवादक चाहिए होंगे। यह $O(N^2)$ की समस्या है: जैसे-जैसे आप देश जोड़ते हैं, काम विस्फोटक रूप से बढ़ता जाता है।

LLM-Rosetta: एक सार्वभौमिक "हब" (Universal Hub)

इस शोध पत्र के लेखकों ने, जिनका नेतृत्व पेंग डिंग (Peng Ding) ने किया, महसूस किया कि विभिन्न बोलियों के बावजूद, वास्तव में सभी एक ही बात कह रहे हैं। वे सभी वास्तव में इनके बारे में बात करते हैं:

कौन बोल रहा है? (System, User, Assistant)
क्या कहा जा रहा है? (Text, Images, Audio)
किन टूल्स का उपयोग किया जा रहा है? (Calculators, Search engines)
हमें कैसे सोचना चाहिए? (Reasoning steps)

उन्होंने LLM-Rosetta बनाया, जो एक सार्वभौमिक मुद्रा विनिमय (universal currency exchange) या एक केंद्रीय रेलवे स्टेशन की तरह कार्य करता है।

प्रत्येक देश के बीच सीधा रास्ता बनाने के बजाय, उन्होंने एक केंद्रीय हब (एक "मध्यवर्ती प्रतिनिधित्व" या Intermediate Representation - IR) बनाया।

द स्पोक (The Spoke): आप अपने विशिष्ट अनुरोध (जैसे, OpenAI से) को लेते हैं और उसे सार्वभौमिक भाषा (The Hub) में एक बार अनुवादित करते हैं।
द हब (The Hub): हब मूल अर्थ को पूरी तरह से समझता है। इसे मूल देश के अजीब फॉर्मेट की परवाह नहीं है।
द स्पोक (The Spoke): हब फिर उस सार्वभौमिक भाषा को गंतव्य देश (जैसे, Google) की विशिष्ट बोली में अनुवादित करता है।

अब, यदि आप एक 5वां देश (जैसे, एक नया AI प्रदाता) जोड़ना चाहते हैं, तो आपको अपने पुराने अनुवादकों को फिर से लिखने की आवश्यकता नहीं है। आपको बस उस देश से हब तक एक नया अनुवादक बनाना होगा। गणित $N^2$ के उलझे हुए विस्फोट से बदलकर एक सरल जोड़ ( $N$ ) में बदल जाता है।

यह कैसे काम करता है ("Ops" किचन)

यह शोध पत्र इन अनुवादकों को बनाने के एक चतुर तरीके का वर्णन करता है जिसे "Ops-Composition" कहा जाता है।

कल्पना कीजिए कि एक किचन है जहाँ आपको चार अलग-अलग संस्कृतियों के लिए भोजन पकाना है। एक शेफ द्वारा एक साथ चार अलग-अलग रेसिपी याद रखने के बजाय, आपके पास चार विशिष्ट स्टेशन हैं:

द कंटेंट स्टेशन (The Content Station): भोजन (टेक्स्ट, इमेज, फाइल्स) को संभालता है।
द मैसेज स्टेशन (The Message Station): भोजन के क्रम (कौन पहले बोलता है) को संभालता है।
द टूल स्टेशन (The Tool Station): बर्तनों/उपकरणों (कैलकुलेटर, कोड) को संभालता है।
द कॉन्फ़िग स्टेशन (The Config Station): तापमान और समय (कितनी तेजी से सोचना है, कितनी रचनात्मकता होनी चाहिए) को संभालता है।

जब आपको OpenAI से Google में अनुवाद करने की आवश्यकता होती है, तो आप बस प्रत्येक स्टेशन पर "OpenAI शेफ" को "Google शेफ" से बदल देते हैं। बाकी किचन वैसा ही रहता है। यह सिस्टम को मॉड्यूलर, सुधारने में आसान और परीक्षण करने में आसान बनाता है।

"लाइव स्ट्रीम" की चुनौती

AI के साथ बात करने का सबसे कठिन हिस्सा यह है कि वह एक साथ जवाब नहीं देता; वह शब्दों को एक-एक करके "स्ट्रीम" करता है, जैसे एक लाइव वीडियो फीड। विभिन्न प्रदाता इस डेटा के "chunks" को अलग-अलग तरीकों से भेजते हैं।

OpenAI एक "start" सिग्नल, फिर "text," और फिर "end" भेज सकता है।
Google अब तक का पूरा वाक्य भेज सकता है, फिर अगला भाग।

LLM-Rosetta एक लाइव सबटाइटल अनुवादक की तरह कार्य करता है। यह आने वाली स्ट्रीम को देखता है, इसे "सार्वभौमिक भाषा" (10 मानक इवेंट प्रकारों) में सामान्य करता है, और फिर इसे उस प्रारूप में री-स्ट्रीम करता है जिसकी गंतव्य अपेक्षा करता है। यह "स्टेट" (state) का ट्रैक रखता है ताकि यदि एक टूल कॉल एक चंक में शुरू होता है और दूसरे में समाप्त होता है, तो अनुवाद भ्रमित न हो।

यह एक बड़ी बात क्यों है?

यह लॉसलेस (Lossless) है: आप OpenAI से हब को एक संदेश भेज सकते हैं और वापस OpenAI को, और यह बिल्कुल वैसा ही दिखेगा जैसा कि पहले था (सूक्ष्म मेटाडेटा विवरणों सहित), ठीक वैसे ही जैसे किसी किताब को फ्रेंच में अनुवाद करना और फिर वापस अंग्रेजी में अनुवाद करना बिना कहानी का एक भी बिंदु खोए।
यह तेज़ है: अनुवाद 100 माइक्रोसेकंड (यानी 0.0001 सेकंड) से भी कम समय में होता है। यह इतना तेज़ है कि यह आपके ऐप को धीमा नहीं करता है।
यह पहले से ही काम कर रहा है: यह केवल सिद्धांत नहीं है। इसका उपयोग वर्तमान में आर्गोन नेशनल लेबोरेटरी (Argonne National Laboratory) में शोधकर्ताओं को उनके कोड को फिर से लिखे बिना विभिन्न AI मॉडल के बीच स्विच करने में मदद करने के लिए किया जा रहा है।

निचोड़

LLM-Rosetta AI के लिए रोसेटा स्टोन है। इसने महसूस किया कि जबकि AI कंपनियां अलग-अलग "बोलियाँ" बोलती हैं, वे सभी एक ही "व्याकरण" साझा करती हैं। एक सार्वभौमिक मध्यस्थ बनाकर, यह डेवलपर्स को एक कंपनी तक सीमित होने से मुक्त करता है। अब आप एक ऐसा ऐप बना सकते हैं जो आज OpenAI से बात करता है, और यदि आप कल Google पर स्विच करना चाहते हैं, तो आप बस एक स्विच फ्लिप कर सकते हैं। आपके ऐप को फिर से बनाने की आवश्यकता नहीं है; इसे बस हब के लिए एक नया अनुवादक चाहिए।

यहाँ शोध पत्र "LLM-ROSETTA: CROSS-PROVIDER LLM API TRANSLATION के लिए एक HUB-AND-SPOKE INTERMEDIATE REPRESENTATION" का विस्तृत तकनीकी सारांश दिया गया है।

1. समस्या विवरण (Problem Statement)

लार्ज लैंग्वेज मॉडल (LLM) पारिस्थितिकी तंत्र अत्यधिक खंडित है, जहाँ प्रमुख प्रदाता (OpenAI, Anthropic, Google, आदि) मालिकाना (proprietary) API प्रारूप प्रस्तुत करते हैं।

$O(N^2)$ एकीकरण का बोझ: $N$ प्रदाताओं को जोड़ने के लिए, एक सरल दृष्टिकोण में $N(N-1)/2$ द्विपक्षीय एडेप्टर (bilateral adapters) की आवश्यकता होती है। जैसे-जैसे प्रदाता अपने API विकसित करते हैं (उदाहरण के लिए, रीजनिंग ट्रेसेस जोड़ना, स्ट्रीमिंग स्कीमा बदलना), इन एडेप्टरों का रखरखाव करना कॉम्बिनेटोरियल रूप से महंगा और नाजुक हो जाता है।
सिंटैक्टिक विचलन बनाम सिमेंटिक कोर (Syntactic Divergence vs. Semantic Core): जबकि API स्कीमा सिंटैक्स (फील्ड नामकरण, नेस्टिंग डेप्थ, कंटेंट एनकोडिंग) में काफी भिन्न होते हैं, यह शोध पत्र देखता है कि वे एक सामान्य सिमेंटिक कोर (संदेश, कंटेंट पार्ट्स, टूल कॉल्स, रीजनिंग, और जनरेशन कंट्रोल्स) साझा करते हैं।
मौजूदा समाधानों की सीमाएँ:
- एप्लीकेशन फ्रेमवर्क्स (जैसे, LangChain): ये एप्लीकेशन स्तर पर एब्स्ट्रैक्शन प्रदान करते हैं लेकिन कच्चे API पेलोड के लिए पुन: प्रयोज्य, फॉर्मेट-स्तर के ट्रांसलेशन लेयर प्रदान नहीं करते हैं।
- SDK रैपर्स (जैसे, LiteLLM): अक्सर सभी प्रदाताओं को एक एकल "लिंगुआ फ्रंका" (आमतौर पर OpenAI Chat Completions) में मैप करते हैं। यह दृष्टिकोण प्रदाता-विशिष्ट विशेषताओं (जैसे, Anthropic का कैश कंट्रोल, Google का ग्राउंडिंग मेटाडेटा) को खो देता है और वास्तविक द्विदिश निष्ठा (bidirectional fidelity) की कमी रखता है।

2. कार्यप्रणाली: LLM-Rosetta आर्किटेक्चर (Methodology: LLM-Rosetta Architecture)

LLM-Rosetta एक Hub-and-Spoke आर्किटेक्चर प्रस्तावित करता है जो प्रदाताओं को अलग करने के लिए एक टाइप किया गया इंटरमीडिएट रिप्रेजेंटेशन (IR) उपयोग करता है, जिससे जटिलता $O(N^2)$ से घटकर $O(N)$ हो जाती है।

A. इंटरमीडिएट रिप्रेजेंटेशन (IR)

IR एक प्रदाता-तटस्थ डेटा मॉडल है जिसे समर्थित API के सिमेंटिक यूनियन को कैप्चर करने के लिए डिज़ाइन किया गया है। इसमें शामिल हैं:

9 कंटेंट पार्ट प्रकार: TextPart, ImagePart, AudioPart, FilePart, ToolCallPart, ToolResultPart, ReasoningPart, RefusalPart, CitationPart|
10 स्ट्रीम इवेंट प्रकार: स्ट्रीमिंग के लिए सामान्यीकृत इवेंट्स (जैसे, stream_start, content_block_start, text_delta, tool_call_delta, finish, usage)|
कोर स्ट्रक्चर्स:
- Messages: रोल-टैग किए गए कंटेनर्स (System, User, Assistant, Tool)|
- Tools: डेफिनिशन और चॉइस कॉन्फ़िगरेशन|
- Config: जनरेशन पैरामीटर्स (temperature, top-p, reasoning budgets)|
- Requests/Responses: पेलोड के लिए मानकीकृत रैपर्स|

B. ऑप्स-कंपोजिशन कन्वर्टर आर्किटेक्चर (Ops-Composition Converter Architecture)

मोनोलिथिक कन्वर्टर्स के बजाय, LLM-Rosetta एक मॉड्यूलर डिज़ाइन का उपयोग करता है जहाँ प्रत्येक प्रदाता एडेप्टर को चार ऑर्थोगोनल Ops मॉड्यूल्स से जोड़ा जाता है:

ContentOps: परमाणु (atomic) कंटेंट रूपांतरण को संभालता है (जैसे, base64 एनकोडिंग, टूल कॉल सीरियलाइजेशन)|
MessageOps: कन्वर्सेशन स्ट्रक्चर, रोल मैपिंग, और सिस्टम प्रॉम्प्ट एक्सट्रैक्शन को संभालता है|
ToolOps: टूल डेफिनिशन और सिलेक्शन लॉजिक को प्रबंधित करता है|
ConfigOps: जनरेशन पैरामीटर्स और कैशिंग सेटिंग्स को मैप करता है|

यह पृथक्करण प्रदाताओं को मॉड्यूल को पुनः उपयोग करने की अनुमति देता है (उदाहरण के लिए, OpenAI Responses, OpenAI Chat के कंटेंट लॉजिक को पुनः उपयोग करता है) और सिंटैक्टिक विचित्रताओं को सिमेंटिक लॉजिक से अलग करता है।

C. स्ट्रीमिंग और स्टेट मैनेजमेंट (Streaming and State Management)

विभिन्न सर्वर-सेंट इवेंट (SSE) स्कीमा के कारण स्ट्रीमिंग एक महत्वपूर्ण चुनौती है। LLM-Rosetta एक स्टेटफुल StreamContext लागू करता है जो:

विसंगत इवेंट स्ट्रीम्स को (जैसे, Anthropic के स्पष्ट ब्लॉक लाइफसाइकिल बनाम OpenAI के निहित डेल्टा) 10 IR इवेंट प्रकारों में सामान्य करता है|
आउट-ऑफ-ऑर्डर इवेंट्स को संभालता है (जैसे, Google द्वारा फाइनल कंटेंट डेल्टा से पहले फिनिश कारणों को उत्सर्जित करना) बफरिंग और रीऑर्डरिंग के माध्यम से|
सब-मिलीसेकंड ओवरहेड के साथ चंक-लेवल ट्रांसलेशन का समर्थन करता है|

D. मेटाडेटा मोड (Metadata Modes)

सिस्टम दो रूपांतरण मोड का समर्थन करता है:

Preserve Mode: प्रदाता-विशिष्ट मेटाडेटा (जैसे, cache_control, thought_signature) को एक provider_metadata फ़ील्ड में बनाए रखता है, जो लॉसलेस राउंड-ट्रिप्स ( $A \to IR \to A$ ) को सक्षम बनाता है|
Strip Mode: क्रॉस-प्रदाता फॉरवर्डिंग ( $A \to IR \to B$ ) के लिए स्वच्छ, प्रदाता-तटस्थ IR बनाने के लिए प्रदाता-विशिष्ट मेटाडेटा को हटा देता है|

3. मुख्य योगदान (Key Contributions)

अनुभवजन्य लक्षण वर्णन (Empirical Characterization): प्रदर्शित किया कि LLM API विचलन मुख्य रूप से सिंटैक्टिक है, जिससे एक कॉम्पैक्ट IR (9 कंटेंट प्रकार, 10 स्ट्रीम प्रकार) को प्रमुख प्रदाताओं का निष्ठापूर्वक प्रतिनिधित्व करने में सक्षम बनाया गया|
द्विदिश अनुवाद (Bidirectional Translation): सिंगल-डायरेक्शनल रैपर्स के विपरीत, LLM-Rosetta अनुरोधों और प्रतिक्रियाओं दोनों के लिए पूर्ण द्विदिश रूपांतरण ( $Provider \leftrightarrow IR \leftrightarrow Provider$ ) का समर्थन करता है|
मॉड्यूलर विस्तारशीलता (Modular Extensibility): ऑप्स-कंपोजिशन पैटर्न नए प्रदाताओं को कोर IR या मौजूदा कन्वर्टर्स को संशोधित किए बिना केवल विशिष्ट ऑप्स मॉड्यूल्स को लागू करके जोड़ने की अनुमति देता है|
प्रोडक्शन परिनियोजन (Production Deployment): इस फ्रेमवर्क को Argonne National Laboratory में ARGO-PROXY गेटवे के लिए ट्रांसलेशन लेयर के रूप में प्रोडक्शन में तैनात किया गया है|

4. मूल्यांकन परिणाम (Evaluation Results)

सिस्टम का मूल्यांकन 1,364 परीक्षणों (Open Responses अनुपालन सूट सहित) और प्रोडक्शन बेंचमार्क का उपयोग करके किया गया।

राउंड-ट्रिप फिडेलिटी: सभी चार समर्थित प्रदाताओं (OpenAI Chat, OpenAI Responses, Anthropic, Google GenAI) में Preserve मोड में लॉसलेस फील्ड-लेवल समानता प्राप्त की|
स्ट्रीमिंग शुद्धता: 100% इवेंट-अनुक्रम सटीकता बनाए रखी, जटिल परिदृश्यों जैसे टूल कॉल संचय और आउट-ऑफ-ऑर्डर प्रदाता इवेंट्स को सही ढंग से संभाला|
क्रॉस-प्रदाता अनुवाद: सभी छह प्रदाता जोड़ों के बीच सिमेंटिक कंटेंट (रोल्स, टूल्स, मल्टी-मोडल डेटा) को सफलतापूर्वक अनुवादित किया। बिना समकक्ष वाले प्रदाता-विशिष्ट सुविधाओं (जैसे, Google में Anthropic कैश कंट्रोल) को चेतावनी के साथ सुरक्षित रूप से हटा दिया गया|
परफॉरमेंस ओवरहेड:
- लेटेंसी: मीडियन कन्वर्जन ओवरहेड < 100 µs है (पेलोड जटिलता के आधार पर 21–77 µs)|
- तुलना: हालांकि जटिल मल्टी-टर्न कन्वर्सेशन के लिए LiteLLM के सिंगल-पास अप्रोच की तुलना में यह थोड़ा धीमा है (2.2x ओवरहेड), फिर भी यह नेटवर्क लेटेंसी (50–500 ms) और मॉडल इन्फरेंस समय की तुलना में नगण्य है। महत्वपूर्ण रूप से, यह वह द्विदिशता और प्रदाता तटस्थता प्रदान करता है जो LiteLLM में नहीं है।

5. महत्व (Significance)

LLM-Rosetta LLM पारिस्थितिकी तंत्र में एक महत्वपूर्ण बुनियादी ढांचे के अंतर को संबोधित करता है। API अनुवाद को एक सिंटैक्टिक समस्या के बजाय एक सिमेंटिक मैपिंग समस्या के रूप में मानकर, यह सक्षम बनाता है:

पोर्टेबिलिटी: एप्लिकेशन बिना ग्लू कोड को फिर से लिखे प्रदाताओं को बदल सकते हैं या ब्रिज कर सकते हैं|
इंटरऑपरेबिलिटी: गेटवे और फ्रेमवर्क को असंगत API के बीच ट्रैफ़िक को पारदर्शी रूप से रूट करने में सक्षम बनाता है|
भविष्य के लिए तैयारी (Future-Proofing): मॉड्यूलर डिज़ाइन यह सुनिश्चित करता है कि जैसे-जैसे LLM API विकसित होते हैं (जैसे, नए कंटेंट प्रकार या रीजनिंग फीचर्स), सिस्टम पूर्ण पुनर्लेखन के बिना क्रमिक रूप से अनुकूलित हो सके|

शोध पत्र निष्कर्ष निकालता है कि जबकि API विविधताओं की "कॉम्बिनेटोरियल सतह" जटिल है, साझा सिमेंटिक कोर एक हब-एंड-स्पोक IR को एक व्यवहार्य और कुशल समाधान बनाता है।