AI แบบโลคัลควรกลายเป็นมาตรฐาน

(unix.foo)

13 คะแนน โดย GN⁺ 8 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

กระแสการนำ API ของ OpenAI หรือ Anthropic มาเชื่อมกับฟีเจอร์ในแอปกลายเป็นเรื่องปกติไปแล้ว แต่การพึ่งพาโมเดล AI ที่โฮสต์บนคลาวด์ทำให้ฟีเจอร์หยุดทำงานได้เพียงเพราะเซิร์ฟเวอร์ล่มหรือมีปัญหาการชำระเงิน และยังเพิ่มภาระด้านความเป็นส่วนตัวอีกด้วย
อุปกรณ์สมัยใหม่มีความสามารถในการประมวลผลบนอุปกรณ์ที่ทรงพลัง เช่น Neural Engine แต่ส่วนใหญ่กลับถูกปล่อยให้ว่างงาน ขณะที่ตัวแอปรอเพียงการตอบกลับจากเซิร์ฟเวอร์
ตัวอย่างเช่น หากใช้เฟรมเวิร์ก FoundationModels ของ Apple ก็สามารถสร้างฟีเจอร์ AI อย่างการสรุป จัดหมวดหมู่ และดึงข้อมูลได้โดยตรงบนอุปกรณ์โดยไม่ต้องมีเซิร์ฟเวอร์
native iOS client ของ The Brutalist Report สร้างสรุปบทความแบบ on-device ผ่าน Apple local model API โดยตรง จึงไม่ต้องอ้อมผ่านเซิร์ฟเวอร์ และไม่ต้องมีเชิงอรรถเรื่อง prompt, user log, บัญชีผู้ขาย หรือการเก็บรักษาเนื้อหา
โมเดลแบบโลคัลอาจไม่ได้ฉลาดเท่าโมเดลคลาวด์ แต่สำหรับงาน แปลงข้อมูล อย่างการสรุป จัดหมวดหมู่ ดึงข้อมูล เขียนใหม่ หรือปรับให้อยู่ในรูปแบบมาตรฐาน ก็อาจเพียงพอ และควรใช้โมเดลคลาวด์เฉพาะเมื่อจำเป็นจริง ๆ

ปัญหาของการพึ่งพา Cloud AI

กำลังเกิดเทรนด์ที่นักพัฒนาเพิ่ม API call ไปยัง OpenAI หรือ Anthropic เข้าไปในฟีเจอร์ของแอปอย่างไม่ยั้งคิด
วิธีแบบนี้ทำให้ซอฟต์แวร์ เปราะบาง ละเมิดความเป็นส่วนตัว และไม่เสถียรโดยพื้นฐาน
- โครงสร้างแบบที่แอปหยุดทำงานทันทีเมื่อเซิร์ฟเวอร์ล่มหรือบัตรเครดิตหมดอายุ
ทันทีที่เริ่มสตรีมคอนเทนต์ของผู้ใช้ไปยังผู้ให้บริการ AI ภายนอก ลักษณะของผลิตภัณฑ์ก็เปลี่ยนไปโดยสิ้นเชิง
- มีประเด็นเรื่อง การเก็บรักษาข้อมูล, การยินยอม, การตรวจสอบ, การรั่วไหล, คำขอจากรัฐ, การใช้เป็นข้อมูลฝึกสอน ฯลฯ ตามมา
สแตกจึงซับซ้อนขึ้น เพราะต้องพึ่งพาทั้งสถานะเครือข่าย, uptime ของผู้ให้บริการภายนอก, rate limit, การเรียกเก็บเงินของบัญชี และสถานะของ backend ของตัวเอง
สุดท้ายแล้ว ฟีเจอร์ด้าน UX เพียงอย่างเดียวก็ถูกเปลี่ยนให้กลายเป็น distributed system ที่มีต้นทุน
การส่งงานที่ประมวลผลได้ในเครื่องขึ้นไปบนคลาวด์โดยไม่จำเป็นถือเป็นการทำร้ายตัวเอง

เหตุผลที่ควรใช้ประโยชน์จากอุปกรณ์โลคัล

วันนี้ซิลิคอนในอุปกรณ์ที่พกอยู่ในกระเป๋าเร็วขึ้นจนเทียบกับเมื่อ 10 ปีก่อนไม่ได้ และ Neural Engine เฉพาะทางก็ยังว่างงานอยู่เป็นส่วนใหญ่
- ในระหว่างนั้นกลับต้องรอ JSON response จาก server farm ในเวอร์จิเนีย ซึ่งเป็นโครงสร้างที่ไม่มีเหตุผล
เป้าหมายไม่ควรเป็น “AI everywhere” แต่ควรเป็น ซอฟต์แวร์ที่มีประโยชน์
ถ้าฟีเจอร์หนึ่งทำงานแบบโลคัลได้ การเลือกสร้าง dependency ภายนอกก็คือการเพิ่มความเสียหายโดยไม่จำเป็น

การสรุปแบบ on-device ของ The Brutalist Report

The Brutalist Report คือบริการ news aggregator ที่ได้แรงบันดาลใจจากเว็บสไตล์ยุค 1990s
ระหว่างการสร้าง native iOS client ล่าสุด เป้าหมายการออกแบบคือการคงประสบการณ์การอ่านข่าวที่หนาแน่นไปด้วยข้อมูล
ไคลเอนต์ iOS มีทั้งรายการพาดหัวที่คอนทราสต์จัด, reader mode ที่ตัดองค์ประกอบซึ่งทำให้อ่านเว็บได้ยากออกไป, และมุมมอง “intelligence” สำหรับสรุปบทความแบบเลือกใช้
หัวใจสำคัญคือสรุปเหล่านี้ถูกสร้างแบบ on-device ผ่าน Apple local model API
ไม่ต้องอ้อมผ่านเซิร์ฟเวอร์ ไม่ต้องมี prompt หรือ user log ไม่ต้องมีบัญชีผู้ขาย และไม่ต้องมีเชิงอรรถประเภท “เก็บเนื้อหาไว้ 30 วัน”
กระแสที่มองว่าการใช้ AI ทุกอย่างต้องเกิดขึ้นฝั่งเซิร์ฟเวอร์นั้นกลายเป็นเรื่องปกติเกินไป และหากจะย้อนทิศทางนี้ก็ต้องอาศัยความพยายามระดับอุตสาหกรรม
use case บางอย่างต้องการความฉลาดที่มีได้เฉพาะจากโมเดลที่โฮสต์บนคลาวด์ แต่ไม่ใช่ทุก use case จะเป็นเช่นนั้น จึงต้องตัดสินใจอย่างระมัดระวัง

เครื่องมือ Local AI ใน ecosystem ของ Apple

ใน ecosystem ของ Apple ตลอดปีที่ผ่านมา มีการลงทุนเพื่อให้นักพัฒนาใช้งานโมเดล Local AI ที่ฝังมาในระบบได้ง่ายขึ้น

โฟลว์พื้นฐานคือ import FoundationModels, ตรวจสอบความพร้อมใช้งานของ SystemLanguageModel.default, แล้วประกอบ prompt ด้วย LanguageModelSession เพื่อรับ response

import FoundationModels  

let model = SystemLanguageModel.default  
guard model.availability == .available else { return }  

let session = LanguageModelSession {  
  """  
  Provide a brutalist, information-dense summary in Markdown format.  
  - Use **bold** for key concepts.  
  - Use bullet points for facts.  
  - No fluff. Just facts.  
  """  
}  

let response = try await session.respond(options: .init(maximumResponseTokens: 1_000)) {  
  articleText  
}  

let markdown = response.content

สำหรับคอนเทนต์ยาว สามารถแบ่งข้อความธรรมดาออกเป็นช่วงละราว 10,000 ตัวอักษร สร้างโน้ตสั้นแบบ “facts only” จากแต่ละชิ้น แล้วค่อยรวมเป็นสรุปสุดท้ายในรอบที่สอง
งานลักษณะนี้เหมาะกับโมเดลโลคัลมาก
- ข้อมูลนำเข้าคือคอนเทนต์ที่ผู้ใช้กำลังอ่านอยู่แล้ว จึงอยู่บนอุปกรณ์
- เอาต์พุตมีขนาดเบา
- ประมวลผลได้เร็วและเป็นส่วนตัว
- งานนี้คือการสรุปหน้าที่ผู้ใช้เพิ่งเปิด ไม่ใช่การสร้างองค์ความรู้ใหม่ระดับโลก จึงไม่ต้องการสติปัญญาเหนือมนุษย์
Local AI โดดเด่นเมื่อบทบาทของโมเดลไม่ใช่การค้นหาทั้งจักรวาล แต่เป็นการแปลงข้อมูลที่ผู้ใช้เป็นเจ้าของ

วิธีสร้างความไว้วางใจ

ฟีเจอร์ AI อย่างการสรุปอีเมล, การดึงสิ่งที่ต้องทำจากโน้ต, หรือการจัดหมวดหมู่เอกสาร เป็นสิ่งที่ผู้คนต้องการแต่ยังไม่ไว้วางใจ
แนวทางคลาวด์ทั่วไปเปลี่ยนฟีเจอร์เหล่านี้ทั้งหมดให้กลายเป็นปัญหาเรื่องความเชื่อใจว่า “ส่งข้อมูลขึ้นเซิร์ฟเวอร์ได้หรือไม่”
Local AI เปลี่ยนโครงสร้างนี้ด้วยการประมวลผลข้อมูลที่มีอยู่บนอุปกรณ์ตรงนั้นเลย
ความไว้วางใจของผู้ใช้ไม่ได้เกิดจากนโยบายความเป็นส่วนตัวยาว 2,000 คำ
ความไว้วางใจเกิดจากการออกแบบให้ไม่จำเป็นต้องมีนโยบายแบบนั้นตั้งแต่แรก

Structured output และ AI แบบอิง type

หนึ่งในการตัดสินใจที่ Apple ทำได้ดีเมื่อไม่นานมานี้ คือการย้าย “AI output” จากก้อนข้อความไร้โครงสร้างไปเป็น ข้อมูลที่มี type
แทนที่จะใช้วิธี “ขอ JSON จากโมเดลแล้วหวังว่ามันจะออกมาดี” รูปแบบที่ใหม่กว่าและดีกว่าคือการนิยาม Swift struct ที่อธิบายผลลัพธ์ที่ต้องการ

ให้คำแนะนำเป็นภาษาธรรมชาติกับแต่ละฟิลด์ แล้วให้โมเดลสร้างอินสแตนซ์ของ type นั้น

import FoundationModels  

@Generable  
struct ArticleIntel {  
  @Guide(description: "One sentence. No hype.") var tldr: String  
  @Guide(description: "3–7 bullets. Facts only.") var bullets: [String]  
  @Guide(description: "Comma-separated keywords.") var keywords: [String]  
}  

let session = LanguageModelSession()  
let response = try await session.respond(  
  to: "Extract structured notes from the article.",  
  generating: ArticleIntel.self  
) {  
  articleText  
}  

let intel = response.content

วิธีนี้ทำให้ UI ไม่ต้องมาคอยแกะ bullet จาก Markdown หรือคาดหวังว่าโมเดลจะจำ JSON schema ได้
แอปสามารถ รับ type จริงที่มีฟิลด์จริงและ render ได้อย่างสม่ำเสมอ
มันสร้าง structured output ที่แอปนำไปใช้ได้จริง และกระบวนการทั้งหมดนี้รันแบบโลคัล
นี่ไม่ใช่แค่อินเทอร์เฟซที่สะดวกขึ้น แต่คือ การยกระดับคุณภาพทางวิศวกรรม
และคือความต่างที่ทำให้ในแอปแบบ local-first นั้น AI ไม่ใช่ “ลูกเล่นเจ๋ง ๆ” แต่เป็น “subsystem ที่เชื่อถือได้”

ข้อโต้แย้งต่อคำว่า “โมเดลโลคัลฉลาดน้อยกว่า”

จริงอยู่ว่าโมเดลโลคัลอาจไม่ฉลาดเท่าโมเดลคลาวด์ แต่สำหรับฟีเจอร์ส่วนใหญ่ในแอป ข้อนี้ไม่ใช่ประเด็นสำคัญ
สิ่งที่ฟีเจอร์ส่วนใหญ่ต้องการ ไม่ใช่ความสามารถในการเขียน Shakespeare หรืออธิบายกลศาสตร์ควอนตัม แต่เป็นความสามารถในการทำอย่างใดอย่างหนึ่งได้อย่างสม่ำเสมอในกลุ่มงาน สรุป จัดหมวดหมู่ ดึงข้อมูล เขียนใหม่ และทำให้เป็นมาตรฐาน
สำหรับงานเหล่านี้ โมเดลโลคัล ดีพออย่างมาก
ถ้าใช้โมเดลโลคัลแทนอินเทอร์เน็ตทั้งโลก คุณจะผิดหวัง แต่ถ้าใช้มันเป็น “ตัวแปลงข้อมูล” ภายในแอป คุณอาจสงสัยด้วยซ้ำว่าทำไมถึงเคยส่งงานนี้ไปที่เซิร์ฟเวอร์
ควรใช้โมเดลคลาวด์เมื่อจำเป็นจริง ๆ เท่านั้น และควรปล่อยให้ข้อมูลของผู้ใช้อยู่กับที่
การใช้ AI ควรเป็นการสร้าง subsystem จริงที่มี type output และพฤติกรรมที่คาดเดาได้ ไม่ใช่แค่แปะกล่องแชตเข้าไป

ความเป็นส่วนตัวและการสร้างความไว้วางใจ

มีฟีเจอร์ AI จำนวนมากที่ผู้คน ต้องการแต่ยังไม่ไว้วางใจ เช่น การสรุปอีเมล, การดึง action item จากโน้ต, และการจัดหมวดหมู่เอกสาร
แนวทางคลาวด์เปลี่ยนทั้งหมดนี้ให้กลายเป็นการทดลองเรื่องความไว้วางใจ: “โปรดส่งข้อมูลของคุณมายังเซิร์ฟเวอร์ เราจะจัดการมันอย่างดี”
Local AI เปลี่ยนเรื่องนี้อย่างถึงราก — ข้อมูลอยู่บนอุปกรณ์อยู่แล้ว และถูก ประมวลผลตรงนั้นทันที
ความไว้วางใจไม่ได้สร้างจากการเขียนนโยบายความเป็นส่วนตัว 2,000 คำ แต่สร้างจาก โครงสร้างที่ไม่จำเป็นต้องมีนโยบายแบบนั้นตั้งแต่ต้น

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

GN⁺ 8 시간 전

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

ความรู้สึกที่ผู้ใช้กระแสหลักมีต่อ Local AI ตอนนี้ คล้ายกับความรู้สึกที่เคยมีต่อโอเพนซอร์สเมื่อหลายสิบปีก่อน
ในสินค้าบางประเภท โซลูชันแบบเสียเงินนำหน้าไปไกลมากจนโอเพนซอร์สมักถูกมองข้ามไปเลย และบรรยากาศก็ประมาณว่า “จะลำบากไปทำไม?”
จากนั้น SaaS และแพลตฟอร์มแบบผูกขาดก็เกิดขึ้น และตอนนี้ก็เห็นชัดแล้วว่าการตัดสินแบบนั้นส่วนใหญ่ผิด
การ พึ่งพา Anthropic และ OpenAI ในงานเขียนโค้ดนั้นสูงจนน่าเหลือเชื่อ แต่หลายคนก็ไม่สนใจ หรือแค่หวังว่าจีนจะไม่หยุดปล่อย open weights
โมเดลธุรกิจของ open weights ยังใหม่มาก มีทั้งเกมอำนาจระหว่างรัฐและสถาบันวิจัยเข้ามาปะปนกัน และมีเงินมหาศาลไหลเวียนโดยแทบไม่มีการกำกับดูแลที่แท้จริง
ตอนนี้ของที่มีมูลค่ามหาศาลเปิดให้แทบทุกคนใช้ได้ แต่ก็เป็นการเดิมพันอันตรายที่อาจหยุดลงได้โดยไม่มีคำเตือนจากเหตุผลที่เราไม่มีทางควบคุม
- ตอนนี้ผมนึกไม่ออกเลยว่าอะไรจะมาหยุดไม่ให้คนรัน LLM แบบ open weights ระดับท็อปบนฮาร์ดแวร์ผู้บริโภคต่อไปได้
  สำหรับ 95% ของการใช้งาน มันก็ดีพออยู่แล้ว และไม่มีวันหมดอายุ
  “ความเสี่ยง” ก็แค่คุณจะใช้โมเดลรุ่นถัดไปไม่ได้ ซึ่งผลกระทบดูน้อยมาก
- ผมไม่รู้ว่า โมเดลธุรกิจของ AI แบบ open weights คืออะไร และจริง ๆ ก็คิดว่าแทบไม่มี
  อย่างดีที่สุดมันก็เหมือนโฆษณาเพื่อขายโมเดลที่ล้ำกว่านั้น
  ความต่างใหญ่จากโอเพนซอร์สคือ คุณไม่สามารถฝึก LLM ได้ด้วยแค่เวลาว่างและความตั้งใจ
  คุณต้องมีข้อมูลจำนวนมากและทรัพยากรคอมพิวต์มหาศาล
  เรื่องนี้ผมหวังว่าตัวเองจะคิดผิด เพราะอนาคตที่ไปทาง open weights น่าสนใจกว่ามาก
- ผมไม่คิดว่ามันควรถูกมองเป็นเกมระหว่าง local AI กับ cloud AI
  Local AI ควรถูกมองเป็นผลิตภัณฑ์แยกต่างหาก แล้วเอาไว้จัดการงานที่ไม่จำเป็นต้องใช้ cloud AI จริง ๆ ก่อน จากนั้นค่อยใช้ cloud AI เป็นทางเลือกสำรอง ซึ่งน่าจะลดต้นทุนได้มาก
- ผมกำลังรอให้รัฐบาลสหรัฐสร้าง local AI ของตัวเอง
  ถ้าทำด้วยภาษีประชาชน ก็มีโอกาสสูงว่าสุดท้ายจะต้องปล่อยเป็นโอเพนซอร์ส และ NSA ก็มีข้อมูลอินเทอร์เน็ตสะสมมาหลายสิบปี ถ้าเอามาฝึก โมเดล open weights ก็อาจดีได้พอ ๆ กับของบริษัทเอกชนบางราย
- เมื่อไหร่ก็ตามที่ต้นทุนกลายเป็นปัจจัยสำคัญ หรือมีตัวเลือกที่ฟรีแต่ด้อยกว่านิดหน่อยซึ่งน่าสนใจและเข้าถึงง่ายขึ้น เช่น on-device agent ที่ให้ประสบการณ์ผู้ใช้แบบ Apple ผู้ใช้ก็ขยับไปทาง local กันพอสมควรแล้ว
  ลองนึกถึงการลบพื้นหลังรูปหรือ OCR PDF ดูก็ได้ แทบไม่มีใครยอมจ่ายบริการรายเดือนเพื่อทำเรื่องพวกนี้ในชีวิตประจำวัน
ช่วงเวลานั้นจะมาถึง และมันก็ไม่ไกลแล้ว
แนวโน้มเริ่มชัดเจนมากแล้ว ตอนแรก LLM ที่แรงจริงรันได้แค่ในดาต้าเซ็นเตอร์ขนาดใหญ่ แต่ตอนนี้มันมาถึงระดับ เซิร์ฟเวอร์หลายเครื่องที่ใส่ H100 ไม่กี่ใบ อย่างชัดเจนแล้ว และกำลังค่อย ๆ ขยับไปสู่ “MacBook Pro หรือ Strix Halo ที่มี 128GB VRAM”
ภายใน 1 ปีข้างหน้า ในบริษัทต่าง ๆ รูปแบบ “ใช้ LLM ระยะไกลราคาแพงสำหรับวางแผน และใช้ LLM ในเครื่องที่ช้าแต่ยังเร็วกว่าคนสำหรับลงมือทำ” จะกลายเป็นมาตรฐาน และจากนั้นก็จะค่อย ๆ ขยับไปสู่ “ทำทุกอย่างด้วย local LLM ก็พอ”
สุดท้ายมันจะเกิดสมดุลแบบเดียวกับคลาวด์ยุคเดิม คือคุณจะโฮสต์เอง หรือจะจ่ายเงินเพื่อความยืดหยุ่นและความเร็ว
คำถามคือ local hosting จะช่วยดับภาวะ ความร้อนแรงด้านทรัพยากรคอมพิวต์ ในตอนนี้ได้มากแค่ไหน และนั่นจะมีความหมายต่อทั้งตลาดอย่างไร
- จุดนั้นมาถึงแล้วในตอนนี้
  ผมกำลังรัน Qwen และ Gemma แบบ quantized บนพีซีเกมมิ่งอายุ 3 ปีที่ยังใช้ได้ ประมาณ RTX 3080 12GB กับ RAM 32GB
  มันช้าและ context window ก็เล็ก แต่ถ้าจัด runtime ให้เหมาะสม มันก็สามารถไล่ดูและจัดหมวดหมู่รูปทริปเที่ยวได้
  ทำ OCR ใบเสร็จ สรุปรายจ่าย ตอบคำถามง่าย ๆ วิเคราะห์โค้ด และถ้าไม่ต้องใช้บริบทมากก็เขียนโค้ดได้ด้วย
  ถ้าลงแรงกับการเชื่อมต่อ VS Code หน่อย ผมคิดว่าก็น่าจะทำ autocomplete ที่พอใช้ได้
  “MacBook Pro หรือ Strix Halo ที่มี 128GB VRAM” น่าจะเป็นสเปกขั้นต่ำที่ใช้งานได้จริงสำหรับ agentic coding
  แต่ตอนนี้สถานการณ์กลับกันอยู่ เวอร์ชันคลาวด์ถูกกว่าการโฮสต์เองหลายหลัก เพราะการแชร์ทรัพยากรทำให้อัตราการใช้งานเซิร์ฟเวอร์สูงกว่ามาก
  ถ้าบริษัทใช้เงิน 500,000 ดอลลาร์กับเครื่องสำหรับรัน GLM 5.1 ก็จะได้ความปลอดภัยของข้อมูล ความยืดหยุ่น และไม่มีการเซ็นเซอร์ แต่ถ้าเทียบกับค่า seat license ของ Anthropic มันแพงเกินไป
- ผลกระทบที่ใหญ่ที่สุดของโมเดลในเครื่อง อาจเป็นแค่การป้องกันไม่ให้ การทำ inference จากระยะไกล กลายเป็นทางเลือกเดียว
แค่ไม่กี่บรรทัดถัดจากนี้ ก็มีคนโวยเรื่อง Chrome ใส่ โมเดล LLM แบบในเครื่อง ที่ใช้พื้นที่หลาย GB สำหรับ local inference
กลายเป็นว่าจะทำก็โดนด่า ไม่ทำก็โดนด่า
- แค่ไม่ใช้แบนด์วิดท์และพื้นที่เก็บข้อมูลระดับกิกะไบต์โดยไม่ถามก่อนก็พอ
- ถ้าผมต้องใช้โมเดล ผมจะไปดาวน์โหลดเอง
  ไม่นานมานี้ผมก็ทำแบบนั้นเพื่อเล่นกับการสร้างภาพ
- การตีความแบบนั้นไม่ค่อยซื่อตรงเท่าไร
  คนไม่ได้โกรธที่มีการติดตั้งโมเดลในเครื่อง แต่โกรธเรื่อง การขาดอำนาจตัดสินใจของผู้ใช้
  อย่าติดตั้งเงียบ ๆ แค่ให้ผู้ใช้เลือกว่าจะดาวน์โหลดโมเดลไหมก็พอ
  มันไม่ได้ยากอะไร และตัวเลือกแบบ local อื่น ๆ ก็ทำงานแบบนี้กันทั้งนั้น
- การตีความแปลก ๆ
  ถ้าไม่ใช่ opt-in หรือเป็นการยัดใส่เบราว์เซอร์ ก็ไม่น่าสนับสนุน
  ไม่มีใครโมโหเวลาที่แอปซึ่งรัน local LLM ดาวน์โหลดข้อมูลที่จำเป็น
- ควรลองอ่านคอมเมนต์ดูว่าคนบ่นเรื่องอะไรกันจริง ๆ
  คอมเมนต์นี้นำเสนอธรรมชาติของการถกเถียงแบบไม่ค่อยซื่อตรงพอสมควร
ผมคิดว่าควรแยก การถกเถียงเรื่อง Private AI ออกจากการถกเถียงเรื่อง local AI
ทางเลือกที่เป็นจริงสำหรับการรัน LLM ขนาดใหญ่ก็คือเซิร์ฟเวอร์ใหญ่หนึ่งเครื่องหรือหลายเครื่องที่ออนไลน์อยู่ แต่ก็ไม่ได้แปลว่าต้องมีแค่บริษัทเอกชนเท่านั้นที่รันมันได้
ตัวเลือกด้านความเป็นส่วนตัวอาจเป็นโซลูชัน inference แบบ self-hosted ที่ดูแลง่าย ติดตั้งง่าย ให้การแยก tenant ที่ดี และ ideally เป็น zero-trust เหมือน Plex สำหรับ AI
เอาจริง ๆ ผมยังไม่ได้ศึกษาด้านนี้เลย เลยไม่รู้ว่ามันเป็นไปได้แค่ไหน หรืออาจมีอยู่แล้วและผมแค่ยังไม่ได้เข้า Discord server ที่ถูกก็ได้
และเสริมอีกนิด แม้จะไม่จำเป็นต้องพูดตรงนี้ก็ตาม เรื่องที่น่าทึ่งคือ โมเดลเปิด ตอนนี้เข้าใกล้โมเดลเชิงพาณิชย์ที่ดีที่สุดมากแล้ว ดังนั้นส่วนที่ยากที่สุดก็นับว่าเกือบถูกแก้ไปแล้ว
- อีกทางเลือกหนึ่งคือ private inference ที่ตรวจสอบได้ โดยรันโมเดลโอเพนซอร์สภายใน secure enclave บนคลาวด์
  ใช้ NVIDIA confidential computing ตัวโค้ดใน enclave เป็นโอเพนซอร์ส และเมื่อเชื่อมต่อก็ตรวจสอบด้วย remote attestation เพื่อพิสูจน์เชิงคริปโตว่าผู้ให้บริการ inference ไม่สามารถเห็นข้อมูลใด ๆ ได้
  Tinfoil: https://tinfoil.sh/ เป็นตัวอย่างที่ดี ขอเปิดเผยผลประโยชน์ทับซ้อนว่าผมเป็นผู้ร่วมก่อตั้ง
  อ่านวิธีทำงานเพิ่มเติมได้ที่นี่: https://docs.tinfoil.sh/verification/verification-in-tinfoil
  ที่บอกว่าโมเดลเปิดเข้าใกล้โมเดลเชิงพาณิชย์ที่ดีที่สุดนั้น โดยรวมแล้วก็จริงสำหรับงานบางประเภท
  ยกตัวอย่างเช่น อินเทอร์เฟซแชต ตอนนี้แทบจะใช้ประโยชน์จากความฉลาดที่สูงกว่าของโมเดลระดับท็อปได้ไม่ค่อยดีอยู่แล้ว เมื่อเทียบกับสิ่งที่โมเดลโอเพนซอร์สที่ดีที่สุดให้ได้
  แต่ runtime สำหรับงานเขียนโค้ดยังได้ประโยชน์จากความฉลาดของโมเดลที่สูงกว่าอยู่มาก โดยเฉพาะเมื่อ environment สำหรับเขียนโค้ดของผู้ให้บริการและอินเทอร์เฟซการเรียกใช้เครื่องมือของโมเดลถูกผูกเข้าด้วยกันอย่างแน่นผ่าน reinforcement learning แบบเดียวกับใน claude-code หรือ codex ซึ่งเป็นอีกเหตุผลว่าทำไมถึงยังมีช่องว่างด้านประสิทธิภาพ แม้จะควบคุมตัวแปรเรื่องความฉลาดของโมเดลแล้วก็ตาม
  แม้แต่ผู้ก่อตั้ง opencode ซึ่งเป็น runtime สำหรับเขียนโค้ดแบบโอเพนซอร์สที่รองรับผู้ให้บริการหลายราย ก็เพิ่งบ่นถึงความยากในการปรับ runtime ให้เข้ากับผู้ให้บริการแต่ละเจ้า: https://x.com/thdxr/status/2053290393727324313
ตัวอย่างในบทความยืนยันความคิดของผมว่า หากโมเดลในเครื่องจะประสบความสำเร็จ มันไม่จำเป็นต้องใหญ่พอจะแข่งกับโมเดลแนวหน้าสุดได้ แค่ ดีพอ ก็พอ
มันต้องทำงานเล็ก ๆ ได้ดี และรันบนอุปกรณ์ผู้บริโภคได้อย่างสมเหตุสมผล
ถ้ารันบนมือถือได้ก็ยิ่งดี
จากที่ผมลองเล่นกับ local LLM มา การเพิ่มขนาดโมเดลก็ดีอยู่หรอก แต่ปัจจัยที่เปลี่ยนโมเดลจากแทบไร้ประโยชน์ให้กลายเป็นมีประโยชน์จริง ๆ คือ ความสามารถในการใช้เครื่องมือ
ตอนที่อนุญาตให้มันค้นเว็บและดึงหน้าเว็บมาใช้ มันช่วยลดอาการหลอนได้มากกว่าการใช้โมเดลใหญ่ขึ้นเสียอีก และยังไม่มีปัญหาเรื่อง knowledge cutoff ด้วย
แน่นอนว่าโมเดลใหญ่กว่าอาจใช้เครื่องมือได้ดีกว่า แต่หลายครั้งโมเดลเล็กก็เพียงพอแล้ว
ผมทำเดโมไว้ว่า Prompt API ใหม่ของ Chrome ซึ่งใช้โมเดลในเครื่อง ทำอะไรได้บ้าง: https://adsm.dev/posts/prompt-api/#what-could-you-build-with...
มันโดดเด่นในสภาพแวดล้อมแบบจำกัด ที่เน้นแปลงข้อมูลซึ่งผู้ใช้เป็นเจ้าของเอง ตามที่บทความต้นฉบับพูดไว้
แต่สำหรับงานที่เปิดกว้างกว่านั้น มันชัดเจนว่าใช้งานได้น้อยกว่า
- ผมไม่แนะนำให้มอง Prompt API ของ Chrome เป็นตัวอย่างที่ดีของ local LLM
  มันก็พอใช้ได้ แต่จริง ๆ แล้วอ่อนมาก
  โมเดล 8B เมื่อปีก่อนยังดีกว่าในบางด้าน และโมเดลล่าสุดก็ดีขึ้นอย่างมีนัยสำคัญ
- “เขียนข้อความโฆษณาใหม่โดยใช้บริบทรอบข้าง” ใช่เลย นั่นแหละคือแผน
  มันทำไม่ได้ถ้าไม่มีทั้ง local model และหน้าเว็บ
  ขณะที่คนอื่นต้องรับภาระค่าไฟและการเสื่อมของฮาร์ดแวร์ ผู้ขายกลับได้ เทคโนโลยีโฆษณาแบบขูดรีดและการเฝ้าระวัง ที่มากขึ้น ดีขึ้น และถูกลง
- เท่ากับว่ากำลังรัน LLM เพื่อทำ data transformation ที่จริง ๆ แล้วขั้นตอนแบบกำหนดแน่นอนน่าจะเหมาะกว่าเยอะ และทำแบบนั้นด้วย พาวเวอร์ซัพพลาย 1000 วัตต์
  สุดยอดจริง ๆ
ผู้เล่นเดิม ๆ จะทำทุกอย่างเพื่อขัดขวาง local แต่ก็มีเหตุผลทางเทคนิคหลายอย่างที่ทำให้น่าเชื่อว่าโมเดลขนาดเล็กและเฉพาะทางอาจกลายเป็นมาตรฐานในที่สุด
ถ้าเป็นแบบนั้น local ก็จะตามมาเอง
บทความต้นฉบับเน้นว่าจริง ๆ แล้วสิ่งที่ผู้ใช้ต้องการจำเป็นต้องใช้โมเดลใหญ่หรือไม่
แต่ก็มีเหตุผลด้วยว่าโมเดลใหญ่อาจไม่มีวันน่าเชื่อถือพอจริง ๆ จนกว่า a) mechanistic interpretability จะก้าวหน้าพอ หรือ b) ระบบหลายเอเจนต์จะไม่กลายเป็นระบบหลายโมเดลทั้งหมด
ในกรณี a ความก้าวหน้าด้าน mechanistic interpretability อาจช่วยแก้ปัญหาของโมเดลใหญ่ แต่ในขณะเดียวกันก็อาจทำให้เราดึง representation แบบรวมศูนย์ออกมา แล้วตัดเอาเฉพาะส่วนที่มีประโยชน์จากโมเดลยักษ์มาใช้ได้ด้วย
เอาแค่สิ่งที่ต้องใช้ และทิ้งส่วนที่ไม่จำเป็น เพื่อลดต้นทุนและลดพื้นผิวของปัญหา
ต้องการแค่ตรรกะหรือ? ต้องการแค่วิสัยทัศน์หรือ? ก็ตัดเอาส่วนนั้นออกมาจากสัตว์ประหลาดตัวใหญ่ได้เลย
ความสามารถในการแยกปัญหาออกจากกันคงมาได้ยาก หากยังแยก subsystem เชิงหน้าที่ออกจากกันไม่ได้
ส่วนกรณี b ก็ลองดู evil vector หรือหมวดอาการหลอนที่เฉพาะกับการใช้เครื่องมือ
ถ้าเรายังไม่มีคำตอบสมบูรณ์สำหรับการจัดแนวแบบ helpful/honest/harmless ความคิดสร้างสรรค์กับความเข้มงวด รวมถึงคุณสมบัติอีกหลายอย่าง ก็มีแนวโน้มจะขัดแย้งกันโดยพื้นฐาน
ถ้าสุดท้ายต้องใช้หลายโมเดลทำทุกอย่างอยู่ดี แล้วจะต้องมีโมเดลสารพัดประโยชน์ขนาดมหึมาราคาแพงไปทำไม
ดังนั้น ความเฉพาะทางจึงเป็นแรงกดดันให้ทุกอย่างถูกย่อให้เหลือโมเดลผู้เชี่ยวชาญที่เล็กที่สุดและเชื่อถือได้มากที่สุด
ประเด็นกังวลของผมกับ LLM แยกจากเรื่องปรัชญาและผลกระทบทางเศรษฐกิจ คือดูเหมือนว่าเราจะฝึก โมเดลที่ใช้งานได้จริง แบบ local ได้ยาก
LLM แบบของเล่นอาจทำได้ แต่ถ้าจะให้มีประโยชน์จริงคงยาก
ไม่ใช่แค่ต้องใช้พลังคอมพิวต์มหาศาล แต่ยังต้องใช้ชุดข้อมูลที่ส่วนใหญ่ได้มาอย่างผิดกฎหมายด้วย
- มองโลกในแง่ร้ายเกินไปหน่อย
  ผมอาจไม่ได้ฉลาดมากนักเป็นการส่วนตัว แต่กว่าจะได้สติปัญญาเท่าที่มีอยู่ตอนนี้ ผมก็ไม่ได้ต้องเรียนรู้จากหนังสือทุกเล่ม บทความ Wikipedia ทุกหน้า บล็อกทุกโพสต์ คู่มืออ้างอิงทุกเล่ม หรือทุกบรรทัดของโค้ดที่เคยมี
  จริง ๆ แล้วผมไม่ได้เรียนรู้แม้แต่ 1% ของสิ่งเหล่านั้น หรือกระทั่ง 0.00000000001% ด้วยซ้ำ
  เห็นได้ชัดว่าตัวข้อความเองไม่ใช่เงื่อนไขตั้งต้นของสติปัญญา
  อย่างน้อยถ้าผมเข้าใกล้ความฉลาดได้จากการสังเกตโลกแบบหลวม ๆ สัก 20 ปี นั่นก็เป็นหลักฐานชัดเจนว่าชุดข้อมูลที่จำเป็นจริง ๆ อาจมีแค่ เซนเซอร์และโลกแวดล้อม
  แน่นอนว่าสมองมนุษย์ไม่ได้เริ่มจากศูนย์ และมีวิวัฒนาการนับล้านปีก่อนหน้าที่สร้างดินให้สติปัญญาหยั่งรากได้
  แต่โครงสร้างพื้นฐานนั้นก็ค่อนข้างทั่วไป และไม่ได้ดูเหมือนจะพึ่งพาชุดเรียนรู้เฉพาะเจาะจง
  มันอาจเป็นไปได้ที่จะวิวัฒน์สิ่งนี้ขึ้นมาแบบประดิษฐ์
- ด้วยเทคโนโลยีปัจจุบัน แม้จะไม่ใช่ทั้งโมเดล แต่ LoRA นั้นยอดเยี่ยมมากสำหรับการ fine-tune และทำได้ภายในไม่กี่ชั่วโมงบนคอมเกมมิ่งระดับสูง
  ถ้า base model รองรับภาษาของผม แปลว่าด้วยพลังคอมพิวต์ส่วนเกินจากอุปกรณ์อิเล็กทรอนิกส์ที่มีอยู่ ผมก็น่าจะฝึก LoRA ได้หลายตัวต่อเดือน
  ในอนาคตเมื่อคอมพิวเตอร์บ้านทั่วไปมีพลังระดับเซิร์ฟเวอร์ในปัจจุบัน เราก็น่าจะฝึก LLM ทั้งตัวที่บ้านได้
- เหตุผลที่เรื่องนี้สำคัญคือ ต่อให้รันโมเดลแบบ local มันก็ยังอาจเป็น โมเดลปิด ได้อยู่ดี
  ผมไม่มีส่วนร่วมเลยว่ามันฝึกมาจากอะไร ข้อมูลฝึกถูกติดป้ายกำกับอย่างไร มี guardrails อะไร หรือมีอคติแบบไหน
- มีเทคโนโลยีอีกมากที่คุณทำซ้ำในระดับ local ไม่ได้ และผมก็ไม่คิดว่า LLM จะต่างออกไปเป็นพิเศษ
  เหมือนอย่างทุกอย่าง เราจะมีผู้ผลิต LLM รายใหญ่ ผู้ผลิต LLM รายเล็ก ช่างฝีมือทำ LLM คนทำ LLM เป็นงานอดิเรก และผู้บริโภค LLM
- มันขึ้นอยู่กับสาขา
  มี use case จำนวนไม่น้อยที่สามารถหา training data สำหรับการใช้งานส่วนบุคคลหรือไม่เชิงพาณิชย์ได้
  จากจุดนั้นก็เหลือแค่ปัญหาเรื่องพลังคอมพิวต์และเวลาที่ต้องใช้ในการฝึก ซึ่งถ้าคุณยอมรอได้ ฮาร์ดแวร์ผู้บริโภคก็สามารถสร้าง โมเดลที่มีประโยชน์ ได้
ประโยคที่ว่า “ใช้โมเดลคลาวด์เฉพาะเวลาจำเป็นจริง ๆ” นั้นถูกต้อง แต่ปัญหาคือการใช้ โมเดลล้ำสมัยที่สุด ที่มีการอุดหนุนต้นทุนอยู่ มันง่ายกว่าการเสียเวลาไปจูน local model มาก
ผมเพิ่งตระหนักเรื่องนี้จาก coding agent
ไม่จำเป็นต้องใช้รุ่นล่าสุดแบบ xhigh ตลอดก็จริง แต่สุดท้ายก็มักลงเอยแบบนั้น
เพราะมันทำงานเสร็จได้เร็วกว่า ใช้ความพยายามน้อยกว่า และราคาก็แทบไม่ต่างกัน
ผมคิดว่าเราจะเริ่มเห็นความพยายามจริงจังกับ local AI ก็ต่อเมื่อผู้ขายรายใหญ่เริ่มคิดเงินตามปริมาณ token ที่ใช้จริง
- ที่ว่าใช้โมเดลล้ำสมัยง่ายกว่า นั่นไม่ใช่บั๊ก แต่มันคือฟีเจอร์
  ผมเปิดแท็บผู้ให้บริการฟรีไว้ประมาณ 8 แท็บ และ ChatGPT, Claude, Gemini ก็อยู่ฝั่งล้ำสมัย
  ผมใช้ตัวหนึ่งจนถึงลิมิตแล้วก็ย้ายไปอีกตัวได้แบบไม่มีปัญหา
  ผมทำแบบนี้ได้ทั้งวันเพื่อให้มันช่วย implement ฟังก์ชันหรือคลาสบางส่วนในโค้ดของผม
  เพราะผมรู้วิธีเขียนและออกแบบซอฟต์แวร์จริง ๆ ผมจึงไม่จำเป็นต้องให้ agent วิ่งวนเพื่อหวังให้มันทำทุกอย่างเสร็จในวันเดียว
  แค่ใช้เว็บแชตบอตกับการคัดลอก/วาง ผมก็สร้างโค้ดได้หลายพันบรรทัดต่อชั่วโมง โดยยังคงมี mental model ของโค้ดที่ชัดเจน และแก้ส่วนที่ต้องแก้เองได้
  เมื่อเช้านี้ผมก็เพิ่งทำแบบนั้นกับโปรเจกต์ Python
  เพราะผมเป็นคนออกแบบสิ่งที่ต้องการเอง แต่ละครั้งที่ให้สร้างจึงเป็นการขอแค่ฟังก์ชันเดียว และตอนเช้าที่ต้องเพิ่มอะไรบางอย่าง ผมก็ไปแก้ในตำแหน่งที่ถูกเองทันทีโดยไม่ต้องถามแชตบอต
  ถ้าคุณให้มันสร้างทั้งหมดจากสเปกตั้งแต่แรก คุณจะทำแบบนั้นไม่ได้
- เส้นทางที่แรงต้านน้อยที่สุดมักชนะ
  โดยเฉพาะเมื่อราคาซ่อนต้นทุนที่แท้จริงเอาไว้
- ผมยังไม่เห็นประสิทธิภาพที่ดีจาก local model
  ทุกครั้งที่มีโพสต์เรื่อง LLM ในคอมเมนต์จะมีคนจำนวนมากยืนยันหนักแน่นว่าตนได้ผลลัพธ์ดีเท่า Opus จาก DeepSeek/Qwen รุ่นล่าสุด หรือรุ่นอื่น ๆ แต่ประสบการณ์ของผมไม่เป็นแบบนั้นเลย
  โมเดลโอเพนซอร์สพังแบบหมดรูปเมื่อให้ทำงานที่ซับซ้อนขึ้นมานิดเดียวเมื่อเทียบกับ Claude
  มันทำให้ผมสงสัยว่านี่อาจคล้าย Linux ยุค 90 หรือเปล่า
  มันพอทำงานได้ในระดับหนึ่ง แต่ยังไม่พร้อมจริงสำหรับผู้ใช้ตามบ้าน ทั้งที่มีคนจำนวนมากยืนยันต่อหน้าคุณว่าทุกอย่างโอเคแล้วด้วยเหตุผลเชิงอุดมการณ์เป็นหลัก
ผู้คนกำลังพยายามสร้าง “ซอฟต์แวร์ที่ดีที่สุด” กันจริง ๆ
พวกเร่งการพัฒนา AI แบบดอนกิโฆเต้เป็นเพียงคนส่วนน้อยเสียงดังในหมู่คนที่สร้างซอฟต์แวร์ และการเลือก API ออนไลน์แทนระบบ local ส่วนใหญ่ไม่ใช่เพราะนักพัฒนาขี้เกียจ แต่เป็นการเลือกเพื่อผู้ใช้
ตอนนี้เราทำสิ่งต่าง ๆ ได้มากกว่าและดีกว่าด้วย AI แบบปิด มากกว่า local model
เรื่องนี้หลีกเลี่ยงไม่ได้
ต่อให้ local AI ดีขึ้น การลงทุนกับสมรรถนะระดับแนวหน้าของ LLM ก็มักยังคุ้มค่าอยู่
คนส่วนใหญ่จะไม่ยอมรับผลิตภัณฑ์ ถ้ามันไม่ดีระดับท็อปและไม่สะดวกอย่างมาก
มาตรฐานนั้นสูง และ local AI ก็มักไปไม่ถึง
ความดื้อดึงของ HN ที่ชอบปฏิบัติต่อผู้ใช้ทุกคนเหมือนเป็นพวกคลั่งโอเพนซอร์ส เน้นความเป็นส่วนตัว และ self-hosted Linux นั้นชวนอายจนดูเชยมาก