Contact
Line : comsiam
Contact
Line : comsiam

Perplexity API คิดค่าบริการอย่างไร ราคาเท่าไหร่ ต้องซื้อเครดิตก่อนหรือไม่ และถ้านำไปสร้าง Chatbot หรือระบบค้นข้อมูลบนเว็บไซต์จะเสียเงินเดือนละเท่าไหร่? เป็นคำถามสำคัญสำหรับผู้พัฒนาเว็บไซต์ โปรแกรมเมอร์ เจ้าของธุรกิจ และผู้ที่ต้องการนำความสามารถ AI Search ของ Perplexity ไปใช้ในระบบของตนเอง
Perplexity API มีระบบคิดค่าบริการตามการใช้งานจริง โดยแต่ละ API มีรูปแบบราคาแตกต่างกัน เช่น Search API คิดต่อคำขอค้นหาที่สำเร็จ Agent API คิดตามโมเดล AI และเครื่องมือที่เรียกใช้งาน ส่วน Embeddings API คิดตามปริมาณ Tokens ที่นำไปประมวลผล
สำหรับ Agent API การเรียกหนึ่งครั้งอาจมีค่าใช้จ่ายหลายส่วน เช่น Input Tokens, Output Tokens, Cached Tokens, Reasoning Tokens และ Web Search Tool Calls ขึ้นอยู่กับโมเดลและรูปแบบการทำงาน ดังนั้นจำนวนคำถามเท่ากันไม่ได้หมายความว่าจะมีต้นทุนเท่ากันเสมอไป
อีกประเด็นคือ Perplexity API มีระบบ Billing แยกจาก Perplexity Pro, Max และ Enterprise Subscription จึงไม่ควรเข้าใจว่าการสมัครแพ็กเกจรายเดือนสำหรับใช้งานผ่านเว็บไซต์จะทำให้ API ใช้งานได้ฟรีไม่จำกัด
ผู้เริ่มต้นควรทราบวิธีคำนวณต้นทุนก่อนเปิดให้ลูกค้าใช้จริง โดยเฉพาะเว็บไซต์ที่มีผู้ใช้งานจำนวนมาก เพราะการเรียก API ซ้ำ การสร้างคำตอบยาว หรือการเปิดให้ AI เรียกเครื่องมือหลายรอบอาจทำให้เครดิตลดลงรวดเร็วกว่าที่คาดไว้
บทความนี้ ComSiam จะอธิบาย Perplexity API คิดค่าบริการอย่างไร ครอบคลุม Agent API, Search API, Fast Search, Embeddings API, Orchestrator API, Input Tokens, Output Tokens, Reasoning, Cache, Web Search, Tool Calls, Pay-as-you-go, Projects, Billing, Credits, Usage Tiers และ Rate Limits พร้อมตัวอย่างคำนวณต้นทุนเป็นดอลลาร์สหรัฐและเงินบาทโดยใช้อัตราแลกเปลี่ยนสมมติ ตารางเปรียบเทียบงาน Chatbot, SEO Research และ Business Research สูตร Excel, Workflow, Checklist, FAQ และ Prompt ภาษาไทยกับภาษาอังกฤษ
Perplexity API คิดค่าบริการตามประเภทของ API และปริมาณทรัพยากรที่ใช้จริง
① คิดต่อจำนวน Requests
② คิดต่อ Input Tokens
③ คิดต่อ Output Tokens
④ คิดต่อ Cached Tokens ตามโมเดล
⑤ คิดต่อ Reasoning Tokens ตามโมเดล
⑥ คิดต่อจำนวน Tool Invocations
⑦ คิดต่อจำนวน Tokens สำหรับ Embeddings
⑧ คิดค่าบริการของเครื่องมือเฉพาะทางเพิ่มเติมเมื่อเรียกใช้งาน
| บริการ | วิธีคิดค่าบริการหลัก |
|---|---|
| Search API | จำนวน Requests ที่สำเร็จ |
| Fast Search API | จำนวน Requests ที่สำเร็จ |
| Agent API | Model Tokens และ Tools |
| Embeddings API | Tokens ที่นำไปสร้าง Embeddings |
| Orchestrator API | Tokens ตามโมเดล |
| เครื่องมือ Web Search | จำนวนครั้งที่เรียก |
| เครื่องมือ Fetch URL | จำนวนครั้งที่เรียก |
| Sandbox | จำนวน Sessions ตามช่วงคิดค่าบริการ |
คำถามสั้นที่ไม่ใช้เครื่องมือ อาจเสียค่าใช้จ่ายน้อยกว่างาน Research ที่ค้นเว็บหลายครั้งและสร้างคำตอบจำนวนมาก
ดังนั้นควรคำนวณต้นทุนจาก Usage จริง ไม่ใช่จากจำนวนคำถามอย่างเดียว
Perplexity API ใช้ระบบเครดิตสำหรับชำระค่าบริการตามการใช้งาน
① เติมเครดิตเข้าบัญชี API
② เรียก API ตามความจำเป็น
③ ระบบคำนวณค่าใช้จ่าย
④ หักเครดิตตาม Usage
⑤ ตรวจเครดิตคงเหลือ
⑥ เติมเครดิตเพิ่มเมื่อจำเป็น
หมายถึงคิดตามการใช้งาน ไม่ใช่จ่ายค่าบริการแบบเหมาจ่ายแล้วใช้ได้ไม่จำกัด
ตามคู่มือ Projects & Billing ระบบใช้เครดิตที่ซื้อไว้ล่วงหน้าในการชำระค่า API
หากเครดิตหมด API Keys อาจถูกระงับการเรียกจนกว่าจะมีเครดิตเพียงพอ
ค่าใช้จ่าย Subscription ของ Perplexity Pro หรือ Max ไม่ควรถูกนำไปถือเป็นเครดิต API โดยอัตโนมัติ
บริการหลักที่เกี่ยวข้องกับการคิดราคามีดังนี้
สำหรับสร้าง AI Applications และใช้โมเดลร่วมกับเครื่องมือ
สำหรับรับผลการค้นเว็บในรูปแบบที่โปรแกรมอ่านได้
ตัวเลือกค้นหาที่มีราคาต่อ Request ต่ำกว่า Search API ปกติ
สำหรับสร้างเวกเตอร์สำหรับ Semantic Search และ RAG
สำหรับเรียกโมเดลด้วยราคาตาม Input และ Output Tokens
| API | เหมาะกับงาน | ต้นทุนที่ต้องดู |
|---|---|---|
| Agent API | Chatbot และ AI Agent | Model + Tools |
| Search API | ค้นเว็บ | Requests |
| Fast Search | ค้นเว็บต้นทุนต่ำ | Requests |
| Embeddings API | ค้นเอกสารเชิงความหมาย | Input Tokens |
| Orchestrator API | เรียกโมเดล | Model Tokens |
หากต้องการเพียงผลการค้นเว็บ ให้เริ่มประเมิน Search API
หากต้องการ AI สรุปและตอบคำถาม ให้พิจารณา Agent API
หน้า Pricing ทางการระบุราคา Search API มาตรฐานดังนี้
US$5 ต่อ 1,000 Requests
ค่าใช้จ่าย = จำนวน Requests ที่คิดเงิน ÷ 1,000 × 5
| จำนวน Requests | ค่าใช้จ่าย |
|---|---|
| 100 | US$0.50 |
| 1,000 | US$5 |
| 5,000 | US$25 |
| 10,000 | US$50 |
| 50,000 | US$250 |
| 100,000 | US$500 |
ตัวเลขเป็นการคำนวณตามอัตรา Search API มาตรฐาน โดยสมมติว่าทุก Request เป็นรายการที่คิดค่าบริการ
Search API คิดต่อ Successful POST Request
หนึ่ง Request สามารถมี Queries ได้สูงสุดตามข้อกำหนด โดยคู่มือ Pricing ระบุว่ารองรับชุดคำค้นได้สูงสุด 5 Queries ในหนึ่ง Request
หนึ่ง Request ที่มีหลาย Queries ภายใต้ข้อกำหนดยังคงเป็นหนึ่งหน่วยคิดค่าบริการ ไม่ใช่คิดแยกตามจำนวน Queries เสมอไป
เสียเงิน หากเป็น Request ที่สำเร็จตามเกณฑ์ Billing แม้ผลค้นจะว่าง
| สถานะ Request | การคิดเงินตามคู่มือ |
|---|---|
| Successful Request มีผลค้น | คิดเงิน |
| Successful Request ไม่พบผลค้น | คิดเงิน |
| Invalid Request | ไม่คิดเงิน |
| Rate-Limited Request | ไม่คิดเงิน |
| Upstream Failure | ไม่คิดเงิน |
ผู้ใช้ส่งคำค้นที่ไม่มีข้อมูลตรงกัน
Search API ส่งสถานะสำเร็จ แต่ Results ว่าง
คำขอนั้นยังถือเป็น Successful Request ตามกติกา
ไม่ควรเขียนโปรแกรมให้ส่งคำค้นเดิมซ้ำโดยไม่มีเหตุผลเพียงเพราะผลลัพธ์ว่าง เพราะอาจสร้างค่าใช้จ่ายเพิ่มเติม
Fast Search API มีราคาต่ำกว่า Search API มาตรฐาน
US$1 ต่อ 1,000 Requests
| จำนวน Requests | Search API | Fast Search |
|---|---|---|
| 1,000 | US$5 | US$1 |
| 5,000 | US$25 | US$5 |
| 10,000 | US$50 | US$10 |
| 50,000 | US$250 | US$50 |
| 100,000 | US$500 | US$100 |
เมื่อเทียบเฉพาะค่าบริการต่อ Request ของ Search API มาตรฐาน Fast Search มีราคาต่ำกว่า 80%
ควรทดสอบผลลัพธ์จริงก่อนเลือกใช้ เพราะราคาถูกกว่าไม่ได้หมายความว่าเหมาะกับทุกคำถามและทุก Workflow
Agent API สามารถมีค่าใช้จ่ายสองส่วนหลัก
ค่าประมวลผลของโมเดล AI เช่น Input Tokens และ Output Tokens
ค่าใช้เครื่องมือ เช่น Web Search หรือ Fetch URL
Agent Cost = Model Cost + Tool Cost
หากมีค่าใช้จ่ายเฉพาะอื่นที่ระบบเรียกใช้ ต้องนำมารวมเพิ่มเติมด้วย
ผู้ใช้ถามคำถามเกี่ยวกับข่าวล่าสุด
Agent อาจ
① รับคำถาม
② เรียก Web Search
③ ดึงหน้าเว็บ
④ วิเคราะห์ข้อมูล
⑤ สร้างคำตอบ
จึงอาจมีค่าใช้จ่ายจากโมเดลและเครื่องมือหลายส่วนในคำขอเดียว
Input Tokens คือข้อมูลที่ผู้ใช้หรือระบบส่งให้โมเดล AI
Input Cost = Input Tokens ÷ 1,000,000 × Input Rate
โดย Input Rate เป็นราคา US$ ต่อ 1 ล้าน Tokens ของโมเดลที่เลือก
สมมติ Input Rate = US$1 ต่อ 1 ล้าน Tokens
ใช้ Input 10,000 Tokens
ค่า Input = US$0.01
ราคา US$1 ในตัวอย่างนี้เป็นสมมติฐานเพื่อสอนสูตร ไม่ใช่ราคาโมเดลทุกตัวของ Perplexity
Output Tokens คือข้อความหรือผลลัพธ์ที่โมเดลสร้าง
Output Cost = Output Tokens ÷ 1,000,000 × Output Rate
สมมติ Output Rate = US$4 ต่อ 1 ล้าน Tokens
โมเดลสร้าง 5,000 Output Tokens
ค่า Output = US$0.02
บางโมเดลกำหนดราคา Output ต่อ Token สูงกว่า Input
จึงควรตรวจราคาทั้งสองส่วน ไม่ดูเพียงจำนวน Input Tokens
Reasoning Tokens เกี่ยวข้องกับการประมวลผลภายในของโมเดลที่รองรับ
เอกสารทางการระบุว่า Reasoning Tokens คิดตาม Output Rate ของโมเดล
ขึ้นอยู่กับโมเดลที่เลือกและโครงสร้างราคาในหน้า Model Pricing
โมเดลมี Output Rate US$4 ต่อ 1 ล้าน Tokens
หากมี Reasoning Tokens 2,000 Tokens ที่คิดในอัตรานี้
ค่าประมวลผลส่วนดังกล่าว = US$0.008
ต้องตรวจว่า Usage ของโมเดลรายงาน Reasoning Tokens แยกหรือรวมกับยอด Output อย่างไร
ห้ามบวก Reasoning Tokens ซ้ำกับ Output Tokens หาก Usage และ Billing รวมรายการนั้นไว้แล้ว
Cache ช่วยให้ระบบนำข้อมูลที่เคยประมวลผลบางส่วนกลับมาใช้ตามความสามารถของโมเดล
เอกสารระบุว่าการอ่าน Cache คิดตาม Cache-Read Rate ของโมเดล
Cache Read Cost = Cached Tokens ÷ 1,000,000 × Cache-Read Rate
ระบบมี Instructions ยาวที่ใช้ซ้ำทุกคำขอ
หากโมเดลรองรับ Cache อาจมีต้นทุนส่วน Cached Tokens ต่ำกว่าการประมวลผล Input ใหม่
ไม่ใช่ทุกโมเดลหรือทุกคำขอจะได้ประโยชน์จาก Cache เท่ากัน
ต้องตรวจ Cache Hit และค่าใช้จ่ายจาก Usage จริง
Agent API มีค่าใช้จ่ายเพิ่มเติมเมื่อเรียก Web Search Tool
| เครื่องมือ | ราคาต่อครั้ง |
|---|---|
| Standard Web Search | US$0.0025 |
| Fast Web Search | US$0.001 |
Agent เรียก Standard Web Search 3 ครั้ง
ค่า Web Search = 3 × US$0.0025
รวม US$0.0075
ยังไม่รวม Model Tokens
ขึ้นอยู่กับ Workflow และการเรียกเครื่องมือจริง
ไม่ควรสมมติว่าหนึ่งคำถามเท่ากับหนึ่ง Web Search เสมอไป
หน้า Pricing ระบุเครื่องมือหลายประเภท
| Tool | ค่าบริการ |
|---|---|
| Standard Web Search | US$0.0025/ครั้ง |
| Fast Web Search | US$0.001/ครั้ง |
| Image Search | US$0.0025/ครั้งที่สำเร็จ |
| Fetch URL | US$0.0005/ครั้ง |
| People Search | US$0.005/ครั้ง |
| Finance Search | US$0.005/ครั้ง |
| Sandbox | US$0.03/Session |
เอกสารระบุช่วงการคิดค่าบริการของ Sandbox เป็น 20 นาทีของการใช้งานจริงต่อ Session ไม่ใช่ข้อจำกัดว่า Sandbox ต้องหยุดทำงานหลัง 20 นาที
คำขอผ่าน SDK Search ภายใน Sandbox มีค่าบริการเพิ่มตามราคาที่กำหนด
Tool Cost แยกจาก Model Token Cost
Orchestrator API คิดค่าบริการตาม Tokens ของโมเดลที่เลือก
Orchestrator Cost = Input Cost + Output Cost + Cache Cost และส่วนที่เกี่ยวข้องตาม Billing
โมเดล A มีราคา
ใช้งาน
ค่า Input = US$0.002
ค่า Output = US$0.004
รวม US$0.006 ต่อ Request
ตัวเลขอัตราโมเดล A เป็นสมมติฐาน ไม่ใช่ราคาโมเดลที่ยืนยันจากหน้า Pricing
ไม่มีคำตอบตายตัว
เหมาะกับงานที่ต้องใช้เครื่องมือและกระบวนการ AI หลายขั้นตอน
เหมาะกับการเรียกโมเดลที่รองรับโดยตรง
| ปัจจัย | Agent API | Orchestrator API |
|---|---|---|
| Model Tokens | มีค่าใช้จ่าย | มีค่าใช้จ่าย |
| Web Search Tools | อาจคิดเพิ่ม | ไม่ใช่ส่วนหลักของการเรียกโมเดลโดยตรง |
| Tool Calls | รองรับ | ตามรูปแบบบริการ |
| Complexity | สูงได้ | ขึ้นกับโมเดล |
| ต้นทุนต่อคำถาม | ขึ้นกับ Tools และ Tokens | ขึ้นกับ Tokens เป็นหลัก |
หากไม่ต้องค้นเว็บและต้องการเพียงให้โมเดลประมวลผลข้อความ Orchestrator API อาจง่ายต่อการคำนวณต้นทุน
แต่ต้องเปรียบเทียบราคาโมเดลและคุณภาพผลลัพธ์จริง
Perplexity มี Standard Embeddings และ Contextualized Embeddings
| โมเดล | Dimensions | ราคา/1 ล้าน Tokens |
|---|---|---|
| pplx-embed-v1-0.6b | 1,024 | US$0.004 |
| pplx-embed-v1-4b | 2,560 | US$0.03 |
| pplx-embed-context-v1-0.6b | 1,024 | US$0.008 |
| pplx-embed-context-v1-4b | 2,560 | US$0.05 |
Embeddings Cost = Tokens ÷ 1,000,000 × Model Rate
ใช้ 10 ล้าน Tokens กับโมเดล 0.6B มาตรฐาน
10 × US$0.004
รวม US$0.04
Credits คือยอดเงินหรือเครดิตที่ใช้ชำระค่า API ตามระบบ Billing
① ซื้อเครดิต
② เครดิตเพิ่มในบัญชี
③ เรียก API
④ ระบบคำนวณ Usage
⑤ หักเครดิต
⑥ ตรวจยอดคงเหลือ
คู่มือระบุว่า API Keys อาจถูกบล็อกการเรียกจนกว่าจะเติมเครดิต
ไม่ควรถือว่าเหมือนกัน
Perplexity Computer ในผลิตภัณฑ์ผู้ใช้ทั่วไปและ API Platform มีระบบเครดิตหรือสิทธิ์ที่ต้องตรวจแยก
ต้องตรวจชื่อบริการและประเภทเครดิตก่อนซื้อหรือวางงบประมาณ
① เปิด API Console
② เลือก Project
③ เปิด Billing
④ ตรวจ Credit Balance
⑤ เลือก Add Payment Method
⑥ กรอกข้อมูลการชำระเงินผ่านระบบที่รองรับ
⑦ ตรวจการตั้งค่า Auto Reload
⑧ ตรวจ Usage
⑨ ตรวจ Invoice History
คู่มือระบุว่าเพิ่ม Payment Method ผ่านระบบ Stripe ได้ โดยการเพิ่มบัตรไม่ใช่การเรียกเก็บเงินทันทีเพียงเพราะเพิ่มข้อมูล
การเปิด Auto Reload อาจทำให้ระบบเติมเครดิตเพิ่มเมื่อยอดต่ำกว่าเกณฑ์ที่กำหนด
จึงต้องตรวจวงเงินและขั้นตอนอนุมัติขององค์กร
Auto Reload คือระบบเติมเครดิตอัตโนมัติเมื่อยอดคงเหลือต่ำกว่าระดับที่กำหนด
หากระบบมีคำขอผิดปกติหรือถูกใช้งานโดยไม่ได้รับอนุญาต Auto Reload อาจเพิ่มค่าใช้จ่าย
① เริ่มจากเครดิตจำนวนที่รับความเสี่ยงได้
② ปิด Auto Reload ระหว่างทดสอบเมื่อเหมาะสม
③ ตรวจ Usage ทุกวันในช่วงแรก
④ ใช้ Backend Rate Limiting
⑤ ตั้งงบประมาณและแจ้งเตือนภายใน
ไม่ใช่
Auto Reload ทำหน้าที่เติมเครดิต ส่วน Budget Limit เป็นมาตรการควบคุมค่าใช้จ่าย
ทั้งสองมีวัตถุประสงค์ต่างกัน
API Project เป็นพื้นที่สำหรับจัดการบริการ API
Project A: Website Chatbot
Project B: SEO Research
Project C: Market Research
เพื่อให้วิเคราะห์ต้นทุนและการใช้งานแต่ละระบบได้สะดวก
การสร้าง Project ไม่ควรถือว่าเป็นการกำหนดวงเงินสูงสุดของ Project โดยอัตโนมัติ
ต้องตรวจ Budget Controls และ Rate Limits ที่รองรับจริง
Usage Tiers คือระดับการใช้งาน API ที่สัมพันธ์กับยอดซื้อเครดิตสะสม
| Tier | ยอดซื้อเครดิตสะสม |
|---|---|
| Tier 0 | US$0 |
| Tier 1 | US$50 ขึ้นไป |
| Tier 2 | US$250 ขึ้นไป |
| Tier 3 | US$500 ขึ้นไป |
| Tier 4 | US$1,000 ขึ้นไป |
| Tier 5 | US$5,000 ขึ้นไป |
Tier คำนวณจากยอดซื้อเครดิตสะสมตลอดช่วงการใช้บัญชี ไม่ใช่เครดิตคงเหลือในปัจจุบัน
ไม่ควรนำ Usage Tier ไปตีความเป็นแพ็กเกจรายเดือน
ต้องดูเงื่อนไขเครดิตและ Billing แยกต่างหาก
โดยทั่วไปได้รับ Rate Limits สูงขึ้นและอาจเข้าถึงฟีเจอร์เพิ่มเติมตามนโยบาย
Rate Limits คือข้อจำกัดจำนวนคำขอหรือปริมาณ Tokens ภายในช่วงเวลาหนึ่ง
QPS — Queries per Second
จำนวนคำขอในหนึ่งวินาที
TPM/TPH — Tokens per Minute/Hour
จำนวน Tokens ภายในช่วงเวลาที่กำหนด
| Tier | QPS |
|---|---|
| Tier 0 | 1 |
| Tier 1 | 3 |
| Tier 2 | 8 |
| Tier 3 | 17 |
| Tier 4 | 33 |
| Tier 5 | 33 |
Rate Limits ใช้ร่วมกันในระดับองค์กรตามข้อกำหนด แม้ใช้ API Keys หลายชุด
การสร้าง Key เพิ่มไม่ได้หมายความว่าจะได้โควตาเพิ่มเท่าตัว
Rate Limits ไม่ได้กำหนดราคาต่อ Token โดยตรง แต่มีผลต่อปริมาณการใช้งานที่ระบบรองรับ
เว็บไซต์มีผู้ใช้ส่งคำถามพร้อมกันจำนวนมาก
หากเกิน QPS หรือ Token Limits ระบบอาจตอบ Error 429
① ตรวจ Tier
② ใช้ Queue
③ ใช้ Caching
④ กำหนด Retry-After
⑤ ใช้ Backoff
⑥ จำกัดคำขอต่อผู้ใช้
Search API ระบุว่า Rate-Limited Requests ไม่ถูกคิดค่าบริการ
แต่การ Retry ที่สำเร็จภายหลังอาจเป็นคำขอที่คิดค่าบริการตามเงื่อนไข
Budget คือกรอบค่าใช้จ่ายที่ผู้ใช้หรือองค์กรยอมรับได้
① กำหนดงบประมาณรายเดือน
② กำหนดงบประมาณรายวัน
③ ประมาณ Requests
④ เลือก API
⑤ คำนวณค่า Model Tokens
⑥ คำนวณ Tool Calls
⑦ เผื่อส่วนเพิ่มสำหรับ Retry และการเติบโต
⑧ ตรวจยอดเครดิต
⑨ ตั้งแจ้งเตือนเมื่อระบบรองรับ
⑩ ตรวจค่าใช้จ่ายตามรอบ
กำหนดงบ API เดือนละ US$50
แบ่งเป็น
หากไม่มี Hard Spending Cap ที่ระบบรองรับ ต้องกำหนดการตัดการเรียก API จาก Backend หรือระบบควบคุมของตนเอง
Total Agent Cost = Input Cost + Output Cost + Cache Cost + Tool Cost + ค่าใช้จ่ายอื่นที่เกี่ยวข้อง
หากโมเดลคิด Reasoning แยก ให้ตรวจวิธีรายงาน Usage และนำมาคำนวณตามกติกาของโมเดลโดยไม่บวกซ้ำ
Input Cost = Input Tokens ÷ 1,000,000 × Input Rate
Output Cost = Output Tokens ÷ 1,000,000 × Output Rate
Cache Cost = Cached Tokens ÷ 1,000,000 × Cache Rate
Web Search Cost = จำนวน Search Calls × ราคาต่อ Call
Fetch Cost = จำนวน Fetch Calls × ราคาต่อ Call
Input = 2,000 ÷ 1,000,000 × 1 = US$0.002
Cache = 1,000 ÷ 1,000,000 × 0.20 = US$0.0002
Output = 500 ÷ 1,000,000 × 4 = US$0.002
Search = 2 × 0.0025 = US$0.005
Fetch = 1 × 0.0005 = US$0.0005
รวม US$0.0097 ต่อ Request
ราคาโมเดลและปริมาณ Tokens ทั้งหมดในตัวอย่างนี้เป็นสมมติฐาน ส่วนอัตรา Standard Web Search และ Fetch URL ใช้อัตราที่ระบุในหน้า Pricing ทางการ ณ วันที่ตรวจสอบ
ราคาจาก API Documentation แสดงเป็นดอลลาร์สหรัฐ
หากต้องทำ Budget เป็นเงินบาท ให้ใช้อัตราแลกเปลี่ยนสำหรับการวางแผน และตรวจอัตราชำระเงินจริงอีกครั้ง
1 ดอลลาร์สหรัฐ = 35 บาท
ตัวเลขนี้ใช้เพื่อสอนการคำนวณเท่านั้น ไม่ใช่อัตราแลกเปลี่ยนปัจจุบันที่ยืนยัน
ค่าใช้จ่ายเงินบาท = ค่าใช้จ่าย US$ × อัตราแลกเปลี่ยน
| ค่าใช้จ่าย US$ | บาทที่อัตราสมมติ 35 บาท/US$ |
|---|---|
| US$1 | 35 บาท |
| US$5 | 175 บาท |
| US$10 | 350 บาท |
| US$25 | 875 บาท |
| US$50 | 1,750 บาท |
| US$100 | 3,500 บาท |
ยังไม่รวมภาษี ค่าธรรมเนียมบัตร หรือส่วนต่างอัตราแลกเปลี่ยน
สมมติเว็บไซต์มี Chatbot ใช้ Agent API
Input = US$0.001
Output = US$0.002
Search = US$0.0025
รวม US$0.0055 ต่อคำถาม
| จำนวนคำถาม/เดือน | ค่าใช้จ่าย US$ | บาทที่อัตราสมมติ 35 |
|---|---|---|
| 1,000 | US$5.50 | 192.50 บาท |
| 5,000 | US$27.50 | 962.50 บาท |
| 10,000 | US$55 | 1,925 บาท |
| 50,000 | US$275 | 9,625 บาท |
ตัวเลขทั้งหมดเป็นต้นทุนจำลอง ไม่ใช่ใบเสนอราคาหรือราคาต่อคำถามที่รับประกันของ Perplexity
สมมติระบบต้องใช้ Search API เพื่อค้นแหล่งข้อมูลประกอบ Content Brief
10,000 Successful Requests
ราคา US$5/1,000 Requests
รวม US$50
10,000 Successful Requests
ราคา US$1/1,000 Requests
รวม US$10
สมมติใช้ Orchestrator API เพิ่ม
ต้นทุนโมเดลต่อ Request = US$0.006
หากสรุป 1,000 ครั้ง
ต้นทุนโมเดล = US$6
| รายการ | ค่าใช้จ่าย |
|---|---|
| Fast Search 10,000 Requests | US$10 |
| สรุปด้วยโมเดล 1,000 ครั้ง | US$6 |
| รวม | US$16 |
| บาทที่อัตราสมมติ 35 | 560 บาท |
การค้นข้อมูลเพื่อ SEO ไม่ได้ทำให้ได้รับข้อมูล Google Search Volume, CTR หรืออันดับเว็บไซต์โดยอัตโนมัติ
ต้องใช้แหล่งข้อมูลเฉพาะสำหรับสถิติเหล่านั้น
สมมติระบบวิเคราะห์ตลาดใช้ Agent API พร้อม Web Search
Input = US$0.01
Output = US$0.02
Web Search = US$0.0125
Fetch URL = US$0.005
รวม US$0.0475 ต่อรายงาน
100 × US$0.0475
รวม US$4.75
US$4.75 × 35
ประมาณ 166.25 บาท
นี่เป็นแบบจำลองสำหรับการสอนสูตรเท่านั้น งาน Research จริงอาจมีการเรียกโมเดลและเครื่องมือหลายรอบ จึงมีต้นทุนต่างจากตัวอย่างมาก
| งาน | หน่วยวัดในตัวอย่าง | ต้นทุนสมมติ |
|---|---|---|
| Chatbot | 10,000 คำถาม | US$55 |
| SEO Fast Search + Summary | 10,000 Search + 1,000 Summaries | US$16 |
| Business Research | 100 Reports | US$4.75 |
ตัวเลขนี้ไม่ใช่การทดสอบ Benchmark จริง
แต่เป็นการแสดงผลลัพธ์จากปริมาณงานและสมมติฐานที่กำหนดไว้ในแต่ละกรณี
ไม่ควร
ต้องทดลองกับ Prompt และ Usage ที่ใกล้เคียงระบบจริงก่อน
แนะนำให้แยก Cost Model เป็น 4 ส่วน
จำนวนคำถามหรือ Requests
Input, Output และ Cached Tokens
จำนวน Web Search, Fetch URL และเครื่องมืออื่น
ค่า Hosting, Database, Monitoring และค่าใช้จ่ายอื่น
| ตัวแปร | ความหมาย |
|---|---|
| Requests | จำนวนคำขอ |
| Avg Input Tokens | Tokens ขาเข้าเฉลี่ย |
| Avg Output Tokens | Tokens ขาออกเฉลี่ย |
| Input Rate | ราคา Input/ล้าน Tokens |
| Output Rate | ราคา Output/ล้าน Tokens |
| Search Calls | จำนวนครั้งเรียก Search |
| Search Rate | ราคาต่อครั้ง |
| Fetch Calls | จำนวนครั้งเรียก Fetch |
| Fetch Rate | ราคาต่อครั้ง |
| FX Rate | อัตราแลกเปลี่ยน |
| Overhead | ค่าใช้จ่ายอื่น |
เก็บข้อมูล Usage จริงจากระบบแล้วนำมาแทนสมมติฐานใน Cost Model
กำหนด
=B2/1000*B3
=B2/1000*B3*B4
B2 = 10000
B3 = 5
B4 = 35
ผลลัพธ์ค่าใช้จ่าย US$ = 50
ผลลัพธ์เงินบาท = 1750
เปลี่ยน B3 เป็น 1 ตามราคา Fast Search ที่ตรวจสอบได้
กำหนดเซลล์ดังนี้
| เซลล์ | ข้อมูล |
|---|---|
| B2 | Uncached Input Tokens |
| B3 | Cached Input Tokens |
| B4 | Output Tokens |
| B5 | Input Rate/1M |
| B6 | Cached Rate/1M |
| B7 | Output Rate/1M |
| B8 | Web Search Calls |
| B9 | Web Search Rate/Call |
| B10 | Fetch Calls |
| B11 | Fetch Rate/Call |
| B12 | FX Rate |
=(B2/1000000*B5)+(B3/1000000*B6)+(B4/1000000*B7)+(B8*B9)+(B10*B11)
=((B2/1000000*B5)+(B3/1000000*B6)+(B4/1000000*B7)+(B8*B9)+(B10*B11))*B12
หากต้นทุนต่อ Request อยู่ B13 และจำนวน Requests อยู่ B14
=B13*B14
สูตรนี้เป็นแบบจำลองสำหรับงานที่มีองค์ประกอบตามตารางเท่านั้น
หากใช้ Reasoning หรือ Tools อื่น ต้องตรวจ Usage และเพิ่มต้นทุนตามโครงสร้างจริงโดยไม่คิดซ้ำ
กำหนด
=B2/1000000*B3
=B2/1000000*B3*B4
B2 = 10000000
B3 = 0.004
B4 = 35
ค่า Embeddings = US$0.04
คิดเป็น 1.40 บาทตามอัตราแลกเปลี่ยนสมมติ
ค่าจัดเก็บ Vector Database และค่าโมเดลสร้างคำตอบหลังการค้นข้อมูล
① เก็บจำนวน Requests จริง
② คำนวณ Average Cost per Request
③ ตรวจ Peak Usage
④ ประมาณการเติบโต
⑤ เผื่อ Usage Variance
⑥ คำนวณงบรายเดือน
⑦ ตรวจ Credit Balance
⑧ กำหนดการแจ้งเตือน
Forecast Cost = Expected Requests × Average Cost per Request
สมมติ Chatbot มี
Forecast = US$120 ต่อเดือน
120 × 1.20
งบวางแผน = US$144
ส่วนเผื่อ 20% เป็นสมมติฐานในการวางแผน ไม่ใช่มาตรฐานที่ Perplexity กำหนด
ไม่ต้องใช้ Agent หากต้องการเพียงผลค้นเว็บ
ลดต้นทุนต่อ Request ในงานที่ไม่จำเป็นต้องใช้ Search มาตรฐาน
ลดคำตอบยาวเกินจำเป็น
ใช้ Instructions ที่กระชับ
ลดต้นทุนข้อมูลซ้ำ
ไม่ให้ Agent ค้นเว็บซ้ำโดยไม่มีเหตุผล
ลดผลค้นที่ไม่เกี่ยวข้อง
ระบุ Workflow ที่มีต้นทุนสูง
จัดงานให้มีประสิทธิภาพตามข้อกำหนด API
ไม่ใช้ผลลัพธ์ของผู้ใช้รายหนึ่งปะปนกับอีกคน
เว็บไซต์ WordPress อาจมีผู้เข้าชมจำนวนมาก
หากเปิด Chatbot ให้ทุกคนถามโดยไม่มีข้อจำกัด อาจมี API Requests เพิ่มขึ้นรวดเร็ว
① จำกัด Requests ต่อ IP หรือบัญชี
② ใช้ Rate Limiting
③ ใช้ CAPTCHA เมื่อเหมาะสม
④ จำกัดความยาว Input
⑤ จำกัด Output Tokens
⑥ ใช้ Cache
⑦ ตรวจ Usage
⑧ ตั้ง Budget
⑨ เก็บ API Key ฝั่ง Server
⑩ ตรวจ Abuse
เว็บไซต์มีผู้ใช้ 5,000 คนต่อเดือน
หากแต่ละคนถามเฉลี่ย 3 คำถาม
จะมี 15,000 คำถามต่อเดือน
ต้องนำจำนวนดังกล่าวไปคูณต้นทุนเฉลี่ยต่อคำถามของระบบจริง
ห้ามฝัง API Key ไว้ใน JavaScript ที่ผู้เข้าชมตรวจดูได้
หาก API Key รั่วหรือระบบถูกนำไปใช้โดยไม่ได้รับอนุญาต อาจเกิดค่าใช้จ่ายผิดปกติ
① ใช้ Secret Manager
② จำกัดสิทธิ์
③ ไม่เปิด API Key ให้ Frontend
④ จำกัด Requests
⑤ ตรวจ Usage
⑥ ตั้ง Alert
⑦ กำหนด Timeout
⑧ กำหนด Retry Limit
⑨ ตรวจ Logs
⑩ Revoke Key หากสงสัยว่ารั่วไหล
การป้องกัน Abuse เป็นส่วนหนึ่งของการควบคุมต้นทุน ไม่ใช่เฉพาะเรื่องความปลอดภัยเท่านั้น
“ตอบคำถามนี้เป็นภาษาไทยไม่เกิน 5 ประเด็น ใช้ข้อมูลที่จำเป็นและระบุความไม่แน่นอน หลีกเลี่ยงคำอธิบายซ้ำ”
“ค้นเฉพาะข้อมูลที่เกี่ยวข้องกับหัวข้อนี้ และใช้แหล่งข้อมูลที่ตรวจสอบได้ หลีกเลี่ยงการค้นซ้ำเมื่อมีหลักฐานเพียงพอ”
“สร้าง Content Brief แบบกระชับโดยแยก Search Intent, Key Questions และ Facts to Verify ห้ามสร้างตัวเลข Search Volume ที่ไม่มีหลักฐาน”
“สรุปข้อมูลตลาดจากแหล่งที่เชื่อถือได้ แยกข้อเท็จจริง สมมติฐาน และข้อเสนอ โดยไม่สร้างตัวเลข”
“ตอบคำถามลูกค้าอย่างกระชับจากข้อมูลที่ได้รับอนุมัติเท่านั้น หากไม่พบราคา ให้แนะนำให้ขอใบเสนอราคา”
“สร้างคำตอบทดสอบที่มีโครงสร้างชัดเจนและสั้นพอสำหรับตรวจสอบ Request/Response และ Token Usage”
Prompt ช่วยกำหนดรูปแบบคำตอบ แต่การลดค่าใช้จ่ายอย่างแท้จริงควรควบคุม Model, Tools และ Max Tokens ผ่าน API Parameters ตามที่รองรับ
“Answer accurately and concisely. Avoid unnecessary repetition and clearly state uncertainty.”
“Use only the necessary search tools and cite reliable evidence. Avoid redundant searches.”
“Create a concise SEO content brief. Do not invent search volume, rankings, or traffic data.”
“Summarize verified business information and separate facts, estimates, assumptions, and recommendations.”
“Answer using approved documentation. Keep responses focused and do not invent prices or guarantees.”
“Complete the task with only necessary tool calls while maintaining source verification and factual accuracy.”
Chatbot, Search, SEO หรือ Business Research
Agent, Search, Fast Search, Embeddings หรือ Orchestrator
ตรวจราคา Model และ Tools
แยกงานตามระบบ
เพิ่ม Payment Method ตามขั้นตอน
เริ่มจากวงเงินที่เหมาะสม
ใช้คำถามจริงจำนวนเล็กน้อย
ตรวจ Tokens และ Tool Calls
หารค่าใช้จ่ายด้วยจำนวนงานที่สำเร็จ
ประมาณการจำนวน Requests รายเดือน
ตั้งงบรายวันและรายเดือน
เปิดเมื่อมีมาตรการที่เหมาะสม
กำหนด Queue และ Retry Policy
ป้องกัน API Key และ Abuse
ติดตามต้นทุนและคุณภาพต่อเนื่อง
| รายการตรวจสอบ | สถานะ |
|---|---|
| ① เลือก Use Case | ☐ |
| ② เลือก API ให้เหมาะสม | ☐ |
| ③ ตรวจ Pricing ล่าสุด | ☐ |
| ④ ตรวจ Model Rates | ☐ |
| ⑤ ตรวจ Input Tokens | ☐ |
| ⑥ ตรวจ Output Tokens | ☐ |
| ⑦ ตรวจ Reasoning Tokens | ☐ |
| ⑧ ตรวจ Cache Rates | ☐ |
| ⑨ ตรวจ Tool Calls | ☐ |
| ⑩ ตรวจ Search API Rate | ☐ |
| ⑪ ตรวจ Fast Search Rate | ☐ |
| ⑫ ตรวจ Embeddings Rate | ☐ |
| ⑬ ตรวจ Orchestrator Rate | ☐ |
| ⑭ สร้าง API Project | ☐ |
| ⑮ ตั้ง Billing | ☐ |
| ⑯ ตรวจ Credit Balance | ☐ |
| ⑰ ตรวจ Auto Reload | ☐ |
| ⑱ ตรวจ Usage Tier | ☐ |
| ⑲ ตรวจ Rate Limits | ☐ |
| ⑳ ตั้ง Request Limits | ☐ |
| ㉑ ตั้ง Token Limits ตามที่รองรับ | ☐ |
| ㉒ ตั้ง Retry Policy | ☐ |
| ㉓ จำกัด Duplicate Requests | ☐ |
| ㉔ ตรวจ API Key Security | ☐ |
| ㉕ ตรวจ Data Privacy | ☐ |
| ㉖ ตรวจ Cache Privacy | ☐ |
| ㉗ คำนวณต้นทุน US$ | ☐ |
| ㉘ คำนวณต้นทุน THB | ☐ |
| ㉙ เผื่อภาษีและค่าธรรมเนียม | ☐ |
| ㉚ ตั้ง Monthly Budget | ☐ |
| ㉛ ติดตาม Usage | ☐ |
| ㉜ ทดสอบ Chatbot | ☐ |
| ㉝ ทดสอบ SEO Workflow | ☐ |
| ㉞ ทดสอบ Research Workflow | ☐ |
| ㉟ ตรวจ Cost per Request | ☐ |
| ㊱ ตรวจคุณภาพคำตอบ | ☐ |
| ㊲ ทบทวนราคาเป็นระยะ | ☐ |
คิดตามการใช้งานจริง โดยแต่ละ API มีหน่วยราคาแตกต่างกัน เช่น Requests, Tokens และ Tool Calls
ต้องตรวจเครดิตและเงื่อนไข API Platform โดยทั่วไปเป็นระบบใช้เครดิตตามการใช้งาน ไม่ใช่ฟรีไม่จำกัด
คู่มือ Billing ระบุระบบซื้อเครดิตล่วงหน้าและหักเครดิตจากการใช้งาน API
ไม่ควรถือว่า Pro Subscription รวม API ฟรีไม่จำกัด
API Platform มี Billing และเงื่อนไขแยกจาก Subscription
ต้องตรวจข้อตกลงที่ใช้จริง ไม่ควรสรุปว่ารวม API ทุกประเภท
US$5 ต่อ 1,000 Requests ตามหน้า Pricing ที่ตรวจสอบ
US$1 ต่อ 1,000 Requests ตามหน้า Pricing
คิดตาม Successful POST Request ไม่ใช่คิดต่อทุก Query ใน Request เสมอไป
คิดหากเป็น Successful Request แม้ไม่มี Results
คู่มือ Search API ระบุว่า Rate-Limited Requests ไม่ถูกคิดค่าบริการ
คิดตามโมเดล Tokens และค่าเครื่องมือที่เรียกใช้
คือข้อมูลที่ส่งให้โมเดลประมวลผล
คือข้อมูลที่โมเดลสร้างกลับมา
อาจมีค่าใช้จ่ายตามโมเดลและ API โดย Orchestrator ระบุว่าคิดตาม Output Rate
เป็น Tokens ที่ระบบนำข้อมูลจาก Cache กลับมาใช้ตามความสามารถที่รองรับ
Standard Web Search US$0.0025 ต่อครั้ง และ Fast Web Search US$0.001 ต่อครั้ง
US$0.0005 ต่อครั้งตามหน้า Pricing
US$0.03 ต่อ Session ตามช่วงคิดค่าบริการที่กำหนด และอาจมีค่า Search ภายใน Sandbox เพิ่ม
เอกสารระบุว่าคิดตาม Tokens ของโมเดลโดยไม่มีค่าบริการต่อ Request เพิ่มโดยตรง
ขึ้นอยู่กับโมเดล โดยรุ่น 0.6B มาตรฐานเริ่ม US$0.004 ต่อ 1 ล้าน Tokens
ใช้ระบบเครดิตตามเอกสาร Projects & Billing
เป็นระบบเติมเครดิตอัตโนมัติเมื่อยอดต่ำกว่าเกณฑ์ที่กำหนด
คู่มือระบุว่า API Keys อาจถูกบล็อกจนกว่าจะเพิ่มเครดิต
เป็นระดับการใช้งานที่สัมพันธ์กับยอดซื้อเครดิตสะสมและส่งผลต่อ Rate Limits
เริ่มจากยอดซื้อเครดิตสะสม US$50
เริ่มจากยอดซื้อเครดิตสะสม US$250
เอกสาร Usage Tiers เน้นสิทธิ์ด้าน Rate Limits ไม่ควรถือว่าราคาต่อ Token ลดลงอัตโนมัติ
เป็นข้อจำกัดความถี่คำขอหรือปริมาณ Tokens ตาม Tier และ Endpoint
ไม่ใช่เสมอไป เพราะ Agent API ใช้ข้อจำกัดร่วมกันในระดับองค์กรตามคู่มือ
ขึ้นอยู่กับจำนวนคำถาม โมเดล Tokens และ Tool Calls ต้องคำนวณจาก Usage จริง
ขึ้นอยู่กับจำนวน Search Requests และการประมวลผลเพิ่มเติมด้วย AI
ขึ้นอยู่กับจำนวนการค้นเว็บและการประมวลผล ไม่สามารถระบุราคาต่อรายงานตายตัวได้
นำค่าใช้จ่าย US$ คูณอัตราแลกเปลี่ยนที่ใช้วางแผน และตรวจภาษีหรือค่าธรรมเนียมเพิ่ม
ได้ โดยสร้างสูตรจาก Requests, Tokens, Model Rates และ Tool Calls
ไม่รวม Hosting ของเว็บไซต์หรือระบบที่ผู้ใช้พัฒนาเอง
ไม่รวมต้นทุน Database หรือ Vector Storage ภายนอกที่ผู้ใช้เลือก
ขึ้นอยู่กับความจำเป็นในการทำงานต่อเนื่องและมาตรการควบคุมค่าใช้จ่าย
ใช้ Rate Limiting, Caching, Token Controls, Budget Monitoring และรักษา API Key
เลือก API ให้ตรงงาน ทดลองด้วย Requests จำนวนน้อย วัดต้นทุนต่อผลลัพธ์ แล้วจึงค่อยขยายระบบ
Perplexity API คิดค่าบริการตามประเภท API และปริมาณการใช้งานจริง โดยไม่ได้มีราคาเหมาจ่ายต่อคำถามเท่ากันทุกบริการ
Search API คิดตาม Successful Requests ที่ราคา US$5 ต่อ 1,000 Requests ส่วน Fast Search คิด US$1 ต่อ 1,000 Requests
Agent API คิดค่าประมวลผลโมเดลตาม Tokens และค่าเครื่องมือที่เรียก เช่น Web Search หรือ Fetch URL
Embeddings API คิดตามจำนวน Tokens ที่นำไปสร้างเวกเตอร์ ส่วน Orchestrator API คิดตามอัตรา Input, Output และ Cache ของโมเดลโดยไม่มีค่าธรรมเนียมต่อ Request เพิ่มโดยตรง
Perplexity API ใช้ระบบเครดิตที่ซื้อไว้ล่วงหน้า โดยสามารถตรวจ Billing, Usage, Invoice และ Auto Reload ผ่าน API Console
Usage Tiers เพิ่มสิทธิ์ด้าน Rate Limits ตามยอดซื้อเครดิตสะสม ซึ่งไม่ใช่แพ็กเกจรายเดือนแบบ Pro หรือ Max
สำหรับผู้พัฒนาเว็บไซต์และเจ้าของธุรกิจ ควรวาง Cost Model ก่อนเปิดให้ผู้ใช้จำนวนมาก โดยคำนวณจำนวน Requests, Tokens, Tool Calls และค่าใช้จ่ายระบบภายนอกทั้งหมด
คำแนะนำจาก ComSiam: ใช้ขั้นตอน กำหนด Use Case → เลือก API → ตรวจ Pricing → ทดลอง Requests → วัด Tokens/Tools → คำนวณ Cost per Request → สร้าง Excel Budget → ตรวจเครดิต → จำกัดการใช้งาน → ติดตาม Usage → ปรับปรุงต้นทุน
หากสร้าง Chatbot ควรตรวจต้นทุนเฉลี่ยต่อคำถามจริง หากทำ SEO Research ให้ประเมิน Search API กับ Fast Search และหากทำ Business Research ให้ตรวจจำนวนครั้งที่ Agent เรียกเครื่องมือ
ตัวอย่างราคาเงินบาทในบทความใช้อัตราแลกเปลี่ยนสมมติ 35 บาทต่อดอลลาร์ เพื่อสอนวิธีวางงบประมาณเท่านั้น ไม่ใช่อัตราแลกเปลี่ยนหรือใบเสนอราคาจริง
ท้ายที่สุด การใช้งาน Perplexity API อย่างคุ้มค่าไม่ได้ขึ้นอยู่กับการเลือกบริการที่ราคาถูกที่สุดเสมอไป แต่ต้องพิจารณา คุณภาพผลลัพธ์ ความถูกต้องของข้อมูล ความเร็ว ความปลอดภัย และต้นทุนรวมต่อหนึ่งงานที่สำเร็จ