CPU ทำงานอย่างไร และต่างจาก GPU ตรงไหน: อ่าน Workflow ก่อนดูสเปก

คำตอบสั้น: CPU จัดลำดับเก่ง ส่วน GPU ทำงานขนานเก่ง

CPU มี Core จำนวนน้อยกว่าแต่แต่ละ Core ซับซ้อน เหมาะกับงานที่มีเงื่อนไขเปลี่ยนไปมา ต้องสลับหน้าที่ และต้องตอบคำขอสั้นให้เร็ว GPU มีหน่วยคำนวณจำนวนมาก เหมาะกับการใช้ Operation คล้ายกันกับข้อมูลจำนวนมาก เช่น เมทริกซ์ พิกเซล หรือ Tensor แต่ต้องมีงานมากพอให้แบ่ง และต้องรวมต้นทุนการส่งข้อมูลกับการเริ่ม Kernel ด้วย

คำว่า “เร็ว” จึงต้องมีหน่วยกำกับ หากผู้ใช้รอคำตอบหนึ่งรายการ เราสนใจ Latency หากระบบต้องประมวลผลเอกสารหนึ่งหมื่นไฟล์ เราสนใจ Throughput หากบริการมีผู้ใช้พร้อมกัน เราต้องดูทั้งเวลารอคิว P95/P99 ปริมาณงานต่อวินาที คุณภาพผลลัพธ์ และต้นทุนต่อผลสำเร็จ ไม่มีชิปใดชนะทุกมิติพร้อมกัน

มองทั้งระบบก่อนมองชิป

เริ่มจากวาด Input ว่าเข้ามาจากที่ใด ผ่าน Network หรือ Storage แบบใด ถูกอ่านเข้า RAM เท่าไร ใครเป็นคน Parse และตรวจความถูกต้อง งานใดถูกส่งให้ CPU หรือ GPU แล้วผลถูกเก็บหรือส่งกลับอย่างไร เส้นทางนี้มักเปิดเผยทันทีว่าคอขวดอยู่ก่อนหรือหลังหน่วยคำนวณ เช่น PDF สแกนอาจช้าที่ OCR ไม่ใช่โมเดลสรุป ขณะที่งานภาพจำนวนมากอาจช้าที่การอ่านไฟล์เล็กกระจัดกระจายจากดิสก์

ระบบจริงเป็น Heterogeneous Computing: CPU เป็น Host ที่เริ่มโปรแกรม เตรียมข้อมูล เรียกงาน GPU และประสาน I/O ส่วน GPU เป็น Accelerator ที่รับช่วงคำนวณบางตอน เอกสาร CUDA อธิบายว่า Host และ Device อาจทำงานพร้อมกันได้ แต่การทำให้พร้อมกันจริงต้องจัด Queue, Stream, Buffer และจังหวะ Synchronization ให้ถูก หากส่วนใดรออีกส่วนตลอด ความขนานบนกระดาษจะไม่เกิดผล

วงจรคำสั่ง CPU: จากโค้ดสู่ผลลัพธ์

โปรแกรมถูกแปลงเป็นลำดับคำสั่งที่ CPU รู้จัก

โค้ดภาษาระดับสูงถูก Compiler หรือ Runtime แปลงให้ลงท้ายเป็นคำสั่งตาม Instruction Set Architecture เช่น x86-64 หรือ Arm แต่ละคำสั่งระบุ Operation และ Operand เช่น “นำค่าจาก Register A กับ B มาบวก แล้วเก็บใน C” CPU รุ่นต่างกันอาจใช้สถาปัตยกรรมภายในต่างกัน แต่ต้องรักษาพฤติกรรมที่ ISA กำหนดเพื่อให้โปรแกรมทำงานได้

หนึ่งคำสั่งเดินผ่านวงจรพื้นฐานอย่างไร

CPU สมัยใหม่ทำหลายขั้นซ้อนกันและอาจแยกคำสั่งเป็น Micro-operations แต่กรอบนี้ยังช่วยตามเหตุผลได้ว่า “ข้อมูลอยู่ที่ไหน กำลังรออะไร และผลกลับไปที่ใด”

ชิ้นส่วนสำคัญทำหน้าที่ต่างกัน

Pipeline ทำให้หลายคำสั่งอยู่คนละขั้นพร้อมกัน

เหมือนสายงานที่คำสั่ง A กำลัง Execute ขณะที่ B Decode และ C Fetch วิธีนี้เพิ่ม Throughput โดยไม่ต้องรอคำสั่งหนึ่งจบทุกขั้น แต่เมื่อข้อมูลของคำสั่งถัดไปพึ่งผลก่อนหน้า หรือทรัพยากรชนกัน Pipeline อาจต้องรอ จึงต้องมี Forwarding, Scheduling และกลไกแก้ Hazard

Branch ทำให้ CPU ต้องคาดเดาทางไปต่อ

คำสั่ง if/else และ Loop เปลี่ยนตำแหน่งคำสั่งถัดไป CPU จึงใช้ Branch Prediction คาดว่าเส้นทางใดน่าจะถูก แล้วทำงานล่วงหน้า หากเดาผิด งานที่ทำไว้บางส่วนถูกทิ้งและ Pipeline ต้องเริ่มเส้นทางใหม่ นี่คือเหตุผลหนึ่งที่โค้ดสองชุดมีจำนวนคำสั่งใกล้กันแต่ใช้เวลาไม่เท่ากัน

Core และ Thread บอกความขนาน แต่ไม่รับประกันว่างานแบ่งได้

แต่ละ Core ประมวลผลลำดับคำสั่งได้ค่อนข้างอิสระ หลาย Core ช่วยเมื่อโปรแกรมแบ่งงานพร้อมกันได้ Hardware Thread ช่วยใช้ทรัพยากรใน Core ระหว่างที่อีก Thread รอ แต่ถ้างานมีลำดับต่อเนื่องหรือใช้ Lock ร่วมกัน การเพิ่ม Core อาจไม่ทำให้เร็วขึ้นตามสัดส่วน Amdahl’s Law เตือนว่าส่วนที่ทำขนานไม่ได้จะจำกัด Speedup

Clock คือจังหวะ ไม่ใช่จำนวนงานที่เสร็จ

การเปรียบเทียบ CPU จึงควรดู Benchmark ที่ใกล้ Workflow จริง ร่วมกับ Core, Cache, Memory, Power และระยะเวลาโหลด ไม่ใช่หยิบ GHz มาเทียบข้ามรุ่นโดยตรง

ตัวอย่าง: รวมยอดรายการหนึ่งล้านแถว

CPU Fetch คำสั่งโหลดค่า Decode ให้หน่วย Load/ALU ทำงาน ดึงข้อมูลจาก Cache หรือ RAM บวกเข้ากับ Register และทำ Branch เพื่อวนรอบ หากข้อมูลต่อเนื่อง Cache Prefetcher ทำงานง่าย หากกระโดดตำแหน่งหรือมีเงื่อนไขเดายาก จะรอ Memory และเสีย Pipeline มากขึ้น Compiler อาจใช้ Vector Instruction รวมหลายค่าต่อคำสั่ง และโปรแกรมอาจแบ่งช่วงให้หลาย Core ทำพร้อมกัน

สรุป: CPU คือระบบจัดลำดับคำสั่งและเคลื่อนข้อมูลอย่างแม่นยำ

วงจร Fetch–Decode–Execute ช่วยเห็นพื้นฐาน ส่วน Pipeline, Branch Prediction, Multiple Cores และ Cache ช่วยเพิ่ม Throughput แต่สร้างเงื่อนไขใหม่ให้ต้องจัดการ ความเร็วจริงขึ้นกับงาน ข้อมูล Software และระบบรอบข้าง การเข้าใจเส้นทางคำสั่งจึงมีค่ากว่าการจำชื่อรุ่น

RAM และ Cache: พื้นที่ทำงานกำหนดเวลารอ

RAM เก็บสถานะที่ระบบกำลังใช้และเข้าถึงแบบสุ่ม

Random Access Memory ช่วยให้ CPU เข้าถึงตำแหน่งข้อมูลต่าง ๆ โดยไม่ต้องอ่านเรียงจากต้นเหมือนสื่อบางชนิด ระบบปฏิบัติการวางโค้ด โปรแกรม Stack, Heap, Buffer และ Cache ของไฟล์ไว้ใน RAM ข้อมูลทั่วไปจะหายเมื่อปิดไฟ จึงต้องบันทึกสิ่งที่ต้องเก็บระยะยาวลง Storage

ข้อมูลเดินจาก Storage ไป RAM แล้วถึง CPU

CPU มักค้น Cache ก่อน หากไม่พบจึงขอจาก RAM การเดินทางข้ามชั้นช้ากว่า Register และ Cache มาก แต่ RAM มีความจุมากกว่าและราคาต่อหน่วยต่ำกว่า

ความจุ แบนด์วิดท์ และ Latency ตอบคนละคำถาม

Module, Chip, Channel และ Controller ทำงานร่วมกัน

DIMM/SODIMM คือแผงที่ติดตั้งในเครื่อง ภายในมีชิป DRAM จัดเป็น Bank และ Row/Column Memory Controller ส่งคำสั่งผ่าน Channel การติดตั้งโมดูลที่เข้าคู่ในช่องถูกต้องช่วยใช้หลาย Channel ส่วน Timing เช่น CAS Latency ต้องอ่านร่วมกับ Data Rate เพราะตัวเลข Cycle เดียวกันอาจแปลเป็นเวลาจริงต่างกัน

ระบบต้องเข้ากันได้ทั้งชนิด DDR รุ่น ความจุสูงสุด ความเร็วที่ CPU/Mainboard รองรับ Rank, Voltage และ ECC การผสมโมดูลต่างสเปกอาจทำงานที่ค่าร่วมต่ำสุดหรือไม่เสถียร จึงควรอ้างคู่มืออุปกรณ์ ไม่เดาจากรูปร่างสล็อตเพียงอย่างเดียว

เมื่อ RAM ไม่พอ ระบบไม่ได้ “ช้าลงนิดหน่อย” เสมอไป

OS อาจย้าย Page ที่ใช้น้อยไป Swap/Pagefile บน Storage ซึ่งช้ากว่า RAM มาก หากสลับไปมาถี่จะเกิด Thrashing: CPU ใช้เวลารอ I/O มากกว่าทำงาน โปรแกรมอาจถูกปิดด้วย Out-of-memory หรือเกิด Latency กระโดด Memory Compression และ File Cache ช่วยได้บางส่วน แต่ไม่เพิ่ม Working Set จริง

RAM, Cache, Storage และ VRAM ต่างกันอย่างไร

เลือก RAM จาก Peak Working Set และช่องทางขยาย

วัดงานจริงช่วงพีก รวม OS, โปรแกรมหลัก, Dataset/Model, Buffer, Browser และงานเบื้องหลัง เผื่อ Headroom สำหรับ Spike และการอัปเดต ตรวจจำนวน Slot, Channel, ความจุต่อโมดูล และความเข้ากันได้ หากงานต้องความเสถียรสูง พิจารณา ECC และการทดสอบ Memory Error

อย่าเพิ่ม RAM เพราะเห็น “ใช้ 80%” เพียงอย่างเดียว OS ตั้งใจใช้พื้นที่ว่างทำ Cache ตัวชี้วัดสำคัญคือ Memory Pressure, Swap Activity, Page Fault ที่ต้องอ่าน Storage และผลต่อ Latency ของงาน

ตัวอย่าง AI: โมเดลไม่ได้ใช้หน่วยความจำแค่ขนาดไฟล์

การรันโมเดลต้องมีน้ำหนัก ตัวแทนข้อมูลระหว่างคำนวณ KV Cache, Input Batch, Runtime และ Buffer การฝึกยังมี Gradient และ Optimizer State จึงใช้มากกว่าขนาด Model File หลายเท่า หาก GPU VRAM ไม่พอ ระบบอาจ Offload ไป RAM แต่จะช้าลงตามเส้นทาง PCIe และการคัดลอกข้อมูล การวัด Peak Working Set ของ Workflow จริงจึงจำเป็น

สรุป: RAM คือพื้นที่ทำงาน ไม่ใช่คะแนนความเร็ว

Capacity กำหนดว่างานอยู่พร้อมกันได้มากเท่าไร Bandwidth กำหนดปริมาณการขนส่ง และ Latency กำหนดเวลารอ ความจุไม่พออาจผลักงานไป Storage จนช้ามาก แต่ความจุเกินไม่ทำให้งานเร็วขึ้นอัตโนมัติ เลือกจาก Working Set, Channel, Compatibility และหลักฐาน Memory Pressure

Storage และ I/O: จุดเริ่มต้นที่มักถูกมองข้าม

Storage เก็บข้อมูลแม้ปิดไฟและเป็นต้นทางของ Working Set

ระบบปฏิบัติการ โปรแกรม โมเดล Dataset, Log และผลลัพธ์อยู่บน Storage เมื่อต้องใช้ ระบบอ่านข้อมูลเข้าสู่ RAM/VRAM ความเร็วในการเริ่มโปรแกรม โหลดตัวอย่างจำนวนมาก หรือเขียน Checkpoint จึงขึ้นกับทั้งอุปกรณ์ File System, Interface และรูปแบบ I/O

HDD ใช้หัวอ่านเขียนบนจานแม่เหล็กที่หมุน

ข้อมูลอยู่ตาม Track/Sector หัวอ่านต้องเคลื่อนไปตำแหน่งและรอจานหมุนให้ข้อมูลผ่านใต้หัว จึงมี Mechanical Latency งานอ่านไฟล์ใหญ่ต่อเนื่องทำได้ดีเมื่อเทียบต้นทุนต่อ TB แต่งานสุ่มไฟล์เล็กจำนวนมากต้องขยับหัวบ่อย ทำให้ IOPS และ Latency ด้อยกว่า SSD การสั่นสะเทือนและแรงกระแทกระหว่างทำงานเป็นความเสี่ยงเฉพาะกลไก

SSD ใช้ NAND Flash และ Controller จัดการตำแหน่ง

SSD ไม่มีหัวอ่านเคลื่อนที่ จึงเข้าถึงแบบสุ่มเร็วกว่า แต่ Flash เขียนทับตรง ๆ ไม่ได้ ต้อง Erase เป็น Block และเขียนเป็น Page Controller ใช้ Flash Translation Layer, Garbage Collection, Wear Leveling, Error Correction และ Over-provisioning เพื่อซ่อนความซับซ้อน ประสิทธิภาพจึงอาจเปลี่ยนเมื่อไดรฟ์เต็ม ร้อน หรือเขียนต่อเนื่องจน Cache หมด

ตัวเลขแต่ละตัวตอบคนละ I/O Pattern

SATA, NVMe และ Network เป็นเส้นทาง ไม่ใช่ตัวสื่อเอง

SSD อาจเชื่อมผ่าน SATA หรือ NVMe บน PCIe; HDD มักใช้ SATA/SAS ส่วน Storage ภายนอกอาจผ่าน USB, Thunderbolt หรือ Network Interface กำหนดเพดาน Bandwidth/Latency และ Protocol จัด Queue ต่างกัน ไดรฟ์เร็วไม่อาจเกินเส้นทางที่แคบกว่า และตัวเลขสูงสุดจาก Queue ลึกอาจไม่สะท้อนงานผู้ใช้ทั่วไป

อุปกรณ์ทุกชนิดเสียได้—Storage ไม่เท่ากับ Backup

HDD อาจมีปัญหากลไกหรือ Bad Sector; SSD มี Flash Wear, Controller/Firmware Failure และ Data Retention ที่ขึ้นกับสภาพ การดู SMART/Health ช่วยเตือนบางกรณีแต่ทำนายไม่ได้ทั้งหมด RAID เพิ่ม Availability บางรูปแบบ แต่ไม่ป้องกันการลบผิด Ransomware ไฟไหม้ หรือความเสียหายที่ถูก Sync ไปทุกชุด

เลือกตาม Pattern และต้นทุนตลอดวงจร

คำนวณ Capacity + Headroom, ความเร็วที่ต้องการจริง, จำนวนอุปกรณ์, พลังงาน, การสำรอง, Downtime และเวลา Restore วิธี Hybrid มักคุ้ม: SSD สำหรับ Hot Data/Cache และ HDD/Object Storage สำหรับ Cold Data/Backup

งาน AI แพ้ Storage Bottleneck ได้แม้ GPU ว่าง

Training ต้องอ่านตัวอย่างจำนวนมาก หากไฟล์เล็กกระจายหรือ Decode ช้า GPU จะรอข้อมูล การจัด Shard, Prefetch, Cache, Parallel Loader และ Local SSD อาจช่วยมากกว่าการเปลี่ยน GPU Inference ต้องโหลดโมเดลตอนเริ่มและเขียน Log/Trace อย่างเหมาะสม ขณะที่ Checkpoint ต้องรองรับการเขียนขนาดใหญ่โดยไม่หยุด Pipeline นาน

สรุป: เลือก Storage จากรูปแบบการอ่านเขียนและแผนกู้คืน

HDD ให้ความจุต่อต้นทุนดีและเหมาะงานต่อเนื่อง/Archive ส่วน SSD ให้ Latency ต่ำและ Random IOPS สูง แต่ต้องดู Interface, Cache, Thermal และ Endurance ความเร็วสูงสุดตัวเดียวไม่อธิบาย Workflow ทั้งหมด และไม่มีอุปกรณ์ใดแทน Backup ที่ทดสอบ Restore แล้วได้

GPU และงานขนาน: เร็วเมื่อรูปร่างงานเหมาะ

จากการวาดภาพสู่ General-purpose Parallel Computing

การสร้างภาพต้องแปลงจุดยอด เติมสี คำนวณแสง และเขียน Pixel จำนวนมากด้วย Operation คล้ายกัน GPU จึงมีหน่วยคำนวณจำนวนมากและระบบ Memory ที่เน้น Throughput ต่อมาชุดคำสั่งและแพลตฟอร์มอย่าง CUDA/OpenCL ทำให้โปรแกรมทั่วไปส่ง Kernel ไปประมวลผลบน GPU ได้ แม้รายละเอียดสถาปัตยกรรมและชื่อหน่วยจะแตกต่างตามผู้ผลิต

CPU เก่งลำดับซับซ้อน GPU เก่งงานขนานจำนวนมาก

Kernel แบ่งงานเป็น Thread จำนวนมากที่เดินเป็นกลุ่ม

ผู้ผลิตเรียกกลุ่ม Thread ว่า Warp หรือ Wavefront เมื่อ Thread ในกลุ่มแยก Branch คนละทาง ระบบอาจต้องทำแต่ละทางสลับกัน (Divergence) ทำให้ความขนานที่คาดหวังลดลง การจัดข้อมูลและ Algorithm จึงสำคัญพอ ๆ กับจำนวนหน่วยคำนวณ

VRAM Capacity และ Memory Bandwidth เป็นข้อจำกัดคนละแบบ

โมเดล Tensor และ Buffer ต้องใส่ใน VRAM หรือถูกแบ่ง/Offload Capacity ไม่พออาจรันไม่ได้หรือมีการคัดลอกข้อมูลช้า ส่วน Bandwidth ไม่พอทำให้หน่วยคำนวณรอข้อมูล แม้ FLOPS สูง งานที่คำนวณน้อยต่อ Byte (Low Arithmetic Intensity) มักติด Memory-bound งานที่นำข้อมูลมาใช้ซ้ำใน Cache/Shared Memory ได้ดีจึงใช้ GPU คุ้มกว่า

Matrix Multiplication เปิดพื้นที่ให้คำนวณขนานและใช้ข้อมูลซ้ำ

Neural Network จำนวนมากลดรูปเป็นการคูณเมทริกซ์ Convolution และ Element-wise Operation ซึ่งแบ่ง Tile และ Thread ได้ Library ที่ปรับแต่งแล้วเลือก Kernel, Precision และ Layout ให้เหมาะ Tensor Core/Matrix Unit เร่ง Operation บางรูปแบบ แต่ต้องรักษาคุณภาพเชิงตัวเลข และผลจริงขึ้นกับ Batch Size, Sequence Length, Model Architecture และ Software

GPU อาจไม่ช่วยเมื่อโจทย์เล็ก ลำดับมาก หรือส่งข้อมูลแพง

GPU Utilization สูงก็ไม่รับประกันว่าคุ้ม อาจกำลังทำงานซ้ำหรือรอ Memory แบบไม่เกิด Outcome ควรวัด End-to-end Latency, Throughput, Cost per Result และคุณภาพ ไม่ใช่ดู Utilization แยกตัวเดียว

อ่าน Metric เป็นเส้นทาง ไม่ใช่คะแนน

เลือก GPU จาก Workflow, Precision และระบบรอบข้าง

เริ่มจาก Framework/Operator Compatibility, VRAM Peak, Precision ที่ยอมรับได้, Latency/Throughput เป้าหมาย และ Multi-GPU Communication จากนั้นดู Cooling, Power, PCIe/Network, Driver และต้นทุน Cloud/On-premises ทดลอง Benchmark ด้วย Model/Batch/Sequence จริง และเปรียบเทียบกับ CPU หรือ GPU ขนาดเล็กกว่า

สำหรับการเรียน โมเดลเล็ก Local หรือ Notebook/Cloud เป็นครั้งคราวอาจคุ้มกว่าซื้ออุปกรณ์ สำหรับ Production ให้รวม Availability, Monitoring, Scaling, Queue และต้นทุนเวลาที่ GPU ว่างด้วย

สรุป: GPU เร็วเมื่อ Algorithm และข้อมูลสร้างความขนานได้

GPU เน้น Throughput จากหน่วยคำนวณจำนวนมาก งานต้องแบ่งเป็น Thread ที่ทำ Operation คล้ายกัน มี Data Reuse และป้อนข้อมูลทัน VRAM Capacity, Bandwidth, Transfer และ Software Stack ล้วนกำหนดผลจริง จึงควรวัด End-to-end Workflow ก่อนสรุปว่าต้องใช้ GPU รุ่นใด

เปรียบเทียบ CPU–GPU โดยไม่ติดชื่อรุ่น

อย่าถามว่าอะไรเร็วกว่า ให้ถามว่างานมีรูปร่างแบบไหน

ระบุขนาดงาน จำนวนงานพร้อมกัน ลำดับคำสั่ง ความถี่ Branch, ขนาด Working Set, การใช้ข้อมูลซ้ำ เวลาตอบสนอง และต้นทุนที่ยอมรับได้ งานเดียวกันอาจเหมาะ CPU ใน Batch เล็กและเหมาะ GPU ใน Batch ใหญ่ การตัดสินจึงต้องผูกกับ Input และ Service Goal

สองสถาปัตยกรรมใช้พื้นที่ทรานซิสเตอร์ต่างเป้าหมาย

Latency คือเวลาของหนึ่งงาน Throughput คือปริมาณงานต่อเวลา

GPU อาจทำ 1,000 รายการต่อวินาทีได้ดี แต่รายการเดียวอาจเสียเวลารอ Batch และ Transfer ส่วน CPU อาจตอบรายการเดียวเร็วกว่าแต่รับปริมาณรวมต่ำกว่า เป้าหมายผลิตภัณฑ์เป็นผู้ตัดสินว่ามิติใดสำคัญ

Data Movement มักแพงกว่าที่จำนวน Core บอก

CPU ใช้ RAM และ Cache; GPU ใช้ VRAM กับ Memory Bandwidth สูง การส่งข้อมูลผ่าน PCIe/Interconnect มีค่าใช้จ่าย หาก Copy ไปกลับทุก Operation ประโยชน์การคำนวณขนานอาจหาย การเก็บข้อมูลไว้บน Device ใช้ Kernel หลายขั้นต่อเนื่อง และเพิ่ม Arithmetic Intensity ช่วยได้ ขณะเดียวกัน VRAM Capacity อาจบังคับให้แบ่ง Model/Batch

ระบบ AI จริงมักเป็น Hybrid Pipeline

ถ้า Preprocess, Tokenization, Data Loader หรือ Network ช้า GPU จะว่างรอ ถ้า GPU ช้า คิวจะโตและ Tail Latency พุ่ง การเพิ่มเฉพาะ GPU อาจไม่เพิ่ม Throughput เพราะ Bottleneck อยู่ก่อนหรือหลังโมเดล

ตัวอย่างงานที่รูปร่างต่างกัน

Benchmark ต้องรวม Warm-up, Transfer, Queue และคุณภาพ

กรอบเลือก: เริ่มเล็ก วัด แล้วขยายตรงคอขวด

เลือก CPU-only หากงานเล็ก Branch มาก Latency สำคัญ หรือ Library GPU ไม่รองรับ เลือก GPU เมื่อ Parallelism สูง Working Set เหมาะ VRAM และปริมาณงานคุ้ม Overhead ใช้ Hybrid เมื่อ Workflow มีทั้ง Business Logic กับ Tensor Compute ซึ่งเป็นกรณีทั่วไป ทดลองทางเลือกอย่างน้อยสองแบบและตั้ง Stop Rule ก่อนซื้อโครงสร้างถาวร

สรุป: CPU และ GPU เป็นทีมที่เหมาะคนละช่วงของงาน

CPU เน้น Latency และ Control Flow; GPU เน้น Throughput และ Data Parallelism ความเร็วจริงเกิดจาก Pipeline ทั้งระบบ ไม่ใช่ Core Count หรือ FLOPS แยกตัว เมื่อวาด Data Path วัด End-to-end และรวมต้นทุน คุณจะรู้ว่าควรใช้ CPU, GPU หรือทั้งคู่ตรงจุดใด

Latency กับ Throughput ต้องวัดคนละคำถาม

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

ค่าเฉลี่ยเพียงค่าเดียวปิดบังผู้ใช้กลุ่มที่รอนาน ควรดู Median ร่วมกับ P95 หรือ P99 และแยกเวลารอ Queue, Preprocess, Transfer, Kernel, Post-process และ Network เมื่อ Tail Latency สูง สาเหตุอาจเป็นไฟล์ขนาดใหญ่ผิดปกติ การแย่ง RAM การย้ายข้อมูลซ้ำ หรือ Cold Start ไม่ใช่ Compute ช้าเสมอไป

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

เลือกจาก Workflow: วาด แยก วัด แล้วค่อยเพิ่ม

1. วาด Data Path ตั้งแต่ Input, Storage, RAM, CPU/GPU จนถึง Output พร้อมขนาดข้อมูลและจุดคัดลอก
2. แยกรูปร่างงาน ทำเครื่องหมายส่วน Sequential, Branch-heavy, Parallel, Memory-bound และ I/O-bound
3. กำหนด Service Metric ระบุ Latency ที่ยอมรับได้ Throughput เป้าหมาย คุณภาพ และงบต่อผลลัพธ์
4. วัด Baseline End-to-end รวม Warm-up, Queue, Transfer, Pre/Post-process และเหตุการณ์ผิดพลาด
5. เพิ่มตรงคอขวด เปรียบเทียบ CPU-only, GPU และ Hybrid ด้วยข้อมูล Batch และ Software เดียวกัน
6. เฝ้าดูหลังใช้งาน ตรวจ Drift ของปริมาณงาน อุณหภูมิ หน่วยความจำ Error และค่าใช้จ่ายจริง

ลำดับนี้สำคัญเพราะการซื้อ GPU ก่อนวัดอาจย้ายคอขวดไปยัง CPU, RAM หรือ Storage โดยไม่ลดเวลารวม หาก Baseline พบว่า 70% ของเวลาหมดกับการอ่านไฟล์และ OCR การเร่ง Inference ที่กินเวลา 10% ให้เร็วขึ้นครึ่งหนึ่งจะลดเวลารวมได้เพียงเล็กน้อย ในทางกลับกัน ถ้า Kernel คำนวณกินเวลาส่วนใหญ่และข้อมูลอยู่ใน VRAM อยู่แล้ว GPU ที่เหมาะกว่าหรือการปรับ Batch อาจให้ผลชัดเจน

ตัวอย่างงานจริง: อ่านเส้นทางก่อนเลือกเครื่อง

ระบบอ่าน PDF ภาษาไทย

ขั้นแรกต้องจำแนกว่า PDF มี Text Layer หรือเป็นภาพสแกน จากนั้นจึง Parse หน้า ทำ OCR เมื่อจำเป็น ทำความสะอาด Unicode แบ่ง Chunk สร้าง Embedding และเรียกโมเดลสรุป CPU เหมาะกับการจัดไฟล์ ตรวจ Metadata และ Control Flow ที่แตกต่างรายหน้า GPU อาจช่วย OCR, Embedding หรือ Inference เมื่อรวมงานเป็น Batch ได้ แต่หากไฟล์มาจาก Network ช้าหรือ OCR ทำงานทีละหน้า GPU อาจว่างรอ

แชตบอตที่ต้องตอบทันที

คำขอแต่ละรายการผ่าน Authentication, Retrieval, Prompt Assembly, Model Inference และ Streaming คำตอบ Batch ใหญ่อาจเพิ่ม Throughput แต่ทำให้ Time-to-first-token แย่ ระบบจึงต้องหาจุดสมดุลระหว่าง Queue, Continuous Batching และ VRAM พร้อมเผื่อ Context ที่ยาวผิดปกติ การมองเฉพาะ Token ต่อวินาทีของโมเดลไม่บอกเวลาที่ผู้ใช้รอก่อน Token แรก

ประมวลผลภาพจำนวนมาก

การ Resize, Decode และ Augmentation บางส่วนทำบน CPU ขณะที่ Convolution หรือ Transformer ทำบน GPU หาก Data Loader มี Worker น้อย ดิสก์อ่านไม่ทัน หรือรูปมีขนาดหลากหลาย GPU จะเกิดช่องว่างระหว่าง Batch วิธีแก้อาจเป็น Preprocessing, Caching, Parallel I/O หรือการจัด Bucket ไม่ใช่เปลี่ยน GPU ทันที

งานตารางและ Automation ขนาดเล็ก

สคริปต์ที่อ่าน CSV เล็ก ตรวจเงื่อนไขหลายแบบ แล้วเขียนรายงานมักจบบน CPU ได้เร็วกว่า เพราะต้นทุนเริ่ม GPU และส่งข้อมูลไม่คุ้ม งาน Database ยังขึ้นกับ Index, Query Plan และ Disk มากกว่าจำนวนหน่วยคำนวณ การเลือก Accelerator จึงต้องเริ่มจาก Profile ไม่ใช่ประเภทไฟล์หรือคำว่า AI

ทดลองวัดด้วยตนเองโดยไม่สร้าง Benchmark ลวง

เลือกงานตัวแทนอย่างน้อยสามขนาด: เล็กแบบผู้ใช้ทั่วไป กลางแบบงานประจำ และใหญ่แบบช่วงพีก ใช้ข้อมูลจริงที่ลบข้อมูลอ่อนไหวแล้ว ล็อกเวอร์ชันโมเดล Library, Driver, Precision และการตั้งค่า วอร์มระบบก่อนวัด จากนั้นรันซ้ำหลายรอบและบันทึกความแปรปรวน ห้ามเลือกเฉพาะรอบที่เร็วที่สุด

เก็บ Timeline ตั้งแต่เริ่มรับ Input จน Output พร้อมใช้งาน แยก CPU Time, GPU Kernel Time, Data Transfer, Disk/Network I/O, Queue และ Memory Peak หากเครื่องมือวัดมี Overhead ให้บันทึกไว้ เปรียบเทียบ CPU-only กับ GPU ด้วยผลลัพธ์คุณภาพเดียวกันและเงื่อนไขเดียวกัน การลด Precision ต้องผ่านเกณฑ์ความถูกต้อง ไม่ใช่นับว่าเร็วขึ้นโดยละเว้นผลเสีย

เมื่อได้ผล ให้เขียนข้อสรุปในรูป “ภายใต้เงื่อนไขใด” เช่น งาน Batch 32 ที่ข้อมูลอยู่ใน VRAM ให้ Throughput ดีกว่า CPU แต่คำขอเดี่ยวมี Latency ใกล้กัน ข้อสรุปแบบมีขอบเขตนำไปใช้ซ้ำได้มากกว่าคำว่า GPU เร็วกว่า และช่วยให้ทีมรู้ว่าผลจะเปลี่ยนเมื่อ Batch, Model หรือ Data Path เปลี่ยน

ข้อเข้าใจผิดที่พบบ่อยและเหตุผลที่ฟังดูน่าเชื่อ

ข้อจำกัด ความเสี่ยง และต้นทุนที่ต้องรวม

Hardware ต้องทำงานกับ Software Stack ที่รองรับจริง ตั้งแต่ Driver, Runtime, Framework, Operator และระบบปฏิบัติการ รุ่นที่แรงบนกระดาษอาจใช้กับ Library สำคัญไม่ได้หรือใช้เวลาบำรุงรักษาสูง VRAM ต้องพอกับ Peak ไม่ใช่เฉพาะขนาดไฟล์โมเดล และ Multi-GPU ต้องคิด Communication, Synchronization และความซับซ้อนของการ Debug

พลังงาน ความร้อน เสียง พื้นที่ และแหล่งจ่ายไฟเป็นส่วนของต้นทุนรวม Cloud ลดภาระซื้อเครื่องแต่เพิ่มค่า Network, Storage, Data Egress และเวลาที่ Instance ว่าง On-premises ให้การควบคุมและความเป็นส่วนตัวมากขึ้นแต่ต้องดูแล Availability, Monitoring, Spare Part และรอบการเสื่อมราคา ไม่มีคำตอบเดียวจนกว่าจะระบุปริมาณงานและข้อกำกับข้อมูล

บทความนี้ไม่แทน Benchmark เฉพาะรุ่นหรือคำแนะนำจัดซื้อ องค์กรที่มีข้อมูลอ่อนไหวต้องทบทวนสิทธิ์เข้าถึง การเข้ารหัส ที่ตั้งข้อมูล และข้อตกลงผู้ให้บริการก่อนส่งงานขึ้น Cloud ส่วนงานสำคัญควรมี Stop Rule เมื่อ Error, อุณหภูมิ หรือค่าใช้จ่ายเกินเกณฑ์ เพื่อหยุดการทดลองก่อนความเสียหายขยาย

เชื่อมกลับบทเรียน 31–35

• บทเรียน 31 — CPU ทำงานอย่างไร: วงจรคำสั่ง Register, Pipeline และ Cache
• บทเรียน 32 — RAM คืออะไร: Working Set, Capacity, Bandwidth และ Memory Pressure
• บทเรียน 33 — SSD กับ HDD: Latency, Throughput และรูปแบบ I/O
• บทเรียน 34 — GPU คืออะไร: Thread, Warp/Wave, VRAM และ Data Transfer
• บทเรียน 35 — CPU กับ GPU ต่างกันอย่างไร: เลือก CPU-only, GPU หรือ Hybrid จาก Workflow

หากหัวข้อใดยังอธิบายด้วยภาษาของตัวเองไม่ได้ ให้ย้อนอ่านบทนั้นก่อน แล้วกลับมาวาด Data Path อีกครั้ง เป้าหมายไม่ใช่จำคำศัพท์ทุกคำ แต่คือบอกได้ว่าข้อมูลอยู่ที่ไหน กำลังรออะไร ใครควบคุม และ Metric ใดพิสูจน์ว่าการแก้ไขดีขึ้นจริง

คำถามที่พบบ่อย

เล่นเกมหรือทำ AI ต้องเลือก CPU หรือ GPU ก่อน

เริ่มจาก Software และงานหลัก เกมต้องพึ่งทั้ง Logic บน CPU และการเรนเดอร์บน GPU งาน AI ต้องดูโมเดล VRAM และ Operator ที่รองรับ หากงบจำกัด ให้หาจุดขั้นต่ำที่ไม่ทำให้ส่วนใดเป็นคอขวดรุนแรง แล้วเทียบ Benchmark ของ Workflow ใกล้เคียงแทนการเลือกจากชื่อหมวด

Integrated GPU ใช้เรียน AI ได้ไหม

ใช้เรียนแนวคิด เขียนโค้ด และทดลองโมเดลเล็กได้ในหลายกรณี แต่ความเข้ากันได้ของ Framework และ Memory Sharing ต่างกันตามแพลตฟอร์ม ตรวจเอกสารทางการของ Runtime ก่อน และอย่าสรุปจากคำว่า GPU เพียงคำเดียว

ทำไม GPU Utilization ต่ำ

อาจเกิดจาก Batch เล็ก Data Loader ช้า CPU เตรียมงานไม่ทัน Transfer มาก Kernel สั้นเกิน หรือ Operation บางส่วนกลับไป CPU ต้องดู Timeline และ Metric หลายส่วนพร้อมกัน ไม่ควรแก้ด้วยการเพิ่ม Batch โดยไม่ตรวจ Latency และ Memory Peak

ทำไมเพิ่ม RAM แล้วเครื่องไม่เร็วขึ้น

ถ้าก่อนเพิ่มไม่มี Memory Pressure หรือ Swap คอขวดอาจอยู่ที่ CPU, Storage, Network หรือ Algorithm RAM เพิ่มช่วยให้เก็บ Working Set และ Cache มากขึ้น แต่ไม่ได้เพิ่มอัตราคำนวณของงานที่ติด Compute

ควรเชื่อคะแนน Benchmark แค่ไหน

ใช้เป็นสัญญาณเริ่มต้นเมื่อวิธีทดสอบโปร่งใส แต่ต้องตรวจ Dataset, Precision, Batch, Power Limit, Software Version และ Metric แล้วทำ Pilot ด้วยงานจริง คะแนนที่ไม่บอกเงื่อนไขไม่เพียงพอสำหรับการตัดสินใจซื้อ

ระบบ Hybrid หมายถึงต้องมี GPU เสมอไหม

ไม่จำเป็น Hybrid หมายถึงใช้หน่วยประมวลผลหลายชนิดตามความเหมาะสม อาจเป็น CPU ร่วมกับ GPU, NPU, Accelerator เฉพาะทาง หรือบริการ Cloud หาก CPU-only ผ่าน Service Metric และคุ้มกว่า ก็เป็นคำตอบที่ถูกต้องสำหรับ Workflow นั้น

สรุป: อ่านระบบก่อนอ่านสเปก

CPU ทำหน้าที่จัดลำดับและรับมือเงื่อนไขหลากหลาย GPU เพิ่ม Throughput เมื่อปัญหาถูกแบ่งเป็นงานคล้ายกันจำนวนมาก แต่ RAM, Cache, Storage, Network และ Data Transfer กำหนดว่าความสามารถของชิปไปถึงผู้ใช้หรือไม่ การเลือกที่ดีจึงเริ่มจาก Service Metric และ Data Path แล้วพิสูจน์ด้วย Benchmark แบบ End-to-end

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