خلاصه‌های ویدیویی BibiGPT را روی یک API سفارشی سازگار با OpenAI اجرا کنید.

پاسخ سریع: سه متغیر محیطی.

فایل محیطی نمونه BibiGPT سطح را مستقیم مستند می‌کند: OPENAI_COMPATIBLE_BASE_URL endpoint را تنظیم می‌کند (پیش‌فرض https://api.openai.com/v1)، OPENAI_COMPATIBLE_API_KEY کلید را نگه می‌دارد (fallback به OPENAI_API_KEY وقتی تنظیم‌نشده)، و OPENAI_COMPATIBLE_MODEL مدل پیش‌فرض برای خلاصه‌ها را انتخاب می‌کند. base URL را روی https://api.apisrouter.com/v1 تنظیم کنید، یک کلید gateway در متغیر کلید بگذارید، و هر id کاتالوگی را به‌عنوان مدل انتخاب کنید. base URL هنگام استفاده اعتبارسنجی می‌شود: باید با http:// یا https:// شروع شود، و اسلش‌های انتهایی حذف می‌شوند، پس شکل /v1 بالا دقیقاً درست است. زیر کاپوت، اپ یک provider سازگار با openai از Vercel AI SDK از این مقادیر می‌سازد و chatModel را با id پیکربندی‌شده فرا می‌خواند، که به همین دلیل هر مدلی که endpoint سرویس دهد بدون تغییر کد کار می‌کند.

# 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 (JimmyLv در GitHub، حدود ۶ هزار ستاره برای نسخه متن‌باز v1) یک خلاصه‌ساز AI یک-کلیکی برای صدا و ویدیو است: یک لینک Bilibili یا YouTube، یک پادکست، ضبط یک جلسه، یا یک فایل محلی را بچسبانید، و آن transcript را می‌گیرد، آن را فشرده می‌کند، و اجازه می‌دهد با محتوا چت کنید. به‌عنوان BiliGPT برای خلاصه‌های Bilibili شروع شد و به یک ابزار دوزبانه با یک جانشین میزبانی‌شده رشد کرد؛ پیکربندی محیطی توصیف‌شده اینجا روی نسخه متن‌باز self-hosted اعمال می‌شود. workload به‌شکل transcript است: ورودی بلند، خروجی کوتاه. یک ساعت گفتار transcript زیادی است، که اپ آن را به قطعات به‌اندازه مدل قبل از خلاصه‌سازی chunk می‌کند، پس یک ویدیو می‌تواند به‌معنای چندین فراخوانی chat-completions باشد که token های input آن‌ها بر خلاصه‌ای که تولید می‌کنند سایه می‌اندازد. پس قیمت هر-token-input کل اقتصاد است، و مدل‌های long-context chunking را برای سخنرانی‌ها و پادکست‌های بلند کاهش می‌دهند. ساخت provider مقادیر را در یک آبشار معقول resolve می‌کند: یک کلید هر-درخواست (برای instance هایی که به کاربران اجازه می‌دهند کلید خودشان را بیاورند) بر OPENAI_COMPATIBLE_API_KEY غالب است، که بر OPENAI_API_KEY غالب است؛ همین برای base URL و مدل هم اعمال می‌شود. حتی یک متغیر OPENAI_COMPATIBLE_KEY_PREFIXES برای پذیرش کلیدهای وارد‌شده توسط کاربر که پیشوند آن‌ها sk- نیست وجود دارد، که وقتی کلیدهایی که کاربران شما نگه می‌دارند از یک gateway به‌جای OpenAI می‌آیند اهمیت دارد.

راه‌اندازی کامل برای یک instance خودمیزبان.

BibiGPT یک اپ Next.js است، پس محیط هرطور که deploy کنید سفر می‌کند: یک فایل .env محلی، متغیرهای محیطی پروژه روی Vercel، یا env کانتینر در Docker. سه متغیر را تنظیم کنید، دوباره deploy یا restart کنید، و خلاصه‌ها از طریق gateway مسیردهی می‌شوند. متغیر مدل پیش‌فرض است، نه یک محدودیت سخت. درخواست‌ها یک config هر-ویدیو حمل می‌کنند که فیلد model آن، وقتی حاضر باشد، OPENAI_COMPATIBLE_MODEL را override می‌کند، پس یک instance می‌تواند به یک id حجمی پیش‌فرض شود در حالی که flow های خاص یک id قوی‌تر درخواست می‌کنند. اگر instance را برای دیگران اجرا می‌کنید و اجازه می‌دهید کلیدهای خودشان را بچسبانند، OPENAI_COMPATIBLE_KEY_PREFIXES را طوری تنظیم کنید که پیشوند کلید gateway شما را شامل شود تا فرم آن‌ها را بپذیرد.

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-

انتخاب یک مدل خلاصه‌سازی، شرق و غرب.

مقایسه اجرای صادقانه‌اش آسان است: همان ویدیو، دو id مدل، هر دو خلاصه را در برابر transcript بخوانید. usage log هر-کلید هر کاندید را روی محتوای واقعی قیمت‌گذاری می‌کند، و برای workload های transcript تفاوت بلافاصله در ستون input-token قابل‌مشاهده است.

• محتوای چینی زمین خانگی BibiGPT است: سخنرانی‌های Bilibili، کلیپ‌های Douyin، پادکست‌های چینی. glm-5.2، deepseek-v4-flash، و kimi-k2.6 به‌طور native روی transcript های چینی قوی‌اند و پشت همان endpoint بقیه می‌نشینند.
• محتوای انگلیسی و مخلوط (YouTube، پادکست‌های جهانی) روی claude-haiku-4-5-20251001 و gemini-3.5-flash خوب عمل می‌کند، هر دو با transcript های بلند و پرنویز راحت.
• این تفکیک استدلال عملی چین-به‌علاوه-جهانی برای یک gateway است: یک endpoint، یک کلید، و override مدل هر-ویدیو خانواده درست را به ازای هر منبع محتوا انتخاب می‌کند به‌جای اجبار یک vendor برای هر دو.
• سخنرانی‌های بلند به context بلند پاداش می‌دهند. chunk کمتر یعنی فراخوانی کمتر و خلاصه‌ای منسجم‌تر؛ یک id long-context را در برابر بلندترین محتوای خود قبل از استانداردسازی تست کنید.
• instance های حجمی (تیمی که هر چیزی که تماشا می‌کند را خلاصه می‌کند) باید به deepseek-v4-flash پیش‌فرض شوند و به‌صورت گزینشی escalate کنند؛ شکل input-سنگین باعث می‌شود قیمت‌گذاری fast-tier انباشته شود.

پرداخت بر اساس مصرف · پایین‌تر از قیمت رسمی

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

حالت‌های شکست مختص BibiGPT.

زنجیره fallback می‌تواند شما را غافلگیر کند. اگر OPENAI_COMPATIBLE_API_KEY خالی باشد، اپ بی‌صدا به OPENAI_API_KEY برمی‌گردد. این راحت است تا وقتی آن دو به سرویس‌های مختلف اشاره کنند: یک base URL gateway با یک کلید OpenAI خطاهای احراز هویتی تولید می‌کند که شبیه مشکلات gateway به‌نظر می‌رسند. وقتی مسیردهی تغییر می‌کند، جفت پیشوند-compatible را با هم تنظیم کنید و هیچ OPENAI_API_KEY کهنه‌ای که جای دیگری اشاره می‌کند رها نکنید، یا مطمئن شوید همان کلید gateway را نگه می‌دارد. اعتبارسنج base URL مقادیر بدون scheme را رد می‌کند، پس یک host خام سریع با یک خطای واضح شکست می‌خورد؛ https:// و مسیر /v1 را شامل کنید. اسلش‌های انتهایی نرمالایز می‌شوند، پس هر دو شکل آنجا کار می‌کنند. id های مدل رشته‌های دقیق در برابر فهرست /v1/models endpoint هستند؛ یک غلط‌تایپی در OPENAI_COMPATIBLE_MODEL اولین خلاصه را با model-not-found شکست می‌دهد. override هر-ویدیو را هم به‌خاطر داشته باشید: اگر یک flow همچنان از یک مدل قدیمی استفاده می‌کند، چیزی یک model صریح در config درخواست پاس می‌دهد. دریافت transcript لوله‌کشی جدایی است. اگر یک ویدیو خلاصه‌ای تولید نمی‌کند چون زیرنویس یا صدا قابل‌دریافت نبوده، این pipeline محتوا است (API های پلتفرم، در دسترس‌بودن زیرنویس)، نه endpoint LLM. env var های این راهنما فقط فراخوانی‌های خلاصه‌سازی را جابه‌جا می‌کنند. و توجه کنید سرویس میزبانی‌شده bibigpt.co مدل‌های خودش را مدیریت می‌کند؛ این متغیرها نسخه متن‌باز v1 ای که خودتان deploy می‌کنید را پیکربندی می‌کنند.

چه کسانی BibiGPT را از طریق یک gateway مسیردهی می‌کنند.

• بینندگان دوزبانه‌ای که هم Bilibili و هم YouTube را خلاصه می‌کنند، id های قوی-چینی را با id های جهانی پشت یک کلید جفت می‌کنند به‌جای یک vendor به ازای هر زبان.
• self-hoster هایی در راه‌اندازی‌های نزدیک-به-چین جایی که یک endpoint تکی سازگار با OpenAI که GLM، DeepSeek، و Kimi را هم سرویس می‌دهد مشکل صورت‌حساب چند-vendor را کاملاً حذف می‌کند.
• تیم‌هایی که یک خلاصه‌ساز مشترک برای جلسات و سخنرانی‌ها اجرا می‌کنند، usage را به ازای هر کلید متر می‌کنند و به id های volume-tier پیش‌فرض می‌شوند.
• شنوندگان سنگین پادکست، جایی که ساعت‌ها transcript در هفته قیمت‌گذاری input-token را کل داستان هزینه می‌کند.
• توسعه‌دهندگان بدون دسترسی به صورت‌حساب یک vendor خاص. دسترسی مبتنی بر شارژ بدون الزام کارت وابستگی ثبت‌نام هر-provider را حذف می‌کند.

endpoint را تأیید کنید و اولین خلاصه را عیب‌یابی کنید.

مدل‌هایی را که کلید شما می‌تواند آدرس دهد فهرست کنید و تأیید کنید id در OPENAI_COMPATIBLE_MODEL جزو آن‌هاست؛ همین یک چک بیشتر شکست‌های اجرای اول را جلوگیری می‌کند. سپس چیز کوتاهی را خلاصه کنید. یک خطای احراز هویت یعنی کلید resolve‌شده با base URL مطابقت ندارد، و با توجه به زنجیره fallback، قبل از فرض‌کردن چاپ کنید کدام متغیر واقعاً کلید را تأمین کرده. Model-not-found یک غلط‌تایپی id است. یک خطای scheme در startup یعنی base URL که https:// را گم کرده. خلاصه‌ای که با وجود یک endpoint سالم هرگز شروع نمی‌شود یعنی دریافت transcript بالادست هر فراخوانی LLM شکست می‌خورد. وقتی خلاصه‌ها جاری شوند، کنسول APIsRouter مدل، شمارش token، و هزینه هر-درخواست را نشان می‌دهد. خلاصه‌سازی transcript شفاف‌ترین workload input-سنگین موجود است، و یک هفته داده usage هزینه واقعی هر-ساعت محتوا برای هر مدل را به شما می‌گوید، که همان عددی است که ارزش بهینه‌سازی دارد.

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

پرسش‌های پرتکرار