โมเดล Qwen ขนาด 30 พันล้านพารามิเตอร์ที่รันแบบเรียลไทม์บน Raspberry Pi

 (byteshape.com)
22 คะแนน โดย GN⁺ 2026-01-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โมเดล Qwen3-30B-A3B-Instruct-2507 ทำงานแบบเรียลไทม์บน Raspberry Pi 5 (16GB) ได้ โดยคงประสิทธิภาพไว้ที่ 8.03 TPS และคุณภาพระดับ 94.18% ของ BF16
  • ด้วย วิธีเรียนรู้ความยาวบิต ShapeLearn ของ ByteShape ทำให้สามารถปรับ สมดุลระหว่างความเร็วและคุณภาพ ให้เหมาะสมภายในข้อจำกัดหน่วยความจำของแต่ละอุปกรณ์
  • เมื่อเทียบกับ Unsloth และ MagicQuant สามารถทำ TPS ได้สูงกว่าในคุณภาพระดับเดียวกัน หรือให้คุณภาพสูงกว่าใน TPS ระดับเดียวกัน
  • ทั้งบน CPU และ GPU (โดยเฉพาะ RTX 5090·4080) พบว่า ช่วงใกล้ 4 บิตคือจุดที่ให้ประสิทธิภาพดีที่สุด และการลดจำนวนบิตไม่ได้ทำให้เร็วขึ้นเสมอไป
  • โดยรวมแล้ว โมเดลของ ByteShape ใช้แนวทาง “มองหน่วยความจำเป็นงบประมาณ แล้วปรับ TPS/คุณภาพให้เหมาะสม” เพื่อมอบประสิทธิภาพที่มีประสิทธิผลตั้งแต่อุปกรณ์ edge ไปจนถึงดาต้าเซ็นเตอร์

ภาพรวมการปรับแต่งด้วย ShapeLearn

  • ByteShape ปรับแต่งโดยเน้น ความเร็วและคุณภาพของการตอบสนอง ที่ผู้ใช้สัมผัสได้จริงขณะรันโมเดล
    • ShapeLearn เรียนรู้ data type (bitlength) ของ weight ในแต่ละ tensor เพื่อเพิ่มทั้ง TPS (โทเคนต่อวินาที) และ คุณภาพของผลลัพธ์ ให้สูงสุดพร้อมกัน
    • เป้าหมายไม่ใช่แค่การลดขนาดไฟล์ แต่คือการปรับปรุง สมดุลจริงระหว่างความเร็วกับคุณภาพ
  • ในสภาพแวดล้อม llama.cpp ต่อให้ลดจำนวนบิตลง ความเร็วก็ไม่ได้เพิ่มขึ้นเสมอไป และ การเลือก kernel กับ overhead มีผลต่อประสิทธิภาพอย่างมาก
  • ByteShape มองหน่วยความจำเป็น “งบประมาณที่ต้องให้พอดี” และหลังจากนั้นจึงปรับโดยเน้น TPS และคุณภาพ

ประสิทธิภาพบน Raspberry Pi 5

  • บน Raspberry Pi 5 (16GB) โมเดล 30B ยังคงได้ 8.5 TPS และความแม่นยำเกิน 92%
    • โมเดล Q3_K_S-2.70bpw [KQ-2] ให้ความเร็วตอบสนองระดับที่สนทนาแบบเรียลไทม์ได้
  • ใน โมเดลที่เน้นความแม่นยำ ByteShape มี relative error 1.1~1.3% (ความแม่นยำราว 98.8%) ทำให้อัตราความผิดพลาดต่ำกว่า Unsloth ได้สูงสุด 1.87 เท่า
    • ในสภาพแวดล้อมเดียวกันยังคงได้ 5~6 TPS เหมาะกับงานที่เน้นความแม่นยำ
  • โมเดลที่เน้นความเร็ว (Q3_K_S-3.25bpw [KQ-5]) ก็มีขนาดเล็กและเร็วกว่า Unsloth พร้อมรักษาความเหนือกว่าในด้านความแม่นยำ
  • โมเดลจำนวนมากของ Unsloth และ MagicQuant ไม่สามารถรันบน Pi ได้เนื่องจากข้อจำกัดด้านหน่วยความจำ

ประสิทธิภาพบน Intel i7 (64GB)

  • ในสภาพแวดล้อมที่ทุกโมเดลพอดีกับหน่วยความจำ ByteShape ทำได้ทั้ง คุณภาพและ TPS สูงกว่า Unsloth·MagicQuant
  • ช่วงที่เน้นคุณภาพ: โมเดล IQ4_XS-4.67bpw [KQ-9] ของ ByteShape มี อัตราความผิดพลาดต่ำกว่า 1.44 เท่า เมื่อเทียบกับ Q6_K ของ Unsloth และยังได้ TPS สูงกว่า
  • ช่วงสมดุล: โมเดล Q3_K_S-3.25bpw ของ ByteShape มี อัตราความผิดพลาดต่ำกว่า 1.73 เท่า เมื่อเทียบกับ Unsloth และ เหนือกว่า MagicQuant ทั้งด้านความแม่นยำและความเร็ว
  • มีเพียง ByteShape เท่านั้นที่ครอบคลุมได้ทั้งช่วง 26+ TPS และช่วงคุณภาพสูงพร้อมกัน

เปรียบเทียบประสิทธิภาพ GPU (RTX 5090 / RTX 4080)

  • บน GPU นั้น การเลือก kernel และประสิทธิภาพการเข้าถึง VRAM เป็นตัวกำหนดประสิทธิภาพหลัก
    • ยืนยันได้ว่า ใกล้ 4 บิต (~4bpw) คือ sweet spot ของทั้ง TPS และคุณภาพ
  • RTX 5090 (32GB)
    • Unsloth, MagicQuant และ ByteShape ต่างทำได้ 302~303 TPS และความแม่นยำ 98.4~98.9% ในช่วง 4b
    • โมเดล IQ4_XS-4.67bpw ของ ByteShape ทำความแม่นยำสูงสุดที่ 272.98 TPS และ 99.75%
    • เหนือกว่า Unsloth Q6_K (6.57bpw, 264.88 TPS, 99.64%) และ MagicQuant mxfp4 (5.46bpw, 240.42 TPS, 99.32%)
  • RTX 4080 (16GB)
    • ด้วยข้อจำกัด VRAM จึงใช้โมเดล 4b ไม่ได้ และภายใต้เงื่อนไข 16GB เดียวกัน ByteShape ก็ยัง เหนือกว่า Unsloth ทั้ง TPS และความแม่นยำ
    • ByteShape IQ4_XS-3.87bpw: 214.81 TPS, ความแม่นยำ 98.66%
      • เมื่อเทียบกับ Unsloth Q3_K_XL มี อัตราความผิดพลาดต่ำกว่า 1.59 เท่า และ TPS สูงกว่า 9.4%
      • เมื่อเทียบกับ Unsloth IQ2_M มี อัตราความผิดพลาดต่ำกว่า 2.54 เท่า

ความย้อนแย้งของจำนวนบิตกับความเร็ว

  • แม้ลดลงต่ำกว่า 3 บิต ก็ไม่ได้การันตีว่าจะเร็วขึ้น
    • GPU ทำงานเป็นหน่วย warp ขนาด 32 เธรด และถูกปรับแต่งมาสำหรับรูปแบบข้อมูลกับแพตเทิร์นการเข้าถึงบางประเภท
    • VRAM อ่านข้อมูลเป็นบล็อกที่จัดแนว 32 ไบต์ ดังนั้นแม้ข้อมูลจะเล็กลงก็ยังใช้แบนด์วิดท์เท่าเดิม
    • bitwidth ที่ต่ำลงอาจทำให้ overhead จากการถอดรหัสเพิ่มขึ้น จนกลับช้าลง
  • ตัวอย่าง: บน RTX 5090 iq4_xs ใช้เวลา 54µs ส่วน iq3_xxs ใช้ 62µs → ขนาดลดลง 25% แต่ความเร็วกลับลดลง 13%
  • ShapeLearn เลือก data type ราย tensor โดยคำนึงถึงคุณลักษณะฮาร์ดแวร์เหล่านี้ เพื่อให้ได้ทั้งความเร็วและความแม่นยำพร้อมกัน

วิธีประเมินและข้อสรุป

  • ทุกโมเดลถูกวัดด้วย evaluation harness เดียวกันในด้าน TPS และ คะแนนคุณภาพที่ทำ normalization เทียบกับ BF16
    • การประเมินคุณภาพรวมผลจาก MMLU, GSM8K, IFEval, LiveCodeBench V4
  • ข้อสรุปหลัก:
    • “จงปฏิบัติต่อหน่วยความจำในฐานะข้อจำกัด ไม่ใช่เป้าหมาย”
    • เมื่อโมเดลโหลดลงอุปกรณ์ได้แล้ว สิ่งสำคัญหลังจากนั้นคือ เส้นโค้งสมดุลระหว่าง TPS กับคุณภาพ
    • ByteShape สามารถทำได้ เร็วกว่าในคุณภาพระดับเดียวกัน หรือให้คุณภาพสูงกว่าในความเร็วระดับเดียวกัน บนอุปกรณ์ทุกประเภท
  • บน Raspberry Pi 5 โมเดล Q3_K_S-2.70bpw [KQ-2] เหมาะสำหรับการสนทนาแบบเรียลไทม์
  • ในสภาพแวดล้อม CPU·GPU ขนาดใหญ่ก็ใช้หลักการเดียวกัน: “ให้พอดีก่อน แล้วค่อยปรับให้เหมาะสม”
  • ByteShape มีแผนจะทยอยเผยแพร่ โมเดลที่ปรับแต่งตามอุปกรณ์ เพิ่มเติมต่อไป

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

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

 
GN⁺ 2026-01-07
ความคิดเห็นจาก Hacker News

  • ฉันคิดว่าตรงนี้มีโอกาสทางตลาดครั้งใหญ่
    สิ่งที่ฉันต้องการคือผู้ช่วยเสียงแบบ Alexa แต่เป็นระบบที่มีองค์ประกอบมาตรฐานซึ่งอิงกับการอนุมานแบบโลคัลและที่เก็บข้อมูลในเครื่อง

    • อุปกรณ์สนทนา: อุปกรณ์แนว Alexa/Google/Apple หรืออุปกรณ์รับสัญญาณทีวีที่มีลำโพงดีและควบคุมด้วยเสียงได้ หรือถ้าทำหน้าที่เป็น Wi-Fi extender หรือเราเตอร์ได้ด้วยก็ยิ่งดี อยากวางไว้ห้องละตัวเพื่อสร้างเมชเน็ตเวิร์กจริง ๆ
    • เซิร์ฟเวอร์โฮมคลาวด์: อุปกรณ์ที่มี CPU ราคาถูก RAM พอประมาณ และพื้นที่เก็บข้อมูลเพียงพอ ซึ่งจะเป็นโหนดศูนย์กลางสำหรับจัดการแอปในบ้านและการสำรองข้อมูลเครือข่าย
    • เอนจินอนุมาน: อยากให้ประกาศบริการด้วยวิธีมาตรฐาน และให้โหนดควบคุมเชื่อมต่อให้อัตโนมัติ ต้องการสภาพแวดล้อมแบบplug-and-play ที่เสียบแล้วใช้งานได้เลย
      หัวใจสำคัญคือความเป็นส่วนตัวและการทำงานร่วมกันได้ ถ้าต้องสมัครบัญชีหรือต้องเชื่อมต่อเซิร์ฟเวอร์ภายนอก ฉันจะไม่ซื้อ อยากให้คำสั่งอย่าง “Freddy, ตั้งเวลา 10 นาที” ถูกประมวลผลภายในเครื่อง
    • แม้ยังไม่มีผลิตภัณฑ์แบบ plug-and-play ที่สมบูรณ์ แต่ฉันได้ผลลัพธ์ค่อนข้างดีกับHome Assistant และ Voice Preview Edition ของมัน
      โครงสร้างคือวางอุปกรณ์ Wi-Fi + ไมโครโฟน + ลำโพงราคาถูกหลายตัวไว้ตามจุดต่าง ๆ ในบ้าน แล้วให้กล่องประสิทธิภาพสูงตรงกลางทำงานประมวลผลเสียง
      ท้ายที่สุดมันทำงานเหมือนโปรแกรมเดียว ดังนั้นถ้าเพิ่มการ์ด Wi-Fi ให้เครื่องที่แรงขึ้นอีกหน่อย ก็อาจทำหน้าที่เป็นWi-Fi extenderได้ด้วย
    • ฉันก็เห็นด้วยกับไอเดียนี้ กำลังเจอปัญหาในการทำให้การเชื่อมต่อเสียงจาก Home Assistant (HA) ไปยัง ChatGPT ลื่นไหล
      ฉันก็ไม่ชอบแนวคิดเรื่องwake wordเหมือนกัน รู้สึกว่ายังมีอีกหลายจุดในทั้งสแตกที่ต้องปรับปรุง
    • และถ้ามีระบบแบบนี้ในของเล่นก็น่าจะสนุกดี

  • สงสัยว่ามีแหล่งข้อมูลดี ๆ ที่เปรียบเทียบโมเดลต่าง ๆ ได้ง่ายหรือไม่
    ฉันรู้ว่า จำนวนพารามิเตอร์ของ gpt-oss-20b กับ gpt-oss-120b ต่างกัน แต่ไม่ค่อยรู้ว่าประสิทธิภาพจริงต่างกันมากแค่ไหน
    ฉันเคยใช้แต่โมเดลใหญ่ ๆ อย่าง Gemini หรือ GPT เลยอยากรู้ว่าบนฮาร์ดแวร์ของฉัน โมเดลที่เล็กลงแค่ไหนยังใช้งานได้คุ้มค่า

    • สามารถเปรียบเทียบเบนช์มาร์กตามโมเดลได้ที่ swe-rebench.com

  • ฉันลองไปค้นดูเพราะอยากรู้ว่าประสิทธิภาพแบบ “เรียลไทม์” อยู่ระดับไหน
    บน Pi 5 (16GB) โมเดล Q3_K_S-2.70bpw [KQ-2] ทำได้ 8.03 TPS และยังคงคุณภาพได้ 94.18% ของ BF16
    บทความยังพูดถึงรายละเอียดฮาร์ดแวร์อื่น ๆ ด้วย

    • ฉันคิดว่าน่าจะดีถ้ามีหน้าสรุป Hacker Newsที่คัดมาโชว์เฉพาะตัวเลขสำคัญแบบนี้

  • ฉันก็ลองทดสอบบน Pi 5 (16GB) ด้วย llama.cpp เวอร์ชันล่าสุด แล้วเกิดsegmentation fault (segfault)
    มีข้อความแจ้งข้อผิดพลาดว่าเมมโมรีไม่พอ และโปรแกรมก็ปิดไปหลังใช้ RAM ไปประมาณ 10GB
    พอลดขนาดคอนเท็กซ์ด้วยตัวเลือก -c 4096 ก็โหลดสำเร็จ

    • อาจลองใช้โมเดลควอนไทซ์ 4 บิตของ illama หรือ ik_llama.cpp หรือ Microsoft BitNet ก็ได้
      โมเดลอย่าง BitNet b1.58-2B-4T-gguf น่าจะเหมาะกับการทดลองเปรียบเทียบบนอุปกรณ์สเปกต่ำหรือพีซีสำนักงานที่มีแค่ iGPU
    • เป็นไปได้ไหมว่าเขาอาจเพิ่มหน่วยความจำสว็อปเข้าไปด้วย

  • ฉันสงสัยว่าวิธีวัดความแม่นยำนี้ต่างจาก perplexity แบบทั่วไปหรือไม่
    ลดจาก BF16 ลงมาเหลือ 2.8 แล้วคุณภาพเสียไปแค่ 5% ฟังดูแปลก ๆ

  • GPT-OSS-20B มีขนาดประมาณ 11.2GB ดังนั้นแม้อุปกรณ์ที่มีหน่วยความจำ 16GB ก็น่าจะรันได้สบายโดยที่คุณภาพไม่ลดลง