- แชร์การตั้งค่าที่ใช้งานได้จริงสำหรับการรัน LLM แบบโลคัลบน M4 MacBook Pro ที่มีหน่วยความจำ 24GB เพื่อทำงานเขียนโค้ดพื้นฐาน รีเสิร์ช วางแผน ฯลฯ ได้โดยไม่ต้องเชื่อมต่ออินเทอร์เน็ต
- โมเดลที่ทำงานได้ดีที่สุดในตอนนี้คือ Qwen 3.5-9B (quantization แบบ Q4) โดยรองรับโหมด thinking, tool use และ context window 128K ที่ความเร็วประมาณ 40 โทเค็น/วินาทีบน LM Studio
- ตั้งแต่ การเลือกเครื่องมือรัน ไปจนถึงโมเดลและตัวเลือกการตั้งค่า อย่าง Ollama, llama.cpp, LM Studio ขั้นตอนเซ็ตอัปมีความซับซ้อนและแต่ละตัวก็มีข้อจำกัดเฉพาะ
- แม้จะยังยากที่จะให้มันแก้ปัญหาซับซ้อนแบบอัตโนมัติได้เหมือนโมเดลระดับ SOTA แต่ก็เพียงพอสำหรับใช้เป็นผู้ช่วยรีเสิร์ชหรือ rubber duck debugging ผ่าน เวิร์กโฟลว์เชิงโต้ตอบแบบเป็นขั้นตอน
- ใช้งานได้โดยมีเพียงค่าไฟแทนค่าสมัครสมาชิก และมีคุณค่าในฐานะแนวทางใช้ AI อย่างยั่งยืนที่ ลดการพึ่งพา Big Tech แต่ก็มี trade-off ด้านประสิทธิภาพและการตั้งค่าค่อนข้างมาก
สภาพแวดล้อมการรันโมเดลแบบโลคัลและเกณฑ์การเลือก
- มีการทดลองตั้งค่าการรันโมเดลแบบโลคัลบน M4 MacBook Pro พร้อมหน่วยความจำ 24GB และพบว่าสามารถจัดชุดการใช้งานที่รองรับงานพื้นฐาน การค้นคว้า และการวางแผนได้โดยไม่ต้องเชื่อมต่ออินเทอร์เน็ต แม้ผลลัพธ์จะยังต่างจากโมเดลชั้นนำระดับ SOTA
- เครื่องมือสำหรับรันแบบโลคัลมีทั้ง Ollama, llama.cpp, LM Studio ซึ่งแต่ละตัวมีข้อจำกัดและโมเดลที่รองรับต่างกัน
- ในการเลือกโมเดล ต้องการโมเดลที่ใส่ลงในหน่วยความจำได้ และยังเหลือทรัพยากรพอให้เปิดแอป Electron ทั่วไปควบคู่กันได้ โดยต้องมี context window อย่างน้อย 64K และ ideally มากกว่า 128K
- โมเดลที่ลองล่าสุดอย่าง Qwen 3.6 Q3, GPT-OSS 20B และ Devstral Small 24B แม้จะใส่ลงหน่วยความจำได้ แต่ใช้งานจริงได้ยาก ส่วน Gemma 4B รันได้ดีแต่มีปัญหาเรื่องการใช้เครื่องมือ
- รายการตั้งค่ามีตั้งแต่ค่าที่คุ้นเคยอย่าง temperature ไปจนถึงตัวเลือกเฉพาะทางอย่าง K Cache Quantization Type และค่าที่เหมาะสมก็อาจเปลี่ยนไปตามว่าจะเปิดใช้งาน thinking หรือไม่
ชุดใช้งาน Qwen 3.5-9B แบบ quantization 4 บิต
- qwen3.5-9b@q4_k_s เป็นโมเดลที่ดีที่สุดเมื่อรันบน LM Studio เพราะให้ครบทั้งความเร็วราว 40 โทเค็น/วินาที การเปิดใช้ thinking การใช้เครื่องมือได้สำเร็จ และ context window 128K
- แม้มันจะเสียสมาธิได้ง่ายกว่าโมเดลชั้นนำ บางครั้งติดลูป และตีความคำขอผิด แต่สำหรับโมเดลที่รันบน MacBook Pro 24GB โดยยังเหลือพื้นที่ให้ทำงานอื่น ก็ถือว่าใช้งานได้ดีมาก
- ค่าที่แนะนำสำหรับโหมด thinking และงานเขียนโค้ดมีดังนี้
temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0
- หากต้องการเปิดใช้งาน thinking ให้เลือกโมเดลใน LM Studio จากนั้นไปที่ configuration แล้วเพิ่มค่าต่อไปนี้ใน Prompt Template ด้านล่างของแท็บ Inference
{%- set enable_thinking = true %}
- โมเดลนี้ถูกใช้งานทั้งกับ pi และ OpenCode โดย pi ให้ความรู้สึกตอบสนองไวกว่า แต่แม้จะมีข้อดีเรื่องการสร้างและปรับแต่ง harness ได้เอง ก็ยังขาดค่าเริ่มต้นที่สมเหตุสมผล
- มีโอกาสที่จะใช้เวลาปรับแต่ง pi มากกว่าการทำโปรเจ็กต์จริงเสียอีก
การตั้งค่า pi
- ใน
~/.pi/agent/models.json มีการลงทะเบียน OpenAI-compatible endpoint ของ LM Studio และโมเดล qwen3.5-9b@q4_k_s
{
"providers": {
"lmstudio": {
"baseUrl": "http://localhost:1234/v1";,
"api": "openai-completions",
"apiKey": "lm-studio",
"models": [
{
"id": "qwen3.5-9b@q4_k_s",
"reasoning": true,
"compat": { "thinkingFormat": "qwen-chat-template" }
}
]
}
}
}
- หากต้องการซ่อนบล็อก thinking ที่ฟุ้งซ่าน ให้เพิ่ม
"hideThinkingBlock": true ลงใน ~/.pi/agent/settings.json
การตั้งค่า OpenCode
- ใน
~/.config/opencode/opencode.json มีการลงทะเบียน LM Studio เป็น provider แบบ OpenAI-compatible ในเครื่อง พร้อมตั้งค่า tool use, context length 131072 และ max tokens 32768
{
"$schema": "https://opencode.ai/config.json";,
"provider": {
"lmstudio": {
"npm": "@ai-sdk/openai-compatible",
"name": "LM Studio (local)",
"options": {
"baseURL": "http://127.0.0.1:1234/v1";
},
"models": {
"qwen3.5-9b@q4_k_s": {
"name": "Qwen 3.5 9B Q4_K_S",
"tools": true,
"context_length": 131072,
"max_tokens": 32768
}
}
}
},
"model": "lmstudio/qwen3.5-9b@q4_k_s"
}
ความต่างเมื่อเทียบกับโมเดลชั้นนำ
- โมเดลอย่าง Qwen 3.5 9B Q4 ยังไม่ถึงระดับที่จะแก้ปัญหาซับซ้อนอย่างอิสระได้นาน ๆ เหมือนโมเดลชั้นนำ
- วิธีสั่งให้สร้างทั้งแอปในครั้งเดียวไม่เหมาะนัก และอาจจบลงด้วยการที่โน้ตบุ๊กแค่ร้อนขึ้นโดยไม่มีผลลัพธ์
- วิธีที่เหมาะกว่าคือเวิร์กโฟลว์แบบโต้ตอบที่สื่อสารอย่างชัดเจนเป็นขั้นตอน และให้คำสั่งจำนวนมาก
- เมื่อต้องใช้โมเดลแบบโลคัล ผู้ใช้ต้องรับภาระการคิดและวางแผนมากขึ้น รวมถึงสั่งงานให้เฉพาะเจาะจงกว่าเดิม แต่ก็ยังมีประโยชน์ในฐานะผู้ช่วยค้นคว้า rubber duck และผู้ช่วยที่ช่วยนึกดีเทลของภาษาโปรแกรมหรือคำสั่ง command line ได้ทันที
- มันอาจไม่ใช่การเพิ่มประสิทธิภาพ 10 เท่าตามที่บริษัท AI รายใหญ่โฆษณา แต่ก็ให้ความช่วยเหลือที่มีความหมายและประสบการณ์ใช้งานที่น่าสนใจ
งานที่ทำได้และงานที่ล้มเหลว
-
การแก้คำเตือน Elixir Credo
- หลังอัปเกรด Elixir linter
credo เป็นเวอร์ชันล่าสุด ก็เกิดคำเตือนในโค้ด จึงขอให้ Qwen รัน mix credo --strict เพื่อเสนอวิธีแก้ โดยไม่ให้แก้ไขไฟล์เอง
- Qwen พบปัญหาในไฟล์ทดสอบ 4 จุดที่ใช้
length/1 เพื่อตรวจว่าลิสต์ไม่ว่าง และเสนอให้ใช้ list != [] แทน length(list) > 0
- เมื่อขอให้แก้ไขต่อ Qwen ก็ทำการแก้ไขแบบขนาน 4 จุดได้อย่างเรียบร้อย
- แม้งานนี้จะเป็นงานง่ายที่ทำเองได้จากการสลับไปมาระหว่างเทอร์มินัลกับเอดิเตอร์ แต่ก็ช่วยเพิ่มความสะดวกได้ดี
-
การจัดการ rebase conflict ใน Dependabot PR
- หลังอัปเดต dependency แล้วเกิด git conflict ใน Dependabot PR และ Dependabot ปฏิเสธการ rebase จึงต้องดึงลงมา rebase เองก่อนให้ Qwen ช่วยตรวจสอบ
- conflict เป็นรูปแบบง่าย ๆ ที่แค่เลือกเวอร์ชันที่ใหม่กว่าของแต่ละ dependency และ Qwen แนะนำให้คง
sentry ที่ 13.0.1 และ tailwind ที่ 0.4.1
- แต่เมื่อให้ลงมือเปลี่ยนจริง Qwen กลับพยายามรัน
git add mix.lock && git rebase --continue ทั้งที่ยังมี conflict marker ค้างอยู่และไม่ได้แก้ไฟล์
- มันยังไม่เข้าใจด้วยว่า
git rebase --continue จะเปิดเอดิเตอร์ ส่งผลให้ OpenCode ค้าง แม้เหตุการณ์นี้อาจเป็นเพียงครั้งเดียวก็ได้
ข้อดีและข้อจำกัดของโมเดลแบบโลคัล
- โมเดลแบบโลคัลมี trade-off ใหญ่พอสมควร แต่ก็มีข้อดีคือสามารถทำงานบนเครื่องบินได้แม้ไม่มีอินเทอร์เน็ต
- หากถือว่าต้องซื้อคอมพิวเตอร์อยู่แล้ว ค่าใช้จ่ายก็จำกัดอยู่ที่พลังงานไฟฟ้าที่ใช้ และไม่ต้องมีค่าสมัครสมาชิก
- การฝึกโมเดลยังคงมีต้นทุนด้านสิ่งแวดล้อมสูง แต่บริษัทโอเพนโมเดลยังห่างไกลจากกลุ่มที่มีผลกระทบสิ่งแวดล้อมสูงสุด และการใช้ฮาร์ดแวร์ส่วนตัวก็ช่วยลดการพึ่งพาดาต้าเซ็นเตอร์ได้
- การได้ปรับแต่งและทดลองด้วยตัวเองก็เป็นความสนุกอีกแบบหนึ่ง
- แม้ LLM จะสร้างผลกระทบอย่างมากไปแล้วและมีด้านลบอยู่มาก แต่ก็ดูจะเป็นเทคโนโลยีที่ยังอยู่ต่อไป และการทดลองกับโมเดลแบบโลคัลก็ให้ความรู้สึกเหมือนเป็นวิธีโต้ตอบกับเทคโนโลยีนี้อย่างยั่งยืนและเป็นบวกมากขึ้น
1 ความคิดเห็น
ความเห็นจาก Hacker News
การรัน LLM บนเครื่องโลคัลนั้นทั้งสนุกและทรงพลัง แต่ถ้าจะเอามาใช้ปิดงานจริงกลับค่อนข้างปวดหัว
ต้องวางแผนล่วงหน้า ทำสเปก และเตรียมของให้พร้อม ขณะที่โมเดลใหญ่ของ OpenAI หรือ Claude มักเข้าใจได้ทันทีแค่โยนคำสั่งไปไม่กี่ประโยค
ถ้าใช้งานจริงจังกับโมเดลใหญ่อยู่แล้ว ก็ใช้ต่อไปได้เลย
แต่ผมมองงาน vision/OCR ต่างออกไป โมเดล open weight ขนาดเล็กและกลางก็ใกล้เคียงระดับล้ำสมัยแล้ว และในงานแบตช์ใหญ่ ๆ ค่า prefill token ก็น่าเสียดายไม่น้อย
อีกอย่างที่คนมักลืมคือ ต่อให้เป็น LLM ตัวเล็ก ถ้าจะใช้เหมือนบริการส่วนตัวที่เสถียร ก็ต้องกัน RAM/VRAM 16~24GB ไว้ให้มันรันค้างตลอด
สุดท้ายปัญหาหลักก็ยังเป็นเรื่องเงินอยู่ดี
ผมว่ามันมาถึงจุดที่แทบใช้งานได้จริงแล้ว
Gemma 4 31B ให้ความรู้สึกเหมือนเป็น baseline ใหม่ของโมเดลโลคัล แน่นอนว่ายังสู้ frontier model ไม่ได้ แต่ก็ให้ความรู้สึกเป็นงานทดลองวิทยาศาสตร์น้อยกว่าโมเดลโลคัลอื่น ๆ ที่เคยรัน รวมถึง GPT OSS 120B กับ Nemotron Super 120B
บน M5 Max RAM 128GB ถ้าใช้ context window เต็ม 256K การใช้ RAM จะพุ่งไปประมาณ 70GB และเห็น system overhead ราว 14GB
เครื่อง 64GB Panther Lake ที่ติด Arc B390 เต็มตัว หรือเครื่อง 48GB Snapdragon X2 Elite น่าจะรันด้วย context window 128K~256K ได้ และบน 32GB อาจพอฝืนให้ใช้ 32K context window ได้
แค่ปีที่แล้วยังรู้สึกเลยว่าการได้ประสิทธิภาพแบบนี้บนเครื่องระดับสูงที่ใกล้เคียงเมนสตรีมเป็นความฝันลม ๆ แล้ง ๆ
สุดท้ายเกณฑ์วัดคือ “จะมอบหมายอะไรให้โมเดลนี้ทำได้อย่างสม่ำเสมอ” Opus รู้มากกว่าแน่นอนและทำงานซับซ้อนได้มากกว่า แต่ถ้าใส่บริบทให้ดี Gemma ก็ทำได้ดีอย่างน่าประหลาด
ช่วงงานที่ผมเชื่อใจให้ทั้งสองโมเดลทำได้นั้นต่างกันน้อยกว่าที่คิดมาก มันให้ผลลัพธ์ดีมากในเครื่องมือส่วนตัวและหลายโปรเจ็กต์ และเป็นโมเดลโลคัลตัวแรกที่ผมกล้าให้ทำ implementation ของฟีเจอร์ในโหมด agent กับโปรเจ็กต์ที่ไม่เล็กน้อย
https://thot-experiment.github.io/gradient-gemma4-31b/
นี่เป็นเครื่องมือที่ค่อนข้างซับซ้อนซึ่ง Gemma 4 ทำแทบทั้งหมดใน OpenCode และตลอดหลายชั่วโมงนั้นผมแทรกแซงด้วยมือตัวเองแค่ราว 4 ครั้ง
Q6_K_XL, context 128K @ q8 อ่านได้ราว 800tok/s เขียนได้ราว 16tok/s
ตอนนี้กำลังรอ turboquant กับ MTP ใน llama.cpp ถ้าข่าวลือเป็นจริงก็น่าจะไปถึง 256K และ 25~30tok/s ได้
ตอนออกใหม่ ๆ คะแนน benchmark น่าประทับใจมากจนผมเขียนโพสต์เกี่ยวกับมันไว้ [0] แต่พอเอาไปรันในสภาพแวดล้อม agent coding ที่มี context ยาวขึ้น อันดับบนตารางก็ลดลงไปบ้างในภายหลัง
[0] https://gertlabs.com/blog/gemma-4-economics
แนวทางคือวางแผนด้วยโมเดลใหม่ แล้วให้โมเดลเล็กลงมือทำ ถ้าวางแผนดีพอและไม่เหลือความกำกวมให้โมเดลเล็กต้องตีความเอง มันก็เวิร์ก
ถ้าได้มาอ่านโพสต์นี้ก่อน ผมคงไม่ต้องใช้เวลาทั้งสุดสัปดาห์กว่าจะสรุปแบบเดียวกัน
ผมทำการทดสอบแบบประดิษฐ์บนโน้ตบุ๊กเครื่องเดียวกัน โดยให้มันแก้ lint error ราว 50 จุดใน repo C++ แนว vibe coding ขนาดเล็ก หวังว่ามันจะจัดการงานย่อยจำนวนมากได้โดยไม่ติดขัดบ่อยเกินไป
GPT OSS 20B พอใช้ได้แต่ช้า ชอบเติมประโยคที่ไม่จำเป็นหรือพูดซ้ำ และมักพลาดแบบบอกว่าแก้แล้วทั้งที่ยังไม่ได้แก้โค้ด
Qwen 3.5 9B ที่ใช้กับ Opencode เร็วกว่ามาก และแม้ระหว่างที่มีการบีบอัด context อยู่ก็ยังจัดการ lint warning ส่วนใหญ่ได้โดยไม่สะดุด และแก้ทุก warning ได้ถูกต้อง
ผมลองใช้ 4-bit MLX quantization ของ Qwen 3.5 9B ด้วย แต่สุดท้ายแครชเพราะหน่วยความจำไม่พอ พอเปลี่ยนเป็น GGUF ที่รันด้วย llama.cpp ก็รันได้โดยไม่แครช
มันเทียบกับ frontier model ไม่ได้เลย ช้ากว่ามาก ข้อมูลพื้นฐานก็ผิด และจัดการงานที่ไม่เล็กน้อยแบบครั้งเดียวจบไม่ได้
ตอนให้มันสรุปสถาปัตยกรรมโปรเจ็กต์ มันกลับอ้างว่าใช้ไลบรารีที่ไม่มีอยู่ใน repo เลย แน่นอนว่าคนอื่นอาจมองต่างกัน แต่ก็ยังพอมีประโยชน์อยู่บ้าง และหวังว่าเมื่อเวลาผ่านไปสภาพแวดล้อม LLM แบบโลคัลบนฮาร์ดแวร์พอประมาณจะดีขึ้นมาก
LLM โลคัลนั้นยอดเยี่ยม แต่ถ้าอ่านโพสต์แนวนี้เยอะ ๆ จะรู้สึกเหมือนมันเกือบแตะระดับ Opus 4.7 แล้ว
ใน HN มีกลุ่มเล็ก ๆ ที่เสียงดังและกระตือรือร้นมาก ซึ่งมักพูดเกินจริงเรื่องความสามารถของ LLM โลคัล
ในบรรดาโมเดลขนาดใกล้กัน มันเป็นหนึ่งในตัวที่เร็วที่สุดที่ผมเคยรันบน local GPU แต่ผมทดสอบแค่กับการ์ด Nvidia
พอมารู้ทีหลังว่ามันเป็น MoE และมี active parameter แค่ 3.6B หลายอย่างก็อธิบายได้เลย
การมองแบบ สมจริง ว่าโมเดลโลคัล โดยเฉพาะโมเดลเล็กอย่าง 9B ที่ผู้เขียนใช้ ทำอะไรได้บ้างนั้นมีประโยชน์มาก
โมเดล 9B อยู่ประมาณระดับ Sonnet 3.6 คือทำ autocomplete กับฟังก์ชันเล็ก ๆ ได้ แต่พอพยายามทำความเข้าใจปัญหาใหญ่ ๆ มันจะหลุดประเด็น
ถึงอย่างนั้นมันก็ยังน่าสนใจและเล่นสนุก ผมเลยทำ agent harness แบบโลคัลไว้เยอะพอสมควรเพื่อความสนุก
โปรเจ็กต์ปัจจุบันคือเอเจนต์แบบไม่ต้องติดตั้ง: https://gemma-agent-explainer.nicklothian.com/
Python, SQL และ React รันได้ครบในเบราว์เซอร์ทั้งหมด เพื่อประสบการณ์ที่ดีที่สุดผมแนะนำ Gemma E4B
ยังอยู่ระหว่างพัฒนาอย่างหนัก และต้องใช้ Chrome เพราะ HTML5 Filesystem API กับการรองรับ LiteRT แต่ก็อาจทำให้เบราว์เซอร์สาย Chromium ส่วนใหญ่ใช้งานได้
สิ่งที่ต่างจากเอเจนต์ส่วนใหญ่คือมัน ไม่ต้องติดตั้ง โมเดลรันอยู่ในเบราว์เซอร์ผ่าน LiteRT/LiteLLM และให้ประสิทธิภาพดีกว่า Transformers.js อีกทั้งยังใช้ Filesystem API เพื่อเปิดสิทธิ์อ่าน sandbox directory แบบเลือกได้ด้วย
มันมีเอกสารอธิบายตัวเองในตัว ดังนั้นถ้าถามในแผงช่วยเหลือสดว่า “system prompt ถูกใช้อย่างไร” มันก็เข้าถึง source code ของตัวเองแล้วตอบได้
กด “Tour” เพื่อดูภาพรวมทั้งหมดได้ และผมตั้งใจจะเปิดซอร์สในสัปดาห์หน้า
เพียงแต่ benchmark ที่คนใช้ประเมินโมเดลเปลี่ยนบ่อยเกินไป เลยหาการเทียบที่ดีได้ยาก อ้างอิงไว้ว่า Sonnet 3.6 ออกหลัง GPT-3.5 ประมาณ 1 ปี
ถ้ามองแบบวิจารณ์ ก็จริงที่โมเดลพวกนี้ยังไม่เทียบชั้นระดับท็อปล่าสุดในงานเขียนโค้ดซับซ้อน
แต่ในงานออฟฟิศ คนทำงานความรู้จำนวนมากใช้เวลากับ การจัดการ Excel, ย้ายไฟล์, แปลเอกสารกฎหมายแข็ง ๆ, ร่างอีเมล, งานจุกจิกใน PPT แบบนี้เยอะมาก
งานพวกนี้ใช้โมเดล 30~35B ขึ้นไปก็เพียงพอแล้ว และยังได้ข้อดีเรื่องเก็บข้อมูลบริษัทไว้เป็นความลับด้วย
เวลาคนพูดถึงโมเดลโลคัล สิ่งที่คาดหวังคือโมเดลที่ออกในเดือนเมษายนปีนี้ อย่าง Qwen 3.6 27B และถ้า GPU อ่อนหน่อยก็ qwen 35b a3b
โมเดลพวกนี้เอามาเทียบกับโมเดลระดับล้ำสมัยได้อย่างจริงจัง
ตัวอย่างชัด ๆ คือคดี London Whale ของ JPMorgan ที่ขาดทุน 6 พันล้านดอลลาร์จาก ข้อผิดพลาดใน Excel
ผมกำลังมอง MacBook M5 Pro 18/20-core 64GB RAM อยู่ แต่หาข้อมูล benchmark โมเดลจริง ๆ ได้ยากมาก
เช่นถ้ามีใครบอกได้ว่า Qwen 3.6 35B/A3B แบบ quantization Q4 และ Q6 จะได้กี่โทเคนต่อวินาที ก็คงดีมาก
ฝั่ง local inference ตอนนี้กำลังเอนไปทางโมเดล MoE และหลายตัวแม้โทเคนต่อวินาทีจะโอเค แต่เวลาไปถึงโทเคนแรกนั้นแย่มาก
ผมเขียนการตั้งค่าแบบมั่ว ๆ ที่ใช้บน M2 Studio 32GB ไว้ใน Bluesky และอยากได้ฟีดแบ็ก
ผมเป็นพวกที่ทำได้ไม่ค่อยดีถ้าไม่ได้เห็นของจริง เลยแชร์ไว้เผื่อมีคนช่วยดู
https://bsky.app/profile/mooresolutions.io/post/3mliilyf2i22...
ตอนนี้ผมรัน qwen 3.6 9b quantized model บน M4 Pro 48GB ซึ่งพอเรียกได้ว่าแทบจะใช้งานได้สำหรับงานพัฒนาเบื้องต้นบน pi.dev/cc
ถ้าจะทำอะไรที่มีความหมายจริง ๆ ดูเหมือนว่าเดสก์ท็อป 128GB คือ sweet spot แต่ตอนนี้หาเครื่องแบบนั้นยาก
การรันโลคัลมันสนุก แต่ก็อย่าลืมว่าเวลาของตัวเองก็ไม่ฟรีเหมือนกัน
สำหรับโปรเจ็กต์ส่วนตัว ผมย้ายไปใช้ OpenRouter มากขึ้นเรื่อย ๆ และแม้จะใช้ qwen ตัวใหญ่สุดแบบจริงจัง ก็ยังเสียไม่ถึง 2~3 ดอลลาร์ต่อวัน
เพราะถ้าเป็น M4 Pro 48GB คุณก็รันโมเดลที่ใหญ่กว่านี้ได้อยู่แล้ว และถ้าความฉลาดของโมเดลคือหัวใจของความมีประโยชน์ การใช้โมเดลใหญ่กว่าอาจเหมาะกว่า
เห็นด้วยว่า dense 9B ยังไม่ค่อยไหว
ผมใช้ MacBook Pro M5 สเปกสูงสุดรุ่นล่าสุดและลองโมเดลโลคัลมาด้วย แต่มันแทบจะอยู่ในระดับ “พอทำงานได้” เท่านั้น
บน 4090 24GB ผมกำลังรัน qwen3.6:27B ด้วย context ราว 128K โดยใช้การปรับหน่วยความจำ activation แบบ turboquant/rotorquant รุ่นล่าสุด
แนะนำอย่างแรงให้ขยับขึ้นมาระดับโมเดลนี้เลย ชุด q4_xl+rotorquant ดีมากทีเดียว
และมีโค้ดอ้างอิงไว้โยนให้เอเจนต์ด้วย
https://github.com/rapatel0/rq-models
ผมว่าการเอาเงินหลายพันดอลลาร์ไปลงกับ Mac ยังดีกว่าจ่ายค่าสมาชิก API
โมเดลโลคัล ทำให้ทำงานได้ทุกที่ทุกเวลาโดยไม่ต้องกังวลเรื่องข้อมูลส่วนตัวรั่วไหล