เมื่อคุณป้อนข้อความลงใน ChatGPT, Claude หรือ DeepSeek และโมเดลเริ่มตอบแบบทีละคำภายในเวลาเพียงไม่กี่ร้อยมิลลิวินาที กระบวนการนี้ดูเหมือนเรื่องง่าย—แต่จริงๆ แล้วมันคือหนึ่งในงานวิศวกรรมที่ละเอียดที่สุดในโลกของการคำนวณสมัยใหม่ บทความนี้สรุปการวิเคราะห์ขั้นตอนการอนุมานแบบครบถ้วนของวิศวกร AI Akshay Pachaar ตั้งแต่ tokenization, embedding, attention ไปจนถึง prefill/decode สองขั้นตอน, KV cache, การทำควอนไทซ์ (quantization) และเหตุผลที่ DeepSeek V4 ทำให้ขนาดแคชลดลงเหลือเพียง 10% ของเดิม
แก่นของ “โมเดลความคิด” คือ: LLM แค่ “เดา token ถัดไป” แล้วทำซ้ำไปเรื่อยๆ
โมเดลภาษาขนาดใหญ่โดยแก่นแท้ทำแค่เรื่องเดียว: ทำนาย token ถัดไป มันรับลำดับ token ที่คุณป้อนเข้าไป คำนวณการแจกแจงความน่าจะเป็นของ token ถัดไป สุ่มเลือก token ตามการแจกแจงนั้น ต่อ token ดังกล่าวไปต่อท้ายอินพุต แล้วจึงทำนาย token ถัดไป—ไม่หยุดจนกว่าโมเดลจะส่งสัญลักษณ์หยุดหรือถึงขีดจำกัด
ประเด็นสำคัญของทั้งกระบวนการอนุมานไม่ใช่ว่า “มันทำนายได้อย่างไร” แต่คือ “ทำไม token ตัวที่สองถึงเร็วกว่าตัวแรกมาก?” คำตอบนี้จะพาไปสู่แนวคิดสำคัญ 2 อย่างของการให้บริการ LLM สมัยใหม่: prefill และ decode สองขั้นตอน รวมถึง KV cache
Step 1：Tokenization แปลงข้อความเป็นตัวเลข
โครงข่ายประสาทไม่อ่านข้อความ มันอ่านแค่วีคเตอร์ ดังนั้น prompt ของคุณจะถูกผ่าน tokenization ก่อน จากนั้นถูกตัดเป็นหน่วยๆ เรียกว่า “token” และ token แต่ละตัวจะสอดคล้องกับตัวเลข ID ในปัจจุบัน LLM ส่วนใหญ่ใช้ BPE (Byte Pair Encoding, การเข้ารหัสคู่ไบต์): เริ่มจากอักขระดั้งเดิม แล้วค่อยๆ รวมคู่ของอักขระที่โผล่ร่วมกันบ่อยที่สุดเข้าด้วยกัน จนสุดท้ายได้ตารางคำศัพท์ของ token ที่ใช้บ่อยราว 50K
ขั้นตอนนี้ส่งผลมากกว่าที่คนส่วนใหญ่คิด ในภาษาที่อยู่ในข้อมูลฝึกของ tokenizer มีน้ำหนักน้อย มักจะถูกตัดเป็น token มากขึ้น ต้นทุนการอนุมานก็เพิ่มขึ้น และความเร็วก็ช้าลง ในกรณีภาษาจีนกับภาษาจีนตัวเต็ม ภายใต้ tokenizer ที่เน้นทางอังกฤษ ในหลายกรณี “แต่ละตัวอักษร” มักถูกแบ่งออกเป็น 2 ถึง 3 token นี่คือสาเหตุหนึ่งที่ทำให้ต้นทุนการอนุมานของผู้ใช้จีนสูง
Step 2：Embedding แปลงจำนวนเต็มเป็นเวกเตอร์ แล้วฉีดข้อมูลตำแหน่งเข้าไป
ID จำนวนเต็มของแต่ละ token จะไปค้นหา “embedding table” ขนาดใหญ่ ถ้าคำศัพท์ของโมเดลมี 50K และมิติของ hidden คือ 4096 รูปร่างของตารางนี้คือ [50000, 4096] token แต่ละตัวจะดึงเวกเตอร์ 1 แถว ซึ่งเป็นการแทนความหมายในมิติ 4096
เวกเตอร์เหล่านี้ไม่ใช่สุ่มล้วนๆ ตอนฝึก โมเดลจะดัน token ที่มีความหมายใกล้กันให้อยู่ในบริเวณเดียวกันของพื้นที่เชิงนามธรรม ตัวอย่างเช่น king และ queen อยู่ใกล้กันในทิศทางหนึ่ง python (ภาษา) และ javascript อยู่ใกล้กันในอีกทิศทางหนึ่ง และ python กับ snake (งูหลาม) ก็อยู่ใกล้กันในทิศทางที่สาม
ข้อมูลตำแหน่งถูกใส่เข้ามาในขั้นตอนนี้เช่นกัน เพราะกลไก attention เองไม่รู้ว่า token ตัวไหนอยู่ก่อนตัวไหนอยู่หลัง โมเดลที่นิยมในปัจจุบันใช้ RoPE (Rotary Position Embedding, การเข้ารหัสตำแหน่งแบบหมุน): หมุนเวกเตอร์ตามตำแหน่งของ token เพื่อฝังข้อมูลลำดับไว้ในตัวเวกเตอร์เอง
Step 3：Self-Attention คือหัวใจของ Transformer
ลำดับของเวกเตอร์จะถูกส่งเข้าชั้น transformer จำนวน 32 ชั้น (หรือมากกว่า) แต่ละชั้นทำ 2 อย่าง: ใช้ self-attention เพื่อผสมข้อมูลระหว่าง token ต่างๆ และใช้ feed-forward เพื่อผสมข้อมูลภายในแต่ละ token
การทำงานของ self-attention คือ: token แต่ละตัวผ่านเมทริกซ์น้ำหนักที่เรียนรู้ได้ 3 ชุด Wq, Wk, Wv เพื่อสร้าง query (แบบสอบถาม), key (คีย์), value (ค่า) จากนั้น token แต่ละตัวใช้ query ของตัวเองทำ dot product กับ key ของ token อื่นทั้งหมด เพื่อได้ “ค่าน้ำหนักที่ token นี้ควรดึงข้อมูลจากตำแหน่งไหน” แล้วนำไปถ่วงน้ำหนักเพื่อผสม value
นี่คือเวทมนตร์ของ attention: token แต่ละตัวเป็นผู้ตัดสินใจเองว่าควรมองบริบทที่ตำแหน่งไหนบ้าง และดึงข้อมูลที่มีประโยชน์เข้ามาไว้ในเวกเตอร์ของตัวมัน เมื่อซ้อนทับ 32 ชั้น โมเดลจะสามารถติดตามการอ้างอิงข้าม token ได้เป็นพันๆ ตัว ต่อจาก attention จะเป็น feed-forward ที่รับหน้าที่ “ความรู้ส่วนใหญ่” ของโมเดล ขณะที่ attention รับหน้าที่ขนส่งข้อมูล และ feed-forward รับหน้าที่ประมวลผลข้อมูล
Prefill และ Decode：GPU ตัวเดียวกัน แต่คอขวดคนละแบบ
นี่คือจุดแบ่งที่สำคัญที่สุดของบทความนี้ การสร้างคำตอบ 200 คำ โดยแท้จริงคือ “งาน 2 ประเภทที่มีคุณสมบัติแตกต่างกัน” ซึ่งทำงานบน GPU ตัวเดียวกัน
ขั้น prefill—เมื่อคุณส่ง prompt ออกไป โมเดลต้องรัน token อินพุตทั้งหมดครั้งหนึ่งก่อน จึงจะสร้าง token ตัวแรกได้ ขั้นนี้สามารถ “ขนาน” การประมวลผล token อินพุตทั้งหมดได้: Q, K, V ของแต่ละ token คำนวณพร้อมกัน และ attention เป็นการคูณเมทริกซ์ขนาดใหญ่กับเมทริกซ์ GPU ถูกออกแบบมาเพื่อการคำนวณแบบนี้ หน่วยคำนวณ (Tensor Cores) ทำงานเต็มพิกัด คอขวดอยู่ที่ “พลังการคำนวณ” ตัวชี้วัดความหน่วงของขั้นนี้เรียกว่า TTFT (Time to First Token, หน่วงก่อน token ตัวแรก)
ขั้น decode—หลังจาก token ตัวแรกออกมาแล้ว โมเดลจะเปลี่ยนโหมด ตอนที่สร้าง token ตัวที่ 51 มันแค่ต้องคำนวณ Q, K, V ของ token ใหม่ตัวนี้ ส่วน K, V ของ token เก่าก่อนหน้า 50 ตัวถูกคำนวณไว้แล้ว ไม่ต้องทำซ้ำอีก แต่ถึงปริมาณการคำนวณต่อ token จะน้อย อย่างไรก็ตาม GPU ยังต้องโหลดน้ำหนักทั้งโมเดลและประวัติ KV ทั้งหมดจากหน่วยความจำไปทำการคำนวณเล็กๆ หนึ่งรอบ แล้วส่งกลับไป ปัญหาเปลี่ยนจาก “พลังการคำนวณ” เป็น “แบนด์วิดธ์ของหน่วยความจำ” ตัวชี้วัดความหน่วงของขั้นนี้เรียกว่า ITL (Inter-Token Latency, ความหน่วงระหว่าง token) ซึ่งเป็นตัวกำหนดว่าความรู้สึกตอน “พิมพ์” ของโมเดลเร็วหรือไม่
ดังนั้น prefill คือ compute-bound และ decode คือ memory-bound—โมเดลและฮาร์ดแวร์เหมือนกัน แต่คุณลักษณะด้านประสิทธิภาพกลับต่างกันอย่างสิ้นเชิง
KV Cache：หัวใจของการทำให้การอนุมาน LLM ทำได้จริง
ในขั้น decode “ไม่ต้องคำนวณ K, V ของ token ในอดีตซ้ำ” ซึ่งทำได้ด้วย KV cache แต่ละชั้นของ transformer จะรักษาเทนเซอร์ 2 ชุด เก็บ K และ V ของ token ทั้งหมดในอดีต เมื่อคำนวณ K และ V ของ token ใหม่เสร็จ ก็จะ append เข้าไป พอตอน attention ก็อ่านประวัติทั้งหมดโดยตรง
ถ้าไม่มี KV cache การสร้างคำตอบ 1,000 token ทุกก้าวจะต้องคำนวณลำดับที่กำลังยาวขึ้นทั้งหมดอีกครั้ง ทำให้ความซับซ้อนระเบิดแบบกำลังสอง มี KV cache แล้ว การสร้างแบบยาวสามารถเร่งได้มากกว่า 5 เท่า แต่แลกมาด้วยต้นทุน: cache อยู่ในหน่วยความจำ GPU และทุกครั้งที่สร้าง token เพิ่ม cache ก็จะเพิ่มขึ้นหนึ่งหน่วย ขนาดโมเดล 13B แต่ละ token ใช้ราว 1MB ดังนั้น context 4K จะกินหน่วยความจำ 4GB เฉพาะเพื่อเก็บ cache นี้
นี่คือเหตุผลจริงที่ว่า “context ยาวช้าและแพง”—ไม่ใช่ว่าโมเดล “ทำไม่ไหว” แต่ cache กินหน่วยความจำจนหมด จำนวนผู้ใช้ที่เซิร์ฟได้พร้อมกันบน GPU ตัวเดียวก็ลดลงตามไปด้วย วิธีปรับปรุงที่พบบ่อย เช่น ทำให้ cache เป็น INT8 หรือ INT4, ใช้ sliding window ทิ้ง token ที่เก่ามากเกินไป, ใช้ grouped-query attention (GQA) ให้ multi attention head ใช้ K และ V ร่วมกัน หรืออย่าง vLLM ที่ใช้ PagedAttention จัดการ cache แบบแบ่งหน้า (คล้ายการจัดการหน่วยความจำของระบบปฏิบัติการ)
การปฏิวัติแคชของ DeepSeek V4：ลดเหลือ 10% จากของเดิมใน context 1M
การทำควอนไทซ์และการแบ่งหน้า (paging) ทำให้ KV cache กลายเป็น “ต้นทุนแบบคงที่” ที่ถูกปรับลด DeepSeek ช่วงปลายปี 2025 ที่ประกาศตัวอย่างซีรีส์ V4 เดินทางที่ยิ่งกว่าเดิม: ออกแบบ attention ใหม่โดยตรง ทำให้ cache เล็กลงตั้งแต่ต้น
V4 ใช้กลไกแบบผสม รวม variant ของ attention แบบ sparse และ dense ทั้งสองทำงานบนกระแส KV ที่ถูกบีบอัดอย่างมาก ในบริบทระดับล้าน token ลงไป รายงาน V4-Pro ระบุว่า KV cache มีขนาดเพียงราว 10% ของรุ่นก่อน และปริมาณคำนวณต่อ token ลดเหลือราว 27% ความหมายไม่ใช่แค่ “DeepSeek ถูกลงอีกครั้ง” แต่คือ KV cache ได้กลายเป็นคอขวดที่ถูกปรับแต่งในทั้งวงการ LLM แล้ว—เมื่อ attention mechanism ถูกออกแบบใหม่เพื่อทำให้ cache เล็กลง นั่นแปลว่า “เงื่อนไขจำกัด” ของทั้งชุมชนเทคนิคได้ถูกย้ายออกไปอย่างชัดเจน
สำหรับผู้อ่านในไต้หวัน ข้อมูลที่นำไปใช้ได้ทันทีคือ: DeepSeek V4-Flash ได้ขึ้น Ollama Cloud และเซิร์ฟเวอร์ในสหรัฐ (ดูรายงาน abmedia 4/24), Claude Code, OpenClaw สามารถเชื่อมต่อด้วยคลิกเดียว ทำให้ไม่ต้องตั้งค่าเองก็สามารถทดสอบข้อได้เปรียบของ attention รุ่นใหม่ในสถานการณ์ context ยาวได้
Quantization：แลกความแม่นยำเพื่อความเร็วและหน่วยความจำ
การฝึกต้องการความแม่นยำสูง แต่การอนุมานไม่จำเป็นต้องขนาดนั้น การดีพลอยที่เป็นทางการส่วนใหญ่จึงเปลี่ยนจาก FP32 ไปใช้ FP16 หรือ BF16 ทันที ซึ่งทำให้หน่วยความจำและ throughput เพิ่มขึ้นเป็นเท่าตัว วิธีที่ก้าวร้าวกว่านั้นคือทำให้ค่าน้ำหนักเป็น INT8 หรือแม้กระทั่ง INT4
ตัวเลขทำให้เห็นภาพ: โมเดล 7B ใน FP32 ต้องใช้ 28GB, FP16 ใช้ 14GB, INT8 ใช้ 7GB และ INT4 ใช้เพียง 3.5GB นี่คือเหตุผลที่ทำให้การ์ดจอในแล็ปท็อปทั่วไปก็สามารถรันโมเดลขนาด 7B ได้
วิธีเช่น GPTQ และ AWQ จะเลือกค่าตัวคูณ (scaling coefficients) ต่อแต่ละช่อง เพื่อทำให้การสูญเสียคุณภาพจากการบีบอัดมีน้อยที่สุด สำหรับ INT4 ที่ออกแบบดี ในหลายชุดสถิติ (benchmarks) ประสิทธิภาพจะต่ำกว่าเวอร์ชันเดิมเพียงภายใน 1 จุดเปอร์เซ็นต์
เมื่อรวมทุกขั้นเข้าด้วยกัน：การเดินทางแบบครบวงจรของ prompt หนึ่งชุด
เมื่อเรียงทุกขั้นตอนเข้าด้วยกัน เส้นทางการอนุมานแบบครั้งเดียวคือ:
(1) Tokenize—แปลงข้อความเป็น integer ID
(2) Embed—แปลง ID เป็นเวกเตอร์ และฉีดข้อมูลตำแหน่งเข้าไป
(3) Prefill—ทุกชั้นประมวลผล token อินพุตทั้งหมดแบบขนาน เป็น compute-bound, สร้าง KV cache และสร้าง token เอาต์พุตตัวแรก
(4) Decode loop—ในแต่ละครั้งจะฉาย (project) เฉพาะ token ใหม่ของ Q, ทำ attention กับ K, V ใน cache, รัน feed-forward, สุ่มเพื่อเลือกเอาต์พุต, จากนั้นเขียน K, V ใหม่ลงใน cache เป็น memory-bound
(5) Detokenize—แปลง token ID กลับเป็นอักขระ แล้วสตรีมเอาต์พุตไปยังหน้าจอ
เฟรมเวิร์กให้บริการอย่าง vLLM, TensorRT-LLM, Text Generation Inference จะเพิ่มการทำงานนอกวงจรนี้ เช่น การสลับเป็นชุดแบบต่อเนื่อง (token ของผู้ใช้ต่างรายสามารถสลับกันใน GPU step เดียว), speculative decoding (โมเดลเล็กสเก็ตช์ก่อน โมเดลใหญ่ตรวจทาน), และการจัดการหน่วยความจำแบบละเอียด นี่คือวิธีที่ทำให้ GPU ตัวเดียวสามารถให้บริการผู้ใช้ได้หลายสิบคน
ข้อสรุปเชิงปฏิบัติสำหรับนักพัฒนา：คุณควรสนใจ TTFT หรือ ITL？
เมื่อภาพรวมของกระบวนการอนุมานชัดเจนแล้ว การตัดสินใจเชิงปฏิบัติบางอย่างก็จะเกิดขึ้นตามธรรมชาติ:
prompt ยาวจะทำให้ TTFT แย่ลง และการส่ง output ยาวจะทำให้ ITL แย่ลง—ต้นตอแรงกดดันต่างกัน อย่าเอาทรัพยากรการปรับแต่งไปลงผิดตัวชี้วัด Context ไม่ได้ “ฟรี” การเพิ่ม context เป็น 2 เท่าคือไม่เพียงแค่คูณการคำนวณ แต่ยังไปกดทับจำนวน batch ที่ KV cache จะรองรับได้ด้วย การทำควอนไทซ์คือปุ่มที่ให้ผลตอบแทน (lever) สูงที่สุดในปัจจุบัน การเปลี่ยน FP16 ไปเป็น INT8 มักจะลด latency ลงได้ประมาณครึ่ง โดยที่การสูญเสียคุณภาพมีน้อยมาก
GPU utilization ก็เป็นตัวชี้วัดที่มักทำให้เข้าใจผิด—ในขั้น prefill GPU ถูกดึงให้เต็มพิกัด แต่ในขั้น decode อาจใช้ได้แค่ราว 30% ดังนั้นวิธีแก้ไม่ใช่เพิ่มพลังคำนวณ แต่ควรทำให้หน่วยความจำเร็วขึ้นหรือให้ cache เล็กลง
โครงสร้าง Transformer อาจดึงความสนใจได้มากที่สุด แต่ประสิทธิภาพของการอนุมานจริงๆ ไปอยู่ใน “รายละเอียดที่ดูไม่น่าสนใจ”: การจัดหน่วยความจำ การจัดการ cache ความกว้างบิต (bit width) ของข้อมูล เมื่อมีคนบอกว่า “โมเดลนี้ช้า” คำถามถัดไปที่ควรถามไม่ใช่ “เปลี่ยน GPU ไหม” แต่คือ “ช้าตรง ‘เริ่มต้น’ หรือช้าตรง ‘สตรีม’?” คำตอบจะกำหนดเส้นทางการปรับแต่งทั้งหมด
บทความสอนการอนุมาน LLM แบบครบชุดนี้：KV cache และการปฏิวัติแคชของ DeepSeek V4 เป็นครั้งแรกที่ปรากฏใน 链新闻 ABMedia
