Google TPU กับ NVIDIA GPU: วิธีเลือก AI Accelerator ที่เหมาะกับงานจริง

เวลาเปรียบเทียบฮาร์ดแวร์ AI หลายคนมักถามสั้น ๆ ว่า TPU เร็วกว่า GPU หรือไม่ แต่คำถามนี้กว้างเกินไปสำหรับการตัดสินใจจริง Tensor Processing Unit หรือ TPU ของ Google เป็นตัวเร่งเฉพาะทางสำหรับงาน tensor ในระบบ machine learning ขณะที่ NVIDIA H100 SXM เป็น GPU ระดับดาต้าเซ็นเตอร์ที่มีสเปกสาธารณะครอบคลุมหลายโหมดตัวเลข ทั้ง FP64, FP32, TF32 Tensor Core, BF16/FP16, FP8 และ INT8

บทความนี้จึงไม่ฟันธงว่าใครชนะทุกสนาม แต่ใช้ Google TPU v5e, v5p, v6e และ NVIDIA H100 SXM รวมถึง VM ตระกูล A3 H100 บน Google Cloud เป็นจุดอ้างอิงหลัก

สรุปสั้น ๆ ก่อนเลือก

• เลือก Google TPU ถ้าเวิร์กโหลดเป็น deep learning เป็นหลัก โมเดลเข้ากับการรันบน TPU ได้ดี และทีมพร้อมทำงานตามแนวทางการสเกลแบบ TPU เอกสาร JAX ระบุ topology ของ TPU pod รวมถึง HBM ต่อชิป bandwidth และตัวเลข BF16/INT8 สำหรับ TPU v5e, v5p และ v6e
• เลือก NVIDIA H100 GPU ถ้าต้องการรองรับชนิดตัวเลขหลากหลาย มีเวิร์กโหลดผสม หรือไม่อยากเสี่ยงกับการย้ายระบบจาก stack ที่เน้น GPU อยู่แล้ว ตารางสเปก H100 SXM ของ NVIDIA ระบุการรองรับ FP64, FP32, TF32 Tensor Core, BF16/FP16 Tensor Core, FP8 Tensor Core และ INT8 Tensor Core พร้อมหน่วยความจำ 80GB HBM3 และ bandwidth 3.35TB/s
• ถ้าต้นทุนเป็นตัวตัดสิน ให้ benchmark ทั้งสองแบบ เพราะสเปก peak, ราคาต่อชั่วโมงของชิป และคำกล่าวอ้างจากผู้ขาย ไม่สามารถแทนการวัดต้นทุนต่อ training step หรือ inference token บนโมเดลของคุณเองได้

ภาพใหญ่: ความเฉพาะทางของ TPU ปะทะความยืดหยุ่นของ H100

TPU เป็น ASIC ที่ออกแบบมาเพื่อเร่งงาน tensor processing ในระบบ machine learning จุดแข็งของแนวทางนี้คือ เมื่อ compiler, รูปทรง tensor, batching และ sharding เข้ากับ TPU ได้ดี ชิปสามารถถูกใช้งานได้คุ้มกับงาน tensor ขนาดใหญ่และมีรูปแบบค่อนข้างสม่ำเสมอ

H100 เลือกเส้นทางกว้างกว่า แม้จะถูกปรับแต่งหนักสำหรับ AI ผ่าน Tensor Cores แต่สเปก H100 SXM ยังครอบคลุมทั้ง FP64 และ FP32 แบบทั่วไป รวมถึง Tensor Core precision หลายระดับ ความกว้างนี้มีค่าเมื่อทีมต้องใช้ accelerator ชุดเดียวรองรับงานทดลองหลายแบบ งานที่ต้องการ precision ต่างกัน หรือระบบ production ที่ไม่ได้มีแค่ deep learning job รูปแบบเดียว

อ่านสเปกอย่างไรไม่ให้หลงทาง

ตารางสเปกช่วยให้เห็นทิศทางของ trade-off แต่ไม่ใช่ benchmark แบบเทียบกันตรง ๆ ได้ทุกกรณี เพราะ TPU และ GPU มักรายงานคนละ precision mode ใช้สมมติฐานระบบต่างกัน และมีวิธีสเกลไม่เหมือนกัน

ตัวเร่ง	หน่วยความจำตามสเปกสาธารณะ	Bandwidth ตามสเปกสาธารณะ	ตัวเลข compute ตามสเปกสาธารณะ	ควรตีความอย่างไร
TPU v5e	16GB HBM ต่อชิป	8.1e11 bytes/s ต่อชิป	1.97e14 BF16 FLOPs/s ต่อชิป; 3.94e14 INT8 FLOPs/s ต่อชิป	เป็นตัวเลือก TPU ที่มี HBM ต่อชิปน้อยกว่า v5p และ v6e ในตาราง JAX จึงต้องเช็ก memory fit ให้ดี
TPU v5p	96GB HBM ต่อชิป	2.8e12 bytes/s ต่อชิป	4.59e14 BF16 FLOPs/s ต่อชิป; 9.18e14 INT8 FLOPs/s ต่อชิป	เป็นแถว TPU ที่มี HBM ต่อชิปสูงสุดในกลุ่ม v5e, v5p และ v6e ตามตาราง JAX
TPU v6e	32GB HBM ต่อชิป	1.6e12 bytes/s ต่อชิป	9.20e14 BF16 FLOPs/s ต่อชิป; 1.84e15 INT8 FLOPs/s ต่อชิป	เป็นแถวที่มี throughput ต่อชิปแบบ BF16 และ INT8 สูงสุดในกลุ่ม TPU ที่เทียบกันนี้
NVIDIA H100 SXM	80GB HBM3	3.35TB/s	67 TFLOPS FP32; 989 TFLOPS TF32 Tensor Core; 1,979 TFLOPS BF16/FP16 Tensor Core; 3,958 TFLOPS FP8 Tensor Core; 3,958 TOPS INT8 Tensor Core	ครอบคลุม precision กว้าง มี bandwidth สูง และเหมาะกับบทบาท accelerator ที่ทั่วไปกว่า

บน Google Cloud เองก็ไม่ได้มีแค่ TPU เอกสาร Compute Engine ระบุ machine type ตระกูล A3 ที่ใช้ H100 ได้ 1, 2, 4 หรือ 8 GPU โดยแต่ละ GPU มี 80GB HBM3 ขณะเดียวกันเนื้อหา AI Hypercomputer ของ Google Cloud ก็วางทั้ง TPU และ A3 VM ที่รัน H100 GPU ไว้ในพอร์ตโฟลิโอโครงสร้างพื้นฐาน AI เดียวกัน ดังนั้นในทางปฏิบัติ การเลือกอาจไม่ใช่ Google Cloud TPU ปะทะ GPU จากผู้ให้บริการอื่นเสมอไป

เมื่อไร TPU น่าอยู่ใน shortlist

TPU จะน่าสนใจเป็นพิเศษเมื่อความเฉพาะทางกลายเป็นข้อได้เปรียบ ไม่ใช่ข้อจำกัด โดยควรพิจารณา TPU ถ้า:

• งานหลักคือ training หรือ inference ของ deep learning ที่ถูกขับเคลื่อนด้วย tensor operation ขนาดใหญ่
• โมเดลมี shape, batch และ sharding pattern ที่ค่อนข้างนิ่ง และสามารถปรับให้ใช้ TPU ได้เต็มขึ้น
• ทีมพร้อมทำงานกับแนวทางสเกลแบบ TPU เพราะเอกสาร JAX ใช้ pod size, host size, HBM capacity, bandwidth และ throughput แบบ BF16/INT8 เป็นมิติสำคัญในการวางแผน
• ตั้งใจ deploy บน Google Cloud อยู่แล้ว
• เป้าหมายธุรกิจคือ cost-performance ที่วัดได้บนโมเดลกลุ่มแคบ ๆ มากกว่าความพกพาสูงสุดข้ามหลายเวิร์กโหลด

TPU อาจคุ้มมากเมื่อ workload ทำให้ชิปทำงานได้เต็มและไม่ต้องแลกด้วยการเขียนระบบใหม่มากเกินไป แต่ข้อดีนี้เป็นผลลัพธ์ของ workload ไม่ใช่คุณสมบัติสากลที่เกิดขึ้นทุกกรณี Google เคยเผยแพร่เนื้อหาเรื่อง performance-per-dollar ของ GPU และ TPU สำหรับ AI inference ซึ่งย้ำว่าเศรษฐศาสตร์ของการให้บริการโมเดลขึ้นอยู่กับโมเดลและการตั้งค่าระบบ ไม่ใช่อันดับ accelerator แบบเดียวที่ใช้ได้ทุกงาน

เมื่อไร NVIDIA H100 GPU เป็นทางเลือกที่ปลอดภัยกว่า

H100 มักเป็นตัวเลือกที่แข็งแรงเมื่อความยืดหยุ่นสำคัญกว่าความเฉพาะทาง โดยเฉพาะเมื่อ:

• ต้องการ precision สูง เช่น FP64 หรือ FP32 ควบคู่กับโหมด Tensor Core แบบ lower precision เพราะตารางสเปก H100 SXM ระบุ FP64, FP32, TF32, BF16, FP16, FP8 และ INT8
• codebase มีการพึ่งพา kernel, library หรือ tooling ฝั่ง GPU อยู่แล้ว
• accelerator pool เดียวต้องรองรับเวิร์กโหลดหลายชนิด ไม่ใช่โมเดลตระกูลเดียว
• ต้องการใช้ VM H100 บน Google Cloud โดย A3 machine type รองรับ H100 แบบ 1, 2, 4 หรือ 8 GPU
• ความเสี่ยงในการ migrate ระบบสำคัญกว่าประสิทธิภาพเชิงทฤษฎีต่อชิป

เหตุผลที่ดีที่สุดของ H100 จึงไม่จำเป็นต้องเป็นคำว่า GPU หนึ่งตัวชนะ TPU หนึ่งชิปทุก benchmark แต่คือความยืดหยุ่นเมื่อข้อกำหนดของงานเปลี่ยนไป

เรื่องต้นทุน: อย่าดูราคาต่อชั่วโมงของชิปอย่างเดียว

การเทียบราคาเป็นเรื่องดึงดูดใจ แต่ก็หลอกตาได้ง่าย ตัวอย่างจากบุคคลที่สามระบุ Google Cloud TPU v5e ประมาณ 1.20 ดอลลาร์สหรัฐต่อ chip-hour และตัวอย่าง Azure ND H100 v5 ประมาณ 12.84 ดอลลาร์สหรัฐต่อ 80GB H100 GPU-hour อย่างไรก็ตาม ตัวเลขนี้เป็นการเทียบข้าม cloud และไม่ใช่ราคาทางการจากผู้ให้บริการทั้งหมด จึงควรใช้เป็นสัญญาณคร่าว ๆ ไม่ใช่ข้อสรุปว่า TPU ถูกกว่าเสมอ

วิธีเทียบต้นทุนที่ดีกว่าคือวัดทั้งระบบ:

1. Throughput ที่ใช้งานได้จริง: training step ต่อวินาที, sample ต่อวินาที, token ต่อวินาที หรือ latency ที่ batch size เป้าหมาย
2. Precision mode: FP8, BF16, FP16, TF32, FP32, FP64 และ INT8 ไม่ใช่ตัวเลขที่แทนกันได้ตรง ๆ
3. ความจุและ bandwidth ของหน่วยความจำ: โมเดลใหญ่ context ยาว หรือ batch size สูง อาจทำให้คอขวดเปลี่ยนจาก compute peak ไปอยู่ที่ memory
4. พฤติกรรมเมื่อสเกล: topology ของ TPU pod และ configuration ของ H100 VM ส่งผลต่อการออกแบบ distributed training และ serving
5. Utilization: accelerator ที่ว่างหรือใช้ไม่เต็มยังคงมีต้นทุน แม้ราคาต่อชั่วโมงจะดูดี
6. ต้นทุนวิศวกรรม: การ port โค้ด งาน compiler การ debug monitoring และการเปลี่ยน deployment อาจแพงกว่าส่วนต่างค่า chip-hour

ตัวชี้วัดที่ควรใช้คือ cost ต่อ output ที่มีประโยชน์จริง เช่น ต่อ training step ต่อโมเดลที่ converge ต่อ inference token หรือ ต่อเป้าหมาย latency

ตารางตัดสินใจแบบเร็ว

สิ่งที่ให้ความสำคัญ	ค่าเริ่มต้นที่น่าพิจารณา	เหตุผล
Deep learning ที่เข้ากับ TPU บน Google Cloud	Google TPU	เอกสาร TPU เน้น pod scale, HBM, bandwidth และ throughput แบบ BF16/INT8 สำหรับการสเกลโมเดล
รองรับ precision กว้าง	NVIDIA H100 GPU	H100 SXM ระบุโหมด FP64, FP32, TF32 Tensor Core, BF16/FP16 Tensor Core, FP8 Tensor Core และ INT8 Tensor Core
ใช้ Google Cloud อยู่แล้วและอยากมีทางเลือก	Benchmark ทั้งคู่	Google Cloud มีทั้ง A3 H100 machine type และวาง TPU กับ A3 VM ที่ใช้ H100 ไว้ในพอร์ตโฟลิโอโครงสร้างพื้นฐาน AI
ต้องการต้นทุน inference ต่ำที่สุด	Benchmark ทั้งคู่	Google มีบทวิเคราะห์ performance-per-dollar สำหรับ AI inference ส่วนตัวอย่าง chip-hour จากบุคคลที่สามเป็นเพียงข้อมูลเชิงทิศทางและเป็นการเทียบข้าม cloud
ระบบ production เดิมเป็น GPU-first	NVIDIA H100 GPU	การลดความเสี่ยงจาก migration อาจสำคัญกว่าประสิทธิภาพเชิงทฤษฎีของ accelerator

บทสรุป

มอง TPU เป็น accelerator เฉพาะทางสำหรับ AI และมอง H100 เป็นแพลตฟอร์ม accelerator ที่ยืดหยุ่นกว่า ถ้าโมเดลของคุณเข้ากับ TPU เป็นงาน deep learning หนัก ๆ และวางแผนใช้ Google Cloud อยู่แล้ว TPU อาจให้ cost-performance ที่ดีกว่าได้ แต่ถ้าต้องการ precision หลายแบบ เวิร์กโหลดหลากหลาย ความต่อเนื่องของเครื่องมือฝั่ง GPU หรือความเสี่ยงในการย้ายระบบต่ำกว่า NVIDIA H100 GPU มักเป็นค่าเริ่มต้นที่ปลอดภัยกว่า

คำตอบสุดท้ายที่เชื่อถือได้จึงไม่ใช่การดูสเปกสูงสุด แต่คือ benchmark เฉพาะ workload ที่วัด throughput, พฤติกรรมของ memory, utilization, ต้นทุนรวม และแรงงานวิศวกรรม บนโมเดลจริงที่คุณจะ train หรือ serve