LLMs 101: คู่มือฉบับปฏิบัติ (ฉบับปี 2026)

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

คำแนะนำเชิงปฏิบัติเกี่ยวกับการทำงานของ LLM, วิธีที่โมเดลคิดทีละ 1 โทเค็น, และวิธีรันโมเดลในเครื่องของคุณ

เมื่อเข้าใจลูปนี้แล้ว การเลือกฮาร์ดแวร์และซอฟต์แวร์จะง่ายขึ้น VRAM, quantization, ความยาวบริบท, chat templates, decoding, RAG, serving engines, และการเลือกโมเดล ล้วนเป็นกลไกเดียวกัน

เริ่มต้นด้วยลูป: โทเค็นเข้า, ความน่าจะเป็นออก, ทีละหนึ่งโทเค็นถัดไป น้ำหนักบอกโมเดลว่ารูปแบบใดที่มันเรียนรู้ บริบทบอกว่ากำลังมองอะไรอยู่ตอนนี้ KV cache คือหน่วยความจำทำงานที่ทำให้ลูปใช้งานได้ ฮาร์ดแวร์, รันไทม์, และการเลือกโมเดลจะสมเหตุสมผลก็ต่อเมื่อคุณเข้าใจหน่วยความจำ, บริบท, และกฎการจัดรูปแบบที่โมเดลปฏิบัติตาม

เป้าหมายคือทำให้กลไกของ LLM ท้องถิ่นเข้าใจได้ง่ายก่อน จากนั้นให้เส้นทางปฏิบัติสู่ฮาร์ดแวร์, รันไทม์, การให้บริการ, และงานวิจัย LLM ปัจจุบัน ณ วันที่ 21 พฤษภาคม 2026

Focus

นี่คือคู่มือที่เน้นโมเดลเป็นหลัก เริ่มต้นด้วยกลไก: inference, tokens, Transformers, attention, KV cache, prefill, decode, การควบคุมการถอดรหัส, ชุดโมเดล, chat templates, ประเภทโมเดล, บริบทยาว, RAG, agents, fine-tuning, และ multimodal models

หลังจากนั้น จะเข้าสู่ชั้นการปรับใช้ในเครื่อง: ความหมายของ local, quantization, คณิตศาสตร์ VRAM, ระดับฮาร์ดแวร์, ตัวเลือกรันไทม์, โหมดการให้บริการ, ใบอนุญาต, การเลือกโมเดล, ความเป็นส่วนตัว, การแก้ปัญหา, benchmarks, เส้นทางการตั้งค่า, และกรณีการใช้งานจริง

ลำดับนั้นสำคัญ คุณควรเข้าใจว่าเหตุใดพรอมต์ยาวจึงใช้หน่วยความจำมากก่อนเลือก GPU คุณควรเข้าใจว่าเหตุใด chat templates จึงสำคัญก่อนตัดสินโมเดล คุณควรเข้าใจว่าเหตุใด decode จึงเป็นลำดับก่อนใส่ใจ tokens ต่อวินาที

สำหรับเส้นทางฮาร์ดแวร์และซอฟต์แวร์ที่ลึกขึ้น ผมมีซีรีส์สามส่วนสอนการโฮสต์ LLM ด้วยตนเอง / AI ท้องถิ่น:

• ส่วนที่ 1: คณิตศาสตร์หน่วยความจำ GPU สำหรับ LLM (ฉบับ 2026).
• ส่วนที่ 2: แบนด์วิดท์หน่วยความจำสำหรับฮาร์ดแวร์ AI ท้องถิ่น (ฉบับ 2026).
• ส่วนที่ 3: อินเฟอเรนซ์เอนจินสำหรับ LLM และฮาร์ดแวร์ AI ท้องถิ่น (ฉบับ 2026).

สองส่วนแรกอธิบายความจุฮาร์ดแวร์และคณิตศาสตร์แบนด์วิดท์ ส่วนที่สามอธิบายชั้นซอฟต์แวร์ที่เปลี่ยนฮาร์ดแวร์นั้นให้เป็นการอนุมานที่ใช้งานได้ บทความนี้ให้พื้นฐานด้านโมเดลก่อน จากนั้นชี้กลับไปยังชั้นการปรับใช้เหล่านั้นเมื่อกลไกชัดเจนแล้ว

What An LLM Actually Does

การรันโมเดลเรียกว่า inference สำหรับ LLM แบบ decoder-only มาตรฐาน inference คือลูปเดียวกันที่ทำซ้ำแล้วซ้ำอีก:

1. แปลงข้อความของคุณเป็นโทเค็น
2. ป้อนโทเค็นเหล่านั้นเข้าไปในโมเดล
3. คำนวณคะแนนสำหรับทุกโทเค็นถัดไปที่เป็นไปได้
4. เลือกหนึ่งโทเค็นด้วยนโยบายการถอดรหัส
5. ต่อท้ายโทเค็นนั้นในลำดับ
6. ทำซ้ำจนกว่าโมเดลจะหยุด ผู้ใช้หยุด หรือถึงขีดจำกัดโทเค็น

โมเดลไม่ได้เขียนคำตอบทั้งหมดในครั้งเดียว มันสร้างทีละหนึ่งโทเค็น ทุกโทเค็นใหม่จะกลายเป็นส่วนหนึ่งของลำดับที่มีอิทธิพลต่อโทเค็นถัดไป

ในเชิงคณิตศาสตร์ โมเดลคือฟังก์ชันที่เรียนรู้:

f(theta, sequence) -> การกระจายความน่าจะเป็นของ next_token

โดยที่:

• theta หมายถึงน้ำหนักของโมเดล
• sequence หมายถึงพรอมต์บวกโทเค็นที่สร้างขึ้นจนถึงตอนนี้
• Logits คือคะแนนดิบก่อน softmax
• Probabilities คือคะแนนปกติหลัง softmax
• Decoding เปลี่ยนความน่าจะเป็นเหล่านั้นเป็นโทเค็นที่เลือกหนึ่งตัว

นี่คือเหตุผลที่ความเร็วในการสร้างในเครื่องวัดเป็น tokens ต่อวินาที ระบบของคุณทำงาน forward pass ซ้ำๆ เลือกหรือสุ่มโทเค็น อัปเดต KV cache และดำเนินต่อไป

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

Tokens

LLM ไม่เห็นข้อความดิบเป็นคำ พวกมันเห็นโทเค็น: ชิ้นข้อความเล็กๆ ที่แสดงภายในเป็น ID จำนวนเต็ม

โทเค็นอาจเป็น:

• คำทั้งคำ: "hello"
• ส่วนของคำ: "inter", "national", "ization"
• เครื่องหมายวรรคตอน
• สตริงที่นำหน้าด้วยการเว้นวรรค
• การ fallback ระดับไบต์
• เครื่องหมายควบคุมพิเศษ เช่น <|user|>, <|assistant|>, , หรือ

Tokenizer จับคู่ข้อความกับ token ID และ token ID กลับเป็นข้อความ ครอบครัว tokenizer ทั่วไปรวมถึง tokenizer แบบ BPE และ tokenizer แบบ SentencePiece ตระกูลโมเดลที่ต่างกันใช้ tokenizer ที่ต่างกัน และนั่นสำคัญ เอกสาร 4,000 คำอาจเป็น 5,000 โทเค็นใน tokenizer หนึ่ง และ 7,500 โทเค็นในอีกตัว

ขนาดคำศัพท์ก็สำคัญเช่นกัน Tokenizer ที่มีคำศัพท์ใหญ่กว่าสามารถบีบอัดข้อความบางส่วนเป็นโทเค็นน้อยลง แต่ก็เปลี่ยนขนาด embedding และ output-projection ด้วย นี่คือเหตุผลหนึ่งที่ tokens ต่อวินาทีไม่สามารถเปรียบเทียบได้สมบูรณ์แบบข้ามตระกูลโมเดล

โทเค็นสำคัญเพราะมันกำหนด:

• ข้อความเท่าใดที่พอดีในหน้าต่างบริบท
• KV cache ใหญ่แค่ไหน
• คุณเสียเวลาแฝงเท่าใดระหว่างการประมวลผลพรอมต์
• ข้อความหลายภาษาหรือโค้ดหนามีประสิทธิภาพหรือไม่
• โมเดลเห็นเครื่องหมายแชทพิเศษอย่างถูกต้องหรือไม่

หน้าต่างบริบทของโมเดลคือจำนวนโทเค็นสูงสุดที่สามารถให้ความสนใจได้ในครั้งเดียว ในปี 2026 โมเดลที่ใช้งานในเครื่องทั่วไปมีตั้งแต่บริบท 8K และ 32K ถึง 128K, 256K และแม้แต่บริบท 1M โทเค็นในระบบระดับเซิร์ฟเวอร์

แต่ความยาวบริบทที่รองรับไม่เหมือนกับบริบทที่ถูก รวดเร็ว หรือแม่นยำเท่ากัน โมเดลที่สามารถจัดการ 128K โทเค็นในทางเทคนิคอาจช้าลงมากที่ 64K และสูญเสียความสอดคล้องที่ 100K ทดสอบความยาวบริบทที่คุณวางแผนจะใช้จริงเสมอ

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

แบบฝึกหัดที่มีประโยชน์: ลอง แอปสาธิต Tokenizer ของผมเพื่อดูว่าข้อความถูกแยกเป็นโทเค็นแบบเรียลไทม์

Transformers

LLM สมัยใหม่ส่วนใหญ่ใช้สถาปัตยกรรม Transformer LLM แชทท้องถิ่นส่วนใหญ่เป็น Transformer แบบ decoder-only: พวกมันทำนายโทเค็นถัดไปโดยมองย้อนกลับไปที่โทเค็นก่อนหน้า

ทุกอย่างก่อนหน้านี้ รวมถึง tokens, weights, config, และ chat templates คือการตั้งค่าสำหรับเอนจินจริงที่อยู่ข้างใต้ Transformer คือโครงกระดูกที่ย้ายตัวเลขไปมา

ชั้น Transformer แบบย่อประกอบด้วย:

1. Token embeddings: Token ID กลายเป็นเวกเตอร์
2. ข้อมูลตำแหน่ง: โมเดลต้องการลำดับโทเค็น LLM สมัยใหม่หลายตัวใช้ RoPE (Rotary Position Embeddings) ซึ่งเข้ารหัสตำแหน่งโดยหมุนการแสดงผล
3. Self-attention: การแสดงผลของแต่ละโทเค็นมองย้อนกลับไปที่การแสดงผลของโทเค็นก่อนหน้าและตัดสินใจว่าสิ่งใดสำคัญ
4. MLP / feed-forward block: การคำนวณไม่เชิงเส้นแบบหนาแน่นที่ขยายและบีบอัดการแสดงผล พารามิเตอร์ส่วนใหญ่อยู่ที่นี่
5. Layer normalization และ residual connections: สิ่งเหล่านี้ทำให้เครือข่ายลึกเสถียรและช่วยให้ข้อมูลไหลผ่านหลายชั้น
6. Output projection: สถานะซ่อนสุดท้ายกลายเป็น logits เหนือคำศัพท์

ซ้อนสูตรนี้หลายสิบหรือหลายร้อยครั้งแล้วคุณจะได้โมเดลภาษา

สรุป Transformer: โทเค็นกลายเป็นเวกเตอร์, attention เชื่อมต่อลำดับ, MLP ปรับรูปแบบการแสดงผล, RoPE รักษาตำแหน่งให้ตรง, และ projection สุดท้ายเปลี่ยนสถานะซ่อนสุดท้ายเป็น next-token logits

Attention

Attention คือวิธีที่โทเค็นตัดสินใจว่าโทเค็นก่อนหน้าใดสำคัญสำหรับการทำนายถัดไป นอกจากนี้ยังเป็นสาเหตุหนึ่งที่การอนุมานในเครื่องไวต่อหน่วยความจำมาก

MHA (multi-head attention) แบบคลาสสิกจัดเก็บสถานะ key/value แยกสำหรับหลายหัว มันให้ความยืดหยุ่นแก่โมเดล แต่ทำให้ KV cache ใหญ่

โมเดลท้องถิ่นสมัยใหม่มักใช้การออกแบบ attention ที่มีประสิทธิภาพมากขึ้น:

• MQA: Multiple query heads แชร์หนึ่ง key/value head มันประหยัดหน่วยความจำ แต่อาจแสดงออกน้อยลง
• GQA: กลุ่มของ query heads แชร์ key/value heads มันเป็นจุดกึ่งกลางทั่วไปในโมเดลท้องถิ่นปัจจุบันหลายตัว
• MHA: Full multi-head attention มันอาจแข็งแกร่ง แต่บริบทยาวมีราคาแพงอย่างรวดเร็ว

เคอร์เนลสมัยใหม่เช่น FlashAttention และการใช้งานแบบ SDPA ลดการรับส่งข้อมูลหน่วยความจำ attention และทำให้ GPU ทำงานมากขึ้น รันไทม์ที่มีเคอร์เนล attention ที่ดีสามารถเร็วกว่าตัวที่ไม่มีอย่างมาก แม้ในโมเดลและฮาร์ดแวร์เดียวกัน

นี่คือเหตุผลที่โมเดล 7B สองตัวสามารถทำงานแตกต่างกันมากที่บริบทยาว จำนวนพารามิเตอร์ไม่ใช่ทั้งหมด โมเดล 7B MHA ที่บริบท 128K สามารถใช้ GPU 24 GB หมด ในขณะที่โมเดล 7B GQA ที่มีบริบทโฆษณาเท่ากันอาจพอดีและมีที่ว่างเหลือ

เมื่อเปรียบเทียบโมเดล ดูที่ประเภท attention, KV heads, ความยาวบริบท, และการสนับสนุนรันไทม์ ไม่ใช่แค่จำนวนพารามิเตอร์

KV Cache

KV cache คือหน่วยความจำทำงานของโมเดลระหว่างการสร้าง มันจัดเก็บสถานะ attention key/value สำหรับโทเค็นก่อนหน้า เพื่อให้โมเดลไม่ต้องคำนวณประวัติทั้งหมดใหม่ตั้งแต่ต้นทุกครั้งที่สร้างโทเค็น

หากไม่มี KV cache การสร้างจะไม่มีประสิทธิภาพอย่างโหดร้าย หากมี KV cache การสร้างก็ใช้งานได้ แต่ cache ใช้หน่วยความจำตามสัดส่วนของ:

tokens x layers x kv_heads x head_dim x precision x 2

x 2 คือสำหรับ keys และ values

กฎหัวแม่มือที่มีประโยชน์สำหรับโมเดล 7B MHA แบบ Llama รุ่นเก่าคือประมาณ 0.5 MiB ต่อโทเค็นใน KV cache แบบ FP16 นั่นหมายถึง 4K โทเค็นอาจใช้ประมาณ 2 GiB สำหรับ KV cache เท่านั้น ที่ 32K โทเค็น คุณอาจมองเห็น KV cache เพียงอย่างเดียว 16 GiB

โมเดล GQA/MQA รุ่นใหม่ลดสิ่งนี้ลงอย่างมาก รันไทม์บางตัวรองรับ KV cache แบบ FP8 หรือ INT8 นั่นมักเป็นพื้นการบีบอัดที่ใช้งานได้จริงที่ผมแนะนำสำหรับผู้ใช้ในเครื่องในปี 2026

อย่าถือว่า KV cache ต่ำกว่า 8 บิตเป็นค่าเริ่มต้น ระบบวิจัยเช่น KIVI, KVQuant, และเคอร์เนล cache บีบอัดรุ่นใหม่แสดงว่า KV 2 บิตถึง 4 บิตสามารถทำงานได้ด้วยอัลกอริทึมที่ระมัดระวัง การปรับเทียบ และเคอร์เนลที่กำหนดเอง นั่นไม่เหมือนกับการพลิกสวิตช์ Q4 KV อย่างไม่ระมัดระวังในรันไทม์เดสก์ท็อป ต่ำกว่า 8 บิต ให้ benchmark อย่างหนัก โดยเฉพาะสำหรับการเขียนโค้ด, การเรียกเครื่องมือ, JSON, การดึงข้อมูลบริบทยาว, และงานที่โทเค็นก่อนหน้าที่แน่นอนมีความสำคัญ

และอย่าสับสนระหว่าง KV-cache quantization กับ speculative decoding DFlash และ DDTree ซึ่งมักย่อว่า DTree โจมตีความหน่วงของการถอดรหัสโดยร่างโทเค็นในอนาคตและตรวจสอบ พวกมันสามารถปรับปรุงความเร็ว แต่ไม่ได้ลบภาระหน่วยความจำ KV-cache

นี่คือเหตุผลที่โมเดลสามารถพอดีกับพรอมต์ว่าง แต่พังเมื่อคุณโหลดเอกสารยาว น้ำหนักพอดี แต่หน่วยความจำทำงานไม่พอ

Prefill And Decode

การอนุมาน LLM มีสองระบอบประสิทธิภาพที่แตกต่างกัน: prefill และ decode

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

เวลาที่คุณรอให้โทเค็นแรกปรากฏมักเป็นเวลา prefill

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

พรอมต์ยาวลงโทษ prefill คำตอบยาวลงโทษ decode การสนทนายาวลงโทษทั้งคู่เพราะ KV cache โตขึ้น

ในเซสชันแชท แต่ละเทิร์นเพิ่มใน cache หากคุณปล่อยให้การสนทนาถึง 16K โทเค็น คุณจ่ายค่าใช้จ่ายหน่วยความจำสำหรับทั้งหมด 16K โทเค็นในทุกโทเค็นใหม่ที่สร้าง นี่คือสาเหตุที่ UI แชทที่เก็บประวัติไม่จำกัดในที่สุดช้าลงหรือพัง

Decoding

หลังจากที่โมเดลสร้าง logits มันยังไม่ได้เขียนอะไรเลย มันแค่ให้คะแนนทุกโทเค็นถัดไปที่เป็นไปได้ Decoding คือนโยบายที่เปลี่ยนคะแนนเหล่านั้นเป็นโทเค็นจริงหนึ่งตัว ต่อท้ายโทเค็นนั้นในบริบท และทำซ้ำลูป

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

ตัวเลือกเหล่านี้ไม่เปลี่ยนน้ำหนักโมเดล แต่มันเปลี่ยนน้ำเสียง, ความแน่นอน, ความคิดสร้างสรรค์, โปรไฟล์ความเสี่ยง, และแนวโน้มที่จะลูปของโมเดล

ลูกบิดสำคัญตอบสามคำถามเชิงปฏิบัติ:

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

สำหรับงานที่แม่นยำ เริ่มต้นแคบ: อุณหภูมิต่ำ, ขีดจำกัด max-token สั้น, ลำดับหยุดที่ชัดเจน, และ constrained decoding เมื่อผลลัพธ์ต้องตรงกับ JSON หรือ schema สำหรับงานสร้างสรรค์ ให้พื้นที่ตัวสุ่มมากขึ้นด้วยอุณหภูมิสูงขึ้น, top-p, และหลายตัวเลือกที่จัดอันดับทีหลัง สำหรับการเขียนโค้ด ให้รอบแรกเป็นแบบอนุรักษ์นิยม จากนั้นสุ่มทางเลือกเมื่อคุณสำรวจโดยตั้งใจเท่านั้น

Greedy decoding ไม่ได้แม่นยำกว่าเสมอไป มันมักเปราะบาง ตัวถอดรหัสแบบ greedy อาจติดลูปหรือสร้างคำตอบทั่วไปเพราะมันไม่เคยสำรวจทางเลือก สำหรับการประเมิน ใช้การตั้งค่าแบบกำหนดได้ สำหรับการคิดสร้างสรรค์ ปล่อยให้โมเดลหายใจ

What A Model Package Contains

LLM ท้องถิ่นที่ใช้งานได้มีมากกว่าแค่ไฟล์น้ำหนักไฟล์เดียว ชุดโมเดลมักประกอบด้วย:

• Architecture/config: จำนวนชั้น, ขนาดซ่อน, ประเภท attention, การตั้งค่า RoPE, ขนาดคำศัพท์, โทเค็นพิเศษ, และความยาวบริบท
• Weights: พารามิเตอร์ที่เรียนรู้ มักเก็บเป็น safetensors, GGUF, GPTQ, AWQ, EXL2 หรือรูปแบบเฉพาะรันไทม์อื่น
• Tokenizer: กฎที่เปลี่ยนข้อความเป็น token ID และ token ID กลับเป็นข้อความ
• Chat template: มาร์กอัปที่แน่นอนสำหรับข้อความ system, user, assistant, tool, และ reasoning
• Generation config: ค่าเริ่มต้นสำหรับ temperature, top-p, stop tokens, repetition penalties, และ max tokens
• License และ model card: คำแนะนำทางกฎหมายและการดำเนินงานเกี่ยวกับวิธีการใช้โมเดล

น้ำหนักเป็นไฟล์ที่ใหญ่ที่สุด แต่ไม่ใช่ทั้งโมเดล หาก tokenizer, config หรือ chat template ผิด น้ำหนักเดียวกันอาจรู้สึกพัง

ส่วนชุดโมเดลบอกคุณว่าสิ่งใดต้องเดินทางด้วยกัน ส่วนถัดไปอธิบายว่าเหตุใด chat template จึงเป็นส่วนที่คนมักทำพัง

Chat Templates

โมเดลแชทถูกฝึกด้วยรูปแบบการสนทนาที่เฉพาะเจาะจง ตัวอย่างเช่น มันอาจคาดหวังสิ่งเช่น:

<|system|> คุณคือผู้ช่วยที่มีประโยชน์ <|user|> อธิบาย KV cache <|assistant|>

อีกโมเดลอาจคาดหวัง:

[BOS] [INST] อธิบาย KV cache [/INST]

อีกโมเดลอาจใช้เครื่องหมายแบบ ChatML อีกโมเดลอาจต้องใช้โทเค็น reasoning พิเศษ อีกโมเดลอาจต้องใช้ wrapper XML หรือ JSON สำหรับการเรียกเครื่องมือ

การใช้รูปแบบผิดอาจทำให้เกิดเรื่องไร้สาระ สับสนบทบาท ละเว้น system prompt พรอมต์ซ้ำ การปฏิเสธแปลก ๆ การเรียกเครื่องมือเสีย ผล benchmark แย่ และข้อสรุปว่าโมเดลโง่เมื่อเทมเพลตคือบั๊กจริง

แนวปฏิบัติที่ดีที่สุด:

• ใช้ apply_chat_template ของ tokenizer เมื่อใช้ Transformers
• ใช้เทมเพลตเฉพาะโมเดลใน frontend ที่ใช้ Harbor, llama.cpp, LM Studio, vLLM หรือ SGLang
• ตรวจสอบว่าโมเดลเป็น base, instruct, chat, reasoning หรือ tool-tuned
• ตรวจสอบให้แน่ใจว่า BOS/EOS tokens ถูกต้อง
• ทำให้ system prompts สั้นเว้นแต่ต้องการยาว
• สำหรับการใช้เครื่องมือ ตาม schema ที่แน่นอนที่โมเดล/รันไทม์คาดหวัง

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

ปฏิบัติต่อเทมเพลตเหมือนสัญญา API หากคุณทำให้ผิด คุณไม่ได้ทดสอบโมเดลที่คุณคิดว่ากำลังทดสอบจริงๆ

Model Types

LLM ไม่ทั้งหมดถูกปรับแต่งสำหรับพฤติกรรมเดียวกัน

สำหรับผู้ใช้ส่วนใหญ่ จุดเริ่มต้นเริ่มต้นควรเป็นโมเดล instruct/chat-tuned ล่าสุดในขนาดที่พอดีในหน่วยความจำอย่างสบาย

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

หากคุณถาม base model ว่าอะไรคือเมืองหลวงของฝรั่งเศส? มันอาจต่อด้วย และประชากรของปารีสคือเท่าใด? แทนที่จะตอบว่าปารีส

การแบ่งเชิงปฏิบัตินั้นง่าย:

• Base model: เหมาะสำหรับการวิจัย pretraining, fine-tuning และไปป์ไลน์แบบกำหนดเอง
• Instruct model: เหมาะสำหรับการปฏิบัติตามคำสั่งโดยตรง
• Chat model: เหมาะสำหรับการสนทนาหลายเทิร์นพร้อมการจัดรูปแบบบทบาท
• Reasoning model: เหมาะเมื่องานได้ประโยชน์จากโทเค็นการคิดเพิ่มเติมและการตรวจสอบ
• Tool-tuned model: เหมาะเมื่อการเรียกที่มีโครงสร้าง, JSON หรือการใช้ฟังก์ชันมีความสำคัญ

What Local Really Means

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

อิสระนั้นมาพร้อมกับงาน ตอนนี้คุณคือทีมปฏิบัติการ คุณจัดการดาวน์โหลด อัปเดต ความเข้ากันได้ ขีดจำกัดหน่วยความจำ และความปลอดภัย เมื่อมีอะไรพัง ไม่มีตั๋วสนับสนุนให้ยื่น มีเพียงคุณ, logs และเอกสาร

Local สามารถหมายถึง:

• โมเดล 2B พารามิเตอร์ที่รันบนโทรศัพท์
• โมเดล 7B ถึง 14B ที่รันบน GPU ผู้บริโภค
• โมเดล 30B ถึง 70B ที่รันบนเวิร์กสเตชันระดับสูง
• โมเดล MoE แบบ sparse ที่รันบน GPU ดาต้าเซ็นเตอร์หนึ่งตัวหรือมากกว่า
• การปรับใช้ส่วนตัวโดยใช้ vLLM, SGLang, TensorRT-LLM, llama.cpp, Harbor, LM Studio หรือสแต็ก PyTorch แบบกำหนดเอง

ประเด็นสำคัญ: local ไม่ได้หมายถึง offline, ส่วนตัว, ปลอดภัย, ถูก หรือ opensource โดยอัตโนมัติ มันหมายถึงคุณกำลังรันโมเดลด้วยตัวเองเท่านั้น แอปท้องถิ่นยังสามารถติดต่อกลับบ้านได้ โมเดลสามารถเป็น open-weight แต่ไม่ใช่ opensource โมเดลสามารถเป็น local แต่ไม่ปลอดภัยที่จะโหลด โมเดลที่ถูก quantization สามารถพอดีในหน่วยความจำแต่ตอบได้ไม่ดี

การแลกเปลี่ยนนั้นคุ้มค่าเมื่อคุณต้องการความเป็นส่วนตัว, ความหน่วงต่ำ, พฤติกรรมที่กำหนดเอง, การทำงานแบบออฟไลน์ หรือการควบคุมต้นทุนในขนาดใหญ่ มันไม่คุ้มเมื่อคุณต้องการคุณภาพโมเดลที่ดีที่สุดและไม่มีฮาร์ดแวร์ที่เทียบกันได้ ในกรณีนั้น API ที่โฮสต์คือเครื่องมือที่เหมาะสม

LLM ท้องถิ่นใช้งานได้จริงเมื่อคุณเข้าใจสมการเดียว:

ความสำเร็จของ LLM ท้องถิ่น = โมเดลที่เหมาะสม + รูปแบบพรอมต์ที่ถูกต้อง + รันไทม์ที่ดี + การประเมินที่สมจริง

ทุกอย่างอื่นคือรายละเอียด รายละเอียดสำคัญ

Quantization

Quantization จัดเก็บน้ำหนักในความแม่นยำต่ำกว่าเพื่อลดหน่วยความจำและบางครั้งปรับปรุงปริมาณงาน

กฎหัวแม่มือปี 2026 สำหรับผู้ใช้ในเครื่อง:

• FP16/BF16: คุณภาพดีที่สุดเมื่อหน่วยความจำเหลือเฟือ ใช้เป็นเกณฑ์พื้นฐานสำหรับการประเมิน
• Q8 / INT8: ใกล้ไม่สูญเสียสำหรับหลายงาน แต่ยังใหญ่ ดีเมื่อคุณมี VRAM และต้องการสูญเสียคุณภาพน้อยที่สุด
• Q6 / Q5: คุณภาพดีเยี่ยมพร้อมประหยัดปานกลาง นี่คือจุดกึ่งกลางที่แข็งแกร่ง
• Q4: จุดหวานเริ่มต้นสำหรับผู้บริโภคสำหรับเวิร์กโฟลว์แชทและเอกสารจำนวนมาก
• Q3 / Q2: เฉพาะเมื่อคุณต้องใส่โมเดลที่ใหญ่กว่า คณิตศาสตร์ โค้ด ผลลัพธ์ที่มีโครงสร้าง และการใช้เครื่องมือลดคุณภาพก่อน

Weight quantization ไม่เหมือนกับ KV-cache quantization Weight quantization ทำให้โมเดลเล็กลง KV-cache quantization ทำให้หน่วยความจำบริบทสดเล็กลง

สำหรับ KV cache ให้ถือว่า FP16/BF16 เป็นเกณฑ์พื้นฐานที่สะอาด และ FP8/INT8 เป็นพื้นการบีบอัดในเครื่องที่ใช้งานได้จริง ต่ำกว่า 8 บิตเป็นงานวิจัยหนักและไวต่อปริมาณงาน ใช้เฉพาะหลังจากวัดคุณภาพบนพรอมต์จริงของคุณ

ความล้มเหลวของ quantization ปรากฏก่อนในคณิตศาสตร์ การใช้เหตุผลหลายขั้นตอน ความถูกต้องของโค้ด ความน่าเชื่อถือในการใช้เครื่องมือ การปฏิบัติตาม JSON/schema การปฏิบัติตามคำแนะนำที่ละเอียดอ่อน และการดึงข้อมูลบริบทยาว

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

File Formats And Load Safety

safetensors คือรูปแบบการจัดลำดับเทนเซอร์ที่ปลอดภัย ออกแบบมาเพื่อเก็บเทนเซอร์โดยไม่มีพฤติกรรม pickle ของ Python ใช้ safetensors เมื่อเป็นไปได้ โดยเฉพาะสำหรับโมเดล PyTorch/Transformers

หลีกเลี่ยงไฟล์ .bin สุ่มจากแหล่งที่ไม่น่าเชื่อถือ การโหลดแบบ pickle ของ PyTorch สามารถรันโค้ดตามอำเภอใจระหว่างการจัดลำดับกลับ กฎความปลอดภัย AI ท้องถิ่นข้อที่หนึ่ง: อย่าให้ไฟล์โมเดลของคนแปลกหน้ากลายเป็นการรันโค้ดของคนแปลกหน้า

GGUF คือรูปแบบโมเดลไบนารีของระบบนิเวศ llama.cpp ใช้ GGUF เมื่อคุณต้องการ llama.cpp, การอนุมาน CPU, การอนุมาน Apple Silicon, เซิร์ฟเวอร์ในเครื่องอย่างง่าย, โมเดล quantization แบบพกพา หรือเครื่องมือเดสก์ท็อปเช่น LM Studio

ONNX มีประโยชน์สำหรับการปรับใช้ที่ได้มาตรฐานและการเร่งความเร็วเฉพาะฮาร์ดแวร์ โดยเฉพาะนอกสแต็ก PyTorcทั่วไป หากคุณกำลังปรับใช้กับ Intel NPU, อุปกรณ์ ARM หรือตัวเร่งความเร็วแบบกำหนดเอง ONNX มักเป็นเส้นทางที่มีอุปสรรคน้อยที่สุด

TensorRT-LLM คือเส้นทางการอนุมานประสิทธิภาพสูงของ NVIDIA สำหรับการปรับใช้ GPU ในระดับโปรดักชั่น มันทรงพลัง แต่ซับซ้อนกว่า llama.cpp หรือ Harbor โดยทั่วไปคุณแปลง checkpoint เป็น TensorRT engines ซึ่งใช้เวลาและหน่วยความจำ GPU แต่ให้ปริมาณงานที่ยอดเยี่ยมเมื่อสร้างเสร็จ

รูปแบบ EXL2 / GPTQ / AWQ พบได้ทั่วไปในชุมชนการอนุมานในเครื่องที่เน้น GPU โดยเฉพาะสำหรับการยัดโมเดลใหญ่ลงใน GPU เดียว

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

Runtimes And Serving Modes

รันไทม์คือซอฟต์แวร์ที่โหลดโมเดลและดำเนินการอนุมาน ในปี 2026 ระบบนิเวศรันไทม์ LLM ท้องถิ่นมีความสมบูรณ์ มีประโยชน์ และแตกแยก

สำหรับบุคคลเดียวที่ทดลองในเครื่อง เริ่มต้นด้วย Harbor, LM Studio หรือ llama.cpp Harbor เหมาะที่สุดเมื่อคุณต้องการสแต็กท้องถิ่นที่สมบูรณ์พร้อม frontends, backends และบริการสนับสนุนที่เชื่อมต่อกัน LM Studio เป็นเส้นทางเดสก์ท็อปแรกที่ง่ายที่สุด llama.cpp คือม้าทำงานระดับต่ำที่พกพาได้

สำหรับทีมหรือบริการส่วนตัว ดูที่ vLLM หรือ SGLang สำหรับประสิทธิภาพโปรดักชั่นสูงสุดของ NVIDIA ตรวจสอบ TensorRT-LLM สำหรับการปรับใช้เบราว์เซอร์หรือมือถือ ดูที่ MLC หรือ WebLLM

การเลือกรันไทม์มักล็อคคุณเข้าสู่ระบบนิเวศรูปแบบ llama.cpp หมายถึง GGUF vLLM และ SGLang มักหมายถึง safetensors หรือ Hugging Face checkpoints TensorRT-LLM หมายถึง ONNX หรือ engines ที่ปรับแต่งแล้ว เลือกรันไทม์ก่อน จากนั้นหาโมเดลในรูปแบบที่ถูกต้อง

มีสามโหมดการให้บริการที่ใช้งานได้จริง

Single-user local หมายถึงแอปเดสก์ท็อป, สแต็ก CLI หรือเซิร์ฟเวอร์บรรทัดคำสั่งสำหรับคนเดียว Harbor, LM Studio, llama.cpp server, ExLlama/TabbyAPI และสคริปต์ Transformers ขนาดเล็กทั้งหมดอยู่ในนี้ เป้าหมายคือการวนซ้ำอย่างรวดเร็ว: เปรียบเทียบพฤติกรรม ความเร็ว การใช้หน่วยความจำ และรูปแบบพรอมต์โดยไม่ต้องสร้างแพลตฟอร์มปฏิบัติการ

Team or private API หมายถึงปลายทางที่เข้ากันได้กับ OpenAI บนเวิร์กสเตชันหรือเซิร์ฟเวอร์ vLLM, SGLang, TensorRT-LLM และ llama.cpp server ทั้งหมดปรากฏที่นี่ขึ้นอยู่กับขนาดโมเดลและความต้องการปริมาณงาน เมื่อหลายคนหรือหลายงานแชร์โมเดล คุณต้องมีการตรวจสอบ, การจัดการพรอมต์/เวอร์ชัน, การกำหนดเส้นทาง และการวัดความหน่วงที่สมจริง

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

การให้บริการในระดับโปรดักชันเป็นอีกเรื่องที่แตกต่างออกไป ตอนนี้การสนทนาครอบคลุมถึง continuous batching, prefix caching, speculative decoding, paged attention, tensor parallelism, pipeline parallelism, quantized serving, structured outputs, load balancing, GPU utilization, latency percentiles, prompt caching, admission control, logging, failover, privacy และ cost controls

ในระดับโปรดักชัน คำถามง่ายๆ คือ ฉันสามารถโหลดโมเดลได้หรือไม่? แต่คำถามที่ยากคือ ฉันสามารถให้บริการโมเดลได้อย่างน่าเชื่อถือภายใต้ traffic จริงหรือไม่?

คำนวณ VRAM สำหรับโมเดลที่รันบนเครื่องตัวเอง

มีองค์ประกอบหลักที่ใช้หน่วยความจำสามส่วน:

1. น้ำหนักของโมเดล (Model weights)
2. KV cache
3. ค่าใช้จ่ายเบ็ดเตล็ดของรันไทม์ (Runtime overhead)

สูตรคร่าวๆ สำหรับหน่วยความจำของน้ำหนักโมเดลคือ:

weight_memory ~= parameters x bytes_per_parameter

ค่าประมาณที่เป็นประโยชน์:

• FP16/BF16: ประมาณ 2 ไบต์ต่อพารามิเตอร์
• INT8/Q8: ประมาณ 1 ไบต์ต่อพารามิเตอร์
• Q4: ประมาณ 0.5 ไบต์ต่อพารามิเตอร์ บวกค่าใช้จ่ายของรูปแบบข้อมูล

จากนั้นให้บวกเพิ่ม:

• ค่าใช้จ่ายเบ็ดเตล็ดของรันไทม์: Framework buffers, CUDA overhead, memory fragmentation, และ temporary tensors
• KV cache: เพิ่มขึ้นตามทุก token ใน context ที่กำลังทำงานอยู่
• หน่วยความจำสำหรับการทำ Batch/Concurrency: แต่ละคำขอที่ทำพร้อมกันต้องมี cache ของตัวเอง
• หน่วยความจำของ Vision encoder: รูปภาพก็จะถูกแปลงเป็น tokens ด้วย
• หน่วยความจำสำหรับ Speculative decoding: Draft models, draft heads, หรือโครงสร้างสำหรับการตรวจสอบเพิ่มเติมไม่ได้ฟรี
• หน่วยความจำสำหรับ Adapter: LoRA adapters อาจเล็ก แต่ก็กินหน่วยความจำจริงๆ

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

ค่าประมาณที่สมจริงจะมีหน้าตาประมาณนี้:

total_memory = quantized_weights + KV_cache_for_context + runtime_overhead + batch_or_concurrency_overhead + safety_margin

นี่คือกับดัก: โมเดล 13B ในรูปแบบ Q4 อาจพอดีกับ context ที่ 8K อย่างสบายๆ แต่จะล้มเหลวที่ 32K เพราะ KV cache เพิ่มขึ้นเป็นสี่เท่า น้ำหนักของโมเดลไม่ได้เปลี่ยน แต่ context เปลี่ยนไป

ควรเผื่อพื้นที่ว่างไว้ 10 ถึง 20 เปอร์เซ็นต์ การใช้ VRAM ถึง 99 เปอร์เซ็นต์นั้นเท่ากับกำลังเสี่ยงต่อข้อผิดพลาดหน่วยความจำไม่พอและการล้มเหลวจากการแตกกระจายของหน่วยความจำ

ระดับฮาร์ดแวร์ในทางปฏิบัติ

นี่คือกฎเชิงปฏิบัติการสำหรับปี 2026 โดยสมมติว่าใช้ quantized inference และความยาว context ที่เหมาะสม ผลลัพธ์ที่แน่นอนขึ้นอยู่กับรันไทม์, quantization, สถาปัตยกรรมโมเดล, ประเภทของ attention, ความยาว context, และค่าใช้จ่ายของ OS/driver

สำหรับผู้ใช้ที่จริงจังส่วนใหญ่ที่รันโมเดลบนเครื่องตัวเองในปี 2026, 16 GB คือระดับ GPU ขั้นต่ำที่ใช้งานได้สะดวก, 24 GB คือระดับที่ดีที่สุดสำหรับผู้ที่ชื่นชอบ และ 48 GB+ คือจุดเริ่มต้นที่โลกของโมเดลท้องถิ่นที่ทรงพลังเปิดกว้างขึ้น

ประสิทธิภาพขึ้นอยู่กับ memory bandwidth, GPU FLOPs, ความจุ VRAM, ขนาด KV-cache, การใช้งาน attention, quantization, batch size, ความยาว prompt, ความยาวของข้อความที่สร้าง, และความสมบูรณ์ของรันไทม์

ขั้นตอน Decode มักถูกจำกัดด้วย memory bandwidth: GPU จะโหลดน้ำหนักโมเดลซ้ำๆ ในขณะที่คำนวณต่อไบต์ค่อนข้างน้อย ขั้นตอน Prefill ถูกจำกัดด้วยการคำนวณมากกว่าเพราะสามารถประมวลผล prompt แบบขนานได้ นั่นคือสาเหตุที่การ์ดสองใบที่มีความจุ VRAM เท่ากันสามารถให้ความเร็ว token ต่างกันมากได้ ถ้าการ์ดหนึ่งมี memory bandwidth สูงกว่าอย่างเห็นได้ชัด

การตั้งค่าที่เจ็บปวดที่สุดในการรันโมเดลบนเครื่องตัวเองคือสถานการณ์ที่โมเดลแทบจะพอดี แต่ต้อง spill layers ไปยัง CPU ในทางเทคนิคมันอาจจะรันได้ แต่ความเร็ว token อาจลดลงอย่างรุนแรง การ offload ไปยัง CPU เป็นที่ยอมรับได้สำหรับการทดลอง แต่มันไม่ใช่กลยุทธ์ด้านประสิทธิภาพ

เลือกโมเดลที่เหมาะสม

คำถามเชิงปฏิบัติการไม่ใช่ "โมเดลไหนดีที่สุด?" แต่คือ "โมเดลที่เล็กที่สุดที่ชนะงานจริงของคุณบนฮาร์ดแวร์ของคุณคือตัวไหน?"

เริ่มต้นด้วยโมเดล instruct/chat รุ่นล่าสุดที่พอดีกับความยาว context ที่คุณต้องการจริงๆ ถ้าคุณมี VRAM หรือ unified memory 8 GB ถึง 12 GB ให้เริ่มจากโมเดลเล็กๆ ถ้าคุณมี 16 GB ถึง 24 GB ให้ทดสอบโมเดลคลาส 7B ถึง 14B ก่อน ถ้าคุณมี 48 GB หรือมากกว่า โมเดล dense ขนาดใหญ่และโมเดล MoE ก็เป็นไปได้ในทางปฏิบัติ

ใช้หลักเกณฑ์หน่วยความจำนี้ก่อนที่จะปลื้มกับ checkpoint ใดๆ:

น้ำหนักโมเดล + KV cache + ค่าใช้จ่ายรันไทม์ <= 80 ถึง 90 เปอร์เซ็นต์ของหน่วยความจำที่มีอยู่

จากนั้นให้รัน prompt เดียวกัน 20 ถึง 50 ข้อความกับตัวเลือกต่างๆ รวมถึงงานจริงของคุณ: การแก้ไขโค้ด, การถามตอบเอกสาร, การสร้างผลลัพธ์ JSON, การสรุปความ, การเรียกใช้เครื่องมือ, context ยาว, หรืออะไรก็ตามที่คุณต้องการจริงๆ วัดคุณภาพคำตอบ, latency, การใช้หน่วยความจำ, ความน่าเชื่อถือของเทมเพลต, และรูปแบบความล้มเหลว

โดยทั่วไปแล้วการเลือกโมเดลในทางปฏิบัติจะขึ้นอยู่กับการตรวจสอบห้าประการ:

• ความเหมาะสมกับงาน: แชท, เขียนโค้ด, เอกสาร, agents, multimodal, edge, หรือ fine-tuning
• ความเหมาะสมของหน่วยความจำ: น้ำหนักโมเดล, KV cache, ค่าใช้จ่ายรันไทม์, และระยะปลอดภัย
• ความเหมาะสมของอินเทอร์เฟส: Tokenizer, chat template, stop tokens, tool schema, และโหมด reasoning
• ความเหมาะสมของรันไทม์: รันไทม์ของคุณรองรับสถาปัตยกรรมนี้, quantization, ความยาว context, และโหมดการให้บริการได้ดีหรือไม่?
• ความเหมาะสมของใบอนุญาต: คุณสามารถใช้งานได้จริงในที่ที่คุณวางแผนจะใช้หรือไม่?

กระดานผู้นำ (Leaderboards) มีประโยชน์สำหรับการค้นหา แต่ไม่สามารถใช้แทนการประเมินผลของคุณเองได้ งานของคุณคือ benchmark ที่สำคัญ

สำหรับผู้ช่วยท้องถิ่นแบบง่ายๆ ให้เลือกโมเดล instruct รุ่นล่าสุดขนาด 7B ถึง 14B, quantization แบบ Q4/Q5, chat template ที่ถูกต้อง, context 8K ถึง 32K, และใช้ Harbor, LM Studio หรือ llama.cpp ให้ความสำคัญกับความตอบสนอง (responsiveness) มากกว่าขนาดที่ใหญ่โต

สำหรับผู้ช่วยเขียนโค้ดท้องถิ่น ให้เลือกโมเดลที่เขียนโค้ดได้ขนาด 14B ถึง 32B ถ้าคุณมี VRAM เพียงพอ ใช้ temperature ต่ำ, repository retrieval, การรันทดสอบ, และ workflow แบบ patch-based โมเดลเขียนโค้ดที่ไม่มีเครื่องมือคือผลิตภัณฑ์ที่ไม่สมบูรณ์

สำหรับผู้ช่วยเอกสารส่วนตัว ให้เลือกโมเดล instruct ที่แข็งแกร่ง, โมเดล embedding ในเครื่อง, reranker, RAG pipeline, การบังคับใช้การอ้างอิง, และ context ระดับปานกลางถึงยาว อย่าเพียงแค่วางเอกสาร PDF 200 หน้าแล้วหวังว่ามันจะทำงานได้

สำหรับการตั้งค่าแบบ reasoning ให้เลือกโมเดลที่ถูกเทรนมาสำหรับ reasoning, จอง tokens เพิ่ม, ใช้ temperature ต่ำถึงปานกลาง, เพิ่มการตรวจสอบ และใช้เครื่องมือสำหรับคณิตศาสตร์ โค้ด หรือการค้นหา โมเดล reasoning ใช้ tokens มากกว่า ควรจัดสรรงบประมาณให้เหมาะสม

สำหรับการตั้งค่าที่มีทรัพยากรจำกัด ให้เลือกโมเดลขนาด 1B ถึง 4B, Q4/Q5, prompt สั้น, งานที่มีโครงสร้าง, การค้นคืนหรือเครื่องมือ, และ output schema ที่จำกัด โมเดลเล็กจะกลายเป็นประโยชน์เมื่องานถูกจำกัดขอบเขต

สิ่งที่ควบคุมความเร็ว

Tokens ต่อวินาทีไม่ได้ถูกควบคุมด้วยปัจจัยเดียว มันเป็นผลลัพธ์ของขนาดโมเดล, memory bandwidth, การคำนวณ, attention kernels, ความยาว context, quantization, การทำ batch, และคุณภาพของรันไทม์

ตัวควบคุมหลักๆ ได้แก่:

• Memory bandwidth: ขั้นตอน Decode มักจะโหลดน้ำหนักโมเดลซ้ำๆ ดังนั้น bandwidth จึงเป็นตัวกำหนดความเร็ว token สำหรับผู้ใช้คนเดียว
• GPU FLOPs: Prefill และ batch ขนาดใหญ่ใช้การคำนวณแบบขนานมากขึ้น ดังนั้น FLOPs จึงมีความสำคัญมากกว่าในกรณีนี้
• ความจุ VRAM: ถ้าโมเดลหรือ KV cache ถูก spill ไปยัง CPU ประสิทธิภาพอาจลดลงอย่างรุนแรง
• การใช้งาน Attention: FlashAttention, SDPA, paged attention, และ kernels เฉพาะของรันไทม์สามารถเปลี่ยนทั้งความเร็วและพฤติกรรมของหน่วยความจำ
• Quantization: น้ำหนักที่เล็กลงช่วยลดการเคลื่อนย้ายหน่วยความจำ แต่การ quantization ที่รุนแรงอาจทำให้คุณภาพลดลงและบางครั้งก็เพิ่มค่าใช้จ่ายในการ dequantization
• Batch size และ concurrency: การทำ batch ช่วยเพิ่ม throughput แต่แต่ละ sequence ที่ทำงานอยู่ต้องใช้ KV cache
• ความยาว Prompt: prompt ยาวจะเพิ่มเวลา prefill
• ความยาวข้อความที่สร้าง: คำตอบยาวจะเผยให้เห็นความเร็ว decode
• Speculative decoding: วิธีการแบบ EAGLE, MTP, DFlash และ DDTree สามารถตรวจสอบ token ที่ร่างไว้ได้มากกว่าหนึ่ง token ต่อการส่งผ่านของ target model เมื่อรองรับ

การตั้งค่าที่เจ็บปวดคือการตั้งค่าแบบ "เกือบจะพอดี" โมเดลที่ spill layers หรือ cache ไปยัง CPU อาจทำงานได้ในทางเทคนิค แต่ความเร็ว token อาจลดลงจากที่ใช้ได้เป็นที่ทรมาน

ควร benchmark รันไทม์, quantization, ความยาว context, รูปร่างของ prompt, และ workload ที่แน่นอนที่คุณจะใช้จริง ตัวเลขจากกระดานผู้นำที่ใช้ BF16 ไม่ได้บอกคุณว่า stack แบบ Q4 บนเครื่องของคุณจะให้ความรู้สึกอย่างไร

Context แบบยาว (Long Context)

Context แบบยาวฟังดูวิเศษ: 128K, 256K, หรือแม้แต่ 1M tokens ใน prompt เดียว มันมีประโยชน์ แต่ก็มีต้นทุนที่แท้จริง

context ที่มากขึ้นหมายถึงหน่วยความจำ KV cache ที่มากขึ้น, การประมวลผล prompt ที่ช้าลง, งาน attention ที่มากขึ้น, การประเมินผลที่ยากขึ้น, และวิธีที่ข้อความที่ไม่เกี่ยวข้องจะเบี่ยงเบนความสนใจของโมเดลได้มากขึ้น คุณภาพอาจลดลงตามระยะทาง โมเดลอาจจัดการกับส่วนท้ายของเอกสารยาวๆ ได้ดีในขณะที่พลาดรายละเอียดสำคัญที่ซ่อนอยู่ใกล้ตอนต้น

ใช้ context แบบยาวสำหรับการวิเคราะห์เอกสารทั้งฉบับ, โค้ดเบสบางส่วน, การตรวจสอบทางกฎหมายหรือเทคนิค, การสรุปบทสนทนา, การใช้เหตุผลจากหลายไฟล์, และ RAG fallback เมื่อการค้นคืนพลาด context

อย่าปฏิบัติต่อ context แบบยาวว่าเป็นสิ่งทดแทนการค้นคืน (retrieval) มันคือตัวเสริม ใช้ RAG สำหรับคลังข้อมูลขนาดใหญ่ และใช้ context แบบยาวสำหรับหลักฐานที่เลือกแล้วในขั้นสุดท้าย

นิสัยที่เป็นประโยชน์ในทางปฏิบัติ:

• วางคำแนะนำที่สำคัญไว้ใกล้จุดเริ่มต้นและจุดสิ้นสุด
• ใช้หัวข้อย่อยและตัวคั่น
• ขอให้ระบุแหล่งที่มาที่เชื่อมโยงกับชิ้นส่วนต้นฉบับ
• บีบอัดประวัติที่ไม่เกี่ยวข้อง
• ใช้ summary memory แทนประวัติแชทที่ไม่สิ้นสุด

คิดว่า context แบบยาวเป็น attention ที่มีราคาแพง ไม่ใช่สมุดบันทึกฟรี

Multimodality (ประมวลผลหลายรูปแบบ)

โมเดลท้องถิ่นแบบ multimodal สามารถรับรูปภาพ และบางครั้งก็เสียงหรือวิดีโอ นอกเหนือจากข้อความ ระบบนิเวศของโมเดลโอเพ่นเวทสมัยใหม่รวมโมเดลเหล่านี้มากขึ้นเรื่อยๆ

ต้นทุนที่ซ่อนอยู่คือข้อมูลที่ไม่ใช่ข้อความจะกลายเป็น tokens เช่นกัน Vision encoders เพิ่มหน่วยความจำ Image patches กิน context เสียงและวิดีโอสามารถทำให้งบประมาณ input พุ่งสูงขึ้น นอกจากนี้ multimodal templates ยังทำผิดได้ง่ายกว่า templates ที่เป็นข้อความล้วน

รูปภาพความละเอียดสูงเพียงรูปเดียวสามารถกิน tokens หลายพันตัวใน context window ถ้าคุณรันโมเดล multimodal บนเครื่องตัวเอง ให้นับ image tokens แบบเดียวกับที่คุณนับ text tokens พวกมันมาจากงบประมาณเดียวกัน

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

ภาพรวมของโมเดลท้องถิ่นในปี 2026

วงการโมเดลเปลี่ยนแปลงเร็ว ณ วันที่ 21 พฤษภาคม 2026 ผู้ใช้ LLM ท้องถิ่นควรคิดในแง่ของตระกูลและระบบนิเวศ ไม่ใช่ "โมเดลที่ดีที่สุดตัวเดียว"

Qwen 3.5 / Qwen 3.6 เป็นตระกูลโอเพ่นเวทที่สำคัญเพราะครอบคลุมทุกชั้น: โมเดลเล็กสำหรับแล็ปท็อป, โมเดล dense ขนาดกลางสำหรับเวิร์คสเตชั่น, โมเดล MoE สำหรับการให้บริการแบบ multi-GPU, รูปแบบ FP8, context แบบยาว, การทำงานหลายภาษา, การเขียนโค้ด, เครื่องมือ, และ workflow ตัวแทน ข้อสรุปเชิงปฏิบัติการนั้นง่าย: Qwen เป็นค่าเริ่มต้นที่แข็งแกร่งเมื่อคุณต้องการระบบนิเวศเดียวที่ครอบคลุมตั้งแต่การทดลองบนแล็ปท็อปไปจนถึงการให้บริการในเครื่องที่จริงจัง

Gemma 4 มีความสำคัญเพราะ Google DeepMind กำลังผลักดันตระกูลนี้ไปสู่การปรับใช้ในเครื่องที่มีประโยชน์: โมเดล edge ที่มีประสิทธิภาพ, ตัวเลือก dense และ MoE ที่ใหญ่ขึ้น, ความสามารถ multimodal, context แบบยาวบนโมเดลที่ใหญ่ขึ้น, การรองรับภาษาที่กว้างขึ้น, พฤติกรรมการเขียนโค้ด/ตัวแทนที่แข็งแกร่งขึ้น, และสัญญาอนุญาต Apache 2.0 การผสมผสานนี้ทำให้คุ้มค่าที่จะทดสอบเมื่อการใช้งานเชิงพาณิชย์และการปรับใช้บนอุปกรณ์เป็นสิ่งสำคัญ

Kimi / Moonshot AI, GLM / Z.ai, DeepSeek, MiniMax และ Mistral ก็เป็นตระกูลหลักที่ต้องจับตามอง Kimi มีความเกี่ยวข้องสำหรับการเขียนโค้ดระยะยาว, การใช้เหตุผลแบบ multimodal, การใช้เครื่องมือ, และ workflow ตัวแทน GLM มีความสำคัญสำหรับตัวแทนเขียนโค้ด, งานระยะยาว, ระบบ MoE, และการเปิดตัวโมเดลที่เน้นการปรับใช้ DeepSeek ยังคงมีอิทธิพลเนื่องจากระบบ MoE ขนาดใหญ่, Multi-head Latent Attention, DeepSeekMoE, เส้นทางการให้บริการ FP8, sparse attention, และการโฮสต์เองที่มี throughput สูง MiniMax น่าจับตามองสำหรับ workload ตัวแทนในทางปฏิบัติและโมเดล MoE ที่มีประสิทธิภาพในการอนุมาน Mistral ยังคงมีความสำคัญเพราะสายผลิตภัณฑ์ของมันครอบคลุมกรณีการใช้งานทั่วไป, การเขียนโค้ด, การใช้เหตุผล, multimodal, และเฉพาะทาง พร้อมการสนับสนุนการปรับใช้ที่แข็งแกร่ง

Nemotron 3 คือตระกูลโมเดลโอเพ่นของ NVIDIA สำหรับระบบตัวแทนระดับโปรดักชันบนฮาร์ดแวร์ NVIDIA ตระกูลนี้ประกอบด้วยขนาด Nano, Super และ Ultra ใช้การออกแบบ MoE แบบ hybrid Mamba-Transformer และเชื่อมโยงอย่างใกล้ชิดกับ TensorRT-LLM, NIM, Dynamo, เส้นทาง Blackwell NVFP4/FP8, และการปรับใช้ตัวแทนระดับองค์กร ควรมองว่ามันไม่ใช่ตระกูลแชทบนเดสก์ท็อปทั่วไป แต่เป็นสัญญาณที่บ่งบอกว่า NVIDIA ต้องการให้ระบบนิเวศโอเพ่นเวทสำหรับการให้บริการพัฒนาไปในทิศทางใด

โอเพ่นเวท AI ไม่ใช่แค่เรื่องของ Llama เทียบกับสิ่งอื่นอีกต่อไป คุณกำลังเลือกระบบนิเวศ: น้ำหนัก, สัญญาอนุญาต, tokenizer, template, quantization, การรองรับรันไทม์, เส้นทางการให้บริการ, เครื่องมือชุมชน, และรูปแบบความล้มเหลว

โมเดล Qwen 27B แบบ Dense

Qwen 3.5 / 3.6 27B (Dense) เป็นหนึ่งในตัวเลือกน้ำหนักสาธารณะที่ใช้งานได้จริงที่สุดสำหรับผู้ใช้ท้องถิ่นที่ใส่ใจเรื่องการเขียนโค้ด, การทำงานหลายภาษา, การใช้เครื่องมือ, โหมดคิด/ไม่คิด, และ context แบบยาว การ์ดโมเดล Qwen 3.5 27B และ Qwen 3.6 27B อธิบายเส้นทางการให้บริการที่เข้ากันได้กับ OpenAI, ค่าเริ่มต้นของโหมดคิด, การใช้เครื่องมือ, และความยาว context สูงถึง 262,144 tokens พร้อมส่วนขยาย context ที่ยาวขึ้นผ่าน YaRN ใน framework ที่รองรับ

Qwen เป็นค่าเริ่มต้นที่แข็งแกร่งสำหรับการตั้งค่า 2x RTX 3090 เมื่อรันไทม์ถูกกำหนดค่าอย่างถูกต้องสำหรับการเขียนโค้ด ตัวแทน หรือการครอบคลุมหลายภาษา

งานวิจัยด้าน Inference

ขอบเขตในปี 2026 ไม่ได้มีแค่คุณภาพของโมเดล แต่ยังรวมถึงประสิทธิภาพของ inference ด้วย PagedAttention จัดการกับการสูญเสียหน่วยความจำ KV cache ในการให้บริการ FP8 KV cache ตอนนี้เป็นคุณสมบัติรันไทม์ที่ใช้งานได้จริงในระบบเช่น vLLM DFlash และ DDTree สำรวจ speculative decoding ด้วย block diffusion draft models และ draft trees NVFP4 ก็น่าจับตาดูบนฮาร์ดแวร์ NVIDIA เพราะมันเปลี่ยนการสนทนาเกี่ยวกับการปรับใช้ในทางปฏิบัติสำหรับ stack ที่รองรับ

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

รูปแบบความล้มเหลวและวิธีแก้ไข

ความล้มเหลวของ LLM ท้องถิ่นส่วนใหญ่ไม่ได้ลึกลับ โดยปกติแล้วมาจากความเหมาะสมของหน่วยความจำ, การจัดรูปแบบ, การรองรับของรันไทม์, การตั้งค่าการถอดรหัส, หรือคุณภาพของการค้นคืน

หน่วยความจำไม่พอ (Out of memory): น้ำหนักโมเดล, KV cache, ค่าใช้จ่ายรันไทม์, หรือ batch size ไม่พอดี ใช้โมเดลที่เล็กลง, ลด context, ลด batch/concurrency, เลือก quantization ที่ดีขึ้น, หรือเผื่อพื้นที่ว่างมากขึ้น

ข้อความไร้สาระหรือสับสนบทบาท (Gibberish or role confusion): Chat template, tokenizer, BOS/EOS token, สวิตช์โหมด reasoning, หรือ tool schema ผิด ตรวจสอบการ์ดโมเดลและ template ของรันไทม์ก่อนที่จะโทษคุณภาพโมเดล

การตอบสนอง первого токена ช้า (Slow first token): Prefill มีราคาแพง ทำให้ prompt สั้นลง, ใช้ prefix caching, ปรับปรุงการค้นคืน, ลด context, หรือใช้รันไทม์ที่เร็วขึ้น

การสตรีมช้า (Slow streaming): Decode คือคอขวด ตรวจสอบ memory bandwidth, quantization, การ spill ไปยัง CPU, attention backend, การรองรับ speculative decoding, และดูว่าโมเดลใหญ่เกินไปสำหรับฮาร์ดแวร์หรือไม่

คำตอบเกี่ยวกับเอกสารไม่ดี (Bad document answers): การค้นคืนน่าจะล้มเหลว ตรวจสอบข้อความที่แยกวิเคราะห์, ขอบเขตของ chunk, meta data, การค้นคืนแบบ top-k, การ rerank, และการยึดโยงกับการอ้างอิง

การเรียก JSON หรือเครื่องมือไม่ดี (Bad JSON or tool calls): ใช้ temperature ที่ต่ำกว่า, constrained decoding, schema ที่เข้มงวดขึ้น, ตัวอย่างที่ดีขึ้น, และโมเดลที่ถูกเทรนมาสำหรับการใช้เครื่องมือ

ลูปซ้ำๆ (Repeating loops): ลด temperature หรือ top-p, เพิ่มการลงโทษการซ้ำ, ตรวจสอบ stop tokens, และตรวจสอบให้แน่ใจว่า template ไม่ได้ทำให้โมเดลเห็นคำตอบของตัวเองเป็น prompt ใหม่

เริ่มต้นด้วยการตรวจสอบพื้นฐาน สิ่งเหล่านี้แก้ปัญหาได้มากกว่าการเปลี่ยนโมเดล

วิธีขยายขีดความสามารถของระบบ

มือใหม่: การตั้งค่าที่มีประโยชน์และง่ายที่สุด

ใช้ Harbor หรือ LM Studio, โมเดล instruct รุ่นล่าสุดขนาด 4B ถึง 9B, quantization แบบ Q4, context 8K ถึง 32K, และ UI แชทในตัว ดาวน์โหลดโมเดลสองหรือสามรุ่นในคลาสขนาดเดียวกันและเปรียบเทียบกับ prompt เดียวกัน

เป้าหมาย: เรียนรู้การเขียน prompt, เปรียบเทียบโมเดล, ทำความเข้าใจความเร็วและหน่วยความจำ, และหลีกเลี่ยงการเขียนโค้ดที่กำหนดเองในตอนแรก

ระดับกลาง: การตั้งค่าสำหรับนักพัฒนา

ใช้ llama.cpp หรือ Transformers, GGUF หรือ safetensors, เซิร์ฟเวอร์ท้องถิ่นที่เข้ากันได้กับ OpenAI, RAG pipeline ง่ายๆ, และชุดประเมินผลเล็กๆ เรียกใช้เซิร์ฟเวอร์ท้องถิ่นจากแอปพลิเคชันหรือสคริปต์จริง แทนที่จะใช้เฉพาะ UI แชท

เป้าหมาย: สร้างแอปท้องถิ่น, ทดสอบการค้นคืน, วัดคุณภาพ, และให้บริการจาก localhost

ระดับสูง: การตั้งค่าการให้บริการส่วนตัว

ใช้ vLLM หรือ SGLang, GPU หนึ่งตัวหรือมากกว่า, API ที่เข้ากันได้กับ OpenAI, การตรวจสอบ, การจัดการ prompt/เวอร์ชัน, ชุดประเมินผล, RAG พร้อม reranking, และ sandbox สำหรับเครื่องมือ

เป้าหมาย: ให้บริการผู้ใช้จริงหรือ workflow ภายใน, ปรับ throughput และ latency ให้เหมาะสม, และรักษาความปลอดภัยและการสังเกตการณ์ได้

ระดับผู้เชี่ยวชาญ: การปรับแต่งเฉพาะ

ใช้ TensorRT-LLM, kernels ที่กำหนดเอง, รันไทม์เฉพาะทาง, การทดลอง quantization, speculative decoding, parallelism แบบ multi-GPU, fine-tuning, distillation, และการประเมินผลระดับโปรดักชัน

เป้าหมาย: แลกเวลาทางวิศวกรรมกับประสิทธิภาพของ inference, ต้นทุนที่ต่ำลง, และคุณภาพที่สูงขึ้นในระดับ大规模

ความเป็นส่วนตัวไม่ได้เกิดขึ้นโดยอัตโนมัติ

LLM ท้องถิ่นช่วยปรับปรุงความเป็นส่วนตัวเพราะ prompt และ output สามารถอยู่บนฮาร์ดแวร์ของคุณได้ แต่ "ท้องถิ่น" ไม่ได้หมายถึง "ปลอดภัย" โดยอัตโนมัติ

ภัยคุกคามรวมถึงไฟล์โมเดลที่เป็นอันตราย, การโหลดน้ำหนักแบบ pickle, untrusted trust_remote_code, prompt injection ในเอกสารที่ถูกค้นคืน, การละเมิดการเรียกใช้เครื่องมือ, การรั่วไหลของความลับผ่าน log, telemetry จากแอปเดสก์ท็อป, ส่วนขยายเบราว์เซอร์หรือปลั๊กอิน, ภาพหลอนของโมเดลในสถานการณ์ที่มีความเสี่ยงสูง, การละเมิดสัญญาอนุญาต, และการปนเปื้อนข้อมูลระหว่าง fine-tuning

หลักการพื้นฐานด้านความปลอดภัยของ AI ท้องถิ่นที่ใช้ได้มีสี่ประการ:

• โหลดอย่างระมัดระวัง: เลือกใช้ safetensors หรือ GGUF จากแหล่งที่เชื่อถือได้, หลีกเลี่ยงไฟล์ .bin ที่ไม่น่าเชื่อถือ, และอย่าเปิดใช้งาน trust_remote_code โดยไม่จำเป็น
• รันด้วยขอบเขต: ใช้ผู้ใช้ที่ไม่มีสิทธิพิเศษ, คอนเทนเนอร์หรือ sandbox สำหรับตัวแทน, และปิดการเข้าถึงเครือข่ายเมื่อความเป็นส่วนตัวแบบออฟไลน์สำคัญ
• ปกป้องความลับ: เก็บข้อมูลประจำตัวออกจาก prompt และ RAG indexes, ตรวจสอบการตั้งค่า telemetry ของแอปเดสก์ท็อป, และตรวจสอบการเรียกใช้เครื่องมือก่อนดำเนินการ
• ควบคุมเวอร์ชันสิ่งที่สำคัญ: ติดตามเวอร์ชันของโมเดล, prompt, adapter, รันไทม์, และ quantization, และบันทึก log ให้เพียงพอสำหรับการดีบักโดยไม่สร้างภัยพิบัติด้านความเป็นส่วนตัว

ความปลอดภัยของ AI ท้องถิ่นส่วนใหญ่เป็นวินัยในการปฏิบัติงานทั่วไป นั่นคือวิธีที่คุณหลีกเลี่ยงการดาวน์โหลด checkpoint สุ่มๆ มารันในฐานะ root และเปลี่ยน AI ท้องถิ่นให้กลายเป็นช่องโหว่ในเครื่อง

Benchmarks ที่สำคัญ

ทำ benchmark กับ stack ที่คุณจะใช้งานจริง คะแนน BF16 จากกระดานผู้นำของโมเดลไม่ใช่ความเป็นจริงของ Q4 บนเครื่องของคุณ

วัดคุณภาพ, latency, หน่วยความจำ, ความน่าเชื่อถือ, และความเหมาะสมในการปฏิบัติงาน:

• คุณภาพ: ความถูกต้องต้องกับงานจริงของคุณ ไม่ใช่แค่ benchmark ทั่วไป
• Latency: เวลาจนถึง token แรก, tokens ต่อวินาทีในขั้นตอน decode, และเวลาตั้งแต่ต้นจนจบ
• หน่วยความจำ: หน่วยความจำน้ำหนักโมเดล, การเติบโตของ KV-cache, VRAM สูงสุด, และพื้นที่ว่างภายใต้โหลด
• การจัดรูปแบบ: ความถูกต้องของ chat template, ความสำเร็จของ JSON/schema, ความน่าเชื่อถือของการเรียกใช้เครื่องมือ, และพฤติกรรมของ stop-token
• การค้นคืน: ความถูกต้องของการอ้างอิง, การยึดโยงกับแหล่งที่มาของคำตอบ, พฤติกรรมเมื่อไม่มีหลักฐาน, และผลกระทบของ reranker
• การปฏิบัติการ: เวลาเริ่มต้น, พฤติกรรมการอุ่นเครื่อง, การกู้คืนจากข้อขัดข้อง, การบันทึก log, ความเป็นส่วนตัว, และการติดตามเวอร์ชัน

สร้างชุดประเมินผลเล็กๆ ที่มี prompt แทน 30 ถึง 100 ข้อ รวมถึงคำตอบที่คาดหวังหรือเกณฑ์การให้คะแนน, การวัด latency และหน่วยความจำ, หมวดหมู่ความล้มเหลว, การตรวจสอบการยึดโยงของ RAG เฉพาะ, การตรวจสอบการปฏิบัติตาม JSON หากเกี่ยวข้อง, และการตรวจสอบโดยมนุษย์สำหรับงานที่คลุมเครือ

จากนั้นเปรียบเทียบโมเดล อย่าปล่อยให้กระดานผู้นำเลือก stack ท้องถิ่นให้คุณ

การเขียนโค้ดด้วยโมเดลท้องถิ่น

การเขียนโค้ดเป็นหนึ่งในกรณีการใช้งาน LLM ท้องถิ่นที่ดีที่สุด เพราะ prompt มักจะมีโค้ดส่วนตัว, latency มีความสำคัญ, การวนซ้ำบ่อยครั้ง, ต้นทุน API สามารถเพิ่มขึ้นอย่างรวดเร็ว, และโมเดลท้องถิ่นสามารถผสานรวมกับ editors, shells, grep, test runners, และ patch workflows

การตั้งค่าการเขียนโค้ดด้วยโมเดลท้องถิ่นที่แข็งแกร่งที่สุดไม่ใช่แค่ chatbot เปล่าๆ มันคือโมเดล instruct ที่มีความสามารถในการเขียนโค้ดซึ่งเชื่อมต่อกับ context ของ repository ที่ตรงเป้าหมาย, การค้นคืนผ่าน codebase, เส้นทางไฟล์, snippets ที่เกี่ยวข้อง, การรันทดสอบ, และ loop สำหรับ patch

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

อย่าปล่อยให้โมเดลท้องถิ่นเขียนโค้ดเบสขนาดใหญ่โดยไม่ตรวจสอบ "ท้องถิ่น" ไม่ได้ทำให้ตัวแทนเขียนโค้ดฉลาดขึ้น มันแค่ทำให้ context เป็นส่วนตัว, loop ราคาถูกลง, และการผสานรวมควบคุมง่ายขึ้น

ตัวแทนท้องถิ่นต้องการขอบเขตการป้องกัน

LLM ท้องถิ่นจะมีประโยชน์มากขึ้นเมื่อสามารถใช้เครื่องมือได้: การค้นหาไฟล์, คำสั่ง shell, ระบบอัตโนมัติของเบราว์เซอร์, ฐานข้อมูล, การรันโค้ด, ปฏิทิน, ระบบ ticket, API ภายใน, vector databases, ระบบบ้านอัตโนมัติ, หุ่นยนต์, หรืออุปกรณ์ edge

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

ความปลอดภัยของตัวแทนท้องถิ่นมีสี่ชั้น จำกัดขอบเขตของตัวแทนอย่างเคร่งครัดโดยให้เข้าถึงเฉพาะไดเรกทอรี, API, การเข้าถึงเครือข่าย, และข้อมูลประจำตัวที่จำเป็นจริงๆ จำกัดการทำงานด้วย sandbox, คอนเทนเนอร์, ผู้ใช้ที่มีสิทธิ์น้อยที่สุด, การยืนยันสำหรับการกระทำที่ทำลายล้าง, และอาร์กิวเมนต์ของเครื่องมือที่ตรวจสอบ schema แล้ว ปฏิบัติต่อข้อมูลนำเข้าเสมือนเป็นปรปักษ์ เพราะเอกสารที่ถูกค้นคืน, หน้าเว็บ, ticket, และอีเมลสามารถมีการโจมตีแบบ prompt injection ได้ เก็บบันทึกการตรวจสอบโดยการบันทึกการเรียกใช้เครื่องมือ, เวอร์ชันโมเดล, prompt, และการอนุมัติ โดยไม่ทิ้งความลับลงใน log

Structured outputs ช่วยได้ แต่ไม่ใช่ขอบเขตด้านความปลอดภัย JSON schemas, constrained decoding, และ function signatures ทำให้การตรวจสอบการเรียกใช้เครื่องมือง่ายขึ้น แต่ไม่ได้พิสูจน์ว่าโมเดลเข้าใจคำขอ, เลือกการกระทำที่ปลอดภัย, หรือหลีกเลี่ยงคำแนะนำที่ถูกแทรก

สำหรับการใช้เครื่องมืออย่างจริงจัง ให้วางนโยบายการตรวจสอบไว้นอกโมเดล

RAG ดีกว่า Prompt ขนาดใหญ่

RAG ย่อมาจาก Retrieval-Augmented Generation แทนที่จะยัดข้อมูลทั้งหมดลงใน prompt คุณจะดึงข้อมูล chunk ที่เกี่ยวข้องจากฐานความรู้และให้เฉพาะ chunk เหล่านั้นแก่โมเดล

ระบบ RAG ท้องถิ่นที่ดีโดยทั่วไปประกอบด้วยการนำเข้าเอกสาร, การแยกวิเคราะห์, การแบ่ง chunk, embeddings, ดัชนีเวกเตอร์, การค้นคืน, การ rerank, การสร้าง prompt, การสร้างคำตอบ, การตรวจสอบการยึดโยง, และการประเมินผล แต่ละขั้นตอนคือจุดที่อาจเกิดความล้มเหลว

การแยกวิเคราะห์ที่ไม่ดีทำให้ตารางกลายเป็นขยะ การแบ่ง chunk ที่ไม่ดีแบ่งคำตอบข้ามขอบเขต การค้นคืนที่ไม่ดีส่งคืนย่อหน้าที่ไม่เกี่ยวข้อง การ rerank ที่ไม่ดีฝังคำตอบที่ถูกต้องไว้ที่อันดับ 20 โมเดลที่ดีไม่สามารถตอบโดยอาศัยหลักฐานที่ไม่เคยได้รับอย่างน่าเชื่อถือ

ระบบ RAG ที่แย่ส่วนใหญ่ไม่ได้แย่เพราะ LLM พวกมันแย่เพราะการแบ่ง chunk, การค้นคืน, การ rerank, และการประเมินผล

กลยุทธ์การแบ่ง chunk คือนักฆ่าเงียบ Chunk ขนาดคงที่ที่ไม่มีการซ้อนทับกันสามารถแยกประโยคและสูญเสียบริบทได้ การแบ่ง chunk แบบ semantic หรือ hierarchical chunking พร้อมการค้นคืนเอกสารแม่มักจะทำงานได้ดีกว่า แต่ไม่มีคำตอบสากล คุณต้องประเมินขนาด chunk, การซ้อนทับ, และกฎการแบ่งบนเอกสารจริงของคุณ

Reranker ที่ดีสามารถกู้คืนการค้นคืนที่แย่ได้ แต่ไม่มี reranker ใดที่สามารถแก้ไข chunk ที่สูญเสียคำตอบไประหว่างการนำเข้าได้

เอกสารและงานความรู้

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

Workflow นั้นง่ายแต่ก็ไร้ความปราณี แยกวิเคราะห์เอกสารอย่างระมัดระวัง, เก็บ meta data ของหน้าและส่วนต่างๆ, แบ่ง chunk แบบ semantic, ใช้ embeddings และ rerankers, ขอให้อ้างอิงแหล่งที่มา, แยกคำตอบออกจากแหล่งที่มาและจากการใช้เหตุผลทั่วไป, และประเมินความถูกต้องของการอ้างอิง

อย่าสมมติว่าโมเดลรู้ว่ามีอะไรอยู่ในเอกสารของคุณ มันรู้แค่สิ่งที่คุณใส่ลงใน prompt หรือดึงเข้ามาใน context

สำหรับบันทึกการประชุม ให้รักษาป้ายชื่อผู้พูดและการประทับเวลา สำหรับการตรวจสอบสัญญา ให้แบ่ง chunk ตามข้อหรือส่วน แทนที่จะนับ token ตามอำเภอใจ สำหรับการถามตอบเอกสารทางเทคนิค ให้รวมหมายเลขหน้าหรือจุดยึดส่วนต่างๆ ใน chunk ที่ดึงมา เพื่อให้โมเดลสามารถอ้างอิงแหล่งที่มาได้อย่างถูกต้อง

สำหรับงานเอกสาร parser และ retriever ของคุณมีความสำคัญพอๆ กับโมเดล

การปรับใช้บน Edge

โมเดลขนาดเล็กมีประโยชน์มากขึ้นบนโทรศัพท์, แล็ปท็อป, หุ่นยนต์, IoT gateways, อุปกรณ์ในโรงงาน, ยานพาหนะ, อุปกรณ์การแพทย์, อุปกรณ์ภาคสนามแบบออฟไลน์, และแอปเบราว์เซอร์ Edge ไม่ได้เป็นแค่เวอร์ชันที่เล็กลงของเวิร์คสเตชั่น มันมีข้อจำกัดที่แตกต่างกันออกไป

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

การตั้งค่า Edge ที่ใช้งานได้จริง มักใช้โมเดลขนาด 0.5B ถึง 4B การควอนไทซ์น้ำหนักแบบ aggressive พรอมต์ขนาดเล็ก โครงสร้างตายตัว เวิร์กโฟลว์ที่ใช้เครื่องมือช่วย embeddings ในเครื่อง การแคช และไม่มีประวัติการสนทนาที่ไม่จำเป็น

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

คู่มือการใช้งาน Local LLM

ใช้สิ่งนี้เป็นด่านสุดท้าย ก่อนที่จะเชื่อถือโมเดลท้องถิ่นสำหรับงานจริง

เลือกและปรับให้เหมาะสม: เลือกตระกูลโมเดลที่เหมาะกับงาน อ่านใบอนุญาต ยืนยันข้อกำหนดด้านฮาร์ดแวร์ เลือกระดับการควอนไทซ์ และประมาณการใช้หน่วยความจำทั้งหมด อย่าหยุดแค่ขนาดน้ำหนัก ให้รวม KV cache โอเวอร์เฮดรันไทม์ batch/concurrency และส่วนเผื่อความปลอดภัย

โหลดและจัดรูปแบบ: เลือกใช้ safetensors หรือ GGUF จากแหล่งที่เชื่อถือได้ หลีกเลี่ยงไฟล์แบบ pickle ที่ไม่น่าเชื่อถือ ตรวจสอบ tokenizer และ chat template กำหนดความยาว context window อย่างตั้งใจ และเลือกพารามิเตอร์การถอดรหัสให้เหมาะกับงาน ถ้า template ผิด การประเมินก็จะไม่ถูกต้อง

ประเมินและดำเนินการ: ทดสอบด้วยพรอมต์ที่เป็นตัวแทน วัด time to first token และ decode speed ติดตาม peak memory ประเมินการค้นคืนก่อนที่จะเพิ่ม RAG ทดสอบเครื่องมือใน sandbox ก่อนที่จะเพิ่ม agents และทำ fine-tuning เฉพาะเมื่อวิธีการที่ง่ายกว่าล้มเหลว

กำหนดเวอร์ชันทุกอย่างที่สำคัญ: โมเดล, การควอนไทซ์, รันไทม์, พรอมต์, chat template, adapter, embedding model, reranker, ชุดการประเมิน และโปรไฟล์ฮาร์ดแวร์ ระบบท้องถิ่นจะควบคุมได้ง่ายขึ้นก็ต่อเมื่อคุณสามารถทำซ้ำสิ่งที่คุณรันได้

Fine-Tuning

Fine-tuning เปลี่ยนพฤติกรรมของโมเดลโดยการฝึกบนข้อมูลเพิ่มเติม สำหรับผู้ใช้ท้องถิ่น วิธีที่สำคัญที่สุดคือ LoRA และ QLoRA

LoRA จะตรึงโมเดลฐานและฝึกน้ำหนัก adapter แบบ low-rank ขนาดเล็ก ซึ่งช่วยลดพารามิเตอร์ที่ต้องฝึกและให้คุณรักษา adapter แบบ lightweight หลายตัวได้ QLoRA ขยายแนวคิดนี้โดยการ fine-tuning ผ่านโมเดลที่ถูกควอนไทซ์แบบ 4-bit ที่ถูกตรึงลงใน LoRA adapters

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

อย่า Fine-tuning ก่อน ลองทำตามลำดับนี้: แก้ไข chat template, ปรับปรุงพรอมต์, ปรับปรุงโมเดล, ปรับปรุงการถอดรหัส, RAG, reranking, ตัวอย่าง few-shot, แล้วจึง fine-tuning

ปัญหาส่วนใหญ่ที่ดูเหมือนว่าโมเดลไม่เข้าใจโดเมนของฉัน จริงๆ แล้วคือพรอมต์ของฉันคลุมเครือ template ผิด หรือการค้นคืนของฉันมีปัญหา

แผน fine-tuning ที่ดีประกอบด้วย ข้อมูลที่สะอาด การแบ่ง train/validation/test การประเมินพื้นฐาน พฤติกรรมเป้าหมายที่ชัดเจน การตรวจสอบความปลอดภัย การตรวจสอบ overfitting การประเมินการถดถอย การกำหนดเวอร์ชัน adapter การตรวจสอบใบอนุญาต และแผนการย้อนกลับ

Open-Weight ไม่ได้หมายถึง Opensource

ในปี 2026 วลี open model มักถูกใช้อย่างหลวมๆ คุณควรแยกแยะระหว่าง open-weight, source-available, opensource และ local-compatible

Open-weight มักหมายถึงคุณสามารถดาวน์โหลดน้ำหนักได้ มันไม่ได้หมายความโดยอัตโนมัติว่าคุณสามารถใช้โมเดลในเชิงพาณิชย์ ดัดแปลงได้อย่างอิสระ ฝึกบนเอาต์พุตของมัน ปรับใช้ในทุกขนาด หรือละเว้นข้อกำหนดการระบุแหล่งที่มา

Source-available หมายถึงโค้ดหรือน้ำหนักสามารถมองเห็นได้ มันไม่จำเป็นต้องหมายถึงใบอนุญาตเป็น opensource

Opensource AI model เป็นข้ออ้างที่แข็งแกร่งกว่า OSI's Opensource AI Definition ถือว่าระบบ AI รวมถึงสถาปัตยกรรม พารามิเตอร์/น้ำหนัก โค้ดการอนุมาน และข้อมูลและโค้ดที่เพียงพอที่ใช้ในการหาพารามิเตอร์ นั่นเป็นมาตรฐานที่สูงกว่าการที่น้ำหนักอยู่บน Hugging Face มาก

ใบอนุญาตบางตัวดูเหมือนอนุญาตแต่มีข้อจำกัด: ห้ามใช้ในการแข่งขัน ห้ามฝึกบนเอาต์พุต ห้ามปรับใช้เกินขนาดที่กำหนด การยกเว้นตามพื้นที่ทางภูมิศาสตร์ ข้อกำหนดการระบุแหล่งที่มา ข้อกำหนดสิทธิบัตร หรือภาระผูกพันแบบ copyleft กับอนุพันธ์

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

อภิธานศัพท์

คำศัพท์เกี่ยวกับโมเดลและการปรับแต่ง

• Active Parameters: ในโมเดล MoE มีเพียงบางพารามิเตอร์เท่านั้นที่ใช้สำหรับโทเค็นที่กำหนด โมเดลอาจมีพารามิเตอร์ทั้งหมดหลายแสนล้าน แต่มีพารามิเตอร์ที่ใช้งานต่อโทเค็นน้อยกว่ามาก
• Adapter: โมดูลขนาดเล็กที่สามารถฝึกได้ซึ่งเพิ่มเข้าไปในโมเดลฐาน มักผ่าน LoRA
• Base Model: โมเดลที่ถูกฝึกไว้ล่วงหน้า ซึ่งไม่ได้ถูกปรับแต่งสำหรับการสนทนาหรือการทำตามคำแนะนำโดยเฉพาะ
• Fine-Tuning: การฝึกเพิ่มเติมที่เปลี่ยนพฤติกรรมของโมเดลสำหรับโดเมนเป้าหมายหรือรูปแบบเอาต์พุต
• Instruct Model: โมเดลที่ถูกปรับแต่งให้ทำตามคำแนะนำ
• LoRA / QLoRA: วิธีการ fine-tuning ที่มีประสิทธิภาพโดยใช้ low-rank adapters โดย QLoRA จะฝึกผ่านโมเดลฐานที่ถูกควอนไทซ์
• MoE: Mixture of Experts สถาปัตยกรรมแบบ稀疏 ที่มีเพียงเครือข่ายย่อยผู้เชี่ยวชาญที่เลือกไว้เท่านั้นที่ทำงานต่อโทเค็น
• Weights / Parameters: ค่าตัวเลขที่เรียนรู้ภายในโมเดล

กลไกการอนุมาน

• BOS / EOS: โทเค็นเริ่มต้นลำดับและสิ้นสุดลำดับ
• Chat Template: รูปแบบที่ใช้ในการแสดงข้อความของระบบ ผู้ใช้ ผู้ช่วย และเครื่องมือ
• Context Window: จำนวนโทเค็นสูงสุดที่โมเดลสามารถประมวลผลได้ในครั้งเดียว
• Decode: ระยะที่โมเดลสร้างโทเค็นใหม่ทีละตัว
• DFlash: วิธีการถอดรหัสแบบ Speculative Decoding ในปี 2026 ที่ใช้ block diffusion สำหรับการร่างแบบขนาน
• DDTree / DTree: วิธีการถอดรหัสแบบ Speculative Decoding ที่สร้าง draft tree จากการกระจายของ block diffusion และตรวจสอบอย่างมีประสิทธิภาพ
• GQA / MQA: รูปแบบ Attention ที่ลดขนาด KV-cache และปรับปรุงประสิทธิภาพการอนุมาน
• Inference: การรันโมเดลเพื่อสร้างเอาต์พุต
• KV Cache: สถานะ attention key/value ที่เก็บไว้สำหรับโทเค็นก่อนหน้า
• Prefill: ระยะที่โมเดลประมวลผลพรอมต์อินพุตก่อนการสร้าง
• RoPE: Rotary Position Embeddings วิธีการเข้ารหัสตำแหน่งที่พบได้ทั่วไปใน LLM สมัยใหม่
• Speculative Decoding: เทคนิคความเร็วที่ drafter ที่ถูกกว่าเสนอโทเค็น และโมเดลเป้าหมายตรวจสอบโทเค็นเหล่านั้น
• Tokenizer: คอมโพเนนต์ที่แปลงข้อความเป็น token ID และกลับกัน
• Top-p / Top-k / Temperature: ตัวควบคุมการสุ่มสำหรับการสร้างโทเค็น

การค้นคืน ไฟล์ และการให้บริการ

• AWQ: Activation-aware weight quantization
• Embedding Model: โมเดลที่แปลงข้อความเป็นเวกเตอร์สำหรับการค้นหา/ค้นคืน
• FP8 KV Cache: โหมดบีบอัด KV-cache 8-bit ที่ใช้งานได้จริง ซึ่งรองรับในรันไทม์บางตัว
• GGUF: รูปแบบไฟล์โมเดลที่ใช้อย่างแพร่หลายโดย llama.cpp
• PagedAttention: เทคนิคการจัดการหน่วยความจำ KV-cache ที่ใช้โดย vLLM-style serving
• Quantization: การลดความแม่นยำเชิงตัวเลขเพื่อประหยัดหน่วยความจำและปรับปรุงประสิทธิภาพ
• RAG: Retrieval-Augmented Generation ค้นคืนบริบทภายนอกที่เกี่ยวข้องและมอบให้กับโมเดล
• Reranker: โมเดลที่จัดลำดับข้อความที่ค้นคืนตามความเกี่ยวข้อง
• Safetensors: รูปแบบการทำให้เป็นอนุกรม tensor ที่ปลอดภัยกว่า ซึ่งหลีกเลี่ยงความเสี่ยงจากการรันที่อิงตาม pickle

คำส่งท้าย

ระบบนิเวศของ Local LLM ประกอบด้วย โมเดล edge ขนาดเล็ก โมเดลผู้บริโภคขนาด 7B ถึง 32B ที่แข็งแกร่ง ระบบ open-weight แบบ MoE ขนาดใหญ่ โมเดล multimodal โมเดล long-context โมเดลการให้เหตุผลท้องถิ่น รันไทม์การอนุมานที่สมบูรณ์ และ stacks การให้บริการส่วนตัวที่ทรงพลังมากขึ้น

แต่พื้นฐานไม่ได้เปลี่ยนไป: โมเดลทำนายหนึ่งโทเค็นต่อครั้ง โทเค็นไม่ใช่คำพูด น้ำหนักไม่ใช่ทั้งโมเดล chat templates มีความสำคัญ KV cache คือค่าหน่วยความจำที่ซ่อนอยู่ การควอนไทซ์คือการแลกเปลี่ยน บริบทที่ยาวไม่ฟรี คุณภาพ RAG ขึ้นอยู่กับการค้นคืน การ fine-tuning ต้องการการประเมิน และความเป็นส่วนตัวในเครื่องยังคงต้องมีวินัยด้านความปลอดภัย

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

Local LLMs ส่วนใหญ่เป็นคณิตศาสตร์หน่วยความจำ บวกกับการจัดรูปแบบ บวกกับการประเมิน ทำให้สิ่งเหล่านั้นถูกต้อง และส่วนที่เหลือของ stack จะกลายเป็นเรื่องง่ายขึ้นที่จะเข้าใจ

จนกว่าจะพบกันใหม่

• Ahmad