Stanford STORM को एक custom OpenAI-compatible endpoint पर चलाएं।

Quick answer: openai_kwargs में api_base, ids पर openai/ prefix।

STORM का LitellmModel जो भी kwargs से आप इसे construct करें उन्हें store करता है और उन्हें हर litellm.completion() call में merge करता है। litellm का api_base parameter openai provider को एक अलग host पर point करने का तरीका है, तो STORM के अपने examples पहले से इस्तेमाल करने वाले openai_kwargs dict में api_base add करना ही पूरा override है। हर model id को openai/ से prefix करें ताकि litellm उस base से chat-completions protocol बोले, और slash के बाद वाली string gateway को pass through होती है। चूंकि examples एक openai_kwargs dict बनाते हैं और उसे हर model के लिए reuse करते हैं, एक add की गई key पूरी pipeline को reroute करती है। कोई STORM code changes नहीं, कोई fork नहीं; यह litellm की documented routing के ऊपर layered stock knowledge_storm behavior है।

openai_kwargs = {
    "api_key": os.getenv("APISROUTER_API_KEY"),
    "api_base": "https://api.apisrouter.com/v1",
    "temperature": 1.0,
    "top_p": 0.9,
}
fast = LitellmModel(model="openai/deepseek-v4-flash", max_tokens=500, **openai_kwargs)
strong = LitellmModel(model="openai/claude-sonnet-4-6", max_tokens=3000, **openai_kwargs)

STORM एक article को पांच LM slots में कैसे split करता है।

STORM (GitHub पर stanford-oval, लगभग 30K stars) scratch से Wikipedia-style reports लिखता है: यह simulated multi-perspective conversations के through एक topic research करता है, इससे सीखी गई चीज़ों से एक outline बनाता है, section by section पूरा article generate करता है, और फिर उसे polish करता है। STORMWikiLMConfigs उस pipeline को पांच independently settable models के तौर पर expose करता है: conv_simulator_lm और question_asker_lm research conversations drive करते हैं, outline_gen_lm article को structure करता है, article_gen_lm इसे लिखता है, और article_polish_lm final pass करता है। Upstream README economics के बारे में explicit है: conversation simulator सबसे ज़्यादा call volume चलाता है, तो यह वहां एक faster model और article generation के लिए एक ज़्यादा powerful model recommend करता है। वह guidance OpenAI models में choose करने को assume करती थी; एक multi-vendor endpoint के पीछे यह कुछ ज़्यादा useful में generalize हो जाती है। हर slot अपना model string रखने वाला अपना LitellmModel है, तो research chatter एक fast DeepSeek id पर चल सकता है जबकि outline और article generation Claude पर चलते हैं, और polish जिस भी model पर tone के लिए भरोसा हो उस पर, सब same key से same api_base के against authenticated। Retrieval side अलग machinery है: STORM का runner अपनी API key वाला एक RM module (You.com, Bing, और कई दूसरे search backends) लेता है। Language models कहां point करते हैं यह बदलना यह नहीं छूता कि sources कैसे fetch होते हैं।

पूरा setup: पांच slots, एक kwargs dict।

Working pattern repo के अपने run scripts को mirror करता है: shared kwargs एक बार बनाएं, per role एक LitellmModel construct करें, और उन्हें STORMWikiLMConfigs setters के through assign करें। api_key कोई भी नाम हो सकता है क्योंकि आप इसे explicitly pass करते हैं; example अपना variable इस्तेमाल करता है ताकि clear हो जाए कि यह कोई OpenAI account credential नहीं है। litellm provider-level environment variables को भी मानता है, और openai provider OPENAI_API_BASE पढ़ता है, तो एक environment-only override possible है। Explicit kwargs path फिर भी prefer करने वाला रहता है: यह उस code में visible है जिसने एक दिया गया article produce किया, यह अलग environment state वाली machine पर चलने से बचा रहता है, और अगर आप कभी एक stage को अलग endpoint पर चाहें तो यह per-slot exceptions possible बनाता है।

import os
from knowledge_storm import STORMWikiRunnerArguments, STORMWikiRunner, STORMWikiLMConfigs
from knowledge_storm.lm import LitellmModel
from knowledge_storm.rm import YouRM

openai_kwargs = {
    "api_key": os.getenv("APISROUTER_API_KEY"),
    "api_base": "https://api.apisrouter.com/v1",
    "temperature": 1.0,
    "top_p": 0.9,
}
fast = LitellmModel(model="openai/deepseek-v4-flash", max_tokens=500, **openai_kwargs)
strong = LitellmModel(model="openai/claude-sonnet-4-6", max_tokens=3000, **openai_kwargs)

lm_configs = STORMWikiLMConfigs()
lm_configs.set_conv_simulator_lm(fast)
lm_configs.set_question_asker_lm(fast)
lm_configs.set_outline_gen_lm(strong)
lm_configs.set_article_gen_lm(strong)
lm_configs.set_article_polish_lm(strong)

engine_args = STORMWikiRunnerArguments(output_dir="./results")
rm = YouRM(ydc_api_key=os.getenv("YDC_API_KEY"), k=engine_args.search_top_k)
runner = STORMWikiRunner(engine_args, lm_configs, rm)
runner.run(topic="Small modular reactors")

Per pipeline stage models चुनना।

पांच setters को boilerplate नहीं, एक budget dial मानें। Upstream guidance पहले से stages के across fast और strong models split करने को कहती है; एक multi-vendor endpoint बस per stage menu widen करता है। Same topic पर runs के बीच एक बार में एक slot बदलें और outputs diff करें, per-key usage log हर configuration की price करते हुए।

• conv_simulator_lm और question_asker_lm volume stages हैं: per topic कई perspectives के across multi-turn simulated interviews। deepseek-v4-flash या कोई और fast id research phase को spend पर हावी होने से रोकती है, और imperfect chatter tolerable है क्योंकि यह prose नहीं, notes feed करता है।
• article_gen_lm flagship slot है। यह accumulated research से लंबे, structured, cited sections लिखता है, जो sustained-generation work है जहां claude-sonnet-4-6 या gpt-5.5 छोटी ids से visibly बेहतर perform करते हैं।
• outline_gen_lm कम calls वाला outsized leverage है, एक planning slot जैसी same shape: एक weak outline article को cap कर देती है चाहे writer कितना भी अच्छा हो। यह claude-opus-4-7 test करने की natural जगह है।
• article_polish_lm assembled article में flow के लिए rewrite करता है और duplication हटाता है, जिसे एक long-context id से फायदा मिलता है; यहां gemini-3.1-pro-preview benchmark करने लायक है।

जितना उपयोग उतना भुगतान · आधिकारिक मूल्य से कम

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

STORM के लिए failure modes।

एक bare model id आपके api_base से नहीं, inference से route होती है। litellm एक provider चुनने के लिए prefix पढ़ता है, और एक prefixless Claude id एक Anthropic-native call के तौर पर infer हो जाती है, जो फिर ANTHROPIC_API_KEY मांगती है और आपके gateway को पूरी तरह ignore करती है। Gateway की तरफ जाने वाली हर id को openai/ prefix carry करना चाहिए; prefix protocol बताता है, vendor नहीं। एक slot पीछे छूट गया। हर LitellmModel construction पर अपने kwargs capture करता है। अगर चार slots openai_kwargs share करते हैं और पांचवां बिना api_base के ad hoc बनाया गया, वह slot चुपचाप vendor default को post करता है और auth पर fail होता है, और traceback एक config line की बजाय एक pipeline stage का नाम लेता है। हर slot को same dict से बनाएं और यह class of bug गायब हो जाता है। Endpoint पर blame की गई retriever failures। Research phase को एक काम करने वाला search backend चाहिए; एक invalid या exhausted retriever key (YDC_API_KEY, BING_SEARCH_API_KEY, या जो भी RM आपने चुना) information gathering के दौरान runs fail करती है। वह phase LM calls के साथ interleave होती है, तो LM config छूने से पहले traceback पढ़ें किस client ने raise किया। Demo का secrets.toml आपके script का config नहीं है। Streamlit demo secrets.toml पढ़ता है; programmatic runs आपका script जो भी pass करे वह पढ़ते हैं। एक को edit करते हुए दूसरा चलाना एक classic mismatch है। max_tokens भी per-slot है। STORM के examples fast slots (500) पर छोटे limits और generation (3000) पर बड़े set करते हैं। एक long-form model वाले slot को इसका max_tokens raise किए बिना point करना चुपचाप sections truncate करता है, जो एक model quality problem जैसा दिखता है लेकिन एक config number है।

कौन STORM को एक gateway के through route करता है।

• Teams जो volume पर knowledge reports (briefs, wiki-style internal docs, topic primers) generate करती हैं, जहां five-slot split per-stage cost tuning को असली पैसे का बना देता है।
• Researchers जो pipeline composition study करते हैं: कौन-सा stage एक stronger model से फायदा उठाता है यह एक empirical question है, और एक endpoint slot-model combinations की grid को enumerate करना trivial बना देता है।
• Builders जो एक OpenAI-shaped stack की writing slots में Claude या Gemini चलाते हैं, per model family एक vendor SDK add किए बिना।
• कोई भी जो batch topic lists चलाता है, जहां research-phase volume topics के across multiply होता है और usage log per-topic cost ledger बन जाता है।
• Developers जिनके पास किसी given vendor की billing तक access नहीं है। बिना card requirement वाला top-up based access per-provider sign-up dependency हटा देता है।

Endpoint verify करें और पहले article को debug करें।

पहले gateway के models list करें: हर slot में openai/ के बाद वाली string एक served id से exactly match होनी चाहिए। First-run failures pipeline order follow करती हैं। Anthropic या Google का नाम लेने वाली एक auth error मतलब एक prefixless id एक native provider पर route हुई; openai/ add करें। Gateway से एक 401 मतलब आपके kwargs में api_key gateway key नहीं है। एक model-not-found error उस slot का नाम लेता है जिसकी id में typo है। Research phase के दौरान failures जो आपके search backend को mention करें retriever credentials हैं, LM routing नहीं। और truncated या अजीब तरीके से छोटे article sections आमतौर पर upstream किसी चीज़ की बजाय generation slot पर एक कंजूस max_tokens है। एक पूरी STORM run एक बड़ा burst है: perspectives के across simulated conversations, फिर outline, generation, और polish। एक बार complete होने पर, APIsRouter console per-request model, token counts, और spend दिखाता है, जो cleanly पांच slots पर map होता है और आपको बताता है कि topics के अगले batch से पहले exactly कौन-सा stage retune करना है।

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

अक्सर पूछे जाने वाले प्रश्न