รัน AnythingLLM บนโมเดลใดก็ได้ผ่าน Generic OpenAI

คำตอบสั้น ๆ: ห้าฟิลด์ใน LLM Preference

เปิดการตั้งค่าของ AnythingLLM ไปที่ส่วน LLM ใต้ AI Providers (หน้าจอที่แต่เดิมชื่อ LLM Preference) แล้วค้นหา Generic OpenAI ในรายการ provider เมื่อเลือกแล้วจะปรากฏห้าฟิลด์: Base URL, API Key, Chat Model Name, Token Context Window และ Max Tokens กรอกดังนี้: Base URL https://api.apisrouter.com/v1 (ต้องมี /v1 ในฟิลด์นี้), key ของคุณ และ id ในแคตตาล็อกเป๊ะ ๆ ใน Chat Model Name เช่น claude-sonnet-4-6 จากนั้นตัวเลขสองตัว: Token Context Window คือ window ทั้งหมดของโมเดล และ Max Tokens จำกัดคำตอบหนึ่งครั้ง ดังนั้นให้เอาทั้งสองค่ามาจากเอกสารของโมเดลแทนที่จะเดา บันทึกแล้ว ทุก workspace ที่ตามค่าเริ่มต้นของระบบจะแชทผ่าน gateway ตั้งแต่นั้น เอกสารระบุ provider นี้ว่าเน้นนักพัฒนาก็เพราะมันเชื่อ input ของคุณตรง ๆ นั่นไม่ใช่คำเตือนไม่ให้ใช้ แค่บอกว่าห้าฟิลด์นี้คือสัญญา

Base URL:              https://api.apisrouter.com/v1
API Key:               sk-YOUR-APISROUTER-KEY
Chat Model Name:       claude-sonnet-4-6
Token Context Window:  200000
Max Tokens:            8192

สิ่งที่ Generic OpenAI provider ขับเคลื่อนจริง ๆ

AnythingLLM (Mintplex Labs บน GitHub มีดาวประมาณ 63K) คือผู้ช่วยเอกสารส่วนตัวแบบ all-in-one: workspace ที่ embed ไฟล์ของคุณ แชทโดยอิงจาก context ที่ retrieve มา agent ที่ใช้ tool ได้ มีทั้งแบบ desktop app และ server ที่ self-host ได้ LLM preference ที่ตั้งค่าไว้ข้างบนคือสมองเริ่มต้นของทั้งหมดนี้ request ออกไปเป็น chat completions มาตรฐานเทียบกับ Base URL ของคุณ โดยมี Chat Model Name เป็น model string ดังนั้น vendor ไม่มีผล: id ของ Claude ใช้ได้พอ ๆ กับของ GPT และการสลับก็แค่แก้ไขฟิลด์เดียว workspace ยังสามารถ override ค่าเริ่มต้นของระบบด้วย provider และการตั้งค่าโมเดลของตัวเองได้ ซึ่งเป็นวิธีที่ deployment เดียวรัน claude-sonnet-4-6 ให้ workspace ฝ่ายกฎหมายและ gpt-5.5 ให้ฝ่ายวิศวกรรม โดยที่ทั้งสองไม่รู้เรื่องของกันและกัน ฟิลด์ token สองตัวสมควรได้รับความใส่ใจ เพราะ AnythingLLM ใช้มันจัดงบ context ค่า context window ตัดสินว่าจะบรรจุข้อความเอกสารที่ retrieve มาและประวัติแชทเข้าไปในแต่ละ request มากแค่ไหน ถ้าตั้งต่ำไปเอกสารที่คุณ embed มาอย่างพิถีพิถันจะถูกตัดออกจากคำตอบของมันเอง ถ้าตั้งสูงไป request จะชนกับ limit จริงของโมเดล นี่คือคู่ฟิลด์ที่อยู่เบื้องหลังรายงาน "RAG รู้สึกโง่" ส่วนใหญ่บน endpoint ทั่วไป

embedding เป็นการตัดสินใจแยกต่างหาก

AnythingLLM แยก LLM preference ออกจาก embedding preference และการแยกนี้มีน้ำหนักจริง โมเดลแชทตอบคำถาม embedder แปลงเอกสารของคุณเป็น vector ตอนอัปโหลด และ vector เหล่านั้นอยู่ถาวร การเปลี่ยนโมเดลแชททำได้ฟรี วันไหนก็ได้ ต่อ workspace การเปลี่ยน embedder ทำให้เรขาคณิตของทุกสิ่งที่ embed ไปแล้วใช้ไม่ได้ และหมายความว่าต้อง re-embed เอกสารของคุณใหม่ การตั้งค่าที่ใช้จริง: AnythingLLM มี local embedder ในตัวที่ทำงานออฟไลน์ได้และไม่มีค่าใช้จ่าย หลาย deployment ก็แค่เก็บมันไว้ ถ้าคุณชี้ embedding preference ไปที่ remote endpoint แทน ให้ยืนยันว่า embedding id ที่ระบุนั้นถูกเสิร์ฟที่นั่นจริงก่อนอัปโหลดฐานเอกสารของคุณ และถือว่าทางเลือกนั้นผูกติดกับ vector store อิสระที่สิ่งนี้ซื้อมาให้ฝั่งแชทคือประเด็นสำคัญของสถาปัตยกรรมนี้: เมื่อ embedding นิ่งแล้ว โมเดลแชทของ Generic OpenAI ก็เป็นแค่ปุ่มปรับที่ความเสี่ยงต่ำ รัน deepseek-v4-pro หนึ่งเดือนสำหรับงานสรุปหนัก ๆ แล้วสลับฟิลด์ไปที่ claude-sonnet-4-6 หนึ่งไตรมาสสำหรับงานลูกค้า โดยไม่ต้องขยับอะไรเกี่ยวกับเอกสารของคุณเลย

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# Chat Model Name must match one of these ids exactly

เลือกโมเดลสำหรับงานเอกสาร

ทุก id คิดเงินผ่าน key เดียวกัน ดังนั้น loop เปรียบเทียบก็แค่แก้ไขการตั้งค่า: workspace เดียวกัน เอกสารเดียวกัน สองสัปดาห์ต่อผู้เข้าแข่งขันแต่ละราย แล้วดูค่าใช้จ่ายต่อโมเดลใน console ของ APIsRouter ควบคู่กับวิจารณญาณของคุณเองต่อคำตอบ

• QA ที่อิงจาก chunk ที่ retrieve มาเป็นงานที่ input หนัก: claude-haiku-4-5-20251001 และ gemini-3.5-flash ตอบคำถามที่ต้องอ้างอิงได้ดีในราคาระดับปริมาณ
• claude-sonnet-4-6 สมควรเป็นค่าเริ่มต้นตรงจุดที่คำตอบส่งถึงมนุษย์โดยไม่มีการแก้ไข: รีวิวสัญญา ร่างรายงาน อะไรก็ตามที่มีผลตามมา
• deepseek-v4-pro คือ workhorse สำหรับ context ยาวในงาน workspace ที่สร้างจากเอกสารขนาดใหญ่ ที่ window และราคา input ครอบงำประสบการณ์
• workspace ของ agent ต้องการ tool calling ที่เชื่อถือได้ เริ่ม agent ด้วย claude-sonnet-4-6 แล้วทดสอบว่า id ที่เบากว่าไหวไหมกับ flow จริงของคุณ
• ใช้การ override ต่อ workspace เป็นนโยบาย: ค่าเริ่มต้นยังคงเร็ว และ id ที่แพงอยู่แค่ใน workspace ที่งานคุ้มค่ากับมัน

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

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

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

ฟิลด์ token คือสาเหตุของความล้มเหลวที่ซ่อนเร้น context window ที่ตั้งต่ำไปจะตัด context ที่ retrieve มาอย่างเงียบ ๆ ซึ่งแสดงออกเป็นโมเดลที่เมินเอกสารของคุณ ตั้ง window ตามเอกสารสำหรับ id ใน Chat Model Name Max Tokens ที่ตั้งสูงเกินไปสำหรับโมเดลจะทำให้เกิด error ตรง ๆ กับคำตอบยาว ๆ ตั้งมันให้ตรงกับสิ่งที่โมเดลอนุญาตจริงสำหรับ output error ตรง ๆ ซื่อสัตย์กว่า Authentication failure คือฟิลด์ API Key Model-not-found คือ Chat Model Name เพี้ยนไปจากการสะกดในแคตตาล็อก ฟิลด์นี้เป็น free text และรายการ /v1/models คือแหล่งความจริง Connection error บน desktop app มักหมายความว่ามี proxy หรือ firewall คั่นระหว่างแอปกับ endpoint บน Docker deployment จำไว้ว่า container ต่างหากที่ต้องเข้าถึง Base URL ได้ ไม่ใช่ browser ของคุณ ถ้าแชททำงานได้แต่ workspace ทำงานต่างจากที่คาดไว้ ให้เช็กการตั้งค่า override ของมัน; การตั้งค่า provider ระดับ workspace ชนะค่าเริ่มต้นของระบบ และ override ที่ลืมไว้คือปริศนา "คำถามเดียวกัน โมเดลต่างกัน" แบบคลาสสิก กรอบความคิดเน้นนักพัฒนาของเอกสารสรุปทั้งหมดข้างบนนี้: provider ทำตามที่ห้าฟิลด์บอกเป๊ะ ๆ ไม่มากไม่น้อย

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

• ทีมที่รันผู้ช่วยเอกสารส่วนตัวที่ต้องการคุณภาพคำตอบระดับ frontier โดยไม่ต้องมีบัญชี vendor ต่อตระกูลโมเดล
• ผู้ใช้ desktop ที่ชี้ฐานเอกสารส่วนตัวของตัวเองไปที่ id ของ Claude หรือ GPT บนยอดคงเหลือแบบเติมเงินล่วงหน้า ไม่ต้องใช้บัตรตอนเริ่ม
• self-hoster ที่เก็บ local embedder ในตัวไว้ และถือว่าแชทระยะไกลเป็นช่องทางเดียวที่ถูกมิเตอร์ อ่านต่อโมเดลใน usage log เดียว
• deployment ที่แบ่งตาม workspace ซึ่ง override ต่อ workspace บวกกับการมิเตอร์ต่อ key ให้แต่ละทีมมีโมเดลของตัวเองและบิลของตัวเอง
• builder ที่เปรียบเทียบโมเดลตอบคำถามบนฐานเอกสารคงที่ ที่แต่ละตัวเลือกเป็นแค่การแก้ไขการตั้งค่า ไม่ใช่การย้ายระบบ

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

Curl รายการโมเดลและ chat completion หนึ่งครั้งก่อน โดยใช้ id เป๊ะ ๆ ที่คุณตั้งใจจะใส่ใน Chat Model Name เมื่อทั้งสองผ่าน ฝั่ง gateway ก็ได้รับการพิสูจน์แล้ว และอาการที่เหลือทั้งหมดอยู่ในห้าฟิลด์นั้น จากนั้น save การตั้งค่า provider แล้วถามคำถามหนึ่งข้อใน workspace ที่มีเอกสารที่คุณรู้จักดี คำตอบที่อิงหลักฐานและอ้างอิงได้แปลว่า pipeline ทั้งหมดทำงาน คำตอบที่เมินเอกสารชี้ไปที่ค่า context window หรือการตั้งค่า retrieval ของ workspace เอง error ตรง ๆ จับคู่ได้ชัดเจน: key, การสะกด id, รูปร่างของ Base URL เมื่อแชทไหลลื่นแล้ว console ของ APIsRouter แสดงโมเดลต่อ request, จำนวน token และค่าใช้จ่าย QA เอกสารคูณ token ฝั่ง input ผ่าน retrieval และ usage log คือที่ที่คุณจะรู้ว่าฐานเอกสารของคุณมีค่าใช้จ่ายจริงในการ query เท่าไหร่ ต่อโมเดล ต่อวัน และต่อ key ของ workspace ถ้าคุณแยกไว้

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"}]}'

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