Qwen แบบรันในเครื่องไม่ใช่ Opus ที่แย่กว่า แต่เป็นเครื่องมืออีกแบบหนึ่ง

• Qwen 3.6 27B แบบรันในเครื่องให้คุณค่าเชิงปฏิบัติได้จริงในงานที่ นำขึ้นคลาวด์ได้ยาก เช่น ข้อมูลลูกค้าและเทเลเมทรีภายใน แต่ยังไม่สามารถทดแทนโมเดล SOTA บนคลาวด์ได้
• จุดแข็งของโมเดลแบบรันในเครื่องไม่ได้อยู่ที่การแข่งขันด้านคะแนนกับโมเดลประสิทธิภาพสูงสุด แต่อยู่ที่ ต้นทุนคงที่ การคุ้มครองความเป็นส่วนตัว และการลดความเสี่ยงจากผู้ขาย โดยจะเห็นความต่างชัดเจนเป็นพิเศษใน งานใช้งานหนักและฟีเจอร์ภายในของ SaaS
• บน SWE-Bench Verified นั้น Qwen 3.6 27B ได้ 77.2 คะแนน ส่วน Claude Opus 4.8 ได้ 88.6% โดยคำกล่าวว่า "โมเดลในเครื่องตามหลัง SOTA แค่ 12%" มองข้ามทั้งความเป็นไปได้ในการจูนเพื่อทำคะแนนเบนช์มาร์ก และความแตกต่างของโดเมนจริงอย่าง Go
• อุปกรณ์ RTX 6000 Pro Blackwell 96GB ที่ซื้อมาในราคาประมาณ 12,000 ดอลลาร์ สามารถคืนทุนได้จากกรณี กู้คืนรายได้ เพียงกรณีเดียวที่ตรวจพบการรายงานไลเซนส์ของลูกค้าต่ำกว่าความเป็นจริง
• ข้อจำกัดที่ใหญ่ที่สุดคือ ปัญหาลูป ซึ่งทำให้เกิดการพ่นข้อความซ้ำและอาการหลอนในงานยาว ๆ โดย Qwen แบบรันในเครื่องเหมาะกับ ซัพพอร์ตลูกค้า งานบำรุงรักษาขอบเขตแคบ การอ่านและอธิบายโค้ดเบส มากกว่างานเขียนโค้ดระยะยาวแบบไม่มีผู้กำกับดูแล

---

เบื้องหลังการใช้ AI และบริบทธุรกิจ

• ทีมขนาดเล็กดูแลผลิตภัณฑ์ที่เน้น โครงสร้างพื้นฐานระดับล่างและ Linux primitives อย่าง OpenFaaS, SlicerVM, Actuated, Inlets
  • ใช้คอนเทนเนอร์, Firecracker microVM, โปรโตคอลเครือข่าย, tunnel, CLI, Kubernetes และเขียนด้วย Go เป็นหลัก พร้อม React UI บางส่วน
• ใช้เครื่องมือ AI มาตั้งแต่ยุค VS Code tab autocomplete และตอนนี้โค้ดส่วนใหญ่ทำโดย Claude หรือ Codex แทบไม่ได้เขียนเองด้วยมือแล้ว
• เพื่อจัดการเวิร์กโฟลว์การทำงานยาว ๆ ใน tmux จึงสร้าง Superterm.dev ขึ้นมา และใช้สำหรับจัดการเซสชัน/โน้ต รวมถึงเป็นภาพตอบกลับให้กับ coding agent

จุดเปลี่ยนของความฉลาดระดับ frontier

• มีจุดเปลี่ยนเกิดขึ้นระหว่างเดือนพฤศจิกายน 2025 ถึงมกราคม 2026 โดยนักพัฒนาหลายคนบน X ประเมินว่า Claude Opus สามารถจัดการงานทั้งหมดของตัวเองได้
• ค่าแพ็กเกจโค้ดดิ้งระดับท็อปเริ่มนิ่งที่ ประมาณ 200 USD ต่อเดือน สำหรับผู้ใช้รายบุคคล และถ้าเลี่ยงงานแบบไม่มีผู้กำกับดูแลที่หนักเกินไป ก็ยังใช้งานได้ภายใต้โควตา 5 ชั่วโมง/รายสัปดาห์

ทำไมโมเดลในเครื่องถึงน่าสนใจ

• ปี 2026 เป็นยุคที่ใครก็สามารถคัดลอกไอเดียข้ามคืนได้ด้วยการสมัครสมาชิกเพียงหนึ่งรายการ โดย SlicerVM และ Superterm ก็เคยเจอกรณีถูกโคลนแล้ว
  • ในตลาดที่ ต้นทุนซอฟต์แวร์เข้าใกล้ศูนย์ สิ่งสำคัญอาจกลายเป็นคำว่า "ฟรีและดีพอ"
• คาดว่าโมเดลชั้นนำมีขนาด 0.5~2T พารามิเตอร์ ซึ่งเป็นคนละระดับกับฮาร์ดแวร์รันในเครื่องที่ดีที่สุด

• Benchmaxxing

  • เบนช์มาร์กเป็นข้อมูลสาธารณะ จึงสามารถ จูนเพื่อปั่นคะแนน ได้ และเชื่อถือเป็นตัวชี้วัดสัมบูรณ์ได้ยาก
  • SWE-Bench Verified อิงจากปัญหาใน Python แต่โค้ดส่วนใหญ่เป็น single-thread และ synchronous ขณะที่ระบบกระจายศูนย์ด้วย Go มี channel, context, struct กระจายครอบคลุมพื้นที่รันไทม์ขนาดใหญ่
  • จึงยากจะสรุปจากคะแนนเบนช์มาร์กเพียงอย่างเดียวว่า “โมเดลในเครื่องตามหลัง SOTA 12%” เพราะในงานจริง ลักษณะของภาษาและระบบ มีผลต่อความสำเร็จอย่างมาก

• ต้นทุน (Cost)

  • คำพูดที่ว่า “โมเดลในเครื่องไม่ใช่เรื่องต้นทุน” ใช้ไม่ได้กับทุกคน
  • แพ็กเกจโค้ดดิ้งสำหรับผู้ใช้รายบุคคล ให้การใช้งานสูงและความฉลาดระดับ SOTA ในราคา 200 ดอลลาร์ต่อเดือน แต่ตัวแพ็กเกจเองก็ดูเหมือนเป็นโครงสร้างที่มีการอุดหนุน (subsidised)
  • GitHub Copilot เคยมีโครงสร้างราคา 39 ดอลลาร์ต่อเดือนสำหรับ 1,500 คำขอ ก่อนเปลี่ยนไปคิดเงินตามโทเค็น ซึ่งสร้างแรงต้านอย่างมาก
  • ถ้าคิดเงินตามต้นทุน API token จุดคุ้มทุนอาจมาถึงเร็วมาก
    • Uber จำกัดค่าใช้จ่าย AI ไว้ที่ 1,500 ดอลลาร์ต่อเดือนต่อเครื่องมือ ต่อหนึ่งนักพัฒนา
    • เมื่ออิงจากเงินเดือนมัธยฐานของ Uber ที่ 330,000 ดอลลาร์ หากนักพัฒนาใช้สองเครื่องมือจนเต็มเพดาน จะเท่ากับราว 12% ของเงินเดือน
  • สำหรับการใช้งานปริมาณมาก ลูป การวิเคราะห์โดย agent และฟีเจอร์ฝังใน SaaS นั้น โมเดล open weight และโมเดลในเครื่องให้คุณค่าได้มาก

• อธิปไตยและความเป็นส่วนตัว (Sovereignty and privacy)

  • มีกรณีที่ไม่สามารถนำข้อมูลขึ้นคลาวด์ได้เพราะข้อมูลลูกค้าและเงื่อนไขตามสัญญา
  • แม้ ChatGPT Pro และ Claude Max จะตั้งระยะเวลาเก็บข้อมูลเป็น 30 วันได้ แต่ผู้เขียนมองว่าแค่นั้นก็อาจทำให้สัญญากับลูกค้าเป็นโมฆะได้
  • กรณีที่โมเดล Fable 5 ของ Anthropic ถูกถอดออกข้ามคืนสำหรับผู้ใช้นอกสหรัฐฯ ก็กลายเป็น ความเสี่ยงจากผู้ขาย
  • โมเดลในเครื่องคือคำตอบของคำถามว่า "ถ้า frontier lab ทำ X ขึ้นมาจะทำอย่างไร?"

อุปมาการตีดาบ — ธรรมชาติของโมเดลในเครื่อง

• เหมือนการอบชุบเหล็กที่ถ้าพลาดไปเพียงขั้นเดียวก็ต้องเริ่มใหม่ทั้งหมด โมเดลในเครื่องก็เช่นกัน หาก ร้อนเกินไปก็จะเลยเป้าหมายและติดลูป
  • วิธีแก้เพียงอย่างเดียวคือปิด harness แล้วเริ่มใหม่ด้วย context ที่ว่างเปล่า เพื่อหวังผลลัพธ์ที่ต่างออกไป
• เช่นเดียวกับที่ไม่มีใครปล่อยให้การตีดาบดำเนินไปโดยไร้การกำกับ ผู้เขียนจึง ไม่มอบงานที่มี horizon ยาวให้ Qwen 3.6 27B ทำเอง

• สิ่งที่ฉันตามหา (What I was looking for)

  • เป้าหมายคือความเป็นส่วนตัว ต้นทุนคงที่ และการป้องกันความเสี่ยงจากผู้ขาย
  • ความผิดหวังเกิดขึ้นเมื่อปฏิบัติต่อโมเดลในเครื่องเหมือน Claude หรือ Codex
  • Claude สามารถทำลูปการทำงานอย่างมีประสิทธิภาพ เช่น สั่งสั้น ๆ ว่า "do it and test it end to end" แล้วสร้าง PR, รีวิวโค้ดอัตโนมัติ และทำซ้ำงานภายใน 5~15 นาที

บทเรียนจาก 3090

• เริ่มต้นในปี 2023 ด้วย 3090 เพียงใบเดียว ก่อนจะต้องเพิ่มอีกใบเพื่อให้โหลดโมเดลและมี context เพียงพอ
  • นั่นคือช่วงแรกที่ได้เห็นว่า Qwen 3.5 ทำงานจริงในฐานะ agent ได้
• เมื่อสั่งให้ "สำรวจเครื่องจากทุกมุมและเขียนรายงานเชิงนิติวิทยาศาสตร์" โมเดลอ่านทุกไฟล์ทีละไฟล์จน context เต็ม และ หลอนชื่อไฟล์/การเรียก tool (~/faas-netes→~/faaned)
  • พอลดขอบเขตงานลงและบอกให้ "ลองดูแบบคร่าว ๆ" ก็สร้างรายงานที่ชัดเจนได้ที่ราว 40~50 tok/s
• โมเดล 27B ไม่สามารถใส่ลงใน 3090 ใบเดียวแบบ full precision ได้ ดังนั้นตัวแปรที่ต้องปรับคือ การ quantize weight, ความยาว context, การบีบอัด KV cache
  • โดยทั่วไปถือกันว่าส่วน keys ของ KV cache จะมี ปัญหาเมื่อใช้ Q4_0 และแม้จะบีบหนักที่สุดก็ใช้ได้เพียง keys Q8_0 / values Q4_0
• แม้จะทดลอง vLLM + NVLink + tensor parallelism ความเร็วการสร้างก็ยัง ช้ากว่า llama.cpp 3 โทเค็นต่อวินาที อีกทั้งยังเกิดลูปและใช้เวลาหลายนาทีในการโหลด weight
  • vLLM เหมาะกับการเสิร์ฟพร้อมกันในสเกลใหญ่ แต่ในสภาพแวดล้อม prosumer เวลาเริ่มต้น ความเรียบง่าย และ latency ของผู้ใช้เดี่ยวสำคัญกว่า

ค่าใช้จ่ายก้อนใหญ่ — การนำ RTX 6000 Pro มาใช้

• เพื่อแก้ปัญหาตั๋วซัพพอร์ตลูกค้าได้อย่างรวดเร็ว จึงซื้อ RTX 6000 Pro Blackwell (VRAM 96GB) ในราคาราว 12,000 USD
  • หลังจากนั้นราคาขึ้นไปประมาณ 15,400 USD ทำให้การเพิ่มการ์ดใบที่สองเป็นเรื่องยาก
  • ด้วยข้อจำกัดเรื่อง PCI lane, แบนด์วิดท์, ระยะห่างระหว่างการ์ด, ภาระของ PSU ฯลฯ จึงไม่สามารถเพิ่มเข้ากับเครื่องคอนซูมเมอร์ได้แบบง่าย ๆ
• แม้เป็นการเดิมพันที่คิดมาแล้วและให้ผลลัพธ์จริง แต่ก็ ไม่สามารถแทนที่การสมัคร Claude ได้

ซัพพอร์ตลูกค้าได้ง่ายโดยไม่มีข้อมูลรั่วไหล

• สร้างเครื่องมือ CLI ชื่อ "diag" ที่ผู้ดูแลระบบสามารถรันได้ง่าย เพื่อจับ สแนปช็อตแบบครบถ้วน ของการติดตั้ง OpenFaaS บน Kubernetes
  • จากนั้นนำ dump ที่ได้รับไปวิเคราะห์ด้วย โมเดลในเครื่องแบบ airgapped ภายใน ephemeral VM ที่ Slicer สร้างขึ้น

• กู้คืนรายได้ (Revenue recovery)

  • ป้อนฐานข้อมูลเทเลเมทรีเข้าโมเดลในเครื่อง แล้วตรวจพบลูกค้ารายหนึ่ง รายงานไลเซนส์ต่ำกว่าความจริงนานกว่า 12 เดือน และค้างชำระ 4~5 เท่า ซึ่งการกู้คืนกรณีนี้เพียงครั้งเดียวก็คุ้มค่าการ์ดแล้ว
  • เทเลเมทรีและ diag dump จะไม่ถูกนำเข้า แผนคลาวด์ใด ๆ ไม่ว่านโยบายเก็บข้อมูลจะเป็นอย่างไร
  • แม้ ChatGPT Pro และ Claude Max จะตั้ง retention 30 วันได้ แต่แค่นั้นก็ยังมีโอกาสทำให้สัญญากับลูกค้าเป็นโมฆะ
  • โมเดลรุ่นแรกมีปัญหาเรื่องเลขคณิต เช่น คำนวณ 27.3K เป็น 273,000 และมองข้ามการใช้งานที่ถี่เพียงเพราะจำนวนฟังก์ชันน้อย จนสรุปผิดว่าเป็นการ churn
  • สรุปแล้วควรทำให้มัน โฟกัสที่การวิเคราะห์มากกว่าการตีความ

เซ็ตอัพปัจจุบัน

• บน rig ที่ใช้ RTX 6000 นั้น รันทั้ง Qwopus รุ่นล่าสุดและ base Qwen 3.6 27B โดยปรับเปลี่ยนตาม finetune ใหม่และ point release
  • Qwopus เป็นโมเดล finetune บน Qwen ที่พยายามเพิ่มการติดตาม Chain of Thought เพื่อยกระดับความสามารถด้านเหตุผลและการเขียนโค้ด
  • จนเมื่อไม่นานมานี้ผู้เขียนปิด thinking ไว้ทั้งหมด และช่วงที่เปิดกลับมาอีกครั้งก็ตรงกับช่วงที่ลูปเพิ่มขึ้นพอดี
• เสิร์ฟผ่าน llama.cpp สองอินสแตนซ์แยกจากกัน เพื่อคงความยาว context แบบเต็ม โดย --parallel 2 จะลด context ลงครึ่งหนึ่ง
• ใน speculative decoding (MTP) มี อัตราการยอมรับราว 93% ทำให้ความเร็วเพิ่มจาก 67 tok/s แบบคงที่ไปเป็น 130~200 tok/s และให้ความรู้สึกว่าเร็วกว่าใช้งานบนคลาวด์
  • การทำตามคำแนะนำการจูนจาก model card เป็นเรื่องสำคัญ โดย Qwopus ทำงานได้ดีที่สุดเมื่อปิด thinking และตั้ง temperature ให้ร้อนมากที่ 0.85~1.0

การพ่นข้อความซ้ำและข้อจำกัดของงานระยะยาว

• ปัญหาใหญ่ที่สุดของ Qwen คือการติด ลูป ในงานที่มีขอบเขตยาว
• เมื่อถามถึงคำสั่งที่จะเพิ่มใน faas-cli ตอนแรกมันเสนอไอเดียที่สมเหตุสมผล แต่หลังจากนั้นกลับพ่นรายการคำสั่งเดิมซ้ำไปมาและใช้ไฟ 600W นานราว 30 นาที
• ตอนให้เพิ่ม --json กับคำสั่ง get และ list ทั้งหมด ช่วงแรกหนึ่งหรือสองรายการยังดูใช้ได้และมีการเขียนเทสต์ แต่หลังจากนั้นปัญหาก็ขยายใหญ่ขึ้น
• เมื่อต้องทำให้เอาต์พุต --json หยุดแสดง insecure TLS warning ของ remote endpoint แบบ http:// โดยใช้ Python reverse proxy เวอร์ชันแรกดูพอใช้ได้ แต่ indent ผิด และระหว่างแก้ก็ทำไฟล์พัง ก่อนจะติดค้างและวนซ้ำต่อไป
• เพื่อนร่วมทีมชื่อ Han ก็เจอลูปคล้ายกัน โดยเฉพาะรูปแบบที่โมเดลหรือ agent ไปติดอยู่ตรงขอบเขตความสามารถของตัวเองแต่ไม่ยอมขอความช่วยเหลือ
• เพราะปัญหานี้เอง จึงยากจะเชื่อถือ Qwen แบบรันในเครื่องได้ง่าย ๆ นอกเหนือจากงานซัพพอร์ตลูกค้าและการวิเคราะห์เทเลเมทรี/diag เพื่อการต่ออายุ

การวัดการเข้าถึงและการกระจายการใช้งาน

• ตอนแรกใช้ inlets tunnel เดียว และเมื่อมี agent สองตัวมาเชื่อมกับอินสแตนซ์ llama.cpp เดียวกัน prefix ที่ถูกแคชไว้จะล้างกันเอง ทำให้ต้อง ประมวลผลพรอมป์ทั้งหมดใหม่
• เมื่อมีหลายคนใช้งาน มันจะหลุดจากระดับต้นแบบทันที และเกิดปัญหาการจัดการว่าใครใช้อินสแตนซ์ไหน เท่าไร ใช้โมเดลอะไร ค่าไฟเป็นเท่าไร และถ้าพนักงานลาออกจะทำอย่างไร
• แทนที่จะต้องแก้และแจกจ่าย opencode.json ด้วยมือ จึงเขียน provider สำหรับ opencode ชื่อ "Toilgate" ขึ้นมา เพื่อให้เลือกได้ตั้งแต่ base model ไปจนถึงสายพันธุ์ Qwopus แบบทดลองใน model picker
  • Toilgate เขียนแบบ 100% vibe-coded และการทำเป็นโอเพนซอร์สก็ดูเป็นภาระมาก
• วัดการใช้พลังงานจากปลั๊กที่ผนังด้วย Shelly Plus Plug 2 สองตัว โดย RTX 6000 Pro ใช้ไฟ 600W ระหว่าง infer และเงียบ ส่วน 3090 สองใบรวมกันใช้ราว 750W และเสียงดังมาก

• การเปรียบเทียบที่ผิด (The wrong comparison)

  • การเอาต้นทุนรับเข้า/ส่งออกต่อหนึ่งล้านโทเค็นไปเทียบกับราคา API ของ GPT-5.5 เป็น การเปรียบเทียบที่ผิด เมื่อพิจารณาจากความสามารถในปัจจุบัน
  • สุดท้ายแล้ว "Local AI" คือ ปัญหาด้านปฏิบัติการ ที่ต้องมีระบบยืนยันตัวตน การควบคุมการเข้าถึง การคิดมิเตอร์ โควตา การ route โมเดล และการมอนิเตอร์การใช้พลังงาน

รูปแบบการใช้งานที่ช่วยได้จริง

• สิ่งสำคัญคือทำให้โมเดลในเครื่องและ harness เชี่ยวชาญกับงานเฉพาะทาง
  • ซัพพอร์ตลูกค้า
  • งานบำรุงรักษาที่กำหนดขอบเขตได้ดี
  • การทดสอบแบบ end-to-end
• หากเพิ่มคำสั่งอย่างละเอียดใน AGENTS.md โมเดลในเครื่องจะสามารถเพิ่ม CLI ใหม่ได้เร็วและมีประสิทธิภาพขึ้น รวมถึงทดสอบเองได้ด้วย
  • ผู้เขียนเห็นผลแบบนี้ใน alexellis/arkade
• แม้โมเดลในเครื่องจะมีข้อจำกัดในการเขียนโค้ดโดยตรง แต่กลับเก่งในการอ่านและอธิบายโค้ดเบสอย่างรวดเร็ว
• Agent Skills ก็ช่วยได้เช่นกัน และมีกรณีที่ local agent ตั้งค่า Slicer บน mini PC เครื่องใหม่ตั้งแต่ต้น ได้สำเร็จ
• ควรทำแนวทางให้เป็นมาตรฐานว่าให้รันงานเดียวกันทั้งกับโมเดลในเครื่องและโมเดลบนคลาวด์
  • เช่น กรณีเปรียบเทียบงานเดียวกัน ที่บางครั้งผลก็น่าผิดหวัง และบางครั้งก็รู้สึกว่าโชคดี
• ควรหลีกเลี่ยงงาน agent แบบไม่มีผู้กำกับดูแลที่มีขอบเขตยาว และแม้อุปกรณ์จะมีราคาสูงเกือบ 15,000 ดอลลาร์ก็ยังแก้ปัญหานี้ไม่ได้

ข้อสรุปปัจจุบันและข้อจำกัดในการเลือกโมเดล

• Qwen แบบรันในเครื่องไม่ใช่สิ่งที่ “ใกล้เคียงระดับ Opus” เท่าไรนัก แต่เป็น เครื่องมือคนละแบบ ที่มีคุณค่าในงานและเวิร์กโฟลว์บางประเภท
• Qwen 3.5 ถูกประเมินว่าเป็นโมเดลแรกที่ให้ผลลัพธ์ที่ใช้งานได้ และแม้จะมีข่าวลือเรื่อง 3.7 ผู้เขียนก็คาดหวังเพียงการพัฒนาแบบค่อยเป็นค่อยไปมากกว่าการเปลี่ยนแปลงระดับปฏิวัติ
• โมเดล 70B ส่วนใหญ่ถือว่าเก่าและตามหลังเจเนอเรชันปัจจุบันแล้ว
• Qwen 35-A3B เป็นที่นิยมเพราะดูเร็วบน MacBook แต่เพราะมี active parameter แค่ 3B ตอนสร้างผลลัพธ์ ผู้เขียนจึงเลือกคุณภาพมากกว่าความเร็ว
• โมเดลที่ใหญ่กว่าอย่าง GLM 5.2, Kimi 2.7, Minimax M3, Deepseek V4 Flash แม้บางส่วนจะสามารถใช้กับฮาร์ดแวร์ในเครื่องได้ แต่บ่อยครั้งต้องใช้ RTX 6000 Pro ถึง 4~6 ใบเพื่อโหลดแม้แต่เวอร์ชัน quantized จึงอยู่นอกขอบเขต
• ตอนนี้โมเดล dense ขนาด 27B ยังไม่ดีพอสำหรับการเขียนโค้ด Go ทั้งวัน และข้อจำกัดด้านความรู้กับสมาธิก็เผยออกมาทันทีในงานรีวิวโค้ด
• Qwen ไม่ค่อยทำตามคำสั่งให้เขียนแบบกระชับ และมักเขียนรายละเอียดเกินจำเป็นในการรีวิวโค้ดอัตโนมัติ หรือหลอนประเด็น concurrency และ race condition จนการทดลองต้องหยุดอย่างรวดเร็ว
• Grok Coder Fast 1 ที่ถูกกว่าและเร็วกว่าเคยทำงานได้ดีอยู่หลายเดือนก่อนจะถูก deprecated
• กรณีศึกษาที่เกี่ยวข้องถูกรวบรวมไว้ใน code review bot และ OpenFaaS's painless customer support and architecture review

[GN⁺]

ความคิดเห็นจาก Hacker News

• ถ้าใช้โมเดลพวกนี้มานานพอ จะรู้ว่ามันไม่ใช่แค่เรื่อง “X ฉลาดกว่า Y” หรือ “Y ถูกกว่า Z” เท่านั้น พวกมันเป็นเครื่องมือคนละแบบกัน และแม้แต่วิธีการพรอมป์ต์ก็ยังต่างกัน ซึ่งค่อนข้างคล้ายกับการเล่นเครื่องดนตรี
  บางครั้งกับ Claude คุณต้องตั้งใจเขียนให้ชัดน้อยลงหรืออ้อมขึ้นนิดหน่อย ถึงจะใส่สีสันให้การนำไปใช้จริงหรือดึงผลลัพธ์เชิงสร้างสรรค์ออกมาได้ และแม้มันจะฟังดูแปลก แต่ถ้าคุณสุภาพกับ Claude คุณจะได้ผลตอบแทนกลับมา แต่ถ้าหยาบคายก็จะเสียประโยชน์ Claude มักเลียนแบบโทนเสียงได้แรงกว่า จึงควรหลีกเลี่ยงไม่ให้ตกเข้าไปในลูปเชิงลบ
  GPT ต้องเขียนให้แม่นยำและลดความกำกวม GPT มักพยายามแก้ความกำกวมด้วยวิธีแบบมิน-แม็กซ์ เช่น “จะทำ X แต่ไม่ให้เป็น Y” และถ้าคุณไม่ระบุขอบเขตให้ชัด มันจะพยายามเก็บทุกกรณีขอบเขตและมีแนวโน้มจะออกแบบเกินจำเป็น
  Qwen ต้องกำหนดโครงไว้ก่อนแล้วให้มันเติมข้างใน Qwen ชอบ XML, JSON, รายการ และทำได้ดีถ้าให้ตัวอย่างงานก่อนหน้าเยอะ ๆ นี่ไม่ใช่เรื่องเชิงวิทยาศาสตร์อะไร แค่ความรู้สึกส่วนตัว ดังนั้นผลลัพธ์อาจต่างกันได้

  • ตรงที่ว่า “ไม่เชิงวิทยาศาสตร์ แค่ความรู้สึก” นั่นแหละคือปัญหา อยากให้มีคู่มือสินค้าแบบที่เขียนจุดแข็งและจุดอ่อนของแต่ละโมเดลไว้ เพื่อให้มี decision tree ว่า “งานแบบนี้ใช้โมเดล X” หรือ “โมเดล Y ต้องใช้แบบ Z”
    แต่ภายนอกแล้วมันดูคล้ายกันไปหมด และถ้าอยากรู้ว่าอะไรดีกว่าเล็กน้อยตรงไหน ก็ต้องไปทดสอบเองแบบกว้างขวาง ใช้เวลามาก และอาจเสียค่าใช้จ่ายสูงด้วย
  • เมื่อก่อนผมเคยลองเยอะมาก ทั้งรันพรอมป์ต์เดียวกันซ้ำกับอินพุตเดิม หรือใส่อินพุตที่คิดว่าเทียบเท่ากันในเชิงความหมายแต่ต่างกันแค่ถ้อยคำหรือโครงสร้าง แล้วดูว่าผลลัพธ์แตกออกไปแค่ไหน โดยเฉพาะระหว่าง Sonnet กับ Opus และระหว่างโมเดล Qwen หลายตัว
    แนะนำให้ทุกคนลอง เพราะไม่ต้องใช้ข้อมูลพิเศษอะไรนอกจากข้อมูลที่ใช้อยู่แล้ว และผลที่ได้ค่อนข้างน่าตกใจ มีความสุ่มหรือความไม่เสถียรมากกว่าที่คิดเยอะ และสิ่งที่เราคิดว่าเป็นเทคนิคพรอมป์ต์ที่ดีกว่า หรือผลลัพธ์ที่ดีหรือแย่เป็นพิเศษ ก็อาจเป็นแค่เรื่องบังเอิญ หรือเป็นความต่างของพฤติกรรมตามเวอร์ชันและขนาดโมเดลก็ได้ ความต่างเล็กน้อยของอินพุตอาจทำให้ผลลัพธ์เอนเอียงอย่างมากได้ ในบริษัทเราเรียกบางอย่างพวกนี้ว่าคำวิเศษ คือแค่พูดถึงคำศัพท์เทคนิค การอ้างอิง หรือเทคนิคบางอย่าง ผลลัพธ์ก็ดีขึ้นมาก
    ตรงนี้มีทักษะอยู่ ถ้าเอาโมเดลเข้าไปอยู่ในโครงสร้างประเมินตนเองใน agent loop ที่ทำให้มันโกงหรือใช้ทางลัดได้ยาก และงานนั้นตรงกับโครงสร้างหรือโดเมนที่มันถูกฝึกมา มันจะทำได้ดีมาก แต่หาจุดที่เหมาะที่สุดยาก ถ้าจะให้ทิป ลองให้ Opus 4.8 แปลงโมเดล PyTorch เป็น ONNX หรือโมเดล quantized หรือให้ไปรันบนฮาร์ดแวร์อื่น มันจะเก่งเหมือนเปิดความสามารถพิเศษจริง ๆ ตรงกันข้าม ผมไม่สามารถทำให้มันเขียนและทดสอบการจัดรูป EBNF ของภาษาหรือฟอร์แมตทั่วไปให้ถูกต้องแบบไม่ใช้ทางลัดได้เลย
    สิ่งที่แย่ที่สุดคือความรู้นี้เปลี่ยนบ่อยเกินไป จนถ้าคุณไม่ใช่คนที่ฝึกโมเดลจริง ๆ ก็แทบไม่มีประโยชน์ที่จะขุดลึกลงไปนัก ผมอยากให้ความเสถียรของเอาต์พุตถูกเน้นมากขึ้นในการฝึก เพื่อให้คาดเดาได้มากขึ้น แม้จะทำได้ยากโดยไม่ทำให้ overfitting หรือวงจรสำรวจ-ใช้ประโยชน์พัง แต่ถ้ามันทำงานแบบ batch ได้เสถียรกว่านี้ ผมน่าจะยอมจ่ายเงินกับ LLM มากกว่านี้มาก
  • มันดูไม่ค่อยเหมือนการเล่นเครื่องดนตรี แต่ใกล้เคียงกับการหมุนสล็อตแมชชีนแล้วจินตนาการส่วนที่เหลือเอาเองมากกว่า
  • โดยรวมเห็นด้วยเกือบหมด แต่มีอยู่ข้อหนึ่งที่ต่างกัน บางครั้งการพูดหยาบกับ Claude ในจังหวะที่เหมาะสมได้ผลอย่างน่าทึ่ง โดยเฉพาะF-bombดูเหมือนจะช่วยดึง Claude ออกจากอาการตันได้ค่อนข้างดีในบางครั้ง
  • ผมให้ GLM 5.2 พอร์ตเกม C#/XNA เก่าไปเป็น HTML5 แล้วมันย้ายโค้ดไปแทบตรง ๆ โดยมีแค่ส่วน operator overloading ที่ JS ไม่มี แล้วก็เติมโค้ดเพิ่มเพื่อให้มันรันได้
    แต่พอขอแบบเดียวกันกับ Claude Sonnet 4.6 ผลลัพธ์กลับเหมือนเกมนั้นถูกเขียนเป็น JS มาตั้งแต่แรก แถมยังทำเป็นไฟล์ HTML เดียว ลบ asset ทั้งหมดทิ้ง แล้วสร้างกราฟิกกับเพลงขึ้นมาแบบไดนามิก รวมถึงทำฉากหลังใหม่ที่ดีกว่าให้ด้วย
    ที่ขอไปมีแค่ให้พอร์ตเกม ก็เลยแปลกใจ ผมค่อนข้างชอบทางเลือกนั้นนะ แต่ไม่รู้ว่าจะเปิดหรือปิดพฤติกรรมแบบนี้ยังไง บางครั้งคุณต้องการความคิดสร้างสรรค์ แต่บางครั้งก็อยากให้มันทำตามที่พูดจริง ๆ

• พออ่านบทความนี้กับคำชมต่าง ๆ แล้วก็ให้ความรู้สึกเหมือนจักรพรรดิเปลือย ประโยคนี้ก็เริ่มไม่สมเหตุสมผลแล้ว
  “These products use very low level Linux primitives like containers, Kubernetes, Firecracker microVMs, and networked protocols.”
  ในบรรดาสิ่งที่พอจะเรียกว่า “องค์ประกอบพื้นฐานระดับต่ำของ Linux” ได้ ก็คงพอฝืนบอกได้แค่พวก network protocol เท่านั้น และมันก็ดูเหมือนข้อความที่ AI สร้างขึ้นอย่างชัดเจน ถ้าเชื่อถือเนื้อหาได้ก็คงไม่เป็นไร แต่ปัญหาคือมันเชื่อถือไม่ได้

  • ทุกวันนี้ low level หมายถึงJavaScriptแทน TypeScript
  • ก็จริงที่ประโยคนั้นถูกบีบอัดมากเกินไป ผมเลยเขียนใหม่แล้ว แต่ความหมายเหมือนเดิม
    บทความนี้ไม่ได้สร้างโดย AI ส่วนโค้ดผมใช้ AI ช่วยสร้าง แต่ตัวบทความเขียนเอง อยากรู้ว่าไม่เข้าใจตรงไหน บทความนี้อธิบายประสบการณ์และเส้นทางของพวกเราเอง และถ้ามีข้ออ้างอิงเฉพาะเจาะจง เรายินดีแสดงหลักฐานให้ได้

• ฉันยังเชื่ออยู่เสมอว่าจุดแข็งของ AI จะออกมาได้ก็ต่อเมื่อนำไปใช้ บนเครื่องแบบปลอดภัยและเป็นส่วนตัว ไม่ใช่กลายเป็นบริการคลาวด์อีกตัวที่ต้องจ่ายเงินไม่รู้จบ และยิ่งแย่ลงเรื่อย ๆ เพื่อสนองความโลภของผู้ถือหุ้นบริษัท
  ไม่มีทางแน่นอนที่ ChatGPT หรือ Anthropic จะทำให้ฉันผูกข้อมูลสุขภาพของตัวเองไว้กับระบบของพวกเขา แต่ฉันก็ยังเชื่อในความสามารถของ AI ที่จะหาลวดลายของข้อมูลที่ฉันอาจมองข้ามไปได้อยู่ดี เพราะแบบนั้นจึงจำเป็นอย่างมากที่จะต้องมี ecosystem สำหรับใช้งานบนเครื่องโดยเฉพาะ ที่สามารถเปิดเผยข้อมูลให้ Qwen หรือ Gemma ประมวลผลได้อย่างปลอดภัยและเป็นส่วนตัว
  เรื่องสมาร์ตโฮมและผู้ช่วยส่วนตัวก็เหมือนกัน แนวทางแบบองค์กรที่บริษัท A เข้าถึงข้อมูลที่เก็บไว้กับบริษัท B แล้วให้บริษัท D·E ประมวลผล ก่อนจะขายต่อให้นักโฆษณาและ data broker โดยที่ฉันไม่มีทางดึงออกมาหรือดูได้จากฮาร์ดแวร์ในเครื่องของตัวเองนั้น ไม่ยั่งยืนสำหรับการใช้งานส่วนตัวแบบนี้ ข้อมูลของฉันควรถูกเป็นเจ้าของ ควบคุม และเปิดเผยภายใต้เงื่อนไขของฉันเอง และควรถูกใช้เพื่อทำให้ชีวิตฉันดีขึ้นก่อน ไม่ใช่ไปช่วยทำให้งบกำไรขาดทุนของคนอื่นดูดีขึ้น ฉันอยากให้เทคโนโลยีคืนเวลาให้ฉันและทำให้ผลลัพธ์ดีขึ้น และเพราะโดน Big Tech เล่นงานมามากพอแล้ว จึงปฏิเสธอย่างหนักแน่นต่อสมมติฐานที่ว่าโมเดลธุรกิจ AI-as-a-Service มีความสูงส่งหรือเป็นประโยชน์ต่อสาธารณะ
  ความสามารถนั้นมีอยู่แล้ว และฉันคิดว่าคนที่กำลังสร้างเครื่องมือบนเครื่องเพื่อสนับสนุนและปลดล็อกศักยภาพของโมเดลแบบ local กำลังเดินมาถูกทาง ชอบดูสิ่งที่พวกเขาสร้าง

  • แก่นสำคัญของโมเดล “local” โดยมากคือเป็น open weight และบางครั้งก็เป็นโอเพนซอร์สด้วย เพราะงั้นจึงใช้บนเครื่องเองได้ แต่ก็ให้ผู้ให้บริการอิสระโฮสต์ได้เช่นกัน
    ถ้าใช้โมเดลอย่าง Qwen หรือ DeepSeek ก็สามารถย้ายไปมาระหว่างผู้ให้บริการอิสระได้ โดยไม่ถูกผูกกับบริษัทใดบริษัทหนึ่ง และอาจได้การคุ้มครองความเป็นส่วนตัวที่ดีกว่าด้วย แบบนั้นต่อให้เป็นอุปกรณ์ที่รันเองไม่ได้ ตราบใดที่มีการเชื่อมต่ออินเทอร์เน็ตก็ยังใช้โมเดลได้
    จุดแข็งของ AI อยู่ที่ โมเดลโอเพนซอร์ส เราควรใช้โมเดลที่หลีกเลี่ยงการผูกติดกับผู้ให้บริการ และเปิดให้ใช้งานได้ทั้งแบบรันบนเครื่องเองและแบบโฮสต์โดยผู้ให้บริการอิสระ

• เป็นบทความที่ดี แค่รู้สึกว่ามันประเมิน ศักยภาพในการพัฒนา ต่ำไปหน่อย
  ผู้เขียนเองก็ยอมรับว่าการเอาโมเดล local เมื่อปีที่แล้วมาเทียบกับตอนนี้ไม่มีความหมายมากนัก ที่จริงหลายคนมองว่า Opus 4.5 เมื่อพฤศจิกายนปีก่อน หรือก็คือเมื่อ 8 เดือนก่อน เป็นจุดแรกที่ agent coding ใช้งานได้อย่างแพร่หลายในบรรดา frontier hosted model
  แล้วทำไมเราต้องรีบตรึงนิยามว่า ณ ตอนนี้โมเดล local ทำอะไรได้หรือไม่ได้กันด้วย? ไม่ว่าอะไรก็ตามในตอนนี้ อีก 1 ปีข้างหน้าก็น่าจะต่างออกไป การคิดว่าในอนาคตมันจะทำงานระยะยาวได้แม้บนฮาร์ดแวร์ระดับผู้บริโภคหรือระดับมืออาชีพอาจเป็นความมองโลกสวยแบบไร้เดียงสา แต่จนถึงตอนนี้พวกคนมองโลกสวยแบบนั้นกลับเป็นฝ่ายชนะ

  • เห็นด้วย ถ้า Opus 4.5 เมื่อ 8 เดือนก่อนดีพอสำหรับ agent coding แล้ว โมเดล open weight ตามหลังอยู่แค่ไหนกัน? มากกว่า 8 เดือนหรือเปล่า? มากกว่านั้นอีกเท่าไร? อีกไม่กี่เดือนจะไปถึงระดับ Opus 4.5 ไหม อีก 1 ปี หรือว่าจะไม่มีวันไปถึงเลย?
  • สิ่งที่หายไปชิ้นใหญ่คือการเทียบ harness ซึ่งมีผลมากมาก ฉันใช้ forge อยู่ และถึงจะคำนึงถึงข้อจำกัดทั้งหมดของโมเดล local แล้ว สิ่งที่มันทำได้ก็ยังน่าประทับใจ
  • ในเมื่อผู้เขียนกำลังพูดถึงโมเดลตัวหนึ่ง ก็คิดว่าไม่จำเป็นต้องสนใจว่าโมเดลนั้นหรือโมเดล local โดยรวมจะดีขึ้นอย่างไรเมื่อเวลาผ่านไป
    มันคล้ายกับการซื้อรถ คุณก็แค่ขับรถคันนั้นและคุ้นเคยกับลักษณะของมัน ไม่ได้คิดว่ารถคันนั้นหรือรถคล้ายกันจะพัฒนาต่อไปอย่างไรในอนาคต มันคือเครื่องมือของฉัน และฉันอยากใช้มันให้คุ้มที่สุด
    แน่นอนว่าต้นทุนทางเทคนิคในการเปลี่ยนโมเดล local นั้นต่ำมาก แต่การดึงประสิทธิภาพสูงสุดออกมาจากโมเดลหนึ่งต้องใช้เวลาพอสมควร และความพยายามนั้นอาจใช้กับเวอร์ชันใหม่ไม่ได้ผล
  • เห็นด้วย 100% ว่า Claude 4.5 คือ จุดเปลี่ยนของ agent coding โมเดลนั้นทำให้มุมมองของฉันเปลี่ยนไปอย่างสิ้นเชิง

• บทความน่าสนใจดี แต่ส่วนตัวคิดว่าผู้เขียนน่าจะทำอยู่สองอย่างให้ดีกว่านี้
  อย่างแรก ควรใช้ vLLM แทน llama.cpp บนฮาร์ดแวร์ NVIDIA ความต่างของ vLLM ในเรื่องโหลดหลายผู้ใช้และการแคชนั้นใหญ่มาก ตอนที่บ่นเรื่องมีผู้ใช้เกินหนึ่งคนหรือปัญหาแคชหาย ก็รู้สึกว่า “ก็แน่อยู่แล้ว”
  อย่างที่สอง งบที่ลงกับการ์ดใบเดียวน่าจะเอาไปลงกับ SPARK ได้คุ้มกว่ามาก ใช้คลัสเตอร์ 2 x GX10 ได้ โดยรวมแล้วแม้แต่ตอนนี้ก็ยังถูกกว่าครึ่งหนึ่งของที่ผู้เขียนจ่าย และกำลังรัน vLLM กับ Deepseek v4 Flash อยู่ ถ้าเทียบกับ Qwen แล้วต่างกันมาก ฉันยังไม่เคยเห็นมันหลุดเข้า loop เลย และจากที่ลองมาทั้งหมดมันเป็นโมเดลที่ให้ความรู้สึกเหมือน Sonnet ที่สุด ดูเหมือน antirez จะเห็นด้วย เลยทำ ds4 fork ขึ้นมา
  วิธีตั้งค่าบน 2 GX10 อยู่ที่นี่: https://forums.developer.nvidia.com/t/deepseek-v4-flash-offi...
  ประสิทธิภาพคือ prefill 2K tokens/s ซึ่งมีประโยชน์มากเวลาใส่ซอร์สโค้ดจำนวนมากลงใน context window ขนาดใหญ่ และตอนเขียนโค้ดด้วย pi.dev harness การ generate อยู่ที่ราว 50~60 tokens/s เงินที่ผู้เขียนจ่ายไปซื้อ GX10 ได้ 4 ตัว และ vLLM ก็สเกลในการทำ tensor parallel ได้เกือบเชิงเส้น จึงทำให้ตัวเลขทั้งสองอย่างเพิ่มเป็นสองเท่าได้

  • ฉันก็ลองรัน vLLM บน 3090 เหมือนกัน สำหรับรูปแบบการใช้งานแบบคนเดียวถึงไม่กี่คนอย่างพวกเรา การ generate ช้าลงราว 3 tokens/s, ความยืดหยุ่นด้าน quantization ก็น้อยกว่า และตอนเริ่มต้นก็ช้ากว่ามาก ใช้เวลาหลายนาทีจริง ๆ ไม่ใช่ไม่กี่วินาทีระดับเลขหลักเดียว
    ไว้ทีหลังอาจลองเพิ่มอีกก็ได้ แต่ก็ไม่ได้มีเวลามานั่งปรับแต่งได้ไม่จำกัด และนี่ก็เป็นการแชร์เส้นทางกับการตัดสินใจที่ผ่านมาจนถึงตอนนี้
    ถ้าเป็นงานเสิร์ฟแบบ concurrent batch แล้ว vLLM คือคำตอบที่ถูกต้อง และที่ barrkel พูดไว้ข้างล่างก็ตรงมาก แต่สำหรับรูปแบบการใช้งานของเรา llama.cpp ยังดีกว่า
    เส้นทาง Spark/GX10 เป็นการเดิมพันคนละแบบจริง ๆ และก็ขอบคุณที่แชร์ตัวเลขมาให้ ไม่กี่เดือนก่อนบรรยากาศโดยรวมยังมองว่า GX10 เอาไว้ fine-tune อย่างเดียว และตัวเลขประสิทธิภาพก็ดูน่าผิดหวังมาก
    แล้วการ์ดใบนั้นก็ไม่ได้ซื้อมาเพื่อแทนการสมัคร Claude Max แต่อย่างใด จริง ๆ แล้วกับงานที่ซื้อมาใช้นั้นมันทำได้ 140~200 tokens/s และนั่นแหละคือสิ่งสำคัญ

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

  • ทุกวันนี้ทุกอย่างคือโฆษณาไปหมด บทความนี้ไม่ถึงกับไร้ประโยชน์ แต่ถ้าดูจากปริมาณข้อมูลที่ให้มา แค่ สองย่อหน้า ก็น่าจะพอแล้ว

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

  • เชื่อว่าโมเดลแบบรันในเครื่องคือ ส่วนขยายที่จำเป็นของคอมพิวเตอร์ส่วนบุคคล คิดว่าคอมพิวเตอร์ส่วนบุคคลยุคแรกก็คงเคยโดนคำวิจารณ์คล้ายกัน
  • สิ่งที่อยากเห็นคือโมเดลแบบรันในเครื่องที่จัดการงานประจำวันได้ราว 80% เช่น “X Handler เชื่อมกับ Y storage อย่างไร?”, “คอมมิตฟีเจอร์นั้นให้ที แต่ตัดส่วนที่เกี่ยวกับการจ่ายเงินออก”
    การเรียกใช้เครื่องมือต้องเชื่อถือได้ 99% และที่สำคัญที่สุดคือต้องพูดได้ว่า “งานนี้เกินความสามารถของฉัน” แล้วส่งต่อไปยัง โมเดลออนไลน์ประสิทธิภาพสูง ที่อยู่ในดาต้าเซ็นเตอร์ขนาดใหญ่สักแห่ง
    แบบนั้นงานง่ายทั้งหมดจะถูกจัดการบนอุปกรณ์ พร้อมทั้งรวบรวมข้อมูลและทำความเข้าใจบริบทของปัญหา แล้วหลังจากงานง่ายเสร็จ โมเดลที่ฉลาดกว่าจะเข้ามาแก้ปัญหาต่อ
    การที่งานอย่าง /commit ซึ่งโมเดลแบบรันในเครื่องทำได้ 100% ยังไปเรียกโมเดลออนไลน์ มันให้ความรู้สึกงี่เง่ามาก แต่ก็เป็นปัญหาที่ส่วนใหญ่เกิดจากฮาร์เนส เลยพอแก้ได้มากพอสมควร
  • โมเดลแบบรันในเครื่องยอดเยี่ยมมากสำหรับการใช้งานหลายแบบ และสำหรับคนส่วนใหญ่ก็ไม่จำเป็นต้องใช้ โมเดลระดับล้ำหน้าที่สุด ตอนรันโมเดล Qwen บน 4070 12GB ตัวเล็ก ๆ เป็นเอเจนต์อีเมลส่วนตัว สิ่งสำคัญที่สุดคือความเป็นส่วนตัว
    มันทำได้ดีมาก และกับงานโค้ด ถ้ารู้วิธีใช้แทนที่จะโยนแผนใหญ่ทั้งก้อนเข้าไป มันก็ยอดเยี่ยมเช่นกัน
  • หลังมีการเปลี่ยนแปลง MTP ตอนนี้ได้ 40~50 โทเคน/วินาที จาก qwen3.6:27b บน 4090 ที่จำกัดไว้ที่ 350W
    คิดแบบเพดานบนก็อยู่ที่ราว 8.75J/โทเคน
    ไม่รู้ว่าเทียบกับอย่างอื่นเป็นอย่างไร แต่คาดว่า 5090 น่าจะถูกกว่านิดหน่อยเพราะน่าจะเร็วกว่าเมื่อจำกัดพลังงานเท่ากัน
  • นั่นคือฮาร์ดแวร์ปัจจุบัน แล้วฮาร์ดแวร์อนาคตล่ะ? ฮาร์ดแวร์ที่ปรับแต่งเพื่อการอนุมาน ล่ะ? หรือฮาร์ดแวร์ที่ออกแบบให้เหมาะกับการรันโมเดลเฉพาะตัวล่ะ?

• น่าสนใจที่ vLLM ถูกมองว่าแย่กว่า llama.cpp
  จากประสบการณ์ของฉัน vLLM เร็วกว่า llama.cpp ค่อนข้างมาก และเหนือกว่าชัดเจนโดยเฉพาะใน การประมวลผลแบบแบตช์ภายใต้โหลดพร้อมกัน ข้อเสียคือความยืดหยุ่นในการปรับแต่งต่ำกว่ามาก ตัวเลือกในการรันน้ำหนักแบบ quantized มีน้อยมาก และเพราะมันพยายามออปติไมซ์ computation graph เวลาสตาร์ตก็นานกว่ามาก ดังนั้นถ้าเป็นผู้ใช้คนเดียวที่อยากลองโมเดลซึ่งใหญ่เกินเครื่องนิดหน่อย vLLM อาจทำให้หงุดหงิดได้

  • จะพูดแบบนี้ก็ได้ว่า vLLM ไม่ใช่ Llama.cpp ที่แย่กว่า แต่เป็น เครื่องมืออีกแบบหนึ่ง
  • vLLM ยอดเยี่ยมสำหรับ continuous batching และการเสิร์ฟโมเดลในโปรดักชัน แต่ในกลุ่ม prosumer มันคือของคนละแบบที่ใช้งานได้รอบด้านน้อยกว่ามาก
    คำว่า “มองว่าแย่กว่า” อาจแรงไปหน่อย แต่ถ้าจะอธิบายให้ละเอียดขึ้น บนเครื่อง 2x 3090 ใช้เวลาโหลดเกิน 4 นาที และคำขอเดี่ยวก็ ช้ากว่า 3 โทเคน/วินาที
    ที่แย่ที่สุดคือแม้จะลงแรงตั้งค่าและจูนทั้งหมดแล้ว มันก็ยังติดลูปอยู่ดี ฉันหวังว่าคำแนะนำที่ได้ยินบ่อย ๆ ว่า “ก็ใช้ vLLM สิ” จะเป็นวิธีแก้สารพัดปัญหา
    สิ่งหนึ่งที่ต้องระวังคืออย่าเริ่มกด llama.cpp ลงเหมือนที่คนเคยทำกับ Ollama llama.cpp เป็นเครื่องมือที่เก่งมาก และเหมาะกับการใช้งานที่เราจะใช้การ์ดพวกนี้จริง ๆ มากกว่า
    ถ้าจะให้ทีมใหญ่แทนที่การสมัคร Claude ได้ vLLM อาจเป็นทางเลือกเดียว แต่ถ้าจะรันอะไรอย่าง GLM 5.2 ก็คงต้องเพิ่มการ์ด RTX 6000 อีกประมาณ 5 ใบ
  • เท่าที่จำได้ ฉันทามติทั่วไปคือถ้าเป็นผู้ใช้คนเดียวให้ใช้ llama.cpp แต่ถ้าเป็นหลายผู้ใช้หรือระดับองค์กรให้ใช้ vLLM คล้ายกันแต่จุดประสงค์ต่างกัน
  • ค่อนข้างงงที่ยังใช้ llama.cpp ต่อ ทั้งที่บ่นว่าเมื่อมีผู้ใช้หลายคนยิงโมเดลพร้อมกันแล้ว cache prefix พัง แต่ก็ยังไม่ย้ายไป vLLM

• มีการบอกว่า “โมเดลร้อนเกินไปจนเลยเป้าหมายและวนลูป” แต่ข้างล่างกลับบอกว่าตั้ง vLLM เป็นการทดลองล่าสุดแล้ว แต่ถึงจะเปิด NVLink และ tensor parallelism ก็ยังสร้างผลลัพธ์ช้ากว่า llama.cpp อยู่ 3 โทเคน/วินาที
  ในทุกการทดสอบของฉัน การรัน vLLM คุ้มค่าเสมอ มันเป็นปัจจัยเดี่ยวที่ช่วยมากที่สุดกับปัญหาลูป ปัญหาที่เอเจนต์เริ่มเพี้ยน ปัญหาหลุดโฟกัสจากงาน และปัญหาที่คอนเท็กซ์ยาว ๆ แทบใช้งานจริงไม่ได้
  ใน vLLM ถ้าใช้ โมเดล FP8 และแคชแบบไม่ quantize ประสบการณ์โดยรวมจะดีขึ้นไปอีกขั้นเมื่อเทียบกับสแตกอื่น ๆ หลังจากนั้นก็เลิกหมกมุ่นกับการจูนค่า แล้วไปโฟกัสกับการเอาโมเดลไปทำอย่างอื่นได้

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

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