รันแอป Dify บน OpenAI-API-compatible endpoint

คำตอบสั้น ๆ: ติดตั้ง provider แล้วเพิ่มโมเดลตาม id

ใน Dify เปิด Settings แล้วไปที่ Model Provider ตั้งแต่ Dify 1.0 provider เป็น plugin: หา OpenAI-API-compatible (เผยแพร่โดย langgenius) ในรายการ หรือติดตั้งจาก Marketplace แล้วคลิก Add Model บนการ์ดของมัน dialog นี้เป็นแบบต่อโมเดล: เลือก Model Type (LLM สำหรับโมเดลแชท) ใส่ id ในแคตตาล็อกเป๊ะ ๆ ใน Model Name วาง key ของคุณใน API Key และตั้ง API Base URL เป็น https://api.apisrouter.com/v1 ปล่อย Completion mode ไว้ที่ Chat แล้วตั้ง Model context size และ Upper bound for max tokens ตาม limit ที่มีเอกสารระบุของ id ที่คุณกำลังเพิ่ม บันทึกแล้ว โมเดลจะปรากฏในรายการของ provider เลือกได้จาก model dropdown ของทุกแอป ทำซ้ำ dialog สำหรับแต่ละ id ที่คุณต้องการ สองนาทีต่อโมเดล ครั้งเดียว

Model Type:                LLM
Model Name:                claude-sonnet-4-6
API Key:                   sk-YOUR-APISROUTER-KEY
API Base URL:              https://api.apisrouter.com/v1
Completion mode:           Chat
Model context size:        200000
Upper bound for max tokens: 64000

Dify คุยกับ compatible provider อย่างไร

Dify (langgenius บน GitHub มีดาวประมาณ 149K) คือแพลตฟอร์มแอป LLM open-source ชั้นนำ: workflow แบบภาพ, agent node, RAG pipeline บน knowledge base และแอปที่เผยแพร่แล้วพร้อม API endpoint ของตัวเอง ทุก LLM node ใน stack นั้นแก้ปัญหาไปที่โมเดลที่ลงทะเบียนไว้ใต้ provider ใดตัวหนึ่ง provider OpenAI-API-compatible ตั้งใจให้ทั่วไป โมเดลแต่ละตัวที่คุณเพิ่มเป็น record ที่ครบในตัวเอง: id, endpoint, key, limit และ Dify ส่ง chat-completions request มาตรฐานไปยัง base url ที่ตั้งค่าไว้ โดยมี Model Name ของคุณเป็น model string ไม่มีอะไรใน request สนใจว่า vendor ไหนเทรนโมเดล ดังนั้น claude-sonnet-4-6 และ deepseek-v4-pro ใช้ได้ที่นี่พอ ๆ กับ id ของ GPT ใด ๆ และโมเดลต่างกันยังชี้ไปที่ endpoint ต่างกันได้ ถ้าคุณต้องการแบบนั้น การลงทะเบียนต่อโมเดลที่ดูเหมือนความยุ่งยากก็คือพื้นผิวควบคุมด้วย: ค่า context size และ max-tokens ที่คุณใส่คือสิ่งที่ orchestrator ของ Dify ใช้จัดงบ prompt, ตัดประวัติแชท และตรวจสอบการตั้งค่า node ใส่ตัวเลขที่ตรงความจริงจากเอกสารของโมเดล การตั้ง context เกินจริงจะทำให้ request ถูก endpoint ปฏิเสธ การตั้งต่ำไปจะตัด context ที่ RAG node ของคุณทำงานหนักเพื่อ retrieve มาอย่างเงียบ ๆ

ฟิลด์ที่ทำงานจริง

Model Name คือค่าที่วิ่งบนสาย: ต้องตรงกับรายการ /v1/models ของ gateway ทุกตัวอักษร เพราะมันเดินทางไปกับทุก request ชื่อแสดงผลของโมเดลที่เป็นตัวเลือกแค่เปลี่ยน label บน UI เท่านั้น Completion mode ควรอยู่ที่ Chat สำหรับทุกโมเดลในแคตตาล็อกปัจจุบัน ตัวเลือก Completion มีไว้สำหรับ endpoint text-completion แบบเก่าและจะสร้าง request ที่ผิดรูปกับโมเดลแชท Model context size และ Upper bound for max tokens คือคู่ที่คนมักรีบข้าม Context size คือ window ทั้งหมดของโมเดล upper bound จำกัดว่า node ขอ output token ได้กี่ตัว Dify ตั้งค่าเริ่มต้นทั้งสองไว้ที่ 4096 ซึ่งต่ำกว่าที่โมเดลปัจจุบันรองรับมาก การปล่อยค่าเริ่มต้นไว้จะทำให้ RAG เอกสารยาวและงานสร้างข้อความยาวพิการอย่างเงียบ ๆ ตั้งค่าจากเอกสารของโมเดล ไม่ใช่จากความเคยชิน ตัวเลือก capability มีความสำคัญเมื่อแอปของคุณใช้มัน: Vision Support สำหรับ id ที่รับ input รูปภาพเท่านั้น และการตั้งค่า function-call ต้องตรงกับความสามารถใช้ tool ของโมเดล เพราะ agent node พึ่งพามัน การอ้าง capability ผิดจะล้มเหลวตอนรันข้างใน workflow ซึ่งเป็นที่ที่ debug ยากกว่า dialog นี้ ถ้า workspace ของคุณใช้โมเดล embedding หรือ rerank ด้วย provider เดียวกันจะลงทะเบียนพวกมันใต้ Model Type ของตัวเองต่อ base url เดียวกัน ยืนยันว่า id เฉพาะเหล่านั้นถูกเสิร์ฟจาก endpoint ก่อนเชื่อมต่อการตั้งค่า knowledge base เข้ากับมัน

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# register these ids verbatim as Model Name entries

เลือกโมเดลสำหรับ workflow และ agent

หน้า overview ของ Dify เองแสดง token ต่อแอป แต่มุมมอง usage ต่อ key ใน console ของ APIsRouter เพิ่มการแบ่งต่อโมเดลข้ามทุกแอปในหน้าเดียว ซึ่งเป็นตัวเลขที่ตัดสินว่า id ไหนควรเก็บตำแหน่งไว้

• LLM node ของ workflow คืองานปริมาณ: การจัดหมวด, การดึงข้อมูล, การ routing, step สรุปที่ทำงานทุกครั้งที่รัน claude-haiku-4-5-20251001, gpt-5.4-mini และ gemini-3.5-flash ทำให้ต้นทุนต่อการรันคงที่
• agent node และ step reasoning ที่ซับซ้อนสมควรได้ claude-sonnet-4-6 และ tool use ที่เชื่อถือได้ของมันมีความสำคัญใน agent มากกว่าคะแนน benchmark ดิบ
• RAG answer node แบก context ที่ retrieve มาในทุกการเรียก ดังนั้นราคา input ครอบงำ deepseek-v4-pro คุ้มค่าที่จะทดสอบตรงที่ retrieval หนักและคำตอบยาว
• ลงทะเบียน id ที่เร็วและ id ที่แข็งแกร่งสำหรับบทบาทเดียวกัน แล้ว A/B ต่อ node: ใน Dify การสลับโมเดลของ node เป็นแค่ dropdown ไม่ใช่การย้ายระบบ
• แอปที่เผยแพร่แล้วรับช่วงการเลือกโมเดลของ node ของมัน ดังนั้นการตัดสินใจใน dropdown ที่คุณทำใน editor คือเศรษฐศาสตร์หน่วยของแอปที่คุณส่งออกไป

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

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

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

Provider ไม่อยู่ในรายการหมายความว่า plugin ยังไม่ได้ติดตั้ง: ตั้งแต่ Dify 1.0 provider OpenAI-API-compatible มาในรูปแบบ Marketplace plugin และ instance self-hosted ใหม่เริ่มต้นโดยไม่มีมัน ติดตั้งครั้งเดียวต่อ workspace โมเดลที่บันทึกได้แต่ error ตอนใช้ครั้งแรกมักเป็นหนึ่งในสามอย่าง: Model Name ที่ไม่ตรงกับการสะกดในแคตตาล็อก, base url ที่ขาด /v1 (Dify เติม route path อย่าง /chat/completions ต่อท้ายสิ่งที่คุณใส่) หรือค่า context/max-token ที่เกินกว่าที่โมเดลยอมรับ error ปรากฏใน log ของแอปหรือ workflow; การแก้ไขอยู่ที่ dialog Add Model agent node ล้มเหลวในขณะที่ chat node ธรรมดาทำงานได้ชี้ไปที่การตั้งค่า capability function-calling หรือโมเดลที่ tool use ไม่ตรงกับสิ่งที่ agent strategy คาดหวัง ทดสอบ agent กับ claude-sonnet-4-6 ก่อนเพื่อแยกปัญหาการตั้งค่าออกจากการเลือกโมเดล และบน instance self-hosted ที่มี egress rule เข้มงวด จำไว้ว่า container api ของ Dify ต่างหากที่ต้องเข้าถึง endpoint ได้ ไม่ใช่ browser ของคุณ; curl จากข้างใน container นั้นตอบคำถามเรื่องการเชื่อมต่อได้เร็ว

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

• ทีมที่สร้างแอป LLM ที่ต้องการให้เลือก Claude, GPT, Gemini และ DeepSeek ได้ต่อ node โดยไม่ต้องดูแลบัญชี vendor ต่อ provider
• self-hoster ที่รัน Dify สำหรับเครื่องมือภายใน โดย key เดียวใน provider เดียวเก็บค่าใช้จ่าย cloud ของ workspace ทั้งหมดไว้ใน usage log เดียว
• builder ที่เปรียบเทียบโมเดลบน workflow จริง: ผู้เข้าแข่งขันแต่ละรายเป็นแค่ dialog Add Model กับการสลับ dropdown ไม่ใช่การเชื่อมต่อระบบใหม่
• นักพัฒนาที่ไม่มีสิทธิ์เข้าถึงระบบเก็บเงินของ vendor รายหนึ่ง การเข้าถึงแบบเติมเงินโดยไม่ต้องใช้บัตรตัดการพึ่งพาการสมัครต่อ provider ออกไป
• เอเจนซี่ที่ส่งมอบแอปให้ลูกค้าบน Dify ที่ต้องการ key ต่อโปรเจกต์เพื่อให้ค่าใช้จ่ายโมเดลของลูกค้าแต่ละรายรายงานตัวเอง

ตรวจสอบ endpoint และ debug การรันแรก

Curl รายการโมเดลก่อนแล้วลงทะเบียน id จาก output ของมัน; Model Name ที่พิมพ์เองเป็นสาเหตุอันดับหนึ่งของ error not-found เพราะฟิลด์นี้เป็น free text จากนั้นรัน chat completion หนึ่งครั้งกับ id ที่คุณลงทะเบียน ด้วย key เดียวกัน ข้างใน Dify ทดสอบในแอปทดลองก่อนเชื่อมต่อ production workflow: เพิ่ม LLM node เลือกโมเดลใหม่ รันหนึ่งครั้ง Authentication error ชี้ไปที่ฟิลด์ API Key; not-found ชี้ไปที่ Model Name; connection error ชี้ไปที่ base url หรือ container egress; length error ชี้ไปที่ค่า context และ max-token เมื่อการรันไหลลื่นแล้ว console ของ APIsRouter แสดงโมเดลต่อ request, จำนวน token และค่าใช้จ่าย workflow คูณจำนวนการเรียก LLM ในแบบที่กะด้วยตาจาก editor ยาก และ usage log คือที่ที่ profile token จริงของ pipeline ห้า node ปรากฏชัด ต่อโมเดล ต่อวัน

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

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