AI หนึ่งคำถามใช้ไฟและน้ำแค่ไหน?

เวลาผมพิมพ์คำถามลงในแชต แล้วคำตอบปรากฏขึ้นในไม่กี่วินาที มันง่ายมากที่จะรู้สึกว่าคำตอบนั้นเกิดขึ้นอยู่บนหน้าจอเลย แต่ก่อนจะมาถึงหน้าจอ คำถามต้องเดินทางผ่านเครือข่าย เข้าเครื่องคอมพิวเตอร์ที่มีชิปสำหรับ AI ผ่านระบบไฟฟ้า และผ่านระบบที่ต้องจัดการความร้อนจากการคำนวณทั้งหมด

คำถามที่น่าสนใจจึงไม่ใช่แค่ “AI ตอบได้เร็วแค่ไหน?” แต่คือ “เบื้องหลังคำตอบหนึ่งครั้งใช้ทรัพยากรอะไรบ้าง และเรารู้ตัวเลขนั้นได้แม่นแค่ไหน?”

คำตอบสั้น ๆ: ไม่มีเลขเดียวที่ใช้แทนทุก Prompt

ถ้าถามว่า Prompt หนึ่งครั้งใช้ไฟกี่หน่วยหรือใช้น้ำกี่หยด คำตอบที่ซื่อสัตย์ที่สุดคือ ขึ้นอยู่กับระบบและขอบเขตที่เรากำลังวัด คำถามสั้นกับเอกสารยาวไม่ใช่งานเดียวกัน โมเดลเล็กกับโมเดลใหญ่ไม่ใช้การคำนวณเท่ากัน และคำตอบธรรมดากับงานที่ต้องคิดหลายรอบก็ไม่เท่ากัน

ตัวเลขต่อ Prompt จึงควรอ่านเป็นค่าของกรณีศึกษาที่มีวิธีวัดชัดเจน ไม่ใช่ใบเสร็จสากลของ AI ทุกตัวบนโลก

จากคำถามไปสู่คำตอบ มีอะไรเกิดขึ้นบ้าง?

ลองย่อเส้นทางให้เห็นภาพก่อน

Prompt จากผู้ใช้
      ↓
Tokenization และการเตรียม Context
      ↓
Model Inference บน GPU / TPU / AI Accelerator
      ↓
CPU, Memory, Network และระบบจัดเก็บข้อมูล
      ↓
Power Distribution และ Cooling
      ↓
คำตอบที่ส่งกลับมาถึงผู้ใช้

Prompt ไม่ได้ถูกส่งเข้าโมเดลเป็นก้อนคำที่มนุษย์เห็นเสมอไป ระบบจะแบ่งข้อความออกเป็นหน่วยเล็ก ๆ ที่เรียกว่า Token จากนั้นนำ Token เดิม บทสนทนาก่อนหน้า เอกสารที่ค้นคืนได้ และคำสั่งของระบบมารวมเป็น Context

เมื่อเริ่ม Inference โมเดลจะคำนวณว่า Token ถัดไปควรเป็นอะไร กระบวนการนี้เกิดซ้ำไปเรื่อย ๆ จนได้คำตอบครบ ดังนั้นความยาวของ Input, ความยาวของ Context และจำนวน Output Tokens ล้วนมีผลต่อปริมาณงาน

GPU ไม่ได้ทำงานอยู่คนเดียว

เวลาเราพูดว่า AI ใช้ GPU คำนี้ช่วยให้เห็นภาพ แต่ยังไม่ครบทั้งระบบ GPU หรือ TPU เป็นตัวเร่งการคำนวณหลัก ส่วน CPU ช่วยจัดการงานรอบข้าง Memory เก็บข้อมูลที่กำลังใช้งาน Network รับส่ง Context และผลลัพธ์ และ Storage เก็บ Model กับข้อมูลที่ระบบต้องเรียกใช้

Data Center ยังต้องเตรียมเครื่องสำรองและ Capacity บางส่วนไว้รับ Traffic ที่เปลี่ยนแปลงหรือรองรับความเสียหาย เครื่องที่เปิดรอแต่ยังไม่ได้ทำงานเต็มที่ก็มีต้นทุนพลังงานของมันเอง นี่เป็นเหตุผลที่การวัดเฉพาะชิปที่กำลังคำนวณอาจมองเห็นเพียงบางส่วนของต้นทุนการให้บริการจริง

ไฟฟ้ากลายเป็นความร้อนได้อย่างไร?

อุปกรณ์ดิจิทัลไม่ได้เปลี่ยนไฟฟ้าให้กลายเป็นคำตอบโดยไม่มีผลข้างเคียง ไฟฟ้าส่วนใหญ่ที่อุปกรณ์ใช้จะจบลงเป็นความร้อน ความร้อนนี้ต้องถูกพาออกจากชิปและห้อง Server เพื่อให้ระบบทำงานได้ต่อเนื่อง

ระบบ Cooling อาจใช้ลม น้ำ หรือการผสมกันหลายแบบ บาง Data Center ใช้ Chilled Water หรือ Cooling Tower บางแห่งใช้ระบบ Liquid Cooling ที่นำของเหลวเข้าใกล้แหล่งความร้อนมากขึ้น และบางสภาพอากาศอาจใช้วิธีที่ลดการใช้น้ำได้ แต่เพิ่มความต้องการไฟฟ้าหรือมี Trade-off ด้านการออกแบบอื่น

ตัวชี้วัดที่ใช้คุยเรื่องไฟฟ้าของอาคารคือ PUE (Power Usage Effectiveness) ซึ่งเปรียบเทียบไฟฟ้ารวมของ Data Center กับไฟฟ้าที่ใช้กับอุปกรณ์ IT โดยตรง ส่วนตัวชี้วัดน้ำที่ใช้กับ Site มักเรียกว่า WUE (Water Usage Effectiveness) การมี PUE หรือ WUE ต่ำลงเป็นสัญญาณที่ดีในขอบเขตนั้น แต่ไม่ได้ทำให้เราสรุปแทนทุกสถานที่ได้

น้ำที่เกี่ยวข้องกับ AI มีอย่างน้อยสองทาง

ทางแรกคือ Direct Water Use น้ำที่ใช้ในสถานที่จริง เช่น ระบบ Cooling และการระบายความร้อน ปริมาณนี้ขึ้นกับเทคโนโลยี Cooling สภาพอากาศ การออกแบบอาคาร และกฎหรือข้อจำกัดของพื้นที่

ทางที่สองคือ Indirect Water Use น้ำที่เกี่ยวข้องกับการผลิตไฟฟ้าที่ Data Center ใช้ โรงไฟฟ้าแต่ละประเภทใช้และสูญเสียน้ำไม่เท่ากัน พื้นที่เดียวกันที่รับไฟจาก Grid คนละแบบจึงอาจมีผลกระทบทางน้ำต่างกัน แม้ Server จะทำงานเหมือนกัน

คำว่า “AI ใช้น้ำกี่หยด?” จึงต้องถามต่อว่า นับเฉพาะน้ำที่ใช้ระบายความร้อนหรือรวม Water Footprint จากการผลิตไฟฟ้าด้วย? นับน้ำที่ถูกดึงมาใช้หรือน้ำที่ถูกบริโภคและไม่กลับเข้าสู่วงจรเดิม? ถ้าไม่กำหนดขอบเขต ตัวเลขสองตัวอาจดูเหมือนขัดกันทั้งที่กำลังวัดคนละเรื่อง

ตัวเลข 0.24 Wh บอกอะไร และไม่ได้บอกอะไร?

ในเดือนสิงหาคม 2025 Google Cloud เผยวิธีวัดผลกระทบของการทำ Inference ใน Gemini Apps และประเมินว่า Median Text Prompt ใช้พลังงาน 0.24 Wh และใช้น้ำ 0.26 mL หรือประมาณห้าหยด ตัวเลขนี้อ้างอิงการวิเคราะห์ข้อมูลเดือนพฤษภาคม 2025 และเป็นกรณีศึกษาของ Gemini Apps ไม่ใช่ค่าเฉลี่ยของ AI ทุกผู้ให้บริการ

จุดสำคัญของวิธีวัดนี้คือ Google อธิบายว่าการคำนวณแบบครอบคลุมรวมองค์ประกอบอย่างเครื่องที่เตรียมไว้แต่ยังไม่ถูกใช้งาน CPU และ RAM รวมถึงพลังงานส่วนเกินของ Data Center และการใช้ไฟฟ้าเพื่อ Cooling ผ่านแนวคิด PUE ด้วย หากนับเฉพาะ Active TPU และ GPU ตัวเลขที่ได้จะต่ำกว่านี้มาก

Google เองก็ระบุข้อจำกัดไว้ชัดเจน: นี่เป็น Point-in-time analysis สำหรับ Median Prompt ผลลัพธ์ไม่แทน Prompt ทุกครั้งหรือประสิทธิภาพในอนาคต และข้อมูลกับข้ออ้างดังกล่าวยังไม่ได้รับการตรวจสอบโดย Third Party อิสระ ตัวเลขนี้จึงมีประโยชน์เพราะมี Scope และ Methodology ให้ดู ไม่ใช่เพราะมันเป็นคำตอบสากล

มองจาก Prompt เดียวไปที่ระบบไฟฟ้าทั้งโลก

ระดับต่อ Prompt กับระดับระบบรวมเป็นคำถามคนละแบบ ต่อให้พลังงานต่อการทำงานหนึ่งครั้งลดลง จำนวนผู้ใช้ จำนวนคำถาม และงานที่ใช้ AI อาจเพิ่มขึ้นพร้อมกันได้

รายงานอัปเดตของ IEA เรื่อง Key Questions on Energy and AI ประเมินว่าไฟฟ้าที่ Data Center ใช้ทั่วโลกอาจเพิ่มจากประมาณ 485 TWh ในปี 2025 เป็น 950 TWh ในปี 2030 หรือเกือบเท่าตัว และการใช้ไฟฟ้าของ Data Center ที่เน้น AI อาจเพิ่มขึ้นประมาณสามเท่าในช่วงเดียวกัน IEA ยังประเมินว่า Data Center อาจคิดเป็นราว 3% ของความต้องการไฟฟ้าทั่วโลกในปี 2030

ตัวเลขระดับโลกนี้ไม่ได้บอกว่า Prompt ของเราแต่ละครั้งใช้ไฟเท่ากัน และตัวเลข 0.24 Wh ของ Google ก็ไม่ได้ใช้แทน 950 TWh ได้ สิ่งที่สองแหล่งนี้ช่วยให้เห็นคือ เราต้องมองทั้ง ประสิทธิภาพต่อหน่วยงาน และ ปริมาณงานรวม

ทำไมตัวเลขน้ำจึงแกว่งได้มาก?

งานวิจัยของ Berkeley Lab ที่เผยแพร่ในปี 2025 ทบทวนปัจจัยที่กำหนด Water Use ของ Workload ใน Data Center และพบความแตกต่างของการใช้น้ำระดับ Workload มากกว่า 10,000 เท่า ความแตกต่างนี้เกี่ยวข้องกับประสิทธิภาพของ Server, น้ำที่ผูกกับไฟฟ้าของ Grid, Utilization, เทคโนโลยี Cooling, ประสิทธิภาพโครงสร้างพื้นฐาน, Climate Zone และสัดส่วนเครื่องที่ไม่ได้ทำงานเต็มที่

ความหมายไม่ได้แปลว่า Prompt หนึ่งแบบจะเปลี่ยนจากหยดน้ำเป็นหลายพันลิตรโดยอัตโนมัติ แต่แปลว่าเราควรระวังการนำตัวเลขจากสถานที่หรือวิธีวัดหนึ่งไปใช้กับอีกระบบโดยไม่ตรวจ Scope ก่อน ไม่มีสูตรเดียวที่ทำให้ทุก Data Center ใช้น้ำน้อยที่สุด เพราะการเลือก Cooling และแหล่งไฟฟ้าต้องดูเงื่อนไขของพื้นที่จริง

Training กับ Inference ไม่ใช่งานเดียวกัน

Training คือการปรับพารามิเตอร์ของ Model จากข้อมูลจำนวนมาก การฝึกหนึ่งรอบอาจทำซ้ำหลายครั้งและใช้ Accelerator จำนวนมากเป็นเวลานาน ส่วน Inference คือการนำ Model ที่ฝึกแล้วมาใช้สร้างผลลัพธ์ เช่น ตอบ Prompt หรือจัดหมวดหมู่ข้อความ

เวลาคนถามว่า “หนึ่ง Prompt ใช้ทรัพยากรเท่าไหร่?” ส่วนมากกำลังถาม Inference แต่ระบบ AI ยังมีต้นทุนจาก Training, การทดลอง Model, การเก็บ Model, การสร้าง Index, การประเมินคุณภาพ และการทำงานของ Infrastructure ที่รองรับทั้งหมด การเปรียบเทียบจึงต้องบอกให้ชัดว่ากำลังนับเฉพาะ Serving หรือรวมวงจรอื่นด้วย

หนึ่ง Agent Task อาจไม่ใช่หนึ่ง Model Call

Chatbot ที่ตอบจากคำถามสั้น ๆ อาจมีการเรียก Model ครั้งเดียว แต่ Agent ที่ทำงานหลายขั้นอาจต้องเรียก Model เพื่อวางแผน ค้นเอกสาร เรียก Tool ตรวจผล แก้คำตอบ และสรุปผลอีกครั้ง ระหว่างทางยังอาจมีการเรียก Embedding Model, Database และระบบภายนอก

User Task
  ├─ Plan
  ├─ Retrieve Context
  ├─ Call Tool
  ├─ Check Result
  ├─ Retry or Correct
  └─ Final Response

ถ้าเรานับพลังงานต่อ Prompt แต่ไม่รู้ว่าหนึ่งงานมี Model Call กี่ครั้ง เราอาจประเมินต้นทุนต่ำเกินจริง สำหรับ Agent จึงควรวัดเป็น Workload ต่อ Task พร้อมจำนวน Call, จำนวน Token, เวลา, เครื่องมือที่ใช้ และผลลัพธ์ที่สำเร็จ ไม่ใช่ดูเฉพาะข้อความสุดท้ายที่ผู้ใช้เห็น

ประสิทธิภาพที่ดีขึ้นไม่ได้แปลว่าความต้องการรวมจะลดลงเสมอ

ระบบอาจตอบได้เร็วขึ้น ใช้พลังงานต่อ Token น้อยลง และมี Model ที่มีประสิทธิภาพกว่าเดิม ขณะเดียวกันผู้คนอาจใช้ AI ในงานมากขึ้น ส่งคำถามยาวขึ้น ขอให้สร้างหลายตัวเลือก หรือปล่อย Agent ทำงานต่อเนื่อง

นี่ไม่ใช่เหตุผลให้เลิกปรับปรุงประสิทธิภาพ แต่เป็นเหตุผลให้วัดสองด้านพร้อมกัน: cost per useful result และ total workload ถ้าดูเพียงตัวเลขต่อคำตอบ เราอาจพลาดการเติบโตของงานรวม ถ้าดูเพียงยอดรวม เราอาจมองไม่เห็นว่าการออกแบบที่ดีลดการใช้ทรัพยากรต่อผลลัพธ์ได้จริง

ถ้าเป็น Engineer เราลดงานที่ไม่จำเป็นได้ตรงไหน?

เริ่มจากคำถามว่าระบบต้องการผลลัพธ์อะไร แล้วค่อยเลือกวิธีที่พอดีกับงาน

• ใช้ Model Routing: งาน Classify, Extract หรือ Reformat อาจใช้ Model ที่เล็กและเร็วกว่า งานที่ต้องวางแผนหลายชั้นจึงค่อยส่งไป Model ที่เหมาะสมกว่า
• จำกัด Context ให้เหลือข้อมูลที่เกี่ยวข้อง ใช้ Retrieval และตัดเอกสารซ้ำแทนการส่งทุกอย่างเข้าไปทุกครั้ง
• กำหนด Output Length และหยุดการ Generate เมื่อได้ผลลัพธ์ที่เพียงพอ
• ใช้ Cache กับคำถามหรือ Context ที่ซ้ำกัน และทำ Batching เมื่อ Latency ของงานยอมรับได้
• ตรวจ Retry และ Agent Loop ไม่ให้เรียก Model ซ้ำโดยไม่มีเหตุผลหรือไม่มี Stop Condition
• วัด Token, Latency, Utilization, Error Rate และคุณภาพของผลลัพธ์แยกตาม Workload ไม่ใช้ค่าเฉลี่ยก้อนเดียวกลบงานที่แพงผิดปกติ
• ในระดับ Infrastructure เลือก Hardware ที่มีประสิทธิภาพต่อ Watt, ปรับ Scheduling และพิจารณา Cooling กับสภาพน้ำของพื้นที่ ไม่ย้ายภาระจากไฟฟ้าไปสู่น้ำโดยไม่เห็น Trade-off

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

วิธีอ่านตัวเลขอย่างไม่หลงกับความแม่นปลอม

ก่อนนำตัวเลขการใช้ไฟหรือน้ำไปเทียบกัน ให้ถามอย่างน้อยหกข้อ: วัด Model อะไร? วัดช่วงเวลาไหน? นับ Input และ Output Tokens อย่างไร? รวม CPU, RAM, Network, Idle Capacity และ PUE หรือยัง? นับ Direct Water อย่างเดียวหรือรวม Indirect Water จาก Grid? ใช้ Median, Average หรือกรณีสูงสุด?

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

Takeaway

1. AI คำตอบหนึ่งครั้งต้องพึ่งพา GPU หรือ AI Accelerator, CPU, Memory, Network, ไฟฟ้า และ Cooling ใน Data Center
2. ไม่มีค่า Energy per Prompt สากล เพราะ Model, Context, Tokens, Hardware, Utilization, PUE และสถานที่แตกต่างกัน
3. น้ำมีทั้งทางตรงจาก Cooling และทางอ้อมจากการผลิตไฟฟ้า วิธีนับต้องระบุ Scope ให้ชัด
4. Training, Inference และ Agentic Workload มีรูปแบบการใช้ทรัพยากรต่างกัน หนึ่ง User Task อาจมีหลาย Model Calls
5. การออกแบบที่ดีเริ่มจากงานที่จำเป็น: Routing, Caching, Retrieval, Batching, Output Control และการวัดผลลัพธ์ที่มีประโยชน์

Sources and measurement notes

• Google Cloud: Measuring the environmental impact of AI inference
• IEA: Key Questions on Energy and AI
• Berkeley Lab: The water use of data center workloads
• Berkeley Lab: 2024 United States Data Center Energy Usage Report

ตัวเลขในบทความเป็นข้อมูลตามวันที่และขอบเขตที่แหล่งข้อมูลระบุ ไม่ใช่การรับรองว่า Prompt ทุกครั้งมีต้นทุนเท่ากัน