ทำไม AI ถึงตอบเร็วไม่เท่ากัน? เจาะเบื้องหลัง LLM Inference Engineering
จากการทำนาย Token ทีละตัว ไปจนถึงเทคนิคจัดหน่วยความจำและการบริหาร GPU ที่เปลี่ยนโมเดลภาษาให้เป็นบริการที่รับผู้ใช้จำนวนมากได้
เวลาเราถาม AI หนึ่งคำถาม สิ่งที่เห็นคือข้อความไหลออกมาทีละคำ แต่สิ่งที่เกิดขึ้นเบื้องหลังซับซ้อนกว่านั้นมาก ระบบต้องอ่านคำถาม จัดสรรหน่วยความจำ ประมวลผลคำตอบทีละ Token และแย่งทรัพยากรกับคำขออื่น ๆ คำว่า LLM Inference Engineering คือศาสตร์การออกแบบขั้นตอนเหล่านี้ให้รวดเร็ว มีเสถียรภาพ และใช้ต้นทุนอย่างเหมาะสม
บทความนี้เรียบเรียงขึ้นใหม่จากแนวคิดใน GitHub llm-inference-engineering ที่ Amit Shekhar รวบรวมไว้ และตรวจประกอบกับเอกสารผู้พัฒนาระบบจริง มีสื่อโต้ตอบ 3 จุดให้กดทดลอง โดยตัวเลขในเครื่องมือจำลองใช้เพื่ออธิบายแนวคิด ไม่ใช่ผลทดสอบ Benchmark
AI ไม่ได้เขียนคำตอบทั้งประโยคในครั้งเดียว
โมเดลประเภท GPT เป็น Autoregressive Language Model กล่าวคือ โมเดลคำนวณความน่าจะเป็นของ Token ถัดไปจากบริบทก่อนหน้า จากนั้นเลือกหรือสุ่ม Token ตามวิธี Decoding ที่กำหนด เพิ่มลงในบริบท แล้วทำซ้ำจนกว่าจะพบเงื่อนไขหยุด เช่น Token จบคำตอบหรือถึงเพดานความยาว
Token ไม่จำเป็นต้องเท่ากับหนึ่งคำ ภาษาไทยอาจถูกแยกเป็นชิ้นส่วนของคำหรือหลายอักขระ ขึ้นกับ Tokenizer ของแต่ละโมเดล ดังนั้นคำตอบยาว ๆ อาจเกิดจากการวนรอบสร้างหลายร้อยหรือหลายพัน Token การรันเพียงคำถามเดียวจึงไม่ใช่การเรียกฟังก์ชันคำนวณหนึ่งครั้งแล้วได้คำตอบทั้งหมดออกมาทันที
ความต่างเพียงเล็กน้อยของเวลาที่ใช้สร้างแต่ละ Token เมื่อนำไปคูณกับจำนวน Token ในคำตอบ และจำนวนผู้ใช้พร้อมกัน จะกลายเป็นประเด็นสำคัญสำหรับผู้ดูแล AI Server เหตุนี้วิศวกรรม Inference จึงไม่ใช่เพียงทำให้โมเดลหนึ่งตัวตอบได้ แต่ต้องคิดทั้งความเร็ว ความจุ และประสิทธิภาพของทั้งระบบ
Interactive 01 · Token Generation
แตะที่ขั้นตอนเพื่อดูว่าโมเดลอ่าน Prompt และสร้างคำตอบทีละ Token อย่างไร
ขั้นที่ 1 · Prefill — อ่าน Prompt ก่อนตอบ
โมเดลอ่านบริบทและเตรียมสถานะ Key/Value ก่อนเข้าสู่การสร้างคำตอบ
ขั้นที่ 2 · Decode — Token แรก
โมเดลเลือก Token ถัดไปตามบริบท จากนั้นนำผลไปใช้กับรอบถัดไป
ขั้นที่ 3 · Decode — คำตอบกำลังก่อตัว
ตัวอย่างการต่อ Token เพิ่มเข้ากับลำดับที่มีอยู่
ขั้นที่ 4 · คำตอบเสร็จสิ้น
Token ที่ได้เรียงต่อกันเป็นข้อความคำตอบ
สาธิตด้วยข้อความที่เตรียมไว้ ไม่ได้เรียกโมเดล AI จริง ไม่ใช่ความเร็ว Benchmark
Prefill และ Decode คืออะไร ทำไมต้องแยกให้ชัด?
อ่านข้อมูลนำเข้า
เมื่อได้รับ Prompt โมเดลประมวลผล Token ที่ป้อนเข้ามาและสร้างสถานะ Key/Value ของบริบท ขั้นตอนนี้มักมีการคำนวณจำนวนมากและสามารถทำงานแบบขนานตามมิติของลำดับได้ จึงมักมีลักษณะ compute-intensive
สร้างคำตอบทีละ Token
หลังจากนั้นโมเดลสร้าง Token ใหม่ทีละขั้น โดยอาศัยบริบทกับ KV Cache ที่มีอยู่ สำหรับการให้บริการหลายกรณี ขั้นตอนนี้มักถูกจำกัดด้วยแบนด์วิดท์หน่วยความจำและการอ่านน้ำหนักโมเดลมากกว่ากำลังคำนวณล้วน ๆ
ผู้ใช้จำนวนหนึ่งพบว่า AI ใช้เวลาคิดนานก่อนเริ่มพิมพ์ แต่เมื่อเริ่มตอบแล้วข้อความไหลเร็ว อีกคำขอหนึ่งอาจเริ่มตอบเร็วแต่ไหลออกมาช้า เพราะคอขวดอยู่คนละช่วงของกระบวนการ ประโยคว่า “โมเดลนี้เร็ว” จึงไม่มีความหมายมากนักหากไม่ได้บอกว่ากำลังวัดความเร็วด้านใด
| ตัวชี้วัด | หมายถึง | ใช้ดูอะไร |
|---|---|---|
| TTFT (Time to First Token) | เวลาตั้งแต่ส่งคำขอจนได้ Token แรก รวมผลของการรอคิวและขั้นตอนเริ่มสร้างคำตอบ | AI เริ่มตอบช้าหรือเร็ว |
| TPOT (Time per Output Token) | เวลาเฉลี่ยต่อ Token หลังเริ่มสร้างคำตอบตามนิยามการวัดที่ใช้ | ข้อความไหลเร็วเพียงใด |
| Throughput | ปริมาณงานที่ระบบทำสำเร็จต่อหน่วยเวลา เช่น output tokens/sec หรือ requests/sec | การรองรับภาระรวม |
| VRAM / P95 latency | หน่วยความจำ GPU และค่าความหน่วงของกลุ่มคำขอที่ช้าที่สุด 5% ตามการวัด P95 | ต้นทุน ความเสถียร และประสบการณ์ปลายหาง |
เทคนิคบางอย่างเพิ่ม Throughput ได้แต่ไม่จำเป็นต้องลด Latency ของทุกคำขอ การเทียบแบบยุติธรรมควรใช้โมเดลเดียวกัน ขนาด Prompt และคำตอบใกล้เคียงกัน ปริมาณผู้ใช้พร้อมกันเท่ากัน และรายงานชนิด GPU รวมถึงเวอร์ชันซอฟต์แวร์ด้วย
KV Cache และ PagedAttention: ทำให้หน่วยความจำ GPU ไม่กลายเป็นคอขวด
ในชั้น Attention โมเดลสร้างข้อมูล Key และ Value จาก Token ที่ผ่านเข้ามา หากทุกครั้งที่สร้าง Token ใหม่ต้องคำนวณ Key/Value ของ Token เก่าซ้ำทั้งหมด ต้นทุนจะสูงโดยไม่จำเป็น KV Cache ช่วยเก็บสถานะเหล่านั้นไว้เพื่อนำกลับมาใช้ในรอบต่อไป จึงลดงานคำนวณซ้ำระหว่างการสร้างคำตอบ
แต่สิ่งที่แลกมาคือหน่วยความจำ ยิ่งบริบทยาว จำนวนชั้นและหัว Attention มาก หรือมีคำขอพร้อมกันหลายรายการ พื้นที่สำหรับ KV Cache ก็ยิ่งเพิ่มขึ้น และอาจเป็นข้อจำกัดแม้น้ำหนักโมเดลจะวางใน VRAM ได้แล้วก็ตาม การลดขนาด Weight ด้วย Quantization จึงไม่เท่ากับการแก้ปัญหา KV Cache ทุกกรณี
PagedAttention ซึ่งเป็นแนวคิดเด่นจากงานวิจัยของ vLLM ใช้การจัด KV Cache เป็นบล็อกและทำแผนที่ระหว่างตำแหน่งเชิงตรรกะกับบล็อกหน่วยความจำจริง คล้ายระบบ Paging ในระบบปฏิบัติการ ช่วยลดพื้นที่ที่สูญเปล่าจากการจองพื้นที่เกินความจำเป็น และเปิดโอกาสให้บริหารการใช้ Cache ร่วมกันในบางรูปแบบได้มีประสิทธิภาพขึ้น
Interactive 02 · KV Cache Memory Visualizer
แตะเลือกจำนวน Token ของคำขอ A เพื่อเปรียบเทียบการจองพื้นที่คงที่กับการแบ่งเป็นบล็อก
คำขอ A = 3 Token — กดดูการจัดหน่วยความจำ
สมมติคำขอ A = 3, B = 6 และ C = 3 Token
ใช้จริง 12 · จอง 48 · ว่าง 36 ช่อง
ใช้จริง 12 · จอง 16 · ว่าง 4 ช่อง
คำขอ A = 9 Token — กดดูการจัดหน่วยความจำ
สมมติคำขอ A = 9, B = 6 และ C = 3 Token
ใช้จริง 18 · จอง 48 · ว่าง 30 ช่อง
ใช้จริง 18 · จอง 24 · ว่าง 6 ช่อง
คำขอ A = 16 Token — กดดูการจัดหน่วยความจำ
สมมติคำขอ A = 16, B = 6 และ C = 3 Token
ใช้จริง 25 · จอง 48 · ว่าง 23 ช่อง
ใช้จริง 25 · จอง 28 · ว่าง 3 ช่อง
ตัวเลขพื้นที่เป็นแบบจำลองสมมติ ไม่ใช่ผลวัด VRAM จริงของ vLLM และไม่ใช่ข้อกำหนดว่าระบบอื่นต้องจอง 16 ช่องเสมอ
อีกแนวคิดที่เกี่ยวข้องคือ Prefix Caching หากคำขอหลายครั้งมีส่วนต้นของ Prompt เหมือนกัน ระบบที่รองรับอาจนำสถานะบางส่วนกลับมาใช้ได้ เช่น คำสั่งระบบขนาดใหญ่ที่ใช้ซ้ำกับผู้ใช้หลายราย อย่างไรก็ตาม ผลลัพธ์ขึ้นอยู่กับการตรงกันของ Prefix การตั้งค่า Cache และสภาพคิวในขณะนั้น
FlashAttention: เมื่อการย้ายข้อมูลใน GPU สำคัญพอ ๆ กับการคำนวณ
Attention มาตรฐานเกี่ยวข้องกับการคำนวณคะแนนความสัมพันธ์ระหว่าง Token และการทำ Softmax หากทำในรูปแบบที่เขียนและอ่านผลลัพธ์ตัวกลางขนาดใหญ่จากหน่วยความจำความเร็วสูง (HBM) บ่อยครั้ง ค่าใช้จ่ายจากการเคลื่อนย้ายข้อมูลอาจสูงมาก FlashAttention เปลี่ยนวิธีจัดลำดับการคำนวณเป็นบล็อกย่อย (Tiling) และใช้ Online Softmax เพื่อลดการอ่านเขียนข้อมูลตัวกลางลง
ความสำคัญคือ FlashAttention เป็น Exact Attention Algorithm ในความหมายเชิงคณิตศาสตร์ ไม่ใช่การตัดทอน Attention ให้เป็นคำตอบใกล้เคียงเพื่อแลกกับความเร็ว ถึงอย่างนั้นค่าตัวเลขบนคอมพิวเตอร์อาจต่างได้เล็กน้อยจากการจัดลำดับการคำนวณและชนิดความละเอียดตัวเลข
FlashAttention 1
เน้นลด I/O ระหว่างหน่วยความจำด้วยการคำนวณแบบ Blockwise และ Online Softmax แทนการสร้างเมทริกซ์คะแนนตัวกลางขนาดใหญ่เต็มรูป
FlashAttention 2
ปรับการแบ่งงาน ความขนาน และการใช้งาน GPU ให้ดีขึ้นกับหลาย Workload โดยเฉพาะประสิทธิภาพของ Kernel และการกระจายงาน
FlashAttention 3
ออกแบบให้ใช้จุดแข็งของ GPU ตระกูล Hopper เช่น H100 ในการซ้อนงานคำนวณและเคลื่อนย้ายข้อมูล ทั้งนี้ข้อกำหนดฮาร์ดแวร์และเวอร์ชันต้องตรวจแยกตามการติดตั้ง
ต้องใช้อันไหน?
ไม่มีคำตอบตายตัว ต้องดู GPU, ชนิดข้อมูล, โมเดล, Attention Backend ที่ Engine เลือกใช้ และเสถียรภาพที่ต้องการ บางระบบเลือก Kernel ที่เหมาะให้โดยอัตโนมัติ
ข้อสำคัญ: PagedAttention กับ FlashAttention ไม่ใช่คู่แข่งกันโดยตรง ตัวแรกเน้นจัดการการเข้าถึง KV Cache แบบแบ่งบล็อก ส่วนตัวหลังเน้นการคำนวณ Attention ให้ใช้หน่วยความจำและ GPU อย่างคุ้มค่า ระบบ Inference สมัยใหม่อาจผสานทั้งสองแนวคิดผ่าน Backend ที่รองรับได้
Continuous Batching: ทำไมคนตอบเสร็จก่อนจึงไม่ควรทำให้ช่อง GPU ว่าง?
สมมติว่าเรามีคำขอ A, B และ C ที่สร้างคำตอบยาว 2, 6 และ 3 Token ตามลำดับ หากระบบจับทั้งสามเป็น Batch คงที่ แล้วรอให้ทุกคำขอจบก่อนเริ่ม Batch ใหม่ ช่องงานของ A จะว่างตั้งแต่สร้างครบ 2 Token ทั้งที่ B ยังต้องทำต่ออีกหลายรอบ ความสูญเปล่าแบบนี้พบได้ในระบบจัดคิวที่ไม่มีการแทนที่สมาชิก Batch ระหว่างรอบสร้าง Token
Continuous Batching หรือการจัด Batch แบบต่อเนื่อง ช่วยรับงานใหม่เข้ามาแทนช่องที่ว่างในระหว่างรอบสร้าง Token ได้ โดยไม่ต้องรอให้ทุกคำขอใน Batch เดิมจบก่อน เหมาะกับลักษณะงาน LLM ที่ความยาวคำตอบไม่แน่นอน และมีคำขอเข้าออกตลอดเวลา แนวคิดนี้เป็นหนึ่งในเทคนิคหลักของระบบ LLM Serving อย่าง vLLM
Interactive 03 · Static vs Continuous Batching
แตะสลับสองวิธีเพื่อดูตารางงานสำหรับ 5 คำขอ A=2, B=6, C=3, D=4 และ E=2 Token มีช่องงาน 3 ช่องต่อรอบ
Static Batching — 10 รอบ (57%)
รอให้ทุกคำขอในชุดเดิมจบก่อนเริ่มชุดใหม่
Continuous Batching — 6 รอบ (94%)
เมื่อมีช่องว่างสามารถรับคำขอใหม่เข้ามาได้
ตัวเลข 10/6 รอบ และ 57%/94% เป็นผลจากการนับช่องงานในแบบจำลอง ไม่ใช่ GPU Utilization จริง การใช้งานจริงมีต้นทุน Prefill, Queue และ Scheduling เพิ่มเติม
เมื่อโหลดจริงเพิ่มขึ้น Scheduler ยังต้องดูความยุติธรรมของคิว ช่วงเวลารอ ความจำที่เหลือ และความสมดุลระหว่าง Prefill กับ Decode อีกด้วย การเพิ่ม Throughput โดยไม่พิจารณา TTFT และความหน่วงปลายหางอาจทำให้บางกลุ่มผู้ใช้รอนานกว่าเดิม
Speculative Decoding และ Streaming: เร่งงานกับทำให้รู้สึกเร็ว เป็นคนละเรื่อง
การสร้าง Token ทีละขั้นมีข้อจำกัดจากการพึ่งพาผลของ Token ก่อนหน้า เทคนิค Speculative Decoding แก้ปัญหาด้วยการให้โมเดลร่างขนาดเล็ก (Draft Model) หรือวิธีเสนอ Token แบบอื่น ช่วยคาดการณ์ Token หลายตัว จากนั้นโมเดลหลัก (Target Model) ตรวจคำทำนายเหล่านั้นเป็นชุด ถ้าผ่านมาก ระบบอาจเพิ่มจำนวน Token ที่ยืนยันได้ต่อรอบและลดเวลาในการสร้างคำตอบ
แนวทางการตรวจและแก้ความน่าจะเป็นที่ถูกต้องสามารถรักษาการแจกแจงผลลัพธ์ของโมเดลเป้าหมายได้ตามเงื่อนไขของอัลกอริทึม แต่ไม่ได้หมายความว่าวิธีการร่างทุกแบบจะได้ผลเหมือนกัน หรือจะเร็วกว่าเสมอ หาก Draft Model ทายผิดมากหรือมีต้นทุนเพิ่มเติมสูง ประโยชน์อาจลดลงหรือไม่คุ้มค่า
Token Streaming ต่างออกไป: เป็นวิธีส่งข้อความส่วนที่สร้างเสร็จแล้วให้ผู้ใช้เห็นทันที แทนการรอให้คำตอบครบก่อนค่อยแสดงทั้งหมด จึงช่วยเรื่องความรู้สึกตอบสนองไว แต่ไม่ได้รับประกันว่าจะเพิ่มจำนวน Token ที่ GPU สร้างได้ในหนึ่งวินาที เพราะเป็นการเปลี่ยนวิธีส่งและแสดงผล ไม่ใช่การเพิ่มประสิทธิภาพการคำนวณโดยตัวมันเอง
vLLM, SGLang, Ollama และ TensorRT-LLM ต่างกันอย่างไร?
เทคนิคที่กล่าวมาจะมีประโยชน์มากขึ้นเมื่อถูกนำมาประกอบเป็น Inference Engine ที่ทำหน้าที่โหลดโมเดล จัดการ GPU และหน่วยความจำ จัดคิวคำขอ และเปิด API ให้ระบบอื่นเรียกใช้ แต่ไม่มี Engine ที่เหมาะกับทุกสถานการณ์ การเลือกควรตั้งต้นจากงานจริง มากกว่าเลือกเพราะ Benchmark เดียว
| เครื่องมือ | จุดเด่นโดยสรุป | เหมาะเริ่มต้นเมื่อ | ข้อควรตรวจสอบ |
|---|---|---|---|
| Ollama | ติดตั้งและทดลอง Local LLM ง่าย มี API ใช้งานสะดวก | ทดลองโมเดลบนคอมพิวเตอร์ส่วนตัวหรือทีมเล็ก | โมเดล/ฟอร์แมต/ฮาร์ดแวร์และประสิทธิภาพเมื่อหลายผู้ใช้ |
| vLLM | ระบบ Serving ที่เน้น Throughput มี PagedAttention, Continuous Batching และ API ที่เข้ากันได้กับ OpenAI | ทำ AI Server รองรับคำขอจำนวนมาก | รองรับโมเดล GPU และการตั้งค่า Scheduling ที่ใช้จริงหรือไม่ |
| SGLang | Runtime สำหรับ LLM Serving และการใช้งานที่มีโครงสร้าง โดยมีเทคนิค เช่น RadixAttention เพื่อใช้ Cache ซ้ำ | ระบบที่มี Prompt ซ้ำ งานหลายขั้น หรือ Structured Output | Workload ของคุณได้ประโยชน์จาก Prefix และความสามารถที่ตั้งค่าไว้หรือไม่ |
| TensorRT-LLM | ชุดเครื่องมือ Inference Optimization ในระบบนิเวศ NVIDIA เน้นการปรับประสิทธิภาพ Kernel และการให้บริการ | มีระบบ GPU NVIDIA และพร้อมดูแลการตั้งค่าเชิงลึก | ข้อกำหนดเวอร์ชัน Driver/CUDA และต้นทุนดูแลระบบ |
การแบ่งประเภทนี้เป็นเพียงจุดเริ่มต้น ไม่ใช่การตัดสินว่า Engine หนึ่งเร็วกว่าอีกตัวเสมอ เช่น vLLM กับ SGLang ต่างรองรับการให้บริการประสิทธิภาพสูงและมีฟีเจอร์ทับซ้อนกันมาก ผลลัพธ์ที่เชื่อถือได้ควรเทียบจากโมเดลเดียวกัน ระบบ GPU เดียวกัน และชุดคำขอจริงของโครงการ
ชวนคิด: เราไม่จำเป็นต้องสร้าง Engine ใหม่เองเสมอ
สำหรับผู้เริ่มต้น ขั้นแรกที่คุ้มค่าคือเข้าใจวงจรของคำขอและตัวชี้วัดก่อน เมื่อพบปัญหาเฉพาะจึงเลือก Engine หรือเปิดความสามารถเสริมที่ตรงกับคอขวด แทนการเพิ่มเทคโนโลยีหลายชิ้นโดยยังไม่ได้วัดผล
ถ้าจะนำไปใช้กับ Local LLM, AI Server และ Multi-Agent ต้องเริ่มตรงไหน?
กรณีที่ 1: รันโมเดลส่วนตัว
เริ่มจากตรวจขนาดน้ำหนักโมเดล ฟอร์แมต Quantization และ VRAM หรือ RAM ที่ใช้งานได้จริง จากนั้นทดลอง Prompt สั้นและยาวแยกกัน วัดเวลาจนเห็น Token แรก ความเร็วขณะสร้างคำตอบ และปริมาณหน่วยความจำที่ใช้ จะช่วยแยกปัญหาได้ว่าติดตอนอ่าน Prompt หรือตอน Decode ก่อนจะตัดสินใจเปลี่ยนฮาร์ดแวร์หรือ Engine
กรณีที่ 2: ทำ AI Server ให้หลายคนใช้พร้อมกัน
ให้ทดสอบภาระงานพร้อมกันหลายระดับ เริ่มจาก Baseline ที่วัดได้ แล้วค่อยประเมิน Continuous Batching, Paged KV Cache และ Prefix Caching โดยต้องติดตามทั้ง Throughput กับ P95 Latency ไม่ใช่ความเร็วเฉลี่ยเพียงค่าเดียว และเผื่อ VRAM ไว้สำหรับ Cache และความผันผวนของภาระงานด้วย
กรณีที่ 3: ทำระบบ Multi-Agent
Inference Engineering ช่วยเพิ่มประสิทธิภาพของการรันโมเดลที่ Agent เรียกใช้ แต่ ไม่ได้แก้ปัญหา Agent รอกันโดยอัตโนมัติ หากงาน A ต้องรอ B และ C ทั้งที่ทำพร้อมกันได้ คอขวดอาจอยู่ที่ Agent Orchestration หรือเครื่องมือภายนอก ไม่ใช่ที่ GPU ขั้นแรกควรวัดเวลาที่เสียไปกับการรอคิวโมเดล การเรียก Tool การตอบกลับจากเครือข่าย และ Dependency ระหว่าง Agent ให้แยกจากกัน
ถ้า TTFT สูง
ตรวจเวลา Queue, ความยาว Prompt, Prefill, Cache Hit และเวลารอ Tool ก่อนคิดเปลี่ยนโมเดล
ถ้า TPOT สูง
ตรวจ Decoder, ขนาดโมเดล, Backend, KV Cache และหน่วยความจำที่ถูกใช้ร่วมกัน
ถ้า VRAM ไม่พอ
แยกพื้นที่ Weight / KV Cache / Buffer แล้วค่อยพิจารณา Quantization, Cache Management หรือเครื่องมือที่เหมาะ
ถ้า Agent ทำงานช้า
วาดแผน Dependency และจับเวลา Tool Calls กับเวลารอ แล้วแก้ที่ Scheduling ก่อนโทษ Inference Engine
ท้ายที่สุด ความเร็วที่ดีคือการหาสมดุลระหว่าง คุณภาพผลลัพธ์ ความหน่วง ต้นทุน พลังงาน และความน่าเชื่อถือ การเพิ่ม Throughput อย่างเดียวไม่ช่วยหากคุณภาพคำตอบตกหรือผู้ใช้บางกลุ่มต้องรอนานขึ้น หากมีงบจำกัด ให้ปรับปรุงโดยอาศัยผลวัดของ Workload จริงเป็นหลัก
อ่านต่อบน Hybrid Mind: หากสนใจบทบาทของระบบ AI Agent ลองอ่าน AI ERA 2026 — จากคนใช้ AI สู่ AI ที่ไปทำงานแทนคน และถ้าอยากเปรียบเทียบกับการเพิ่มประสิทธิภาพช่วง Training ซึ่งเป็นอีกขั้นตอนหนึ่ง อ่านงานวิจัย Seer ของ Kimi ที่ช่วยลดเวลารอใน RL Rollout
คำถามที่พบบ่อยเกี่ยวกับ LLM Inference
LLM Inference ต่างจาก Training อย่างไร?
Training เป็นกระบวนการปรับพารามิเตอร์ของโมเดลจากข้อมูล ส่วน Inference คือการนำโมเดลที่ฝึกแล้วมาใช้ทำนายหรือสร้างผลลัพธ์ให้กับคำขอ งาน Inference ไม่ได้หมายถึงการสอนให้โมเดลเรียนรู้ใหม่ในทุกครั้งที่ถาม
KV Cache ทำให้ AI จำบทสนทนาได้ถาวรหรือไม่?
ไม่ใช่ KV Cache เป็นสถานะสำหรับคำนวณ Attention ระหว่างรันคำขอหรือช่วงที่ระบบยังเก็บ Cache ได้ ต่างจากความจำถาวรในฐานข้อมูลหรือระบบ Memory ของ AI Agent
FlashAttention ช่วยลดการใช้ VRAM เหมือน PagedAttention ไหม?
ทั้งสองช่วยเรื่องประสิทธิภาพหน่วยความจำ แต่คนละจุด FlashAttention ลดการอ่านเขียนข้อมูลตัวกลางในการคำนวณ Attention ขณะที่ PagedAttention เน้นการจัดสรรและเข้าถึง KV Cache เป็นบล็อก
Continuous Batching ทำให้ทุกคำขอตอบเร็วขึ้นเสมอไหม?
ไม่เสมอ จุดเด่นคือการใช้ทรัพยากรระหว่างคำขอหลายรายการให้คุ้มขึ้น แต่ผลด้าน Latency ของแต่ละคนยังขึ้นกับคิว ปริมาณงาน นโยบาย Scheduling และหน่วยความจำที่มี
Speculative Decoding จะทำให้โมเดลตอบฉลาดขึ้นหรือไม่?
ไม่ใช่เป้าหมายหลัก เทคนิคนี้มุ่งลดเวลาสร้าง Token โดยเสนอหลาย Token ให้ Target Model ตรวจ ผลด้านคุณภาพขึ้นกับวิธีตรวจและอัลกอริทึมที่ใช้ ไม่ควรตีความว่าเป็นเทคนิคเพิ่มความรู้ให้โมเดล
ควรใช้ vLLM หรือ Ollama ถ้าเพิ่งเริ่มต้น?
ถ้าเน้นทดลอง Local LLM ด้วยขั้นตอนง่าย Ollama อาจเป็นจุดเริ่มต้นที่เหมาะ หากเป้าหมายเป็นบริการที่มีคำขอพร้อมกันจำนวนมาก ให้ประเมิน vLLM หรือ SGLang โดยเทียบกับฮาร์ดแวร์และโมเดลที่คุณมี
แหล่งข้อมูลและวิธีตรวจสอบ
บทความนี้เป็นงานเรียบเรียงและออกแบบสื่ออธิบายใหม่ของ Hybrid Mind อ้างอิงเนื้อหาจากผู้พัฒนาและงานวิจัยต้นทาง ไม่ใช่การแปลบทความภายนอกแบบคำต่อคำ
- Amit Shekhar / Outcome School — LLM Inference Engineering (GitHub) — โครงหัวข้อหลักและแหล่งเรียนรู้ต่อ
- Kwon et al. — Efficient Memory Management for Large Language Model Serving with PagedAttention — งานวิจัยต้นทาง vLLM / PagedAttention
- Dao-AILab — FlashAttention Repository — รุ่นและข้อกำหนด FlashAttention
- vLLM Documentation — คุณสมบัติ Serving, Batching และ Cache
- Zheng et al. — SGLang: Efficient Execution of Structured Language Model Programs — SGLang และ RadixAttention
หมายเหตุบรรณาธิการ: เทคโนโลยี Inference เปลี่ยนเร็ว เนื้อหานี้เน้นหลักการที่ตรวจสอบย้อนกลับได้ และไม่ได้รับรอง Benchmark ของเครื่องมือใดว่าตรงกับทุกฮาร์ดแวร์
Responses
[…] Hybrid Mind: LLM Inference Engineering และ เมื่อ AI Agent […]
[…] อ่านต่อ: ทำไม AI ตอบเร็วไม่เท่ากัน? LLM Infe…อ่านต่อ: Seer ของ Kimi กับการฝึก RLอ่านต่อ: เมื่อ AI Agent เปลี่ยนวิธีสร้างบทความ […]
[…] […]
[…] […]
[…] LLM Inference Engineering: ทำไม AI ถึงตอบเร็วไม่เท่ากั… […]