Fable5 แพงขึ้น ส่วน GPU ในเครื่องก็ไม่พอ: DRIFT ที่แบ่ง LLM หนึ่งโมเดลไปรันบน Mac และ CUDA

 (github.com/TaewoooPark)
1 คะแนน โดย theoverstructure 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

LLM กำลังถอยห่างจากผู้ใช้รายบุคคล และ DRIFT ต่อสู้กับสิ่งนี้ด้วยการแบ่ง LLM หนึ่งโมเดลให้รันบนอุปกรณ์ส่วนตัวหลายเครื่อง

DRIFT คือโปรเจกต์โอเพนซอร์สที่รัน LLM หนึ่งโมเดลโดยแบ่งออกเป็นระดับเลเยอร์บนอุปกรณ์ส่วนตัวหลายเครื่อง

ช่วงนี้ หากนักพัฒนารายบุคคลต้องการลองใช้งาน AI ด้วยตัวเอง ทั้งสองทางก็ไม่ง่ายนัก โมเดลระดับท็อปอย่าง Fable5 เข้าถึงได้จำกัดขึ้นเรื่อย ๆ ส่วนโมเดลแบบโลคัล แม้จะบอกว่า “รันบนคอมพิวเตอร์ของคุณได้” แต่ในความเป็นจริงก็ยังต้องการหน่วยความจำ GPU และการตั้งค่าที่ค่อนข้างสูง แม้ตัวโมเดลจะเปิดให้ใช้ แต่ความสามารถในการรันโมเดลเหล่านั้นในสเกลที่ใหญ่พอ ยังคงกระจุกตัวอยู่กับฮาร์ดแวร์และแพลตฟอร์มบางกลุ่ม สุดท้ายสิ่งนี้นำไปสู่สภาพแวดล้อม AI แบบรวมศูนย์ และทำให้ระดับการเข้าถึงเทคโนโลยีล่าสุดของบุคคลทั่วไปมีข้อจำกัดอย่างมาก

คำถามที่ DRIFT ตั้งขึ้นนั้นเรียบง่าย

ถ้าเครื่องเดียวรับภาระทั้งโมเดลไม่ไหว อุปกรณ์ส่วนตัวหลายเครื่องจะช่วยกันรันโมเดลเดียวกันได้ไหม?

DRIFT ใช้ Apple GPU (MPS) บน Mac ร่วมกับ NVIDIA GPU (CUDA) บนพีซี Windows/Linux เพื่อรันโมเดลหนึ่งตัว โดยแบ่งโมเดลออกเป็นระดับ decoder layer และระหว่างโหนดจะส่งเพียง hidden state ไม่ใช่ทั้งโมเดลหรือ KV cache การสื่อสารไม่ได้ใช้ PyTorch object หรือ CUDA handle แต่จัดการผ่านโปรโตคอลไบต์ที่เป็นกลางบนพื้นฐาน TCP + msgpack

ฟีเจอร์หลักมีดังนี้

  • แบ่ง LLM หนึ่งโมเดลโดยอัตโนมัติในระดับ decoder layer
  • รันแบบผสมระหว่าง Mac MPS และ NVIDIA CUDA
  • ใช้ TCP + msgpack สำหรับการสื่อสารระหว่างโหนด
  • ลดคอขวดแบนด์วิดท์ของ head node ด้วยโหมด P2P chain
  • สายสื่อสารเข้ารหัสบนพื้นฐาน X25519 และ ChaCha20-Poly1305
  • ตรวจสอบงานของแต่ละโหนดด้วยใบรับรองที่ลงลายเซ็น Ed25519
  • failover ด้วย re-split + replay เมื่อโหนดตายกลางทาง
  • ให้บริการ HTTP API ที่เข้ากันได้กับ OpenAI
  • ในทางทฤษฎีสามารถแบ่งได้ตามจำนวน decoder layer โดยโมเดล Qwen พื้นฐานสามารถแบ่งรันโมเดลเดียวได้สูงสุด 28 เครื่อง และ Gemma ได้สูงสุด 35 เครื่อง ขณะที่ sweet spot ที่ใช้งานได้จริงในปัจจุบันอยู่ที่ประมาณ 2–4 เครื่อง

โปรเจกต์ที่แก้ปัญหาคล้ายกันมี Exo และ llama.cpp RPC Exo สามารถรวม Apple Silicon หลายเครื่องให้ใช้เหมือนคลัสเตอร์โลคัลได้ แต่การสื่อสารระหว่างโหนดผูกกับฝั่ง MLX จึงออกนอกระบบนิเวศ Apple ได้ยาก ส่วน llama.cpp RPC สามารถใช้แบ็กเอนด์หลายแบบได้ แต่เป็นวิธี RPC ที่ผูกอยู่กับรันไทม์ ggml/llama.cpp จุดต่างของ DRIFT คือการยกระดับขอบเขตระหว่างโหนดให้เป็นโปรโตคอลไบต์ที่เป็นกลาง แทนที่จะผูกกับ ML runtime ใดโดยเฉพาะ ดังนั้นจึงโฟกัสไปที่การนำชุดที่เดิมใส่ไว้ใน distributed runtime เดียวกันได้ยาก เช่น Apple MPS และ NVIDIA CUDA เข้ามาอยู่ในการรันโมเดลเดียวกัน

การทำงานของ DRIFT สร้างบน Python และ PyTorch แต่สัญญาระหว่างโหนดถูกออกแบบไม่ให้พึ่งพา PyTorch การโหลดและรันโมเดลใช้ Hugging Face Transformers, safetensors และ PyTorch MPS/CUDA ส่วนภายนอกให้บริการ API ที่เข้ากันได้กับ OpenAI บนพื้นฐาน Starlette/Uvicorn การสื่อสารภายในถูกห่อด้วย msgpack framing และชั้นเข้ารหัส เพื่อแยก “จะรันโมเดลใดบนอุปกรณ์ใด” ออกจาก “โหนดต่าง ๆ ส่งไบต์อะไรหากัน”

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

DRIFT ไม่ใช่โปรเจกต์ที่ชูเรื่องความเร็วเป็นหลัก ตรงกันข้าม ลำดับความสำคัญคือความถูกต้อง โดยให้ความสำคัญกับการตรวจสอบว่า เมื่อรันแบบกระจายแล้วผลลัพธ์จะตรงกับการรันบนเครื่องเดียวหรือไม่ ตาม README ระบุว่า Qwen2.5-1.5B-Instruct ผ่าน parity gate หลายรายการแล้ว และรวมการทดลองที่ผสม Mac MPS กับ NVIDIA CUDA ไว้ด้วย

ในสถานการณ์ที่โมเดล AI ระดับสูงสุดปิดมากขึ้นเรื่อย ๆ และ AI แบบโลคัลยังคงต้องใช้ฮาร์ดแวร์ราคาแพง DRIFT ตั้งคำถามที่ค่อนข้างเป็นจริง

เมื่อ frontier model ถอยห่างจากลูกค้ารายบุคคล เราจะรวมทรัพยากรของบุคคลทั่วไปเพื่อเพิ่มพลังนั้นได้ไหม?

GitHub: https://github.com/TaewoooPark/DRIFT

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
theoverstructure 2 시간 전

DRIFT เป็นโปรเจกต์ที่ไม่ได้เน้นการแข่งขันด้านความเร็วเป็นหลัก แต่เริ่มจากการดูว่าบนเครื่องส่วนตัวแบบต่างสถาปัตยกรรม จะสามารถแบ่งรัน LLM ตัวเดียวได้อย่างถูกต้องหรือไม่!

โดยเฉพาะเมื่อเทียบกับฝั่ง Exo / llama.cpp RPC / Petals ผมอยากขอความคิดเห็นและฟีดแบ็กจากทุกท่านว่า จุดต่างของโปรเจกต์นี้น่าเชื่อถือเพียงพอหรือไม่ และมีประเด็นเพิ่มเติมใดบ้างที่งานจริงต้องการในการรันแบบผสม MPS↔CUDA