รันสรุปวิดีโอของ BibiGPT บน custom OpenAI-compatible API

คำตอบสั้น ๆ: สามตัวแปร environment

ไฟล์ตัวอย่าง environment ของ BibiGPT ระบุพื้นผิวนี้ตรง ๆ: OPENAI_COMPATIBLE_BASE_URL ตั้ง endpoint (ค่าเริ่มต้น https://api.openai.com/v1), OPENAI_COMPATIBLE_API_KEY เก็บ key (ตกกลับไป OPENAI_API_KEY เมื่อไม่ได้ตั้งค่า) และ OPENAI_COMPATIBLE_MODEL เลือกโมเดลเริ่มต้นสำหรับสรุป ตั้ง base URL เป็น https://api.apisrouter.com/v1 ใส่ key ของ gateway ในตัวแปร key แล้วเลือก id ในแคตตาล็อกใดก็ได้เป็นโมเดล base URL ถูกตรวจสอบตอนใช้งาน: ต้องขึ้นต้นด้วย http:// หรือ https:// และเครื่องหมาย / ท้ายสุดจะถูกตัดออก ดังนั้นรูปแบบ /v1 ด้านบนถูกต้องเป๊ะ เบื้องหลัง แอปสร้าง provider แบบ openai-compatible ของ 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 มีดาวประมาณ 6K สำหรับ v1 แบบ open-source) คือตัวสรุปเสียงและวิดีโอด้วย AI แบบคลิกเดียว: วางลิงก์ Bilibili หรือ YouTube, podcast, บันทึกการประชุม หรือไฟล์ในเครื่อง แล้วมันจะดึง transcript ย่อให้กระชับ และให้คุณคุยกับเนื้อหาได้ มันเริ่มต้นเป็น BiliGPT สำหรับสรุป Bilibili แล้วเติบโตเป็นเครื่องมือสองภาษาที่มีเวอร์ชันที่โฮสต์ไว้เป็นรุ่นถัดไป การตั้งค่า environment ที่อธิบายที่นี่ใช้กับเวอร์ชัน open-source แบบ self-hosted workload มีรูปทรงแบบ transcript: input ยาว output สั้น เสียงพูดหนึ่งชั่วโมงคือ transcript จำนวนมาก ซึ่งแอปแบ่งเป็นชิ้นขนาดโมเดลก่อนสรุป ดังนั้นวิดีโอหนึ่งอันอาจหมายถึง call แบบ chat-completions หลายครั้งที่ input token มากกว่าสรุปที่มันสร้างมาก ราคาต่อ input token จึงเป็นเศรษฐศาสตร์ทั้งหมด และโมเดล context ยาวลดการแบ่งชิ้นสำหรับเลกเชอร์และ podcast ยาว การสร้าง provider แก้ค่าตามลำดับที่สมเหตุสมผล: key ต่อ request (สำหรับ instance ที่ให้ผู้ใช้นำ key มาเอง) ชนะ OPENAI_COMPATIBLE_API_KEY ซึ่งชนะ OPENAI_API_KEY เช่นเดียวกันกับ base URL และโมเดล ยังมีตัวแปร OPENAI_COMPATIBLE_KEY_PREFIXES สำหรับรับ key ที่ผู้ใช้กรอกเองที่ prefix ไม่ใช่ sk- ซึ่งสำคัญเมื่อ key ที่ผู้ใช้ของคุณถืออยู่มาจาก gateway ไม่ใช่ OpenAI

ตั้งค่าแบบเต็มสำหรับ instance แบบ self-hosted

BibiGPT เป็นแอป Next.js ดังนั้น environment เดินทางไปกับวิธี deploy ของคุณ: ไฟล์ .env ในเครื่อง, environment variable ของโปรเจกต์บน Vercel หรือ env ใน container บน Docker ตั้งค่าสามตัวแปร redeploy หรือ restart แล้วสรุปจะ route ผ่าน gateway ตัวแปรโมเดลเป็นค่าเริ่มต้น ไม่ใช่ขีดจำกัดตายตัว request แต่ละอันมี config ต่อวิดีโอที่ฟิลด์ model ของมัน ถ้ามี จะ override OPENAI_COMPATIBLE_MODEL ดังนั้น instance หนึ่งสามารถ default ไปที่ id ปริมาณในขณะที่ flow เฉพาะบางอันขอ id ที่แข็งแกร่งกว่า ถ้าคุณรัน instance ให้คนอื่นและให้พวกเขาวาง key ของตัวเอง ให้ตั้ง OPENAI_COMPATIBLE_KEY_PREFIXES ให้รวม prefix key ของ 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-

เลือกโมเดลสรุปทั้งฝั่งตะวันออกและตะวันตก

การเปรียบเทียบทำได้ง่ายอย่างซื่อตรง: วิดีโอเดียวกัน สอง model id อ่านสรุปทั้งคู่เทียบกับ transcript usage log ต่อ key ตั้งราคาผู้สมัครแต่ละคนบนเนื้อหาจริง และสำหรับ workload แบบ transcript ความต่างจะเห็นชัดทันทีในคอลัมน์ input token

• เนื้อหาจีนคือสนามเหย้าของ BibiGPT: เลกเชอร์ Bilibili, คลิป Douyin, podcast จีน glm-5.2, deepseek-v4-flash และ kimi-k2.6 แข็งแกร่งโดยธรรมชาติบน transcript ภาษาจีนและอยู่หลัง endpoint เดียวกับทุกอย่างอื่น
• เนื้อหาภาษาอังกฤษและผสม (YouTube, podcast สากล) ทำงานได้ดีบน claude-haiku-4-5-20251001 และ gemini-3.5-flash ทั้งคู่สบายใจกับ transcript ยาวที่มีเสียงรบกวน
• การแบ่งนี้คือข้อโต้แย้งเชิงปฏิบัติสำหรับจีนบวกสากลของ gateway: endpoint เดียว key เดียว และ override โมเดลต่อวิดีโอเลือกตระกูลที่ถูกต้องตามแหล่งเนื้อหาแทนที่จะบังคับ vendor เดียวสำหรับทั้งสองฝั่ง
• เลกเชอร์ยาวได้ประโยชน์จาก context ยาว การแบ่งชิ้นน้อยลงหมายถึง call น้อยลงและสรุปที่สอดคล้องกันมากขึ้น ทดสอบ id แบบ context ยาวกับเนื้อหายาวที่สุดของคุณก่อนทำเป็นมาตรฐาน
• instance ปริมาณมาก (ทีมที่สรุปทุกอย่างที่พวกเขาดู) ควร default ไปที่ deepseek-v4-flash และยกระดับแบบเลือกสรร รูปทรงที่ input หนักทำให้ราคาระดับเร็วทบต้น

จ่ายตามการใช้งาน · ถูกกว่าราคาทางการ

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

รูปแบบความล้มเหลวเฉพาะของ BibiGPT

chain การตกกลับอาจทำให้คุณแปลกใจ ถ้า OPENAI_COMPATIBLE_API_KEY ว่างเปล่า แอปจะตกกลับไปใช้ OPENAI_API_KEY อย่างเงียบ ๆ ซึ่งสะดวกจนกว่าทั้งสองจะชี้ไปที่บริการต่างกัน: base URL ของ gateway กับ key ของ OpenAI จะสร้าง authentication error ที่ดูเหมือนปัญหา gateway เมื่อเปลี่ยน routing ให้ตั้งคู่ compatible-prefixed ทั้งคู่พร้อมกันและอย่าปล่อยให้ OPENAI_API_KEY เก่าชี้ไปที่อื่น หรือให้แน่ใจว่ามันถือ key ของ gateway เดียวกัน ตัวตรวจสอบ base URL ปฏิเสธค่าที่ไม่มี scheme ดังนั้น host เปล่า ๆ จะล้มเหลวทันทีด้วย error ที่ชัดเจน ใส่ https:// และ path /v1 ด้วย เครื่องหมาย / ท้ายสุดถูก normalize ออกไป ดังนั้นทั้งสองรูปแบบใช้ได้ตรงนั้น id ของโมเดลเป็นสตริงที่ต้องตรงเป๊ะกับรายการ /v1/models ของ endpoint การพิมพ์ผิดใน OPENAI_COMPATIBLE_MODEL จะทำให้สรุปแรกล้มเหลวด้วย model-not-found จำ override ต่อวิดีโอไว้ด้วย: ถ้า flow หนึ่งยังใช้โมเดลเก่าอยู่ แสดงว่ามีบางอย่างส่ง model ที่ระบุชัดเจนใน request config การดึง transcript เป็นระบบแยกต่างหาก ถ้าวิดีโอไม่ให้สรุปเพราะดึง subtitle หรือเสียงไม่ได้ นั่นคือ content pipeline (platform API, ความพร้อมของ subtitle) ไม่ใช่ LLM endpoint ตัวแปร environment ในคู่มือนี้ย้ายแค่ call การสรุปเท่านั้น และสังเกตว่าบริการ bibigpt.co ที่โฮสต์ไว้จัดการโมเดลของตัวเอง ตัวแปรเหล่านี้ตั้งค่า open-source v1 ที่คุณ deploy เอง

ใครที่ route BibiGPT ผ่าน gateway

• ผู้ชมสองภาษาที่สรุปทั้ง Bilibili และ YouTube จับคู่ id ที่แข็งแกร่งด้านจีนกับ id สากลหลัง key เดียวแทนที่จะเป็นหนึ่ง vendor ต่อภาษา
• self-hoster ในการตั้งค่าใกล้จีน ที่ endpoint OpenAI-compatible เดียวที่เสิร์ฟ GLM, DeepSeek และ Kimi ด้วยตัดปัญหาการเก็บเงินหลาย vendor ออกไปทั้งหมด
• ทีมที่รันตัวสรุปร่วมกันสำหรับการประชุมและเลกเชอร์ วัด usage ต่อ key และ default ไปที่ id ระดับปริมาณ
• คนฟัง podcast หนัก ที่ transcript หลายชั่วโมงต่อสัปดาห์ทำให้ราคา input token เป็นเรื่องต้นทุนทั้งหมด
• นักพัฒนาที่ไม่มีสิทธิ์เข้าถึงระบบเก็บเงินของ vendor รายหนึ่ง การเข้าถึงแบบเติมเงินโดยไม่ต้องใช้บัตรตัดการพึ่งพาการสมัครต่อ provider ออกไป

ตรวจสอบ endpoint และ debug สรุปแรก

ลิสต์โมเดลที่ key ของคุณเรียกใช้ได้และยืนยันว่า id ใน OPENAI_COMPATIBLE_MODEL อยู่ในนั้น การตรวจสอบเดียวนี้ป้องกันความล้มเหลวในการรันครั้งแรกได้ส่วนใหญ่ จากนั้นสรุปอะไรสั้น ๆ authentication error หมายความว่า key ที่ resolve ได้ไม่ตรงกับ base URL และเมื่อพิจารณา chain การตกกลับ ให้พิมพ์ดูว่าตัวแปรไหนที่ให้ key จริง ๆ ก่อนสรุปเอาเอง model-not-found คือ id พิมพ์ผิด scheme error ตอน startup คือ base URL ที่ขาด https:// สรุปที่ไม่เริ่มเลยแม้ endpoint จะปกติดีคือการดึง transcript ล้มเหลวก่อนถึง LLM call ใด ๆ เมื่อสรุปไหลลื่นแล้ว console ของ APIsRouter แสดงโมเดลต่อ request, จำนวน token และค่าใช้จ่าย การสรุป transcript คือ workload ที่ input หนักที่ชัดเจนที่สุด และข้อมูล usage หนึ่งสัปดาห์บอกต้นทุนจริงต่อชั่วโมงของเนื้อหาสำหรับแต่ละโมเดล ซึ่งเป็นตัวเลขที่คุ้มค่าที่จะปรับให้ดีขึ้น

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

คำถามที่พบบ่อย