Stanford STORM کو ایک custom OpenAI-compatible endpoint پر چلائیں۔

فوری جواب: openai_kwargs میں api_base، ids پر openai/ prefix۔

STORM کا LitellmModel آپ کے دیے گئے kwargs کو محفوظ رکھتا ہے اور انہیں litellm.completion() کی ہر call میں merge کرتا ہے۔ litellm کا api_base parameter openai provider کو ایک مختلف host پر point کرنے کا طریقہ ہے، تو STORM کے اپنے examples پہلے سے استعمال کرنے والے openai_kwargs dict میں api_base شامل کرنا ہی پوری override ہے۔ ہر model id کے آگے openai/ prefix لگائیں تاکہ litellm اس base سے chat-completions protocol بولے، اور slash کے بعد آنے والا string gateway تک pass ہو جاتا ہے۔ چونکہ examples ایک openai_kwargs dict بناتے ہیں اور اسے ہر model کے لیے دوبارہ استعمال کرتے ہیں، ایک شامل کی گئی key پوری pipeline کو reroute کر دیتی ہے۔ کوئی STORM code تبدیلی نہیں، کوئی fork نہیں؛ یہ stock knowledge_storm رویہ ہے جو litellm کے documented routing پر تہہ در تہہ بیٹھا ہے۔

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 میں کیسے تقسیم کرتا ہے۔

STORM (GitHub پر stanford-oval، تقریباً 30K stars) شروع سے Wikipedia-style رپورٹس لکھتا ہے: یہ simulated multi-perspective conversations کے ذریعے کسی topic پر تحقیق کرتا ہے، جو سیکھا اس سے ایک outline بناتا ہے، پورا article سیکشن بہ سیکشن generate کرتا ہے، اور پھر اسے polish کرتا ہے۔ STORMWikiLMConfigs اس pipeline کو پانچ خودمختار طور پر settable models کے طور پر expose کرتا ہے: conv_simulator_lm اور question_asker_lm research conversations چلاتے ہیں، outline_gen_lm article کو structure دیتا ہے، article_gen_lm اسے لکھتا ہے، اور article_polish_lm آخری pass کرتا ہے۔ Upstream README economics کے بارے میں واضح ہے: conversation simulator سب سے زیادہ call volume چلاتا ہے، تو یہ وہاں ایک تیز model اور article generation کے لیے ایک زیادہ طاقتور model تجویز کرتا ہے۔ یہ guidance OpenAI models میں سے چننے کو فرض کرتی تھی؛ ایک multi-vendor endpoint کے پیچھے یہ کچھ زیادہ مفید چیز میں عام ہو جاتی ہے۔ ہر slot اپنا الگ LitellmModel ہے جس کا اپنا model string ہے، تو research chatter ایک تیز DeepSeek id پر چل سکتا ہے جبکہ outline اور article generation Claude پر چلیں، اور polish جس بھی model پر آپ tone کے لیے بھروسہ کریں، سب ایک ہی key سے authenticate ہوتے ہوئے ایک ہی api_base کے خلاف۔ Retrieval side الگ machinery ہے: STORM کا runner ایک RM module لیتا ہے (You.com، Bing، اور کئی دیگر search backends) اپنی الگ API key کے ساتھ۔ Language models کہاں point کرتے ہیں یہ بدلنا اس بات کو نہیں چھوتا کہ sources کیسے fetch ہوتے ہیں۔

مکمل سیٹ اپ: پانچ slots، ایک kwargs dict۔

working pattern repo کی اپنی run scripts کی نقل کرتا ہے: shared kwargs ایک بار بنائیں، فی role ایک LitellmModel بنائیں، اور انہیں STORMWikiLMConfigs setters کے ذریعے assign کریں۔ api_key کوئی بھی نام ہو سکتا ہے کیونکہ آپ اسے صراحتاً pass کرتے ہیں؛ example اپنا الگ variable استعمال کرتا ہے تاکہ واضح ہو کہ یہ کوئی OpenAI account credential نہیں۔ litellm provider-level environment variables کو بھی مانتا ہے، اور openai provider OPENAI_API_BASE پڑھتا ہے، تو ایک environment-only override ممکن ہے۔ صریح kwargs راستہ اب بھی ترجیح کے قابل ہے: یہ اس code میں نظر آتا ہے جس نے ایک مخصوص article پیدا کیا، یہ مختلف environment state والی مشین پر چلنے سے بچ جاتا ہے، اور اگر آپ کبھی چاہیں تو فی-slot استثنا ممکن بناتا ہے۔

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")

فی pipeline stage models چننا۔

پانچوں setters کو boilerplate نہیں بلکہ ایک budget dial سمجھیں۔ Upstream guidance پہلے ہی fast اور strong models کو stages میں تقسیم کرنے کو کہتی ہے؛ ایک multi-vendor endpoint فی stage صرف menu وسیع کر دیتا ہے۔ ایک ہی topic پر runs کے درمیان ایک وقت میں ایک slot بدلیں اور outputs کا diff کریں، per-key usage log ہر configuration کی قیمت لگاتے ہوئے۔

• conv_simulator_lm اور question_asker_lm volume stages ہیں: فی topic کئی نقطہ نظر پر multi-turn simulated interviews۔ deepseek-v4-flash یا کوئی دوسری تیز id research phase کو spend پر حاوی ہونے سے روکتی ہے، اور ناقص chatter قابلِ برداشت ہے کیونکہ یہ notes کھلاتا ہے، prose نہیں۔
• article_gen_lm flagship slot ہے۔ یہ جمع شدہ research سے لمبے، structured، cited sections لکھتا ہے، جو sustained-generation کام ہے جہاں claude-sonnet-4-6 یا gpt-5.5 چھوٹی ids سے واضح طور پر بہتر کارکردگی دکھاتی ہیں۔
• outline_gen_lm چند calls مگر بڑا اثر رکھتا ہے، ایک planning slot جیسی shape: ایک کمزور outline article کو محدود کر دیتا ہے چاہے writer کتنا ہی اچھا ہو۔ یہ claude-opus-4-7 ٹیسٹ کرنے کی فطری جگہ ہے۔
• article_polish_lm جمع کیے گئے article میں flow کے لیے دوبارہ لکھتا ہے اور 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 پڑھتا ہے، اور ایک prefix کے بغیر Claude id ایک Anthropic-native call کے طور پر infer ہوتی ہے، جو پھر ANTHROPIC_API_KEY مانگتی ہے اور آپ کے gateway کو مکمل طور پر نظر انداز کر دیتی ہے۔ gateway کی طرف جانے والی ہر id کو openai/ prefix لے جانا چاہیے؛ prefix protocol کا نام لیتا ہے، vendor کا نہیں۔ پیچھے رہ جانے والا ایک slot۔ ہر LitellmModel construction پر اپنے kwargs capture کرتا ہے۔ اگر چار slots openai_kwargs share کریں اور پانچواں ad hoc بنایا گیا ہو بغیر api_base کے، تو وہ slot خاموشی سے vendor default پر post کرتا ہے اور auth پر فیل ہوتا ہے، اور traceback ایک config line کی بجائے ایک pipeline stage کا نام لیتا ہے۔ ہر slot کو ایک ہی dict سے بنائیں اور یہ bug class ختم ہو جاتی ہے۔ Endpoint کو الزام دی گئی retriever failures۔ Research phase کو ایک کام کرنے والا search backend چاہیے؛ ایک invalid یا ختم شدہ retriever key (YDC_API_KEY، BING_SEARCH_API_KEY، یا آپ کا منتخب کردہ کوئی بھی RM) information gathering کے دوران runs کو فیل کرتی ہے۔ وہ 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 بھی فی-slot ہے۔ STORM کے examples تیز slots (500) پر چھوٹی limits اور generation (3000) پر بڑی سیٹ کرتے ہیں۔ کسی slot کو ایک long-form model پر point کرنا بغیر اس کا max_tokens بڑھائے خاموشی سے sections کو truncate کر دیتا ہے، جو model quality کا مسئلہ لگتا ہے مگر ایک config number ہے۔

STORM کو gateway کے ذریعے کون route کرتا ہے۔

• وہ teams جو volume پر knowledge reports پیدا کرتی ہیں (briefs، wiki-style internal docs، topic primers)، جہاں five-slot split فی-stage cost tuning کو حقیقی پیسے کے قابل بناتا ہے۔
• وہ researchers جو pipeline composition کا مطالعہ کرتے ہیں: کون سا stage ایک مضبوط model سے فائدہ اٹھاتا ہے یہ ایک empirical سوال ہے، اور ایک endpoint slot-model combinations کے grid کو enumerate کرنا آسان بنا دیتا ہے۔
• وہ builders جو ایک OpenAI-shaped stack کی writing slots میں Claude یا Gemini چلاتے ہیں، فی model family ایک vendor SDK شامل کیے بغیر۔
• وہ لوگ جو batch topic lists چلاتے ہیں، جہاں research-phase volume topics کے پار ضرب کھاتا ہے اور usage log فی-topic cost ledger بن جاتا ہے۔
• وہ developers جن کے پاس کسی مخصوص vendor کی billing تک رسائی نہیں۔ Top-up پر مبنی رسائی بغیر کارڈ کی شرط کے فی-provider sign-up کا انحصار ختم کر دیتی ہے۔

Endpoint verify کریں اور پہلا article debug کریں۔

پہلے gateway کی models list کریں: ہر slot میں openai/ کے بعد آنے والا string ایک serve کی گئی id سے بالکل میچ ہونا چاہیے۔ پہلی-run کی failures pipeline کی ترتیب کی پیروی کرتی ہیں۔ Anthropic یا Google کا نام لینے والا ایک auth error مطلب ایک prefix کے بغیر id ایک native provider کی طرف route ہوئی؛ openai/ شامل کریں۔ Gateway سے ایک 401 مطلب آپ کے kwargs میں api_key gateway key نہیں ہے۔ ایک model-not-found error اس slot کا نام لیتی ہے جس کی id میں typo ہے۔ Research phase کے دوران failures جو آپ کے search backend کا ذکر کریں وہ retriever credentials ہیں، LM routing نہیں۔ اور truncated یا عجیب طور پر مختصر article sections عموماً generation slot پر کنجوس max_tokens ہیں، upstream کی کوئی چیز نہیں۔ ایک مکمل STORM run ایک بڑا burst ہے: مختلف نقطہ نظر پر simulated conversations، پھر outline، generation، اور polish۔ ایک بار مکمل ہونے پر، APIsRouter console per-request model، token counts، اور spend دکھاتا ہے، جو صاف طور پر پانچوں slots پر map ہوتا ہے اور بتاتا ہے کہ topics کے اگلے batch سے پہلے کون سا stage دوبارہ tune کرنا ہے۔

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

عمومی سوالات