ราคาโทเค็นกำลังแพงขึ้นเรื่อย ๆ

• ตรงกันข้ามกับความคาดหวังว่า ต้นทุนโทเค็นของ LLM จะลดลงปีละ 10 เท่า กลับเกิดปรากฏการณ์ที่บริการสมัครสมาชิก AI มีความสามารถในการทำกำไรแย่ลงเรื่อย ๆ
• ความต้องการต่อโมเดล LLM รุ่นล่าสุดมักกระจุกอยู่ที่ โมเดลระดับสูงสุด (SOTA, State-of-the-art) เสมอ ทำให้การลดราคาของโมเดล “รุ่นเก่า” ไม่ได้นำไปสู่การลดต้นทุนจริงอย่างมีนัยสำคัญ
• ยิ่งประสิทธิภาพโมเดลสูงขึ้น ปริมาณโทเค็นที่ใช้ก็เพิ่มขึ้นแบบทวีคูณ จนหักล้างการลดลงของราคาต่อหน่วย และกลับทำให้ต้นทุนรวมพุ่งสูงขึ้นแทน
• การทดลองแพ็กเกจสมัครสมาชิกแบบไม่จำกัด (เช่น Claude Code $200/เดือน) ก็ ไม่ยั่งยืนเพราะโทเค็นของผู้ใช้หนักพุ่งทะลัก
• ในระยะยาวไม่มีโมเดลใดที่ยั่งยืนนอกจาก การคิดค่าบริการตามการใช้งาน แต่การนำมาใช้จริงทำได้ยากจากการแข่งขันของสตาร์ตอัปและแรงต้านจากผู้บริโภค
• หากไม่เปลี่ยนไปสู่ โมเดลรายได้ ที่ยั่งยืน สตาร์ตอัปส่วนใหญ่ก็จะเผชิญความเสี่ยงล้มละลายในที่สุด

---

ธุรกิจสมัครสมาชิก AI ทำไมยิ่งขาดทุน ทั้งที่ราคาโทเค็นลดลง

ภาพลวงของการลดลงของราคา LLM

• ผู้ก่อตั้งจำนวนมากเชื่อใน VC playbook ที่ว่า “ราคาต่อโทเค็นจะลดลง 10 เท่าเรื่อย ๆ แค่ประคองไปก่อน เดี๋ยวก็เปลี่ยนเป็นธุรกิจมาร์จิ้นสูงได้” จึงเปิดขายบริการสมัครสมาชิกในช่วงแรกที่ระดับต้นทุนหรือถึงขั้นขาดทุน
• ในความเป็นจริง ราคาต่อโทเค็นของ โมเดลรุ่นเก่าอย่าง GPT-3.5 ลดลงมากกว่า 10 เท่า แต่ความต้องการของผู้ใช้และตลาดกลับเทไปที่ โมเดลใหม่ล่าสุดและดีที่สุด (SOTA) เสมอ
• ในทางปฏิบัติ เมื่อผ่านไป 18 เดือน มาร์จิ้นไม่ได้ดีขึ้น กลับแย่ลงเสียด้วยซ้ำ
• การลดราคาของโมเดลรุ่นเก่าจะรู้สึกได้ก็ต่อเมื่อมันกลายเป็นของที่ตลาดเลิกสนใจไปแล้ว เหมือน “หนังสือพิมพ์เมื่อวาน”

ราคาและโครงสร้างอุปสงค์ของโมเดลล่าสุด

• โมเดลล่าสุดอย่าง GPT-4, Claude 3 Opus มักเปิดตัวมาด้วยราคาสูงใกล้เคียงกันเสมอ และไม่ว่าโมเดลรุ่นเก่าจะถูกลงแค่ไหน ปริมาณการใช้งานจริงก็ยังน้อยมาก
• ผู้ใช้ต้องการเพียง “ประสิทธิภาพดีที่สุด” ส่วน “โมเดลเก่าราคาถูก” ก็ไม่ต่างจากรถมือสองเก่าในตลาดรถยนต์
• เพราะสิ่งที่ผู้ใช้ต้องการจริง ๆ จาก AI คือ ผลลัพธ์ที่ดีที่สุด จึงแทบไม่ค่อยมีใครสมัครใจใช้โมเดลรุ่นเก่าเพียงเพื่อประหยัดค่าใช้จ่าย
• สุดท้ายแล้ว หากอยากแข่งขันได้ในตลาด ก็ต้องมี โมเดลล่าสุดที่แพงที่สุด ให้บริการอยู่เสมอ และนั่นทำให้ต้นทุนยังคงอยู่ต่อไป
  • คล้ายกับสถานการณ์ที่ราคารถมือสองจากยุค 90 ลดลง แต่ผู้บริโภคก็ยังซื้อรถใหม่อยู่ดี

การเพิ่มขึ้นแบบระเบิดของการใช้โทเค็น

• เมื่อประสิทธิภาพของโมเดลสูงขึ้น ก็เกิดปรากฏการณ์ที่ งานหนึ่งครั้งใช้โทเค็นเพิ่มขึ้นแบบทวีคูณ
• งานที่ในอดีตจบได้ด้วย 1,000 โทเค็น ตอนนี้อาจใช้ถึง 100,000 โทเค็น
• แต่ก่อนอาจเป็นแค่ถามหนึ่งประโยค ตอบหนึ่งประโยค แต่ปัจจุบันกลายเป็นการทำรีเสิร์ชซับซ้อน ลูป หรือ orchestration ที่ทำงานต่อเนื่อง 10–20 นาที และใช้โทเค็นจำนวนมหาศาล
• เมื่อให้ AI ทำงานวิจัย/วิเคราะห์เชิงลึกมากขึ้น ก็เกิดรูปแบบอย่าง “รันครั้งละ 20 นาที รันต่อเนื่อง 24 ชั่วโมงต่อวัน” ทำให้ การใช้งานเฉลี่ยต่อวันต่อผู้ใช้พุ่งขึ้นอย่างรวดเร็ว
  • ตัวอย่างเช่น หากใช้ 'deep research' มูลค่า $1 เพียงวันละครั้ง ค่าสมาชิก $20 ก็ไม่คุ้มทุนแล้ว
• ส่วนที่ได้จากการลดลงของราคาต่อหน่วยถูก การเพิ่มขึ้นของปริมาณโทเค็นที่ใช้ทั้งหมดหักล้างหมด จนเกิดสถานการณ์ที่แพ็กเกจ $20/เดือนไม่สามารถรองรับงานราคา $1 ได้แม้แต่วันละครั้ง

ความล้มเหลวของแพ็กเกจไม่จำกัด

• Anthropic กับ Claude Code เป็นต้น ได้ลองใช้แพ็กเกจ ไม่จำกัด $200/เดือน, การปรับโทเค็นอัตโนมัติ, การใช้พีซีของผู้ใช้ และมาตรการลดต้นทุนอีกหลายแบบ
• แต่ผู้ใช้ระดับพาวเวอร์บางรายใช้โทเค็นเกือบ 10,000 ล้านโทเค็นต่อเดือน (เทียบเท่ากับ “War and Peace” 12,500 เล่ม) เพราะผู้ใช้สามารถอาศัยระบบอัตโนมัติ งานซ้ำ ๆ และลูป เพื่อเร่งการใช้โทเค็นอย่างมหาศาล
  • “การใช้ AI แยกขาดจากเวลาของมนุษย์ API จึงรัน 24 ชั่วโมงและทำให้โทเค็นพุ่งทะลัก”
• ท้ายที่สุด แม้จะมีนวัตกรรมทางวิศวกรรม ก็ยังต้องย้อนกลับนโยบายแพ็กเกจ
• บทสรุปคือ: โมเดลสมัครสมาชิกแบบไม่จำกัดเป็นไปไม่ได้แล้ว เพราะสมการนี้ใช้การไม่ได้อีกต่อไป

ภาวะกลืนไม่เข้าคายไม่ออกที่ทั้งอุตสาหกรรมต้องเผชิญ

• หากยังดันทุรังยึดติดกับโมเดลสมัครสมาชิกต่อไป ความเสี่ยงจาก ความสามารถในการทำกำไรที่แย่ลง และการล่มสลายก็จะยิ่งสูงขึ้น
• บริษัท AI ต่างก็รู้ว่า คำตอบมีเพียง การคิดค่าบริการตามการใช้งาน (usage-based pricing) แต่หากมีคู่แข่งที่ใช้ระบบสมัครสมาชิกเข้ามา ก็เสี่ยงเสียผู้ใช้ได้มาก
• ด้วยโครงสร้างแบบ “prisoner’s dilemma” ทุกฝ่ายจึงถูกบีบให้เข้าสู่ การแข่งขันอุดหนุนผู้ใช้หนัก
• Cursor, Replit และรายอื่น ๆ ก็ใช้แนวทาง “โตให้ได้ก่อน เรื่องกำไรค่อยว่ากันทีหลัง” แต่ท้ายที่สุดก็เลี่ยงการปรับโครงสร้างเมื่อปัญหากำไรปะทุขึ้นไม่ได้

แนวทางแก้ที่เป็นจริง 3 ข้อ

• 1. คิดค่าบริการตามการใช้งาน
  • หากนำโมเดลเศรษฐศาสตร์ที่ตรงไปตรงมามาใช้ตั้งแต่ต้น ก็สามารถออกแบบโครงสร้างรายได้ที่ไม่ต่ำกว่าต้นทุนได้ และในระยะยาวนี่คือโมเดลเดียวที่ยั่งยืน
  • แต่ผู้บริโภคไม่ชอบค่าบริการแบบคิดตามมิเตอร์อย่างมาก จึงมีข้อจำกัดด้านความสำเร็จในวงกว้าง
• 2. เจาะตลาดองค์กรที่มีต้นทุนการย้ายสูง
  • ทำ B2B sales กับ ลูกค้าองค์กร (เช่น บริษัทยักษ์ใหญ่, สถาบันการเงิน) ที่มีต้นทุนการเปลี่ยนระบบสูง เมื่อเข้าไปอยู่ในตลาดได้แล้วก็แทบยกเลิกไม่ได้ และทำมาร์จิ้นได้สูง
  • กลุ่ม system of record (SOR, เช่น CRM/ERP/EHR) เป็นตัวอย่างความสำเร็จที่ชัดเจน (เช่น การนำไปใช้กับวิศวกร 40,000 คนของ Goldman Sachs)
• 3. สร้างมูลค่าเพิ่มผ่านการบูรณาการแนวดิ่ง (Vertical Integration)
  • แบบ Replit ที่ยอมให้ LLM inference เป็น “สินค้าล่อ” ที่ขาดทุน แล้วไปสร้างรายได้จากบริการอื่นที่วางอยู่ด้านบน เช่น โฮสติ้ง, ฐานข้อมูล, การ deploy, การมอนิเตอร์
  • สร้างโครงสร้างที่ทำให้การใช้ AI เพิ่มขึ้นแล้วต่อยอดเข้าสู่ตลาดโครงสร้างพื้นฐาน
• ต่อจากนี้แม้ ราคาต่อโทเค็นจะยังลดลงต่อไป แต่ความคาดหวังและปริมาณการใช้งานของผู้ใช้ก็จะเพิ่มขึ้นแบบทวีคูณเช่นกัน
• บริษัทที่ยังยึดติดกับกลยุทธ์สมัครสมาชิกเพื่อการเติบโตเพียงอย่างเดียว มีความเสี่ยงสูงที่จะต้องจัด “งานศพต้นทุนสูง” ให้ตัวเองในที่สุด

สรุป

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

[mhj5730]

ด้วยความที่แคชได้ยาก บวกกับการทำงานอัตโนมัติผ่าน MCP การใช้งานแบบไม่จำกัดก็อาจมุ่งไปสู่การไม่จำกัดแบบไม่จำกัดจริง ๆ ได้ ..เหมือนผู้ให้บริการเครือข่ายที่ไม่มีแพ็กเกจดาต้าไม่อั้น อาจจะไปในทิศทางคิดค่าบริการแบบวันละ ~300 ครั้ง, วันละ ~2000 ครั้ง ฯลฯ.. ดูเหมือนว่าจะมุ่งไปสู่โมเดลค่าบริการแบบข้อความ SMS สมัยก่อนเหมือนกันนะครับ.

[doolayer]

ดูเหมือนว่าถ้าจะไปในแนวทางแบบอินเทอร์เน็ต ซึ่งปริมาณนั้นแทบไม่จำกัด (แม้บางกรณีจะมีการคิดค่าบริการตามการใช้งาน) แต่จำกัดความเร็วแทน ก็น่าจะดีนะครับ เรื่องการนำไปใช้จริง ทุกวันนี้ก็มีรูปแบบการประมวลผลแบบแบตช์อยู่แล้ว ดังนั้นทรัพยากรคอมพิวต์กับทรัพยากรที่ส่งไปถึงผู้ใช้ก็น่าจะแยกออกจากกันได้ สุดท้ายแล้ว ถ้าฝั่งผู้ให้บริการสามารถมีความสามารถในการคาดการณ์ได้ และผู้ใช้ก็ได้รับการรับประกันทั้งราคาและความเร็วในระดับที่สมเหตุสมผล แบบนี้ก็วินวินไม่ใช่หรือครับ? สำหรับผู้ใช้บางรายที่ใช้งานมากเกินไป ก็คงต้องไปในรูปแบบการจัดสรรทรัพยากรเฉพาะผ่านสัญญาแยกต่างหากครับ

[GN⁺]

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

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

  • ผมคิดว่าบริการ B2B แบบโครงสร้างพื้นฐานอย่าง AWS เหมาะกับการคิดตามการใช้งาน เพราะเมื่อธุรกิจโต การใช้งานโครงสร้างพื้นฐานและค่าบริการก็เพิ่มตามอย่างคาดการณ์ได้ และเมื่อตั้งค่าโครงสร้างพื้นฐานแล้วก็มักแทบไม่ต้องสนใจมันอีก แต่ในกรณีที่ใช้เป็นงานหรือเครื่องมืออย่าง AI การคิดค่าบริการแบบจ่ายตามการใช้งานเป็นอุปสรรคใหญ่ ในสถานการณ์แบบนี้มันถึงขั้นกลายเป็นเหตุผลที่ทำให้คนไม่ใช้ผลิตภัณฑ์เลย และทุกครั้งที่จะใช้ก็ต้องคอยวิเคราะห์ความคุ้มค่าต่อราคา ซึ่งเหนื่อยมาก ถ้าใช้ในงานก็อาจต้องคอยขออนุมัติผู้จัดการอยู่เรื่อย ๆ เครื่องมือที่ตั้งใจเพิ่มประสิทธิภาพไม่ควรสร้างกำแพงแบบนี้ แทบไม่มีใครอยากคิด 250 ครั้งว่า “การกระทำนี้คุ้ม 3 ดอลลาร์ไหม?” ถ้าเป็นแบบจ่ายตามการใช้งาน คนก็จะไม่ใช้มันไปเลย

  • ผมหงุดหงิดที่บริษัทพยายามซ่อนข้อมูลการแปลงโทเคนเป็นดอลลาร์ ตอนนี้กำลังลอง GitHub Copilot agent trial อยู่ และค่าบริการไม่โปร่งใสจริง ๆ มีแต่คำว่า “premium requests” โผล่มาตลอด แต่ในแดชบอร์ดของผมกลับดูการใช้งานแบบเรียลไทม์และขีดจำกัดไม่ได้ บน UI ถ้าคลิกเรื่อง premium requests ก็จะพาไปที่เอกสาร แต่ไม่ได้ชี้ไปยังแดชบอร์ดขีดจำกัดหรือค่าบริการที่ชัดเจน

  • บน Amazon (AWS) ปัญหายิ่งหนักกว่า ตรงข้ามกับคำล่อใจว่า AWS “ถูกกว่า” การย้ายจึงจะมีความหมายก็ต่อเมื่อมันถูกกว่าทางเลือกจริง ๆ แต่หลายบริษัทไม่ยอมใช้เวลานักพัฒนาไปเปลี่ยนโครงสร้างพื้นฐาน เพราะต้นทุนค่าเสียโอกาสสูงและมีความเสี่ยงทั้งด้านรายได้ เวลาในการพัฒนา และการแข่งขัน จึงมองว่าเป็นการเสียเวลานักพัฒนาถ้าผลตอบแทนจากการลงทุนไม่ได้สูงมากพอ ถ้าโครงสร้างพื้นฐานกลับแพงกว่าทางเลือกจริง สุดท้ายก็ต้องยอมรับความเสียหายนั้นเพราะใช้เวลานักพัฒนาไปแล้ว ตอนนี้ในโมเดลค่าบริการแบบอิงโทเคน ภาระเรื่องต้นทุนการย้ายและค่าเสียโอกาสยังไม่รู้สึกหนักเท่าไร เพราะกลับไปใช้วิธีเดิมได้ง่าย แต่ผมคาดว่าโครงสร้างนี้จะเปลี่ยนไปในอนาคต

  • โครงสร้างราคาของ Amazon รู้สึกกำกวมและซับซ้อนมาก ตัวอย่างเช่น บางครั้งก็ไม่มีทางรู้ได้ว่าทำไมค่าใช้จ่ายฐานข้อมูลถึงขึ้น ๆ ลง ๆ อยู่ตลอด

  • สำหรับกระบวนการที่กำหนดไว้ชัดเจน การคิดตามการใช้งานมีประโยชน์จริง ๆ สิ่งที่ผมชอบใน AWS คือมันช่วยให้ผูกต้นทุนเข้ากับธุรกิจจริงได้ เมื่อก่อนเรื่องนี้ยากและมีประเด็นการเมืองภายในเยอะมาก พนักงานขายอาจไปอ้อนผู้บริหารโดยตรงเรื่องความจำเป็นของอุปกรณ์ ทำให้ต้องรับอุปกรณ์เครือข่ายที่ไม่ต้องการเลยมาด้วย แต่จากมุมผู้ใช้ การบริหารต้นทุนละเอียดขนาดนี้ไม่ใช่เรื่องดี เพราะมันทำให้ผู้ใช้ถูกประเมินอยู่ตลอดจากตัวชี้วัดต่าง ๆ ที่ไม่เกี่ยวกับผลิตภาพโดยตรง ตอนเป็นเด็กฝึกงานช่วงยุค 90 ถ้าจะโทรทางไกลสักสายต้องฝ่าระบบราชการ ผู้อนุมัติจะมานั่งประเมินทีละอย่างว่าคุย 20 นาทีเหมาะสมไหม ถ้าเกินเพดานผมต้องออกเงินเอง เป็นประสบการณ์ที่ไม่สนุกเลย สำหรับ AI ที่ทำให้ผู้ใช้ Fixed pricing คือคำตอบ ถ้าผลิตภาพผมเพิ่มขึ้น 20% แล้วใช้ ChatGPT Pro เดือนละ $200 ก็เท่ากับมีมูลค่า $16k ต่อปี เป็นการลงทุนที่ถูกมาก

• ข้ออ้างในบทความฟังดูไม่สมเหตุสมผลสำหรับผม เนื้อหาที่ว่า “พอมีโมเดลใหม่ออกมา 99% ของดีมานด์ก็ย้ายไปทันที” เป็นสิ่งที่ผมเห็นด้วยยาก ตรงกันข้าม Sonnet 4 กลับถูกใช้มากกว่า Opus 4 และในความเป็นจริงมีผู้ใช้จำนวนมากที่ไม่ได้ใช้โมเดลประสิทธิภาพสูงสุด แต่เลือกโมเดลที่ถูกกว่าและธรรมดากว่า ด้วยเหตุผลหลากหลาย เช่น การใช้งานจริง ความเร็ว ความคุ้นเคย ฯลฯ โมเดลที่ไม่ใช่ SOTA จึงยังถูกใช้ควบคู่กันไป สามารถดูอันดับโมเดลได้ที่ https://openrouter.ai/rankings และการสลับจาก Opus ไป Sonnet แล้วตอนงานหนักค่อยไป Haiku ถูกอธิบายเหมือน autoscaling แต่ผมไม่คิดว่าพฤติกรรมแบบนั้นจะถูกฝังอยู่ในน้ำหนักโมเดลจริง ๆ โดยรวมแล้ว ปัญหาเรื่องแพ็กเกจในบทความดูเหมือนเป็นการนำปัญหาจากยุค cloud hosting กลับมาเล่นอีกครั้ง - ผู้ใช้จำนวนมากยอมใช้แบบรายเดือนแม้ประสิทธิภาพจะด้อยลงเพื่อความสะดวก ส่วนผู้ใช้ API บางกลุ่ม (heavy user/องค์กร) ก็ใช้แบบจ่ายตามการใช้งาน ซึ่งโครงสร้างนี้พิสูจน์แล้วว่าทำกำไรได้ดีพอ - สตาร์ตอัป AI ส่วนใหญ่เป็น B2B ไม่ใช่ B2C

  • ผมเห็นด้วยมากกับสถานการณ์ตอนนี้ที่การถกเถียงเรื่อง “โมเดลที่ดีที่สุดคืออะไร” รุนแรงขึ้น บางครั้งผมใช้ Mistral เป็น LLM หลัก และเมื่อเทียบกับ ChatGPT/Gemini/Claude ก็แทบไม่รู้สึกถึงความต่างมากในทางใช้งานจริง แถมยังเร็วกว่าเยอะ ตอนนี้การแข่งขันของ commercial LLM อยู่ในจุดที่ความคุ้มค่าต่อรายได้ไม่สูงมากแล้ว กรณีอย่าง Deepseek แสดงให้เห็นว่าต้นทุนสามารถลดลงพร้อมกับคุณภาพที่เพิ่มขึ้นได้ ผมคิดว่าอีกไม่นานสงครามราคาจะเริ่มจริงจัง นี่อาจเป็นเหตุผลที่แนวทาง Mixture of Experts หรือการแข่งขันด้านโมเดลเฉพาะทางเริ่มเด่นขึ้น กำลังพัฒนาไปในทิศทางที่ลดราคาและเพิ่มความแม่นยำ

• เรื่องที่ว่า “Claude Code เคยให้ไม่จำกัดที่ $200/mo แล้วค่อย rollback” ไม่ตรงกับข้อเท็จจริง ชื่อแพ็กเกจก็เป็นแพ็กเกจ 20x อยู่แล้ว และเดิมก็มีข้อจำกัดชัดเจน เช่น จำกัดเซสชันละ 5 ชั่วโมง และจำกัด 50 เซสชันต่อเดือน (แม้จะไม่ได้บังคับเข้มงวด) ตัวผมเองก็แทบไม่เคยรู้สึกว่ามันไม่พอ กลับกันยังรู้สึกว่าเพดานสูงอยู่ด้วยซ้ำ ดังนั้นพูดความจริงก็ไม่ได้ทำให้ข้อโต้แย้งเสียหายเลย

  • ใช่เลย เดิมที Max plan ก็ไม่ได้ถูกอธิบายว่าไม่จำกัดอยู่แล้ว ผมเห็นและได้ยินความเข้าใจผิดนี้บ่อยมาก พอมันถูกพูดซ้ำ ๆ จนตอนนี้ทุกคนคิดว่าไม่จำกัดไปแล้ว

• ปัญหาใหญ่ในทางปฏิบัติคือ ตอนนี้เรากำลังใช้โมเดลแบบไม่แยกแยะกับทุกงาน เหมือนใช้ปืนใหญ่ยิงยุง ไม่ใช่ทุกปัญหาที่ต้องใช้โมเดล SOTA ต่อไปบริการต่าง ๆ จะไปในทาง “bundle” หลายโมเดลเข้าด้วยกัน และจะได้กราฟการใช้งานที่มีประสิทธิภาพกว่ามาก

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

  • จนถึงตอนนี้ งานที่ยากที่สุดก็ยังไม่ได้รับการแก้ไข และก็มีงานไม่มากนักที่ยอมรับคำตอบความแม่นยำต่ำได้ งานใน text pipeline บางอย่างอาจพอได้ แต่การใช้งานที่เจอผู้ใช้จริงแทบทั้งหมดต้องการคุณภาพสูง

  • หลายคนมองข้ามจุดนี้ไป โมเดล GPU ขนาด 7b, 32b ก็ทำงานได้ดีพอสำหรับหลายงาน และยังรันบนฮาร์ดแวร์รุ่นเก่าได้ด้วย ตอนนี้เรายังอยู่ในช่วง hype ที่ประสิทธิภาพ LLM โดยรวมกำลังขึ้นเรื่อย ๆ แต่พอเวลาผ่านไป การพัฒนาของโมเดลขนาดใหญ่จะเริ่มชะลอ และจะเริ่มมีการเลือกทางที่สมจริงมากขึ้น

  • การลองใช้โมเดลหลายแบบมีคุณค่ามาก ช่วงหลังผมสร้างระบบแชตบอตง่าย ๆ ระบบหนึ่งที่ใช้ 5 โมเดลต่างกันตามสถานการณ์ การสลับและผสมโมเดลแบบหลากหลายสร้างความต่างอย่างมากทั้งด้านต้นทุน ประสบการณ์ผู้ใช้ และคุณภาพ

  • ถ้ามีตัวเลือกให้ Claude Opus คอยไกด์ Sonnet ผมคงใช้กับแทบทุกบทสนทนา ถ้าทำแบบนี้ด้วยมือจะยุ่งและทำให้จังหวะการทำงานสะดุด สุดท้ายเลยใช้ Opus อย่างเดียวต่อไป ด้วยการประมวลผลแบบขนาน ต้นทุนอินพุตก็ต่ำ ผมจึงคิดว่าต่อให้ prompt ใหญ่ขึ้นก็ไม่ได้เป็นภาระมาก

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

  • Claude code ใช้ทั้ง Sonnet และ Haiku แบบอัตโนมัติจริง ๆ และเมื่อจบเซสชันก็จะแจ้งสถิติต่าง ๆ เช่น โทเคน ค่าใช้จ่าย ฯลฯ ผมคาดว่าน่าจะมีวิธีดูข้อมูลพวกนี้ระหว่างเซสชันได้ด้วย

  • ตัวอย่างเช่น ลองให้มันพ่น “ระดับโมเดลที่แนะนำ” 1~10 สำหรับแต่ละ subtasks ใน prompt ก็น่าสนใจ

• ตลอด 1~2 ปีที่ผ่านมา ผมจ่ายค่า API เองโดยตรงและใช้ frontend แบบโอเพนซอร์สอย่าง LibreChat เพื่อเชื่อมต่อและใช้งานหลายโมเดล วิธีนี้เหมาะมากสำหรับการใช้งานเป็นครั้งคราว เติมเงินแค่ประมาณ $10 ทุกสองสามเดือนก็พอแล้ว เพราะปริมาณโทเคนที่ผมใช้น้อยกว่าค่าบริการแบบแพ็กเกจส่วนใหญ่มาก ผมจึงมองว่าวิธีนี้ถูกกว่ามาก แต่พอเริ่มลองใช้เครื่องมือต่าง ๆ อย่าง Claude Code โทเคนกลับหมดเร็วอย่างเห็นได้ชัด เมื่อวานแค่ 15 นาทีก็ใช้โทเคนไป $5 แล้ว ผมรู้ว่าเครื่องมือสำหรับโค้ดทำงานต่างจากการถาม LLM ตรง ๆ มาก แต่ก็ไม่คิดว่าความต่างจะเยอะถึงขนาดนี้ ที่น่าตกใจยิ่งกว่าคือการใช้โทเคนจำนวนมากมักไม่ค่อยเห็นชัดนัก เพราะถูกซ่อนไว้ใน context ที่ค่อย ๆ โตขึ้นหรือในการ orchestration ของเครื่องมือ

  • ปรากฏการณ์นี้เกิดขึ้นเพราะ Claude Code ใช้ context ที่กว้างกว่าเดิมมากและมีการประมวลผลแบบวนซ้ำมากกว่าปกติ

  • ผมใช้ Deepseek API $20 ได้เกือบทั้งปีแบบสบาย ๆ (ไม่สนว่าเป็นบริษัทจีน) มันช้า แต่ในบรรดาโมเดล Deepseek ที่โฮสต์แบบอิสระ ผมกลับรู้สึกว่าคุณภาพดีกว่าเสียอีก (จากประสบการณ์ผม) ผมไม่ได้ใช้พวก agent อะไรเลย

• ผมไม่เห็นด้วยกับคำกล่าวที่ว่า “99% ของดีมานด์จะไหลไปหาโมเดลล้ำหน้าสุดเสมอ” แนวหน้าที่แท้จริงไม่ได้อยู่ที่ ‘ความสามารถ’ อย่างเดียว แต่คือ ‘ความสามารถต่อราคา’ โมเดลสเปกสูงสุดไม่ได้ครอง 99% ของส่วนแบ่ง ตรงกันข้ามเลย สถิติของ OpenRouter บอกว่า Claude Opus 4 มีส่วนแบ่งแค่ราว 1% ส่วนที่นิยมสูงสุดคือ Sonnet 4 มีผู้ใช้ 18% ของสมาชิก นอกจากนี้ Gemini Flash 2.0 และ 2.5 ที่ถูกกว่าก็มีคนใช้มาก และยังถูกกว่า Sonnet 4 อีกด้วย

  • ถูกต้อง ผมเห็นด้วยกับแก่นของบทความทั้งหมด แต่ข้ออ้างที่ว่า Opus ถูกใช้มากกว่า Sonnet นั้นผิด แม้แต่ในกราฟยังมีชื่อ “Claude 3.5 Opus” ซึ่งเป็นโมเดลที่ไม่มีอยู่จริง หลังจาก 3.5 Sonnet เปิดตัว 3 Opus ก็แทบถูกลืมไปแล้ว และเพิ่งมีโมเดลราคาแพงอย่าง Opus 4 กลับมาไม่นานนี้ แต่ถึงอย่างนั้นสัดส่วนผู้ใช้ API ก็ยังไม่มากเมื่อเทียบกับ Sonnet 4

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

  • ผมสงสัยว่าลีลาการเขียนแปลก ๆ แบบนี้ เป็นความพยายามแสดงให้เห็นว่ามนุษย์เขียน ไม่ใช่ LLM เขียนหรือเปล่า

  • รับมือกับการเปลี่ยนแปลงของภาษาแบบธรรมชาติไม่ไหวหรือ?/ล้อเล่น บางทีคงต้องกลับไปใช้ชีวิตแบบสมัยก่อนแล้ว

  • ถ้าไป Tenderloin หรือ Mission Street ในซานฟรานซิสโก จะโดนยิงจริงไหมถ้าไม่ใช้ตัวพิมพ์ใหญ่กับเครื่องหมายวรรคตอน? (ล้อเล่น)

• บทความพลาดประเด็น “เก้าอี้ดนตรี” ในช่วงแย่งชิงพื้นที่ตลาด แบบกรณีของ Uber ที่ใช้เงินทุน VC เผาเพื่อยึดส่วนแบ่งตลาด และแม้จะขาดทุนหลายปี แต่พอฝังตัวในภาพจำของลูกค้าได้แล้ว ต่อให้มีคู่แข่งรายใหม่ที่ถูกกว่าเข้ามาทีหลัง ก็ใช่ว่าจะสั่นคลอนได้ง่าย ธุรกิจก็ตั้งหลักได้มั่นคง และหลังเข้าตลาดหุ้นก็ยังรักษาราคาหุ้นที่แข็งแรงได้พอสมควร (ถึงจะไม่ได้ยอดเยี่ยมมากก็ตาม)

• บทความทำเหมือนไม่มีใครยอมจ่ายราคาแบบจ่ายตามการใช้งาน ทั้งที่ในความเป็นจริงลูกค้า API (ซึ่งก็คือลูกค้าองค์กรแทบทั้งหมด) ต่างก็จ่ายแบบนี้กันอยู่แล้ว

[laeyoung]

"สงสัยว่าทำไมที่ซานฟรานซิสโกถึงไม่ใช้ตัวพิมพ์ใหญ่และเครื่องหมายวรรคตอน"

พอเข้าไปอ่านเนื้อหาจริงก็เป็นแบบนั้นจริง ๆ ครับ ที่น่าสนใจก็คือบางประโยคมีจุดปิดท้าย บางประโยคก็ไม่มีและปะปนกันอยู่ แบบนี้มีเหตุผลอะไรหรือเปล่าครับ? มีใครพอทราบไหมครับ สงสัยอยู่ 🤔