การรันโมเดลแบบโลคัลตอนนี้ดีขึ้นแล้ว
(vickiboykis.com)- แม้ในสภาพแวดล้อม M2 Mac รุ่นปี 2022 ประสิทธิภาพของ local LLM ก็ดีขึ้นจนใช้งานจริงได้สำหรับคำถามด้านการพัฒนา งานเขียนโค้ด และการตรวจเอกสาร
- โมเดลโลคัลยุคแรกช้า ใช้งานยาก และมีความแม่นยำต่ำในงานโปรแกรมมิง แต่หลัง GPT-OSS ความถี่ในการต้องกลับไปตรวจซ้ำด้วยโมเดล API ก็ลดลง
- หลังรีลีสล่าสุดในตระกูล Gemma 4 วงจร agent coding แบบโลคัลทำงานได้ที่ราว 75% ของความแม่นยำและความเร็ว เมื่อเทียบกับ frontier model
- การจับคู่ Pi กับ LM Studio ใช้ agent workflow ผ่าน local inference endpoint, model artifact และการตั้งค่าแยกสภาพแวดล้อมด้วย Docker
- โมเดลโลคัลยังคงมีข้อจำกัดเรื่อง latency ในการอนุมาน หน้าต่าง context ที่เล็ก และข้อจำกัดด้านฮาร์ดแวร์ แต่สามารถสังเกตและปรับแต่งการประมวลผลโทเค็น system prompt การ quantization และ harness ได้โดยตรง
สถานะปัจจุบันของโมเดลโลคัล
- โมเดลโลคัลยุคแรกช้า ใช้งานยาก และไม่แม่นยำสำหรับงานโปรแกรมมิงส่วนใหญ่
- การประเมินว่าโมเดลโลคัลยังตามหลังมากนั้น โดยรวมถือว่าถูกต้องสำหรับการใช้งานส่วนบุคคลจนถึงก่อนการเปิดตัว GPT-OSS
- เกณฑ์ส่วนตัวของคำว่า “ดีพอ” คือยังจำเป็นต้องกลับไปตรวจซ้ำด้วยโมเดล API หรือไม่ และ GPT-OSS เป็นโมเดลแรกที่ลดความถี่ของการตรวจซ้ำนี้ลงอย่างมาก
- จนไม่นานมานี้ โมเดลโลคัลถูกใช้เป็นหลักเหมือน Google แบบรวดเร็วและปรับให้เข้ากับตัวเองได้ สำหรับคำถามด้านการพัฒนาที่ไม่ต้องอาศัยข้อมูลล่าสุด
- หลังรีลีสล่าสุดในตระกูล Gemma 4 วงจร agent coding แบบโลคัลทำงานได้ที่ราว 75% ของความแม่นยำและความเร็วเมื่อเทียบกับ frontier model {p:75}
โมเดลและสภาพแวดล้อมที่ใช้
- มีการรันโมเดลโลคัลหลายตัวบนเครื่อง M2 Mac รุ่นปี 2022 พร้อม RAM 64GB และพื้นที่เก็บข้อมูล 1TB
- โมเดลที่ใช้ได้แก่ Mistral 7B, Gemma 3, OpenAI OSS-20B, Qwen 3 MOE, Qwen 2.5 Coder เป็นต้น
- ชุดการรันผ่านทั้ง raw llama.cpp, Open WebUI, llama-cpp-python, Ollama, llamafiles และ LM Studio
- โมเดลโลคัลหลักที่ใช้คือ อิมพลีเมนเทชัน
gemma-4-26b-a4bของ LM Studio
กรณีใช้งานจริงของงาน agent แบบโลคัล
- มีการรีแฟกเตอร์จากโน้ตบุ๊ก Python ไปเป็นรีโพซิทอรีที่มี 5~6 โมดูล
- โมดูลเหล่านั้นถูก lint ให้ใช้ generic type hints ตามเกณฑ์ของ PEP 585
- ยังใช้การตั้งค่าแบบโลคัลสำหรับการตรวจแก้บทความบล็อก การเขียน unit tests และการตั้งค่าเริ่มต้นของรีโพซิทอรีโมเดล two-tower สำหรับงานแนะนำ
- รีโพซิทอรีโมเดล two-tower ที่ agent สร้างขึ้นจากสถานะว่างยังเป็นพื้นฐาน แต่ก็เกินกว่าขอบเขตที่เคยคิดว่าเป็นไปได้เมื่อปีที่แล้ว
- ทุก agent workflow รันอยู่ภายใน Docker container ที่จำกัดสิทธิ์การเข้าถึงในการรันคำสั่ง
การใช้ทรัพยากรและโมเดลขนาดเล็กรุ่นใหม่
- งานที่ทำไม่ได้ถึงขั้นพลิกวงการ แต่ใกล้เคียงกับ Google แบบปรับให้เข้ากับตัวเองหรือการค้นเอกสารมากกว่า
- ระหว่างทำงาน ปริมาณการใช้ GPU และ RAM สูงขึ้น และ K-V cache ขยายไปถึง RAM 64GB
- แม้จะเป็นงานง่าย ๆ แต่งานโลคัลลักษณะนี้ยังเป็นสิ่งที่ทำไม่ได้เมื่อ 6 เดือนก่อน
Gemma-4-12b-qatสร้างความประทับใจด้านประสิทธิภาพต่อขนาดตั้งแต่ช่วงหลังเปิดตัว- สถาปัตยกรรมของโมเดลทำให้เกิดคำถามว่าต้องมีการประนีประนอมเชิงสถาปัตยกรรมแบบใดเมื่อมีข้อจำกัดด้านประสิทธิภาพและราคา
การตั้งค่าสำหรับรันโมเดล agent แบบโลคัล
- หากต้องการรัน local agent flow จำเป็นต้องมี local model inference engine, agent harness และ local model artifact
- ต้องตั้งค่า harness ให้ชี้ไปยัง local inference endpoint และต้องให้ model artifact ที่ดาวน์โหลดมาให้บริการผ่าน inference engine
- ปัจจุบันการตั้งค่าแบบโลคัลนี้ใช้ Pi เป็น agent harness และ LM Studio เป็น inference server
- มีการอ้างอิง บทความการตั้งค่า Gemma 4 agent coding ด้วย Pi และ LM Studio แต่ปรับบางค่าต่างไป
- โมเดลที่ใช้ไม่ใช่
Gemma 26B A4Bตามบทความ แต่เป็นgemma-4-12b-qatที่ใหม่กว่า เล็กกว่า และเร็วกว่า โดยมีการสูญเสียความแม่นยำไม่มาก - เพื่อความปลอดภัย ทุกเซสชันของ Pi จะรันใน Docker container และให้สิทธิ์เฉพาะ bash เพื่อป้องกันการรันโค้ด Python และการท่องเว็บ
- สำหรับอิมเมจแยกที่ใช้กับงานวิจัย มีแผนจะอนุญาตให้ใช้ curl
- เนื่องจากรันอยู่ใน Docker จึงมีการแก้
models.jsonของ Pi เพื่อให้ Pi สื่อสารกับโมเดลได้
- โมเดลที่ใช้ไม่ใช่
วิธีแยกสภาพแวดล้อมด้วย Docker
- การตั้งค่า Pi ใช้
baseUrlเป็นhttp://host.docker.internal:1234/v1และตั้งค่า API เป็นopenai-completions - การตั้งค่า Docker Compose จะ mount
models.json, ไดเรกทอรีงาน, การตั้งค่า Pi และไดเรกทอรีเซสชันเข้าไปในคอนเทนเนอร์ - สคริปต์รันจะเชื่อมไดเรกทอรีงานปัจจุบันเป็น workspace ของคอนเทนเนอร์ และหากจำเป็นก็เพิ่มไฟล์ Compose สำหรับ sandbox ที่ปลอดภัยยิ่งขึ้น
- Pi รันอยู่ภายในรีโพซิทอรีที่กำลังทำงานและเป็นผู้เปิด Docker จึงไม่สามารถลบไฟล์หรือไดเรกทอรีบนดิสก์จริงได้โดยตรง
- สามารถส่งการตั้งค่า custom model
jsonเข้าไปในคอนเทนเนอร์ได้ ทำให้ในสภาพแวดล้อมทดลองทำงานได้ค่อนข้างดี
ข้อจำกัดที่ยังเหลืออยู่
- โมเดลโลคัลยังอาจอนุมานได้ช้า มีหน้าต่าง context เล็ก และ context ที่ใช้งานได้จริงยังถูกจำกัดด้วยฮาร์ดแวร์ที่มี
- ecosystem ใช้งานง่ายขึ้นมากด้วยเครื่องมืออย่าง LM Studio และปุ่ม Use This Model ของ Hugging Face
- รีลีสแรก ๆ มักเจอปัญหา prompt template ไม่ตรงกัน แต่ปัญหาแบบนี้มักถูกแพตช์อย่างรวดเร็วมาก
- ยังยากที่จะมั่นใจว่าโมเดลเหล่านี้พร้อมใช้งานทันทีสำหรับการพัฒนาซอฟต์แวร์ในระดับ production
ข้อดีและโอกาสในการทดลองของโมเดลโลคัล
- โมเดลโลคัลเปิดให้มองเห็นแทบทุกอย่างได้ และสามารถดูขั้นตอนการอนุมานโทเค็นแบบเรียลไทม์ได้
- สามารถตรวจสอบการไหลของโทเค็นขาเข้าและขาออกได้โดยตรง
- สามารถปรับหน้าต่าง context แบบโลคัลและดูได้ว่าประสิทธิภาพดีขึ้นหรือแย่ลงอย่างไร
- สามารถเจาะลึกวิธีที่โทเค็นถูกประมวลผลบน GPU รวมถึงเปลี่ยน system prompt และการตั้งค่า quantization ได้
- สามารถนำโมเดลมาแข่งกันเอง หรือเปลี่ยนค่าฝั่ง harness แล้วสังเกตผลได้ ทำให้ความเป็นไปได้ในการทดลองขยายกว้างขึ้นเรื่อย ๆ
1 ความคิดเห็น
ความเห็นจาก Hacker News
ไม่แน่ใจว่าดีขึ้นจริงไหม ถึงจะใช้โมเดลโลคัลบ่อย แต่การ รันแบบโลคัล ก็ยังค่อนข้างทรมานอยู่ดี
โมเดลแบบ dense อย่าง Qwen 27B, Gemma 31B ค่อนข้างฉลาดแต่ช้า ส่วนโมเดลแบบ mixture-of-experts (MoE) อย่าง Gemma 26B, Qwen 35B, North Mini Code 30B เร็วก็จริงแต่พลาดบ่อย
ถ้าจะรันให้ดีต้องใช้หน่วยความจำเยอะ และพอ quantize แล้วความสามารถในการเรียกใช้เครื่องมือก็จะแย่ลง คนส่วนใหญ่มักรันที่ 4-bit quantization แล้วสงสัยว่าทำไมผลงานไม่ดี ซึ่งจริง ๆ ก็แทบไม่ต่างจากการทำ lobotomy ให้โมเดลเลย แนะนำ Unsloth quantization และแนะนำ 6-bit สำหรับ MoE, 5-bit สำหรับโมเดล dense
ถ้าอยากให้ prefill เร็วต้องมีพลังประมวลผล ถ้าอยากให้ decode เร็วต้องมีแบนด์วิดท์ และถ้าอยากให้ใส่ทั้งโมเดลได้ก็ต้องมีหน่วยความจำมากด้วย แถมโน้ตบุ๊กก็จะกลายเป็นเครื่องร้อนและเสียงดังจนทำงานลำบาก
สรุปว่าดีไหม? ไม่ค่อยเท่าไร แต่มันก็ใช้งานได้
เพิ่มเติมคือผมคิดว่าโมเดลโอเพนคืออนาคต และยังมีส่วนช่วยใน ecosystem อยู่เรื่อย ๆ ผมอยากให้คนได้ลองจับโมเดลพวกนี้และใช้
piเพื่อเรียนรู้ว่ามันทำงานอย่างไร แต่ก็ไม่ควรคาดหวังว่าแค่ดาวน์โหลดโมเดลมาก็จะดีได้ทันที ถ้าอยากให้แทน “coding agent” แบบที่คนส่วนใหญ่ต้องการได้ ยังต้องจูนและตั้งค่าอีกมากโมเดลที่ไม่ได้ทำมาเพื่อโค้ดโดยเฉพาะมักติดอยู่ที่การพูดว่า “จะทำแบบนี้” โดยไม่เรียกใช้เครื่องมือจริง และพอถามว่าต้องตั้งค่าอะไรถึงจะเปลี่ยนพฤติกรรมนี้ได้ คำตอบก็ไม่ค่อยช่วยอะไร Qwen ถึงขั้นไม่เชื่อว่าตัวเองกำลังรันอยู่บน ollama และยืนกรานว่ากำลังรันบน Alibaba cloud พร้อมทั้งบอกว่าไม่มีสิทธิ์เข้าถึงระบบโลคัล
ส่วนโมเดลสำหรับเขียนโค้ดก็คิดได้เร็วกว่าอัตราที่ผมพิมพ์แค่นิดเดียว และกรณีที่มันสามารถแสดงกระบวนการคิดได้ก็ยังมีจำกัด
ประสบการณ์แบบ “ฟรี” ที่ดีที่สุดที่ผมเจอจนถึงตอนนี้คือ OpenCode + Big Pickle มันไม่ได้ฉลาดมากจนผลลัพธ์แรกถูกเสมอ แต่ free tier ให้มาเยอะมาก จนผมใช้บ่อยครั้งละหลายชั่วโมงอยู่ประมาณเดือนหนึ่ง แล้วชนข้อจำกัดแค่ราวสองครั้งเท่านั้น ถ้าเป้าหมายคือรันแบบโลคัลจริง ๆ มันอาจไม่ตอบโจทย์ แต่ถ้าเป้าหมายคือ “ประสบการณ์ที่ดีที่สุดโดยไม่ต้องจ่ายค่าสมาชิกหรือค่าโทเคน” ตอนนี้นี่คือทางเลือกที่แย่น้อยที่สุดเท่าที่เจอ
การพยายามรันบนอุปกรณ์อย่าง Mac แบบ unified memory, โปรเซสเซอร์ AMD AI Max หรือเครื่องแนว DGX Spark ดูใกล้เคียงกับการหาเรื่องลำบากใส่ตัว เพราะ prefill จะทำให้ประสิทธิภาพพัง
ถ้าใส่ GPU ที่เหมาะสมลงไปมันจะดีขึ้นมาก แต่ก็ยังไม่ถึงระดับ Sonnet หรือ DeepSeek 4 Flash และยิ่งห่างจาก Opus / DeepSeek Pro หรือ Mythos/Fable/GPT-5.5 มากขึ้นไปอีก
ถ้ามีงบประมาณ ไฟฟ้า และระบบระบายความร้อนเพียงพอ ก็สามารถรัน data pipeline ที่ค่อนข้างดีได้ แต่สำหรับงานโค้ด โดยมากการจ่ายเงินให้ผู้ให้บริการ API ก็ยังสมเหตุสมผลกว่า
ถึงอย่างนั้นมันก็ยังคุ้มที่จะลอง ถ้าคุณอยากลดการพึ่งพาบริการแบบรวมศูนย์อย่างหนัก
จากประสบการณ์ของผม มันทำงานตามกฎและงานสไตล์ automation ได้ดีกว่าโมเดล Qwen แม้กระทั่งรุ่น 100B+ การตีความภาพก็ดีมาก และบน benchmark ก็ออกมาสูงกว่า Opus
Qwen มีแนวโน้มจะเมินคำสั่ง และถ้าไม่จำกัดรูปแบบการสร้างโทเคนไว้อย่างชัดเจน ก็มักจะพ่นรูปแบบที่ผิดออกมาอย่างต่อเนื่อง
แต่ถึงอย่างนั้นบน DGX Spark, Gemma 31B Q4 + MTP ก็ยังได้แค่ประมาณ 20 tokens/s และ Gemma 26B A4B ได้ประมาณ 60 tokens/s ซึ่งก็ยังช้าอยู่พอสมควร บนการ์ด Nvidia ระดับสูงน่าจะรันได้เร็วกว่าเยอะและน่าจะใส่ลงหน่วยความจำได้ด้วย
สำหรับคนที่เริ่มเล่นโมเดลโลคัล ผมแนะนำให้โฟกัสที่ memory bandwidth มากกว่า RAM ตอนนี้โมเดลที่เล็กกว่า 100B ก็เพียงพอและมีประโยชน์มากแล้วสำหรับงาน automation
ผมเห็นด้วยว่าสำหรับงานเขียนโค้ด/งานสร้างสรรค์ ยังไม่มีเหตุผลที่แรงพอให้ต้องใช้โมเดลโลคัล แต่สำหรับงานอย่างไล่ดูรายการหุ้น, กรองข่าวแบบ high-pass, ตีความ log หรือแปลความ screenshot โมเดลโลคัลก็เพียงพอแล้ว
ดูเหมือนจะพอมีเหตุผลถ้าจะใช้ M6 Mac Studio พร้อม RAM ราว 256GB แล้วให้หลายคนเข้าถึงโมเดลเดียวที่ตกลงร่วมกันไว้ โน้ตบุ๊กดูร้อนเกินไปและอืดเกินไปสำหรับงานแบบนี้
หลังจากใช้ Qwen3.6-27B อย่างพอใจอยู่หลายสัปดาห์ พอตอนนี้อยู่ห่างจากฮาร์ดแวร์เลยต้องใช้ Claude Sonnet 4.6 แทน ซึ่งให้ความรู้สึกเหมือนดาวน์เกรดครั้งใหญ่
ไม่เข้าใจเหมือนกันว่าทำไมถึงเป็นแบบนี้ มันมีความเห็นแรง ๆ ที่ไม่ได้ขอเยอะเกินไป พูดมากเกินไป และโดยรวมรู้สึกว่าโง่กว่า
แน่นอนว่ามันเป็นโมเดลที่ใหญ่กว่ามาก เลยน่าจะเข้ารหัสความรู้ไว้มากกว่า แต่ถ้าไม่อยากคุยด้วยก็ไม่ได้ช่วยอะไร แถมเวลาคุยก็เสียเงินจริงอีก
เลยสงสัยว่าทำไมถึงไม่ชอบมันขนาดนี้ อาจเป็นเพราะมันมองตัวเองเกือบเหมือนเป็นสิ่งมีชีวิตที่เท่าเทียมกัน ไม่ใช่แค่เครื่องมือ เหมือนทำตัวราวกับว่าความเห็นของตัวเองมีน้ำหนัก
Qwen เองก็อาจทำตัวเหมือนเด็กฝึกงานที่ไฟแรงเกินไปได้ แต่ถ้าบอกว่ามันงี่เง่า มันก็ลดอีโก้ลงได้ ส่วน Claude อย่างน้อยจากประสบการณ์ของผม/ฉัน ไม่เป็นแบบนั้น
สรุปแล้วเห็นด้วยกับหัวข้ออย่างเต็มที่
ช่วงเดือนครึ่งที่ผ่านมาใช้แทบทุกวันบนเครื่อง M2 Ultra หรือ RTX 5090 ใช้มันกับงานเล็ก ๆ ธรรมดา ๆ ของ ggml-org [0] ไม่ได้เป็นอะไรยิ่งใหญ่ แต่เป็นเครื่องมือที่ช่วยเมนเทนเนอร์ได้จริง
ถ้าไม่ได้ใช้เวลาไปกับการรีวิว PR เยอะ ก็น่าจะใช้มันมากกว่านี้อีก ตอนนี้ใช้แค่ harness แบบเบามาก คือ pi agent ที่ถอดทุกอย่างออกแล้ว(
pi -nc --offline) กับ system prompt สั้น ๆ [1] เพื่อให้เข้ากับสไตล์ของผม/ฉันความเร็วในการสร้างอยู่ที่ประมาณ 100~150 โทเคน/วินาทีบน RTX 5090 และประมาณ 40 โทเคน/วินาทีบน Mac เพราะเครื่อง RTX เร็วกว่ามาก เลยชอบรันบนเครื่องนั้นชัดเจนกว่า แต่ก็ยังรันบน Mac บ่อย ๆ เพื่อทดสอบการตั้งค่าแบบโลคัลและเก็บประสบการณ์ที่กว้างขึ้น
[0] - https://github.com/search?q=%22Assisted-by%22+user%3Aggml-or...
[1] - https://github.com/ggml-org/llama.cpp/blob/master/.pi/gg/SYS...
มันอาจด้อยกว่า Opus ในงานแบบ “ช่วยเพิ่มฟีเจอร์ใหญ่ X ให้หน่อย” แต่ผม/ฉันไม่ได้ต้องการแบบนั้นจากโมเดล ผม/ฉันคิดเอง แล้วให้โมเดลช่วยพิมพ์ให้ Qwen 3.6 27B เพียงพอกับงานนั้นอย่างสมบูรณ์ จากประสบการณ์ของผม/ฉัน 35A3B หรือสาย Gemma ถือว่าเป็นการดาวน์เกรดพอสมควร
แถมยังไม่ต้องกังวลเรื่อง rate limit, quota หรือคิวรอตอนพีค สามารถเห็นกระบวนการคิดทั้งหมดได้ตลอด ไม่ต้องกังวลว่าข้อมูลถูกส่งไปไหน และไม่มีทางที่ประสิทธิภาพจะถูกลดลงแบบเงียบ ๆ
ผม/ฉันใช้ llama.cpp บน 2×3090 ด้วยการตั้งค่า Q6_K_XL + MTP ได้ความเร็ว prefill 500~1000 โทเคน/วินาที, output 60 โทเคน/วินาที, และ context window 220,000 โทเคน พอเกิน 160,000 โทเคนจะเริ่มโง่ลงนิดหน่อย และไม่ได้ใช้ KV quantization
มันอาจเป็นผลข้างเคียงของฟีเจอร์การคิดก็ได้ แต่ผม/ฉันอยากให้มันสรุปกระบวนการคิดให้สั้นกว่านี้มาก ในสถานการณ์ที่คำตอบประโยคเดียวก็พอ โมเดลระดับล้ำสมัยกลับเขียนอย่างน้อย 5 ย่อหน้า และพยายามเสนอแนวทางใหม่ 3~5 ทาง
ต่อให้ขอว่าเอาทีละขั้น เอาทางเลือกทีละข้อ และอย่าเสนอทิศทางถัดไปแบบเชิงรุก มันก็ยังควบคุมด้วยพรอมป์ต์ได้ยากมากจริง ๆ
แต่เมื่อกี้ผม/ฉันเองก็เพิ่งทำแบบเดียวกับที่กำลังบ่นอยู่เลย
โปรแกรมเมอร์คุ้นเคยกับการไม่ต้องจ่ายเงินให้เครื่องมือ โน้ตบุ๊กพื้นฐานเครื่องหนึ่ง (SSD, มัลติคอร์, RAM 16GB) ก็ทรงพลังมหาศาลแล้วสำหรับการพัฒนา C/C++/Rust หรือแม้แต่ Python
แต่จู่ ๆ มันกลับไม่พอ แล้วเราก็ย้อนกลับไปสู่สถานการณ์ที่ต้องใช้คอมพิวเตอร์ของคนอื่นและเช่าเครื่องมือใช้ทุกวัน ที่แย่กว่านั้นคือแต่ละวันอาจต้องใช้คนละโมเดล และบางวันก็อาจมีอิทธิพลบางกลุ่มแบบมาเฟียไปกดดันผู้ผลิตจนคุณเช่าเครื่องมือดี ๆ ใช้ไม่ได้ด้วยซ้ำ
อาชีพอื่นส่วนใหญ่ต้องลงทุนกับเครื่องมือพอสมควรอยู่แล้ว ถ้าต้องการเครื่องมือดี ๆ ก็ต้องมี GPU memory 64GB (เช่น 2×5090) และ RAM ราว 96GB ถ้าคุณจ่ายเงินให้วิศวกรมืออาชีพปีละ 200,000 ดอลลาร์ การใช้เงิน 50,000 ดอลลาร์กับเครื่องมือทุก ๆ 2 ปีก็ดูสมเหตุสมผลไม่น้อย
นี่เป็นแนวโน้มที่บริษัทอย่าง Anthropic ควรกังวล ยิ่งการรันโมเดลแบบโลคัลทำได้ง่ายขึ้นเท่าไร เพดานราคา ที่พวกเขาจะเรียกเก็บได้ก็จะยิ่งต่ำลงเท่านั้น
คนที่ยอมจ่าย $$$$$ ต่อเดือนคงไม่ได้หายไปทั้งหมด แต่หลายคนน่าจะเอาค่ารายเดือนมาคูณ 12 หรือ 24 แล้วถามว่า “ถ้าเอาเงินก้อนนี้ไปสร้าง local model เอง จะคืนทุนได้ภายใน 1~2 ปีไหม?”
ถ้าลูกค้าส่วนใหญ่เลือกซื้อแทนเช่า บริษัทที่พึ่งพาโมเดลธุรกิจแบบให้เช่าเป็นหลักก็อาจเจอปัญหาลูกค้าหดหายแบบฉับพลันได้
มันแทบจะฝังอยู่ในโมเดลธุรกิจแบบอเมริกันไปแล้ว ทุกอย่างถูกเอาต์ซอร์ส ไม่มีใครอยากดูแลห้องเซิร์ฟเวอร์เอง และถึงต้องจ่ายแพงขึ้น 2~3 เท่าก็ยังอยากโยนทั้งความปวดหัวและความรับผิดชอบออกไป
AI ก็คงเหมือนกัน จะจ่ายพรีเมียมนี้ให้ Anthropic หรือ AWS ก็ไม่ต่างกัน
ผมอยู่บริษัทขนาดค่อนข้างเล็ก และเพิ่งมีปัญหากับ local infrastructure ไม่นานนี้ แม้ว่า downtime ภายในทั้งหมดตลอด 5 ปีที่ผ่านมาจะยังน้อยกว่าเหตุ AWS ล่มครั้งใหญ่ครั้งเดียวล่าสุดมาก แต่ CEO ก็เริ่มกดดันว่าการโฮสต์โครงสร้างพื้นฐานเองเชื่อถือไม่ได้แล้ว
ทุกคนอยากสลัดงานจุกจิกกับความรับผิดชอบทิ้งทั้งนั้น
ผู้ใช้กระแสหลักทั่วไปดูมีแนวโน้มจะยอมจ่ายให้กับของที่ตั้งค่าไว้พร้อมใช้แล้วมากกว่า ส่วนคนที่มีความรู้ทางเทคนิคมากกว่าหรือมีความมุ่งมั่นมากกว่าก็คงทำเอง แต่ผมก็สงสัยว่าสัดส่วนของคนสองกลุ่มนี้จะออกมาแค่ไหน
ไม่แน่ใจว่ามีไอเดียขายเครื่องแบบ 4GPU ที่ทีมวิศวกรรมเอาไปวางไว้ในตู้เก็บของสักที่แล้วรันโมเดลที่ต้องการได้เลยเกิดขึ้นแล้วหรือยัง
มันอาจไม่ได้ดึงดูดทุกคน แต่ในเมื่อเริ่มมีปัญหาเรื่องความเชื่อใจว่า hyperscaler กำลังดูดข้อมูลของผู้คนไปใช้ฝึกโมเดล ก็ย่อมมีที่ที่ให้คุณค่ากับเครื่องและโมเดลที่ควบคุมได้อย่างโปร่งใส และถ้าจำเป็นก็เดินไปถอดปลั๊กเองได้
แค่ใช้ Sonnet 4.6 ก็แทบทำงานได้ทั้งวันอยู่แล้วด้วยค่าบริการเดือนละ 20 ดอลลาร์ และ Sonnet ก็ยังทรงพลังกว่าโมเดลที่โฮสต์เองบน M2 Mac อยู่มาก
ถ้าทุกคนเปลี่ยนไปคิดเงินตามการใช้โทเคน ผมอาจจะคิดต่างออกไป แต่ถ้าวัดแบบค่าสมาชิกรายเดือน มันยังไม่คุ้มในเชิงการเงิน
มันสนุกอยู่หรอก แต่ยังไม่ คุ้มค่าทางเศรษฐกิจ
OpenAI กว้านซื้อ RAM ทั้งหมดในตลาดสปอต ทำให้ราคา RAM/VRAM พุ่งขึ้น 6 เท่า และทำให้ GPU กับคอมพิวเตอร์ที่พอใช้ได้กลายเป็นของที่คนส่วนใหญ่เอื้อมไม่ถึง
คนรวยบางส่วนอาจซื้อ 512GB Mac Studio หรือ RTX Pro 6000 หนึ่งใบในราคา 13,000 ดอลลาร์แล้วรัน local model ที่ค่อนข้างดีได้ แต่คนส่วนใหญ่ก็คงต้องใช้ API
สักจุดหนึ่ง Nvidia อาจพูดว่า “ขาย 6000 ก็ไม่ได้เยอะอยู่แล้ว ในเมื่อเราได้กำไรจาก GPU สำหรับดาต้าเซ็นเตอร์มากกว่า 4 เท่า ก็ยกเลิกมันไปเลยละกัน” ถ้าเป็นแบบนั้นมันก็จะกลายเป็นของที่หาไม่ได้ และการที่คนทั่วไปจะรันโมเดลโลคัลที่พอใช้ได้แต่ตามหลังระดับล้ำหน้าสุดอยู่ราว 1 ปี ก็อาจกลายเป็นเรื่องเป็นไปไม่ได้
อยากเห็นโค้ดที่ได้จากการใช้มันเหมือนกัน ผมเองก็อยากใช้ local model และก็มีฮาร์ดแวร์พร้อม แต่พอลองเทียบกับ โมเดลระดับแนวหน้า อย่าง GPT 5.5 xhigh หรือ Opus แล้ว ตอนนี้มันยังไม่พร้อมจะมาแทนที่
ทั้งคุณภาพและอุปสรรคระหว่างทางทำให้ workflow ช้าลงมาก และบางครั้งมันยังทำ syntax ของการเรียกใช้เครื่องมือพังด้วย
แต่สำหรับงานที่เล็กลง ขอบเขตชัดเจนขึ้น หรือการแก้ไขแบบ “เปลี่ยนส่วนนี้ให้เป็นแบบนี้เป๊ะ ๆ” ก็ดูจะเพียงพอ ผมกำลังรอให้มันสุกงอมพอจะมาแทนของที่ดีที่สุดในตอนนี้ได้ และคิดว่านั่นจะเป็นจุดเปลี่ยน
ถ้าพูดถึง local model ก็ไม่ควรมองข้าม DiffusionGemma และ diffusion model โดยรวมในการใช้งานแบบโลคัล ปกติปัญหาของฝั่งโลคัลคือ LLM ใช้ฮาร์ดแวร์ได้ไม่ค่อยมีประสิทธิภาพ เว้นแต่จะเอาคำขอมาจัดเป็นแบตช์แล้วรันหลายอย่างพร้อมกัน ซึ่งนั่นต้องเปลี่ยนแนวทางไปเลย ตรงกันข้าม diffusion model เร็วกว่ามากกับพรอมป์ต์เดี่ยว และความต่างก็ไม่ใช่น้อย
วันนี้พอดีผมพอร์ตการรองรับ diffusiongemma-26B-A4B-it จาก Transformers ไป Candle แล้วก็ใส่ optimization เพิ่มอีกนิด จนตอน inference บน Candle มันวิ่งได้ประมาณ 450 โทเคน/วินาที (ราว 19 iteration/วินาที) เลย ส่วนในไลบรารี HF Transformers อยู่ที่ประมาณ 180 โทเคน/วินาที (ราว 11 iteration/วินาที) ถ้ารัน LLM ขนาดใกล้เคียงกันบน vLLM ผมก็ไม่คิดว่าเคยเกิน 250 โทเคน/วินาทีสำหรับพรอมป์ต์เดี่ยว ดังนั้นสำหรับ local model แล้วนี่ถือว่าน่าสนใจมาก
ถ้ามีงบ 2,600 ดอลลาร์ ก็ซื้อ AMD 9700 GPU ได้ 2 ใบ โดยการ์ดละ RAM 32GB ใช้ไฟราว 285W ซึ่งทั้งต้นทุนและการใช้พลังงานต่ำกว่า 5090
ถ้าใช้ VLLM build ที่ลง AITER patch ก็สามารถรัน Qwen3.6 27B FP8 พร้อม full context window ได้ที่ราว 45~50 TPS ในเซสชันเขียนโค้ดจริงบน Opencode หรือ PI
ผมหวังจริง ๆ ว่าจะมี dense model ระดับ 30B ออกมาอีกเรื่อย ๆ แต่แค่ Qwen3.6 ตัวเดียวก็จัดการ งานแบบเอเจนต์ ได้เยอะพอสมควรแล้ว
เพียงแต่ ROCm stack ไม่เหมาะกับคนที่ไม่ตั้งใจจะลงลึกแล้วแพตช์มันเอง
ฉันสงสัยว่าทำไมมาตรฐานของ agent coding ที่ว่า “ดี” ถึงต่างกันมากในแต่ละคน
ด้านหนึ่งก็น่าทึ่งจริง ๆ ที่เราไปได้ไกลตั้งแต่ระดับสติปัญญาแบบ “เล่น
Set a Timerบน Apple Music” ไปจนถึงระดับที่อาจผ่านการทดสอบทัวริงได้ แต่ถ้ามองในเชิงใช้งานจริง โมเดลเล็ก ๆ ยังอีกไกลกว่าจะเรียกได้ว่า “ดี” มากกว่าแค่เดโมเทคนิคสำหรับฉัน โมเดล 7B ก็เป็นแค่เสียงสะท้อนพร่า ๆ ของ Wikipedia เท่านั้น ส่วน Gemma แบบ 4 บิตก็ยังเก้ ๆ กัง ๆ เกินไปแม้แต่กับการสร้าง JSON สำหรับเรียกใช้เครื่องมืออย่างเสถียร หรือคัดลอกโค้ดหนึ่งบรรทัดเพื่อเอาไปใช้กับแพตช์
Qwen ต้องการคำสั่งละเอียดและการประคบประหงมมากเกินไปเพื่อไม่ให้หลุดเข้าไปในลูปหายนะหรือทำบริบทหาย จนบ่อยครั้งคำสั่งที่ฉันต้องให้ยาวกว่าตัวโค้ดสุดท้ายที่ได้เสียอีก
หรือว่ามันมีพรอมป์ตลับอะไรบางอย่างที่ฉันไม่รู้? หรือว่าคนอื่นอดทนกว่ามากหรือมีความคาดหวังต่ำกว่ามากกันแน่?
กับสคริปต์เล็ก ๆ, glue code, หรือการแก้ CRUD ง่าย ๆ โมเดลเล็กอย่าง Qwen3.6-27B อาจทำงานได้ดีกว่ามากเมื่อเทียบกับตอนใช้กับโค้ดเบสที่ใหญ่และยุ่งเหยิงกว่า
ถ้ารัน Qwen/Gemma ระดับ 27/35B ที่ FP8 มันจะดีกว่า gemini-2.5 แต่ยังสู้ gemini-3.1 ไม่ได้ DS4-flash FP8 รันได้บน DGX Spark สองเครื่อง และสถานการณ์ก็ดีขึ้นเรื่อย ๆ DiffusionGemma เมื่อไม่นานมานี้ทำความเร็วการสร้างโทเค็นได้มากขึ้น 4 เท่า
สรุปคือดูเหมือนว่าโมเดลที่คุณลองจะเล็กเกินไปหรือไม่ก็ quantize หนักเกินไป
ฉันชอบรันสองโมเดลบนเครื่องโลคัล คือ qwen3.6 27B 8 บิต (dense) กับ qwen3.6 35B 4 บิต (mixture of experts)
27B ฉลาดกว่าและเชื่อถือได้มากกว่า แต่ช้ากว่า ส่วน 35B เร็วกว่าและยังฉลาดมากอยู่ แต่ด้อยกว่า 27B และเสถียรน้อยกว่านิดหน่อย เหตุผลคือมันเป็นสถาปัตยกรรม mixture of experts (MoE) เลยเปิดใช้งานพารามิเตอร์แค่บางส่วน ทำให้โมเดลเร็วขึ้นมาก
ฉันรัน 27B บน MacBook Pro M5 Max + GPU 40 คอร์ + RAM 128GB บนเครื่องสัตว์ประหลาดนี้สามารถโหลดทั้ง 27B และ 35B ไว้ในหน่วยความจำพร้อมกันได้ และยังเหลือพื้นที่ให้ทำงานอย่างอื่นด้วย แต่เพราะเป็นโน้ตบุ๊ก เลยเปิดรัน local LLM ตลอดเวลาไม่ได้ มันร้อนและเสียงดังเกินไป
ที่น่าสนใจกว่าคือการรัน โมเดล 35B บน MacMini M4 RAM 64GB มันเร็วและจัดการงานได้เยอะ เช่น สแกน·ดึงข้อมูล·จัดหมวดหมู่อีเมล แล้วเฝ้ากล่องเมลทำงานต่อเนื่องอยู่ตลอด ฉันยังใช้มันเป็นผู้ช่วย Hermes ส่วนตัวด้วย ไว้ถามอะไรอย่าง “Starship จะปล่อยครั้งถัดไปเมื่อไหร่?”, “วันนี้ในฟุตบอลโลกมีใครแข่งบ้าง? เล่าเกร็ดความรู้ด้วย”
แผนถัดไปคือเวิร์กสเตชัน RTX Pro 6000 Blackwell ที่จะเอาไปไว้ในห้องใต้ดิน ฉันอยากรัน Qwen ให้เร็วมาก ๆ แบบพร้อมกันหลายเธรด/หลายพรอมป์ต/หลายเอเจนต์ ถ้างบไหวก็อยากจัด 2×RTX Pro 6000 เพื่อรัน DeepSeek v4 flash ใช้ทำงานวิจัย
โดยปกติฉันโฮสต์ Qwen3.6:27b แต่ฉันอยากโฮสต์ deepseekv4 flash มากจริง ๆ มันเป็นโมเดลที่ “ดี” เกินเหตุเมื่อเทียบกับขนาด/ความเร็ว/ราคา
ฉันสงสัยว่าบริษัทต่าง ๆ จะเริ่มโฮสต์โมเดลสำหรับงานประจำวันแบบ on-premises ให้กับนักพัฒนาทุกคนเมื่อไหร่ แทนที่จะจ่ายค่าสมาชิกรายเดือนให้ มันดีพอแล้วและค่อนข้างถูก
ถึงคุณจะไม่ได้ถาม แต่พวกเราไม่มีใครคิดว่าควรใช้โมเดลระดับท็อปล่าสุดสำหรับการเขียนโค้ดหรือแทบทุกงาน
ทางที่ควรทำคือพัฒนา open model สำหรับงานเฉพาะ แล้วเรียนรู้การเขียนโค้ด เขียนหนังสือ และวาดรูปด้วยนิ้วกระดูกและสมองเนื้อของตัวเอง
บริษัทยักษ์ใหญ่และสถาบันวิจัยอาจใช้มันสร้างโค้ดหรือคณิตศาสตร์ได้ หากมีผู้เชี่ยวชาญคอยตรวจว่าผลลัพธ์ถูกต้องหรือไม่ แต่ถึงอย่างนั้นก็คุ้มค่าใช้จ่ายหรือเปล่าก็ยังไม่แน่ชัด เช่น ปีที่แล้ว OpenAI ขาดทุนสุทธิ 3.6 หมื่นล้านดอลลาร์ ขณะที่โอเพนโมเดลก็ไล่ตามมาใกล้มากแล้ว และแผน AI ทั้งหมดก็กำลังหมดแรงหลอกล่อเงินเพิ่มแล้ว
มีงานอีกมากที่ใช้โมเดลเล็กมาก ๆ ได้ และมีงานมากมายที่ไม่ต้องใช้พลังประมวลผลกับหน่วยความจำระดับบ้าคลั่ง แต่กลับมีคนที่วิจัยด้านนั้นอย่างจริงจังน้อยเกินไป