เปรียบเทียบราคา LLM API ปี 2026 ระหว่าง Amazon Bedrock, Azure OpenAI, Google Vertex AI พร้อม Prompt Caching, Batch API และ Model Routing ที่ลดต้นทุนได้ 40-90%
อัปเดต: 14 กรกฎาคม 2026
การลดค่า LLM API ปี 2026 ทำได้จริง 40–90% โดยใช้สามกลยุทธ์หลักที่ใช้ได้ทั้ง Amazon Bedrock, Azure OpenAI และ Google Vertex AI ได้แก่ Prompt Caching (ลด token อินพุตซ้ำ 50–90%), Batch API (ลด 50% เมื่อรอผลลัพธ์ได้ภายใน 24 ชั่วโมง) และ Model Routing (ส่งงานง่ายไปโมเดลเล็ก เช่น Haiku 4.5, GPT-4o-mini, Gemini 2.5 Flash) ในบทความนี้ผมเปรียบเทียบราคาต่อล้านโทเคน กลไก billing และตัวอย่างโค้ดจริงที่ผมใช้กับลูกค้าองค์กรในไตรมาสที่ผ่านมา
ผมทำงานกับทีมเอ็นเตอร์ไพรส์ที่ใช้ทั้งสามคลาวด์พร้อมกัน และคำถามแรกที่ทุกทีมถามคือ "ราคาต่างกันแค่ไหน" ตารางด้านล่างสรุปราคา on-demand ต่อล้านโทเคน (ณ ต้นเดือนกรกฎาคม 2026, ภูมิภาค US East) สำหรับโมเดลที่ใช้จริงในโปรดักชัน ผมแนะนำให้อ่านราคาแยก input/output เพราะ output แพงกว่ามากและมักเป็นตัวขับต้นทุนหลัก
| โมเดล | ผู้ให้บริการ | Input ($/M tokens) | Output ($/M tokens) | Cache Read | Context Window |
|---|---|---|---|---|---|
| Claude Opus 4.8 | Bedrock, Anthropic | $15.00 | $75.00 | $1.50 (90% off) | 200K |
| Claude Sonnet 5 | Bedrock, Anthropic, Vertex | $3.00 | $15.00 | $0.30 (90% off) | 1M |
| Claude Haiku 4.5 | Bedrock, Anthropic | $1.00 | $5.00 | $0.10 (90% off) | 200K |
| GPT-4o (2026-05) | Azure OpenAI, OpenAI | $2.50 | $10.00 | $1.25 (50% off) | 128K |
| GPT-4o-mini | Azure OpenAI, OpenAI | $0.15 | $0.60 | $0.075 (50% off) | 128K |
| Gemini 2.5 Pro | Vertex AI | $1.25 | $5.00 | $0.3125 (75% off) | 2M |
| Gemini 2.5 Flash | Vertex AI | $0.075 | $0.30 | $0.01875 (75% off) | 1M |
| Amazon Nova Pro | Bedrock | $0.80 | $3.20 | N/A | 300K |
สังเกตว่า Gemini 2.5 Flash ถูกที่สุดสำหรับงาน general-purpose แต่ผลลัพธ์เชิง reasoning ยังตามหลัง Sonnet 5 และ GPT-4o ราว 5–10% (วัดจาก MMLU-Pro และ HumanEval) ในทางกลับกัน Claude Opus 4.8 เป็นตัวเลือกที่ผมเลือกสำหรับงาน agentic ที่ต้องเรียก tool ต่อเนื่อง 30+ steps เพราะ output tokens ที่แพงถูกชดเชยด้วยจำนวนรอบ retry ที่ลดลง
ราคา output token ที่แพงกว่า input 4–5 เท่าไม่ใช่การตั้งราคาโดยบังเอิญ แต่เกิดจากลักษณะทางเทคนิคของ transformer inference: ในขณะ prefill (ประมวลผล input) GPU ทำ matrix multiplication เป็นก้อนใหญ่ได้ประสิทธิภาพสูง แต่ในขณะ decode (สร้าง output ทีละโทเคน) แต่ละโทเคนต้องรอโทเคนก่อนหน้าเสร็จ ทำให้ GPU utilization ต่ำ ผู้ให้บริการจึงต้องคิดราคา output แพงกว่าเพื่อให้ครอบคลุมต้นทุน hardware ที่แท้จริง
ในทางปฏิบัติ นี่หมายความว่ากลยุทธ์ลดต้นทุนที่ได้ผลที่สุดคือ ควบคุมความยาวคำตอบ ผมใช้เทคนิคเหล่านี้กับทีมลูกค้า:
max_tokens ให้พอดี ไม่ใช่ตั้งเผื่อ 4096 ทุกครั้ง งาน classification ให้ตอบแค่ label ก็พอ ตั้ง 20 tokensresponse_format: {"type": "json_schema"} เพื่อบังคับให้โมเดลตอบเฉพาะ field ที่ต้องการ ไม่พร่ำสร้าง preamble ("Sure! Here is...")budget_tokens ต่ำ ๆ (1000–2000) แทน defaultPrompt caching คือกลไกที่ผู้ให้บริการจะเก็บ KV cache ของ prefix ที่ยาว ๆ ไว้บน GPU memory เมื่อ request ถัดไปมี prefix เดียวกัน จะไม่ต้อง prefill ใหม่ ประหยัดทั้งเวลาและค่าใช้จ่าย เหมาะมากกับ RAG (system prompt + few-shot examples ยาว) และ agent (tool definitions ยาว) ตัวเลขที่ผมเห็นในโปรดักชัน: ระบบ RAG ที่มี system prompt 8K tokens และ query 200 tokens ประหยัดค่าใช้จ่ายรวม 70–85% หลังเปิด caching
Anthropic ให้ส่วนลด 90% ต่อโทเคน cache-read แต่คิดค่า cache-write เพิ่ม 25% ครั้งแรก TTL อยู่ที่ 5 นาที (default) หรือขยายเป็น 1 ชั่วโมงได้ในราคาสูงขึ้น ต้องระบุ cache_control ในตำแหน่งที่ต้องการแคช (ระบุได้ 4 breakpoints):
import boto3, json
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
response = bedrock.invoke_model(
modelId="anthropic.claude-sonnet-5-20260501-v1:0",
body=json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 500,
"system": [
{
"type": "text",
"text": LARGE_SYSTEM_PROMPT, # 8000+ tokens
"cache_control": {"type": "ephemeral"}
}
],
"messages": [{"role": "user", "content": user_query}]
})
)
usage = json.loads(response["body"].read())["usage"]
print(f"cache_read: {usage['cache_read_input_tokens']}, "
f"cache_write: {usage['cache_creation_input_tokens']}")
OpenAI ให้ส่วนลด 50% อัตโนมัติเมื่อ prompt มี prefix เดียวกัน ≥1024 tokens ไม่ต้องระบุอะไร แต่ TTL สั้นเพียง 5–10 นาที และไม่ได้การันตี ผมแนะนำให้จัดเรียง messages ให้ static content (system prompt, tool definitions) อยู่หัวเสมอ และ dynamic content (user query) อยู่ท้าย
Vertex ให้ส่วนลด 75% ต่อ cache-read และคิดค่า storage แยกต่างหาก ($1/M tokens/hour สำหรับ Gemini 2.5 Pro) minimum cache size อยู่ที่ 4096 tokens จึงเหมาะกับเอกสาร RAG ยาว ๆ หรือ codebase context การสร้าง cache ต้องเรียก cachedContents.create ก่อน แล้วอ้าง name ใน request ถัดไป (เป็นโมเดลที่ควบคุม lifecycle ได้แม่นยำที่สุด)
Batch API ของทั้งสามคลาวด์ให้ส่วนลด 50% กับงานที่ยอมรับ SLA 24 ชั่วโมง (บางกรณีเสร็จภายในไม่กี่นาที) เหมาะกับงาน embedding ล้านชิ้น, summarization ข่าวรายวัน, content moderation, evaluation set หรือ backfill ข้อมูล ผมช่วยลูกค้ารายหนึ่งย้าย pipeline generation summary จาก on-demand ไป Batch แล้วประหยัดจาก $47K/เดือน เหลือ $23K/เดือน โดยผู้ใช้ไม่รู้สึกว่าช้าลง เพราะเนื้อหาถูก pre-generate ค้างคืน
วิธี submit batch บน OpenAI/Azure OpenAI ใช้ไฟล์ JSONL:
# batch_input.jsonl
{"custom_id":"req-1","method":"POST","url":"/v1/chat/completions","body":{"model":"gpt-4o-mini","messages":[{"role":"user","content":"Summarize..."}],"max_tokens":200}}
{"custom_id":"req-2","method":"POST","url":"/v1/chat/completions","body":{"model":"gpt-4o-mini","messages":[{"role":"user","content":"Summarize..."}],"max_tokens":200}}
from openai import AzureOpenAI
client = AzureOpenAI(api_version="2026-05-01-preview")
file = client.files.create(file=open("batch_input.jsonl", "rb"), purpose="batch")
batch = client.batches.create(
input_file_id=file.id,
endpoint="/v1/chat/completions",
completion_window="24h"
)
print(f"Batch {batch.id} - status: {batch.status}") # poll until "completed"
สำหรับ Bedrock ใช้ CreateModelInvocationJob ที่อ่าน/เขียน S3 ส่วน Vertex ใช้ BatchPredictionJob กับ BigQuery หรือ GCS ทั้งสองแบบเหมาะกับ pipeline ที่ orchestrated ผ่าน Airflow, Prefect หรือ Step Functions อยู่แล้ว
Model routing คือการวิเคราะห์ query ก่อนส่งเข้าโมเดล เพื่อเลือกโมเดลที่ราคา/คุณภาพเหมาะสมที่สุด งาน "hello" หรือ "what's my order status" ไม่จำเป็นต้องใช้ Opus 4.8 แค่ Haiku 4.5 หรือ Gemini Flash ก็พอ ผมพบว่าการ implement router ที่ดีลดค่าใช้จ่ายเฉลี่ย 40–70% โดยคุณภาพผลลัพธ์ end-to-end ลดลงเพียง 2–5% (วัดจาก user thumbs-up rate)
ตัวอย่างการใช้ LiteLLM เป็น router แบบ multi-cloud:
from litellm import Router
router = Router(model_list=[
{"model_name": "cheap-tier",
"litellm_params": {"model": "bedrock/anthropic.claude-haiku-4-5-20251001-v1:0",
"aws_region_name": "us-east-1"}},
{"model_name": "cheap-tier",
"litellm_params": {"model": "vertex_ai/gemini-2.5-flash",
"vertex_project": "my-proj", "vertex_location": "us-central1"}},
{"model_name": "smart-tier",
"litellm_params": {"model": "azure/gpt-4o-2026-05",
"api_base": AZURE_ENDPOINT, "api_version": "2026-05-01-preview"}},
], routing_strategy="cost-based-routing", fallbacks=[{"cheap-tier": ["smart-tier"]}])
def classify_and_route(user_message: str) -> str:
tier = "smart-tier" if needs_reasoning(user_message) else "cheap-tier"
resp = router.completion(model=tier, messages=[{"role":"user","content":user_message}])
return resp.choices[0].message.content
สำหรับทีมที่ไม่อยาก self-host ผมแนะนำให้พิจารณา Portkey AI Gateway หรือ OpenRouter documentation ที่มี dashboard cost analytics ในตัว แต่เพิ่ม hop latency ~30–80ms และมี vendor lock-in ระดับหนึ่ง
ทั้งสามคลาวด์เสนอ Provisioned Throughput (Azure เรียกว่า PTU หรือ Provisioned Throughput Units) เป็นการจอง capacity ล่วงหน้าในราคารายชั่วโมง/รายเดือน คุ้มค่าเมื่อ utilization สูงและคงที่ ผมใช้กฎ break-even หยาบ ๆ นี้:
ข้อควรระวังคือ PTU/Provisioned Throughput ผูกกับโมเดลและ region เฉพาะ หากมีการอัปเดตโมเดล (GPT-4o → GPT-5) capacity ที่จองไว้จะไม่ transfer อัตโนมัติ ทำให้ทีม platform ต้องวางแผน migration ล่วงหน้า ผมเขียนเรื่อง sizing และ decision matrix แบบเดียวกันไว้ใน คู่มือลดค่า GPU คลาวด์สำหรับ AI/ML ปี 2026 ซึ่งครอบคลุมงาน training และ inference บน SageMaker, Azure ML และ Vertex AI Training
สิ่งที่ผมพบบ่อยที่สุดในการ audit ทีมที่ค่า LLM API พุ่ง คือไม่มีใครแทงป้ายกำกับ (tag) ว่า request ไหนของ product ไหน ทำให้พอบิลมา ไม่รู้จะไล่ optimize จากตรงไหน สามคลาวด์รองรับ metadata ที่ผูกกับ request ได้:
Application Inference Profiles ผูก tag → บิล + CloudWatch metric ต่อ profileuser field ใน request + ใช้ resource tag บน deploymentlabels ใน prediction request → เห็นใน Billing Export ต่อ labelFramework ที่ผมใช้กับลูกค้าคือ export ค่าใช้จ่ายเป็น unit economics (ค่าต่อ user, ค่าต่อ conversation, ค่าต่อ feature) แล้ว alert เมื่อ deviation ≥3σ วิธีการนี้ผมอธิบายละเอียดใน FinOps Unit Economics 2026 และการตั้ง anomaly detection ให้จับ spike ได้เร็วภายในไม่กี่ชั่วโมง อ่านต่อได้ใน คู่มือ Cloud Cost Anomaly Detection 2026
เครื่องมือ observability ที่นิยมสำหรับ LLM cost specifically คือ Langfuse, Helicone, Datadog LLM Observability และ AWS Bedrock CloudWatch Application Signals ทุกตัวรองรับ per-user, per-prompt, per-model breakdown ซึ่งจำเป็นเมื่อทีมมีมากกว่า 3 use case ที่ share bill เดียวกัน สำหรับข้อกำหนดการรายงาน billing ข้ามคลาวด์แบบเปิด แนะนำให้ตามอ่าน FOCUS Specification จาก FinOps Foundation ซึ่งเวอร์ชันล่าสุดในกลางปี 2026 เริ่มรองรับ AI SKU codes ให้ mapping ระหว่างสามคลาวด์ทำได้ตรงกันขึ้น
คำตอบที่ผมให้ลูกค้าองค์กรเสมอคือ "ขึ้นอยู่กับว่า workload คุณเป็นอะไร" ไม่มีคลาวด์ไหนถูกกว่าอีกคลาวด์แบบ blanket ต่อไปนี้เป็น decision matrix ที่ผมใช้ตัดสินใจจริงในไตรมาสที่ผ่านมา:
ในหลายกรณี คำตอบที่ดีที่สุดคือ "ทั้งสาม" — ผ่าน gateway ตัวเดียว เช่น LiteLLM หรือ Portkey แล้วเลือกโมเดลตาม workload ผมมีลูกค้าที่ใช้ Gemini Flash สำหรับ classification, Claude Sonnet สำหรับ tool-use agent และ GPT-4o สำหรับ chat UI เพราะแต่ละงานมี cost/quality trade-off ต่างกัน กลยุทธ์ multi-cloud นี้ต้องการ tagging และ cost allocation ที่แน่นหนา รายละเอียดผมเขียนไว้ใน คู่มือ Cost Allocation สำหรับ AWS, Azure, GCP
ข้อสำคัญที่ผมย้ำเสมอ: อย่ายึดกับ benchmark สาธารณะอย่างเดียว, สร้าง eval set ของงานจริง (100–300 ตัวอย่าง) แล้ววัดทั้ง ความถูกต้อง และ ต้นทุนต่อ eval ก่อนตัดสินใจ pin โมเดลกับ workload สำหรับข้อมูล pricing และ availability ล่าสุด ให้อ้างอิงจาก AWS Bedrock pricing docs และ Azure OpenAI Provisioned Throughput guide ซึ่งอัปเดตทุก 30–60 วัน
ราคา on-demand เดือนกรกฎาคม 2026 อยู่ในช่วง $0.075–$15/M input และ $0.30–$75/M output ขึ้นอยู่กับโมเดล โดย Gemini 2.5 Flash ถูกที่สุดที่ $0.075/$0.30 ส่วน Claude Opus 4.8 แพงที่สุดที่ $15/$75 โมเดล mid-tier อย่าง Claude Sonnet 5, GPT-4o, Gemini 2.5 Pro อยู่ในช่วง $1.25–$3 input และ $5–$15 output
Anthropic Claude ให้ส่วนลด 90% ต่อโทเคน cache-read, Google Gemini ให้ 75% และ OpenAI GPT ให้ 50% ในระบบ RAG ที่มี system prompt ยาวและ query สั้น จะลดค่าใช้จ่ายรวม 70–85% แต่ต้องระวังค่า cache-write ครั้งแรก (+25% สำหรับ Anthropic) ที่ทำให้ไม่คุ้มหาก hit rate ต่ำ
Batch API รับ input เป็น bulk file (JSONL หรือ S3/GCS) และคืนผลภายใน 24 ชั่วโมง (ปกติเสร็จเร็วกว่านั้น) แลกกับส่วนลด 50% เหมาะกับงาน asynchronous เช่น embedding, summarization, evaluation ที่ไม่ต้องการผลลัพธ์ทันที ไม่เหมาะกับ chatbot หรืองาน user-facing real-time
คุ้มเมื่อ utilization ต่อวันสูงกว่า 60% ตลอดสัปดาห์ ถ้า <30% ให้ใช้ on-demand ล้วน ระหว่าง 30–60% ให้ mix โดยจอง baseline แล้ว spillover ไป on-demand PTU/Provisioned Throughput ผูกกับโมเดลและ region เฉพาะ จึงต้องวางแผน migration เมื่อมี model upgrade
ได้จริง 40–70% โดยคุณภาพลดเพียง 2–5% เมื่อ implement รอบคอบ ใช้ classifier ตัวเล็กหรือ RouteLLM ตัดสินใจว่า query ต้องใช้ smart tier (GPT-4o, Sonnet 5) หรือ cheap tier (GPT-4o-mini, Haiku 4.5, Gemini Flash) ผ่าน gateway เช่น LiteLLM, Portkey หรือ OpenRouter
คู่มือลดค่า Observability ปี 2026 สำหรับ Datadog, Splunk, New Relic และ Grafana Cloud ครอบคลุม log sampling, cardinality management, tail-based tracing และ retention tier ที่ประหยัดจริง 40-70%
FOCUS 1.2 คือมาตรฐานเปิดสำหรับข้อมูลบิลคลาวด์ที่ AWS, Azure, GCP และ Oracle Cloud รองรับหมดในปี 2026 บทความนี้พาลุยตั้งแต่คอลัมน์หลัก การเปิด export ทีละ cloud ตัวอย่าง SQL จริงบน Athena/BigQuery เปรียบเทียบกับ AWS CUR 2.0 และ checklist adoption 6 ขั้น
คู่มือลดค่า Data Warehouse ปี 2026 ครอบคลุม Snowflake, BigQuery, Redshift และ Databricks พร้อมสูตรลด bill 30-60% ผ่าน warehouse sizing, slot reservation, query optimization และ FinOps chargeback