ข้ามไปยังเนื้อหาหลัก

บทช่วยสอน SGLang: ให้บริการ Mistral Medium 3.5 แบบโลคอล

ตั้งค่าสภาพแวดล้อม Docker แบบหลาย GPU พร้อม tensor parallelism และ EAGLE speculative decoding เพื่อให้บริการ Mistral Medium 3.5 128B ผ่าน API ที่เข้ากันได้กับ OpenAI
อัปเดตแล้ว 1 มิ.ย. 2569  · 12 นาที อ่าน

การรันโมเดลภาษาขนาดใหญ่แบบโลคอลไม่จำกัดอยู่แค่โมเดลขนาดเล็กอย่าง 7B หรือ 13B อีกต่อไป ด้วยการตั้งค่า GPU ที่เหมาะสม เฟรมเวิร์กสำหรับให้บริการ และสภาพแวดล้อมแบบคอนเทนเนอร์ ปัจจุบันสามารถรันโมเดลเปิดระดับแนวหน้าอย่าง Mistral Medium 3.5 128B บนเซิร์ฟเวอร์ GPU ของตนเองได้แล้ว

คู่มือนี้จะอธิบายทีละขั้นตอนว่าจะแบบให้บริการ Mistral Medium 3.5 128B แบบโลคอลด้วย SGLang อย่างไร โดยใช้เซิร์ฟเวอร์หลาย GPU, Docker, การเข้าถึงโมเดลบน Hugging Face และเซิร์ฟเวอร์ API ของ SGLang ที่เข้ากันได้กับ OpenAI 

เราจะเริ่มจากการเตรียมอินสแตนซ์ GPU แบบ 4× H100 จากนั้นติดตั้ง Docker และ NVIDIA container runtime ดึงอิมเมจ Docker ของ SGLang เปิดใช้งานเซิร์ฟเวอร์โมเดล ทดสอบเอ็นด์พอยน์ต์ด้วย curl และสุดท้ายเชื่อมต่อโมเดลโลคอลเข้ากับ OpenCode สำหรับเวิร์กโฟลว์ของเอเจนต์ด้านโค้ด นอกจากนี้เราจะทดสอบการตั้งค่า EAGLE speculative decoding เพื่อเปรียบเทียบประสิทธิภาพและดูว่าได้ผลเรื่องระยะหน่วงสำหรับอินเฟอเรนซ์โลคอลหรือไม่ 

เมื่อจบคู่มือนี้ จะมีเอ็นด์พอยน์ต์โลคอลสำหรับ Mistral Medium 3.5 ที่เข้าถึงได้ผ่าน API ที่เข้ากันได้กับ OpenAI

SGLang คืออะไร?

SGLang เป็นเฟรมเวิร์กสำหรับให้บริการ LLM ประสิทธิภาพสูง ออกแบบมาสำหรับอินเฟอเรนซ์โมเดลขนาดใหญ่ การสร้างผลลัพธ์แบบมีโครงสร้าง เวิร์กโหลดบริบทยาว และการให้บริการแบบหลาย GPU 

ในคู่มือนี้ เราใช้เพื่อให้บริการ Mistral Medium 3.5 128B ผ่าน API ที่เข้ากันได้กับ OpenAI เพื่อให้โมเดลใช้งานร่วมกับ curl, Python, OpenCode หรือเครื่องมือเอเจนต์อื่น ๆ ได้

SGLang เหมาะสมกว่า llama.cpp ในกรณีนี้ เพราะเราไม่ได้รันโมเดล GGUF ขนาดเล็กบนแล็ปท็อป แต่กำลังให้บริการโมเดล dense ขนาด 128B บน 4 H100 GPUs ด้วย tensor parallelism บริบทยาว และการให้บริการ GPU ผ่าน Docker llama.cpp เหมาะมากสำหรับอินเฟอเรนซ์โลคอลแบบง่ายและโมเดลควอนไทซ์ แต่ SGLang เหมาะกว่าสำหรับการให้บริการ API ขนาดใหญ่แบบหลาย GPU

เมื่อเทียบกับ vLLM ข้อดีไม่ได้อยู่ที่ SGLang มีฟีเจอร์พื้นฐานที่ vLLM ไม่มี เพราะ vLLM เองก็เป็นเอนจินให้บริการระดับโปรดักชันที่แข็งแกร่ง พร้อม PagedAttention, continuous batching, prefix caching และ speculative decoding 

เหตุผลที่ SGLang เข้ากับคู่มือนี้คือมันโดดเด่นเป็นพิเศษสำหรับ การสร้างผลลัพธ์แบบมีโครงสร้าง เวิร์กโฟลว์เอเจนต์ที่พึ่งพา prefix มาก และ การทดลอง speculative decoding ต่าง ๆ รันไทม์ของมันโฟกัสที่ RadixAttention เพื่อการใช้ prefix ซ้ำ ผลลัพธ์แบบมีโครงสร้าง tensor parallelism และ EAGLE-style speculative decoding ซึ่งตรงกับสิ่งที่เราทดสอบกับ Mistral Medium 3.5 EAGLE

ดังนั้นมุมมองการใช้งานจริงจึงประมาณนี้: 

  • llama.cpp สำหรับอินเฟอเรนซ์โลคอลแบบเบา
  • vLLM สำหรับการให้บริการทั่วไปในโปรดักชัน
  • SGLang เมื่ออยากได้การให้บริการแบบหลาย GPU ขั้นสูงสำหรับเวิร์กโหลดบริบทยาว แบบมีโครงสร้าง เชิงเอเจนต์ หรือ speculative decoding

สำหรับคำแนะนำเปรียบเทียบ SGLang กับทางเลือกอื่น แนะนำให้อ่านบทช่วยสอนของเราเกี่ยวกับ llama.cpp และ vLLM

ขั้นตอนที่ 1: ตั้งค่าฮาร์ดแวร์

สำหรับคู่มือนี้ ฉันใช้เครื่องเสมือน GPU แบบ 4× H100 80GB Mistral Medium 3.5 เป็นโมเดล dense ขนาด 128B จึงต้องใช้การตั้งค่าหลาย GPU SGLang แนะนำให้รันด้วย tensor parallelism โดยใช้ --tp 4 บน GPU รุ่น H100 หรือ H200 โมเดลรองรับหน้าต่างบริบทขนาดใหญ่ แต่ขอแนะนำให้เริ่มจาก 100,000 โทเค็น ก่อน แทนที่จะใช้ 256K เต็ม เพื่อให้ง่ายต่อการทดสอบและดีบัก

ฉันใช้ Hyperbolic เพราะให้เข้าถึง VM ที่มี GPU เต็มรูปแบบ ทำให้ติดตั้ง Docker ตั้งค่า NVIDIA container runtime และรันอิมเมจ Docker ของ SGLang ด้วยตนเองได้ง่าย คุณยังสามารถใช้แพลตฟอร์มอย่าง RunPod หรือ Vast.ai ได้ แต่บางอินสแตนซ์ของพวกเขาผูกกับสภาพแวดล้อม Docker แบบกำหนดเองอยู่แล้ว ซึ่งทำให้ควบคุมน้อยลง

ใน Hyperbolic ให้เลือก H100 PCIe 80GB เลือก 4 GPUs เพิ่มพื้นที่เก็บข้อมูลประมาณ 3TB ป้อน SSH public key และตั้งชื่ออินสแตนซ์ เช่น MM-35 ฉันเลือก H100 PCIe เพราะเป็นตัวเลือก H100 ที่ถูกที่สุดสำหรับการทดสอบนี้ 

ตั้งค่า VPS GPU 4X H100 ใน Hyperbolic

หลังจากคลิก Start Building เครื่องอาจใช้เวลาประมาณ 10 นาทีในการเริ่มทำงาน เมื่อพร้อมแล้ว Hyperbolic จะแสดงคำสั่ง SSH สำหรับขั้นตอนถัดไป

อินสแตนซ์ VPS GPU 4X H100 ของ Hyperbolic กำลังทำงานและสามารถเข้าถึงได้ด้วย ssh

ขั้นตอนที่ 2: SSH เข้าสู่เซิร์ฟเวอร์

เมื่ออินสแตนซ์พร้อมแล้ว ให้เชื่อมต่อจากเทอร์มินัลโลคอลด้วยคำสั่ง SSH ที่แสดงในแดชบอร์ด Hyperbolic:

ssh ubuntu@XXXXXX

เพื่อเข้าถึง SGLang API จากเครื่องโลคอลภายหลัง สามารถทำพอร์ตฟอร์เวิร์ด 30000 ได้เช่นกัน:

ssh -L 30000:localhost:30000 ubuntu@XXXXXX

หากคีย์ SSH มีพาสเฟรส ให้ป้อนเมื่อระบบร้องขอ หลังจากล็อกอินแล้ว ตรวจสอบว่า GPU ทั้งหมดพร้อมใช้งาน:

Nvidia-smi

ควรเห็น GPU NVIDIA H100 PCIe 80GB จำนวน 4 ตัวอยู่ในรายการ แสดงว่าเซิร์ฟเวอร์พร้อมสำหรับการตั้งค่า Docker และ SGLang แล้ว

แสดงรายการ GPU NVIDIA H100 PCIe 80GB จำนวน 4 ตัว

ขั้นตอนที่ 3: ติดตั้ง Docker บนเซิร์ฟเวอร์ Linux

ก่อนอื่น export โทเค็น Hugging Face เพื่อให้เซิร์ฟเวอร์ดาวน์โหลดโมเดล Mistral ได้ในภายหลัง:

echo 'export HF_TOKEN="your_huggingface_token_here"' >> ~/.bashrc
source ~/.bashrc

หมายเหตุ: สามารถรับโทเค็น Hugging Face ได้จากหน้า Access Tokens

สร้างโฟลเดอร์แคชของ Hugging Face:

mkdir -p ~/.cache/huggingface

ตอนนี้ติดตั้ง Docker:

sudo apt update
sudo apt install -y docker.io

สตาร์ท Docker และตั้งค่าให้รันอัตโนมัติหลังรีบูต:

sudo systemctl start docker
sudo systemctl enable docker

ตรวจสอบว่า Docker ติดตั้งถูกต้อง:

docker –version

สามารถใช้คำสั่งค้นหา Docker เพื่อตรวจสอบว่า Docker สามารถค้นหาอิมเมจสาธารณะจาก Docker Hub ได้:

docker search nvidia/cuda

ควรแสดงอิมเมจ NVIDIA CUDA ที่พร้อมใช้งาน ภายหลัง เราจะใช้อิมเมจ CUDA เหล่านี้ตัวใดตัวหนึ่งเพื่อตรวจสอบว่า Docker เข้าถึง GPU ได้

ถัดไป อนุญาตให้ผู้ใช้ของคุณรันคำสั่ง Docker โดยไม่ต้องใช้ sudo:

sudo usermod -aG docker $USER
newgrp docker

จากนั้นติดตั้งและตั้งค่า NVIDIA Container Toolkit เพื่อให้ Docker เข้าถึง GPU ได้:

distribution=$(. /etc/os-release;echo $ID$VERSION_ID)

curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add -

curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update
sudo apt install -y nvidia-container-toolkit

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

ท้ายสุด ทดสอบว่า Docker มองเห็น GPU ได้จากในคอนเทนเนอร์:

docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

หากแสดงรายการ GPU H100 เดิมภายในคอนเทนเนอร์ Docker แสดงว่าการตั้งค่า GPU ของ Docker ทำงานถูกต้อง

มี GPU NVIDIA H100 PCIe 80GB 4 ตัวพร้อมใช้งานใน Docker

ขั้นตอนที่ 4: ดึงอิมเมจ Docker ของ SGLang

ถัดไป ดึงอิมเมจ Docker ของ SGLang ที่สร้างมาสำหรับ Mistral Medium 3.5:

docker pull lmsysorg/sglang:dev-mistral-medium-3.5

กำลังดึงอิมเมจ docker lmsysorg/sglang:dev-mistral-medium-3.5

อาจใช้เวลาสักครู่ขึ้นอยู่กับความเร็วอินเทอร์เน็ต ในกรณีของฉันใช้เวลาประมาณ 10 นาที เมื่อดาวน์โหลดอิมเมจเสร็จ Docker จะแสดงข้อความสำเร็จคล้ายกับ:

Status: Downloaded newer image for lmsysorg/sglang:dev-mistral-medium-3.5

ขั้นตอนที่ 5: ให้บริการ Mistral Medium 3.5 128B ด้วย SGLang

ตอนนี้เริ่มเซิร์ฟเวอร์ SGLang:

docker run -d \
 --name mistral-sglang \
 --gpus all \
 --shm-size 64g \
 --ipc=host \
 --cap-add SYS_NICE \
 -p 30000:30000 \
 -v ~/.cache/huggingface:/root/.cache/huggingface \
 -e HF_TOKEN=$HF_TOKEN \
 -e PYTORCH_ALLOC_CONF=expandable_segments:True \
 lmsysorg/sglang:dev-mistral-medium-3.5 \
 sglang serve \
   --model-path mistralai/Mistral-Medium-3.5-128B \
   --served-model-name mistral-medium-3.5 \
   --host 0.0.0.0 \
   --port 30000 \
   --tp 4 \
   --trust-remote-code \
   --dtype bfloat16 \
   --context-length 100000 \
   --mem-fraction-static 0.85 \
   --disable-custom-all-reduce \
   --tool-call-parser mistral \
   --reasoning-parser mistral

ฉันใช้ --dtype bfloat16 เพราะการตั้งค่า EAGLE ภายหลังก็ต้องใช้ bf16 เช่นกัน จึงคงค่า dtype ให้ตรงกันทั้งรันพื้นฐานและรันแบบ speculative เพื่อลดการเปลี่ยน dtype ระหว่างการทดสอบ นอกจากนี้ฉันเริ่มด้วย --context-length 100000 แทนหน้าต่างบริบทยาวสุดเพื่อให้การรันครั้งแรกดีบักได้ง่าย

ตรวจสอบล็อกของคอนเทนเนอร์ด้วย:

docker logs -f mistral-sglang

กำลังดาวน์โหลด Mistral Medium 3.5 128B

การเปิดครั้งแรกจะใช้เวลานานกว่า เพราะ SGLang ต้องดาวน์โหลดไฟล์โมเดลจาก Hugging Face ที่เก็บทั้งชุดมีขนาดใหญ่ จึงอาจใช้เวลาประมาณชั่วโมงหนึ่งหรือมากกว่านั้น ขึ้นอยู่กับความเร็วของอินสแตนซ์

เมื่อเซิร์ฟเวอร์พร้อม ล็อกควรจะแสดงว่า Uvicorn กำลังรันบนพอร์ต 30000

เซิร์ฟเวอร์ SGLang พร้อมให้บริการโมเดล Mistral Medium 3.5 128B แล้ว

ในเทอร์มินัลอีกหน้าต่าง ให้ SSH เข้าสู่เซิร์ฟเวอร์อีกครั้งและตรวจสอบเอ็นด์พอยน์ต์ของโมเดล:

curl http://localhost:30000/v1/models

ควรเห็น mistral-medium-3.5 พร้อมค่า max_model_len เป็น 100000

{"object":"list","data":[{"id":"mistral-medium-3.5","object":"model","created":1779816738,"owned_by":"sglang","root":"mistral-medium-3.5","parent":null,"max_model_len":100000}]}

สุดท้าย ทดสอบการทำงานของแชต completion:

curl http://localhost:30000/v1/chat/completions \
 -H "Content-Type: application/json" \
 -d '{
   "model": "mistral-medium-3.5",
   "messages": [
     {
       "role": "user",
       "content": "Write a short introduction to Mistral Medium 3.5."
     }
   ],
   "max_tokens": 300,
   "temperature": 0.7,
   "top_p": 0.95
 }'

สร้างคำตอบจาก Mistral Medium 3.5 128B สำเร็จ

ในการทดสอบของฉัน โมเดลตอบกลับสำเร็จและประมวลผลคำขอได้อย่างเรียบร้อย ยืนยันว่าเอ็นด์พอยน์ต์ SGLang ทำงานแล้ว การรันพื้นฐานคร่าว ๆ ได้ประมาณ 35.6 โทเค็นต่อวินาที

ขั้นตอนที่ 6: รัน Mistral Medium 3.5 128B ด้วย EAGLE Speculative Decoding

Speculative decoding สามารถเร่งความเร็วการสร้างผลลัพธ์ด้วยการใช้โมเดลแบบร่างที่เล็กกว่าคาดเดาโทเค็นล่วงหน้า ขณะที่โมเดลหลักทำการยืนยัน 

EAGLE มีประโยชน์ในที่นี้เพราะออกแบบมาสำหรับการให้บริการที่ไวต่อระยะหน่วง โดยเฉพาะเมื่อรันโมเดลขนาดใหญ่แบบโลคอลอย่าง Mistral Medium 3.5 มันอาจไม่เร็วกว่าเสมอไป แต่ก็คุ้มค่าที่จะทดสอบ เพราะประโยชน์ขึ้นอยู่กับความยาวพรอมป์ ความยาวผลลัพธ์ ความขนานของคำขอ และการใช้งาน GPU

ก่อนอื่น ลบคอนเทนเนอร์พื้นฐาน:

docker rm -f mistral-sglang

จากนั้นเริ่มเวอร์ชัน EAGLE:

docker run -d \
 --name mistral-sglang-eagle \
 --gpus all \
 --shm-size 64g \
 --ipc=host \
 --cap-add SYS_NICE \
 -p 30000:30000 \
 -v ~/.cache/huggingface:/root/.cache/huggingface \
 -e HF_TOKEN="$HF_TOKEN" \
 -e PYTORCH_ALLOC_CONF=expandable_segments:True \
 lmsysorg/sglang:dev-mistral-medium-3.5 \
 sglang serve \
   --model-path mistralai/Mistral-Medium-3.5-128B \
   --served-model-name mistral-medium-3.5-eagle \
   --host 0.0.0.0 \
   --port 30000 \
   --tp 4 \
   --trust-remote-code \
   --dtype bfloat16 \
   --context-length 100000 \
   --mem-fraction-static 0.85 \
   --disable-custom-all-reduce \
   --tool-call-parser mistral \
   --reasoning-parser mistral \
   --enable-metrics \
   --speculative-algorithm EAGLE \
   --speculative-draft-model-path mistralai/Mistral-Medium-3.5-128B-EAGLE \
   --speculative-num-steps 3 \
   --speculative-eagle-topk 1 \
   --speculative-num-draft-tokens 4

SGLang แนะนำการตั้งค่า EAGLE นี้เป็นจุดเริ่มต้นที่ดี: --speculative-num-steps 3, --speculative-eagle-topk 1 และ --speculative-num-draft-tokens 4 การรันครั้งแรกอาจใช้เวลานานขึ้นเพราะต้องดาวน์โหลดโมเดลร่าง EAGLE ด้วย 

เมื่อโหลดเสร็จ สามารถตรวจสอบการใช้งาน GPU ด้วย nvidia-smi ในการรันของฉัน โมเดลใช้หน่วยความจำประมาณ 44GB ต่อ H100 GPU

เมื่อใช้โมเดลร่าง EAGLE SGLang ใช้หน่วยความจำ 44GB ต่อ H100 GPU

ติดตามล็อกด้วย:

docker logs -f mistral-sglang-eagle

กำลังให้บริการ Mistral Medium 3.5 128B พร้อม EAGLE

เมื่อเห็นในล็อกว่า Uvicorn กำลังรันบน 0.0.0.0:30000 ให้ทดสอบเอ็นด์พอยน์ต์:

curl http://localhost:30000/v1/chat/completions \
 -H "Content-Type: application/json" \
 -d '{
   "model": "mistral-medium-3.5-eagle",
   "messages": [
     {
       "role": "user",
       "content": "Generate a simple Python game."
     }
   ],
   "reasoning_effort": "none",
   "max_tokens": 300,
   "temperature": 0.7,
   "top_p": 0.95
 }'

การตอบกลับของโมเดล Mistral Medium 3.5 128B พร้อม EAGLE

ในการทดสอบของฉัน เซิร์ฟเวอร์ EAGLE ตอบกลับถูกต้องและสร้างเกม Python อย่างง่าย การรันได้ประมาณ 32 โทเค็นต่อวินาที ซึ่งช้ากว่ารันพื้นฐานเล็กน้อย ดังนั้น EAGLE ไม่ได้ช่วยในเคสนี้ 

นี่เป็นเรื่องปกติ: ประสิทธิภาพของ speculative decoding ขึ้นอยู่กับเวิร์กโหลด วิธีที่ดีที่สุดในการประเมินคือทดสอบด้วยพรอมป์และระดับ concurrency ของงานจริง

ขั้นตอนที่ 7: ตั้งค่า OpenCode กับ Mistral Medium 3.5

OpenCode เป็นเอเจนต์โค้ด AI แบบโอเพนซอร์สที่เชื่อมต่อกับเอ็นด์พอยน์ต์โมเดลที่เข้ากันได้กับ OpenAI ได้ เนื่องจาก SGLang เปิดให้ใช้งาน Mistral Medium 3.5 ผ่าน API แบบโลคอลที่เข้ากันได้กับ OpenAI เราจึงใช้มันใน OpenCode ได้โดยตรง

ติดตั้ง OpenCode หากยังไม่ได้ติดตั้ง:

curl -fsSL https://opencode.ai/install | bash

จากนั้นเข้าไปยังไดเรกทอรีโปรเจ็กต์และสร้างไฟล์ opencode.json

เพิ่มการตั้งค่าต่อไปนี้: 

{
 "$schema": "https://opencode.ai/config.json",
 "provider": {
   "sglang": {
     "npm": "@ai-sdk/openai-compatible",
     "name": "SGLang Local",
     "options": {
       "baseURL": "http://127.0.0.1:30000/v1",
       "apiKey": "EMPTY"
     },
     "models": {
       "mistral-medium-3.5-eagle": {
         "name": "Mistral Medium 3.5 EAGLE",
         "limit": {
           "context": 100000,
           "output": 8192
         }
       }
     }
   }
 },
 "model": "sglang/mistral-medium-3.5-eagle"
}

ตอนนี้เปิด OpenCode จากไดเรกทอรีโปรเจ็กต์เดียวกัน: 

Opencode

ควรเห็นว่าเลือก Mistral Medium 3.5 EAGLE SGLang Local อยู่ใน OpenCode ซึ่งหมายความว่า OpenCode กำลังสื่อสารกับเซิร์ฟเวอร์ SGLang โลคอลผ่านพอร์ตที่ฟอร์เวิร์ด 30000 เช่นเดียวกับการเรียก API ที่เข้ากันได้กับ OpenAI อื่น ๆ 

ใช้ Mistral Medium 3.5 128B พร้อม EAGLE ใน OpenCode แบบโลคอล

ในการทดสอบของฉัน ฉันให้ OpenCode อธิบายโปรเจ็กต์ มันอ่านไฟล์ในรีโพภายในไม่กี่วินาทีและสร้างสรุปออกมาได้ 

ทำความเข้าใจโปรเจ็กต์ใน OpenCode

ต่อมา ฉันให้มันสร้าง อีมูเลเตอร์ Badger 2040 ซึ่งมันตรวจสอบไฟล์โปรเจ็กต์ที่มีอยู่ก่อน ยืนยันโครงสร้าง และสร้างไฟล์ Python ที่ต้องการ กระบวนการทั้งหมดใช้เวลาประมาณ 2 นาที 

ขอให้ Mistral Medium 3.5 128B สร้างอีมูเลเตอร์ Badger 2040

หลังจากนั้น ฉันให้มันทดสอบอีมูเลเตอร์แบบโลคอล OpenCode รันโค้ดและเปิดหน้าต่างอีมูเลเตอร์ได้สำเร็จ 

ขอให้ Mistral Medium 3.5 128B ทดสอบอีมูเลเตอร์ Badger 2040

แบบอักษรไม่เหมือนกับจอจริงของ Badger 2040 เป๊ะ ๆ แต่เลย์เอาต์ การแสดงเวลา ตำแหน่งวันที่ และโครงสร้างโดยรวมถือว่าแทบสมบูรณ์แบบ 

image4.png

ฉันประทับใจผลลัพธ์จริง ๆ เพราะเคยลองงานเดียวกันกับ Claude Code และ GPT-5.5 มาก่อน และทั้งคู่ทำได้ยาก ขณะที่ Mistral Medium 3.5 จัดการได้ดีมากผ่านการตั้งค่า SGLang แบบโลคอลนี้ 

การแก้ปัญหาและบันทึกการตั้งค่า

มีจุดติดขัดอยู่บ้างระหว่างทาง ขออธิบายปัญหาที่อาจพบและแนวทางแก้ไข

1. ต้องใจเย็น: การตั้งค่านี้ใช้เวลา

ก่อนอื่นต้องใจเย็น ๆ การตั้งค่าทั้งหมดนี้ใช้เวลารวมเกือบ 3 ชั่วโมง การเปิดตัว VM ที่มี GPU ใช้เวลาราว 15 นาที การติดตั้ง Docker และ NVIDIA container toolkit ใช้เวลาประมาณ 10 นาที การดึงอิมเมจ Docker ของ SGLang ใช้เวลาราว 30 นาที และการดาวน์โหลดพร้อมโหลดเวทของโมเดล Mistral Medium 3.5 ใช้เวลาประมาณ 1 ชั่วโมง 

การเริ่มตั้งค่า EAGLE ก็ใช้เวลาเพิ่ม เพราะโหลดโมเดลอีกครั้งและอาจต้องดาวน์โหลดโมเดลร่าง EAGLE หากต้องการประสบการณ์ที่ลื่นไหลขึ้น ให้ใช้เครือข่ายที่เร็วกว่า GPU รุ่นใหม่กว่าอย่าง H200 หากมี และพื้นที่เก็บข้อมูลเพียงพอสำหรับแคช Hugging Face ทั้งหมด

อินสแตนซ์ GPU 4x H100 ทำงานเป็นเวลา 3 ชั่วโมง 14 นาที

2. Docker มองไม่เห็น GPU

หาก nvidia-smi ใช้ได้บนโฮสต์ แต่ Docker เข้าถึง GPU ไม่ได้ แสดงว่า NVIDIA container runtime อาจยังไม่ถูกตั้งค่าอย่างถูกต้อง ให้รันการตั้งค่า NVIDIA container toolkit ใหม่และรีสตาร์ท Docker:

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

เอกสารของ NVIDIA ยังแนะนำขั้นตอนตั้งค่า runtime ด้วย nvidia-ctk สำหรับการเข้าถึง GPU ของ Docker

3. โมเดลถูกดาวน์โหลดซ้ำ

ตรวจสอบให้แน่ใจว่าได้เมานต์แคชของ Hugging Face เข้าไปในคอนเทนเนอร์:

-v ~/.cache/huggingface:/root/.cache/huggingface

นี่ช่วยให้ Docker ใช้ไฟล์โมเดลที่ดาวน์โหลดไว้แล้วซ้ำ แทนที่จะดาวน์โหลดใหม่ทุกครั้ง Hugging Face ใช้แคชโลคอลเพื่อหลีกเลี่ยงการดาวน์โหลดไฟล์ที่เป็นเวอร์ชันล่าสุดอยู่แล้ว

4. ดาวน์โหลดช้าหรือค้าง

รีโพของ Mistral Medium 3.5 มีขนาดใหญ่ ดังนั้นการดาวน์โหลดครั้งแรกอาจใช้เวลานาน หากดูเหมือนค้าง ให้ตรวจสอบความเร็วอินเทอร์เน็ต พื้นที่ดิสก์ และโทเค็น Hugging Face ตรวจสอบด้วยว่าคุณยอมรับเงื่อนไขการเข้าถึงโมเดลที่จำเป็นบน Hugging Face แล้วก่อนรันคอนเทนเนอร์

5. API endpoint ไม่ตอบสนอง

เซิร์ฟเวอร์ยังไม่พร้อมจนกว่าล็อกจะแสดงว่า Uvicorn กำลังรันบนพอร์ต 30000 ตรวจสอบล็อกด้วย:

docker logs -f mistral-sglang

หรือสำหรับ EAGLE:

docker logs -f mistral-sglang-eagle

ตรวจสอบด้วยว่าคอนเทนเนอร์เปิดพอร์ตถูกต้องด้วย:

-p 30000:30000

6. EAGLE ไม่เร็วกว่าแบบพื้นฐาน

เป็นเรื่องปกติ Speculative decoding ไม่ได้การันตีว่าจะเร็วขึ้นทุกคำขอ มันทำงานโดยใช้โมเดลแบบร่างเสนอโทเค็น และโมเดลหลักยืนยัน แต่ความเร็วที่เพิ่มขึ้นขึ้นอยู่กับอัตราการยอมรับ ความยาวพรอมป์ ความยาวผลลัพธ์ ระดับ concurrency และการใช้ GPU

7. หน่วยความจำไม่พอ

หากเจอปัญหาหน่วยความจำ ให้ลดความยาวบริบทก่อน เช่น เริ่มที่ --context-length 100000 แทนที่จะลองค่าหน้าต่างบริบทยาวสุดทันที นอกจากนี้อาจลดค่า --mem-fraction-static ลงเล็กน้อยหากสตาร์ทไม่ขึ้น แต่โดยทั่วไปการลดความยาวบริบทเป็นขั้นตอนแรกที่ง่ายที่สุด

8. OpenCode เชื่อมต่อโมเดลไม่ได้

ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ SGLang กำลังรันอยู่ และไฟล์ opencode.json ใช้เอ็นด์พอยน์ต์โลคอลที่ถูกต้อง:

"baseURL": "http://127.0.0.1:30000/v1"

หากเข้าถึงเซิร์ฟเวอร์จากเครื่องโลคอล ให้เริ่ม SSH พร้อมพอร์ตฟอร์เวิร์ด:

ssh -L 30000:localhost:30000 ubuntu@XXXXXX

จากนั้นเปิด OpenCode จากไดเรกทอรีเดียวกับที่บันทึกไฟล์ opencode.json

ข้อคิดส่งท้าย 

ต้องบอกว่าฉันประหลาดใจกับความลื่นไหลของการตั้งค่าทางเทคนิค การรัน Mistral Medium 3.5 128B ด้วยอิมเมจ Docker แบบเนทีฟของ SGLang ง่ายกว่าที่คาดไว้มาก อิมเมจ Docker ดึงได้ถูกต้อง โมเดลโหลดขึ้น เอ็นด์พอยน์ต์ที่เข้ากันได้กับ OpenAI ทำงาน และ OpenCode ก็เชื่อมต่อได้โดยไม่มีปัญหามากนัก ฉัน

หากจะลองทำเอง ขอแนะนำอย่างยิ่งให้ใช้อิมเมจ Docker ของ SGLang แทนการติดตั้งทุกอย่างผ่านแพ็กเกจ Python เพราะการติดตั้งผ่าน Python อาจทำให้ CUDA, PyTorch และดีเพนเดนซีอื่น ๆ ป่วนได้ง่าย Docker ช่วยให้ทุกอย่างสะอาดและแยกส่วน

แต่สิ่งที่ชัดเจนที่สุดจากการทดลองนี้คือเรื่องต้นทุน ฉันไม่แน่ใจจริง ๆ ว่าบริษัท AI ทำกำไรจากอินเฟอเรนซ์กันอย่างไร แม้จะใช้ตัวเลือก H100 PCIe ที่ถูกและเก่ากว่า การตั้งค่านี้ยังมีต้นทุนเกือบ $10 ต่อชั่วโมง และนี่เป็นเพียงโมเดล 128B บน 4 GPU ลองนึกภาพการรันโมเดลระดับล้านล้านพารามิเตอร์บน H100 16 ตัว บิลสามารถพุ่งไปที่ $40+ ต่อชั่วโมง ได้ง่าย ๆ ก่อนจะคิดถึงค่าเก็บข้อมูล เครือข่าย มอนิเตอร์ อัปไทม์ และงานวิศวกรรม

สำหรับบริษัทขนาดเล็ก ฉันคิดว่าไม่คุ้มที่จะให้บริการโมเดลแบบนี้แบบโลคอล เว้นแต่จะมีเหตุผลที่หนักแน่น เช่น ความเป็นส่วนตัว งานวิจัย หรือการควบคุมสแตกอินเฟอเรนซ์อย่างลึก ต้นทุนอินเฟอเรนซ์สูงอยู่แล้ว และภาระการปฏิบัติการก็เป็นปัญหา ต้องทำให้เซิร์ฟเวอร์รันต่อเนื่อง ดูว่าโมเดลไม่ล่ม เฝ้าหน่วยความจำ GPU จัดการคอนเทนเนอร์ที่ล้มเหลว และคงเอ็นด์พอยน์ต์ให้พร้อมใช้งาน

เซิร์ฟเวอร์เลสเองก็ไม่ได้แก้ปัญหานี้สำหรับโมเดลใหญ่มาก ๆ เพราะเวลาสตาร์ทครั้งแรกยาวเกินไป ในการตั้งค่านี้ การเปิด VM ที่มี GPU ติดตั้งดีเพนเดนซี ดึงอิมเมจ Docker ดาวน์โหลดเวท และโหลดโมเดล ใช้เวลารวมเกือบ 3 ชั่วโมง 

ต่อให้การตั้งค่าของคุณเร็วกว่า การโหลดโมเดลขนาดนี้ก็ยังใช้เวลานานอยู่ดี ดังนั้นหากทุกคำขอต้องเปิดคลัสเตอร์ GPU ใหม่และโหลดโมเดลอีกครั้ง ก็ขัดกับแนวคิดของเซิร์ฟเวอร์เลส ในทางปฏิบัติ บริษัทต้องคงคลัสเตอร์ GPU ให้อุ่นอยู่เสมอ หมายความว่าต้องจ่ายเงินแม้ GPU จะว่างงาน

นี่ยังอธิบายว่าทำไมจึงมีราคา GPU ช่วงนอกพีค ผู้ให้บริการต้องการให้คนใช้ความจุ GPU ที่ว่าง เพราะ GPU ที่ไม่ได้ใช้คือค่าใช้จ่ายทิ้ง สำหรับผู้ใช้ นั่นอาจเป็นวิธีทดลองที่ถูกลง แต่ก็ชี้ให้เห็นถึงความยากของเศรษฐศาสตร์ด้านอินเฟอเรนซ์ของโมเดลขนาดใหญ่

โดยรวมแล้ว ฉันชอบ SGLang สำหรับการตั้งค่านี้มาก เวิร์กโฟลว์แบบ Docker ทำให้การให้บริการ Mistral Medium 3.5 128B ง่ายกว่าที่คาด และการทดสอบกับ OpenCode ก็ประทับใจจริง ๆ แต่การทดลองนี้ทำให้เห็นชัดเจนอย่างหนึ่ง: การรันโมเดลเปิดขนาดใหญ่แบบโลคอลทำได้ แต่การรันให้เสถียรและคุ้มค่าในฐานะผลิตภัณฑ์จริงเป็นอีกความท้าทายหนึ่งโดยสิ้นเชิง

หัวข้อ

เรียนรู้ AI กับ DataCamp!

Tracks

วิศวกร AI ระดับ Associate สำหรับนักพัฒนา

26 ชม.
เรียนรู้วิธีผสาน AI เข้ากับแอปพลิเคชันซอฟต์แวร์โดยใช้ API และไลบรารีโอเพนซอร์ส เริ่มต้นเส้นทางสู่การเป็น AI Engineer ของคุณวันนี้!
ดูรายละเอียดRight Arrow
เริ่มหลักสูตร
ดูเพิ่มเติมRight Arrow