รัน Gemma 4 26B บน Xeon อายุ 13 ปีโดยไม่มี GPU ได้ที่ 5 โทเคนต่อวินาที

 (neomindlabs.com)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บนเซิร์ฟเวอร์ที่ประกอบด้วย Xeon E5-2690 v2 แบบคู่ รุ่นปี 2013 และหน่วยความจำ DDR3 สามารถรัน Gemma 4 26B-A4B Q8_0 ด้วย CPU ล้วนได้ โดยทำความเร็วถอดรหัสราว 5.2 โทเคน/วินาที และประเมินพรอมป์ตราว 16 โทเคน/วินาที
  • เส้นทางประสิทธิภาพสูงของ ik_llama.cpp ตั้งสมมติฐานว่ามี AVX2·FMA3 แต่ CPU ตระกูล Ivy Bridge รองรับเพียง AVX1 จึงต้องแก้การคอมไพล์สำหรับบิลด์ที่ไม่ใช้ AVX2 และเพิ่ม fallback สำหรับการคำนวณ
  • ตัวสร้างกราฟสร้าง MOE_FUSED_UP_GATE และ FUSED_UP_GATE แบบไม่มีเงื่อนไข แต่ตัว dispatch ฝั่ง non-AVX2 ไม่มีเส้นทางรองรับ ทำให้ในแต่ละรอบ forward มีเทนเซอร์ราว 240 ตัวที่ไม่ได้ถูกคำนวณ และนำไปสู่เอาต์พุตหลายภาษาที่อ่านไม่รู้เรื่อง
  • Claude พบข้อผิดพลาดผ่านการวัดค่า logits และการวิเคราะห์โค้ด แล้วแทนที่ fused operation ด้วย ggml_mul_mat_id สองครั้งและ ggml_fused_mul_unary ขณะที่ผู้ใช้เป็นผู้รันการทดลองและตัดสินว่าอะไรคือ เกณฑ์ของผลลัพธ์ที่ถูกต้อง
  • เซิร์ฟเวอร์องค์กรรุ่นเก่ายังใช้เป็น ทางเลือกแบบโลคัล ได้เมื่อ API แบบเสียเงินล่ม หรือใช้กับงานแบตช์ช้า ๆ ได้ แต่ไม่ควรใช้ --run-time-repack ที่สร้างเลย์เอาต์เฉพาะ AVX2

สภาพแวดล้อมการรันบนสตอเรจเซิร์ฟเวอร์อายุ 13 ปี

  • อุปกรณ์ HP StoreVirtual ที่นำกลับมาใช้ใหม่ ใช้ Xeon E5-2690 v2 แบบคู่ รุ่นปี 2013 กับหน่วยความจำ DDR3 และไม่มี GPU
    • เป็นสถาปัตยกรรม Ivy Bridge จึงรองรับแค่ AVX1 และ ไม่รองรับ AVX2 กับ FMA3
    • เดิมถูกสร้างมาสำหรับเก็บข้อมูลดิสก์ และมีราคาซื้อไม่ถึง 300 ดอลลาร์
  • โมเดลที่รันคือ Gemma 4 26B-A4B ของ Google ซึ่งเป็นโมเดล Mixture-of-Experts (MoE) แบบ open weights ที่มีพารามิเตอร์ 26 พันล้านตัว
  • บนโมเดลที่ควอนไทซ์แบบ Q8_0 วัดได้ว่าการถอดรหัสอยู่ที่ราว 5.2 โทเคน/วินาที และการประเมินพรอมป์ตราว 16 โทเคน/วินาที

กรณี Xeon รุ่นปี 2016 ที่เป็นจุดตั้งต้น

  • บทความ A 10 year old Xeon is all you need ที่แชร์บน Hacker News เป็นกรณีรัน Gemma 4 บน Xeon เดี่ยวรุ่นปี 2016 พร้อม DDR3 128GB โดยไม่มี GPU
  • การตั้งค่านั้นใช้ ik_llama.cpp และแฟล็กรันจำนวนละเอียดราว 25 ตัว
    • speculative decoding
    • MoE routing ที่คำนึงถึง CPU
    • flash attention สำหรับ CPU
    • repack น้ำหนักระหว่างรัน
  • มีการนำแนวทางเดียวกันมาใช้กับเซิร์ฟเวอร์ Ivy Bridge แต่การรันหยุดตั้งแต่ช่วงเริ่มต้น
    • ต่างจาก Broadwell รุ่นปี 2016, E5-2690 v2 ไม่มี AVX2 และ FMA3
    • ชุดคำสั่งนี้เพิ่งมีตั้งแต่ Haswell ปี 2014 หรือรุ่น v3 ของ Intel และเคอร์เนลความเร็วสูงถูกเขียนโดยตั้งสมมติฐานว่ามีมัน

การวินิจฉัยและแพตช์ด้วย Claude

  • เมื่อได้รับข้อมูลการเริ่มรันล้มเหลว Claude ระบุสาเหตุได้ว่าเป็น ความต่างของชุดคำสั่ง CPU
  • จากนั้นจึงต่อยอดจากความพยายามก่อนหน้าที่ยังค้างอยู่ด้วยโมเดลฟรี โดยแก้ให้เส้นทาง C++ ที่สำคัญด้านประสิทธิภาพ fallback ได้ถูกต้องบน CPU ที่เก่ากว่า AVX2
  • งานนี้ไม่ได้จบด้วยคำขอ fix it ครั้งเดียว
    • ต้องอ่านโค้ด C++ ที่เน้นประสิทธิภาพซึ่งนักพัฒนาคนอื่นเขียนไว้
    • วิเคราะห์ว่าทำไมเคอร์เนลจึงใช้ไม่ได้บนไมโครสถาปัตยกรรมบางตัว
    • หลีกเลี่ยงเส้นทางที่ไม่รองรับโดยไม่ทิ้ง optimization เดิมของฟอร์ก
  • แทนที่จะเขียน C++ kernel fallback เอง ผู้ใช้รับหน้าที่รันการทดลอง อ่านเอาต์พุต ตั้งคำถามถัดไป และตัดสินว่าอะไรคือ เกณฑ์ของผลลัพธ์ที่ถูกต้อง
  • การวินิจฉัยและแพตช์ถูกทำโดยอินสแตนซ์ของ Claude ที่รันอยู่บนเซิร์ฟเวอร์เครื่องนั้นเอง

เส้นทางโอเปอเรชันที่พังในบิลด์ non-AVX2

  • ik_llama.cpp ที่ใช้สำหรับรัน Gemma 4 MoE เป็นฟอร์กของ llama.cpp และโดยพื้นฐานตั้งสมมติฐานว่า AVX2 คือขั้นต่ำ
  • หากปิด GGML_USE_IQK_MULMAT ตอนบิลด์ เส้นทางความเร็วสูงส่วนใหญ่จะถูกตัดออกและ fallback ไปใช้การคำนวณ scalar/SSE ทั่วไป
    • fallback นี้ใช้ได้กับการคูณเมทริกซ์ Q8_0 ทั่วไป
    • แต่มีโอเปอเรชันกราฟอยู่สองตัวที่ไม่ได้มี fallback
  • เครือข่าย feedforward แบบ MoE ของ Gemma 4 สร้างโอเปอเรชันดังนี้
    • MOE_FUSED_UP_GATE: โอเปอเรชันที่รวมการคูณเมทริกซ์ gate·up ราย expert กับ SwiGLU
    • FUSED_UP_GATE: เวอร์ชัน dense สำหรับเลเยอร์ที่ไม่ใช่ MoE
  • โอเปอเรชันสองตัวนี้ใน compute dispatcher ถูกครอบด้วยเงื่อนไข GGML_USE_IQK_MULMAT แต่ ตัวสร้างกราฟกลับสร้างมันเสมอโดยไม่มีเงื่อนไข
    • ใน dispatcher ของบิลด์ non-AVX2 ไม่มี case ที่จัดการ enum นี้
    • เมื่อโอเปอเรชันตกไปยังสาขาค่าเริ่มต้น เทนเซอร์ปลายทางของ feedforward network ของ expert ทั้งหมดจึงเงียบ ๆ ไม่ถูกคำนวณ
  • Gemma 4 26B ใช้ expert ที่ active 8 ตัวต่อโทเคนใน 30 เลเยอร์ ดังนั้นในแต่ละรอบ forward จึงมีการใช้เทนเซอร์ราว 240 ตัว ที่บรรจุค่าค้างจากบัฟเฟอร์หน่วยความจำ

เบาะแสที่ปรากฏจากเอาต์พุตที่อ่านไม่รู้เรื่อง

  • เอาต์พุตที่ผิดพลาดดูเหมือนคล่อง แต่เป็นสตริงหลายภาษาที่ไม่มีความหมาย
    • token ID กระจายเกือบสม่ำเสมอทั่วทั้งคำศัพท์ 262,000 รายการ
    • มีทั้งภาษาไทย ภาษาเกาหลี sentinel <unused> และเศษภาษาอังกฤษออกมาด้วยความถี่ใกล้กัน
  • ที่อุณหภูมิ 0 เอาต์พุตเป็นแบบกำหนดแน่นอน และผลจากการรันแบบเธรดเดียวกับหลายเธรดก็เหมือนกันทุกไบต์ อีกทั้ง ไม่เกิด NaN
  • แต่ละเลเยอร์ดูเหมือนมีค่าคงที่ขนาดใหญ่ดัน hidden state ทำให้ softmax สุดท้ายแบนราบ
  • Claude ใส่การวัด raw logits ก่อนการ sampling เพื่อพิมพ์ 5 โทเคนบนสุด, ช่วงค่า, ค่าเฉลี่ย และจำนวน NaN
    • ค่าเฉลี่ย logit ของโทเคนแรกที่ทำนายไม่ได้อยู่ใกล้ 0 แต่เป็น +16
    • ราว 80% ของทั้งคำศัพท์มี logit เป็นบวก
  • เพราะอคตินี้คงที่ ไม่ใช่ความเสียหายแบบสุ่ม จึงสรุปวงแคบลงได้ว่ามีส่วนใหญ่ของ hidden state ใช้ หน่วยความจำที่ยังไม่ถูก initialize ซึ่งเหลือค่า floating-point บวกขนาดเล็กค้างอยู่

การแก้ไข 3 ขั้น

  • แพตช์นี้ประกอบด้วย 3 คอมมิตบนยอดของ main ของฟอร์ก

  • แก้การคอมไพล์ non-AVX2

    • สาขา scalar #else ใน quantize_row_q8_0_x4 และ quantize_row_q8_1_x4_T ของ iqk_quantize.cpp อ้างอิง helper ของ AVX2 อย่าง hsum_i32_8 อยู่จริง
    • จึงเขียนสาขาเหล่านั้นใหม่เป็น ลูป scalar ที่พกพาได้
    • เพิ่มเงื่อนไขครอบ #if GGML_USE_IQK_MULMAT ให้กับบาง IQK call ที่เล็ดรอดไปยัง ggml.c และ ggml-quants.c
    • เพิ่ม include ที่ขาดเพื่อให้ iqk_cpu_ops.cpp คอมไพล์ได้อย่างอิสระ
    • ถ้าไม่มีการแก้นี้ ฟอร์กจะคอมไพล์บนฮาร์ดแวร์ non-AVX2 ไม่ได้เลย

  • fallback ของกราฟตอนรัน

    • แทนที่จะแก้ dispatcher จึงเปลี่ยนให้ตัวสร้างกราฟสร้างโอเปอเรชันที่บิลด์นั้นมีเส้นทางคำนวณอยู่แล้ว
    • ใน ggml_moe_up_gate จะจัดการน้ำหนัก up_gate_exps ที่ถูก fused เมื่อ GGML_USE_IQK_MULMAT ถูกปิด
    • รูปร่างของเทนเซอร์คือ [n_embd, 2*n_ff, n_experts] โดยครึ่งแรกคือ gate และครึ่งหลังคือ up
    • แยกมันด้วย ggml_view_3d สองชิ้น
    • รัน ggml_mul_mat_id กับแต่ละชิ้น
    • รวมผลทั้งสองด้วย ggml_fused_mul_unary(gate, up, SILU)
    • หากน้ำหนัก gate และ up ถูกแยกอยู่แล้ว ก็ใช้ ggml_mul_mat_id สองครั้งและ fused mul-unary โดยไม่ต้อง slice
    • ใช้ fallback แบบเดียวกันกับ ggml_fused_up_gate ที่ใช้ในเลเยอร์ non-MoE
    • mul_mat_id ใช้อิมพลีเมนเทชัน ggml พื้นฐาน ส่วน fused_mul_unary จัดการ SILU และการคูณในครั้งเดียว ดังนั้นโอเปอเรชันย่อยทั้งหมดจึงมี อิมพลีเมนเทชันที่ไม่พึ่ง IQK อยู่แล้ว
    • การเปลี่ยนทั้งหมดอยู่หลัง #if !GGML_USE_IQK_MULMAT จึงทำให้ผลบนบิลด์ AVX2 ยังคงเหมือนเดิมทุกบิต

  • เก็บกวาด CI stub

    • #else stub ในซอร์ส IQK ไม่ตรงกับ iqk_mul_mat.h ทำให้แม้แต่ ci/run.sh ก็ยังคอมไพล์ไม่ได้บนฮาร์ดแวร์ non-AVX2
    • ขาด include ของ <cstdint>
    • บาง stub มีพารามิเตอร์นำหน้าที่ไม่จำเป็น หรือไม่มีพารามิเตอร์ sinks ทำให้ signature ไม่ตรงกัน
    • บางฟังก์ชันไม่มี stub เลย ทำให้ขั้นตอนลิงก์เจอ undefined reference
    • เมื่อปรับ stub ให้ตรงกับ header ก็สามารถ รัน test suite บนสภาพแวดล้อม non-AVX2 ได้

ต้นทุนด้านประสิทธิภาพของ fallback และบั๊กจาก repack

  • fallback นี้มีต้นทุนเพิ่ม เพราะรัน mul_mat_id สองครั้งแทน fused kernel เดียว
  • อย่างไรก็ดี CPU นี้ติดข้อจำกัด แบนด์วิดท์หน่วยความจำ อยู่แล้ว และ fused kernel เดิมก็ใช้ได้เฉพาะ AVX2 ดังนั้นในสภาพแวดล้อมนี้จึงไม่ได้เสียเส้นทางรันเดิมที่เคยมีอยู่
  • ประสิทธิภาพสุดท้ายบน 26B-A4B MoE คือถอดรหัสราว 5.2 โทเคน/วินาที และประเมินพรอมป์ตราว 16 โทเคน/วินาที
  • --run-time-repack จะจัดเรียงน้ำหนักที่ควอนไทซ์ใหม่ตอนเริ่มต้นให้เป็นรูปแบบ interleave เฉพาะ AVX2 คือ Q8_0_R8
    • นี่เป็น บั๊กอีกตัวหนึ่ง ที่ทำให้เอาต์พุตเสียหายอีกครั้งในสภาพแวดล้อม AVX1
    • แพตช์ปัจจุบันยังไม่แก้เรื่องนี้ และตัดแฟล็กดังกล่าวออกจากสคริปต์รัน

กระบวนการไล่หาต้นเหตุ

  • ความไม่ตรงกันของชุดคำสั่งตรวจพบได้ไม่ยาก แต่ปัญหาที่ dispatcher ตกไปยังสาขาค่าเริ่มต้นโดยไม่แจ้ง error นั้นหายากกว่า
  • มีการตัดตัวเลือกผู้ต้องสงสัยออกหลายตัวผ่านการรีวิวโค้ด
    • helper ของ RMSNorm ดูถูกต้อง
    • fallback แบบ AVX1 ของ ggml_vec_dot_q8_0_q8_0 ก็ดูถูกต้อง
    • ผลแบบเธรดเดียวตรงกันทุกบิต จึงตัดปัญหาเรื่อง threading ออกได้
  • จากการที่ค่าเฉลี่ย logit ค้างอยู่ที่ +16 และโทเคนหางยาวหลายตัวมีค่าใกล้กัน จึงสรุปว่ามีส่วนใหญ่ของ residual stream ที่ยังไม่ได้ถูก initialize
  • หลังค้นหา #if GGML_USE_IQK_MULMAT ใน dispatcher ก็พบสองเส้นทางโอเปอเรชันที่หายไปภายในเวลาราว 1 นาที

เงื่อนไขการทำซ้ำและขอบเขตการใช้งาน

  • เงื่อนไขสำหรับทำซ้ำบนอุปกรณ์ก่อนยุค AVX2 มีดังนี้
    • ฮาร์ดแวร์: Xeon E5-2690 v2 แบบคู่, Ivy Bridge, AVX1, DDR3, ไม่มี GPU
    • บิลด์: คอมไพล์ ik_llama.cpp จากแพตช์แบรนช์โดยไม่ใช้ GGML_USE_IQK_MULMAT
    • โมเดล: Gemma 4 26B-A4B Q8_0
    • การรัน: ใช้แฟล็ก CPU ทั่วไปของ ik_llama.cpp แต่ตัด --run-time-repack ออก
  • รายละเอียดการเปลี่ยนแปลงแบบครบถ้วนดูได้ที่ ikawrakow/ik_llama.cpp PR #2138
    • ณ เวลาที่เขียน PR ยังเปิดอยู่และรอตรวจโดยผู้ดูแล จึงต้องรันจากแบรนช์โดยตรง
    • หากพบบั๊กแบบเดียวกันบนฮาร์ดแวร์ใกล้เคียง ก็สามารถรายงานในเธรดของ PR ได้
  • การเก็บโมเดลโลคัลไว้บนเซิร์ฟเวอร์องค์กรรุ่นเก่า สามารถใช้เป็นทางเลือกเมื่อ API แบบเสียเงินหยุดให้บริการ หรือใช้จัดการงานแบตช์ช้าที่การคิดเงินต่อโทเคนไม่คุ้มค่า
  • แนวคิดนี้ให้ความสำคัญกับความสามารถในการลงลึกกับโค้ดที่ไม่คุ้นเคยและระบบเก่า มากกว่าการพึ่งบริการแบบสมัครสมาชิก ซึ่งใช้แนวทางเดียวกันได้กับการดูแลแอป Rails อายุ 15 ปี หรือฐานข้อมูลที่คนรับผิดชอบเดิมลาออกไปแล้ว

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • คาดว่าภายในกลางปี 2027 จะสามารถรัน โมเดลผู้เชี่ยวชาญผสม (MoE) ที่มีมากกว่า 200,000 ล้านพารามิเตอร์ บนฮาร์ดแวร์สำหรับผู้บริโภคทั่วไปได้
    ตอนนี้รัน Qwen3.6-35B-A3B แบบโลคัลบน Mac 16GB ได้ 7–9 โทเคนต่อวินาที: https://github.com/deepanwadhwa/samosa-chat
    เท่ากับว่าโมเดลระดับ GPT-4 รันแบบโลคัลบน MacBook Air RAM 16GB ได้ที่ความเร็วประมาณนี้

    • อาจไม่ต้องรอถึงตอนนั้นก็ได้ Prism เพิ่งเปิดตัว โมเดลน้ำหนักแบบ ternary Bonsai 27B เมื่อไม่กี่วันก่อน ซึ่งมีขนาดเพียงราว 7GB และทำได้มากกว่า 44 โทเคนต่อวินาทีบนแล็ปท็อป M4 Max: https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit
      ตอนนี้ก็อยู่ในช่วงใกล้เคียงกับจำนวนพารามิเตอร์ที่ active ของโมเดลส่วนใหญ่ที่มีตั้งแต่ 200,000 ล้านขึ้นไปแล้ว ดังนั้นถ้า Prism ตั้งใจ ก็น่าจะปล่อยโมเดลแบบนั้นออกมาได้ อย่างไรก็ตาม โครงข่ายประสาทแบบวนซ้ำ อย่าง HRM ไม่จำเป็นต้องใช้พารามิเตอร์มากขนาดนั้น จึงยังถกเถียงได้ว่าจำเป็นต้องมีขนาดระดับนั้นจริงหรือไม่: https://huggingface.co/sapientinc/HRM-Text-1B
    • 7–9 โทเคนต่อวินาที ไม่น่าถือว่าเป็นความเร็วที่ดีนัก ผมไม่ใช่ผู้เชี่ยวชาญ แต่จากที่ลองเล่นแบบโลคัล ถ้าช้ากว่า 12–16 โทเคนต่อวินาทีก็รู้สึกอึดอัดแล้ว
    • โดยรวมเห็นด้วยกับการคาดการณ์ แต่คิดว่าเวลาอาจช้ากว่านั้นเล็กน้อย การจะได้ผลแบบนี้ต้องมีการบีบอัดที่ต่างไปจากการลดจำนวนบิตต่อพารามิเตอร์แบบปัจจุบันอย่างสิ้นเชิง และในสถานการณ์นั้น ตัวชี้วัดเดิมอย่าง จำนวนพารามิเตอร์ เองก็อาจไม่มีความหมายแล้ว
      เช่น ถ้าแต่ละเลเยอร์มีเพียง seed 256 บิตหนึ่งตัว แล้วป้อนเข้า noise function เพื่อสร้างน้ำหนักจริง 16K ตัว ก็จะลดขนาดจัดเก็บต่อน้ำหนักหนึ่งตัวให้ต่ำกว่า 1 บิตได้
    • กำลังรัน Ornith 35B บน Pi แล้วได้ มากกว่า 50 โทเคนต่อวินาที หลังจากรู้ว่า Pi รองรับทั้งการค้นหาและการดึงข้อมูล ก็ไม่จำเป็นต้องหาโมเดลใหญ่สำหรับงานค้นหาแล้ว
      คาดว่าเดือนนี้และเดือนหน้าจะมีโมเดลใหม่ ๆ ที่เปลี่ยนเกมออกมาต่อเนื่อง น่าตื่นเต้นมาก Ornith คุ้มค่าที่จะลองแน่นอน
    • 9 โทเคนต่อวินาที น่าจะทนได้ยากนะ ในเซสชัน Claude ใช้ 1 ล้านโทเคนภายในไม่ถึงวันเป็นเรื่องปกติ ดูช้าเกินไปสำหรับงานจริง

  • บางคนอาจไม่อยากฟัง แต่ผมคิดว่าค่าโทเคนของผู้ให้บริการ inference ถูกกว่าค่าไฟในการรันโลคัล
    เพื่อให้คำนวณง่าย หากนับเฉพาะการสร้างเอาต์พุต 5 โทเคนต่อวินาทีคือ 18,000 โทเคนต่อชั่วโมง และค่าใช้จ่ายกับผู้ให้บริการอยู่ที่ประมาณ 0.005 ดอลลาร์ หากสมมติว่าเซิร์ฟเวอร์ใช้ไฟราว 500W ขณะ inference และอิงค่าไฟในเยอรมนีที่ 0.3 ดอลลาร์ต่อ kWh การสร้างปริมาณเท่ากันแบบโลคัลจะมีค่าใช้จ่าย 0.15 ดอลลาร์ หรือ แพงกว่า 30 เท่า
    หากกังวลเรื่องความเป็นส่วนตัว การรันโลคัลก็ยังดีอยู่ แต่ควรรู้ไว้ว่ามันไม่มีประสิทธิภาพกว่าผู้ให้บริการ inference มาก GPU รุ่นใหม่จะยิ่งเพิ่มประสิทธิภาพ inference และทำให้ช่องว่างนี้กว้างขึ้นมาก
    ตอนแรกผมคำนวณผิดเป็น 180,000 โทเคน แต่จริง ๆ คือ 18,000 โทเคน ดังนั้นถ้าไม่ได้ใช้ไฟแทบฟรีก็แข่งขันยาก ผู้ให้บริการก็น่าจะยังใช้ H200/H100 กับโมเดลขนาดเล็กอยู่ แต่ถ้าเปลี่ยนเป็น GB300 หรือ Ruby GPU ปีหน้า ต้นทุน inference อาจลดลงเหลือ 1 ใน 30 และคุณค่าหลักของโมเดลโลคัลน่าจะกลายเป็นเรื่องการปกป้องความเป็นส่วนตัว

    • ถ้ารัน Qwen 27B ที่บ้าน จะใช้ไฟประมาณ 400W ระหว่างทำงาน สร้างข้อความได้ราว 40 โทเคนต่อวินาที และการประมวลผลพรอมป์ต์ซึ่งสำคัญกว่านั้นได้ราว 1,000 โทเคนต่อวินาที
      ในหนึ่งชั่วโมงจะประมวลผลอินพุตได้ 3.6 ล้านโทเคน หรือสร้างได้ 144,000 โทเคน โดยค่าไฟอยู่ราว 0.15 ดอลลาร์ ถ้าใช้ Sonnet กับปริมาณเท่ากัน อินพุตจะอยู่ที่ 7.2 ดอลลาร์ และการสร้างข้อความ 1.4 ดอลลาร์ ดังนั้นคลาวด์แพงกว่า 10 เท่าในการสร้างข้อความ และแพงเกือบ 50 เท่า ในการประมวลผล
    • ในสหรัฐฯ ค่าไฟไม่ได้ใกล้ 0.30 ดอลลาร์ต่อ kWh เลย ช่วงเวลาที่ใช้ไฟน้อยก็เหลือครึ่งหนึ่ง และยังสามารถลงทุน 1,000 ดอลลาร์กับแบตเตอรี่เพื่อเก็บ ไฟราคา 0.11 ดอลลาร์ จากช่วงเวลาถูกพิเศษได้
      ผู้ให้บริการ inference กำลังแบกหนี้มหาศาลและแข่งกันแย่งส่วนแบ่งตลาด ดังนั้นราคาต้องขึ้นแน่นอน
    • ถ้าสร้าง เซิร์ฟเวอร์ LLM self-hosted แบบอิสระ ที่ทำงานด้วยพลังงานแสงอาทิตย์และแบตเตอรี่คงจะเท่มาก คล้าย Low Tech Magazine คือออฟไลน์เมื่อแสงแดดไม่พอ และสร้างในขนาดที่ชุมชนท้องถิ่น เช่น กลุ่มเพื่อน ถนน หรือชมรม ใช้งานได้ทุกวัน
      ถ้าทำให้ AI เป็นประชาธิปไตยมากพอที่ชุมชนควบคุมเองได้ ก็จะแก้ปัญหาศูนย์ข้อมูลได้ และชุมชนยังสามารถกำหนดระดับการเซ็นเซอร์และการ alignment ได้อย่างเป็นประชาธิปไตยด้วย เป็นแนวคิดคล้ายงานเขียนบางส่วนของ Geohotz
      โมเดลโอเพนซอร์สจะดีและมีประสิทธิภาพพอในไม่ช้า จนสามารถให้บริการราคาถูกบนฮาร์ดแวร์มือสองได้ แค่มีคนที่รู้เทคโนโลยีหนึ่งคนในแต่ละชุมชนเล็ก ๆ รวบรวมค่าใช้จ่ายเริ่มต้นไม่กี่ร้อยดอลลาร์ หลังจากนั้นก็แทบใช้ฟรีโดยไม่มีค่าไฟ
      https://solar.lowtechmagazine.com/
    • ประสิทธิภาพก็สำคัญ แต่ก็มีคนจำนวนมากที่มีไฟราคาถูกหรืออุปกรณ์ที่มีประสิทธิภาพ บนโฮมเซิร์ฟเวอร์ AMD Strix Halo สามารถให้บริการ Gemma4-26B ได้ประมาณ 70 โทเคนต่อวินาที โดยใช้ไฟแค่ 100W
    • ผมไม่สนว่าจะแพงกว่าหรือไม่ เหตุผลที่รันโลคัลไม่ใช่เพื่อประหยัดเงิน แต่เพื่อให้ได้ เสรีภาพและความเป็นส่วนตัว และเมื่อมีทางเลือกอยู่ ในระยะยาวต้นทุนก็จะลดลงด้วย
      ถ้าไม่มีทางเลือกแบบโลคัล ราคาของโมเดลคลาวด์คงแพงกว่านี้มาก

  • Xeon คู่เจเนอเรชันนี้มีแนวโน้มจะกินไฟ มากกว่า 300W เมื่อมีโหลด คิดตามค่าไฟเฉลี่ยของสหรัฐฯ ก็วันละ 1.35 ดอลลาร์ และถ้าต้องเปิดแอร์ทำความเย็นให้ห้องในฤดูร้อนก็จะมากกว่านั้น
    แม้จะไม่คิดเวลาประมวลผลพรอมป์ต์และปล่อยรัน 24 ชั่วโมง ก็ได้เพียงราว 400,000 โทเค็นต่อวัน ดังนั้นต้นทุนจึงอยู่ที่ประมาณ 0.30 ดอลลาร์ต่อเอาต์พุต 1 ล้านโทเค็น บังเอิญเท่ากับราคาของโมเดลนี้บน OpenRouter ในตอนนี้ แต่ความเร็วในการสร้างของ OpenRouter เร็วกว่า 8 เท่า
    มีเหตุผลมากมายที่จะทดลองใช้ LLM แบบโลคัล เช่น ไม่ให้ข้อมูลออกนอกบ้าน แต่ถ้ามองในแง่เงินแล้วคงยากที่จะได้กำไร จากมุมมองของคนที่ลงทุนกับอุปกรณ์ inference แบบโลคัลที่บ้านไปมากกว่านี้เยอะ ผมมองว่ามันสนุก แต่ไม่ใช่วิธีประหยัดเงิน

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

  • สรุปผลการรันหลายโมเดลบน Xeon คู่กับ DDR4 256GB โดยไม่มี GPU ไว้แล้ว
    https://gist.github.com/hparadiz/f3596d00a62d8ebb2dadcc46ee5822c7

    • อยากรู้ว่าได้ลองใช้ CPU แค่ตัวเดียวเพื่อกำจัด ประสิทธิภาพตกจาก NUMA หรือยัง แม้จะใช้หน่วยความจำได้แค่ครึ่งเดียว แต่อยากรู้ว่าประสิทธิภาพต่างกันแค่ไหน
    • ดูเหมือนว่าถ้ามี RAM ช้า ๆ จำนวนมาก โมเดลขนาดเล็กก็รันได้ค่อนข้างเร็ว อยากรู้ว่า โมเดลที่ใหญ่กว่านี้ จะทำงานบนเครื่องนี้อย่างไร

  • ถือว่าค่อนข้างช้า ผมได้ 8–12 โทเค็นต่อวินาทีแม้บน CPU อายุ 13 ปี และอาจแตกต่างกันตามขนาดคอนเท็กซ์กับการตั้งค่าอื่น ๆ
    https://news.ycombinator.com/item?id=48354801

    • แม้ใช้ Xeon E3-1270 V2 3.50GHz กับ Nvidia Quadro K2200 4GB รุ่นเก่า ก็ยังได้ 8–9 โทเค็นต่อวินาที กำลังรัน gemma4:e2b และ gemma4:12b-it-qat บน Ollama
    • ต่างกันตรงที่บทความต้นฉบับใช้ quantization แบบ Q8 ส่วนกรณีนี้ใช้ Q4 ไม่ใช่หรือ?

  • ผมเป็นผู้เขียนบทความต้นฉบับ ดูเหมือนคอมเมนต์เดิมจะถูกแจ้งรายงานด้วยเหตุผลบางอย่าง ผมเปิดการแก้ไขไว้เป็น PR #2138 ของโปรเจกต์ต้นทางแล้ว: https://github.com/ikawrakow/ik_llama.cpp/pull/2138

  • เครื่อง StoreVirtual นี้ดูเหมือนจะไม่มีพอร์ตที่เหมาะสำหรับติดตั้งซอฟต์แวร์ มีแค่พอร์ต USB ประมาณนั้น เลยสงสัยว่าติดตั้งผ่านคอนโซลแบบ serial หรือเปล่า

  • ผมรัน Gemma 4 26B บน Mac Pro ปี 2013 ด้วยคอนฟิกเดียวกัน และได้ประมาณ 5 โทเค็นต่อวินาที การ์ดจอคู่ไม่มีประโยชน์กับงานนี้ แต่สำหรับบางงานก็ยังใช้งานได้จริงพอสมควร

    • สัปดาห์ก่อนผมเผลอซื้อ Mac Pro ทรงกระบอกจาก eBay แบบหุนหันพลันแล่นในราคา 120 ดอลลาร์ แล้วเพิ่งมารู้ว่าช่วงนี้คนเริ่มรันโมเดลบน GPU ภายในได้ 20–30 โทเค็นต่อวินาทีแล้ว
      มันจะมาถึงวันศุกร์ เลยตื่นเต้นที่จะลองเอง
      https://echalupa.com/blog/mac-pro-6-1-llama-cpp-firepro-d300-vulkan-ubuntu
      https://matthewgribben.com/blog/mac-pro-6-1-llama-cpp-firepro-d700-vulkan-ubuntu
    • ด้วยความเร็วที่ช้าขนาดนั้น อยากรู้ว่ามีประโยชน์กับงานแบบไหน

  • ได้เห็นชุดเครื่องในชั้นใต้ดินด้วยตาตัวเองแล้ว สุดยอดจริง ๆ คราวหน้าช่วยแนะนำ เครื่องพิมพ์ 3D ด้วยก็ดี

  • วิดีโอที่ค่อนข้างเกี่ยวข้อง เป็นการรัน LLM บน Pentium 4 และตั้งชื่อเล่นว่า NetburstGPT แน่นอนว่าช้ามาก
    https://www.youtube.com/watch?v=ILV-eu90te8