รัน Onyx บน custom OpenAI-compatible LLM provider

คำตอบสั้น ๆ: Add Custom LLM Provider ในหน้า admin

เอกสารของ Onyx ระบุชัดเจนว่า custom provider ทำงานได้ตราบใดที่มันเปิด OpenAI-compatible endpoint และตัวอย่างรูปร่าง Base URL ของมันก็คือ https://yourprovider.com/v1 แบบ gateway พอดี flow: เปิด Admin Panel จากไอคอนโปรไฟล์ของคุณ ไปที่ Configuration แล้ว Language Models แล้วเลือก Add Custom LLM Provider มีสี่การตัดสินใจที่สำคัญในฟอร์มนั้น Display Name เป็นแค่เครื่องสำอาง Provider Name ต้องตรงกับ key ของ provider ใน LiteLLM เพราะ Onyx route การเรียกโมเดลผ่าน LiteLLM ข้างใต้ สำหรับ gateway แบบ OpenAI-compatible คือ openai Base URL คือ endpoint ของ gateway รวม suffix /v1 และส่วน Model Configurations คือที่ที่คุณลงทะเบียน model id แต่ละตัวที่ต้องการให้ใช้ได้ สะกดตรงตามที่แคตตาล็อกเสิร์ฟเป๊ะ ๆ บันทึกแล้ว เลือกค่าเริ่มต้น แล้วแชทจะ route ผ่าน gateway ทันที

Admin Panel -> Configuration -> Language Models
  -> Add Custom LLM Provider

Display Name:   APIsRouter
Provider Name:  openai            (LiteLLM provider key)
Base URL:       https://api.apisrouter.com/v1
API Key:        sk-YOUR-APISROUTER-KEY
Model Configurations:
  claude-sonnet-4-6
  claude-haiku-4-5-20251001
  deepseek-v4-pro

LLM อยู่ตรงไหนในสถาปัตยกรรมของ Onyx

Onyx (onyx-dot-app บน GitHub มีดาวประมาณ 31K เดิมชื่อ Danswer) คือแพลตฟอร์ม AI open-source สำหรับความรู้ของบริษัท: มัน index แหล่งข้อมูลอย่าง Slack, Google Drive, Confluence และ connector อีกหลายสิบตัว แล้วตอบคำถามเหนือมันผ่าน chat UI, assistant และ agent workflow มันเป็นหนึ่งใน stack ค้นหาระดับองค์กรแบบ self-hosted ที่ถูก deploy มากที่สุด ซึ่งเป็นเหตุผลพอดีที่บิล LLM ของมันสมควรได้รับการตัดสินใจเรื่อง routing แทนที่จะเป็นค่าเริ่มต้น pipeline แยกออกเป็นสองส่วนอย่างชัดเจน การ index และ retrieval รวมถึงการ embed และ rerank เอกสาร รันบน model server ของ Onyx เองด้วยโมเดล local เป็นค่าเริ่มต้น ไม่มีส่วนไหนแตะ LLM provider ของคุณเลย การสร้างคำตอบคืออีกครึ่งหนึ่ง: เมื่อ retrieval ประกอบ passage ที่เกี่ยวข้องแล้ว LLM จะอ่านมันแล้วเขียนคำตอบที่อิงหลักฐาน และการเรียกนั้น route ผ่าน LiteLLM ไปยัง provider ที่ admin ตั้งค่าไว้ custom provider flow สลับปลายทางของครึ่งนี้เท่านั้น เพราะ LiteLLM ส่ง model id ผ่านเป็นสตริงธรรมดาไปยัง provider ประเภท openai id ที่คุณลงทะเบียนใน Model Configurations เป็นอะไรก็ได้ที่ endpoint หลัง Base URL เสิร์ฟ: Claude สำหรับคำตอบที่อิงหลักฐานอย่างพิถีพิถัน DeepSeek สำหรับปริมาณ Gemini สำหรับ source context ที่ยาวมาก assistant ต่างกันสามารถใช้โมเดลเริ่มต้นต่างกันได้ ดังนั้น assistant ฝ่ายสนับสนุนและ assistant วิศวกรรมสามารถขี่จุดราคาต่างกันผ่าน provider entry เดียวกัน

ตั้งค่าแบบเต็ม และสิ่งที่ยังคงเหมือนเดิม

ฟอร์ม provider คือการเชื่อมต่อทั้งหมด ไม่มี config file ให้แก้หรือ container ให้ rebuild สำหรับมัน หลังบันทึก ตั้งโมเดลเริ่มต้นให้ workspace แล้วถ้าต้องการ override โมเดลต่อ assistant ตรงที่คุณต้องการระดับคุณภาพต่างกัน สิ่งที่ยังคงเหมือนเดิมโดยตั้งใจ: connector เก็บ credential ของตัวเอง index ไม่ได้รับผลกระทบ และ embedding model ที่ตั้งค่าไว้สำหรับการค้นหาไม่ขยับ การแยกนี้คุ้มค่าที่จะพูดชัด ๆ เพราะมันทำให้การเปลี่ยนแปลงนี้มีความเสี่ยงต่ำ ถ้า gateway ทำงานผิดปกติ การค้นหาและแหล่งข้อมูลยังทำงานได้อยู่ มีแค่การสร้างคำตอบที่จะ error และการสลับค่าเริ่มต้นกลับไป provider ก่อนหน้าเป็นแค่ dropdown เดียว สำหรับทีมที่ทำ deployment แบบอัตโนมัติ provider definition เดียวกันสามารถ seed ผ่าน API ของ Onyx แทนการคลิกผ่าน UI ได้ แต่ path หน้า admin คือพื้นผิวที่มีเอกสารรองรับและมั่นคง และการตั้งค่าครั้งเดียวก็ไม่ค่อยคุ้มค่ากับมากกว่านั้น

# confirm the gateway lists the ids you plan to register
curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

# confirm a chat completion works end to end
curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"ping"}]}'

เลือกโมเดลสำหรับคำตอบระดับองค์กรที่อิงหลักฐาน

การประเมินโมเดลข้างใน Onyx เป็นรูปธรรมผิดปกติ: ถามคำถามเดียวกันเทียบกับ connector เดียวกันด้วยค่าเริ่มต้น assistant สองแบบ แล้วเทียบว่าคำตอบไหนอ้างอิง passage ถูกต้อง usage log ต่อ key ตั้งราคาผู้เข้าแข่งขันทั้งสองบนชุดคำถามจริงของคุณ

• การตอบแบบอิงหลักฐานเป็นงานที่ input หนัก: โมเดลอ่าน passage ที่ retrieve มาซึ่งใหญ่กว่าคำตอบที่มันเขียนมาก ราคาต่อ input token จึงตั้งต้นทุนต่อคำถามมากกว่าราคา output
• claude-sonnet-4-6 คือค่าเริ่มต้นของ workspace ที่แข็งแกร่ง: มีวินัยอยู่ในแหล่งข้อมูลที่ retrieve มา และต้านทานการคิดค้นนโยบายที่ไม่มีอยู่ในเอกสาร
• assistant ที่มี traffic สูง (ฝ่ายสนับสนุน IT, FAQ ฝ่ายบุคคล) ทำงานได้ดีบน claude-haiku-4-5-20251001 หรือ deepseek-v4-pro ที่ราคาระดับปริมาณทำให้ต้นทุนต่อที่นั่งคาดการณ์ได้
• เอกสารต้นทางที่ยาวเข้าทาง id แบบ context ยาว gemini-3.1-pro-preview คุ้มค่าทดสอบสำหรับ assistant ที่ดึงเอกสารออกแบบขนาดใหญ่หรือสัญญาเข้า context
• ลงทะเบียนหลาย id ใน provider entry เดียวแล้วกำหนดต่อ assistant ระดับคุณภาพต่อทีมดีกว่าโมเดลประนีประนอมเดียวสำหรับทุกคน

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

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

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

Provider Name ไม่ใช่ label แบบ free-text มันต้องตรงกับ key ของ provider ใน LiteLLM และสำหรับ gateway key นั้นคือ openai ชื่อที่คิดขึ้นเองจะล้มเหลวตอนรันด้วย LiteLLM provider error แม้ฟอร์มจะบันทึกได้สำเร็จก็ตาม Base URL ต้องการ suffix /v1 เอกสารของ Onyx เองแสดงรูปร่าง endpoint ที่ลงท้ายด้วย /v1; ถ้าไม่มีมัน path ของ chat-completions จะ resolve ผิดและ request จะ 404 ที่ gateway Model id อยู่ใน Model Configurations โมเดลที่คุณไม่เคยลงทะเบียนไว้ที่นั่นจะเลือกเป็นค่าเริ่มต้นไม่ได้ และการพิมพ์ id ผิดจะปรากฏเป็น error model-not-found ตอนใช้ครั้งแรก ไม่ใช่ตอนบันทึก รายการ /v1/models ของ gateway คือการสะกดที่เชื่อถือได้ ถ้า admin UI ของคุณไม่มีฟิลด์ Base URL บนฟอร์ม custom-models คุณเจอ UI regression ที่มีรายงานใน release บางตัวของปี 2026 ไม่ใช่ฟีเจอร์ที่หายไป การอัปเกรดจะคืนฟิลด์นั้นมา และจำไว้ว่าคุณย้ายครึ่งไหน: ถ้าผลการค้นหาดูผิดหรือเก่า นั่นคือ indexing และ connector ซึ่งไม่แตะ custom provider เลย มีแค่คำตอบที่สร้างเท่านั้นที่ route ผ่าน gateway

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

• ทีม self-hosted ที่แทนที่บัญชี vendor ต่อรายด้วย endpoint เดียว key เดียว และ usage ต่อ key ที่ map เข้ากับ workspace หรือแผนกได้อย่างชัดเจน
• องค์กรที่มาตรฐาน Onyx สำหรับการค้นหาภายในและต้องการคำตอบที่อิงหลักฐานระดับ Claude โดยไม่ต้องมีความสัมพันธ์การเก็บเงินกับ Anthropic แยกต่างหาก
• ทีม platform ที่รันหลาย assistant ที่ระดับคุณภาพต่างกัน ตั้งราคาต่อ assistant ผ่าน model id ที่ลงทะเบียนบน provider เดียว
• ผู้ประเมินที่เปรียบเทียบคุณภาพคำตอบข้ามตระกูลโมเดลบน corpus เดียวกัน ที่แต่ละตัวเลือกเป็นแค่ id ที่ลงทะเบียน ไม่ใช่การเชื่อมต่อ provider ใหม่
• นักพัฒนาที่ไม่มีสิทธิ์เข้าถึงระบบเก็บเงินของ vendor รายหนึ่ง การเข้าถึงแบบเติมเงินโดยไม่ต้องใช้บัตรตัดการพึ่งพาการสมัครต่อ provider ออกไป

ตรวจสอบ endpoint และ debug การแชทแรก

การตรวจสอบด้วย curl สองอันข้างบนครอบคลุมฝั่ง gateway ก่อนที่คุณจะแตะฟอร์ม: id ที่คุณวางแผนจะลงทะเบียนต้องปรากฏใน /v1/models และ chat completion โดยตรงควรตอบได้ ข้างใน Onyx ความล้มเหลวหาที่มาได้เร็ว provider error ที่พูดถึง LiteLLM หมายความว่า Provider Name ไม่ใช่ key ที่ถูกต้อง ตั้งเป็น openai authentication error ตอนแชทครั้งแรกหมายความว่า API Key ไม่ตรงกับ endpoint ใน Base URL error model-not-found คือความไม่ตรงกันของ id ระหว่าง Model Configurations กับแคตตาล็อก คำตอบที่สร้างขึ้นแต่เมินเอกสารของคุณเป็นปัญหา retrieval หรือ connector ซึ่งอยู่ก่อน LLM provider ทั้งหมด เมื่อแชทไหลลื่นแล้ว console ของ APIsRouter แสดงโมเดลต่อ request, จำนวน token และค่าใช้จ่าย สำหรับเครื่องมือ workspace ที่ทุกคำถามพก context ที่ retrieve มา ตัวเลข token ต่อคำถามนั้นคือฐานที่ตรงไปตรงมาสำหรับการวางแผนกำลังการผลิต และ key เดียวต่อ workspace เปลี่ยน usage log ให้เป็นรายงานต้นทุนระดับแผนก

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