Ask HN: มีใครแทนที่ Claude/GPT ด้วยโมเดลโลคัลสำหรับการเขียนโค้ดในชีวิตประจำวันได้บ้างไหม?

 (news.ycombinator.com)
6 คะแนน โดย GN⁺ 9 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนาที่เลิกใช้โมเดลคลาวด์โดยสิ้นเชิงเริ่มมีมากขึ้น ด้วยเหตุผลด้าน ความเป็นส่วนตัวของข้อมูล และการใช้งาน LLM ฟรี โดยสามารถทำงานผ่าน offline coding harness ที่ถูกทำเป็นคอนเทนเนอร์และแซนด์บ็อกซ์ได้โดยไม่ต้องเรียกเครือข่ายภายนอก
  • โมเดลหลักที่ใช้คือ Qwen3.6 35B-A3B (active parameters 3b จึงทำงานได้เร็ว) และโมเดล dense 27B ซึ่งมีจุดแลกเปลี่ยนระหว่างความแม่นยำในการเขียนโค้ดกับความเร็วในการสร้างโทเคน
  • ชุดที่ถูกพูดถึงมากที่สุดคือ Pi harness กับ llama.cpp และการที่ tool calling เริ่มทำงานได้อย่างสม่ำเสมอในโมเดลโลคัลเป็นครั้งแรก ช่วยยกระดับประสบการณ์ใช้งานอย่างมาก
  • เมื่อเทียบกับ Claude Opus โมเดลโลคัลยังต่างกันราวกับ "จูเนียร์ที่ต้องคอยชี้นำ vs ซีเนียร์ที่ช่วยออกแบบไปด้วยกัน" ทำให้จำเป็นต้องมีพรอมป์ตที่ละเอียดและการแตกงานอย่างชัดเจน
  • ปัจจุบันโมเดลโลคัลถูกประเมินว่าอยู่ในระดับ frontier เมื่อประมาณ 8~18 เดือนก่อน แต่ก็มีข้อดีเชิงปฏิบัติที่ชัดเจนคือ ฟรี เป็นส่วนตัว และไม่ต้องกังวลเรื่องโควตา

กรณีเปลี่ยนมาใช้โมเดลโลคัลและสเป็กฮาร์ดแวร์

  • รัน Qwen3.6 35B-A3B ด้วย Pi harness บน Mac Studio 128GB หรือ MacBook RAM 36GB และรีดีไซน์หน้าแรกกับบล็อกทั้งหมดของเว็บไซต์ที่ใช้ Django + Wagtail เสร็จแล้ว
    • เมื่อตัดการเข้าถึงอินเทอร์เน็ตออก โมเดลอาจไม่รู้วิธีทำงานกับการพัฒนา Wagtail ที่ไม่ค่อยเป็นที่รู้จักเสมอไป
    • งานที่ซับซ้อนจะใช้ Qwen3.5 122b แต่ด้วย active parameters 10b จึงค่อนข้างช้า
  • ในสภาพแวดล้อมหน่วยความจำรวม Strix Halo 128GB มีการแยก Pi ไว้ในคอนเทนเนอร์ และอนุญาตให้เข้าถึงเฉพาะไดเรกทอรีงานโดยไม่มี credentials
    • แชตและแปลภาษาใช้ Gemma 4 31B ส่วนเสียงใช้ Gemma 4 12B
    • แม้จะมีหลายโมเดล เช่น Qwen 3.5 122B-A10B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, GPT-OSS 120B แต่สำหรับการเขียนโค้ด 35B-A3B ยังเหมาะที่สุด
  • บนเครื่อง dual RTX3090 ที่ประกอบไว้เมื่อ 5 ปีก่อน สามารถรันโมเดล Qwen และ Gemma ด้วย quantization แบบ UD-Q4_K_XL ได้ราว ~150tok/s และรองรับคอนเท็กซ์ 300k ทั้งหมดใน VRAM
    • ใช้แทนการสมัคร Claude เดือนละ $100 และสำหรับการใช้งานส่วนตัว ความฟรีสำคัญกว่า
    • ใช้ทำโปรเจกต์หลากหลาย เช่น Android TV launcher, พอร์ทัลจัดการ k8s, การเชื่อม Home Assistant, ระบบจัดการของชำและอาหารการกิน
  • ใช้ RTX 6000 กับชุด Qwen 3.6 27b + Open Code ทำงานเขียนโค้ดได้ 90% แต่เมื่องานซับซ้อนมากหรือเก็บรายละเอียด UI ยังกลับไปใช้ Codex
    • ที่คอนเท็กซ์ 256k หากเกิน 100k คุณภาพและความเร็วจะเริ่มลดลง และหลัง 150k จะหนักมาก
  • บน RTX 5090 ใช้ Qwen 3.6 27b (quantization แบบ Q6) + llama.cpp และจำกัด GPU จาก 600W → 450W เพื่อให้เครื่องเงียบลง
    • ขยายไปสู่งานประจำวัน เช่น commit branch·สร้าง PR, ปิดบัญชี invoice ผ่าน Stripe CLI, วิเคราะห์โหลด Elasticsearch

ประเภทโมเดลและลักษณะประสิทธิภาพ

  • การแยก MoE vs โมเดล dense ส่งผลโดยตรงต่อคุณภาพการเขียนโค้ด
    • Qwen3.5-122B แท้จริงคือ 122B-A10B แบบ MoE ที่มีเพียง 10B ทำงานอยู่จริง ส่วน Qwen3.6-27B เป็นโมเดล dense ที่ 27B ทั้งหมดทำงานตลอดเวลา
    • สามารถประมาณคุณภาพเทียบเท่า dense ได้จากค่าเฉลี่ยเรขาคณิตของ active/total parameters ใน MoE เช่น sqrt(35×10)≈18.7
    • MoE มีคุณภาพต่ำกว่าที่ขนาดรวมเท่ากัน แต่เร็วกว่า และยังสามารถรัน MoE ขนาดใหญ่ได้ด้วยการ offload ไปยัง CPU RAM
  • ระดับของ quantization ส่งผลต่อการเกิดลูปและความแม่นยำ
    • Q8 quantization ช้ากว่า แต่ช่วยลดลูป จึงอาจประหยัดเวลารวมได้
    • โมเดลไวมากต่อ quantization ของส่วน K ใน KV cache โดย F16 K + Q8 V ช่วยลดลูปได้มาก
  • การเพิ่ม GPU ตัวที่สองไม่ได้มีเป้าหมายเพื่อความเร็ว inference แต่เพื่อ เพิ่มความจุ VRAM
    • ทั้ง Gemma-4 31B dense และ 26B MoE เมื่อใช้ Q4 quantization ให้คุณภาพใกล้เคียงกัน แต่ MoE เร็วกว่า ~3 เท่า (150tok/s vs 46tok/s)

ข้อจำกัดของโมเดลโลคัลและกลยุทธ์รับมือ

  • ต้องใช้พรอมป์ตที่ละเอียด

    • หากปล่อยให้โมเดลตั้งสมมติฐานเอง มันมักเลือกทางลัดที่สุด (เช่น CSS ใน HTML) ซึ่งไม่ใช่ผลลัพธ์ที่ดีที่สุดในเชิงสถาปัตยกรรม
    • หากไม่ระบุสถาปัตยกรรม โมเดลจะรีบแก้แบบเร็ว ๆ และเลอะเทอะ และหากไม่สั่งให้ลบประโยค debug ก็จะปล่อยทิ้งไว้
    • Claude Opus สามารถอนุมานเจตนาของผู้ใช้ได้ แต่ Qwen รุ่นเล็กจะทำเฉพาะสิ่งที่สั่ง จึงต้อง "เปิดใช้" ความรู้ด้านการออกแบบอย่างชัดเจนผ่านคำสั่ง

  • ปัญหาลูปและข้อผิดพลาดของเครื่องมือแก้ไข

    • มักเรียกเครื่องมือแก้ไขพลาด และแทนที่จะ retry กลับใช้โทเคนไปกับการคิด แล้วอ่านไฟล์ใหม่
    • การ retry ด้วยมือมักแก้การเรียกแก้ไขได้ แต่โมเดลมักสมมติว่าปัญหารากลึกกว่านั้น ทำให้สิ้นเปลืองโทเคนโดยไม่จำเป็น
    • แนวทางแก้ไขแบบอิง hash (อ้างอิง hash ของแต่ละบรรทัดโค้ด) ช่วยลดข้อผิดพลาดในการแก้ไขได้ แต่เมื่อคุณภาพคอนเท็กซ์หมดลง ก็ยังพังในรูปแบบอื่นอยู่ดี
    • การจำกัดให้แก้ไขแทนการเขียนใหม่ผ่านกฎใน AGENTS.md ช่วยได้บางส่วน

  • การจัดการ context window

    • หน้าต่าง 65,000 โทเคนเกินได้แม้แค่อ่านโครงสร้างไฟล์โค้ด จึงต้องการ 200k ขึ้นไป
    • Qwen3.6-35b สามารถจัดการคอนเท็กซ์ 256k ได้ปกติที่ 128k บน VRAM 16gb
    • Qwen3.6-27B รองรับคอนเท็กซ์ 1 ล้านโทเคน โดยบน DGX Spark ต้องใช้หน่วยความจำราว 100GB กับ f16 KV cache

ปัญหา prompt caching และการคงเหตุผลการอนุมาน

  • โมเดลไฮบริด Qwen มีปัญหากับ prompt caching และต้องประมวลผลคอนเท็กซ์ทั้งหมดใหม่ทุกเทิร์น
    • โมเดลโลคัลส่วนใหญ่ไม่ได้ถูกฝึกให้คงการอนุมานทั้งหมดข้ามหลายเทิร์น จึงต้องรีโปรเซสใหม่หลังจบสาย tool calling ยาว ๆ โดยที่ส่วน reasoning ถูกตัดออกไปแล้ว
    • Qwen 3.6 ถูกฝึกให้คง reasoning ไว้ จึงปรับปรุงการใช้แคชซ้ำได้ด้วยการตั้งค่า chat-template-kwargs = {"preserve_thinking": true}
  • LLM สมัยใหม่ไม่ได้ใช้แค่ full attention แต่ใช้ local attention ด้วย (sliding window, state space model แบบ Mamba-2)
    • full attention มีต้นทุนแบบ O(n²) สูง และอ่อนกับการอนุมานที่ค่าถูกแทนที่ไปตามเวลา
    • local attention จะเก็บ snapshot ไว้ และเมื่อคำนวณแคชใหม่จะเริ่มจาก snapshot ล่าสุด แต่หาก snapshot ใหญ่เกินไปก็ยังมีข้อจำกัดด้านการเก็บรักษา
    • Qwen 3.5 ขึ้นไปใช้ Gated DeltaNet ที่สลับระหว่าง attention และ SSM layers
  • Vulkan กลับเร็วกว่า ROCm อย่างน่าประหลาดใจ และการอัปเดต llama.cpp ให้เป็นเวอร์ชันล่าสุดสำคัญต่อการแก้ปัญหาการประมวลผลซ้ำ
  • ปัญหา tokenizer divergence ที่โทเคนแบบ autoregressive ถูก parse ต่างจากตอน prefill ยังแก้ได้ยาก

ข้อถกเถียงเรื่องต้นทุนและความคุ้มค่าพลังงาน

  • 2x RTX3090 ราคาอยู่ราว $4400 ซึ่งเทียบได้กับ Claude เดือนละ $100 เป็นเวลา 3.6 ปี โดยยังไม่รวมค่าไฟและชิ้นส่วนอื่น
    • แม้ผ่านไป 3.6 ปี ราคาของ GPU ความจุสูงก็น่าจะยังทรงตัวสูง
    • บางพื้นที่มีค่าไฟสูงจนจุดคุ้มทุนอยู่ที่ราว 1 ปี
  • การใช้พลังงาน ต่ำกว่าที่คาด
    • หากรันเต็ม 1.2kw ต้นทุนอยู่ราว $0.12/ชั่วโมง และถ้าต่อกับโซลาร์ก็ถูกลงอีก
    • ภาระ inference ต่างจากการเล่นเกม จึงแทบไม่มีปัญหาเรื่องไฟ โดยระบบ idle ราว 200W และตอน inference อยู่ที่ 350-450W
  • เรื่อง จังหวะซื้อฮาร์ดแวร์
    • ตอนนี้ยังไม่ใช่ช่วงเหมาะแก่การซื้อ และคาดว่าอีก 24-36 เดือนจะเป็นรอบถัดไปที่น่าสนใจ
    • M4 Pro Mac mini RAM รวม 48gb ราคา ~$2k ถูกแนะนำเป็นเครื่อง inference สายประหยัด และน่าจะใช้งานได้อีก 10 ปีที่ ~150tok/s
    • AMD R9700 VRAM 32gb ราคา ~$1200-1400 เหมาะกับงาน AI มากกว่า 2x 9070
  • การเช่าหรือสมัครคลาวด์ก็เป็นกลยุทธ์ที่สมเหตุสมผล เพราะไม่ใช่ทุกคนจะทุ่มเงินก้อนใหญ่กับฮาร์ดแวร์ได้

การประเมินเมื่อเทียบกับโมเดล frontier

  • มีการประเมินซ้ำ ๆ ว่าโมเดลโลคัลอยู่ในระดับ "คุณภาพของโมเดลระดับแนวหน้าเมื่อ 8~12 เดือนก่อน"
    • ตาม benchmark แล้ว Qwen 3.6 35B-A3B เหนือกว่า Claude 4 Opus แต่ก็มีความเป็นไปได้ว่าบางโมเดลโอเพนซอร์สจะถูก benchmark-maxing
    • ในการทดสอบ YouTube browser OS รายหนึ่ง Qwen 3.6 สร้างฟังก์ชันที่ใช้งานได้มากกว่า Claude 4 Opus
    • อย่างไรก็ดี นั่นคือเมื่อเทียบกับ frontier model เมื่อหนึ่งปีก่อน และยังมีเสียงคัดค้านหนักแน่นว่า MoE ที่ active 3B เทียบ Opus หรือ Sonnet รุ่นล่าสุดไม่ได้
  • ประเด็นถกเถียงหลักคือคำนิยามของ "ระดับ Opus" ที่ไม่ตรงกัน
    • ชื่อนี้เริ่มใช้ตั้งแต่ Claude 3 Opus ในปี 2024 และยังคงมีช่องว่างกับโมเดลล่าสุดอย่าง Opus 4.8·4.6
    • เมื่อพฤศจิกายนปีที่แล้ว Opus 4.5·GPT 5.2 ทำให้ frontier model กระโดดขึ้นอีกขั้น และโดยทั่วไปคำว่า "ระดับ Opus" มักหมายถึงหลัง 4.5
    • โมเดล open weights ที่ใหญ่ที่สุดยังต้องใช้ฮาร์ดแวร์ระดับเซิร์ฟเวอร์ 8x H100 ส่วนโมเดลสำหรับบ้านยังไปไม่ถึง
  • บางคนประเมินว่าโมเดลโลคัลอยู่ระหว่าง Haiku 4.5~Sonnet 4.5 และถ้า micromanage ดี ๆ ก็ให้ผลลัพธ์ที่ดี
  • ช่องว่างระหว่าง frontier กับโลคัลอาจคงอยู่เสมอ แต่สำหรับผู้ใช้จำนวนมาก โมเดลโลคัลก็ใช้งานได้จริงแล้ว

กลยุทธ์ด้าน harness และเวิร์กโฟลว์

  • Pi harness ได้รับคำแนะนำมากที่สุด โดยมีลักษณะคล้าย agent development kit และถูกเปรียบว่าเป็น "neovim สำหรับ vscode ของ Claude"
    • มีเครื่องมือพื้นฐานให้ เช่น การเข้าถึงไฟล์ การแก้ไข และ bash และยังเพิ่มส่วนขยายอย่าง MCP adapter หรือเว็บเสิร์ชได้
    • คำสั่ง /tree ช่วยย้อนคอนเท็กซ์กลับไปก่อนการเรียกเครื่องมือที่ล้มเหลว และ /new ใช้รีเซ็ตคอนเท็กซ์
  • ใช้ เวิร์กโฟลว์แบบหลายชั้นและแบ่งบทบาท เพื่อชดเชยข้อจำกัด
    • ให้ frontier model เขียนสเปก การออกแบบ และแผนการดำเนินงาน แล้วให้โมเดลโลคัลลงมือ implement
    • เชื่อมเอเจนต์ตามบทบาท (project manager·schema agent·coding agent) และใช้ orchestrator กับ Playwright เพื่อส่งต่อเฉพาะข้อผิดพลาดไปยังขั้นถัดไป
    • แตกงานเป็น TODO ระดับอะตอมและระบุไฟล์อ้างอิงให้ชัดเจนเพื่อประหยัดคอนเท็กซ์
  • OpenCode บางครั้งเปลี่ยน system prompt ทุกเทิร์น ทำให้ไม่เข้ากันกับ KV cache และการตั้งค่ารองรับ local LLM ยังต้องทำด้วยมือและซับซ้อน
  • Ollama ถูกวิจารณ์เรื่องการเพิ่มโมเดลคลาวด์และการหารายได้ จึงมีคำแนะนำให้ใช้ llama.cpp·llama-swap แทน และบน macOS นั้น llm-mlx เร็วกว่า 10-15%

ตัวอย่างการแชร์การตั้งค่าแบบละเอียด

  • บนเครื่อง AMD 7900xtx 24gb + 5950x + 64gb DDR4 มีการรัน Qwen3.6-27B-MTP-UD-Q4_K_XL ด้วย llama.cpp Vulkan
    • แฟลกหลัก: -ngl 99(offload ทุกเลเยอร์ไป GPU), -c 80000(คอนเท็กซ์ 80K), --cache-type-k q8_0 --cache-type-v q8_0(KV cache 8 บิต), -fa on(flash attention), --spec-type draft-mtp(MTP draft)
    • sampling: --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0(ค่าที่แนะนำสำหรับ Qwen coding)
    • ประสิทธิภาพ: สร้างโทเคน ~65t/s, ประมวลผลพรอมป์ต ~600t/s, cold start ~30 วินาที
    • ใช้ร่วมกับ Crush harness + Headroom + Exa MCP web search แล้วเลิกสมัคร Claude Code ส่วนตัว
  • บน V100 32GB ใช้ Qwen3.6-27B-UD-Q4_K_XL + Pi พร้อมฟอร์ก llama-cpp-turboquant และแพตช์ MTP
    • ที่คอนเท็กซ์ 200,000 และ --spec-type mpt --cache-type-k turbo3 --cache-type-v turbo3 ได้ 45-60 t/s
  • บน Strix Halo 128GB ใช้ Qwen3.6-35B-A3B โดยประมวลผลพรอมป์ตราว ~800tps และสร้างโทเคน 50tps พร้อมใช้ไฟแทบเป็นศูนย์ตอน idle
    • เสียดายที่ยังไม่มีเวอร์ชัน 122B ออกมา และในสภาพแวดล้อมหน่วยความจำรวม โมเดล dense จะช้าเพราะติดข้อจำกัดแบนด์วิดท์หน่วยความจำ
  • ยังมีการบ่นเรื่องข้อมูลไม่ละเอียดพอ พร้อมเรียกร้องให้ระบุ quantization·parameters·context·GPU·VRAM·harness configuration ให้ชัดเจนกว่านี้

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

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

 
b89kim 1 시간 전

ตอนที่ใช้ Pi-coding-agent+Qwen3.6-27B-MTP-GGUF ประสิทธิภาพอยู่ราว ๆ ระดับ Sonnet 4.5 เพียงพอสำหรับทำแอปง่าย ๆ และถ้าจำเป็นก็ค่อยต่อกับ API ฟรี (เช่น GLM5.1) เป็นครั้งคราว การใช้พลังงานของ GPU ระดับ 4090/5090 ค่อนข้างสูงก็จริง แต่ถ้าเป็น agent ที่ออกแบบมาดี ๆ ก็ไม่ได้มีเรื่องให้ต้องรันกันเป็นชั่วโมงบ่อยนัก
 
GN⁺ 9 시간 전
ความคิดเห็นจาก Hacker News

  • Greenpants: ให้ความสำคัญกับ ความเป็นส่วนตัวของข้อมูล และ LLM ฟรี เลยใช้ Pi coding harness ภายในคอนเทนเนอร์·แซนด์บ็อกซ์แบบออฟไลน์เต็มรูปแบบ
    ใช้ Qwen3.6 35B บน Mac Studio 128GB หรือ MacBook 36GB โดยมี active parameters 3B เลยค่อนข้างเร็ว ได้รีดีไซน์หน้าเว็บและบล็อกใหม่ทั้งหมดด้วย Django + Wagtail แต่ Wagtail ไม่ค่อยเป็นที่รู้จักนัก เลยทำให้เอเจนต์ไม่ได้รู้เรื่องดีเสมอไปเมื่อไม่มีอินเทอร์เน็ต
    งานที่ซับซ้อนกว่านี้ก็เคยใช้ Qwen3.5 122B เช่นกัน แต่มี active 10B เลยช้ากว่ามาก เมื่อเทียบกับโมเดลใหญ่แบบ Claude ต้องตั้งคำถามให้แม่นมาก และถ้าปล่อยสมมติฐานไว้ไม่ชัดเจน ก็มักเลือกทางง่าย เช่น ยัด CSS เข้าไปใน HTML ซึ่งเป็นการตัดสินใจด้านสถาปัตยกรรมที่น่าผิดหวัง
    การเรียกใช้เครื่องมือแก้ไขก็พลาดบ่อยและชอบติดลูป Qwen3.6 35B เหมือนจูเนียร์ที่มีความรู้กว้างโดยรวมแต่ต้องคอยนำทางตลอด ส่วน Claude Opus จะใกล้เคียงซีเนียร์ที่ช่วยคิดสถาปัตยกรรมไปด้วย ถ้า Opus ช่วยเร่งงานได้ 15 เท่า Qwen แบบออฟไลน์เต็มรูปแบบก็น่าจะอยู่ราว 5 เท่า แต่พอนึกว่าใช้ฟรีก็ยังน่าทึ่งอยู่ดี

    • lambda: ผมก็คล้ายกัน คือรัน Pi ในคอนเทนเนอร์ แล้วให้มันเชื่อมกับ llama.cpp ที่อยู่ในอีกคอนเทนเนอร์หนึ่ง
      อนุญาตให้เข้าถึงเครือข่ายได้ แต่บล็อก credential และให้เข้าถึงได้แค่ working directory กับ ~/.pi ใช้โน้ตบุ๊ก Strix Halo 128GiB unified memory และเพราะไม่ชอบเขียนโปรแกรมด้วยเครื่องมือแบบปิด เลยยังเทียบกับ frontier model แบบจริงจังไม่ได้
      ตอนนี้ยังเป็นคนสายสงสัย AI อยู่ เลยใช้เวลาทดลองทำให้โมเดลพังและดูจุดแข็งจุดอ่อนมากกว่าการใช้งานจริง แต่ถ้าเป็น agentic coding ก็เลือก Qwen 3.6 35B-A3B บ่อยที่สุด ส่วนแชตทั่วไป·แปลภาษาใช้ Gemma 4 31B บ่อย และงานเสียงใช้ Gemma 4 12B
      ยังเก็บ Qwen 3.5 122B-A10B, Qwen 3.6 27B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, Minimax M2.7 และ GPT-OSS 120B ไว้ด้วย แต่สำหรับคอนฟิกแบบนี้ ตอนนี้ Qwen 3.6 35B-A3B น่าจะใกล้เคียง sweet spot ที่สุดสำหรับงานโค้ด
    • geophile: ประสบการณ์แทบจะเหมือนกันเลย ต้อง วางแผนอย่างระมัดระวังมาก แยกงานเป็นขั้นเล็ก ๆ ที่เป็นอิสระต่อกัน และมนุษย์ต้องเขียนดีไซน์ให้ชัดเจนด้วย
      ถ้าปล่อยให้ qwen เติมรายละเอียดเอง มันจะติดลูปก่อนเริ่มเขียนจริง ปัญหาเรื่องแก้ไขไม่ได้ก็แปลกเหมือนกัน เลยแก้ AGENTS.md ให้จำกัดการแก้ไขแทนการเขียนทับใหม่ทั้งหมด ซึ่งช่วยได้เล็กน้อย
    • adyavanapalli: สำหรับเครื่องมือแก้ไข อาจคุ้มที่จะลองวิธี อิงแฮช ที่แฮชแต่ละบรรทัดของโค้ดแล้วอ้างอิงแฮชนั้นเวลาแทนที่
      ดูแนวทางได้ที่ https://blog.can.ac/2026/02/12/the-harness-problem/. ยังไม่ได้ benchmark แบบจริงจัง แต่จากความรู้สึกเหมือนความผิดพลาดในการแก้ไขลดลง และอาจต่างกันไปตามสภาพแวดล้อม

  • horsawlarway: สำหรับใช้งานส่วนตัว ผมยกเลิก Claude แบบสมัครรายเดือน 100 ดอลลาร์ แล้วแทนที่ด้วย pi harness ที่ชี้ไปยัง unsloth studio และใช้โมเดล Qwen·Gemma
    บนเครื่อง dual RTX3090 ที่ประกอบไว้เมื่อราว 5 ปีก่อน รัน unsloth/Qwen3.6-35B-A3B-MTP-GGUF และ unsloth/gemma-4-26B-A4B-it-GGUF ด้วยควอนไทซ์แบบ UD-Q4_K_XL โดยทั้งคู่ทำความเร็วได้ราว 150tok/s และรองรับ full context 300k ภายใน VRAM
    แม้จะยังไม่ดีเท่า Claude แต่ก็ฟรี และสำหรับงานส่วนตัว ความต่างนั้นไม่ได้เป็นปัญหาใหญ่มาก ยังใช้ OpenClaw ต่อเข้ากับ inference server ตัวเดียวกันด้วย ซึ่งเป็น use case ที่เข้ากับ local model ได้ค่อนข้างดี
    ตัวอย่างที่ทำมีทั้งตัว launcher แทน Android TV, พอร์ทัลผู้ดูแลสำหรับบริการ k8s, integration·automation ของ Home Assistant, การจัดการรายการซื้อของ·มื้ออาหาร, และเวิร์กโฟลว์สร้าง 3D asset ด้วย ComfyUI ถ้าเป็นซอฟต์แวร์ที่เอาไปทำเงินก็ยังแนะนำผู้ให้บริการแบบเสียเงินอยู่ดี แต่ local model ก็ทำอะไรเจ๋ง ๆ ได้ไม่น้อย

    • rootlocus: RTX3090 สองใบราคาอยู่ราว 4,400 ดอลลาร์ ดังนั้นต่อให้ยังไม่รวมค่าไฟและชิ้นส่วนอื่น ๆ ก็เท่ากับค่า Claude เดือนละ 100 ดอลลาร์เป็นเวลา 3.6 ปี
    • kpw94: ถ้ากำลังรัน gemma แบบควอนไทซ์ UD-Q4_K_XL อยู่ ก็น่าลองดู โมเดล QAT อย่าง unsloth/gemma-4-26B-A4B-it-qat-GGUF ด้วย
      ดู https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF และ https://blog.google/innovation-and-ai/technology/developers-... อัปเดตวันที่ 9 มิถุนายนยังเพิ่มการรองรับ MTP ด้วย
    • twothreeone: ผมก็ลองรัน unsloth/Qwen3.6-35B-A3B-MTP-GGUF ตัวเดียวกันบน 3090 ใบเดียว, context 128k, ควอนไทซ์ Q4_K และได้ประมาณ 40~60tok/s
      สิ่งที่รบกวนใจที่สุดคือ คุณภาพของผลลัพธ์ ในงานโค้ดจริงที่มีความซับซ้อนระดับปานกลาง ต้องสลับไปมาระหว่าง “ดันด้วยพรอมป์ต์” กับ “ลงมือทำเอง” ตลอด เลยมีภาระจากการสลับบริบททางความคิดสูง และทุก ๆ ไม่กี่นาทีก็ต้องตัดสินใจว่าเป็นเพราะผมสั่งไม่ดีหรือโมเดลยังไม่พอ
      มันยังข้ามจากรายละเอียดการลงมือทำระดับล่างไปสู่การออกแบบระดับสูงได้ไม่ดี และยังเรนเดอร์ของอย่างตารางง่าย ๆ ได้ไม่ค่อยดีด้วย บน Claude ไม่มีปัญหาแบบนี้ เลยยังมองว่าใช้แทนกันตอนนี้ไม่ได้ หวังว่าอีกไม่กี่เดือนจะเป็นไปได้ ตอนนี้ใช้ aider มาแทน Claude CLI แต่ตัวเลือกนี้เองก็อาจไม่ใช่ทางที่ดีที่สุด

  • bluejay2387: งานเขียนโค้ดประมาณ 90% จัดการด้วย Qwen 3.6 27B, Open Code, custom skills และ Semble
    มันไม่ได้ฉลาดเท่า CC หรือ Codex แต่ก็ทำงานส่วนใหญ่ให้เสร็จได้ มี RTX 6000 อยู่แล้วเลยได้ TPS เร็วพอ และเดิมที GPU ตัวนี้ก็มีไว้ใช้กับงานอย่างอื่น
    เดิมทีแค่ลองดูว่ามันจะเข้าใกล้ frontier model ได้แค่ไหน แต่ผลออกมาดีพอจนใช้ต่อ งานที่ซับซ้อนมากจริง ๆ หรือการขัดเกลา UI ก็ยังกลับไปใช้ Codex อยู่ และดูเหมือนว่า UI จะเป็นจุดอ่อนที่สุดของ Qwen
    ไม่ถึงกับแนะนำ เพราะคนที่มี RTX 6000 ก็ไม่ได้มีเยอะ และค่าใช้จ่ายก็เทียบได้กับค่าสมาชิก MAX CC หรือ Codex หลายปี แต่ก็มองเห็นศักยภาพ และอีกไม่กี่ปีก็น่าจะใช้งานได้จริง
    ที่ context 256k ตั้ง compact target ไว้ที่ 75% และถ้าบทสนทนาเกิน 100k ทั้งคุณภาพและความเร็วจะเริ่มตก หลัง 150k จะมีปัญหามาก ลองใช้ Qwen 3.5 122B ด้วย แต่เรื่องเขียนโค้ดแย่กว่า 3.6 27B มาก ส่วน Gemma 4 31B ดีสำหรับงานอื่น แต่เรื่องโค้ด Qwen ยังนำหน้า และ Nemotron Super 120B ก็เขียนโค้ดสู้ Qwen ไม่ได้ ซึ่งน่าแปลกใจเหมือนกัน

    • heipei: รัน Qwen 3.6 27B Q6 บน RTX 5090 ด้วย llama.cpp และตอนนี้ใช้แค่ pi agent
      พอเป็นโลคัลก็ไม่ต้องกังวลเรื่องราคาต่อโทเคน โควตา ช่วงเวลา หรือความอ่อนไหวของข้อมูลเลย จำกัดไฟ GPU จาก 600W ลงมา 450W แล้วมันเงียบมากแม้ตอน inference
      ไม่ได้ใช้แค่เขียนโค้ด แต่เอาไปใช้กับงานจิปาถะประจำวันบ่อยด้วย เช่น commit ลง branch และสร้าง PR, ใช้ Stripe CLI ดึงใบแจ้งหนี้ค้างชำระ/เกินกำหนดมาจับคู่กับ CSV ของธนาคาร, ใช้ credentials ของ Elasticsearch เพื่อสรุปสาเหตุของโหลดปัจจุบัน, หรือเช็กว่าโค้ดเบสรองรับ X ไหมและ implement ไว้ตรงไหน
    • bo1024: Qwen3.5-122B จริง ๆ คือ Qwen3.5-122B-A10B
      A10B เป็นโมเดล mixture-of-experts เลยเปิดใช้พารามิเตอร์พร้อมกันแค่ 10B ในแต่ละครั้ง ส่วน Qwen3.6-27B เป็นโมเดล dense ที่เปิดใช้พารามิเตอร์ครบทั้ง 27B ตลอด ดังนั้นในหลายงาน โมเดล dense 27B อาจทำได้ดีกว่า 122B-A10B
    • user43928: ที่ทำงานบังคับให้ใช้ Qwen 3.6 27B แต่รู้สึกว่าแทบไม่มีประโยชน์
      ทำเองยังดีกว่า และเวลามัน implement ก็มักเละเทะหรือ debug ผิดทางไปเลย ถ้าไม่นับความสามารถค้นหาที่ฉลาดขึ้นหน่อย รุ่นที่ต่ำกว่า Sonnet ก็รู้สึกว่าเสียเวลา
      และการใช้ Codex มาขัดเกลา UI ก็ฟังดูแปลก Codex ขึ้นชื่อเรื่อง UI ไม่ดี และตามหลัง Claude Opus อยู่มาก Altman ก็เคยโพสต์ว่ากำลังปรับปรุงเรื่องนี้ในโมเดลถัดไป

  • pierotofy: ชุด Llama.cpp + Qwen3.6-35B(MTP) + OpenCode ค่อนข้างเก่งบน RTX 3090 ใบเดียว และเร็วกว่าโมเดลคลาวด์ส่วนใหญ่
    คุณภาพให้ความรู้สึกเหมือนใช้ edge model เมื่อ 8~12 เดือนก่อน ตั้งค่าไว้ที่ https://github.com/pierotofy/LocalCodingLLM/

    • jacobgold: ถ้า “คุณภาพระดับ edge model เมื่อ 8~12 เดือนก่อน” ก็ยอดเยี่ยมสำหรับงานอดิเรก แต่สำหรับนักพัฒนามืออาชีพที่จะใช้เป็นตัวหลักของ coding agent ผมมองว่าจุดเปลี่ยนอยู่ราว 6 เดือนก่อน ตอนที่ Opus 4.6 ออกมา
    • trueno: ผมมี MacBook Pro M4 Max 128GB และอยากลองเล่นสิ่งนี้อยู่ แต่ไม่ค่อยมีเวลา
      อยากรู้ประสบการณ์จากผู้ใช้ Mac ที่ใช้ชุดคล้ายกัน เห็นการถกเถียงเรื่องสายโลคัลเยอะ แต่เกณฑ์อ้างอิงก็เปลี่ยนตลอดและยังไม่คุ้นคำศัพท์นัก อยากรู้ความรู้สึกแบบเป็นกลางว่าไปทางโลคัลแล้วเสียอะไร ได้อะไร
    • atomicnumber3: ตอนนี้ไม่อยากใช้ Claude อีกเลย

  • codinhood: คิดว่าคำถามนี้คงไม่ได้คำตอบที่ “จริงจัง” มากนัก ตอนนี้ ต้นทุนค่าเสียโอกาส ของการไม่ใช้โมเดลที่ใหม่และดีที่สุดยังสูงเกินไป
    ต่อให้สำรวจทุกเดือน ข้อสรุปก็เหมือนเดิม เวลา แรง และค่าใช้จ่ายที่ต้องลงไปเพื่อทำให้โลคัลโมเดลและเครื่องมือเขียนโค้ดรอบ ๆ มันเข้าใกล้ Sonnet/Opus ใน Claude Code ยังไม่คุ้ม
    ถ้ามันคุ้มจริง ป่านนี้คงเป็นข่าวใหญ่ระดับพลิกวงการไปแล้ว ไม่ได้ปฏิเสธว่าอาจมีใครทำสำเร็จ แต่ดูจะใกล้เคียงกับมีดโกนของอ็อกคัมมากกว่า เพื่อไม่ให้หลงเข้าไปในโพรงกระต่ายลึก ๆ

    • pyeri: แม้แต่ ขบวน FOMO ของต้นทุนค่าเสียโอกาส นี้ก็ต้องมีจุดอิ่มตัว และผมคิดว่ามันผ่านจุดนั้นไปแล้ว
      โมเดลระดับ Mythos เป็น state of the art ด้านการให้เหตุผลก็จริง แต่แทบไม่มีประโยชน์มากนักกับปัญหาส่วนใหญ่ที่นักพัฒนาต้องแก้ ผมคิดว่าตระกูล Sonnet/Opus แถว ๆ 4.8 ในตอนนี้น่าจะกลายเป็นระดับที่องค์กรใช้งานกันแพร่หลาย
      โลคัลโมเดลยังไปไม่ถึงจุดนั้น แต่ตอนนี้ก็ใช้ตระกูล DeepSeek, Kimi, GPT, MiniMax ผ่าน API อย่าง NVIDIA, OpenRouter, Groq ได้ในราคาถูก และพวกนี้ก็ใกล้ระดับ Sonnet พอสมควร
    • mark_l_watson: ดูเหมือนจะได้ข้อสรุปเดียวกัน ผมกำลังจะย้ายไปสู่ ระบบแบบเป็นชั้น ที่ไล่จากโลคัล, commercial API อย่าง OpenCode + DeepSeek v4 flash, ไปจนถึง DeepSeek v4 Pro
      แบบนี้ก็ยังทำงานที่จำเป็นได้ต่อเนื่อง พร้อมค่อย ๆ ย้ายไปโลคัลมากขึ้นทีละนิด และแม้ใช้ฮาร์ดแวร์เดิม การตั้งค่าโลคัลตอนนี้ก็ดีกว่าเมื่อ 2 เดือนก่อนมาก และถ้าเทียบกับ 6 เดือนก่อนก็ดีขึ้นแบบมหาศาล
    • gunapologist99: แทนที่จะคิดแบบอ็อกคัม อาจควรคิดแบบ พาเรโต
      ถ้าเชื่อจริง ๆ ว่าจะไปถึงจุดนั้นภายในไม่กี่ปี การเริ่มลองตั้งแต่ตอนนี้ก็ดีกว่า โดยเฉพาะกับโปรเจกต์สั้น ๆ หรือเล็ก ๆ และโปรเจกต์ใหญ่ที่แยกโมดูลได้ดี คุณอาจแปลกใจกับผลลัพธ์ก็ได้

  • sosodev: คำถามนี้มีช่วงของทั้งความสามารถและความคาดหวังกว้างเกินไป ถ้ารันแค่โมเดล 8B แล้วหวังจะทำ vibe coding หรือ one-shot ก็ยากอยู่
    ถ้ารันโมเดลระดับราว 30B ได้ มันทำงานได้ค่อนข้างดีสำหรับงานที่ขอบเขตเหมาะสมและนิยามไว้ชัดเจน ตอนนี้ในช่วงนี้ Gemma4-31B กับ Qwen3.6-27B ดูดีที่สุด
    ถ้าต้องการ inference ที่เร็วขึ้นก็เปลี่ยนไปใช้โมเดล MoE ได้ แต่กับงานส่วนใหญ่คุณภาพจะดรอปลงอย่างเห็นได้ชัด งานขอบเขตเล็กสามารถทำแบบ one-shot หรือ vibe coding ได้เหมือนกัน แต่ถึงอย่างนั้นถ้ามีการชี้นำก็ยังดีกว่ามาก
    ถ้าต้องการความสามารถระดับ frontier อย่างน้อยก็ต้องมีหน่วยความจำ 128GB พร้อมพลังประมวลผลจำนวนมากหรือไม่ก็ความอดทนมากพอ สำหรับคนส่วนใหญ่จะขาดอย่างใดอย่างหนึ่งระหว่างเงินกับความอดทน ความอดทนกับโมเดลโลคัลไม่ได้หมายถึงแค่รอโทเค็นออกมา แต่รวมถึงความพยายามในการตั้งค่าให้เข้ากับเวิร์กโฟลว์และฮาร์ดแวร์ของตัวเองแล้วทำให้มันรันได้ดีด้วย

    • argee: บน MacBook M4 Pro, RAM 48GB ผมใช้ Gemma 4 26B A4B เพื่อเรียน Rust และตอบคำถามหลายอย่าง
      ผมไม่ได้เชื่อว่ามันจะทำ one-shot ได้ดีนัก นอกจากการแก้ไขเล็กจิ๋วมาก ๆ ใน IDE หรือ harness แต่ถ้ามนุษย์ยังจับพวงมาลัย มองถนน และขับต่ำกว่าความเร็วจำกัด มันก็เร็วและดีพอในฐานะ copilot สำหรับงานบริบทขนาดเล็กถึงกลาง
      ถ้าเทียบกับเมื่อไม่กี่ปีก่อนนี่น่าทึ่งมาก และถ้าไม่มีสิ่งนี้ ผมคงแทบไม่ใช้ AI เขียนโค้ดเลย ผมไม่ชอบความรู้สึกที่ว่าพอเน็ตหลุดแล้วตัวเองจะทื่อหรือทำงานต่อไม่ได้
    • user43928: ผมให้โมเดลเล็ก โดยเฉพาะ GPT 5.4 Mini ย้ายการแก้โค้ด 10~20 บรรทัดไปอีกไฟล์หนึ่ง แต่พอรอบที่สองมันก็ยังแก้โค้ดและใส่บั๊กเพิ่มเข้าไป
      ผมไม่ได้คาดหวังความน่าเชื่อถือแบบสมบูรณ์แบบ แต่คิดว่าอย่างน้อยถ้าชี้ให้เห็นความต่าง มันก็น่าจะทำถูกในครั้งที่สองได้ ในความเป็นจริงมันกลับพูดอย่างมั่นใจว่าโค้ดเหมือนเดิมแล้ว ทั้งที่ยังเพิ่มบั๊กลึก ๆ อีกตัวเข้าไป
      ผมไม่รู้ว่างานแบบไหนที่โมเดลระดับขยะพวกนี้จะเพียงพอสำหรับมันอาจแกล้งทำเป็นเก่งได้อยู่ไม่กี่นาที แต่สุดท้ายผลลัพธ์ก็ไม่ถูกต้อง ผมมองว่าอย่างมากก็เหมาะกับการค้นหาที่ฉลาดขึ้นหรือ autocomplete เท่านั้น

  • mgsram: หลังใช้ local LLM มาประมาณ 1 ปี ตอนนี้ผมลงตัวกับชุด Qwen3.6 27B dense GGUF, OpenCode, llmster(LM Studio) บน Mac Studio RAM 512GB
    ผมลอง Qwen 3.6 35B-A3B ด้วย แต่โมเดล dense แม่นยำกว่าขึ้นไปอีกระดับ แลกกับการเสียโทเค็นต่อวินาที Qwen3.6 27B ปกติได้ราว 25~40tok/s
    ตอนแรกใช้กับเครื่องมือง่าย ๆ แต่ช่วง 3~4 เดือนหลังมานี้ผมใช้มันกับงานเขียนโค้ดระดับโปรดักชันจริง ๆ ทั้งในสแตกซอฟต์แวร์ยานยนต์ C/C++ และเครื่องมือ Python ความช้ากลับช่วยให้ผมเดินงานในจังหวะที่เหมาะสม
    งานพัฒนาใหม่หรือเขียนใหม่ ผมจะใช้ Sonnet ร่วมกันทำดีไซน์ สถาปัตยกรรม การให้เหตุผล และแผนปฏิบัติการแบบละเอียด จากนั้นค่อยแยกเป็นชิ้นแล้วป้อนเป็นพรอมป์ต์อย่างแม่นยำ ส่วนงานกับโค้ดเดิมต้องอาศัยการตัดสินใจ และถ้ารู้สึกถึงขีดจำกัดของโมเดลโลคัลก็จะกลับไปใช้ Claude Code
    ไม่นานมานี้ผมใช้ Qwen 3.6 สร้างทั้งบริการจัดการพลังงานที่เขียนใหม่ทั้งหมดด้วย C โดยอ้างอิงโค้ด C++ เดิม, ตัวแยกสเปก Excel ที่ซับซ้อน, และเครื่องมือที่แปลเนื้อหา CJK เป็นภาษาอังกฤษแล้วใส่เข้า KG

  • 3abiton: ทุกคนพูดถึง Qwen กันแล้ว งั้นผมก็ด้วย ผมรัน Qwen 3.6 35B Q8(MTP) บน Strix Halo กับ llama.cpp
    ได้ประมาณ 40~50t/s และประสิทธิภาพดีมาก ผมใช้กับ forge-code โดยตรงใน zsh และเมื่อบริบทยาวเกิน 150k คุณภาพจะตกลงและเริ่มลืม

  • wsintra2022: อ่านคอมเมนต์ที่นี่แล้วแยกไม่ออกเลยว่าคนที่พยายามห้ามใช้โลคัลนี่เป็นบอตฝั่งผู้ให้บริการ AI หรือเป็นคนที่มีประสบการณ์แย่กับโมเดล AI โลคัลจริง ๆ
    การรัน Qwen 3.6 27B 8k quantization บน Mac Studio 64GB ไม่ใช่พลังวิเศษสารพัดนึกระดับ frontier แต่มันก็แค่ดีเลยล่ะ ฟรี เป็นส่วนตัว และเวทมนตร์ของมันคือทำให้วิศวกรมากประสบการณ์จากขี้เกียจกลายเป็นขี้เกียจกว่าเดิม
    ผมใช้ llama.cpp กับ opencode วางแผนการแก้โค้ดแล้วสั่งให้มันทำ จากนั้นก็ไปนอนเปล ล้างจาน หรือทำอย่างอื่น แล้วค่อยเข้าไปเช็กผ่าน tmux กับ ssh ตรงนี้แหละที่น่าทึ่งจริง ๆ

    • epolanski: วงการ “วิศวกรรม” ซอฟต์แวร์มีพวกนินจา MIT Leetcode จำนวนมากที่เขียนสลอปใช้การไม่ได้ มี memory leak ด้วย React+Tailwind ดังนั้นเส้นฐานจึงต่ำมาก

  • garethsprice: บน Ada 4000 VRAM 20GB ผมใช้ OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM และความเร็วตอน generate อยู่ราว 55tok/s
    OpenCode แนบบริบทมาเยอะ เลยรู้สึกช้ากว่าตัวเลข Pi ก็ถูกพูดถึงเยอะเหมือนกัน ไว้จะลองดูเร็ว ๆ นี้
    ผมใช้ Opus ทำแผน แล้วให้เอเจนต์โลคัลทำตาม จากนั้นใช้ Opus ตรวจสอบ มันยังไม่ใช่โลคัล 100% แต่โมเดลพวกนี้ก็กำลังกลายเป็นส่วนหนึ่งของเวิร์กโฟลว์ระดับโปรดักชันมากขึ้นเรื่อย ๆ
    ตอนนี้มันอาจยังไม่คุ้มสำหรับคนที่ไม่ได้ชอบเล่นของแนวงานอดิเรกและพร้อมทุ่มทั้งเวลาและเงิน มันยังไม่ดีเท่า Opus หรือโมเดล frontier อื่น ๆ แต่ในช่วงที่งานซ้ำ ๆ เพิ่มมากขึ้น มันก็ “ดีพอ”
    ถึงไม่มี Rolls Royce คุณก็ยังขับ Corolla มือสองไปซูเปอร์มาร์เก็ตได้ เวิร์กโฟลว์ใหม่ ๆ ที่ถ้าใช้ frontier LLM จะมีค่าใช้จ่ายสูงเกินไปก็เริ่มทำได้ ผมเคยให้มันรัน fuzz test ทั้งคืนผ่าน Chrome devtools MCP แบบทำตัวเหมือนผู้ใช้ และยังให้เช็กสกรีนช็อตแบบมัลติโหมดด้วย พอนึกถึงค่าใช้จ่ายของ Claude+ภาพหน้าจอแล้วก็น่าทึ่ง
    คำพูดที่ว่า “ตามหลัง frontier อยู่ 12~18 เดือน” ดูจะจริง อีก 12~18 เดือนน่าจะรันโมเดลระดับ Opus แบบโลคัลได้ในงบไม่ถึง 5,000 ดอลลาร์ แต่ตอนนั้นโมเดล frontier ก็คงไปไกลกว่าเดิมอีก

  • arjie: ไม่ได้โลคัลและไม่ใช่ interactive coding แต่ผมรัน DeepSeek V4 Flash ด้วย RTX Pro 6000 Blackwell สองใบ
    ความเร็วล้วน ๆ อยู่ที่ 160tok/s แต่มันเป็น reasoning model การใช้งานของผมคือให้มันเขียนโค้ดอัตโนมัติและรีวิวระบบอื่นแบบอัตโนมัติ บางครั้งผมให้ Pi เขียนโค้ด มันเร็วมาก แต่เพราะความเคยชิน ผมเลยยังใช้ CC กับ Codex เป็นหลักต่อไป

    • akersten: อยากรู้ว่าไปหา RTX Pro 6000 Blackwell มาได้จากที่ไหน
      เว็บไซต์ที่ผมหาเจอมีแต่ของหมด ขายให้เฉพาะองค์กร หรือดูน่าสงสัย
    • leptons: อยากรู้ว่าเคยวัด การใช้พลังงานไฟฟ้า ของชุดนี้ไหม ผมกังวลว่าค่าใช้จ่ายต่อเดือนจะออกมาเท่าไร

  • stymaar: รัน Qwen3.6-35B-A3B บน Strix Halo 128GB Bosgame M5
    VRAM สำหรับโมเดลนี้ถือว่าเยอะเกินไปมาก แต่ Qwen ยังไม่ได้ออก Qwen3.6 รุ่น 122B ที่จะเหมาะกับฮาร์ดแวร์ของผมที่สุดมาให้ใช้ ส่วนค่าไฟแทบไม่ต้องนับเลย เพราะเดิมทีมันเป็นชิปโน้ตบุ๊ก จึงกินไฟตอนว่างน้อยมาก และแม้ตอนประมวลผลพรอมป์ตก็ใช้ไฟแค่นิดหน่อยเกิน 120W
    Qwen3.6 มีประสิทธิภาพเกินคาด จนผมใช้ Claude แค่เป็นครั้งคราว คิดเป็นราว 10% ของความต้องการทั้งหมดเท่านั้น อยู่ต่ำกว่าโควตาได้แม้ใช้แพลนที่ถูกที่สุด ความเร็วอยู่ที่ประมวลผลพรอมป์ตราว 800tps, สร้างโทเค็น 50tps และไม่ได้ใช้ speculative decoding

    • manmal: อยากรู้ว่าเคยลอง รุ่น dense 27B ไหม เพราะมันดีกว่าสำหรับงานโค้ดมาก

  • Kostic: สำหรับใช้ส่วนตัว ผมต่อ VSCode กับ llama.cpp เพื่อรัน Qwen 3.6 27B หรือ Gemma 4 31B ซึ่งดีพอจนยกเลิกบริการสมัครสมาชิกคลาวด์ได้เลย
    Qwen ทำงานบน GPU ตัวแรกด้วย q4@176k context และ MTP ได้ราว 70~50tok/s จึงค่อนข้างดีสำหรับงานโค้ด ส่วน Gemma ใช้ GPU ทั้งสองตัวด้วย q8@64k context ทำงานวิเคราะห์อารมณ์เอกสาร สรุป แก้ไข และแปล ได้ที่ 25tok/s
    มันช้าไปหน่อยสำหรับ workflow แบบแบตช์ แต่ก็ยังใช้งานได้ ถ้า llama.cpp รองรับ MTP ในโหมด tensor split ก็น่าจะดันได้อีก
    ที่ทำงานผมยังใช้ frontier LLM อยู่เพราะไม่ได้เป็นคนจ่ายค่าใช้จ่ายเอง และแน่นอนว่ามันดีกว่า หวังว่าอีกราว 1 ปีจะมีโมเดล 30B ที่อยู่ระดับ Sonnet 4.6/Opus 4.5 ออกมา
    การประมวลผลพรอมป์ตเริ่มที่ 800t/s แล้วลดลงถึง 400t/s โดยปกติพรอมป์ตเริ่มต้นยาว 16k~24k โทเค็น จึงใช้เวลา 60~90 วินาทีในการประมวลผล ซึ่งไม่ดีนักแต่ก็พอรับได้

  • jodoherty: ใช้ Gemma 4 31B บน RTX Pro 6000 Blackwell ผ่าน Pi สำหรับงาน agent coding ทั้งหมด
    ผมว่ามันมีประโยชน์ และโปรเจกต์เสริมนี้ก็คล้ายกับวิธีที่ผมกำหนดขอบเขตและจัดการโปรเจกต์ในที่ทำงาน: https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...
    ต้องใช้สถาปัตยกรรมที่รอบคอบและทำ TDD ค่อนข้างมาก ต้องจัดการส่วนยากตั้งแต่ต้น แล้วห่อไว้ด้วยอินเทอร์เฟซที่เรียบง่ายและใช้งานง่าย เพื่อตัดความเสี่ยงทางเทคนิคออก
    บางโปรเจกต์เร็วขึ้น 2~3 เท่าเมื่อเทียบกับการเขียนเอง และสำหรับโปรเจกต์ที่น่าเบื่อหรือขอบเขตกว้าง มันช่วยให้รวบรวมและลองไอเดียได้เร็ว ทำให้ประหยัดเวลา 5~10 เท่า
    การตั้งค่าคือสลับใช้ vLLM ที่ใช้ nvidia/Gemma-4-31B-IT-NVFP4 และ llama.cpp ที่ใช้ unsloth/gemma-4-31B-it-qat-GGUF พร้อม MTP จำกัดพลังงาน GPU ไว้ที่ 400W ตอนนี้คอนฟิก llama.cpp ให้ความเร็ว 60~150t/s ตามอัตราการยอมรับ MTP draft ส่วน prefill อยู่ที่ 1500~4000t/s ตามความยาวและความลึกของ context

  • jborak: ใช้ RTX 5070 สี่ใบ กับ AMD Threadripper 1950X รุ่นแรกเพื่อรัน Qwen3.6 27B MTP Q6_K บน llama.cpp และใช้งาน Pi เป็น daily driver ได้ดี
    ความเร็วอยู่ราว 50~60tok/s และยังต่อกับแอปอื่นอย่าง OpenWeb UI ด้วย ช่วงหลังตั้ง LLM gateway ชื่อ Bifrost ให้เป็นจุดเข้าถึงหลักสำหรับโมเดล
    ผมเคยลอง Qwen3.6 35B A3B ด้วย แต่สำหรับงานโค้ด 27B เหมาะกว่า แม้เป็นโมเดล dense จึงช้ากว่า แต่คุณภาพดูดีกว่ามาก ส่วน 35B A3B แบบ non-MTP ได้ 130~140tok/s ซึ่งเร็วบ้าคลั่ง
    จริง ๆ แล้วการรัน Qwen3.6 27B ไม่จำเป็นต้องใช้ 5070 ถึงสี่ใบ สามใบ หรืออาจสองใบก็พอได้ แต่ถ้าอยากให้ 27B เร็วด้วย MTP โมเดล draft จะต้องมี context ของตัวเอง จึงกินหน่วยความจำเพิ่ม
    ต้องจำไว้ด้วยว่า system prompt ของเครื่องมือจะถูกโหลดเข้าโมเดลในทุกบทสนทนา พอเปิด Pi ขึ้นมาแรก ๆ มันตอบสนองเร็วมาก แต่ถ้าโต้ตอบผ่าน Hermes CLI แต่ละพรอมป์ตจะอัดบริบทอย่าง skills, tools ฯลฯ เข้ามาเยอะและค้างอยู่จนจบบทสนทนา ทำให้ช้าลงมาก
    เรื่องความเป็นส่วนตัวก็ดี แต่ที่ดีอีกอย่างคือไม่มีโควตาและไม่ต้องกังวลเรื่องปริมาณการใช้งาน ถ้าอนาคตคือ “loop engineering” การใช้โมเดลคลาวด์ก็จะเผาทั้งโทเค็นและเงิน ระบบของผมกินไฟ 200W ตอนว่าง และ 350~450W ตอนมีภาระอนุมานสูง โดยตัว decoding เองไม่ได้มีประสิทธิภาพนัก จึงมีช่วงที่ GPU ว่างบ่อยกว่าที่คิด ความก้าวหน้าอย่าง diffusion อาจช่วยให้ decoding เร็วขึ้นและใช้ GPU ที่ว่างอยู่ได้คุ้มขึ้น

    • zakisaad: อยากรู้ว่าทำไมถึงเลือก 5070 สำหรับชุด 4 ใบ
      ตอนแรกผมรู้สึกว่ามันเทไปทางพลังประมวลผลมากเกินไปแต่ VRAM ไม่พอ จึงดูดีสำหรับเกมเมอร์แต่ไม่ค่อยเหมาะกับการรัน LLM ผมเองก็ใช้ 5070 ในเดสก์ท็อปเหมือนกัน

  • cuttysnark: โมเดลโลคัลประสบความสำเร็จพอสมควรเมื่อ เชื่อมหลายเอเจนต์เป็น workflow
    เอเจนต์แต่ละตัวใช้พรอมป์ตและโมเดล ollama คนละแบบตามบทบาท ตัวอย่างเช่น เอเจนต์ผู้จัดการโปรเจกต์หรือเอเจนต์สคีมา (qwen3:14b) ไม่ได้ใช้โมเดลเดียวกับเอเจนต์เขียนโค้ด (qwen2.5-coder:7b)
    ระหว่างแต่ละขั้นจะมี orchestrator และงาน Playwright คอยพยายามเปิดเผยข้อผิดพลาดให้เอเจนต์ที่สร้างบล็อกโค้ดก่อนหน้าเห็น มีเพียงบล็อกที่ไม่มีข้อผิดพลาดเท่านั้นที่จะผ่านไปขั้นถัดไป
    การปรับปรุงที่ใหญ่ที่สุดคือเพิ่มนิยามบริการ backend-for-agents เข้าไป เพื่อให้เอเจนต์สคีมาสร้างเพียง manifest ที่อิงตามงานแล้วส่งต่อให้เอเจนต์ถัดไป สรุปคือกำหนด workflow แล้วแยกงานให้เอเจนต์ทำเฉพาะเรื่องมาก ๆ ก่อนส่งต่อไปขั้นถัดไป วิธีนี้ช่วยไม่ให้หลุดกรอบ และยังสร้างจุดที่มนุษย์เข้าแทรกได้ใน flow ที่สำเร็จแล้ว 25% หรือ 90%

    • pianopatrick: ถ้ามี benchmark และการแข่งขันของ workflow แบบนี้ก็น่าจะช่วยให้รู้ว่าอะไรเวิร์ก
      ประมาณว่า “ใช้ได้แค่ consumer GPU รุ่นนี้ แล้วเลือกโมเดลและ workflow ใดก็ได้เพื่อแก้ benchmark xyz ให้ดีแค่ไหน” น่าจะดีถ้ามีอะไรอย่าง “The Local AI challenge” ที่ให้ผู้เข้าแข่งขันเวลาไม่เกิน 1 ชั่วโมง แล้วให้คะแนนตามสัดส่วนที่ตอบได้ ความถูกต้อง และเวลารวม
    • sowbug: อยากรู้ว่าเคยลองให้เอเจนต์ แข่งกันเอง ไหม
      เช่น โยนงานโค้ดเดียวกันให้สองโมเดล หรือให้โมเดลเดียวกันแต่คนละ seed แล้วให้รีวิวเวอร์เลือกผลลัพธ์ที่ดีกว่า มีมุมมองหนึ่งที่ว่าแม้แต่สมองมนุษย์ก็ทำงานคล้าย ๆ กัน คือมี mini cortical columns หลายพันชุดที่มองสถานการณ์ต่างกันเล็กน้อยแล้วลงคะแนนเสียงข้างมาก

  • HappySweeney: มี Optane กับ RAM เยอะ เลยลองใช้โมเดลที่ใกล้เคียงกับโมเดลเต็มตัวที่ความเร็วประมาณ 0.7t/s เขียนฟังก์ชันข้ามคืน
    ตอนนี้กำลังทดสอบเปลี่ยนฟังก์ชัน Scala ให้เป็นฟังก์ชัน สลับตำแหน่งบิตเมทริกซ์ ที่ใช้ AVX512 อยู่ โมเดลคลาวด์จัดการได้สบาย แต่ Kimi 2.6 กับ GLM 5.1 ล้มเหลวแบบยับเยิน

  • etoxin: ยังแทนที่ไม่ได้เสียทีเดียว ในโปรเจ็กต์ที่ทำงานใช้ openspec และเพื่อเลียนแบบอุปกรณ์โลคัลโดยไม่ต้องเสียเงินก้อนใหญ่ ก็เลยจ่ายเงินใช้เวอร์ชันโฮสต์ของโมเดลโลคัลยอดนิยมรุ่นใหม่ ๆ
    โมเดลโลคัลขนาดเล็กส่วนใหญ่ยังทำ การเรียกใช้เครื่องมือ ได้ไม่ดี แต่โมเดลใหญ่ขึ้นตอนนี้เริ่มทำได้ดีแล้ว อีกจุดหนึ่งที่ฝั่งโลคัลยังไม่ได้คิดถึงคือ วิศวกรที่ทำงานได้อย่างมีประสิทธิภาพมักรัน CLI แชตหลายตัวพร้อมกันควบคู่กับ git worktree ปกติผมเปิด worktree กับ CLI แชตไว้ 3 ชุด

  • blurbleblurble: ตอนนี้ข้อจำกัดอยู่ที่ การใช้งานของฮาร์เนสทดแทน มากกว่าตัวโมเดลเอง เพราะฟีเจอร์อย่างการจัดการคิว การขัดจังหวะ ซับเอเจนต์ และเป้าหมาย กลับหายไปอย่างน่าประหลาด

    • coder543: เห็นด้วยเต็มที่ น่าหงุดหงิดเหมือนกันที่ OpenCode ไม่ได้พยายามรองรับ LLM แบบโลคัลอย่างจริงจัง
      ทำให้ OpenCode ใช้งานได้ก็จริง แต่การตั้งค่ายังเป็นแบบแมนนวลและกระท่อนกระแท่นมาก ผมเขียนสคริปต์แปลงการตั้งค่า llama-server เป็นการตั้งค่า OpenCode อัตโนมัติ ซึ่งช่วยได้ แต่ก็ยังไม่ใช่อุดมคติ
      ถึงขั้นเคยคิดจริงจังว่าจะทำโค้ดดิ้งฮาร์เนสอีกตัวในเวลาว่าง เพราะมีไอเดียบางอย่างที่น่าจะทำให้มันดีกว่าเดิมได้
    • horsawlarway: Pi ใช้ได้โอเค
      ผมเคยใช้ทั้งเอเจนต์ CLI ของ Claude, Cursor, Pi, ฮาร์เนสแบบคัสตอมที่ทำเอง รวมถึง gastown แล้ว และ Pi ก็ถือว่าเพียงพอเลย มันทำงานที่ต้องการได้ เครื่องมือพื้นฐานก็ใช้ได้ดี เชื่อมกับเครื่องมืออื่นได้ดี และทำให้ต้องปวดหัวน้อยลง
      ถ้าคุณรันโมเดลราว 30B ได้ด้วยความเร็วที่โอเค หลายคนน่าจะประหลาดใจกับสิ่งที่ทำได้เมื่อใช้คู่กับ Pi ใส่ส่วนขยายอย่าง https://pi.dev/packages/pi-mcp-adapter?name=mcp และ https://pi.dev/packages/pi-web-access?name=search ก็จะได้ทั้งเครื่องมือเว็บ, การค้นหา perplexity, การเข้าถึง MCP สำหรับควบคุม Chrome ผ่าน https://browsermcp.io/ และ Firefox ผ่าน https://github.com/mozilla/firefox-devtools-mcp
      มันไม่ได้ดีเท่ารุ่นท็อปที่มีเงินอุดหนุนหนุนหลัง แต่ก็ฟรีและยังเก่งพอตัว ส่วนตัวผมก็สนุกกับ https://pi.dev/docs/latest/sdk มากด้วย ในขณะที่ผู้ให้บริการรายอื่นคิดค่าการเข้าถึง API แบบนี้เดือนละหลายพันดอลลาร์
    • Insanity: เคยได้ยินเรื่องดี ๆ เกี่ยวกับ pi.dev แต่ยังไม่ได้ลองใช้ มันอาจช่วยแก้ปัญหาฟีเจอร์ที่ขาดไปบางส่วนที่พูดถึงได้

  • _bobm: เวลาพูดถึงโมเดล Claude/GPT ต้องคิดก่อนว่า “โมเดล” นั้นจริง ๆ คืออะไร
    ลองนึกดูว่า GPT ส่งส่วนของความคิดออกมาทีละส่วนได้อย่างไร และยังแนบสรุปหัวข้อ Markdown ของบล็อกความคิดนั้นได้ด้วย ถ้าสังเกต API endpoint กับพฤติกรรมการแสดงผล จะเห็นว่าโมเดลระดับ SOTA ที่เรียกกันนั้นไม่ได้เป็นอย่างที่เห็น และในเชิงโครงสร้างพื้นฐานก็เทียบกับโมเดลโลคัลตรง ๆ ไม่ได้เลย
    การปฏิบัติการในระดับนี้มี ออร์เคสเตรชัน จำนวนมหาศาล และข้อจำกัดของมันก็นำไปสู่นวัตกรรมที่ไม่ค่อยมีใครพูดถึง ผมไม่ได้คิดว่าตามไม่ทัน แต่การเสิร์ฟโมเดลโลคัลด้วย llama หรือ vLLM ยังเป็นแค่ระดับตัวอักษร A, B, C เท่านั้น
    ผมคิดว่าสิ่งที่ต้องทำจริง ๆ คือจำลองออร์เคสเตรชันที่ผมเกริ่นไว้ข้างบน โมเดล “SOTA” ไม่ใช่โมเดลเดี่ยวหนึ่งตัว แต่เป็นออร์เคสเตรชันที่ลึกของหลายโมเดลที่ทำงานร่วมกัน ดังนั้นโมเดลเดี่ยวจะยังตามไม่ทันจนกว่าจะจำลองออร์เคสเตรชันนี้ได้ทั้งในด้านการฝึกและสถาปัตยกรรม
    ผมคิดว่าโมเดลตัวหนึ่งภายในองค์ประกอบออร์เคสเตรชันที่ให้ผู้บริโภคทั่วไปใช้นั้น อาจไม่ได้เหนือกว่า Qwen 3.6 มากนัก พอมองอีกมุมก็จะเริ่มเห็นขนาดของ “เวทมนตร์” นี้

    • XCSme: ผมไม่เข้าใจว่าทำไมคุณถึงคิดว่าโมเดลระดับ SOTA เป็นออร์เคสเตรชันลึกของหลายโมเดล
      แล้วก็อยากเห็นตัวอย่างแบบเจาะจงของกรณีที่ GPT ส่งส่วนความคิดมาพร้อมสรุปหัวข้อ Markdown ด้วย

  • cheekygeeky: นักพัฒนาซอฟต์แวร์ของเราคือหนึ่งในคนที่ฉลาดที่สุดที่ผมเคยเจอ และเขาใช้ OpenCode กับ Tmux ร่วมกับโมเดลโอเพนซอร์ส
    สำหรับงานเขียนโค้ด เขาชอบ DeepSeek ที่สุดและเรียกมันว่า “ดีมากทีเดียว” รันบน i9, RAM 128GB และ 3090 สองใบ https://www.msn.com/en-us/news/technology/china-s-open-deeps...

  • pianopatrick: น่าจะดีถ้ามี เบนช์มาร์กและการแข่งขัน สำหรับเวิร์กโฟลว์แบบนี้ จะได้รู้ว่าอะไรใช้ได้ผลดี
    ประมาณว่า “ใช้ได้แค่ GPU สำหรับผู้บริโภคตัวนี้ แล้วดูว่าแก้เบนช์มาร์ก xyz ได้ดีแค่ไหนด้วยโมเดลและเวิร์กโฟลว์ที่ต้องการ” ผมอยากเห็นการแข่งขันแนว “The Local AI challenge” ที่ให้ผู้เข้าแข่งขันมีเวลาไม่เกิน 1 ชั่วโมง แล้วให้คะแนนจากสัดส่วนคำตอบ ความถูกต้อง และเวลาที่ใช้เสร็จ

  • bravetraveler: ผมใช้งานแบบแทบจะ “ธรรมชาติล้วน” และการใช้ LLM เพียงเล็กน้อยทั้งหมดก็เป็นแบบโลคัล
    บนระบบ Strix 128GB รุ่น Qwen หรือ Gemma ที่หนาแน่นน้อยกว่าจะให้เอาต์พุตราว 50~80tok/s ผมไม่คิดจะสมัคร Anthropic/OpenAI หรือเจ้าอื่น ๆ และต่อให้โลคัลโมเดลหยุดอยู่แค่นี้ก็ยังไม่จำเป็นสำหรับผม การใช้เครื่องมือภายในโมเดลช่วยครอบคลุมเรื่องความกังวลด้านความทันสมัยได้

  • GodelNumbering: ในฐานะคนที่คุยกับ LLM ทั้งวัน ผมคิดว่าชุด โมเดลฟรอนเทียร์โอเพนซอร์ส + ฮาร์เนสที่ดี นั้นเพียงพอแล้ว
    การติดตั้งใช้งานแบบโลคัลยังต้องรอฮาร์ดแวร์อีกสักหนึ่งหรือสองเจเนอเรชันกว่าจะย้ายไปทั้งหมดได้ แต่บริษัทฮาร์ดแวร์กำลังให้น้ำหนักกับฝั่งดาต้าเซ็นเตอร์อย่างมาก จึงอาจทำให้ช่วงเวลานั้นมาช้ากว่าที่หวัง

  • milchek: ลองบน MacBook Pro 36GB แล้ว แต่พอเกินงานพื้นฐานมาก ๆ ก็ไม่ค่อยประสบความสำเร็จ
    ถึงจะใช้โมเดลเล็ก ปัญหาก็คือบริบทหมดเร็วและช้าอยู่ดี ดูแล้วถ้าจะให้ได้ประสิทธิภาพพอใช้คงต้องมีหน่วยความจำ 128GB ซึ่งทำให้ต้นทุนฮาร์ดแวร์สูงขึ้นมาก
    สุดท้ายก็เป็นเรื่องว่าจะจ่ายค่าสมาชิกรุ่น frontier model หรือจะเอาเงินนั้นไปลงกับเครื่องแทน แน่นอนว่าถ้าให้ความสำคัญกับความเป็นส่วนตัวมาก ก็แทบไม่มีทางเลือกนอกจากทุ่มเงินกับอุปกรณ์ระดับสูง

  • acc_297: สงสัยว่าถ้าเอา RLHF มาใช้กับโมเดลขนาดกลางเป็นประจำทุกพรอมป์ต์ แล้วปรับจูนละเอียดให้เข้ากับพฤติกรรมการใช้งานส่วนตัว จะช่วยได้ไหม
    ไม่แน่ใจว่าการปรับจูนด้วยมือจะทำให้มันแย่ลงหรือดีขึ้น ถ้าให้ฟีดแบ็กอย่างสม่ำเสมอแล้วลดนิสัยติดตัวของโมเดลทั่วไปได้ เช่น การประจบเกินเหตุ ความเยิ่นเย้อ หรือชอบอธิบายด้วยอุปมาอุปไมยจนน่ารำคาญ ก็น่าจะดี แต่ก็ไม่รู้ว่าฟีดแบ็กจากพรอมป์ต์ของคนคนเดียวจะเพียงพอไหม
    เคยได้ยินว่าพวกเอเจนต์ภายในองค์กรที่ปรับจูนด้วยเอกสารภายในก็ยังมีพฤติกรรมแปลก ๆ และไม่ได้มีประโยชน์กว่ามาตรฐานเสมอไป ถ้าสามารถแก้ไขทุกคำตอบของเอเจนต์ แล้วเอาความต่างระหว่างต้นฉบับกับฉบับแก้ไขไปใช้ปรับจูนต่อได้ก็คงดี
    ส่วนตัวคงตัดคำขยายออกเยอะและขัดเกลาให้เหลือแต่คำตอบที่เป็นแก่น แต่พอดูงานของนักวิจัยด้าน alignment อย่าง Owain Evans ก็อดกังวลไม่ได้ว่าการปรับแบบนี้อาจผลักโมเดลไปสู่แนวโน้มที่คาดเดายาก

    • htrp: Cursor กำลังทำแบบนั้นอยู่ น่าจะใช้ Fireworks เป็นผู้ให้บริการ: https://cursor.com/blog/real-time-rl-for-composer
    • rolisz: อยากลองอะไรคล้าย ๆ กันกับ OpenClaw agent
      งานของ Owain Evans น่าจะเป็น SFT นะ มีคนใน Twitter บอกว่า RL เปราะบางต่อปรากฏการณ์ที่เขาแสดงให้เห็นน้อยกว่า แต่ผมอยากลองเอง

  • heisenbit: ต้องมีงานตั้งค่าพอสมควร แต่ก็ได้เรียนรู้อะไรเยอะจากกระบวนการนั้น
    บน M4 MBP 48GB ผมใช้ qwen/qwen3.6-35b-a3b mlx เป็นหลัก และยังพอเหลือทรัพยากรแบบฉิวเฉียดสำหรับ Docker dev-container กับงานพื้นฐาน ใช้รันผ่าน LM Studio แล้วใช้งานจาก VSCode
    การเปลี่ยน system prompt เพื่อปรับปรุงการรวมเครื่องมือเข้าด้วยกันสร้างความแตกต่างมาก ก่อนหน้านั้นมันมักจะสร้างโค้ดใหม่แทนการนำการแก้ไขไปใช้ เลยกลายเป็นพังมากกว่าช่วย
    เพื่อเลี่ยงเสียงรบกวนและความร้อน ผมเลยใช้โหมดพลังงานต่ำเกือบตลอดแม้ตอนเสียบไฟอยู่ โหมดประสิทธิภาพสูงสุดเร็วกว่าประมาณสองเท่า แต่กินไฟมากกว่าสองเท่า
    สิ่งที่ทำได้มีแค่ประมาณการปรับโครงหน้าเพจเล็ก ๆ น้อย ๆ ส่วนการแยก Pinia store ไม่สำเร็จ แต่ GPT-5.4 ทำงานนี้ได้ไม่มีปัญหา ผมคิดว่าถ้าปรับคู่มือการใช้เครื่องมือกับเครื่องมือสนับสนุนรอบข้างเพิ่มอีก ก็น่าจะดันประสิทธิภาพได้มากขึ้น

  • nfrankel: ลองแล้ว และในทางทฤษฎีก็ใช้ได้: https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...
    ผลลัพธ์ขึ้นอยู่กับโมเดล แต่สุดท้ายคอมพิวเตอร์ก็เป็นข้อจำกัด เครื่องผมน่าเสียดายที่รับไม่ไหว

  • K0balt: ได้ผลค่อนข้างดีกับ qwen 3.6 27b dense
    แล้วแต่งาน บางทีก็ใกล้เคียง Claude Haiku 4.5 และอาจถึงระดับ Sonnet ได้เลย

    • kadoban: อยากรู้ว่าใช้เครื่องมืออะไรขับงานพวกนี้
    • kandros: ถ้าเป็นงานเขียนโค้ด ผมยังอยากไปถามคนขายเนื้อมากกว่า Haiku

  • jderekw: สำหรับงานประจำวัน ผมใช้ AMD Lemonade
    เริ่มจาก Ollama แล้วย้ายไป LMStudio และตอนนี้มาลงเอยกับ AMD Lemonade เพราะช่วยดู cRAM, CPU, GPU และ gRAM ได้ดี ฟีเจอร์หลายโมเดลของ Lemonade ทำให้รันสแต็ก LLM, speech-to-text, NPU และการสร้างภาพได้ง่าย
    แพลตฟอร์มนี้ใช้ได้กับชิปเซ็ต Nvidia, Apple, Intel และ AMD

  • redox99: โมเดลอย่าง Qwen 35B ที่รันเองที่บ้านได้ ยัง ไม่ใกล้เคียง Opus หรือ GPT 5.5 เลย
    โมเดลโอเพนที่พอจะเข้าใกล้ได้คงระดับราว 1T พารามิเตอร์ ดังนั้นลืมเรื่องรันที่บ้านไปได้เลย มันเหมือนขับรถเก่าโทรม ๆ อาจมีคนเยอะและพอใช้ไปถึงจาก A ไป B ได้ แต่จริง ๆ แล้วมันไม่ได้โอเค
    ถ้าไม่ใช่ว่าต้องการความเป็นส่วนตัวแบบเด็ดขาด ทำเล่น ๆ หรือมีกรณีพิเศษอย่างบนเครื่องบิน ก็ไม่มีเหตุผลเชิงตรรกะเลย ถ้ายังไม่ยอมจ่าย 20 ดอลลาร์ที่ Codex ได้รับการอุดหนุนหนักมาก การใช้ API ของโมเดลจีนก็กินขาดโมเดลเล็กพวกนี้อยู่ดี

    • pbasista: อยากรู้ว่าความเห็นที่ว่า “โมเดลที่รันที่บ้านได้อย่าง Qwen 35B ไม่ได้ใกล้เคียง Opus หรือ GPT 5.5 เลย” อิงจาก ข้อเท็จจริงเชิงวัตถุหรือเบนช์มาร์ก อะไรบ้าง
    • xgulfie: คุณไม่ได้ต้องใช้ Ferrari เพื่อขับไปทำงาน

  • sj_tech: บน Mac Mini 128GB ผมใช้ GitHub Copilot Extension for VSCode กับ Qwen 3.6 35B A3B สำหรับ agent coding
    ถือว่าใช้ได้เมื่อเทียบกับขนาดโมเดล แต่พอปัญหาใหญ่เกินไปก็เห็นมันวนลูป ใช้ให้มันทำงานที่เรารู้อยู่แล้วว่าทำอย่างไรเพื่อลดเวลาได้ดี

  • julianlam: บน Framework 13 หน่วยความจำ 32GB ผมรัน Qwen 3.6 35B-A3B ด้วย llama.cpp ได้ 15tok/s
    มันปล่อยโค้ดกับข้อความออกมาเร็วกว่าอัตราที่ผมอ่านทัน

  • moezd: ตอนนี้ยังไม่ใช่ ถ้าไม่มีเกมแบบ Apple ล้วน ๆ หรือไม่มี GPU ดี ๆ ต่อให้มี RAM กับเธรดเยอะ ก็ได้แค่ประมาณ 30~50tok/s และนั่นคือตอนปิด thinking แล้ว
    ถ้าไม่มีการปรับแต่งพวกนี้ โมเดลก็จะกิน MCP, skills และคำอธิบาย agent ไปเรื่อย ๆ จนคุณนั่งดูสีแห้งกว่าจะได้เห็น output token แรก
    การเสิร์ฟโมเดลแบบโลคัลต้องประหยัดทุกโทเคนใน context window ซึ่งตรงข้ามสุด ๆ กับทิศทางที่ Claude/GPT/Copilot กำลังผลักอุตสาหกรรมไป

    • amarshall: thinking ไม่ได้เปลี่ยนความเร็วเอาต์พุต ความเร็วเอาต์พุตมัธยฐานของโมเดล Anthropic อยู่ราว 40~60t/s

  • mitchell_h: ลองแล้ว แต่ context window ยังใหญ่ไม่พอ

    • coder543: Qwen3.6-27B รองรับ context window 1 ล้านโทเคน
      แน่นอนว่าคุณต้องมีฮาร์ดแวร์ที่รัน context window แบบนั้นได้ และบน DGX Spark ของผม ถ้าใช้ q4_k_xl model พร้อม f16 KV cache เต็ม จะต้องใช้หน่วยความจำราว 100GB
    • lysace: ผมก็ได้ผลคล้ายกัน RTX 4070 ของผมมีแค่ 12GB เลยสงสัยว่า 24/32GB จะดีขึ้นมากพอจนใช้งานได้จริงไหม
    • deadbabe: แทนที่จะถามกว้าง ๆ แบบปลายเปิด ลองพรอมป์ต์ให้ตรงกว่านี้

  • drnick1: อยากรู้ว่า โมเดลสำหรับเขียนโค้ด ที่ดีที่สุดในตอนนี้ซึ่งรันได้บน GPU สำหรับผู้บริโภคระดับสูงคืออะไร
    ถ้าสมมติว่ามี RTX 3090/4090 อยากรู้ด้วยว่าจะแนะนำสแตกแบบไหน บางทีอาจเป็นชุดอย่าง Llama.cpp + OpenCode

  • bijowo1676: รู้สึกว่าน่าสนใจกับเวิร์กโฟลว์ที่ใช้โมเดล frontier ราคาแพงเพื่อเขียนและอัปเดต เอกสาร Markdown อย่างสเปกแอป ความต้องการของผลิตภัณฑ์ หรือสถาปัตยกรรม แล้วให้โมเดลที่ถูกกว่าหรือโมเดลโลคัลมาลงมือทำตามสเปกนั้น
    Markdown บีบอัดข้อมูลได้ดีกว่าไฟล์ซอร์สหลายร้อยไฟล์จึงใส่ใน context window ได้ง่ายกว่า แต่การเก็บรายละเอียดให้เรียบร้อยต้องมีการไล่เกลารอบสองรอบสาม เลยสงสัยว่ามีใครลองทำแบบนี้ไหม

  • grmnygrmny2: ผมมีความรู้สึกคัดค้านในเชิงจริยธรรมต่อการใช้ผลิตภัณฑ์ของ OpenAI หรือ Anthropic เลยลังเลแม้แต่จะนำ LLM มาใช้
    โมเดลโลคัลช่วยแก้ความขัดข้องทางศีลธรรมส่วนใหญ่ได้ ตอนนี้เลยใช้มันมาประมาณหนึ่งเดือนทั้งกับงานและโปรเจกต์ส่วนตัว ฮาร์ดแวร์ที่มีคือ Mac 32GB กับพีซีเกมมิง 3080 10GB ดังนั้นเพดานก็อยู่แถว ๆ Qwen3.6-35B-A3B ที่ควอนไทซ์หลายแบบ แต่ก็เพียงพอ
    ได้ประมาณ 200~400 PP และ 20~30 TG และต้องใช้เวลาพอสมควรกว่าจะเรียนรู้วิธีใช้งานให้ได้ผลดี บางงานยังต้องคอยดูแลหรือช่วยบอกทิศทาง แต่โดยรวมมีประโยชน์มาก
    ไม่เคยใช้ CC เลยเทียบกันไม่ได้ แต่ทำหน้าที่เป็นผู้ช่วยหรือ pair programmer ที่ดีได้ตั้งแต่ embedded C++ ไปจนถึง Vue ถ้ารัน 27B ได้ก็คงดี และบางครั้งโมเดลนี้จะเหมือนเกือบเข้าใจอะไรบางอย่างแล้วก็ไปต่อไม่ไหว แต่เกิดไม่บ่อย
    มันช่วยประหยัดเวลาได้มากในหลายงาน และเก่งในการขุดหาบั๊กแล้วแก้ให้ได้แม้มีเพียงคำสั่งที่ค่อนข้างกำกวม ส่วน harness ใช้ Pi