ทำทุกอย่างในเครื่อง: การสร้าง AI workspace แบบออฟไลน์

• วิธีการสร้าง AI workspace โดยใช้ LLM ในเครื่องและ สภาพแวดล้อมแซนดบ็อกซ์โค้ด เพื่อรัน AI ได้โดยไม่ต้องพึ่งพาคลาวด์
• รัน LLM ในเครื่องด้วย Ollama และใช้ Apple Container เพื่อรันโค้ดใน VM ที่แยกโดดเดี่ยว พร้อมใช้ Playwright เพื่อทำการทำงานอัตโนมัติผ่าน headless browser และเข้าถึงอินเทอร์เน็ตได้
• UI ใช้พื้นฐานจาก assistant-ui โดยเพิ่ม dropdown เลือกโมเดลและการรวมกับ ai-sdk และสร้างสภาพแวดล้อมรันโค้ดที่ปลอดภัยผ่าน MCP (Model Context Protocol)
• ภายใน VM Coderunner ที่เชื่อมต่อผ่าน MCP ทำการรัน Jupyter server และ browser ทำให้สามารถสร้างกราฟ ตัดต่อภาพ/วิดีโอ ติดตั้งเครื่องมือ GitHub และค้นหาข้อมูลบนเว็บได้ในโหมดที่ปกป้องความเป็นส่วนตัว
• ขณะนี้รองรับเฉพาะ Apple Silicon และยังมีภารกิจต่อไปคือการพัฒนา UI, การหลีกเลี่ยงการตรวจจับ browser และการเสริมความสามารถในการจัดการเครื่องมือ

---

ข้อกำหนดและภูมิหลัง

• เป้าหมาย: รันทุกอย่างบนเครื่อง โดยไม่ใช้การรันโค้ดบนคลาวด์หรือเซิร์ฟเวอร์ระยะไกล
• LLM chat app ที่มีอยู่ (เช่น ChatGPT, Claude) มักมีทั้งการแชตที่ใช้ LLM แบบคลาวด์, การรันโค้ดแบบคลาวด์/ในเครื่อง และการเข้าถึงอินเทอร์เน็ต
• การขยายตัวของการใช้ LLM โอเพ่นซอร์ส ทำให้เกิดคำถามว่าสามารถทำสิ่งเหล่านี้ทั้งหมดแบบท้องถิ่นได้จริงหรือไม่
• LLM ในเครื่องอย่างเดียวไม่เพียงพอ จึงต้องมีการรันโค้ดในสภาพแวดล้อมที่แยกออกจากเครื่องหลัก และยังต้องการการเข้าถึงเนื้อหาผ่าน browser ด้วย

แนวคิดการออกแบบ

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

เทคโนโลยีที่ใช้

• LLM: Ollama (รองรับโมเดลท้องถิ่นและโมเดลภายนอกบางตัว)
• UI: assistant-ui + ai-sdk (เพิ่มความสามารถเลือกระบบโมเดล)
• VM runtime: Apple container (ให้สภาพแวดล้อม VM ที่แยกตัว)
• การ orchestrate: instavm/coderunner (เชื่อมต่อ Jupyter server ผ่าน MCP)
• อัตโนมัติของ browser: Playwright (เปิดเป็นเครื่องมือผ่าน MCP)

การลองสร้างแอป Mac และการเปลี่ยนแนวทาง

• ลองสร้างแอป Mac แบบเนทีฟด้วย a0.dev แต่พบปัญหาหลายอย่างเพราะเป็นแพลตฟอร์มที่เน้น iOS
• เคยลองห่อด้วย Electron + NextJS แต่ยกเลิกเนื่องจากความซับซ้อน
• สุดท้ายเปลี่ยนไปใช้ assistant-ui แบบเว็บในเครื่องเป็นทางเลือกหลัก

ปรับแต่ง Assistant-UI

• คาดหวังว่าจะรองรับฟีเจอร์หลากหลาย เช่น dropdown เลือกโมเดลได้ แต่พบว่ามีข้อจำกัด
• หลังจากอิงตัวอย่างแล้วได้พัฒนาฟังก์ชันเลือกโมเดลหลายตัวเองผ่าน ai-sdk
• ในช่วงแรกยังรองรับโมเดลคลาวด์ เช่น OpenAI/Anthropic และค่อยๆ ชี้นำให้ย้ายไปใช้ โหมดท้องถิ่น

ปัญหาเรื่อง Tool-calling และการรองรับโมเดล

• ต้องการโมเดลที่รองรับ Tool-calling แต่บางโมเดลเช่น Ollama ยังไม่รองรับจริง
• แม้เอกสารทางการจะระบุรองรับเครื่องมือ แต่ในทางปฏิบัติมักมีการรองรับไม่ครบถ้วน
• เนื่องจาก ecosystem โอเพ่นซอร์สเปลี่ยนแปลงเร็ว สถานะการรองรับเครื่องมือและราคา token จึงผันผวนสูง

การรันโค้ดแบบแยกด้วย Container

• โดยใช้ Container ของ Apple ซึ่งให้สภาพแวดล้อม VM ที่แยกสนิทต่อแต่ละ container มากกว่า Docker จึงปลอดภัยมากขึ้นสำหรับการรันโค้ดที่ AI สร้าง
• วาง Jupyter server ลงในสภาพแวดล้อม VM และเปิดเผยผ่าน Model Context Protocol (MCP) เพื่อให้อุปกรณ์ภายนอกหลากหลาย (เช่น Claude Desktop, Gemini CLI) ใช้งานได้ทันที
• โค้ด MCP server ของ coderunner ถูกเปิดเผยสู่สาธารณะ และมีตัวอย่างการเชื่อมต่อกับเครื่องมือภายนอก
• เครื่องมือ Apple Container ยังไม่เสถียร จึงต้องทำการ rebuild/ลบภาพใหม่ซ้ำๆ เมื่อเกิดปัญหาการ build หรือ image
• การทดสอบใช้งานจริง เช่น การตัดต่อวิดีโอ ยืนยันว่าชุด UI + LLM + coderunner ทำงานได้ปกติ

การรวม headless browser

• วาง Playwright headless browser ไว้ใน container และเปิดให้เป็น MCP tool
• คาดหวังว่าได้แก่การสำรวจเครื่องมือ/ข้อมูลใหม่ การค้นหาวิธีใช้ Github และการทำรีเสิร์ชแบบอัตโนมัติ
• สร้าง workflow หลักสำเร็จ: การผสาน LLM ท้องถิ่น + รันโค้ดใน sandbox + headless browser

ตัวอย่างงานที่ทำได้

• การรีเสิร์ชและสรุป หัวข้อเฉพาะ
• สร้างและเรนเดอร์ กราฟจาก CSV ด้วยคำสั่งภาษาธรรมชาติ
• ตัดต่อวิดีโอด้วย ffmpeg (เช่น ตัดช่วง)
• รีไซส์ ครอป และแปลงฟอร์แมตรูปภาพ
• ติดตั้งเครื่องมือของ Github ภายใน container
• เว็บสแป่ม/เก็บข้อมูลหน้าเว็บและสรุปผ่าน headless browser เป็นต้น

การ mount โวลุ่มไฟล์และการแยกตัว

• แมปโฟลเดอร์ของโฮสต์ ~/.coderunner/assets ไปยัง /app/uploads ใน container เพื่อเก็บไฟล์ในพื้นที่แชร์ที่ปลอดภัย
• โค้ดที่รันแล้วไม่สามารถเข้าถึงระบบโฮสต์โดยตรง เพื่อยกระดับความปลอดภัย

ข้อจำกัดและงานต่อไป

• ทำงานได้เฉพาะสภาพแวดล้อม Apple Silicon ส่วน macOS 26 เป็นตัวเลือกเสริม
• ต้องปรับปรุง UI สำหรับการจัดการเครื่องมือ, การสตรีมผลลัพธ์ และอื่นๆ เพิ่มเติม
• headless browser ยังมีปัญหาถูกบล็อกในบางไซต์เนื่องจากการตรวจจับว่าเป็น bot

สรุป

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

• โค้ดโอเพ่นซอร์ส coderunner-ui พร้อมใช้งานบน GitHub และยินดีรับ feedback และการร่วมพัฒนา

ทรัพยากรที่เกี่ยวข้อง

• assistant-ui
• instavm/coderunner
• Apple/container
• instavm/coderunner-ui

[wedding]

เห็นด้วยกับความเห็นของ HN ที่ว่า “แทบจะเป็นงานอดิเรกที่น่าจะสนุกมากกว่า” ครับ
แต่เมื่อปรับแต่งไปมาอย่างไรก็ไม่สามารถเทียบความสะดวกและความเร็วระดับการใช้งานเชิงพาณิชย์ได้...

[GN⁺]

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

• ผมชอบแนวอุดมคตินิยมแบบนี้เสมอ แต่สุดท้ายเมื่อคิดถึงประสิทธิภาพโมเดลที่เข้าถึงได้จริงและต้นทุนการรันแบบ on-demand ในคลาวด์แล้ว มันดูเหมือนเป็นเพียงงานอดิเรกที่น่าสนุกมากกว่ายุทธศาสตร์เชิงปฏิบัติจริง ฮาร์ดแวร์พัฒนาเร็วมาก ทำให้แม้จะซื้ออุปกรณ์มือสองก็มีมูลค่าเสื่อมเร็วเช่นกัน จึงรู้สึกว่าการลงทุนในฮาร์ดแวร์จริงค่อนข้างไม่สมเหตุสมผล นอกจากนี้ประสิทธิภาพของ weights ที่รันใน local ก็ดูเหมือนตกลงมาก จึงยังไม่คุ้มที่จะทำตอนนี้ ผมเชื่อว่าสักวันหนึ่งสถานการณ์จะเปลี่ยน และหวังว่าพอมีน้ำหนักที่ดีถูกปล่อยเผยแพร่แล้วค่อยลงทุนกับ local inference stack ได้ จนกว่าจะถึงวันนั้น มันก็เหมือนการจ่ายเงินกับสินทรัพย์แพงที่มีการเสื่อมค่าสะสมเร็วมาก

• ผมชอบติดตาม local LLM ecosystem อยู่มาก และสนุกที่ได้เห็นว่าคนอื่นกำลังทำอะไรบ้าง แต่ทุกครั้งที่ผมรัน local LLM ด้วย RAM เยอะบน MacBook Pro ผมยิ่งรู้สึกชัดว่ามีช่องว่างกับ frontier model (SaaS LLM ตัวล่าสุด) อยู่มาก จ่ายราว $20 ต่อเดือน โดยจ่ายตาม token ก็ใช้โมเดลประสิทธิภาพสูงหลายตัวได้ แต่ทั้งความเร็วและคุณภาพ local model ยังต่างกันมาก หากดูจากกราฟ benchmark ช่องว่างนี้ไม่ชัดเจนมากนัก แต่ความรู้สึกจริงคือโมเดล frontier ยังดีกว่าอย่างเห็นได้ชัด โมเดลของ OpenAI, Anthropic เองก็บางครั้งช้าและผิดพลาดสูง แต่เมื่อไปที่ local ยิ่งชัดเจนกว่า สำหรับงานอดิเรกหรือการทดลองที่เน้นความเป็นส่วนตัว มันอาจเหมาะสม แต่สำหรับผมรอให้ได้ฮาร์ดแวร์จริงจังอย่าง RAM 128GB ใน Mac รุ่นหน้าอาจจะดีกว่า

• ผมคิดว่าโมเดลที่อยู่หลัง API เมื่อเริ่มทำเงินจากผลลัพธ์จริง ๆ แล้ว คุณภาพของ output จะค่อย ๆ ต่ำลง ผมมองว่านี่เป็นแค่ปัญหาเรื่องเวลา

• ผมสงสัยกับข้ออ้างเรื่อง “ฮาร์ดแวร์เปลี่ยนเร็วมาก ทำให้อุปกรณ์มือสองหรืออะไรก็ตามเสื่อมค่าทันที” ในบางกรณีไม่จำเป็นต้องใช้สเปกสูงสุดก็ยังสามารถรันโมเดลต่อได้ สุดท้ายแล้วนี่เป็นการถกเถียงแบบดั้งเดิมเรื่อง opex (ค่าใช้จ่ายดำเนินงาน) vs capex (การลงทุนสินทรัพย์ถาวร) ซึ่งทางการเงินแล้ว คลาวด์จะแพง/คุ้มก็ต่อเมื่ออยู่ในสถานการณ์ที่ค่อนข้างเฉพาะมาก (ต้องติดตั้งโครงสร้างพื้นฐานอย่างรวดเร็วในขณะที่ไม่สามารถคาดการณ์ demand ได้) กับ LLM มันแทบไม่เข้ากัน OP บอกว่าใช้เงินราว $600 ซึ่งเมื่อเทียบกับ EC2 ก็ประมาณค่าใช้จ่าย 3 เดือน ด้วยมุมนี้ ผมอยากดูว่ามีตัวเลขอะไรมาสนับสนุนข้อโต้แย้งของ OP บ้าง

• ผมเองก็หวังว่ามันจะเปลี่ยนในอนาคต ผมเริ่มใช้ Claude Code ในงานมากขึ้นเรื่อย ๆ และไม่อยากให้การเขียนโค้ดประจำวันต้องพึ่งพาบริษัทตลอดเวลา เรื่อง limit ของแพ็กเกจ, ค่า API, ความกังวลเรื่องต้องจ่าย $100-200 ทุกเดือน และความเสี่ยงที่ข้อมูลทั้งหมดของผมจะถูกเก็บ/สอดแนมโดยบริษัท AI ทำให้ผมหงุดหงิด ใน smart home ผมใช้เฉพาะอุปกรณ์ที่ควบคุมได้ใน local เท่านั้น และเมื่อจำเป็นต้องเข้าถึงจากภายนอก ผมตั้งค่า software เองรันบนเซิร์ฟเวอร์ตัวเอง วันไหนบริษัทปรับนโยบายแล้วหยุดบริการ ขึ้นราคา หรือใช้ข้อมูลผม ผมไม่อยากถูกผูกติดกับสิ่งเหล่านี้ แต่ตอนนี้ผมยังไม่มีแรงผลักดัน เรื่องต้นทุน ความรู้ และภาระการดูแลพอที่จะรัน LLM บนฮาร์ดแวร์ตัวเองหรือ VPS ทันที ผมพอใจกับการจ่าย $20 ต่อเดือนให้ Anthropic และตอนนี้ open models ที่เปิดเผยอยู่ยังห่างไกลจาก frontier SaaS อย่างมาก แม้ยังไงก็หวังว่าสักวันมันจะเปลี่ยน

• ผมเชื่อว่ามันจะไม่เปลี่ยนเลย แม้สองปีข้างหน้าจะมีตัวเลือก local ระดับ GPT-5 ก็ตาม ในช่วงนั้นฝั่งคลาวด์ก็คงมีตัวเลือกที่ดีกว่าเกิดขึ้นใหม่อีก ทำให้คำถามเดิม ๆ ก็ยังวนกลับมา

• งานชิ้นนี้ที่โฟกัสที่ชั้นรันแบบ sandbox local ถือเป็นชิ้นสำคัญหนึ่งในการทำให้ private AI workspace เป็นจริง เครื่องมือ coderunner ดูมีประโยชน์มาก อย่างไรก็ดีอีกปัญญ์หนึ่งคือชั้น “knowledge layer” ที่ทำให้ AI เข้าใจข้อมูลส่วนตัวเช่นอีเมล โน้ต และไฟล์ของผม หากใช้ RAG กับอีเมลหลายปี ปริมาณ vector database ที่ต้องเก็บอาจทะลุ 50GB ได้ง่าย ๆ (เพื่อข้อมูลเพิ่มเติม ผมเป็นหนึ่งในทีมที่ Berkeley ที่แก้ปัญหานี้) เราสร้าง vector index ชื่อ LEANN โดยไม่เก็บ embeddings เอง ทำให้ลดการใช้ที่เก็บข้อมูลลงได้ราว 97% เพราะฉะนั้นการ index ชีวิตดิจิทัลทั้งก้อนแบบ local ก็กลายเป็นไปได้จริง การผสม ultra-light knowledge index แบบนี้เข้ากับ local execution engine คือทางไปสู่ 'local Jarvis' จริง ๆ โค้ด: https://github.com/yichuan-w/LEANN บทความ: https://arxiv.org/abs/2405.08051

  • มองตามสภาพปี 2025 การต้องการ vector database ราว 50GB สำหรับอีเมลหลายปีถือว่าเป็นระดับความต้องการที่ค่อนข้างไม่สูง

  • ขอบคุณที่ให้ข้อมูล LEANN ผมสนใจมากกับการเอา RAG ไปใช้เป็น knowledge layer ของ LLM agent, pipeline และ execution engine ผมอยากรู้ว่าการเชื่อม LLM กับ codebase ขนาดใหญ่เป็นไปได้แค่ไหน และการที่มี RAG solution ที่เชื่อมกับ Claude Code อยู่แล้วทำให้ความยากในการทดลองลดลง จึงค่อนข้างหวัง อยากถามว่ามีใครเคยใช้ RAG ผสมกับ LLM ทำงานกับ codebase ขนาดใหญ่จริง ๆ บ้างไหม สำหรับโมเดลฝั่ง front-end (LM) ผมตั้งใจจะเริ่มด้วยการใช้คลาวด์ก่อน แล้วค่อยลองทำเอง ดูเพิ่มเติม: https://github.com/yichuan-w/LEANN/blob/main/packages/leann-mcp/README.md

  • ผมแทบไม่รู้เรื่อง embedding หรือโครงสร้างจัดเก็บเวกเตอร์เลย อยากทราบว่ามีโปรเจกต์ไหนในด้าน cloud embedding ที่ใช้แนวคิด “pruned graph” แบบนี้บ้าง

  • การที่ index ใหญ่กว่าข้อมูลต้นฉบับรู้สึกแปลก ๆ โดยปกติ index น่าจะเป็นรูปแบบที่ optimize เพื่อเข้าถึงได้เร็วกว่า แต่ตอนนี้ดูใหญ่เกินไปจนรู้สึกไม่เข้าท่า

• หนึ่งในเหตุผลที่แม้จะใช้ “LLM ระดับโลก” แล้วยังไม่ลื่นอย่างที่คาดคือ โมเดลพวกนี้มักข้ามขั้นตอน ไม่สนใจความเฉพาะของแต่ละแพลตฟอร์ม และบางครั้งยังสร้าง hallucination ที่ทำให้ปัญหาซับซ้อนขึ้น นี่สะท้อนว่าข้อมูลการเรียนรู้เกี่ยวกับการพัฒนาแอป native app ค่อนข้างหายาก มีบทความยาว ๆ ในบล็อกหรือ Medium เกี่ยวกับการออกแบบแอป native น้อยมาก และโปรเจกต์ desktop app แบบ open source ก็มีจำนวนน้อยมากเมื่อเทียบกับ mobile/web ยุค 1990 Microsoft เคยจ้างนักเขียนมืออาชีพให้ตีพิมพ์ตำรา coding สำหรับ Windows ที่ยอดเยี่ยมมาก เช่น Charles Petzold แต่ดูเหมือนอุตสาหกรรมเฉพาะทางนั้นแทบหายไปแล้ว ผมคิดว่าช่องโหว่ในข้อมูลฝึกสอนจะยิ่งกว้างขึ้นเรื่อย ๆ โดยรวมคล้ายกับเทรนด์ของซอฟต์แวร์วิศวกรรมโดยรวม เพราะคนที่อยากทำ desktop app native มีจำนวนน้อย และในแง่เส้นทางอาชีพก็เหมือนเป็น “dead-end” ในยุค 1990 นักพัฒนา Windows desktop app สามารถยืนได้แบบชนชั้นกลาง แต่ทางเข้าค่อนข้างสูงมาก (C/C++ ยุ่งยาก และการเรียน Windows API ก็ยากมาก และ MS ใส่เงินมหาศาลในการอบรม) ทุกอย่างเปลี่ยนไปมากแล้ว ตอนนี้ความต้องการทำ desktop app นั้นต่ำมาก ยกเว้น OS vendor (Microsoft, Apple) และบริษัทซอฟต์แวร์ legacy บางราย เช่น Adobe, Autodesk

  • ยกเว้นกรณีคำนวณประสิทธิภาพสูง (HPC) เพราะ browser กำลังทำหน้าที่เป็น VM แบบครอบคลุมและยืดหยุ่นที่สุดในทางปฏิบัติ จึงไม่จำเป็นต้องมี desktop app แยกต่างหาก

• ผมลองใช้งานแอป Ollama บน macOS แบบทดสอบแล้ว พบว่าทันทีที่เริ่มต้น มันพยายามเชื่อมต่อไปยังโดเมนของ Google ทำให้การอ้างเรื่อง privacy แบบครบวงจรดูไม่น่าเชื่อถือ https://imgur.com/a/7wVHnBA

  • เพราะมันเป็นการเช็กอัปเดตอัตโนมัติ https://github.com/ollama/ollama/blob/main/docs/faq.md

  • อย่างน้อย network call เหล่านี้ยังตรวจสอบและ audit ได้ จึงทำให้ผมรู้สึกว่ามีความน่าเชื่อถือมากขึ้น แค่ติดตามการเรียก network ทุกครั้งที่อัปเดต ก็สามารถจัดการได้

• ผมเห็นพฤติกรรมเดียวกันในปลั๊กอิน cline และ copilot ของ vscode ตั้งค่าฉันให้ใช้เฉพาะ local ollama และบล็อกการเชื่อมต่อ outbound แล้วมันก็หยุดทำงานทั้งหมด แม้ปิด telemetry ในการตั้งค่า cline ก็ยังคงพยายามติดต่อภายนอก ทำให้ผิดหวังมาก

• ผมคิดถึงเรื่องนี้บ่อยกว่าที่คิด ผมรู้สึกว่า privacy ที่แท้จริงมีความเสียดทานและความยากลำบากมาก

  • ผมไม่คิดว่าบทความนี้ช่วยแก้เรื่องพวกนี้ได้จริงจังหรือให้แนวทางปฏิบัติที่ชัดเจน

• ผมยังชอบแนวทาง local อยู่ และเหตุผลหลักคือความเร็ว AI inference ส่วนใหญ่ช้าหรือเทียบ local ไม่ต่างมาก ช่วงหลังนี้ผมได้ลอง cerebras (และได้ยินเรื่อง groq ด้วย) แล้วได้ลองความเร็วราว 1000 token/วินาที ทำให้เกณฑ์ความอดทนรอของผมเปลี่ยนไปมาก Cerebras บอกว่าไม่เก็บข้อมูล ผมอยากให้เชื่อครับว่าผมไม่มีความสัมพันธ์สปอนเซอร์ใดๆ กับพวกเขา (จริง ๆ ก็อยากให้มี!) ผมคิดว่ามันเป็นบริการที่ยอดเยี่ยมมาก แต่ก็ยังต้องการความก้าวหน้าที่เห็นได้ชัดในด้านความเร็วด้วย สถาปัตยกรรมโมเดลแบบ diffusion รู้สึกว่ารวดเร็วมาก

• ผมคิดว่าขีดจำกัดตอนนี้อยู่ที่ฮาร์ดแวร์มากกว่าซอฟต์แวร์ หากจะรัน LLM ที่คุ้มค่าสำหรับ local ต้องมีฮาร์ดแวร์อย่างน้อยประมาณ $2000 (เช่น Strix Halo, AI Max 395) ผมคาดหวังว่าเมื่อ Strix Halo ได้อัปเกรดอีกไม่กี่รอบ มันจะง่ายขึ้นมาก

  • การเปลี่ยนแปลงนี้เกิดขึ้นเร็วมากจริง ๆ https://simonwillison.net/2025/Jul/29/space-invaders/

  • แม้มีฮาร์ดแวร์ในช่วงราคานี้ แล้ว ก็ยังไม่ชัดว่าเกณฑ์ “ใช้งานได้” คืออะไร เพื่อให้เทคโนโลยีนี้มีคุณค่าได้จริง ต้องเป็นประสบการณ์ที่ใช้งานได้ทันทีราวกับเกิด “เวทมนตร์” เมื่อเจอผลลัพธ์ที่ช้าและไม่แน่นอนแล้วมานั่งจัดการตั้งค่าต่อเนื่อง มูลค่าส่วนใหญ่แทบหายไป แม้ local model จะดีขึ้นมาก แต่ในฝั่งความสามารถเขียนโค้ดยังไม่ทัดเทียมกับ Claude ผมเพิ่งรันโมเดล Qwen และ GLM รุ่นใหม่ของ OpenRouter ผ่าน cline แล้ว รู้สึกใกล้เคียง Claude 3.0 ผมคิดว่าการ benchmark มักสะท้อนความเป็นจริงไม่ครบ

• โปรดิวส์และบทความในบล็อกให้ความรู้สึกค่อนข้างสับสน หน้าเว็บระบุว่ามีการยก VM ขึ้นคลาวด์ (เช่นแบบ Firecracker) แต่บทความกลับบอกเหมือนรัน VM local เฉพาะ Mac ในฐานะคนที่เคยทำตัวเลือกแบบแรก ผมอยากลองรูปแบบตัวหลังร่วมกับ gpt-oss รุ่นใหม่

• แจ้งให้ OP รู้ว่าลิงก์นี้ใช้งานไม่ได้: https://github.com/assistant-ui/assistant-ui

• ผมคิดว่าโปรเจกต์นี้ออกแบบได้สวยงามมาก ผมเองก็กำลังทำสิ่งเดียวกัน โดยเป้าหมายสำคัญคือทำให้สลับระหว่างคลาวด์และ local ได้ง่าย ๆ ด้วยปุ่มเดียว ข้อมูล การตั้งค่า และ prompt ทั้งหมดจะถูกเก็บไว้ที่ local เท่านั้น และการเรียก API จะ route ไปยังผู้ให้บริการโดยตรงโดยไม่ผ่านเซิร์ฟเวอร์ของเรา ตอนนี้ผมใช้ mlc-llm สำหรับรัน inference แบบ local 100% ใน browser (Qwen3-1.7b ทำงานได้ดีมาก) https://hypersonic.chat/