- Gemma 4 26B-A4B สามารถรันบนเซิร์ฟเวอร์ปี 2016 ที่มี Intel Xeon E5-2620 v4 ตัวเดียว, DDR3 128GB และไม่มี GPU ได้ด้วยการปรับแต่ง
ik_llama.cpp จนได้ความเร็วระดับการอ่าน
- เส้นทางดีโคดของ LLM ติดคอขวดที่ แบนด์วิดท์หน่วยความจำ มากกว่าพลังประมวลผล โดย CPU ต้องเสียเวลารอการดึงน้ำหนักถัดไปจาก RAM เข้าแคชมาก
--spec-type mtp, --cpu-moe, --merge-up-gate-experts, --run-time-repack เป็นต้น ช่วยลดคอขวดในสภาพแวดล้อม DDR3 ด้วย MTP speculative decoding, การทำ MoE routing และการจัดวางหน่วยความจำให้เป็นมิตรกับแคช- จาก log ความต้องการหน่วยความจำรวมอยู่ที่ 82,355MiB และในคอนเท็กซ์ 262K เต็มรูปแบบ KV cache ขนาดราว 56GB ใหญ่กว่าน้ำหนักโมเดลราว 25GB
- เครื่องมือแบบกล่องดำอย่าง
ollama ขาดทั้งการรองรับโมเดลที่ต้องใช้และปุ่มปรับละเอียดเพียงพอ ดังนั้นบนฮาร์ดแวร์เก่าจึงต้องเข้าใจทั้ง inference engine และโครงสร้างหน่วยความจำอย่างลึกซึ้งเพื่อดึงประสิทธิภาพออกมา
สภาพแวดล้อมการรันและคอขวดหลัก
- เซิร์ฟเวอร์ที่ใช้ทดสอบเป็นอุปกรณ์รีไซเคิล โดยมีสเปกคือ Intel Xeon E5-2620 v4 @ 2.10GHz, 8 คอร์ 16 เธรด, AVX2, L3 cache 20MiB, L2 2MiB, DDR3 128GB และไม่มี GPU
- CPU ตัวนี้ไม่รองรับ AVX-512, AVX-VNNI, BF16 และไม่มี integrated GPU
- ในงาน LLM inference เส้นทางดีโคดที่สร้างโทเคนทีละตัวนั้นติดข้อจำกัดหลักที่แบนด์วิดท์หน่วยความจำ ไม่ใช่ปริมาณการคำนวณ
- การคำนวณโทเคนถัดไปต้องย้ายน้ำหนักที่บรรจุความรู้ที่โมเดลเรียนรู้ไว้จาก RAM ไปยัง CPU cache และคอร์อย่างต่อเนื่อง ทำให้โปรเซสเซอร์ใช้เวลารอการย้ายน้ำหนักถัดไปมากกว่าการคำนวณเมทริกซ์
- “กำแพงหน่วยความจำ (memory wall)” นี้เป็นอุปสรรคด้านประสิทธิภาพสำคัญไม่เฉพาะกับ Xeon แต่รวมถึงฮาร์ดแวร์สมรรถนะสูงอย่าง H100 ด้วย
ปุ่มควบคุมที่ต้องมี แทนการใช้เครื่องมือแบบกล่องดำ
- หากรัน
llama-cli ตรง ๆ ในสภาพแวดล้อม DDR3 ที่ไม่มี GPU จะช้ามาก และยังเหลือพื้นที่ให้ปรับปรุงอีกมากเพราะการปรับแต่งส่วนใหญ่ถูกออกแบบมาสำหรับกรณีใช้งาน GPU ทั่วไป
ollama อาจไม่รองรับโมเดลที่ต้องการ และไม่ได้เปิดเผยการตั้งค่าละเอียดมากพอที่จะรีดประสิทธิภาพการรันได้จริง- การรันจริงจึงต้องอาศัยการผสมผสานแฟลกจำนวนมากที่
ik_llama.cpp เปิดให้ใช้
- ชุดแฟลกหลักมีดังนี้
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune
-sm graph -smgs -sas -mea 256 --split-mode-f32
-t 8 --parallel 8
--cpu-moe --merge-up-gate-experts
--flash-attn on --mla-use 3
--mlock --run-time-repack --no-kv-offload
การดีโคดแบบคาดเดาและการปรับแต่ง MoE
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune ใช้ verifier ขนาด 26B ร่วมกับ MTP drafter ขนาดเล็กที่สร้างไว้ก่อนหน้า--draft-max 3 คือสูงสุด 3 โทเคนต่อ draft, --draft-p-min 0.0 คือยอมรับทุกความน่าจะเป็น และ --spec-autotune จะปรับความยาวเชนให้เหมาะกับเวิร์กโหลด- เวลาสร้าง reasoning chain ยาว ๆ แม้ผู้ใช้จะเห็นเพียงคำตอบสุดท้ายสั้น ๆ แต่ทุกโทเคนความคิดภายในก็ยังต้องผ่านเส้นทางดีโคดเต็มรูปแบบ
- บน CPU ต้นทุนของการสตรีมน้ำหนัก verifier เข้าแคชสูงมาก ขณะที่เลเยอร์ที่ทำงานของ drafter ขนาดเล็กพอดีกับ L3 cache ได้ดี จึงยิ่งทำให้ speculative decoding มีประโยชน์มากขึ้น
- Gemma 4 26B-A4B ใช้โครงสร้าง MoE ที่มีผู้เชี่ยวชาญ 128 ตัว โดยจะมี 8 ตัวที่ทำงานต่อหนึ่งโทเคน และจากพารามิเตอร์รวมราว 25.2B จะมีพารามิเตอร์ที่ active จริงราว 3.8B
--cpu-moe ปรับ routing ให้เข้ากับลำดับชั้นแคชของ CPU และช่วยลด cache thrashing จากการสลับไปมาระหว่างผู้เชี่ยวชาญทั้ง 128 ตัว จนต้องล้างแคชและดึงข้อมูลจาก DDR3 ซ้ำ--merge-up-gate-experts รวม up projection และ gate projection ภายใน expert ให้เป็นการคูณเมทริกซ์ครั้งเดียว ซึ่งยืนยันได้จาก log ที่แสดง fused_up_gate = 1-t 8 เป็นค่าที่ตั้งให้ตรงกับ 8 คอร์จริง และในเวิร์กโหลดที่ติดคอขวดด้านหน่วยความจำ การใช้ 16 SMT threads ทั้งหมดอาจเพิ่มต้นทุนการจัดตารางมากกว่าช่วยเพิ่ม throughput
การตรึงหน่วยความจำ การจัดวางใหม่ และการแบ่งกราฟ
--run-time-repack จะจัดโครงสร้างเมทริกซ์น้ำหนักใหม่ก่อนเริ่ม inference ให้เหมาะกับเลย์เอาต์แคชของ CPU ซึ่งใน log จะแสดงเป็น Repacked 265 tensors- การตั้งค่านี้แลกกับเวลาหลายวินาทีตอนเริ่มต้น เพื่อจัดเรียงตารางตัวเลขใน RAM ใหม่ให้อยู่ในรูปแบบที่ CPU อ่านได้ดีขึ้น และช่วยใช้แบนด์วิดท์หน่วยความจำได้สูงสุดระหว่างการสร้างข้อความจริง
--mlock คือการตรึงโมเดลไว้ใน RAM เพื่อไม่ให้ระบบปฏิบัติการสลับออกไปยังดิสก์- หากข้อจำกัด memlock ของเคอร์เนลไม่สูงพอ จะมีคำเตือน
failed to mlock 27628376064-byte buffer และ Try increasing RLIMIT_MEMLOCK ซึ่งไม่ได้เป็นปัญหาของ LLM เอง แต่เป็นปัญหาจากการตั้งค่า ulimit พื้นฐาน
--no-kv-offload จะข้ามการพยายามย้าย KV cache ไปยัง GPU ในสภาพแวดล้อมที่ไม่มี GPU และคงไว้ใน RAM ของระบบ-sm graph เป็นความพยายามทำ graph splitting โดยแบ่งกราฟการคำนวณในแนวตั้ง เพื่อให้อุปกรณ์ประมวลผลหรือพื้นที่หน่วยความจำหลายส่วนคำนวณคนละส่วนของเลเยอร์เดียวกันได้พร้อมกัน- ในการรันครั้งนี้ มี log ว่า
Split mode 'graph' is not supported for Gemma4 external MTP และจึงลดระดับลงอย่างปลอดภัยไปใช้การแบ่งตามเลเยอร์
-sas ใช้สั่งให้แบ่งเวิร์กโหลดระหว่าง physical CPU socket หรือ NUMA node และ --split-mode-f32 ทำให้จุดกลางที่ต้องรวมผลกลับหลังการแบ่งใช้ความละเอียดเลขทศนิยม 32 บิต
Attention, การใช้หน่วยความจำ และบทสรุป
- ikawrakow ได้เขียน custom kernel สำหรับประมวลผล Flash Attention บน CPU ทำให้รองรับงานคอนเท็กซ์หนัก ๆ ได้โดยไม่ต้องพึ่ง GPU
--flash-attn on จะรวม attention softmax และการคูณเมทริกซ์เข้าด้วยกัน โดยไม่เขียน attention matrix ขนาด N×N ทั้งก้อนไปลง RAM จริง แต่คำนวณและใช้ผลในแคชเป็นชิ้นเล็ก ๆ--mla-use 3 เปิดใช้ Multi-Head Latent Attention เพื่อบีบอัด Key และ Value ของ KV cache ให้เป็นตัวแทนแฝงที่เล็กลง- ใน log มี
flash_attn = 1, fused_moe = 1, fused_up_gate = 1 แสดงว่าได้ใช้การปรับแต่งเหล่านี้จริง
- จาก log หน่วยความจำ ผลรวมทุกเลเยอร์อยู่ที่ 81,607.46MiB และหน่วยความจำที่ต้องใช้สำหรับ model tensor กับ cache อยู่ที่ 82,355MiB
- ในคอนเท็กซ์ 262K เต็มรูปแบบ น้ำหนักโมเดลอยู่ที่ราว 25GB ส่วน KV cache อยู่ที่ราว 56GB ทำให้ KV cache ใหญ่กว่าตัวโมเดล
- การตั้งค่านี้สามารถโหลด MoE ขนาด 25B พารามิเตอร์และทำ speculative decoding ด้วย MTP drafter ได้ พร้อมสร้างข้อความด้วยความเร็วระดับการอ่านบนเซิร์ฟเวอร์ Xeon ปี 2016 ที่ใช้ DDR3 และไม่มี GPU
- บทสรุปคือคอขวดของการรัน AI แบบ open weights สมัยใหม่ในเครื่อง local ไม่ได้อยู่ที่ซิลิคอนเพียงอย่างเดียว แต่อยู่ที่การเข้าใจการทำงานของ inference engine และโครงสร้างหน่วยความจำด้วย และหากเลือก fork ที่ถูกต้อง ใช้ quantization ที่ปรับเหมาะ และเข้าใจสถาปัตยกรรมหน่วยความจำ ก็สามารถรันบนเซิร์ฟเวอร์เก่าได้เช่นกัน
2 ความคิดเห็น
ความเห็นจาก Hacker News
เขียนโพสต์นี้ขึ้นมาเพราะรู้สึกอัดอั้นที่แทบไม่มีวิธีรันโมเดล Gemma 4 Drafter ตัวใหม่ และเครื่องมือกระแสหลักก็มักซ่อนจุดปรับแต่งประสิทธิภาพเอาไว้
สุดท้ายก็ทำสำเร็จจนสามารถรันโมเดล 26B MoE รุ่นล่าสุดได้ที่ความเร็วระดับอ่าน บนเซิร์ฟเวอร์รีไซเคิลเก่าที่ไม่มี GPU และมีเพียง Xeon E5-2620 v4 ตัวเดียวกับ RAM DDR3 128GB
ท้ายบทความมีลิงก์โมเดล quantized ไว้ด้วย แต่คงจะรันไม่ได้ถ้าไม่ใช้ฟอร์ก ik_llama-cpp ที่กล่าวถึง และรายละเอียดต้องไปดูในอีกบทความหนึ่ง
ผมไม่ใช่วิศวกรแมชชีนเลิร์นนิง และเซิร์ฟเวอร์เครื่องนี้ก็ยังยุ่งกับการทำหน้าที่เป็น Nix cache อยู่ แต่ถ้ามีคำถามก็จะตอบเท่าที่ตอบได้
เพราะระหว่างที่เธรดหนึ่งรอ DDR3 อีกเธรดก็ยังทำงานต่อได้
อีกอย่างผมก็ยังไม่ค่อยเข้าใจคำอธิบายของ
--cpu-moeเท่าไร ผู้เชี่ยวชาญหนึ่งตัวมีพารามิเตอร์ราว 4.0GiB แต่ถ้า L3 cache มีแค่ 20MiB ต่อให้จัดลำดับผู้เชี่ยวชาญให้เหมาะ ก็ดูไม่น่าจะ cache พารามิเตอร์ได้อย่างมีนัยสำคัญและอย่างที่คนอื่นพูดไว้ Intel Xeon E5-2xxx v4 มีเพียงบางรุ่นเท่านั้นที่รองรับ DDR3 และตามข้อมูลของ Intel E5-2620 v4 ไม่ใช่หนึ่งในนั้น
เป็นชุด dual Xeon กับ DDR3 128GB และ CPU คือ 2 × Xeon E5-2697 v2 รวม 24 คอร์/48 เธรด จึงดูดีกว่าในแง่จำนวนคอร์ แต่ความต่างจริงอาจไม่มากก็ได้
เครื่องนี้นอนจับฝุ่นอยู่ และถ้าเป็น Gemma ที่เร็วระดับอ่าน ก็น่าลองมาก
ให้ค้นหา “chia farming” ใน Amazon แต่ไม่ต้องไปสนใจ chia seeds
ตอนนี้อุปกรณ์ชุดเดียวกันแพงขึ้นราว 2.5 เท่าแล้ว แต่ก็ยังถูกกว่าเครื่อง DDR5 ยุคปัจจุบันมาก
https://www.amazon.com/dp/B095TRGCSX
เป็น
Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHzมี CPU ออนไลน์ 0-31 และ RAM 128GBอยากรู้ว่าถ้ามีสล็อต DIMM 8 ช่อง แบนด์วิดท์หน่วยความจำจริงๆ จะดีขึ้นด้วยหรือไม่ ตอนนี้เครื่องน่าสงสารนี้ถูกใช้ไว้ดู YouTube เท่านั้น
ยังไม่ถึงจุดนั้นเสียทีเดียว แต่ปลายทางที่ชัดเจนของฟองสบู่รอบนี้คือ โมเดลเปิดที่รันบนฮาร์ดแวร์และอุปกรณ์ในเครื่อง จะ “ดีพอ” สำหรับการใช้งานส่วนใหญ่
ถ้าเป็นแบบนั้น สิ่งที่กำลังเกิดขึ้นในวงการเทคตอนนี้อาจพังครืนลงมาได้ทั้งหมด
ถ้าตันจริงๆ ก็ยังเรียก Claude API ได้ แต่ความต้องการ 80% น่าจะใช้โมเดลโลคัลที่ฉลาดน้อยกว่าจัดการได้
ภาษาโปรแกรมและเทคนิคต่างๆ ไม่ได้เปลี่ยนมากนัก ก็หวังว่าจะใช้แบบนี้ได้อย่างน้อย 5 ปี และถ้ามีการ optimize ให้ใส่โมเดลที่ฉลาดกว่านี้ลงใน VRAM เดิมได้ ค่อยอัปเกรดตอนนั้น
ผมชอบทิศทางนี้
ถ้าจะเดาเหตุผลที่ยังไม่ทำ ก็คงเพราะตอนนี้แล็บ AI ต่างๆ กำลังขายโมเดลแบบขาดทุนหนัก ทำให้สำหรับ Amazon แล้วคอมพิวต์มาร์จินต่ำแบบนี้ไม่น่าดึงดูดเท่าสินค้ามาร์จินสูงตัวอื่น
สภาพปัจจุบันอาจไม่จำเป็นต้องรอให้ไปถึงการรันในเครื่องก่อนก็ได้ถึงจะพัง เมื่อเงินเผาของแล็บ AI หมดลงและต้องขายในราคาที่สูงกว่าต้นทุนรันจริง ใครก็ตามที่มีคอมพิวต์ก็จะมีแรงจูงใจให้บริการ โมเดลเปิดแบบเป็นบริการ ในราคาทั่วไปที่ถูกกว่า
ทุกคนจะมีโมเดลและมีความสามารถในการรันมันได้เอง และนั่นทำให้ภาวะขาดแคลน GPU กลายเป็นข้อได้เปรียบสำหรับพวกเขา
ความหวังของพวกเขาขึ้นอยู่กับการที่องค์กรและ SMB จะย้ายทุกกระบวนการทำงานขึ้นคลาวด์ และให้พนักงานแข่งขันกันใช้โทเคนให้มากที่สุด
โมเดลที่ “ดีพอ” บวกกับความเป็นส่วนตัวและการประหยัดต้นทุนระยะยาวนั้นน่าดึงดูดมาก
น่าแปลกตรงที่ยิ่งสภาพแวดล้อมรันทั่วไปสำหรับ coding agent ดีขึ้น คูเมืองของบริการอย่าง Claude ก็ยิ่งแคบลง ไม่น่าเชื่อว่าภายในไม่กี่เดือน โมเดลเปิดบางตัวไล่ตามโมเดลแนวหน้ามาได้เร็วขนาดไหน
บทความก็ดีและน่าประทับใจในเชิงเทคนิคด้วย ผมเห็นด้วยว่าควรเข้าใจ build pipeline และควรรันเองในเครื่องได้
แต่ความคุ้มค่าอาจไม่เวิร์กขึ้นอยู่กับค่าไฟ เซิร์ฟเวอร์เก่าประสิทธิภาพพลังงานไม่ดี และผมเคยคิดว่าเซิร์ฟเวอร์ Xeon รุ่นเก่าน่าจะกินไฟราว 200W ตอนโหลด ในขณะที่โมเดลเดียวกันมีให้ใช้บน OpenRouter ที่ 0.1/0.3 ดอลลาร์ต่อ 1 ล้านโทเคน, 76 โทเคน/วินาที, context 262k
แถมเซิร์ฟเวอร์แบบนี้ยังเสียงดังด้วย แม้ว่าดูเหมือนว่าที่ประเมินไว้ 200W จะสูงเกินไปหน่อย และเครื่อง Xeon เก่าที่ผมเคยใช้ก็กินไฟมากจริง แต่จำรุ่นที่แน่นอนไม่ได้แล้ว
เซิร์ฟเวอร์มักจะเสียงดังจริง แต่ก็ขึ้นอยู่กับการจัดชุดเหมือนกัน มีโฮสติ้งราคาถูกจำนวนมากที่ใช้ชิปตระกูลนี้ และประสิทธิภาพพลังงานดีกว่าที่คิด
ถ้ารันชุดคล้ายกันในเคส 4U พร้อมพัดลม 120mm รอบช้า ก็โอเค
ดีใจที่เห็นคนอื่นก็เริ่มตระหนักเรื่องนี้เหมือนกัน ผมกำลังรัน Gemma 26B-A4B Q4 บนคอนเทนเนอร์ที่ใช้ Xeon รุ่นปี 2012 กับ RAM 16~24GB ได้ราว ๆ 8~12 โทเคน/วินาที
มันเทียบกับการใช้บริบทขนาดใหญ่หรือรันบน GPU ไม่ได้ และตัวถอดรหัสภาพของ llama.cpp ก็ช้ากว่า GPU มากเช่นกัน แต่สำหรับงานอัตโนมัติเล็ก ๆ หรือคำถามความรู้ทั่วไปก็ถือว่าใช้ได้ อ่านตามทันได้จึงรู้สึกว่ารอน้อยลง
ชุดตั้งค่าคือบิลด์
llama.cppที่เปิด OpenBLAS กับ OpenMP, ตั้งOPENBLAS_NUM_THREADS=4,OMP_NUM_THREADS=4, ใช้unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL, แคชq8_0, และบริบท 8192ต้องลองหาการปรับแต่งเฉพาะ CPU อย่าง AVX2 ด้วย, MTP ผมลองอยู่พักหนึ่งแต่ไม่เห็นประสิทธิภาพดีขึ้น อาจลองปรับขนาดแบตช์ของแคช·บริบท หรือลดลงถึง Q2 ก็ได้ และควรเลี่ยงการจัดสรรเธรดมากเกินไป แนะนำให้เริ่มจากค่าเริ่มต้นหรือ
llama-benchก่อนระหว่างทดสอบผมรัน
gemma4:e4b-it-q4_K_Mซึ่งใส่ลงใน VRAM 11GB ได้พอดี และทำได้เกิน 50 โทเคน/วินาที โมเดลเล็กระดับนั้นอาจไม่ค่อยมีประโยชน์สำหรับงานเขียนโค้ด แต่ก็น่าจะมีประโยชน์กับงานแบบอื่นอยากทำ Wake-on-Use ให้ใช้เหมือน ChatGPT ส่วนตัว อาจทำได้โดยวาง Pi ไว้เป็นพร็อกซีแล้วเรียกสคริปต์ Wake-on-LAN และสักวันหนึ่งก็คงเป็นโปรเจ็กต์สุดสัปดาห์ที่สนุกดี
LLM ที่เปิดทิ้งไว้ตลอดคือ dense
Gemma4:31bซึ่งลงบน 2060 12GB ยังไม่ถึงครึ่ง มันช้ามากแต่คุณภาพดี และเพราะใช้กับงานประมวลผลคิวอัตโนมัติ ก็ไม่ได้ต้องนั่งจ้องผลลัพธ์มันตลอด 2060 ยังมีอีกใบ แต่ถ้าเสียบทั้งสองใบ PC จะ POST ไม่ผ่านผมชั่งใจเรื่อง Mac Studio Pro อยู่พักหนึ่ง ก่อนจะมาลงเอยทางนี้แทน ใช้เครื่อง HP Z620 แบบเฮดเลส มี ECC RAM 192GB, Xeon E5-2680 v2 คู่, Optane AIC, P102-100 VRAM 10GB สองใบ, SSD บูตขั้นต่ำที่ลง Debian 12.6 และ CUDA เวอร์ชันเก่าที่ตรึงไว้ซึ่งรองรับการ์ด Pascal
ผมใช้งานจากระยะไกลผ่าน AMT/meshcommander ในห้องใต้ดิน เปิด
llama.cppกับฟรอนต์เอนด์แล้วเข้าใช้งานผ่านเครือข่ายภายใน กำลังลองเล่น Talkie, Qwen 3.6 27b และ medgemma อยู่ และถ้าเลือกการควอนไทซ์ให้เหมาะสม ประสิทธิภาพของ GGUF โดยรวมก็ถือว่าดีค่าใช้จ่ายรวมต่ำกว่า 500 ดอลลาร์ แต่เป็นเซิร์ฟเวอร์ที่ซื้อจาก eBay เมื่อปีที่แล้ว ตอนนี้ราคาอาจไม่เหมือนเดิม
ต่อไปถ้า LLM ฐานสาม เบ่งบานขึ้นมา ผมก็หวังว่าฮาร์ดแวร์เก่านี้จะสามารถโฮสต์โมเดลความหนาแน่นสูงที่อัดแน่นด้วยความรู้ได้จริง แม้จะใหญ่กว่า GPU RAM แล้วล้นไปที่ Optane ก็ยังโอเค เพราะสิ่งสำคัญคือความรู้ข้อเท็จจริงทั่วไป ไม่ใช่ความเร็ว
แผนสุดท้ายคือเซ็ตทุกอย่างให้พร้อมแล้วเก็บไว้ในถังขยะ Faraday ที่ห้องใต้ดิน เพื่อให้มันเป็นออราเคิลสำหรับ “สร้างอารยธรรมใหม่” ตอนโลกพังลง แน่นอนว่าถ้าเกิดสถานการณ์แบบนั้นจริง พลังงานไฟฟ้าคงเป็นปัญหา แต่ถ้าฮาร์ดแวร์พวกนี้ถูกขนาดนี้และ AI สมัยใหม่ก็มีหลายจุดที่ใช้งานได้จริง ก็น่าลองทำอยู่ดี
สิ่งที่น่าสนใจที่สุดในความก้าวหน้าของ AI ไม่ใช่ AGI หรือโมเดลล่าสุดของยูนิคอร์น AI รายใดรายหนึ่ง แต่คือ เราจะรันอะไรแบบโลคัลได้บ้าง
เมื่อ 6 ปีก่อน เรารันโมเดลที่สนุกแต่แทบไม่มีประโยชน์บนพีซีเกมมิงสเปกสูง แต่ตอนนี้บนโน้ตบุ๊ก M5 กลับรันสิ่งที่ดีกว่านั้น 100 เท่าได้
ถ้าตลาดตอบสนองต่อปัญหาหน่วยความจำไม่พอ และ Apple silicon ยังพัฒนาในอัตราเดียวกันต่อไป สิ่งที่เราจะรันแบบโลคัลได้ในอีก 6 ปีน่าจะทั้งน่าสนใจมากหรือไม่ก็น่ากลัวมาก
ผมก็ไม่รู้ว่าสิ่งนี้หมายถึงอะไรต่อมูลค่าบริษัท AI บ้าง ครั้งหนึ่งเคยถามคำถามคล้าย ๆ กันกับพนักงานของบริษัทนั้นในงานอีเวนต์ แต่เขาไม่ตอบและเดินไปหยิบค็อกเทลแทน
ธุรกิจ AI ใช้เงินลงทุนสูงเหมือนโรงงานยุคเก่า ดาต้าเซ็นเตอร์แพง โมเดลกินไฟมาก และฮาร์ดแวร์ภายในก็ต้องเปลี่ยนทุก 3~4 ปี
โมเดลที่เล็กกว่าและเฉพาะทางกว่าก็กัดกินมาร์จินจากด้านล่าง งานถอดเสียง เสียงพูด และการตรวจจับภาพ ไม่จำเป็นต้องใช้โมเดลยักษ์
ไม่มีเหตุผลให้คาดหวังกำไรขั้นต้นสูงแบบธุรกิจซอฟต์แวร์ดั้งเดิม และผลประโยชน์จาก AI ส่วนใหญ่จะตกไปที่ผู้บริโภค ถึงอย่างนั้น บริษัทยักษ์ไม่กี่รายอย่าง Microsoft, Google, Amazon, Meta อาจอาศัยเศรษฐศาสตร์ขนาดเพื่อสร้างความได้เปรียบด้านต้นทุนได้
ไม่จำเป็นต้องเป็นตัวท็อปอย่าง 5080 แค่มี GPU เกมมิงที่ดีพอ ก็สามารถรันโมเดลโลคัลที่ดีกว่าสุดล้ำช่วงต้นปี 2025 ได้แล้ว
ทั้งนี้อาจต้องเปลี่ยนโมเดลตามงานที่ต้องการทำ และโมเดลมหึมาตัวเดียวที่ทำได้ทุกอย่างก็ยังเป็นเขตของดาต้าเซ็นเตอร์อยู่
หลายอย่างตั้งแต่วิกิพีเดียไปจนถึงโซเชียลมีเดีย อีเมล และวิดีโอเซิร์ฟเวอร์ สามารถรันแบบโลคัลได้
แต่คนส่วนใหญ่ที่มีงานประจำและมีลูกสองคน ไม่มีเวลาและพลังงานพอจะคอยแพตช์และดูแลรักษา ระบบก็ยิ่งซับซ้อนขึ้นเรื่อย ๆ และบั๊กก็เพิ่มขึ้นเรื่อย ๆ นี่คือการแลกเปลี่ยนเก่าแก่ระหว่างอิสรภาพกับความสะดวก
ผู้ใช้ส่วนใหญ่ไม่รู้ด้วยซ้ำว่า LLM คืออะไรหรือมันทำงานอย่างไร ผู้ใช้ LLM จำนวนมากก็ใช้สิ่งที่ที่ทำงานมีให้เป็นค่าเริ่มต้น และแม้แต่ผู้ใช้ที่คล่องกว่านิดหน่อยก็ดูจะยอมจ่ายค่าสมาชิก OpenAI หรือ Anthropic ได้
น่าจะมีกลุ่มผู้ใช้โมเดลแบบเปิดน้ำหนักที่ชอบ LLM แบบโลคัล ซึ่งมีขนาดเล็กแต่ทุ่มเทเกิดขึ้น แต่คนนอกนั้นก็น่าจะยังบริโภคจากผู้ให้บริการรายใหญ่มากกว่า คล้ายกับการเลือกระบบปฏิบัติการในปัจจุบัน ที่มีผู้ใช้ Linux ส่วนน้อย และผู้ใช้ Windows, macOS, Chrome ส่วนใหญ่
เกมที่อายุ 5~6 ปีมักซื้อได้ถูกกว่ามากและรันบนฮาร์ดแวร์ธรรมดาได้ แต่ตัวอุตสาหกรรมเองก็ไม่ได้หยุดนิ่งไป 5 ปี ยังมีซอฟต์แวร์ใหม่ที่ต้องการฮาร์ดแวร์ดีกว่าออกมาเรื่อย ๆ
ผลลัพธ์ที่ผู้เขียนต้นฉบับเปิดเผยไว้ในคอมเมนต์คือประมาณ 12 โทเค็น/วินาที
เป็นความพยายามที่น่าประทับใจกว่าที่คิดว่าจะทำได้บนฮาร์ดแวร์นี้มาก แต่ก็ยังห่างพอสมควรจากระดับที่จำเป็นสำหรับเซสชันโต้ตอบที่น่าพอใจ
หลายครั้งถูกกว่าโมเดลล้ำสมัย 100~500 เท่า และบางกรณีก็เร็วกว่าในแง่โทเค็น/วินาที 2~5 เท่า
ถ้าใช้ทำงานเบื้องหลังก็ถือว่าเพียงพอ
มันทำงานได้ แต่ไม่ใช่ระดับ throughput ที่จะใช้กับงานจริงจัง
E5-2620 v4 ยอดเยี่ยมมาก ผมใช้มา 10 ปีแล้ว และพอจะอัปเกรดก็มาหยุดเมื่อเห็นราคาปัจจุบัน
ผมใส่ 64GB DDR4 กับ RX 9060 XT 16GB และมันก็ยังเล่นเกมได้ลื่นอยู่ ใน DOOM The Dark Ages CPU อาจเป็นคอขวดเล็กน้อย แต่ที่ 60fps ก็ไม่มีปัญหา
การรัน LLM เบาๆ บน GPU เป็นตัวเลือกที่ชัดเจนอยู่แล้ว และก็น่าสนใจที่บน CPU ถ้าจูนดีๆ ก็ยังรันได้โอเค
เดือนก่อนผมซื้อ 2667 v4 มาในราคา 30 ดอลลาร์ น่าจะเพิ่มประสิทธิภาพได้พอสมควร แต่ยังไม่จำเป็น ถ้าจะดันไปทาง LLM แบบในโพสต์นี้ ก็คงอัปเกรดเพราะ 2667 จัดการ RAM ที่เร็วกว่าได้เล็กน้อย
ผมยังค่อนข้างแปลกใจกับของที่ยังหาได้ในตลาดมือสอง
ไม่คิดว่าราคา RAM กับ GPU จะพุ่งแรงขนาดนี้ แต่บังเอิญจังหวะดี กำลังคิดเหมือนกันว่าจะคว้า 3080 ราคาแถว 300 ดอลลาร์จาก eBay แล้วขาย 1080 Ti ทิ้ง แต่ยกเว้นเรื่องนั้น มันเป็นการอัปเกรดที่ยอดเยี่ยมมาก
มันกินไฟเหมือน Coca Cola แต่ในฐานะเวิร์กสเตชันแล้วทำงานได้ดีเยี่ยม ดังนั้นผมคงใช้งานมันหนักๆ จนกว่าจะพัง
เมื่อก่อนผมคิดว่าความเสียหายจากความร้อนจะฆ่า CPU ได้ราวๆ 5~7 ปี เลยสงสัยว่านั่นเป็นข้อสมมติที่ผิดหรือเปล่า หรือไม่ก็ CPU สมัยนี้แข็งแกร่งและทนทานกว่าสมัยก่อนมาก
เมื่อเร็วๆ นี้มีโพสต์คล้ายกันเกี่ยวกับการปรับแต่ง Xeon รุ่นเก่าสำหรับงานนี้
“High-Performance AI on a Budget: Optimizing llama.cpp for Qwen3.5 Inference on a Dual-GPU HP Z440”
https://news.ycombinator.com/item?id=47320244
น่าแปลกที่ Itanium ก็ดูเหมือนจะเหมาะกับ LLM พอสมควรด้วย: https://medium.com/@tglozar/running-llama-inference-on-intel...
พอลองคิดดูก็สมเหตุสมผลอยู่
เนื้อหาน่าสนใจดีครับ ผมมีระบบ Xeon รุ่นเก่าอยู่เครื่องหนึ่ง ไว้จะลองทำตามดูครับ