Contact
Line : comsiam
Contact
Line : comsiam

Gemini API มีทั้ง Free Tier และ Paid Tier โดยค่าใช้จ่ายไม่ได้คิดเป็นค่ารายเดือนแบบตายตัว แต่โดยทั่วไปคิดตามปริมาณการใช้งานจริง เช่น จำนวน Input Tokens, Output Tokens, Thinking Tokens, Cached Tokens และเครื่องมือเพิ่มเติมที่เรียกใช้ เช่น Google Search, Google Maps, Image, Audio หรือ Video
ราคายังแตกต่างกันตาม Model และ Processing Mode ที่เลือก เช่น Standard, Batch, Flex และ Priority ดังนั้นคำถามว่า “Gemini API ราคาเท่าไร” จึงไม่มีคำตอบเป็นตัวเลขเดียวสำหรับทุก Application
ตัวอย่างสำคัญ ณ วันที่ 2 กันยายน 2026 คือ gemini-3.7-flash แบบ Standard Paid Tier มีราคา Input $0.75 ต่อ 1 ล้าน Tokens และ Output $3.75 ต่อ 1 ล้าน Tokens จนถึงวันที่ 31 ธันวาคม 2026 โดย Google ประกาศว่าตั้งแต่วันที่ 1 มกราคม 2027 ราคาจะเปลี่ยนเป็น Input $1.50 และ Output $7.50 ต่อ 1 ล้าน Tokens
ดังนั้นก่อนสร้างระบบจริงควรคิดต้นทุนด้วยสูตร
ค่าใช้จ่าย
=
Input
+
Output
+
Caching
+
Tools
+
Media
+
Infrastructure อื่น
ไม่ควรดูเฉพาะราคา Input Token อย่างเดียว
Gemini API มี Free Tier สำหรับ Developer และ Project ขนาดเล็กตามโมเดลและ Limit ที่ Google กำหนด
Free Tier เหมาะกับ
Google ระบุว่า Free Tier มี
แต่ Free Tier ไม่ได้หมายความว่า
ใช้งานไม่จำกัด
แต่ละโมเดลมีข้อจำกัดต่างกัน
Paid Tier เหมาะกับระบบ Production ที่ต้องการ
เมื่อเปิด Paid Tier ระบบจะคิดค่าบริการตาม Usage จริง
ตัวอย่าง
วันนี้ใช้ 100,000 Tokens
↓
จ่ายตาม 100,000 Tokens
ไม่ใช่
จ่าย Package 1 เดือน
แล้วใช้ไม่จำกัด
Token คือหน่วยที่โมเดลใช้ประมวลผลข้อความและข้อมูล
ตัวอย่างประโยค
Gemini API ช่วยสร้าง AI Application
ไม่ได้หมายความว่า 1 ตัวอักษร = 1 Token
การแบ่ง Token ขึ้นกับ Tokenizer และข้อมูลที่ส่ง
ดังนั้นควรใช้ Token Count จาก API หรือเครื่องมือของ Google เมื่อจะประมาณค่าใช้จ่ายจริง
Input Token คือข้อมูลที่ส่งเข้า Gemini
อาจประกอบด้วย
ตัวอย่าง
System Prompt
+
User Prompt
+
Conversation History
=
Input
ยิ่งส่ง Context มาก ค่า Input ก็สามารถเพิ่มขึ้น
Output Token คือข้อมูลที่ Gemini สร้างกลับมา
เช่น
คำตอบ
บทความ
JSON
Code
Summary
ถ้าสั่ง
ตอบ 1 ประโยค
มักใช้ Output น้อยกว่า
เขียนบทความ 5,000 คำ
ดังนั้นการจำกัด Output ให้ตรงกับงานช่วยลดต้นทุนได้
สำหรับโมเดลที่ใช้ Thinking หรือ Reasoning Google ระบุราคา Output ว่า
รวม Thinking Tokens
ดังนั้นค่าใช้จ่ายไม่ได้ดูเฉพาะข้อความที่ User มองเห็นเท่านั้น
หากโมเดลใช้การ Reasoning มากขึ้น Total Output Token Billing สามารถเพิ่มขึ้นตาม Pricing ของ Model
นี่เป็นเหตุผลว่าทำไมงานง่ายไม่จำเป็นต้องใช้ Reasoning สูงสุดทุกครั้ง
ณ วันที่ 2 กันยายน 2026 ราคา Standard Paid Tier ของ
gemini-3.7-flash
คือ
| ประเภท | ราคาถึง 31 ธ.ค. 2026 | ตั้งแต่ 1 ม.ค. 2027 |
|---|---|---|
| Input | $0.75 / 1M tokens | $1.50 / 1M tokens |
| Output รวม Thinking | $3.75 / 1M tokens | $7.50 / 1M tokens |
| Cached Input | $0.075 / 1M tokens | $0.15 / 1M tokens |
| Cache Storage | $0.50 / 1M tokens/ชั่วโมง | $1.00 / 1M tokens/ชั่วโมง |
จุดสำคัญคือราคาปัจจุบันมีช่วง Promotional Pricing ก่อนปรับวันที่ 1 มกราคม 2027
ดังนั้นถ้ากำลังวาง Business Model สำหรับปี 2027 ไม่ควรใช้ราคา $0.75/$3.75 ไปคำนวณต้นทุนระยะยาวโดยไม่คิดราคาที่ประกาศใหม่ด้วย
สมมติ Request หนึ่งมี
Input = 2,000 tokens
Output = 500 tokens
ราคา ณ ช่วงปัจจุบันคือ
Input:
2,000 / 1,000,000 × $0.75
Output:
500 / 1,000,000 × $3.75
เท่ากับประมาณ
Input = $0.0015
Output = $0.001875
รวมประมาณ
$0.003375 ต่อ Request
ยังไม่รวม
ถ้ามี Feature เหล่านี้
ใช้ค่าเฉลี่ยเดิม
$0.003375 × 10,000
ประมาณ
$33.75 ต่อวัน
หรือประมาณ
$1,012.50 ต่อ 30 วัน
นี่เป็นเพียงตัวอย่างเพื่อให้เข้าใจสูตร
ต้นทุนจริงขึ้นกับ Token Usage ของแต่ละ Request
User A อาจส่ง
100 tokens
User B อาจ Upload เอกสารยาว
100,000 tokens
ดังนั้น
1 Request
ไม่ใช่ Unit Cost ที่แม่นที่สุดเสมอไป
ควรติดตาม
Tokens per request
ควบคู่กับจำนวน Request
ตัวอย่าง Model อีกรุ่นคือ
gemini-3.5-flash
Standard Paid Tier ปัจจุบันมีราคา
| ประเภท | ราคา |
|---|---|
| Input | $1.50 / 1M tokens |
| Output รวม Thinking | $9.00 / 1M tokens |
| Cached Input | $0.15 / 1M tokens |
| Cache Storage | $1.00 / 1M tokens/ชั่วโมง |
ราคาสามารถเปลี่ยนในอนาคต จึงควรตรวจ Pricing Page ก่อนใช้ Production
สำหรับงานที่เน้น Volume และ Cost Efficiency มี
gemini-3.5-flash-lite
Standard Paid Tier ปัจจุบันคือ
| ประเภท | ราคา |
|---|---|
| Input | $0.30 / 1M tokens |
| Output รวม Thinking | $2.50 / 1M tokens |
| Cached Input | $0.03 / 1M tokens |
| Cache Storage | $1.00 / 1M tokens/ชั่วโมง |
เหมาะกับงานง่ายหรือ Volume สูงใน Use Case ที่คุณภาพของ Model รุ่นนี้เพียงพอ
เช่น
แต่ควร Benchmark คุณภาพจริงก่อนเลือกเพราะ Model ที่ถูกที่สุดไม่ได้หมายความว่าคุ้มที่สุดเสมอไป
สมมติ Model ราคาถูกต้อง Retry 3 ครั้งกว่าจะได้ผลถูก
เมื่อเทียบกับ Model ที่แพงกว่าแต่ตอบถูกครั้งเดียว
ต้นทุนรวมอาจกลับกัน
จึงควรวัด
Cost per successful task
ไม่ใช่เพียง
Cost per token
นี่เป็น Metric ที่เหมาะกับ Business มากกว่า
โดยทั่วไปใช่สำหรับ Model ที่รองรับ
Google ระบุว่า Paid Tier มี Batch API ที่สามารถลดต้นทุนประมาณ 50% จาก Standard Pricing ในหลาย Model
ตัวอย่าง gemini-3.7-flash จนถึงวันที่ 31 ธันวาคม 2026
Input $0.75
Output $3.75
Input $0.375
Output $1.875
ต่อ 1 ล้าน Tokens
เหมาะกับงานที่ไม่จำเป็นต้องตอบ User ทันที
เช่น
Workflow
Data
↓
Batch Job
↓
Gemini
↓
รอผล
↓
นำผลไปใช้
ถ้า User ต้องการคำตอบทันที Batch ไม่เหมาะ
Gemini API Pricing ปัจจุบันมี Processing Mode แบบ Flex สำหรับบาง Model
Flex เหมาะกับ Workload ที่ยอมรับการประมวลผลแบบยืดหยุ่นได้
ในบาง Model ราคาสามารถใกล้เคียง Batch
แลกกับ Processing Characteristics ที่ต่างจาก Standard
ควรเลือกตาม
ไม่ควรเลือกเพียงเพราะราคาต่ำ
Priority Processing เหมาะกับ Workload ที่ต้องการ Processing Priority ตามเงื่อนไขของ Google
ราคาสูงกว่า Standard
ตัวอย่าง gemini-3.7-flash ปัจจุบันจนถึง 31 ธันวาคม 2026
Priority Input
$1.35 / 1M tokens
Priority Output
$6.75 / 1M tokens
เทียบกับ Standard
$0.75
$3.75
ดังนั้นไม่ควรใช้ Priority ทุก Request หาก Application ไม่ต้องการคุณสมบัตินั้น
| Mode | เหมาะกับ |
|---|---|
| Standard | Request ทั่วไป |
| Batch | งานจำนวนมาก ไม่ต้องตอบทันที |
| Flex | Workload ที่ยืดหยุ่นเรื่องการประมวลผล |
| Priority | งานที่ต้องการ Processing Priority |
การเลือก Mode เป็นอีกวิธีหนึ่งในการ Optimize Cost
สมมติมีคู่มือขนาดใหญ่
100,000 tokens
และถามคำถาม 1,000 ครั้ง
หากส่ง Context เดิมทั้งหมดทุกครั้ง
100,000 × 1,000
Input Token จะสูงมาก
Context Caching ช่วยให้ Context ที่ใช้ซ้ำสามารถถูกคิดในราคาที่ต่ำกว่า Input ปกติเมื่อ Cache Hit ตาม Model และ API ที่รองรับ
สำหรับ Gemini 2.5 และรุ่นใหม่กว่า Google เปิด Implicit Caching โดยอัตโนมัติ
Developer ไม่ต้องเปิดเอง
ถ้า Request ตรงกับ Cache ระบบสามารถส่ง Cost Saving ให้โดยอัตโนมัติ
แนวทางเพิ่มโอกาส Cache Hit คือ
แต่ Cache Hit ไม่ได้รับประกันทุก Request
Explicit Caching คือ Developer สร้าง Cache Object และกำหนด TTL เอง
เหมาะกับข้อมูล เช่น
ค่าใช้จ่ายประกอบด้วย
Cached Token Usage
+
Cache Storage Time
ดังนั้น Cache ไม่ใช่ฟรี
ต้องคำนวณว่าการใช้ซ้ำมากพอที่จะคุ้มกับ Storage หรือไม่
Interactions API ปัจจุบันรองรับ Implicit Caching เท่านั้น
ถ้าต้องการสร้างและควบคุม Explicit Cache Object ด้วยตัวเอง Google ระบุให้ใช้ generateContent API ตาม Feature ปัจจุบัน
จุดนี้สำคัญมากก่อนออกแบบ Architecture
Gemini 3.x Paid Tier ปัจจุบันให้
5,000 Search Requests ฟรีต่อเดือน
โดยใช้ร่วมกันระหว่าง Gemini 3.x Models
หลังจากนั้น ราคาอยู่ที่
$14 ต่อ 1,000 Search Requests
ตาม Pricing ปัจจุบัน
แต่ต้องระวังว่า User Prompt หนึ่งรายการสามารถทำให้ Gemini สร้าง Search Query มากกว่าหนึ่งครั้ง
Google คิดตาม Search Query ที่ระบบดำเนินการ
ไม่ใช่เพียงจำนวน Prompt ที่ User ส่ง
สมมติ User ส่ง
1 Prompt
แต่ Gemini Search
Query 1
Query 2
Query 3
Usage อาจนับ 3 Search Requests
ดังนั้น Cost Planning ต้องติดตาม Tool Usage จริง
สำหรับ Gemini 3 Pricing ปัจจุบันมี Free Allowance
5,000 requests/prompts ต่อเดือน
ตาม Model/Mode ที่รองรับ
หลังจากนั้น Pricing ปัจจุบันระบุ
$14 ต่อ 1,000 Search Queries
รายละเอียดสามารถเปลี่ยนได้ จึงควรตรวจ Pricing ก่อนเปิด Location App จำนวนมาก
Model สร้างภาพสามารถมี Pricing แยกจาก Text
ตัวอย่างบาง Model คิดเป็น
ราคาต่อ 1M image output tokens
และ Google ยังแสดง Equivalent Cost ต่อภาพตาม Resolution
เช่นภาพ
สามารถมีราคาแตกต่างกัน
ดังนั้นระบบ Generate Image ต้องคิดต้นทุนต่อภาพ ไม่ควรใช้สูตร Text Token อย่างเดียว
Audio Model สามารถคิดตาม
ตาม Model
ตัวอย่าง Pricing Page บางรุ่นแสดง Equivalent Cost ต่อ Minute
ดังนั้น Voice App ควรติดตาม
minutes per session
ควบคู่กับจำนวน User
Video Generation และ Video Processing ใช้ข้อมูลมากกว่า Text
บาง Model คิดตาม
ก่อนสร้างระบบให้ User Generate Video ไม่จำกัด ควรคำนวณ
Cost per generated video
ให้ชัดก่อน
Google Pricing ปัจจุบันระบุว่า Token ใน DOCUMENT Modality เช่น PDF ถูกคิดตาม Image Token Rate
ดังนั้น PDF Pricing ไม่ควรถูกประมาณจากจำนวนตัวอักษรในเอกสารเพียงอย่างเดียว
สำหรับระบบวิเคราะห์ PDF จำนวนมากควรดู Usage Metadata จาก Request จริง
ใช้สูตร
Input Cost
=
Input Tokens
÷ 1,000,000
× Input Price
และ
Output Cost
=
Output Tokens
÷ 1,000,000
× Output Price
รวม
Total
=
Input Cost
+
Output Cost
+
Tools
+
Caching
+
Media
สมมติ Chatbot มี
5,000 Users
แต่ละ User ใช้
20 Requests / เดือน
รวม
100,000 Requests / เดือน
ถ้าเฉลี่ยต่อ Request
Input 1,500 tokens
Output 400 tokens
รวม Token
Input
150,000,000 tokens
Output
40,000,000 tokens
จากนั้นนำไปคูณราคา Model ที่เลือก
นี่เป็นวิธีประมาณก่อนเปิด Production
Production Traffic อาจมี
Normal User
1,000 tokens
แต่บาง User
Upload PDF
100,000 tokens
Average อย่างเดียวอาจซ่อน Heavy User
ควรดู
ด้วย
สมมติ
รายได้/User
= 300 บาท/เดือน
แต่ AI Cost
= 400 บาท/User/เดือน
Business Model ไม่ยั่งยืน
ควรคำนวณ
Revenue
-
AI Cost
-
Hosting
-
Database
-
Payment Fee
=
Margin
ก่อน Scale
สมมติ Model A
$0.001 / request
แต่ต้องเรียก 5 ครั้ง
รวม
$0.005
Model B
$0.003
แต่สำเร็จครั้งเดียว
Model B อาจถูกกว่าในเชิง Business
ดังนั้น Evaluate
Cost per successful result
ด้วย
งานง่ายใช้ Model ที่ Cost-efficient
อย่าส่ง Context ทั้งหมดทุกครั้ง
กำหนด Length
ลดคำอธิบายส่วนเกิน
เมื่อ Context ซ้ำ
สำหรับ Offline Workload
อย่าส่ง Prompt ซ้ำ
ป้องกัน Heavy Usage
Search สามารถสร้าง Cost เพิ่ม
อย่าประมาณจากจำนวน Request อย่างเดียว
Application ไม่จำเป็นต้องใช้โมเดลเดียวทุก Feature
ตัวอย่าง
Classification
→ Flash-Lite
Complex Analysis
→ Flash/Pro
Realtime
→ Live Model
ใช้ Model ตามความยากของงาน
ช่วยควบคุมทั้ง Cost และ Latency
ตัวอย่าง
Model A fail
↓
Model B
มีประโยชน์ด้าน Reliability
แต่ถ้า Configuration ผิดอาจเกิด
A
→ B
→ C
→ Retry A
ทำให้ Cost เพิ่มโดยไม่รู้ตัว
ควรกำหนด Maximum Attempt
ขึ้นกับผล Request
Google Billing FAQ ปัจจุบันระบุว่า Request ที่ล้มเหลวด้วย Error 400 หรือ 500 จะ ไม่ถูกคิด Token Charge แต่ Request ยังนับกับ Quota
อย่างไรก็ตามไม่ควร Retry ไม่จำกัด
เพราะ Error อื่นและ Request ที่สำเร็จสามารถสร้าง Usage ได้
Google ระบุว่า Request ไปยัง GetTokens API
จึงสามารถใช้ช่วยตรวจ Token ก่อนส่ง Request จริงได้ตาม Workflow ที่เหมาะสม
จุดนี้สำคัญมาก
Google ระบุว่าตั้งแต่ มีนาคม 2026 ค่าใช้ Gemini API ถูกแยกออกจาก Google Cloud Free Trial $300
ดังนั้นอย่าคิดว่าเปิด Google Cloud ใหม่แล้ว
$300 Free Trial
สามารถนำไปจ่าย Gemini API ได้โดยอัตโนมัติ
ต้องตรวจประเภท Credit และ Eligibility แยกต่างหาก
ใน Google AI Studio สามารถเลือก
Set up billing
จากหน้า
แล้วทำตามขั้นตอน Cloud Billing
ปัจจุบัน Getting Started ของ Google ระบุว่าการเปิด Paid Tier ต้อง
ตาม Billing Workflow ปัจจุบัน
ไม่ใช่
จำนวนดังกล่าวเป็น Minimum Prepay ใน Workflow เปิด Paid Tier ปัจจุบัน
ไม่ใช่ Subscription รายเดือนราคา $10
หลังจากนั้น Billing ยังขึ้นกับ Usage และ Billing Model ของบัญชี
Google AI Studio สามารถดูการใช้งานที่
Dashboard
↓
Usage
ควรตรวจเป็นประจำ
โดยเฉพาะหลัง
ควร
โดยเฉพาะ Production
สามารถตั้ง Budget Monitoring ใน Cloud Billing ตามระบบที่รองรับ
ตัวอย่าง Threshold
50%
75%
90%
100%
แต่ควรจำไว้ว่า Budget Alert ไม่ควรถูกสมมติว่าเป็น Hard Stop ของ Service
Application ควรมี Usage Control ของตัวเองด้วย
ตัวอย่าง
Free User
10 requests/day
Paid User
100 requests/day
ช่วยจำกัด Abuse
ก่อน Request ถึง Gemini
ดังนั้นควรมี
Application Rate Limit
+
Gemini API Rate Limit
สองชั้น
ถ้า Paid Key ถูกขโมย
ผู้โจมตีอาจใช้ Project Quota และสร้างค่าใช้จ่าย
ดังนั้นต้อง
Cost Control กับ Security เป็นเรื่องเดียวกันในหลายกรณี
ถ้า App มี
Chat
Search
Image
Document
Voice
ควรแยก Usage
เช่น
Chat = 40%
Search = 10%
Image = 35%
Voice = 15%
ทำให้รู้ว่า Feature ใดกิน Budget มากที่สุด
Gemini API Response มี Usage Metadata ตาม API
สามารถนำมาบันทึก
user_id
model
input_tokens
output_tokens
cached_tokens
timestamp
จากนั้นสร้าง Dashboard
Daily Tokens
Monthly Tokens
Cost per User
Cost per Feature
มีประโยชน์มากกว่าเดาค่าใช้จ่ายจากจำนวนสมาชิก
Prompt ที่สั้นมากแต่อธิบายไม่ชัดอาจทำให้
Bad Output
↓
Retry
↓
Retry
สุดท้ายแพงกว่า Prompt ที่ยาวขึ้นเล็กน้อยแต่ให้คำตอบถูกครั้งเดียว
ดังนั้น Optimize ที่
Accuracy
+
Tokens
+
Retries
พร้อมกัน
ถ้า System Prompt
20,000 tokens
ถูกส่งทุก Request
เมื่อมี Request จำนวนมากต้นทุน Input จะสูง
ควรพิจารณา
ตาม Architecture
Chatbot ที่ส่ง
Message 1
...
Message 500
ทุกครั้งจะมี Context ใหญ่ขึ้นเรื่อย ๆ
ควรใช้ Strategy เช่น
เพื่อไม่ให้ Token โตโดยไม่มีขอบเขต
User Upload
PDF 300 หน้า
อาจใช้ Token มากกว่า Prompt Text ธรรมดามาก
Public App ควรกำหนด
ตาม Business Model
อย่าเปิด Upload ไม่จำกัดถ้าเจ้าของระบบเป็นคนจ่าย API Cost
สำหรับ Media Generation เหมาะกับระบบ Credit เช่น
1 Image
= X credits
1 Video
= Y credits
เพราะแต่ละงานมีต้นทุนต่างกันมาก
ดีกว่าปล่อย
Unlimited Generate
โดยไม่มี Usage Control
Pricing Page ของ Google ปัจจุบันระบุ
Content สามารถถูกใช้เพื่อช่วยปรับปรุงผลิตภัณฑ์ตามเงื่อนไขของ Google
Content ไม่ถูกใช้เพื่อปรับปรุงผลิตภัณฑ์ภายใต้เงื่อนไข Paid Service ที่ระบุ
ดังนั้นธุรกิจไม่ควรเลือก Tier จากราคาอย่างเดียว
ควรดู Data Terms ด้วย
Text, Image, Audio, Video
ถ้าไม่ต้องทันทีอาจใช้ Batch
ตอบคำถามเหล่านี้ก่อนเลือก Model
ไม่จริง
Output อาจแพงกว่า
รวมใน Output Billing สำหรับ Model ที่เกี่ยวข้อง
Token ต่างกันทุก Request
Tool Usage เพิ่ม
พลาด Cost Saving
Token สูงโดยไม่จำเป็น
Heavy User กิน Budget
ราคาเปลี่ยนได้
รู้ตัวเมื่อ Bill มาแล้ว
รู้ว่าต้องการ AI ทำอะไร
ไม่เลือกจากชื่ออย่างเดียว
ใช้ข้อมูลจริง
สร้าง Baseline
ดู Unit Economics
ป้องกัน Abuse
สำหรับงานไม่เร่งด่วน
เมื่อ Context ซ้ำ
เก็บ Usage Metadata
ก่อน Production
ดู Feature ที่ Cost สูง
ลด Cost โดยไม่ทำให้ Quality พัง
สำหรับ Project AI ของ comsiam การเก็บ Token Usage ตั้งแต่ Development จะช่วยให้ตัดสินใจเรื่อง Model และราคาได้ดีกว่ารอจนเปิด Production แล้วค่อยดูยอดรวมจาก Billing
เริ่มจาก
Users × Requests/User
=
Requests
จากนั้น
Requests × Average Input Tokens
=
Total Input
และ
Requests × Average Output Tokens
=
Total Output
คำนวณ
Input Cost
+
Output Cost
+
Tools
+
Media
+
Caching
=
Estimated Gemini Cost
จากนั้นเพิ่ม Safety Margin เช่น
20–30%
ตามความผันผวนของ Usage
Column เช่น
Feature
Model
Requests/month
Avg input tokens
Avg output tokens
Search calls
Cost/request
Monthly cost
เช่น
Chat
FAQ
PDF
Search
Image
จะเห็นชัดว่า Feature ไหนควร Optimize ก่อน
ไม่มีราคาเดียว ราคาขึ้นกับ Model, Input/Output Tokens, Processing Mode และ Feature ที่ใช้ ตัวอย่าง gemini-3.7-flash แบบ Standard Paid Tier ณ 2 กันยายน 2026 อยู่ที่ $0.75 ต่อ 1 ล้าน Input Tokens และ $3.75 ต่อ 1 ล้าน Output Tokens จนถึง 31 ธันวาคม 2026
มี Free Tier สำหรับ Model และ Limit ที่ Google กำหนด เหมาะกับการทดลองและ Project ขนาดเล็ก แต่ไม่ใช่ Unlimited Usage
ในหลาย Model ใช่ ตัวอย่าง Gemini 3.7 Flash ปัจจุบัน Input $0.75 แต่ Output $3.75 ต่อ 1 ล้าน Tokens จึงควรควบคุม Output Length
สำหรับโมเดลที่เกี่ยวข้อง Googleรวม Thinking Tokens ไว้ใน Output Token Pricing
สำหรับ Model ที่รองรับ Batch Pricing มักต่ำกว่า Standard อย่างมาก และ Googleระบุ Paid Tier ว่า Batch API ช่วยลด Cost ได้ประมาณ 50% เหมาะกับงานที่ไม่ต้องตอบทันที
Google ระบุว่า Google AI Studio Usage เองใช้ฟรีในพื้นที่ที่รองรับ แต่เมื่อใช้ Paid API Project หรือสร้าง Usage ผ่าน Gemini API จะต้องคิดตาม Pricing และ Billing ของ API ที่เกี่ยวข้อง
Gemini API คิดค่าบริการแบบ Usage-based โดยต้นทุนหลักมาจาก Input Tokens, Output Tokens และ Thinking Tokens รวมถึง Feature เพิ่มเติม เช่น Context Caching, Google Search, Google Maps, Image, Audio และ Video
แต่ละโมเดลมีราคาไม่เท่ากัน และยังมี Processing Mode หลายประเภท เช่น Standard, Batch, Flex และ Priority ทำให้ Developer สามารถเลือกระหว่างราคา Latency และลักษณะ Workload ได้
ณ วันที่ 2 กันยายน 2026 gemini-3.7-flash มี Standard Paid Pricing ที่ $0.75 ต่อ 1 ล้าน Input Tokens และ $3.75 ต่อ 1 ล้าน Output Tokens จนถึงวันที่ 31 ธันวาคม 2026 และ Google ประกาศราคาใหม่ตั้งแต่ 1 มกราคม 2027 เป็น $1.50 และ $7.50 ตามลำดับ
งานจำนวนมากที่ไม่ต้องตอบทันทีควรพิจารณา Batch ซึ่งปัจจุบันมีราคาประมาณครึ่งหนึ่งของ Standard สำหรับ Gemini 3.7 Flash ส่วน Context ที่ใช้ซ้ำจำนวนมากอาจลดต้นทุนด้วย Caching
การควบคุม Cost ที่ดีที่สุดไม่ใช่เพียงเลือก Model ที่ถูกที่สุด แต่ต้องวัด Cost per Successful Task, Cost per User และ Cost per Feature พร้อมควบคุม Input, Output, Retry, Tool Calls และ User Quota
แนวทางของ comsiam คือเริ่มจาก Free Tier สำหรับ Development จากนั้นวัด Token Usage ของงานจริงก่อนเปิด Paid Tier และสร้าง Budget จาก Traffic จริง วิธีนี้ช่วยป้องกันทั้งการประเมิน Cost ต่ำเกินไปและการเลือก Model ที่แพงเกินความจำเป็น