โน้ตบุ๊กอายุ 2.5 ปีของผมตอนนี้เขียน Space Invaders เป็น JavaScript ได้แล้ว (GLM-4.5 Air)

 (simonwillison.net)
3 คะแนน โดย GN⁺ 2025-07-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บน MacBook Pro M2 อายุ 2.5 ปี มีการใช้ โมเดล GLM-4.5 Air 3bit เพื่อสร้างโค้ดเกม Space Invaders ได้ในครั้งเดียว
  • โมเดลนี้เป็นโมเดล open weight รุ่นล่าสุดที่ Z.ai จากจีนเปิดเผยภายใต้สัญญาอนุญาต MIT และแสดงประสิทธิภาพที่โดดเด่นในเกณฑ์วัดด้านการเขียนโค้ด
  • ด้วย เวอร์ชัน quantized ขนาด 44GB แบบ 3bit จึงสามารถรันได้แม้บนพีซีที่มี RAM 64GB
  • มีการใช้ ไลบรารี ml-explore/mlx-lm จากคอมมิตล่าสุดเพื่อรันโมเดลแบบโลคัล และพบว่าทำงานได้ค่อนข้าง รวดเร็ว และเสถียร
  • โมเดลภาษาขนาดใหญ่สำหรับงานเขียนโค้ดแบบโลคัล ที่เพิ่งเปิดตัวเมื่อไม่นานมานี้กำลังพัฒนาอย่างรวดเร็วและแสดงความสามารถในการสร้างโค้ดในระดับสูงมาก

ประสบการณ์สร้าง JavaScript Space Invaders ด้วย GLM-4.5 Air และ MLX

29 กรกฎาคม 2025

ตระกูลโมเดล GLM-4.5 ที่แนะนำไปเมื่อวาน เป็น โมเดล open weight สมรรถนะสูงรุ่นล่าสุด ที่ Z.ai จากจีนเปิดเผยภายใต้สัญญาอนุญาต MIT
มีการประเมินว่าให้ ประสิทธิภาพสูง แม้เมื่อเทียบกับโมเดลที่มีอยู่เดิมอย่าง Claude Sonnet 4 ในเกณฑ์วัดด้านการเขียนโค้ด

แม้แต่โมเดล GLM-4.5 Air ซึ่งเล็กที่สุดก็ยังมี พารามิเตอร์รวม 106 พันล้านตัว และมีขนาดราว 206GB
Ivan Fioravanti ได้เผยแพร่เวอร์ชันที่ quantize เป็น 3bit เหลือ 44GB เพื่อให้รันบน โน้ตบุ๊กที่มีหน่วยความจำ 64GB ได้
เมื่อทดลองด้วยตัวเอง พบว่าแม้แต่โมเดลเล็กตัวนี้ก็ยังแสดง ประสิทธิภาพที่ทรงพลังมาก

พรอมป์ตที่ป้อน:

ป้อนพรอมป์ตที่ขอให้เขียนหน้าเว็บที่สร้าง Space Invaders ด้วย HTML และ JavaScript

โมเดลใช้เวลาสักเล็กน้อยในการสร้างคำตอบ และ ผลลัพธ์นี้ ก็ถูกสร้างออกมาได้สำเร็จ
แม้จะเป็นตัวอย่างระดับพื้นฐาน แต่การที่โน้ตบุ๊กอายุ 2.5 ปี (MacBook Pro M2 พร้อมหน่วยความจำ 64GB) สามารถสร้าง โค้ดที่สมบูรณ์และทำงานได้ตั้งแต่ครั้งแรก นั้นน่าประทับใจมาก

วิธีรันโมเดล

from mlx_lm import load, generate
model, tokenizer = load("mlx-community/GLM-4.5-Air-3bit")

  • น้ำหนักโมเดลขนาด 44GB จะถูกเก็บไว้ในโฟลเดอร์ ~/.cache/huggingface/hub/models--mlx-community--GLM-4.5-Air-3bit

  • ป้อนพรอมป์ตดังนี้เพื่อรันการสร้าง

prompt = "Write an HTML and JavaScript page implementing space invaders"
messages = [{"role": "user", "content": prompt}]
prompt = tokenizer.apply_chat_template(
    messages,
    add_generation_prompt=True
)
response = generate(
    model, tokenizer,
    prompt=prompt,
    verbose=True,
    max_tokens=8192
)
  • ในกระบวนการสร้าง โมเดลจะสรุปข้อกำหนดของปัญหาและข้อมูลการออกแบบเกมออกมาก่อน
  • จากนั้นจึงสร้างโค้ด HTML, CSS และ JavaScript ที่ใช้งานได้จริงด้วยความเร็วสูง

สถิติการสร้าง

  • พรอมป์ต: 14 โทเค็น, สร้างได้ 14.095 โทเค็นต่อวินาที

  • เนื้อหา: 4193 โทเค็น, สร้างได้ 25.564 โทเค็นต่อวินาที

  • การใช้หน่วยความจำสูงสุด: 47.687GB

  • ประวัติการสนทนาทั้งหมดอยู่ที่ ลิงก์ gist

  • ซอร์สโค้ดที่สร้างออกมาดูได้จาก ตัวอย่างบน GitHub

  • และสามารถ ทดสอบรัน ได้โดยตรงในเบราว์เซอร์

การทดสอบด้วยเกณฑ์วัด pelican

  • มีการประเมิน ความสามารถในการสร้างภาพ SVG ของโมเดลเดียวกันด้วยเกณฑ์วัด pelican riding a bicycle
  • สามารถสร้างโค้ดภาพ SVG เชิงสร้างสรรค์ได้สำเร็จจากพรอมป์ต Generate an SVG of a pelican riding a bicycle
  • โมเดลใช้ RAM สูงสุดราว 48GB ระหว่างส่งคืนผลลัพธ์
  • อาจต้องปิดบางแอปบนโน้ตบุ๊กเพื่อให้มีหน่วยความจำเพียงพอ
  • ความเร็วก็อยู่ในระดับที่น่าพอใจเช่นกัน

ความก้าวหน้าของโมเดลเขียนโค้ดแบบโลคัล

  • ในปี 2025 โมเดลภาษาขนาดใหญ่ส่วนใหญ่ต่างมุ่งเน้นที่การ เสริมประสิทธิภาพการสร้างโค้ด
  • ผลลัพธ์คือแม้บนฮาร์ดแวร์แบบโลคัลก็สามารถใช้งานจริงได้ พร้อม ความสามารถในการสร้างโค้ดระดับสูง
  • นี่ใกล้เคียงกับระดับที่ยากจะจินตนาการได้ในช่วงที่ LLaMA รุ่นแรกถูกทดลองเมื่อ 2 ปีก่อน
  • บนโน้ตบุ๊กเครื่องเดียวกันที่ใช้อยู่ตอนนี้ ก็สามารถได้รับประโยชน์จากโมเดลโอเพนซอร์สสมรรถนะสูงที่ทยอยออกมาอย่าง GLM-4.5 Air, Mistral 3.2 Small, Gemma 3, Qwen 3
  • ตลอด 6 เดือนที่ผ่านมา สภาพแวดล้อมการพัฒนากำลังดีขึ้นจากการเปิดตัว โมเดลภาษาคุณภาพสูงที่เน้นงานเขียนโค้ดและรันแบบโลคัล อย่างต่อเนื่อง

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

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

 
GN⁺ 2025-07-30
ความเห็นจาก Hacker News

  • ตอนที่ได้ลอง LLaMA ครั้งแรกเมื่อ 2 ปีก่อน ผมนึกภาพไม่ออกเลยว่าโมเดลอย่าง GLM 4.5 Air ที่เห็นตอนนี้ (Gemma 3, Qwen 3, Mistral 3.2 Small ฯลฯ) จะรันได้บนโน้ตบุ๊กที่ผมใช้อยู่ตอนนั้น ทั้งคุณภาพและความเร็วในการออกของโอเพนโมเดลนั้นเหนือความคาดหมายของผมไปมาก เอาแค่ว่า ตอนที่ ChatGPT ออกในเดือน 12 ปี 2022 โอเพนโมเดลที่ดีที่สุดในตอนนั้นคือ GPT-J (ราว 6~7B) กับ GPT-neoX (ประมาณ 22B?) ผมเคยเอา gpt-j ไปเปิดให้บริการกับผู้ใช้จริงอยู่เกือบเดือน คุณภาพแย่มากและแทบไม่ทำตามคำสั่งเลย ต้องเขียนพรอมป์ต์ให้เป็นเรื่องราวหรือใส่ตัวอย่างหลาย ๆ อันถึงจะพอใช้งานได้ จากนั้นพอโมเดล LLama “หลุด” ออกมา (ผมคิดว่าน่าจะเป็นการปล่อยแบบตั้งใจ) ประวัติศาสตร์ก็เปลี่ยนไป ยุค L1 มีทั้ง quantization, fine-tuning และการปรับแต่งอีกมากมาย พอมาถึง L2 การ fine-tuning ก็เริ่มใช้งานเชิงพาณิชย์กันจริงจัง (หลาย ๆ fine-tune ดีกว่าต้นฉบับของ Meta เสียอีก) หลังจากเดโม LoRA ของ Alpaca ก็มีทั้ง Mistral, Mixtral, L3, Gemma, Qwen, DeepSeek, glm, Granite และโมเดลทรงพลังอีกมากมายหลั่งไหลออกมา มีการวิเคราะห์บางชิ้นบอกว่าโอเพนโมเดลตามหลังโมเดลที่ห้องแล็บระดับ SotA ปล่อยออกมาราว 6 เดือน (และก็คาดกันว่าห้องแล็บเหล่านั้นไม่ได้ปล่อยโมเดลที่ดีที่สุด แต่เก็บไว้ใช้ภายใน เช่น เพื่อคัดสรรข้อมูลสำหรับการฝึกครั้งถัดไป) ระยะห่าง 6 เดือนนี่บ้าคลั่งจริง ๆ ผมนึกว่าจะต้องใช้เวลา 2 ปีกว่าจะไปถึงระดับ gpt-3.5 แต่ไม่เคยคิดเลยว่าจะมีวันที่เรารันโมเดลพวกนี้บนเครื่องตัวเองและยัง fine-tune เองได้ด้วย

    • ผมถามอยู่พักใหญ่ว่าการทำ LLM fine-tuning หรือ LoRA (parameter-efficient fine-tuning) เขาทำกันอย่างไร หรือใช้งานกันอย่างไร แต่ไม่เคยได้คำตอบที่มีประโยชน์จริง ๆ เลย และผลค้นหาเว็บก็เต็มไปด้วยบทความสาย SEO/โฆษณา ผมรู้วิธีสร้างและใช้งาน SD LoRA มาตั้งแต่ 2 ปีก่อนและใช้งานมันได้ดี แต่พอเป็น LLM LoRA กลับรู้สึกเหมือนทุกอย่างถูกซ่อนเป็นความลับ

    • Zuck (Mark Zuckerberg) คงไม่ได้เอาไปปล่อยเองบน 4chan หรอก

    • สงสัยว่า GLM 4.5 ดีกว่า Qwen3 coder หรือเปล่า

  • ผมยังทึ่งไม่หายที่ MacBook Pro M2 แรม 64GB ที่ซื้อมาเมื่อ 2.5 ปีก่อน สามารถสร้างโค้ดแบบนี้ได้ โดยเฉพาะอย่างยิ่งคือมันได้โค้ดที่รันได้ในครั้งเดียวโดยไม่ต้องแก้อะไรเลย ดูเหมือนเราจะประเมินศักยภาพของฮาร์ดแวร์ปัจจุบันต่ำไปมาก ผมกังวลว่าทั้งแนวคิด “Bitter lesson” (เวทมนตร์ขึ้นอยู่กับพลังประมวลผล) และกรอบคิดเรื่อง “ขอบเขตของการคำนวณที่มีประสิทธิภาพ” อาจยิ่งผลักคนเก่ง ๆ ให้ออกห่างจากการสำรวจแนวทางที่แหวกแนว ทั้งที่จริงแล้วเมื่อเห็นว่าโมเดลทุกวันนี้ลดความละเอียดของน้ำหนักหลังการฝึกลงอย่างหนักแล้วยังรักษาประสิทธิภาพไว้ได้ ก็ชวนให้คิดว่าเราอาจกำลังอยู่ฝั่งที่ไม่มีประสิทธิภาพมากกว่าด้วยซ้ำ

    • แก่นของ bitter lesson ไม่ใช่ว่าต้องมีข้อมูลจำนวนมากหรือ? โมเดลที่ยกมาเป็นตัวอย่างก็ฝึกจากคอร์ปัสขนาดมหึมาอย่าง 22 ล้านล้านโทเคนอยู่ดี

  • สงสัยว่าเขาเข้าใจผลลัพธ์ของการอิมพลีเมนต์นั้นจริง ๆ หรือแค่เห็นว่ามันรันได้ LLM เองก็น่าจะตอบคำถามสัมภาษณ์ยอดฮิตแบบคร่าว ๆ ให้ดูเหมือนถูกได้เหมือนกัน เพื่อนร่วมงานของผมเคยใช้ LLM ทำแอป visualise JSON ตอนต้องพรีเซนต์การเปลี่ยนแปลงข้อมูล ทั้งที่มี JSON viewer ที่ใช้งานได้ดีอยู่แล้ว ก็ยังสงสัยว่าทำไมต้องสร้างใหม่ด้วย ดูเหมือนในงานจริงคนใช้ LLM เพื่อเสริมการพรีเซนต์มากกว่าจะใช้เป็นเครื่องมือสำหรับงานใช้งานจริง อีกคนหนึ่งต้องการแมโครสำหรับแก้ไขเนื้อหาเอกสารการสอนจำนวนมาก แต่กลับเริ่มจากทำ rubric สำหรับพรอมป์ต์ LLM แล้วต่อด้วยสรุป requirement ของแมโครเป็นสไลด์พรีเซนต์ก่อนโยนกลับเข้า LLM อีกที ระบบมันซับซ้อนเกินไปจนผมไม่คิดว่ามันช่วยประหยัดเวลาได้จริง ผลลัพธ์ดูน่าทึ่งก็จริง แต่หลายครั้งก็ไม่มีประโยชน์อะไรกับคนอื่นเลย

    • ผมไล่ดูโค้ดและพอเข้าใจว่ามันทำอะไร แต่ถ้าแค่เห็นว่ามันรันได้ ผมก็ไม่ได้ลงลึกต่อ เวลาใช้ LLM เขียนโค้ดสำหรับ production ผมจะตรวจทุกบรรทัด และจะ commit ก็ต่อเมื่อเข้าใจมันอย่างสมบูรณ์พอที่จะอธิบายให้คนอื่นฟังได้ มีบทความที่อธิบายละเอียดว่าผมใช้ LLM กับการเขียนโค้ดจริงอย่างไร
      https://simonwillison.net/2025/Mar/11/using-llms-for-code/

    • ตัว LLM นั่นแหละคือโซลูชัน

    • จริง ๆ แล้วโค้ดใช้ครั้งเดียวทิ้ง (Disposable code) คือพื้นที่ที่ AI ฉายแววได้ดีที่สุด ถ้ามันช่วยปั่น boilerplate สำหรับระบบ build สุดเพี้ยนหรือโค้ดแอนิเมชันให้ได้เอง ผมยินดีมาก (พอนึกถึงแรงที่ 3Blue1Brown ลงไปกับงานแอนิเมชันแล้ว ถ้า AI ช่วยเรื่องนี้ได้ก็น่าเชียร์เต็มที่) การที่คนไม่รู้โปรแกรมมิงสามารถทำต้นแบบแล้วส่งต่อให้โปรแกรมเมอร์มืออาชีพได้ ถือเป็นคุณค่ามหาศาลจริง ๆ ไม่จำเป็นต้องเข้าใจรายละเอียดทุกบรรทัดของโค้ด แค่ตัดสินได้ว่าผ่านหรือไม่ผ่านก็พอ จึงมีประโยชน์ในทางปฏิบัติสูงมาก แต่ปัญหาที่มี “มูลค่าระดับหลายล้าน” กลับเป็นอีกแบบ เช่น การแก้บั๊กหรือเพิ่มฟีเจอร์ในบริการจริง ซึ่งตรงนั้น AI ยังชนข้อจำกัดอยู่ อีกด้านหนึ่ง โค้ดใช้ครั้งเดียวทิ้งเคยเป็นเครื่องมือเติบโตของนักพัฒนาจูเนียร์ แต่ตอนนี้ AI เข้ามาแย่งบทบาทนั้นไป ก็เป็นจุดที่น่าคิดเหมือนกัน

  • คาดว่าข้อมูลฝึกของโมเดลนี้น่าจะมี Space Invaders ที่เขียนด้วยภาษาต่าง ๆ อยู่เป็นจำนวนมหาศาล

    • บททดสอบจริงคือดูว่ามันรับมือกับคำขอแก้ implementation รายละเอียดได้ไหม เช่น “ช่วยแก้ฟังก์ชันให้ยานยิงลงล่างได้ ให้ศัตรูโผล่มาจากซ้าย/ขวา และเพิ่มโหมด 2 คนเล่น”

    • เป็นไปได้มากว่าข้อมูลบางส่วนก็มาจากกรณีที่โมเดลคัดลอกเกมที่มีอยู่ในชุดข้อมูลแล้วสร้างเป็นข้อมูลสังเคราะห์ขึ้นมาอีกที เวลาเห็นโค้ด React frontend ที่ LLM สร้าง ผมรู้สึกว่ามันออกมาคล้าย ๆ กันไปหมด

    • ประเด็นนี้จริง ๆ ถกจบกันไปตั้งแต่ 3 ปีก่อนแล้ว หลัง gpt3 เป็นต้นมา โค้ดที่ใช้งานได้แทบทั้งหมดก็อยู่ในข้อมูลฝึกกันหมด และเราใช้เวลาแค่ 2 ปีจากจุด “โค้ดดูเหมือนถูกแต่จริง ๆ ผิดหมด” มาถึงจุด “สร้าง full-stack app ที่รันได้จริงแบบ 0-shot ได้เลย” หัวใจของการก้าวกระโดดไม่ใช่แค่ชุดข้อมูล แต่คือ post-training, reinforcement learning (RL), context ที่ยาวขึ้น และพฤติกรรมแบบ agentic โมเดลยุคแรกติดข้อจำกัด 2/4k โทเคน แต่ตอนนี้เกมเปลี่ยนไปหมดแล้ว ถ้าจะพูดเรื่องข้อมูลอย่างเดียวโดยไม่มีมุมมองพวกนี้ ก็ถือว่าพลาดประเด็นไปเลย

    • ความคล้ายทางภาพกับเกม breakout ก็น่าสนใจดี

    • คอมเมนต์แบบนี้เองก็น่าจะมีโอกาสสูงมากที่จะกลายเป็นคอมเมนต์สังเคราะห์คล้าย ๆ กันแบบไร้การวิเคราะห์จริง แล้วถูกใส่เข้าไปในข้อมูลฝึกนับไม่ถ้วน

  • ผมใช้ M4 Mac พร้อมแรม 128GB และกำลังดาวน์โหลด GLM-4.5-Air-q5-hi-mlx (80GB) ผ่าน LM Studio เดี๋ยวจะมาแชร์ผลลัพธ์

  • ผมคิดว่าการโชว์ให้เห็นว่า LLM รันแบบโลคัลบนโน้ตบุ๊กได้มีความหมายมาก ในอดีตเรื่องแบบนี้แทบเป็นไปไม่ได้กับโมเดลเล็ก ๆ เลย จึงเป็นหมุดหมายสำคัญจริง ๆ แต่ถ้าเป็นโดเมนเฉพาะแคบ ๆ อย่าง Space Invaders ผมกลับคิดว่าการไปค้น implementation ที่มีอยู่แล้วบน GitHub แล้วดาวน์โหลดมาจะมีประสิทธิภาพกว่า เพราะในเคสแบบนี้ชุดฝึกเองก็เล็กมาก และเวกเตอร์สเปซของโมเดลก็คงมีขอบเขตจำกัด ทำให้มีโอกาสสูงที่โค้ดผลลัพธ์จะคล้ายต้นฉบับมากหรือแทบจะ copy-paste อยู่แล้ว แถมยังต้องรอให้โมเดลพิมพ์อีก มูลค่าเพิ่มจึงต่ำมาก ผมกลับรู้สึกว่าการสั่ง LLM ว่า “ช่วยหา source ของ Space Invaders ที่เขียนด้วยภาษา X บน GitHub ให้หน่อย” น่าจะฉลาดกว่า พอให้ ChatGPT จัดระเบียบโค้ดแบบนี้ มันตลกตรงที่ LLM มักถูกชักนำให้ท่องซ้ำข้ออ้างว่า “แทบไม่มี overfitting และโมเดลก็ไม่ได้จดจำข้อมูล” (ซึ่งส่วนตัวผมก็ไม่ค่อยเชื่อทั้งสองอย่าง)

    • ผมลองแล้วแต่ทำซ้ำข้อความเตือนนั้นบน ChatGPT ไม่ได้ จริง ๆ แล้วการแทรกคำเตือนแบบนี้มีแรงทางการเมืองสูงมาก (ไม่ว่าจะโดยตรงหรือผ่านการปรับใหม่เล็กน้อย) ซึ่งน่าสนใจมาก

  • ผมลองกับ Claude Sonnet 4 แล้ว แต่มันทำงานไม่ได้ถูกต้อง ดังนั้น GLM-4.5 Air ที่ quantize 3bit เลยดูเหนือกว่า ประวัติแชตที่เกี่ยวข้อง: https://claude.ai/share/dc9eccbf-b34a-4e2b-af86-ec2dd83687ea Claude Opus 4 ก็พอทำงานได้เหมือนกัน แต่ถ้าเทียบกับ GLM-4.5 ที่ Simon โพสต์ไว้ก็ยังตามหลังอยู่มาก: https://claude.ai/share/5ddc0e94-3429-4c35-ad3f-2c9a2499fb5d

  • ตอนแรกผมอ่านชื่อเรื่องผิดเป็น “ลูกวัย 2.5 ขวบของผมตอนนี้เขียน Space Invaders ด้วย JavaScript ได้แล้ว (GLM-4.5 Air)” แต่ผ่านไปอีกไม่กี่ปี มันอาจเป็นเรื่องจริงก็ได้

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

    • นี่แหละคือสมมติฐานพื้นฐานของงานวิจัย ML ของผมมาตลอด ถ้าเปลี่ยนคำว่า “รูหนอน” เป็น “genetic programming / neuroevolution ฯลฯ” ก็แทบจะเหมือนเดิม ซอฟต์แวร์แบบปรับแต่งสุดขั้วของ demoscene พาผมมาสู่เส้นทางนี้ ทุกวันนี้คำถามที่ผมถามอยู่เรื่อย ๆ คือ “Kolmogorov complexity ของไบนารีที่ให้ความสามารถทุกอย่างเทียบเท่า LLM รุ่นปัจจุบันจะเป็นเท่าไร?” ถ้าขนาดนั้นมันเล็กพอจะรันบนเดสก์ท็อปของผมตอนนี้ได้ ภาพที่ตามมาจะเป็นอย่างไร คอมผมปั่นเฟรม AAA ได้ 400fps ดังนั้นผมไม่เชื่อว่าความต่างระหว่างนั้นกับการที่ LLM พ่นข้อความ utf-8 ออกมาที่ 100b/s จะต้องมากขนาดนี้

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

  • สงสัยว่ามีเว็บที่รวบรวมฮาร์ดแวร์ขั้นต่ำ/แนะนำสำหรับการรัน local LLM ไหม แบบเดียวกับเอกสาร “system requirements” ของเกม

    • ใน LM Studio (และเครื่องมืออื่นอีกหลายตัว) การเลือกโมเดลที่เหมาะกับสมรรถนะฮาร์ดแวร์ทำได้ง่ายมาก

    • นอกจากคำตอบอื่น ๆ แล้ว กฎคร่าว ๆ ที่ดีคือ local model ส่วนใหญ่ให้ประสิทธิภาพดีที่สุดที่ q4 quantization (ต้องใช้หน่วยความจำมากกว่าครึ่งหนึ่งของจำนวนพารามิเตอร์ของโมเดลเล็กน้อย) เช่น โมเดล 14B จะใช้ประมาณ 8GB และเมื่อบวกพื้นที่สำหรับ context แล้ว 14B ก็ควรมี VRAM ราว 10GB จึงจะกำลังดี ถ้ามีทรัพยากรเหลือที่ q4 ก็ขยับไปใช้โมเดลพารามิเตอร์ใหญ่ขึ้น ถ้าไม่พอก็ลดระดับ quantization ลง แบบนี้ถือว่าเหมาะสม

    • ที่นี่ก็มีข้อมูลอ้างอิงด้วย
      https://www.reddit.com/r/LocalLLaMA/

    • ผมคิดว่าเว็บนี้มีประโยชน์มาก
      https://apxml.com/tools/vram-calculator

    • ถ้าคุณมีบัญชี HuggingFace คุณสามารถลงทะเบียนข้อมูลฮาร์ดแวร์ที่มีอยู่ แล้วดูได้ทันทีว่าแต่ละโมเดลรันได้หรือไม่