BibiGPT کی video summaries کو ایک custom OpenAI-compatible API پر چلائیں۔

فوری جواب: تین environment variables۔

BibiGPT کی example environment file اس surface کو براہ راست document کرتی ہے: OPENAI_COMPATIBLE_BASE_URL endpoint سیٹ کرتا ہے (default https://api.openai.com/v1)، OPENAI_COMPATIBLE_API_KEY key رکھتا ہے (unset ہونے پر OPENAI_API_KEY پر fallback کرتا ہے)، اور OPENAI_COMPATIBLE_MODEL summaries کے لیے default model چنتا ہے۔ base URL کو https://api.apisrouter.com/v1 پر سیٹ کریں، key variable میں gateway key ڈالیں، اور model کے طور پر کوئی بھی کیٹلاگ id چنیں۔ base URL استعمال کے وقت validate ہوتا ہے: اسے http:// یا https:// سے شروع ہونا چاہیے، اور trailing slashes ہٹا دیے جاتے ہیں، تو اوپر والی /v1 form بالکل درست ہے۔ اندر ہی اندر app ان values سے ایک Vercel AI SDK openai-compatible provider بناتا ہے اور configured id کے ساتھ chatModel کو call کرتا ہے، یہی وجہ ہے کہ endpoint جو بھی model serve کرے وہ بغیر code تبدیلی کے کام کرتا ہے۔

# Optional: use OpenAI-compatible providers (falls back to OPENAI_API_KEY)
OPENAI_COMPATIBLE_API_KEY=sk-YOUR-APISROUTER-KEY
OPENAI_COMPATIBLE_BASE_URL=https://api.apisrouter.com/v1
OPENAI_COMPATIBLE_MODEL=deepseek-v4-flash

BibiGPT endpoint کو کیا بھیجتا ہے۔

BibiGPT (GitHub پر JimmyLv، open-source v1 کے لیے تقریباً 6K stars) audio اور video کے لیے ایک one-click AI summarizer ہے: ایک Bilibili یا YouTube link، ایک podcast، ایک meeting recording، یا local file paste کریں، اور یہ transcript fetch کرتا ہے، اسے condense کرتا ہے، اور آپ کو content کے ساتھ chat کرنے دیتا ہے۔ یہ Bilibili summaries کے لیے BiliGPT کے طور پر شروع ہوا اور ایک hosted successor کے ساتھ ایک bilingual tool میں تبدیل ہو گیا؛ یہاں بیان کردہ environment configuration self-hosted open-source version پر لاگو ہوتی ہے۔ workload transcript کی شکل کا ہے: لمبے inputs، مختصر outputs۔ ایک گھنٹے کی speech ایک بڑا transcript ہوتا ہے، جسے app summarize کرنے سے پہلے model-sized ٹکڑوں میں chunk کرتا ہے، تو ایک video کا مطلب کئی chat-completions calls ہو سکتا ہے جن کے input tokens اس summary سے کہیں بڑے ہوتے ہیں جو وہ پیدا کرتے ہیں۔ per-input-token price اس لیے پوری economics ہے، اور long-context models لمبے lectures اور podcasts کے لیے chunking کم کرتے ہیں۔ provider construction values کو ایک عقلمندانہ cascade میں resolve کرتا ہے: ایک per-request key (ان instances کے لیے جو users کو اپنی key لانے دیتی ہیں) OPENAI_COMPATIBLE_API_KEY پر جیتتی ہے، جو OPENAI_API_KEY پر جیتتی ہے؛ یہی base URL اور model پر بھی لاگو ہوتا ہے۔ ایک OPENAI_COMPATIBLE_KEY_PREFIXES variable بھی موجود ہے جو ان user-entered keys کو قبول کرنے کے لیے ہے جن کا prefix sk- نہیں ہوتا، جو اس وقت اہم ہے جب آپ کے users کی keys OpenAI کی بجائے کسی gateway سے آتی ہوں۔

Self-hosted instance کے لیے مکمل سیٹ اپ۔

BibiGPT ایک Next.js app ہے، تو environment ویسے ہی سفر کرتا ہے جیسے آپ deploy کریں: local طور پر ایک .env file، Vercel پر project environment variables، یا Docker میں container env۔ تینوں variables سیٹ کریں، redeploy یا restart کریں، اور summaries gateway کے ذریعے route ہوتی ہیں۔ model variable default ہے، سخت حد نہیں۔ Requests ایک per-video config لے کر چلتی ہیں جس کا model field، جب موجود ہو، OPENAI_COMPATIBLE_MODEL کو override کرتا ہے، تو ایک instance ایک volume id پر default ہو سکتا ہے جبکہ مخصوص flows ایک زیادہ طاقتور id مانگیں۔ اگر آپ دوسروں کے لیے instance چلاتے ہیں اور انہیں اپنی keys paste کرنے دیتے ہیں، تو OPENAI_COMPATIBLE_KEY_PREFIXES کو اپنے gateway کی key prefix شامل کرنے کے لیے سیٹ کریں تاکہ form انہیں قبول کرے۔

OPENAI_COMPATIBLE_API_KEY=sk-YOUR-APISROUTER-KEY
OPENAI_COMPATIBLE_BASE_URL=https://api.apisrouter.com/v1
OPENAI_COMPATIBLE_MODEL=deepseek-v4-flash

# accepting user-entered gateway keys in the UI:
OPENAI_COMPATIBLE_KEY_PREFIXES=sk-

ایک summarization model چننا، East اور West دونوں کے لیے۔

یہ موازنہ ایمانداری سے چلانا آسان ہے: ایک ہی video، دو model ids، دونوں summaries کو transcript کے خلاف پڑھیں۔ per-key usage log ہر candidate کی قیمت حقیقی content پر لگاتا ہے، اور transcript workloads کے لیے فرق فوری طور پر input-token column میں نظر آتا ہے۔

• Chinese content BibiGPT کا home turf ہے: Bilibili lectures، Douyin clips، Chinese podcasts۔ glm-5.2، deepseek-v4-flash، اور kimi-k2.6 Chinese transcripts پر native طور پر strong ہیں اور باقی سب کی طرح اسی endpoint کے پیچھے بیٹھتے ہیں۔
• English اور mixed content (YouTube، global podcasts) claude-haiku-4-5-20251001 اور gemini-3.5-flash پر اچھی کارکردگی دکھاتا ہے، دونوں لمبے noisy transcripts کے ساتھ آرام دہ ہیں۔
• یہ تقسیم gateway کے لیے عملی China-plus-global دلیل ہے: ایک endpoint، ایک key، اور per-video model override ہر content source کے لیے صحیح family چنتا ہے بجائے اس کے کہ دونوں کے لیے ایک vendor مسلط کیا جائے۔
• لمبے lectures long context کا صلہ دیتے ہیں۔ کم chunks کا مطلب کم calls اور ایک زیادہ مربوط summary ہے؛ standardize کرنے سے پہلے اپنے سب سے لمبے content کے خلاف ایک long-context id ٹیسٹ کریں۔
• Volume instances (ایک team جو ہر وہ چیز summarize کرتی ہے جو وہ دیکھتی ہے) کو deepseek-v4-flash پر default ہونا چاہیے اور selectively escalate کرنا چاہیے؛ input-heavy shape fast-tier pricing کو compound کر دیتی ہے۔

استعمال کے مطابق ادائیگی · سرکاری قیمت سے کم

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

BibiGPT سے مخصوص failure modes۔

fallback chain آپ کو حیران کر سکتی ہے۔ اگر OPENAI_COMPATIBLE_API_KEY خالی ہو، تو app خاموشی سے OPENAI_API_KEY پر fallback کر جاتا ہے۔ یہ اس وقت تک آسان ہے جب تک دونوں مختلف services کی طرف point نہ کریں: ایک gateway base URL کے ساتھ OpenAI key authentication errors پیدا کرتی ہے جو gateway کے مسائل جیسی لگتی ہیں۔ جب routing بدلے، تو compatible-prefixed جوڑا اکٹھے سیٹ کریں اور کوئی پرانا OPENAI_API_KEY کہیں اور point کرتا ہوا نہ چھوڑیں، یا یقینی بنائیں کہ وہ بھی وہی gateway key رکھتا ہے۔ base URL validator بغیر scheme والی values کو رد کر دیتا ہے، تو ایک bare host ایک واضح error کے ساتھ فوری فیل ہوتا ہے؛ https:// اور /v1 path شامل کریں۔ Trailing slashes normalize ہو کر ہٹ جاتے ہیں، تو وہاں دونوں forms کام کرتی ہیں۔ Model ids endpoint کی /v1/models listing کے خلاف exact strings ہیں؛ OPENAI_COMPATIBLE_MODEL میں ایک typo پہلی summary کو model-not-found کے ساتھ فیل کر دیتا ہے۔ per-video override بھی یاد رکھیں: اگر کوئی flow پرانا model استعمال کرتا رہے، تو کچھ request config میں ایک explicit model pass کر رہا ہے۔ Transcript fetching الگ plumbing ہے۔ اگر کوئی video اس لیے summary پیدا نہ کرے کہ subtitles یا audio fetch نہ ہو سکے، تو یہ content pipeline ہے (platform APIs، subtitle availability)، LLM endpoint نہیں۔ اس guide میں env vars صرف summarization calls کو move کرتے ہیں۔ اور نوٹ کریں کہ hosted bibigpt.co service اپنے models خود manage کرتی ہے؛ یہ variables اس open-source v1 کو configure کرتے ہیں جسے آپ خود deploy کرتے ہیں۔

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

• Bilingual viewers جو Bilibili اور YouTube دونوں summarize کرتے ہیں، Chinese-strong ids کو global ids کے ساتھ ایک ہی key کے پیچھے جوڑتے ہیں بجائے فی زبان ایک vendor کے۔
• China-adjacent setups میں self-hosters جہاں ایک ہی OpenAI-compatible endpoint جو GLM، DeepSeek، اور Kimi بھی serve کرتا ہے multi-vendor billing کے مسئلے کو مکمل طور پر ختم کر دیتا ہے۔
• وہ teams جو meetings اور lectures کے لیے ایک shared summarizer چلاتی ہیں، فی key usage میٹر کرتی ہیں اور volume-tier ids پر default ہوتی ہیں۔
• بھاری podcast listeners، جہاں ہفتے میں کئی گھنٹوں کا transcript input-token pricing کو پوری cost story بنا دیتا ہے۔
• وہ developers جن کے پاس کسی مخصوص vendor کی billing تک رسائی نہیں۔ Top-up پر مبنی رسائی بغیر کارڈ کی شرط کے فی-provider sign-up کا انحصار ختم کر دیتی ہے۔

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

ان models کی list کریں جنہیں آپ کی key address کر سکتی ہے اور تصدیق کریں کہ OPENAI_COMPATIBLE_MODEL میں موجود id ان میں شامل ہے؛ یہ ایک check زیادہ تر first-run failures کو روک دیتا ہے۔ پھر کوئی مختصر چیز summarize کریں۔ ایک authentication error کا مطلب ہے resolved key base URL سے میچ نہیں کرتی، اور fallback chain کو دیکھتے ہوئے، فرض کرنے سے پہلے پرنٹ کریں کہ کون سا variable اصل میں key فراہم کر رہا ہے۔ Model-not-found ایک id typo ہے۔ startup پر ایک scheme error کا مطلب ہے base URL میں https:// missing ہے۔ ایک healthy endpoint کے باوجود کبھی شروع نہ ہونے والی summary کا مطلب ہے transcript fetch کسی بھی LLM call سے پہلے فیل ہو رہی ہے۔ ایک بار summaries چلنے لگیں، APIsRouter console per-request model، token counts، اور spend دکھاتا ہے۔ Transcript summarization سب سے واضح input-heavy workload ہے، اور ایک ہفتے کا usage data آپ کو ہر model کے لیے content کے فی گھنٹہ حقیقی cost بتاتا ہے، جو وہ number ہے جسے optimize کرنا قابل قدر ہے۔

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

عمومی سوالات