วิเคราะห์โครงสร้างสัญญา · TH-AI Passport

รัฐจ่ายค่าบุฟเฟต์ 5 ล้านที่นั่ง
แต่ลืมเขียนว่าแต่ละคนกินได้เท่าไร

โครงการ 1,600 ล้านบาท ที่ปมไม่ได้อยู่ที่ "แพงไป" แต่อยู่ที่วิธีเขียนสัญญา ซึ่งออกแบบให้ผู้รับงานการันตีกำไรได้ และหมุนปุ่มปรับกำไรเองได้ด้วย

เลื่อนลงเพื่ออ่าน ↓
01 — สองวิธีจ่ายเงิน

ร้านคิดตามจาน กับ ร้านบุฟเฟต์ ต่างกันตรงไหน

ลองนึกถึงร้านอาหารสองแบบ มันคือหัวใจของเรื่องทั้งหมด

ร้านคิดตามจาน

จ่ายตามที่กินจริง

รายรับ สั่งเยอะจ่ายเยอะ สั่งน้อยจ่ายน้อย
ต้นทุน ขยับขึ้น–ลงไปพร้อมกับรายรับ
กำไร ส่วนต่างต่อจานคงที่ คาดเดาได้
ร้านบุฟเฟต์รายหัว

จ่ายเหมาต่อหัว

รายรับ ล็อกที่จำนวนหัว จ่ายเท่ากันเสมอ
ต้นทุน รายรับนิ่ง แต่ต้นทุนวิ่งอิสระตามที่กิน
กำไร ขึ้นกับ "คนมากินจริง" และ "กินได้เร็วแค่ไหน"

โครงการ TH-AI Passport เซ็นสัญญาแบบร้านบุฟเฟต์ รัฐจ่ายเหมาให้ประชาชน 5 ล้านที่นั่ง ส่วนต้นทุนจริงของผู้รับงานคือปริมาณ token ที่ AI ประมวลผล ซึ่งคิดเงินตามการใช้งานจริง

ช่องว่างระหว่าง "รายรับที่ล็อกไว้" กับ "ต้นทุนที่แปรผัน" — คือที่ที่กำไรไปกอง

02 — รายรับล็อก ต้นทุนลอย

รายการเดียวในงบ ใหญ่กว่าโครงการส่วนใหญ่ทั้งโครงการ

0 ล้านบาท

= รายการ "ระบบ Generative AI" รายการเดียว

รัฐคิดงบแบบ "รายหัว" ตั้งเป้า 5,000,000 คน ใช้ฟรี 12 เดือน แล้วตั้งงบก้อนนี้ให้ผู้รับงาน เท่ากับจ่ายราว 300 บาท/คน/ปี (≈25 บาท/เดือน) โดยอ้างว่าไปทดแทนค่าบริการจริงราว 600 บาท/เดือน

รายรับผู้รับงาน
ล็อกแล้ว
ได้เท่าเดิม ไม่ว่าคนใช้ 5 ล้านหรือ 5 แสน
ต้นทุน token จริง
ลอยตัว
คิดตามการใช้งานจริง ~$1–25 / ล้าน token
ความเสี่ยง "คนใช้ไม่ถึงเป้า"
รัฐแบก
ฝ่ายเดียว
03 — ลองเล่นตัวเลขเอง

คนใช้ยิ่งน้อย กำไรส่วนต่างยิ่งพอง

เลื่อนแถบดูว่าเมื่อคนใช้จริงไม่ถึงเป้า หรือใช้งานเบา ส่วนต่าง (แถบแดง) กินพื้นที่ขึ้นเรื่อย ๆ อย่างไร — กำไรไม่ได้มาจากการทำงานเพิ่ม แต่มาจากการที่คน "ไม่มาใช้"

รายรับที่รัฐจ่าย (ล็อกแล้ว)
1,500
ล้านบาท · เหมาจ่าย
ต้นทุน token โดยประมาณ
ล้านบาท · แปรตามการใช้
ส่วนต่างเข้ากระเป๋า
ลากแถบด้านล่างเพื่อลองเปลี่ยนตัวเลขเอง
0.3 ล้านคน
5%
0%
ต้นทุน token จริงกำไรส่วนต่างที่การันตีไว้

ความสัมพันธ์: ยิ่งคนใช้น้อย ส่วนต่างยิ่งโต

แกนนอน = สัดส่วนผู้ใช้จริง · แกนตั้ง = เงิน 1,500 ล้านบาทถูกแบ่งเป็นต้นทุนกับส่วนต่าง (เส้นประ = จุดที่คุณตั้งไว้ตอนนี้)
ต้นทุน token จริง กำไรส่วนต่าง
04 — วาล์วกันขาดทุน

ถ้าคนแห่มาเยอะ ก็แค่ "เสิร์ฟช้าลง"

ในร้านบุฟเฟต์ ถ้าคนแน่นร้าน เจ้าของก็เติมของช้าลง ลูกค้ากินได้น้อยลงต่อหัว ต้นทุนถูกคุม — ในโลก AI ทำแบบเดียวกันได้ผ่านการบีบอัตรา token/วินาที ลองเลื่อนแถบ "จำนวนคนใช้พร้อมกัน" ดู

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

ที่อันตรายคือ TOR เปิดช่องให้ผู้รับงานหมุนปุ่มเหล่านี้ได้เอง

กำหนดโควตาเครดิตเอง

ตั้งเครดิต/โควตา token ต่อกลุ่มผู้ใช้ (Tier) ได้ตามใจ

เปิด–ปิดโมเดลแพง

ดันคนไปใช้โมเดลถูก (Haiku) แทนโมเดลแพง (Opus) โดยผู้ใช้แทบไม่รู้ตัว

SLA วัดแค่ "ระบบล่ม"

วัด downtime ≤216 นาที/เดือน แต่ไม่วัดความเร็วหรือจำนวน token ที่ผู้ใช้ได้จริง

05 — ทั้งวงการรู้ดี

โมเดลเหมาจ่ายแบบนี้ ทุกเจ้ากำลังวิ่งหนี

ประเด็นนี้ไม่ใช่ทฤษฎี ทั้งอุตสาหกรรม AI พิสูจน์แล้วว่า "เหมาจ่ายไม่จำกัด" ทำให้ผู้ให้บริการขาดทุนเมื่อเจอผู้ใช้หนัก — แต่สัญญานี้กลับวางผู้รับงานไว้ฝั่งที่ได้เปรียบ

OpenAI ยอมรับว่าขาดทุนกับแพ็กเกจ Pro เพราะผู้ใช้หนักบางคนใช้ทะลุ 20,000 query/เดือน จึงตอบโต้ด้วยการ throttle และดันคนไป pay-as-you-go
รายงานอุตสาหกรรม 2025
GitHub Copilot ประกาศย้ายไปคิดเงินตามการใช้จริง ตั้งแต่ 1 มิ.ย. 2026 เพราะโมเดลเหมาจ่ายพังเมื่อเจอภาระงานหนัก
ข่าวอุตสาหกรรม 2026
เงื่อนไข fair-use และการจำกัดอัตราเป็นมาตรฐานในสัญญาเหมาจ่าย และมักซ่อนอยู่ในเงื่อนไขที่ไม่มีใครอ่าน ต้องถามเป็นลายลักษณ์อักษรว่าเกินเท่าไรจะโดนลดบริการ
คำแนะนำการจัดซื้อ AI
แม้แต่ Anthropic ก็เป็นเจ้าแรกที่ประกาศเลิกที่นั่งแบบเหมาจ่ายสำหรับองค์กร เพราะต้นทุนจริงเกินราคาที่ตั้งไว้
รายงานอุตสาหกรรม 2026
06 — ทางออก

ปิดช่องโหว่ด้วยตัวเลขในสัญญา

ช่องว่างทั้งหมดนี้ปิดได้ด้วยการ ระบุปริมาณ token ขั้นต่ำที่การันตีต่อคนต่อโมเดล ลงในสัญญาให้ชัด พร้อมเปลี่ยนไปจ่ายตามการใช้งานจริง (pay-per-use) แทนการเหมาจ่ายล่วงหน้า — ซึ่งสอดคล้องกับทิศทางที่ทั้งอุตสาหกรรมกำลังเปลี่ยนไป

ระบุ token ขั้นต่ำ/คน/โมเดล วัด SLA ที่ความเร็ว ไม่ใช่แค่ระบบล่ม จ่ายตามการใช้จริง เปิดเผยเกณฑ์ throttle

ตราบใดที่ตัวเลขนี้ยังว่างอยู่ใน TOR สัญญานี้ก็เท่ากับการเซ็นเช็คเปล่าที่ผู้รับงานเป็นคนกรอกกำไรเอง