ผลการวัดต้นทุนโทเคไนเซอร์ของ Claude 4.7

 (claudecodecamp.com)
3 คะแนน โดย GN⁺ 12 일 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Claude 4.7 สร้างโทเคนมากกว่ารุ่นก่อนหน้าโดยเฉลี่ย 1.3~1.45 เท่า ทำให้ภายใต้โครงสร้างราคาเดิม ต้นทุนต่อเซสชันเพิ่มขึ้น 20~30%
  • การเพิ่มขึ้นของโทเคนเด่นชัดใน คอนเทนต์ภาษาอังกฤษและโค้ด ขณะที่คอนเทนต์ CJK (จีน·ญี่ปุ่น·เกาหลี) แทบไม่เปลี่ยนแปลง
  • จากการโทเคไนซ์ที่ละเอียดขึ้น ทำให้ ความสามารถในการทำตามคำสั่ง (Instruction Following) ดีขึ้นราว 5 จุดเปอร์เซ็นต์ โดยเฉพาะข้อผิดพลาดด้านรูปแบบที่ลดลง
  • จำนวนโทเคนของแคชพรีฟิกซ์และประวัติการสนทนาเพิ่มขึ้น ส่งผลให้ ต้นทุนแคชและความเร็วในการใช้เรตลิมิต สูงขึ้นตามไปด้วย
  • โดยสรุป Claude 4.7 ถูกประเมินว่าเป็นโครงสร้างที่ แลกต้นทุนโทเคนที่เพิ่มขึ้น เพื่อให้ได้ ความแม่นยำและการทำตามคำสั่งที่ละเอียดขึ้น

ผลการวัดโทเคไนเซอร์ของ Claude 4.7

  • Claude Opus 4.7 ของ Anthropic ระบุว่าใช้โทเคนมากกว่ารุ่นก่อนหน้า 4.6 ที่ 1.0~1.35 เท่า แต่จากการวัดจริงพบว่าอยู่ที่ระดับ 1.45~1.47 เท่า
  • เมื่อจำนวนโทเคนเพิ่มขึ้นภายใต้ราคาและโควตาเดิม จึงเกิดผลกระทบอย่าง การใช้ max window เร็วขึ้น, ต้นทุนแคชพรีฟิกซ์สูงขึ้น, และ ชนเรตลิมิตเร็วขึ้น
  • การทดลองแบ่งเป็น 2 ส่วน คือการวัดต้นทุนและการวัดความสามารถในการทำตามคำสั่ง

วิธีวัดต้นทุน

  • ใช้เอนด์พอยต์ POST /v1/messages/count_tokens ของ Anthropic API ป้อนคอนเทนต์เดียวกันให้โมเดล 4.6 และ 4.7 ตามลำดับ เพื่อเปรียบเทียบเฉพาะความต่างของโทเคไนเซอร์
  • ใช้ชุดตัวอย่าง 2 แบบ
    • ตัวอย่างการใช้งานจริง 7 ชุดที่ผู้ใช้ Claude Code ส่งมา
    • ตัวอย่างสังเคราะห์ 12 ชุด เช่น ภาษาอังกฤษ โค้ด ข้อมูลมีโครงสร้าง CJK อีโมจิ และสัญลักษณ์ทางคณิตศาสตร์

  • ผลลัพธ์จากคอนเทนต์ Claude Code จริง

    • ค่าเฉลี่ยถ่วงน้ำหนักของตัวอย่างใช้งานจริง 7 ชุดอยู่ที่ 1.325 เท่า (8,254 → 10,937 โทเคน)
    • ตัวอย่างสำคัญ
    • ไฟล์ CLAUDE.md: 1.445 เท่า
    • พรอมป์ต์ผู้ใช้: 1.373 เท่า
    • บล็อกโพสต์: 1.368 เท่า
    • code diff: 1.212 เท่า

  • ผลลัพธ์ตามประเภทคอนเทนต์ (ตัวอย่างสังเคราะห์ 12 ชุด)

    • ค่าเฉลี่ยของคอนเทนต์ภาษาอังกฤษและโค้ด: 1.345 เท่า
    • ค่าเฉลี่ยของคอนเทนต์ CJK (จีน·ญี่ปุ่น·เกาหลี): 1.01 เท่า
    • ตัวอย่างรายละเอียด
    • เอกสารเทคนิค: 1.47 เท่า
    • Shell script: 1.39 เท่า
    • โค้ด TypeScript: 1.36 เท่า
    • ร้อยแก้วภาษาอังกฤษ: 1.20 เท่า
    • JSON: 1.13 เท่า
    • ร้อยแก้วภาษาญี่ปุ่น·จีน: 1.01 เท่า

รูปแบบการเปลี่ยนแปลงของโทเคไนเซอร์

  • คอนเทนต์ CJK อีโมจิ และสัญลักษณ์ อยู่ที่ระดับ 1.005~1.07 เท่า แทบไม่เปลี่ยนแปลง
    • ดูเหมือนว่าคำศัพท์ที่ไม่ใช่อักษรละตินแทบไม่ได้เปลี่ยนแปลงมาก
  • คอนเทนต์ภาษาอังกฤษและโค้ดเพิ่มขึ้น 1.20~1.47 เท่า โดยโค้ดได้รับผลกระทบมากกว่าร้อยแก้ว
    • สตริงซ้ำในโค้ด (คีย์เวิร์ด, import, identifier ฯลฯ) ถูกแยกละเอียดขึ้นจนแตกเป็นโทเคนมากขึ้น
  • อัตราโทเคนต่ออักขระของภาษาอังกฤษลดลงจาก 4.33→3.60 และของ TypeScript ลดลงจาก 3.66→2.69
    • หมายความว่าข้อความเดียวกันถูกแยกเป็นหน่วยย่อยกว่าเดิมเพื่อใช้แทน

เหตุผลที่ใช้โทเคนมากขึ้น

  • Anthropic เน้นย้ำว่าใน 4.7 โมเดลมี “แนวโน้มที่จะทำตามคำสั่งแบบตรงตัวมากขึ้น”
  • หน่วยโทเคนที่เล็กลงช่วยเสริม attention ระดับคำ (word-level attention) และมีส่วนช่วยให้ การทำตามคำสั่งได้แม่นยำ, งานระดับอักขระ, และความแม่นยำของการเรียกใช้เครื่องมือ ดีขึ้น
  • พันธมิตรอย่าง Notion, Warp และ Factory รายงานว่า ข้อผิดพลาดในการใช้เครื่องมือลดลง
  • อย่างไรก็ตาม นอกจากการโทเคไนซ์แล้ว ยังมีการเปลี่ยน น้ำหนักโมเดลและ post-training ด้วย จึงแยกสาเหตุอย่างเด็ดขาดไม่ได้

การทดสอบความสามารถในการทำตามคำสั่ง

  • ใช้ IFEval benchmark (2023, Google): ทดสอบตัวอย่าง 20 ชุดจากพรอมป์ต์ 541 รายการ เช่น “ตอบให้มี N คำพอดี”, “เขียนโดยไม่ใช้เครื่องหมายจุลภาค”
  • ผลลัพธ์
    • strict mode ระดับพรอมป์ต์: 4.6 → 85%, 4.7 → 90% (+5pp)
    • strict mode ระดับคำสั่ง: 86% → 90% (+4pp)
    • ใน loose mode ไม่พบความต่าง
  • การปรับปรุงหลักมาจาก การลดข้อผิดพลาดที่เกี่ยวข้องกับรูปแบบ (formatting)
  • พบความต่างชัดเจนเฉพาะในพรอมป์ต์เดี่ยว (change_case:english_capital)
  • เนื่องจากขนาดตัวอย่างเล็ก (+5pp จึงยังไม่แน่นอนทางสถิติ) จึงประเมินว่าเป็น การปรับปรุงเล็กน้อยแต่สม่ำเสมอ

การคำนวณต้นทุนต่อเซสชันของ Claude Code

  • สมมติเป็นเซสชันสนทนาโต้ตอบ 80 รอบ
    • สแตติกพรีฟิกซ์: 6K โทเคน (CLAUDE.md 2K + คำจำกัดความของเครื่องมือ 4K)
    • ประวัติการสนทนา: เพิ่มรอบละ 2K และแตะ 160K ที่รอบที่ 80
    • อินพุต/เอาต์พุต: 500 / 1,500 โทเคนต่อรอบ
    • อัตรา cache hit: 95%

  • ต้นทุนต่อเซสชันบน 4.6

    • | รายการ | การคำนวณ | ต้นทุน |
    • | --- | --- | --- |
    • | เขียนแคชครั้งแรก | 8K × $6.25/MTok | $0.05 |
    • | อ่านแคช (79 ครั้ง) | 79 × 86K × $0.50/MTok | $3.40 |
    • | อินพุตใหม่ | 79 × 500 × $5/MTok | $0.20 |
    • | เอาต์พุต | 80 × 1,500 × $25/MTok | $3.00 |
    • | รวม | | ประมาณ $6.65 |

  • ต้นทุนต่อเซสชันบน 4.7

    • CLAUDE.md: 1.445 เท่า → 2K → 2.9K
    • คำจำกัดความของเครื่องมือ: 1.12 เท่า → 4K → 4.5K
    • ประวัติการสนทนา: 1.325 เท่า → 160K → 212K
    • อินพุตผู้ใช้: 1.325 เท่า → 500 → 660
    • ค่าเฉลี่ยแคชพรีฟิกซ์: ราว 115K โทเคน
    • | รายการ | การคำนวณ | ต้นทุน |
    • | --- | --- | --- |
    • | เขียนแคชครั้งแรก | 10K × $6.25/MTok | $0.06 |
    • | อ่านแคช (79 ครั้ง) | 79 × 115K × $0.50/MTok | $4.54 |
    • | อินพุตใหม่ | 79 × 660 × $5/MTok | $0.26 |
    • | เอาต์พุต | 80 × 1,500–1,950 × $25/MTok | $3.00–$3.90 |
    • | รวม | | ประมาณ $7.86–$8.76 |
    • ต้นทุนต่อเซสชันเพิ่มขึ้น 20~30% โดยไม่ได้มีการเปลี่ยนแปลงราคาโทเคนต่อหน่วย
    • ผู้ใช้แพ็กเกจ Max จะ จบเซสชันได้เร็วขึ้น ภายในหน้าต่างเวลาเดียวกัน

ผลกระทบต่อ prompt cache

  1. เนื่องจาก แคชแยกตามโมเดล เมื่อเปลี่ยนไปใช้ 4.7 แคชเดิมของ 4.6 จะใช้ไม่ได้
    • เซสชันแรกจึงเริ่มต้นแบบไม่มีแคช และมีต้นทุนพรีฟิกซ์ที่สูงขึ้น
  2. ปริมาณแคชเองเพิ่มขึ้น 1.3~1.45 เท่า ทำให้ทั้งการอ่านและเขียนเพิ่มขึ้นในสัดส่วนเดียวกัน
  3. แม้จะเป็นล็อกการสนทนาเดียวกัน จำนวนโทเคนก็เปลี่ยนไป ทำให้ตัวเลขการคิดค่าบริการและการมอนิเตอร์เกิดความไม่ต่อเนื่องเมื่อเทียบกับอดีต

ข้อโต้แย้งและการตีความ

  • “อินพุตส่วนใหญ่เป็นการอ่านแคช เลยแทบไม่มีผล”

    • หากอัตรา cache hit สูง ผลกระทบด้านต้นทุนอาจน้อย แต่เมื่อเกิด TTL หมดอายุ, แคชถูกล้าง, หรือเปลี่ยนโมเดล ต้นทุนจะเพิ่มขึ้นตามสัดส่วนทั้งหมด

  • “1.35 เท่าไม่ใช่เพดาน แต่เป็นช่วง”

    • ค่าที่วัดได้จริงกระจุกใกล้เพดาน (1.325 เท่า) และบางไฟล์สูงกว่านั้น
    • ในการใช้งานจริง ควรวางแผนโดยอิงเพดาน เพื่อความปลอดภัย

บทสรุป

  • ในงานที่เน้นภาษาอังกฤษและโค้ด การใช้โทเคนเพิ่มขึ้น 1.3~1.45 เท่า
  • ความสามารถในการทำตามคำสั่งดีขึ้นราว +5pp แม้ไม่มากแต่ถือว่าดีขึ้นอย่างมีนัยในทางปฏิบัติ
  • ต้นทุนต่อเซสชันเพิ่มขึ้น 20~30% โดยราคาโทเคนต่อหน่วยเท่าเดิม
  • โดยสรุป จึงถูกประเมินว่าเป็นโครงสร้างที่ จ่ายต้นทุนเพิ่ม เพื่อแลกกับ ความแม่นยำที่สูงขึ้นและการทำตามคำสั่งที่ละเอียดกว่าเดิม

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

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

 
kaydash 11 일 전

ไม่ใช่ Claude 4.7 แต่เป็น Opus 4.7
 
GN⁺ 12 일 전
ความคิดเห็นจาก Hacker News

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

    • อ้างอิง การวิเคราะห์ต้นทุนต่อชั่วโมงของ AI เอเจนต์ ของ Toby Ord แนวคิดเรื่อง ประสิทธิภาพ/ต้นทุนฟรอนเทียร์ ของเขาควรได้รับความสนใจมากกว่านี้
    • ตอนนี้ถึงเวลาที่นักพัฒนาควร ปรับขนาดให้เหมาะสม (right-sizing) ทั้งขนาดโมเดลและระดับความพยายามให้เข้ากับงานแล้ว
      ยุคที่ใช้แต่โมเดลที่ดีที่สุดเสมอได้จบลงไปแล้ว จำเป็นต้องมีตัวเลือกหลายระดับให้เลือกตามลักษณะงาน
      สำหรับงานซับซ้อน การใช้โมเดลใหญ่และใช้โทเค็นรวดเดียว 5 ชั่วโมงก็อาจยอมรับได้
      แต่หลายคนก็คงไม่ชอบความซับซ้อนในการเลือกแบบนี้ และคาดว่าในอนาคตจะมีความพยายามด้าน smart routing เพิ่มขึ้น
    • Anthropic กำลังจะ IPO จึงมีแรงกดดันสูงเรื่อง การเพิ่มรายได้ต่อผู้ใช้ สุดท้ายจึงกำลังเดินไปสู่โครงสร้างราคาที่สะท้อนต้นทุนการรันโมเดลจริง
    • ถ้าโมเดลถูก ทำลงบนซิลิคอนโดยตรง ต้นทุนจะลดลงและความเร็วจะเพิ่มขึ้น ลองดูแนวทางอย่าง Taalas ได้
    • ถ้าลูกค้ายินดีรับต้นทุนที่สูงกว่า ก็น่าจะมีตลาดสำหรับโมเดลที่ทรงพลังกว่านี้มากได้
      เช่นเดียวกับที่มีลูกค้ากลุ่มหนึ่งต้องการตัวเลือกระดับแพงมากแบบ Apple ตลาด LLM สมรรถนะสูงพิเศษ ก็อาจเป็นไปได้

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

    • ทีมของเราเปิดตัวผลิตภัณฑ์ไป 3 ตัวในปีนี้ด้วย Claude โดยเฉพาะโปรเจกต์หนึ่งที่เดิมคาดว่า 9 คนใช้เวลา 6 เดือน กลับจบได้ด้วยคน 2 คนใน 2 เดือน
      มองว่า มูลค่าทางเศรษฐกิจ ของการสมัคร Claude อยู่ราว 10,000–40,000 ยูโร
      ต่อให้ราคาขึ้น 100 เท่าก็ยังซื้ออยู่ แม้ถ้าถึง 20,000 ยูโร/เดือนคงเริ่มมองหาทางเลือก แต่ตอนนี้ การเพิ่มผลิตภาพ ยังเหนือกว่ามาก
    • $200 สำหรับองค์กรแทบไม่เป็นภาระ แต่สำหรับงานอดิเรกส่วนบุคคลก็ยากจะอธิบายความคุ้มค่า
    • อินสแตนซ์ Openclaw ของฉันโดนคิดเงินวันละ $200 เพราะใช้ Opus ปัญหาใหญ่กว่าคือ การทำ routing ให้เหมาะสม ตอนอยู่ที่ $1/ชั่วโมงยังดี แต่ถ้าเป็น $15/ชั่วโมงก็เริ่มไม่คุ้มในการแข่งขัน

  • คิดว่าการยกระดับคุณภาพโมเดลสุดท้ายจะเข้าสู่ช่วง ผลตอบแทนลดลง
    เหมือนจอ 8K เทียบกับ 16K ที่ผู้ใช้ส่วนใหญ่แทบไม่รู้สึกถึงความต่าง
    ถ้าต้นทุนเพิ่มขึ้น 20–30% ก็ต้องมี คุณค่าที่มองเห็นได้ชัด เพิ่มขึ้นตามนั้น

    • นี่จึงเป็นเหตุผลว่าทำไมงานวิจัยส่วนใหญ่ถึงมุ่งไปที่ สายโค้ดดิ้ง เพราะระดับความยากยังสูงขึ้นต่อเนื่องและยังมีมูลค่าทางเศรษฐกิจรองรับ
      ในทางกลับกัน งานถามตอบเชิงสนทนาทั่วไปนั้นแทบ อิ่มตัว แล้ว จึงแยกความต่างระหว่างโมเดลได้ยาก
    • ต่อให้ดูเหมือนแม่นยำ 99% แต่ถ้าต้องตัดสินใจวันละ 100,000 ครั้ง ความคลาดเคลื่อนเล็กน้อยก็สะสมจนกลายเป็นปัญหาใหญ่ได้
    • ถ้ามี โมเดล 4K ที่รันในเครื่องได้จริง ห้องแล็บขนาดใหญ่คงลำบาก แม้ Google น่าจะยังอยู่ได้เพราะมีรายได้จากโฆษณา
    • มันขึ้นอยู่กับประเภทของงาน เช่น ในการออกแบบยา ความต่างระหว่างความสมบูรณ์ 95% กับ 100% อาจแปลเป็น มูลค่าที่ต่างกันหลายสิบเท่า
    • สำหรับการค้นเว็บหรือสรุปความ ตอนนี้อาจใกล้ชนเพดานแล้ว แต่ ความซับซ้อนของงานเขียนโค้ด ยังขยายต่อได้ไม่สิ้นสุด

  • ตัวคูณโมเดล (multiplier) ของ GitHub Copilot เพิ่มจาก 3 เป็น 7.5
    ดูเหมือนเป็นความพยายามของ Microsoft ในการลดการขาดทุน
    ดู เอกสารทางการ

    • เพราะแบบนี้เราจึงแนะนำในองค์กรว่า “อย่าเปิด Opus 4.7 เด็ดขาด” 4.6 (3x) กับ 4.5 (3x) ยังพอได้ แต่ 4.7 (7.5x) นั้น ไม่คุ้มค่าเลย
    • ช่วงหลัง Opus 4.6 มี คุณภาพการให้เหตุผลลดลง รีบสรุปข้ามขั้นตอน และละตรรกะไป ถ้าไม่มีความก้าวหน้าใหญ่จริง ๆ ก็ดูเหมือนว่า คุณภาพเสื่อมถอย(en**)** แบบรวดเร็วอาจกำลังมา

  • พาดหัวข่าวทำให้เข้าใจผิด จำนวนโทเค็นเพิ่มขึ้นก็จริง แต่ ต้นทุนต่อหนึ่งงาน อาจไม่เหมือนเดิม
    สมมติว่า Opus 4.7 ไม่ได้ใช้เส้นทางการให้เหตุผลเดียวกับ Opus 4.6
    คงต้องรอดูผลจาก Intelligence Index ของ Artificial Analysis

    • ในเบนช์มาร์กภายใน Opus 4.7 ถูกกว่า 50% และได้คะแนนประสิทธิภาพ 80% (เทียบกับ 60%)
    • ได้แก้ชื่อบทความจาก “Claude Opus 4.7 costs 20–30% more per session” ให้เป็นกลางขึ้นแล้ว
    • จากผล การทดลองเปรียบเทียบ 28 งาน 4.7 มีต้นทุนใกล้กับ 4.6 เวอร์ชันเก่า และแพงกว่า 4.6 เวอร์ชันใหม่ราว 20%
    • จากข้อมูลส่วนตัวของฉัน 4.7 มีต้นทุนสูงกว่า 4.6 และก็ยังไม่ชัดว่าประสิทธิภาพดีขึ้นหรือไม่
    • แม้แต่ใน กราฟประกาศทางการ ก็ยังพอเห็นเหตุผลรองรับคำกล่าวอ้างว่า “strictly better”

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

    • นี่ไม่ใช่บั๊ก แต่เป็น นโยบายลดปริมาณการคำนวณ และต่อจากนี้น่าจะแย่ลงอีก
    • LLM ไม่ใช่บุคลิกหรือคนจริง เมื่อสุ่มจากการกระจายความน่าจะเป็น ก็มีโอกาส 100% ที่จะเกิด เซสชันแย่ ๆ ขึ้นมา ต้องล้างคอนเท็กซ์แล้วลองใหม่
    • ช่วงหลังฉันก็เจอ Opus 4.7 ให้ ผลลัพธ์เละเทะ บ่อยเหมือนกัน เห็นมันยอมรับเองว่าผิดแล้วลองใหม่ก็รู้สึกขมขื่นอยู่หน่อย ๆ

  • ช่วงนี้คิดบ่อยว่า “เราจำเป็นต้องมีโมเดลที่แรงขึ้นจริงหรือ?”
    ทั้งอุตสาหกรรมกำลังหมกมุ่นกับ การแข่งขันด้านสมรรถนะ จนมองข้าม ประสิทธิภาพ และ ความยั่งยืน
    ต่อไปทิศทางสำคัญน่าจะเป็นการ ปรับให้เหมาะกับงานเฉพาะ ของโมเดลขนาด 0.5B–1B พารามิเตอร์

    • ถ้าฉันสามารถรัน Sonnet 4.6 แบบโลคัลได้ก็คงพอใจมากแล้ว
      อย่างที่บทความ CPUs Aren’t Dead บอกไว้ โมเดล Gemma 4 E2B ของ Google รันบนมือถือได้และยังเหนือกว่า GPT-3.5-turbo
      ตาม Intelligence Index ของ Artificial Analysis โมเดล 2B รุ่นล่าสุดให้ประสิทธิภาพใกล้เคียงกับโมเดล 175B เมื่อ 3–4 ปีก่อน
      และ Gemma 4 E4B บางครั้งยังเหนือกว่า GPT-4o ด้วย
      ถ้าแนวโน้มนี้ดำเนินต่อไป ไม่นานก็คงรัน โมเดลระดับท็อปบนโน้ตบุ๊ก ได้
    • หลายคนคาดหวังว่า Sonnet 4.6 จะให้ประสิทธิภาพระดับ Opus 4.5 แต่ความจริงไม่เป็นแบบนั้น
    • ประสิทธิภาพทำเงินไม่ได้ บริษัท LLM รายใหญ่ได้ประโยชน์จากการ คงต้นทุน inference ให้แพงไว้
      การโหมโปรโมตแนว “โมเดลใหม่มันบ้าคลั่งมาก” สุดท้ายก็เป็นแค่การตลาดแบบ FOMO
    • ไม่ใช่ทุกคนที่ต้องการเครื่องคิดเลขระดับสูง สิ่งสำคัญคือการเลือก เครื่องมือในระดับที่จำเป็น
    • แต่ก็ไม่อาจพอใจกับ “โมเดลที่ขี้เกียจและไม่แม่นยำ” ได้ ถ้าแล็บไหนแก้ปัญหานี้ได้ ก็จะได้เปรียบแบบ ชี้ขาด

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

    • คล้ายกันทั่วโลก บรรจุภัณฑ์ขนมยังเท่าเดิมแต่ของข้างในน้อยลง แม้แต่ กระป๋อง Pringles ก็ยังบางลงและสั้นลง
    • ปรากฏการณ์นี้เรียกว่า Shrinkflation

  • Anthropic เพิ่ม โหมด xhigh ใหม่ใน 4.7
    โหมด max ใช้โทเค็นมากและอาจทำให้เกิดการใช้เหตุผลมากเกินไป จึงแนะนำให้ใช้ xhigh ในกรณีส่วนใหญ่
    ดู เอกสารทางการ

    • การเพิ่มระดับ xhigh แล้วดัน max ออกไปไกลขึ้น ให้ความรู้สึกเหมือน “อันนี้หมุนได้ถึง 11 เลยนะ”

  • จากโค้ดจริง Opus 4.7 แสดงให้เห็นว่าโทเค็นเพิ่มขึ้นราว 30%
    สิ่งสำคัญคือ “4.7 มอบความสามารถใหม่อะไรเมื่อเทียบกับ 4.6”
    ยังเร็วเกินไปที่จะตัดสิน และถ้ามันคุ้มค่า ก็อาจยอมรับต้นทุนที่เพิ่มขึ้นได้

    • ประเด็นน่าสนใจในการประชุมคือ หลายคนไล่ตามโมเดลใหม่ แต่จริง ๆ แล้ว Sonnet 4.6 ก็มีประสิทธิภาพเพียงพอ อยู่แล้ว
      ถ้าจำกัดขอบเขตงานให้แคบลง ก็จะรีวิวและจัดการได้ง่ายขึ้น และแก้ได้เร็วด้วย diff ขนาดเล็ก
      ถ้า Copilot ใช้โทเค็นมากขึ้น 7 เท่า กลับรู้สึกว่าน่าจะทำให้ เวิร์กโฟลว์สะดุด เสียมากกว่า
    • ช่วงนี้มีคนบ่นเยอะว่า 4.6 ประสิทธิภาพตกลง
    • ไม่แน่ใจว่า 4.6 จะถูกคงไว้ได้นานแค่ไหน ฝั่งองค์กรอาจอยู่ต่ออีกหน่อย แต่ผู้สมัครใช้งานรายบุคคลน่าจะหมดสิทธิ์เลือกในไม่ช้า