การเชื่อมต่อ hy4 กับ Ollama: นำ Hunyuan ในเครื่องเข้ากับ Dify, Cursor และ client ที่เข้ากันได้กับ OpenAI ทุกตัว
หลังจากรัน hy4 แล้ว คำถามประจำวันคือเครื่องมือของคุณเรียกมันได้หรือไม่ บทความนี้ครอบคลุมการนำเข้า GGUF ในเครื่องเข้า Ollama ด้วย Modelfile การให้บริการ การตั้งค่า Dify, Cursor, Open WebUI และปลั๊กอินตัวแก้ไข การทำงานร่วมกันระหว่างในเครื่องกับคลาวด์ พร้อมข้อผิดพลาดที่พบบ่อย
การเชื่อมต่อ hy4 กับ Ollama: นำ Hunyuan ในเครื่องเข้ากับ Dify, Cursor และ client ที่เข้ากันได้กับ OpenAI ทุกตัว
การรัน hy4 ให้ทำงานได้เป็นเพียงครึ่งหนึ่งของปัญหา เพราะสิ่งที่กระทบประสบการณ์รายวันคือคำถามว่าเครื่องมือของคุณเรียกมันได้หรือไม่ คุณค่าของ Ollama อยู่ที่มันมีการจัดการโมเดลและ endpoint ที่เข้ากันได้กับ OpenAI มาให้พร้อม ทำให้ Dify, Cursor, Open WebUI และปลั๊กอินตัวแก้ไขเข้าใจมันทันทีโดยไม่ต้องเขียนโค้ดแปล บทความนี้จะไปทีละขั้น: จากการนำเข้า GGUF ในเครื่อง ไปสู่การให้บริการ การตั้งค่า client และการแก้ปัญหา
สรุปใน 30 วินาที
นำเข้า GGUF ในเครื่องเข้า Ollama ด้วย ollama create พร้อม Modelfile ให้บริการที่พอร์ต 11434 จากนั้นชี้ client ไปที่ http://127.0.0.1:11434/v1 ด้วย api_key อะไรก็ได้ และตรวจสอบด้วยรายการโมเดล Dify, Cursor และ Open WebUI ใช้โปรโตคอลที่เข้ากันได้กับ OpenAI ทั้งหมด ดังนั้นนี่คืองานการตั้งค่า ไม่ใช่การทำ integration ที่ซับซ้อน
ขั้นตอนที่หนึ่ง: เตรียมน้ำหนัก GGUF
mkdir -p ~/models && cd ~/models
huggingface-cli download bartowski/tencent_Hunyuan-4B-Instruct-GGUF \
Q4_K_M.gguf --local-dir .
ls -lh
ทำไมควรใช้ GGUF จากชุมชนแทน quantization อย่างเป็นทางการ
รุ่นอย่างเป็นทางการคือ FP8, GPTQ-Int4 และ AWQ-Int4 ซึ่งต้องการ stack การบริการแบบ vLLM Ollama และ llama.cpp เดินทางด้วยเส้น GGUF ดังนั้นการ deploy ในเครื่องจึงใช้งานที่แปลงจากชุมชนที่สั้นที่สุด bartowski มี coverage ของ quantization กว้างที่สุดและยอดดาวน์โหลดสูงสุด จึงเป็นตัวเริ่มต้นที่ปลอดภัย
ขั้นตอนที่สอง: สร้างโมเดลใน Ollama
cat > ~/models/Modelfile <<'EOF'
FROM ./Q4_K_M.gguf
TEMPLATE """{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}{{ if .Prompt }}<|im_start|>user
{{ .Prompt }}<|im_end|>
{{ end }}<|im_start|>assistant
"""
PARAMETER num_ctx 8192
PARAMETER temperature 0.7
PARAMETER top_p 0.8
PARAMETER stop "<|im_end|>"
EOF
cd ~/models && ollama create hy4-local -f Modelfile
ollama list
TEMPLATE ต้องคัดลอกจาก model card
นี่คือกับดักที่ซ่อนที่สุดเวลา deploy ในเครื่อง: โมเดลโหลดได้ ให้ token ได้ แต่คุณภาพคำตอบไม่ดีและดูเหมือนโมเดลอ่อน สาเหตุเกือบทั้งหมดคือเทมเพลตการสนทนาไม่ตรง เพราะเทมเพลตของ Hunyuan ไม่เหมือนกันระหว่างรุ่น ให้คัดลอกจากส่วน Usage ของ model card ที่ตรงกัน และต้องใส่พารามิเตอร์ stop ด้วย มิฉะนั้นโมเดลจะไม่หยุดพูด
ขั้นตอนที่สาม: ให้บริการและตรวจสอบ
# รันแบบ foreground แล้วเปิดอีก terminal สำหรับคำสั่งตรวจสอบ
ollama serve
# ตรวจสอบ API ดั้งเดิมจากอีก terminal
curl http://127.0.0.1:11434/api/chat -d '{
"model": "hy4-local",
"messages": [{"role": "user", "content": "อธิบายฐานข้อมูลเวกเตอร์ในหนึ่งประโยค"}],
"stream": false
}'
ตรวจสอบ surface ที่เข้ากันได้กับ OpenAI:
# รายการโมเดล
curl http://127.0.0.1:11434/v1/models
# สนทนา
curl http://127.0.0.1:11434/v1/chat/completions -H 'Content-Type: application/json' -d '{
"model": "hy4-local",
"messages": [{"role": "user", "content": "เขียนฟังก์ชัน Python วิเคราะห์เวลาแบบ ISO 8601"}]
}'
สอง API สองงานต่างกัน
/api/chat คือ endpoint ดั้งเดิมของ Ollama และรองรับส่วนขยายเช่น think และ images /v1/* คือ surface ที่เข้ากันได้กับ OpenAI สำหรับเครื่องมือบุคคลที่สาม เวลาต่อเครื่องมือให้ใช้ /v1 เท่านั้น และเฉพาะเมื่อต้องการความสามารถเฉพาะของ Ollama เช่น การส่งภาพให้โมเดลหลายโมดาเลติ คุณจึงใช้ API ดั้งเดิม
ขั้นตอนที่สี่: เชื่อมต่อ client ที่เข้ากันได้กับ OpenAI
from openai import OpenAI
client = OpenAI(
base_url="http://127.0.0.1:11434/v1",
api_key="ollama", # ค่า placeholder เพราะ Ollama ไม่ตรวจสอบ
)
resp = client.chat.completions.create(
model="hy4-local",
messages=[{"role": "user", "content": "สวัสดี"}],
)
print(resp.choices[0].message.content)
ขั้นตอนที่ห้า: เชื่อมต่อเครื่องมือเฉพาะ
Dify
ใน Settings, Model Providers, OpenAI-API-compatible ให้ใส่ API Base URLhttp://127.0.0.1:11434/v1, API Keyollamaและชื่อโมเดลhy4-localโปรดทราบว่าเมื่อ Dify ทำงานใน Docker แล้ว127.0.0.1จะชี้ไปที่ตัว container เอง ดังนั้นต้องใช้ IP หรือชื่อ service ของเครื่องโฮสต์Cursor
เปิดส่วน Models ในการตั้งค่า Cursor เพิ่มโมเดลผ่านผู้ให้บริการ OpenAI ตั้ง Base URL เป็นที่อยู่ในเครื่อง และใช้hy4-localเป็นชื่อโมเดล การรองรับ local endpoint ของ Cursor เปลี่ยนตามเวอร์ชัน และการพิมพ์ชื่อโมเดลเองยังทำงานเมื่อการค้นพบอัตโนมัติล้มเหลวOpen WebUI
ใน Admin Settings, Connections, OpenAI ให้ใส่ที่อยู่เดียวกัน จากนั้นเปิดใช้hy4-localในส่วน Models โปรดทราบว่า Open WebUI ที่ทำงานใน container ต้องเรียกเครื่องโฮสต์ผ่านhost.docker.internalแทน127.0.0.1ปลั๊กอินตัวแก้ไขเช่น Continue และ Cline
ในการตั้งค่าโมเดลของปลั๊กอิน ให้เลือกผู้ให้บริการ OpenAI และใส่ base URL กับชื่อโมเดลในเครื่อง ปลั๊กอินเหล่านี้ส่วนใหญ่มีตัวเลือก local models หรือ custom provider ซึ่งให้ผลที่สะอาดกว่าการแก้การตั้งค่าทั่วทั้งระบบ
เครือข่าย Docker คือจุดที่ล้มเหลวบ่อยที่สุด
เมื่อเครื่องมือทำงานใน container แล้ว localhost จะชี้ไปที่ตัว container นั้นเอง มีวิธีแก้สองทาง: เพิ่ม extra_hosts: ["host.docker.internal:host-gateway"] ในไฟล์ compose แล้วใช้ host.docker.internal:11434 หรือให้ Ollama ฟัง 0.0.0.0:11434 ด้วย OLLAMA_HOST=0.0.0.0 ollama serve ทางเลือกหลังทำให้โมเดลของคุณเข้าถึงได้จากทั้งเครือข่ายภายใน ดังนั้นควรเพิ่มการควบคุมการเข้าถึงก่อนใช้
ขั้นตอนที่หก: ในเครื่องกับคลาวด์ทำงานร่วมกัน
หลายทีมใช้ hy4 ในเครื่องและโมเดลบนคลาวด์พร้อมกัน วิธีทำคือการตั้งค่า endpoint ต่างกันให้แต่ละเครื่องมือ หรือการ routing ภายใน client:
import os
def pick_client(task: str):
if task in {"classify", "rewrite", "summarize"}:
return OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")
return OpenAI(base_url="https://exaiv.com/api/ai/v1", api_key=os.environ["EXAIV_KEY"])
อย่าใช้ชื่อโมเดลสลับกัน
ชื่อโมเดลในเครื่องคือ hy4-local ซึ่งคุณตั้งเอง ในขณะที่ ID ของโมเดลบนคลาวด์คือ ID จริงที่มีอยู่ในแคตตาล็อก เช่น kimi-k3 เมื่อใส่ชื่อโมเดลผิด อาการมักเป็น "ไม่พบโมเดล" มากกว่า "เชื่อมต่อไม่ได้" ดังนั้นเวลาดีบักให้ตรวจชื่อก่อน แล้วค่อยมาดูเรื่องเครือข่าย
ตารางแก้ปัญหา
| อาการ | สาเหตุ | วิธีจัดการ |
|---|---|---|
| ผลลัพธ์แปลก ๆ หรือไม่ตรงคำถาม | เทมเพลตการสนทนาผิด | แก้ TEMPLATE และ stop ตาม model card |
| การเชื่อมต่อถูกปฏิเสธ | บริการยังไม่ทำงาน หรือไม่ใช่พอร์ต 11434 | รัน ollama serve แล้วตรวจสอบพอร์ตด้วย curl |
| เชื่อมต่อจาก Docker ไม่ได้ | การแยกเครือข่ายของ container | ใช้ host.docker.internal หรือฟัง 0.0.0.0 |
| คำตอบถูกตัดกลางคัน | บริบทไม่พอ หรือ max_tokens เล็กเกินไป | เพิ่ม num_ctx และ max_tokens |
| ข้อผิดพลาดชื่อโมเดล | ใช้ ID ของคลาวด์ หรือพิมพ์ผิด | ดู ollama list เพื่อดึงชื่อจริง |
| การเรียกครั้งแรกช้ามาก | โมเดลกำลังโหลดเข้าหน่วยความจำ | เป็นเรื่องปกติ การเรียกครั้งถัดไปจะเร็วขึ้น |
| หน่วยความจำไม่พอ | num_ctx ใหญ่เกินไป | ลดบริบท เพราะ KV cache โตตามเส้นตรง |
FAQ
ควรเลือก Ollama หรือ llama.cpp?
หา TEMPLATE สำหรับ Modelfile ได้จากไหน?
Dify ใน Docker เรียก Ollama บนเครื่องโฮสต์อย่างไร?
ให้บริการ Ollama ออกสู่ภายนอกได้ไหม?
เรียก Hunyuan ผ่าน API ของ EXAIV ได้ไหม?
อ่านต่อ
- hy4 GGUF local deployment — ระดับ quantization การคำนวณหน่วยความจำ และคำสั่ง llama.cpp
- Open WebUI กับ Hunyuan ในเครื่อง — การตั้งค่าส่วนติดต่อแชทแบบ self-hosted
- RAG กับ hy4 — การต่อ endpoint ในเครื่องเข้ากับฐานความรู้
- Dify integration — การต่อโมเดลคลาวด์เข้ากับ Dify
- Open WebUI integration — การต่อโมเดลคลาวด์เข้ากับส่วนติดต่อแบบ self-hosted
- คู่มือเลือกโมเดล hy4 — ขนาดต่าง ๆ และที่ของ A13B
แหล่งข้อมูล
รายการคลังและระดับ quantization จะเปลี่ยนตามการอัปเดตของชุมชน บทความนี้สะท้อนสถานะ ณ เวลาเก็บตัวอย่าง