ทีมที่สร้างบริการ inference ระดับ production ได้ทดสอบโมเดลภาษา 6 รุ่นบน DigitalOcean Inference เป็นเวลา 48 ชั่วโมง โมเดลขนาด "tiny" ที่มีราคาเพียง 0.20 ดอลลาร์ต่อเดือนสามารถเอาชนะตัวเลือกที่มีราคาสูงกว่าได้ โดยโมเดลนี้ยังคงทำงานอยู่ภายใต้ขีดจำกัดหน่วยความจำ 8 GB ของ droplets และหลีกเลี่ยงการแครชที่ทำให้โมเดลรุ่น 70B ล่ม โดยสามารถให้ความหน่วง (latency) และความแม่นยำ (accuracy) ที่ใช้งานได้จริงในราคาเพียงเศษเสี้ยวของตัวเลือกอื่น

ทำไมการทดสอบนี้ถึงสำคัญ

องค์กรที่ให้บริการโมเดลภาษาขนาดใหญ่ (LLMs) ในรูปแบบ API มักจะทึกทักเอาเองว่าโมเดลที่ใหญ่กว่าและแพงกว่าจะรับประกันประสบการณ์ที่ดีที่สุด แต่ในความเป็นจริง สภาพแวดล้อมการใช้งานจริงต้องจัดการทั้งเรื่องหน่วยความจำ, การทำงานพร้อมกัน (concurrency) และการรับประกันเวลาทำงาน (uptime) โมเดลที่ดูดีในทางทฤษฎีอาจกลายเป็นภาระเมื่อมันทำให้เกิดการถูกสั่งปิดเนื่องจากหน่วยความจำเต็ม (OOM kills) หรือทำให้บริการหยุดชะงักระหว่างการเริ่มทำงานครั้งแรก (cold starts) การทดลองภาคปฏิบัติครั้งนี้แสดงให้เห็นว่าโมเดลราคาถูกอาจเป็นทางเลือกเดียวที่ใช้งานได้จริงบนฮาร์ดแวร์ที่มีทรัพยากรจำกัด

ผู้เข้าแข่งขันทั้ง 6 รุ่น

โมเดล ค่าใช้จ่ายรายเดือน ความหน่วงเฉลี่ย ความแม่นยำ* การใช้ RAM / การแครช
mistral-tiny $0.20 120 ms 88 % 1.2 GB
mistral-small $0.80 180 ms 91 % 2.4 GB
mistral-medium $2.50 250 ms 93 % 4.1 GB
mistral-large $5.00 300 ms 94 % 6.8 GB
llama-70b $8.00 450 ms 95 % CRASH
mixtral-8x7b $10.00 500 ms 96 % CRASH

*ความแม่นยำสะท้อนถึงประสิทธิภาพของโมเดลจากการทดสอบด้วยชุดเกณฑ์มาตรฐาน (benchmark suite) ภายในของทีม

โมเดลขนาด "tiny" มีค่าใช้จ่ายไม่ถึงหนึ่งในสี่ดอลลาร์ต่อเดือน และทำงานอยู่ภายใต้ขีดจำกัดหน่วยความจำ 8 GB ได้อย่างสบาย ส่วนโมเดลที่ใหญ่ที่สุดสองรุ่น ได้แก่ llama-70b และ mixtral-8x7b ใช้หน่วยความจำเกินขีดจำกัดและทำให้โฮสต์แครชซ้ำแล้วซ้ำเล่า ส่งผลให้ไม่สามารถใช้งานได้แม้จะมีคะแนนความแม่นยำที่สูงกว่าก็ตาม

จุดบกพร่องที่ทำให้โมเดลขนาดใหญ่ล้มเหลว

  • Hard-coded endpoints – สถาปัตยกรรมเดิมส่งทุกคำขอไปยังโมเดลเดียว เมื่อโมเดลนั้นล้มเหลว API ทั้งหมดก็ล่มตามไปด้วย
  • No memory caps – โมเดลขนาดใหญ่กิน RAM ทั้งหมดที่มี ทำให้เกิด OOM kills โดยไม่มีการแจ้งเตือน
  • Cold-start latency – คำขอแรกที่ส่งไปยังโมเดลที่เพิ่งเริ่มทำงานต้องใช้เวลาหลายวินาที ซึ่งส่งผลเสียต่อความรู้สึกในการตอบสนอง
  • Unbounded concurrency – การแห่กันส่งคำขอพร้อมกันจำนวนมากทำให้หน่วยความจำและ CPU ทำงานหนักเกินไป จนเกิดความล้มเหลวทั้งระบบ

ตัวเลขประสิทธิภาพดิบๆ จะไม่มีความหมายเลย หากบริการไม่สามารถออนไลน์อยู่ได้ภายใต้ภาระงาน (load) ที่เกิดขึ้นจริง

การแก้ไขด้วย Dynamic Routing

วิศวกรได้เขียนเส้นทางการส่งคำขอใหม่โดยยึดหลักการ 3 ประการ:

  1. Runtime model selection – ตัวเลือกเส้นทาง (router) จะเลือกโมเดลตามแต่ละคำขอ แทนที่จะใช้เอนด์พอยต์แบบคงที่
  2. Hardware awareness – แต่ละคำขอจะได้รับงบประมาณหน่วยความจำ โดย router จะส่งคำขอไปยังโมเดลที่สามารถทำงานได้ภายใต้ RAM ที่เหลืออยู่เท่านั้น
  3. Fallback chains – หากโมเดลที่เลือกไว้ล้มเหลวหรือหมดเวลา (timeout) router จะพยายามใหม่โดยอัตโนมัติด้วยโมเดลที่ดีรองลงมา

สถาปัตยกรรมที่ปรับปรุงใหม่นี้ได้เพิ่มมาตรการป้องกันที่จับต้องได้ 4 ประการ:

  • Bounded concurrency – การใช้ semaphore เพื่อจำกัดการทำ inference แบบขนาน เพื่อป้องกันหน่วยความจำหมด
  • Fail-fast timeouts – การกำหนดเวลาหมดอายุต่อคำขอที่เข้มงวด เพื่อยกเลิกโมเดลที่ทำงานช้าก่อนที่จะไปบล็อกกระบวนการทั้งหมด
  • Memory buffers – ระบบจะสำรองพื้นที่ว่าง 20% ของ RAM บน droplet เพื่อรับประกันพื้นที่สำหรับ OS overhead และกรณีที่มีการใช้งานพุ่งสูงขึ้น (spikes)
  • Pre-warming – การส่งคำขอหลอก (dummy requests) ไปยังแต่ละโมเดลเมื่อเริ่มระบบ เพื่อกำจัดปัญหาความล่าช้าจากการเริ่มทำงานครั้งแรก (cold-start penalty)

มาตรการเหล่านี้ได้เปลี่ยนไปป์ไลน์ที่เปราะบางให้กลายเป็นบริการที่มีความยืดหยุ่น (resilient) ซึ่งสามารถรองรับทราฟฟิกบน droplets ขนาด 8 GB ได้โดยไม่ต้องสูญเสียความแม่นยำมากจนเกินไป

สิ่งที่ต้องจับตามองต่อไป

  • Hardware scaling – เมื่อผู้ให้บริการคลาวด์เสนอ droplet ที่มีหน่วยความจำใหญ่ขึ้นในราคาที่ต่ำลง จุดคุ้มทุนสำหรับโมเดลที่ใหญ่กว่าอาจเปลี่ยนไป
  • Model compression – การทำ Quantization หรือ Knowledge distillation อาจช่วยลดขนาดการใช้ RAM ของโมเดลที่มีความแม่นยำสูง ทำให้สามารถรันบนเครื่องที่มีขนาดเล็กลงได้
  • Adaptive routing – ในอนาคต router อาจเรียนรู้ได้แบบเรียลไทม์ว่าโมเดลใดให้ความสมดุลระหว่างความแม่นยำและต้นทุนได้ดีที่สุดสำหรับคำถามนั้นๆ ซึ่งจะช่วยเพิ่มความเป็นอัตโนมัติในการรักษาสมดุลระหว่างความแม่นยำและต้นทุน

บทสรุปนั้นง่ายมาก: ในการใช้งานจริง โมเดลที่ยังคงทำงานอยู่ได้ภายใต้ความกดดันจะมอบคุณค่าได้มากกว่าโมเดลที่ดูดีที่สุดในทางทฤษฎี จงเลือกโมเดลโดยพิจารณาจากข้อจำกัดในการติดตั้งใช้งาน (deployment constraints) ของคุณ ไม่ใช่แค่ความแม่นยำที่ปรากฏในพาดหัวข่าว