Inference Engines สำหรับ LLM และฮาร์ดแวร์ AI แบบ Local (ฉบับปี 2026)

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

นั่นคือวิธีคิดที่มีประโยชน์ที่สุดเกี่ยวกับ LLM inference engines

หมายเหตุเกี่ยวกับซีรีส์: นี่คือภาคที่ 3 ในซีรีส์ของฉันเกี่ยวกับการสอน Self-hosted LLMs / Local AI

• ภาคที่ 1: GPU Memory Math for LLMs (2026 Edition)
• ภาคที่ 2: Memory Bandwidth for Local AI Hardware (2026 Edition)

สองชิ้นนั้นอธิบายเกี่ยวกับความจุของฮาร์ดแวร์และคณิตศาสตร์ของแบนด์วิดท์

ชิ้นนี้อธิบายเกี่ยวกับเลเยอร์ซอฟต์แวร์ที่เปลี่ยนฮาร์ดแวร์นั้นให้เป็นอินเฟอเรนซ์ที่ใช้งานได้

เอนจิน

เครื่องมือเหล่านี้มีวัตถุประสงค์/อยู่ในเลเยอร์ที่แตกต่างกัน

• ความสะดวกในการพกพาในเครื่อง
• CUDA สำหรับผู้บริโภค
• เวิร์กโฟลว์หน่วยความจำแบบรวมของ Apple
• อินเฟอเรนซ์แบบ Quantized
• การให้บริการในระดับโปรดักชัน
• การประสานงานแบบกระจาย
• การทำงานในดาต้าเซ็นเตอร์ที่ปรับแต่งโดยผู้จำหน่าย

แบบจำลองทางความคิดที่มีประโยชน์:

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

เอนจินที่ดีที่สุดจะตรงกับลำดับชั้นหน่วยความจำ อินเตอร์คอนเนกต์ รูปแบบ quantization ความหน่วงและเป้าหมายปริมาณงาน สถาปัตยกรรมโมเดล และวุฒิภาวะในการปฏิบัติการของคุณ

คู่มือการตัดสินใจในหน้าเดียว

• แล็ปท็อป / อุปกรณ์ขอบ / ฮาร์ดแวร์แปลก → llama.cpp
• เวิร์กโฟลว์ที่ใช้ Mac เป็นหลัก → MLX / MLX-LM
• อินเฟอเรนซ์ในเครื่อง RTX เดียว → ExLlamaV2
• GPU NVIDIA / CUDA 2-4+ ตัว → ExLlamaV3
• การให้บริการโปรดักชันทั่วไป → vLLM
• บริบทยาว / MoE / การกำหนดเส้นทาง → SGLang
• ประสิทธิภาพสูงสุดของ NVIDIA → TensorRT-LLM
• การประสานงานคลัสเตอร์ → NVIDIA Dynamo

ส่วนที่เหลือของคู่มือนี้อธิบายว่าเพราะเหตุใด

อินเฟอเรนซ์เอนจินทำอะไรได้บ้าง

อินเฟอเรนซ์เอนจินโหลดเวท โทเค็นไนซ์อินพุต รัน forward pass สุ่มตัวอย่างโทเค็น ดูแล KV cache และสตรีมผลลัพธ์ เอนจินที่จริงจังยังจัดการกับการทำเป็นชุด การจัดลำดับ การแคชคำนำหน้า quantization การดำเนินการแบบขนาน การให้บริการ API เมตริก และการดำเนินการแบบกระจาย

เวิร์กโหลดมีสองเฟส:

Prefill อ่านพรอมต์และสร้าง KV cache เริ่มต้น ซึ่งต้องใช้การคำนวณสูง

Decode สร้างทีละหนึ่งโทเค็น อ่านเวทและ KV cache ซ้ำๆ ซึ่งถูกจำกัดด้วยแบนด์วิดท์หน่วยความจำ ความเร็วในการ Decode ติดตามแบนด์วิดท์หน่วยความจำมากกว่าค่าการคำนวณสูงสุด

ความแตกต่างนั้นอธิบายได้เกือบทุกอย่าง:

• พรอมต์สั้น คำตอบยาว: decode ครอบงำ → แบนด์วิดท์หน่วยความจำและการทำเป็นชุดมีความสำคัญ
• พรอมต์ยาว คำตอบสั้น: prefill ครอบงำ → attention kernels และ chunked prefill มีความสำคัญ
• ผู้ใช้จำนวนมาก: คุณภาพของตัวจัดลำดับมีความสำคัญ → continuous batching, cache paging, ความเป็นธรรม
• บริบทยาว: KV cache ครอบงำ → paged attention, KV quantization, offload
• MoE: การกำหนดเส้นทางผู้เชี่ยวชาญครอบงำ → expert parallelism, อินเตอร์คอนเนกต์, grouped GEMMs
• หลายโหนด: อินเตอร์คอนเนกต์ครอบงำ → NVLink, RDMA, pipeline parallelism, การแยกส่วน

PagedAttention จัดการกับการกระจายตัวของ KV cache FlashAttention ใช้ IO-aware tiling เพื่อลดการรับส่งข้อมูล HBM (High Bandwidth Memory) Speculative decoding ร่างโทเค็นราคาถูกและตรวจสอบแบบขนาน ธีมที่เกิดขึ้นซ้ำ: ประสิทธิภาพของอินเฟอเรนซ์คือการเคลื่อนย้ายหน่วยความจำบวกกับการจัดลำดับ

คอขวดที่แท้จริง

1. แบนด์วิดท์หน่วยความจำ ไม่ใช่แค่ขนาด VRAM VRAM กำหนดความพอดี แบนด์วิดท์กำหนดความเร็วในการ Decode M3 Ultra ของ Apple มีแบนด์วิดท์หน่วยความจำแบบรวมสูงสุดถึง 819 GB/s H100 SXM ของ NVIDIA มีแบนด์วิดท์หน่วยความจำ GPU อยู่ที่ 3.35 TB/s หน่วยความจำแบบรวมช่วยให้คุณใส่โมเดลที่ไม่พอดีกับ VRAM สำหรับผู้บริโภคได้ HBM ช่วยให้คุณให้บริการได้เร็วขึ้นเมื่อโมเดลพอดี ความพอดีไม่ใช่ความเร็ว ความจุไม่ใช่แบนด์วิดท์

1. การเติบโตของ KV cache KV cache จะเติบโตตามขนาดแบตช์และความยาวบริบท เวิร์กโหลดแบบบริบทยาวอาจหน่วยความจำหมดแม้ว่าเวทจะพอดี PagedAttention แบ่ง KV cache ออกเป็นบล็อก เพิ่มการใช้งานและรองรับแบตช์ที่ใหญ่ขึ้น

1. อินเตอร์คอนเนกต์ ทันทีที่โมเดลข้ามขอบเขต GPU (หลาย GPU) คุณต้องจ่ายต้นทุนการสื่อสาร Tensor parallelism จำเป็นต้องมีการสื่อสารแบบ all-reduce บ่อยครั้ง Pipeline parallelism สื่อสารที่ขอบเขตของสเตจ Expert parallelism จำเป็นต้องมีการรับส่งข้อมูลแบบ all-to-all สำหรับ MoE เอกสารของ vLLM ระบุว่าหากไม่มี NVLink pipeline parallelism สามารถมีประสิทธิภาพดีกว่า tensor parallelism

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

1. โอเวอร์เฮดรันไทม์ CUDA graphs, kernel fusion, โอเวอร์เฮดการสุ่มตัวอย่าง, โอเวอร์เฮด tokenizer, โอเวอร์เฮด HTTP, การสลับ LoRA, และ structured decoding ล้วนมีความสำคัญ ในระดับสูง โอเวอร์เฮด 2% ที่น่ารำคาญจะรวมตัวกันและเรียกร้องความสนใจ

ตระกูลของเอนจิน

มีสี่ตระกูลใหญ่:

รันไทม์ในเครื่องที่พกพาได้: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, เครื่องมือแบบ Ollama สิ่งเหล่านี้สนใจเกี่ยวกับ "ทำให้มันทำงานที่นี่"

รันไทม์หน่วยความจำแบบรวมของ Apple: MLX และ MLX-LM สิ่งเหล่านี้สนใจเกี่ยวกับ "ใช้หน่วยความจำที่ใช้ร่วมกันขนาดใหญ่และสแต็กของ Apple ให้ดี"

ควอนต์เอนจิน CUDA สำหรับผู้บริโภค: ExLlamaV2 และ ExLlamaV3 สิ่งเหล่านี้สนใจเกี่ยวกับ "ทำให้เครื่อง 3090/4090/5090 ของฉันทำงานเร็วด้วยเวทบิตต่ำ"

เอนจินการให้บริการโปรดักชัน: vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy สิ่งเหล่านี้สนใจเกี่ยวกับผู้ใช้พร้อมกัน, KV cache, การทำเป็นชุด, ความขนาน, การสังเกตการณ์ และต้นทุนต่อโทเค็น

จากนั้นก็มีเลเยอร์การประสานงานเช่น Dynamo ที่อยู่เหนือเอนจินและประสานงานฝูง, prefill/decode ที่แยกส่วน, การกำหนดเส้นทาง และการปรับขนาดอัตโนมัติ

llama.cpp: ราชาแห่งความสะดวกในการพกพา

llama.cpp คือคำตอบเมื่อฮาร์ดแวร์ผิดปกติ, ถูกจำกัด, ออฟไลน์, เน้น CPU, เน้นขอบ หรือไม่ใช่โหนดดาต้าเซ็นเตอร์ NVIDIA ที่เป็นระเบียบ

รองรับ Apple Silicon ผ่าน ARM NEON, Accelerate และ Metal; x86 ผ่าน AVX/AVX2/AVX512/AMX; RISC-V; quantization บิตต่ำ; CUDA; AMD ผ่าน HIP; MUSA; Vulkan; SYCL; และการ offload แบบ CPU+GPU แบบไฮบริด นี่คือเหตุผลที่ llama.cpp ครองเลน "แค่ทำให้มันทำงาน"

HTTP server มีความสามารถมากกว่า "ตัวรันในเครื่องแบบของเล่น" llama-server มีเส้นทางที่เข้ากันได้กับ OpenAI, ความเข้ากันได้กับ Anthropic Messages API, การ re-ranking, continuous batching, การรองรับ multimodal, ข้อจำกัด JSON schema, การเรียกใช้ฟังก์ชัน, speculative decoding และ web UI

ข้อจำกัดที่สำคัญ: llama.cpp ไม่ได้มีไว้สำหรับการให้บริการโปรดักชันแบบหลายโหนดที่จริงจัง RPC backend ของมันถูกจัดทำเป็นเอกสารอย่างชัดเจนว่าเป็น proof-of-concept, เปราะบาง และไม่ปลอดภัย

คำตัดสิน: ใช้ llama.cpp เมื่อความสะดวกในการพกพา, การทำงานออฟไลน์, GGUF หรือการ offload แบบไฮบริดมีความสำคัญมากกว่าการให้บริการในระดับฝูง

อย่าใช้กับ Multi-GPUs

MLX และ MLX-LM: อาวุธของ Apple Silicon

MLX คืออาร์เรย์เฟรมเวิร์กของ Apple สำหรับ Apple Silicon และ MLX-LM คือแพ็คเกจ LLM ที่สร้างขึ้นบนนั้น มันคือสแตก ML ที่เน้น Mac เป็นหลัก

ข้อเท็จจริงสำคัญของฮาร์ดแวร์คือหน่วยความจำแบบรวม Apple Silicon ให้ CPU และ GPU เข้าถึงพูลหน่วยความจำเดียวกันโดยตรง อาร์เรย์ MLX อยู่ในหน่วยความจำแบบรวม และคุณเลือกอุปกรณ์เมื่อรันการดำเนินการแทนที่จะย้ายอาร์เรย์ระหว่างพื้นที่หน่วยความจำแยกกัน

สิ่งนี้เปลี่ยนสมดุลของอินเฟอเรนซ์ในเครื่อง บนระบบ GPU แบบแยกส่วน คำถามคือ "มันพอดีกับ VRAM หรือไม่?" บน Mac ที่ใช้ชิป M-series ที่มีหน่วยความจำแบบรวมขนาดใหญ่ คำถามกลายเป็น "มันพอดีกับหน่วยความจำหรือไม่ และระบบหน่วยความจำสามารถป้อน GPU ได้เร็วพอหรือไม่?" โมเดลควอนไทซ์ขนาดใหญ่สามารถพอดีกับเครื่องที่โมเดลเดียวกันนั้นเป็นไปไม่ได้บน GPU สำหรับผู้บริโภคขนาด 24 GB

อย่างไรก็ตาม มันก็ช้าลงเช่นกัน

MLX-LM เพิ่มการบูรณาการ Hugging Face Hub, quantization, การปรับแต่ง LoRA และแบบเต็มรูปแบบ, อินเฟอเรนซ์แบบกระจาย และระบบนิเวศโมเดล MLX Community ขนาดใหญ่ MLX ไม่ได้มีเฉพาะ Mac อีกต่อไป: มีแพ็คเกจ CUDA และ CPU-only สำหรับ Linux การสื่อสารแบบกระจายรองรับ MPI, Ring over TCP, JACCL สำหรับ RDMA ผ่าน Thunderbolt และ NCCL สำหรับ CUDA

เซิร์ฟเวอร์ของ MLX-LM เองก็เตือนว่าไม่แนะนำสำหรับโปรดักชันเนื่องจากใช้การตรวจสอบความปลอดภัยขั้นพื้นฐานเท่านั้น

คำตัดสิน: ใช้ MLX สำหรับเวิร์กโฟลว์ ML และ LLM ที่เน้น Mac เป็นหลัก สำหรับการให้บริการสาธารณะที่มีการทำงานพร้อมกันสูง ให้เริ่มต้นด้วยสแตกการให้บริการจริง

ExLlamaV2 และ V3: CUDA สำหรับผู้บริโภค ปรับแต่งและรวดเร็ว

ExLlamaV2 คือควอนต์เอนจิน CUDA ในเครื่องสำหรับคนที่ต้องการให้ GPU NVIDIA สำหรับผู้บริโภคทำงานได้ดีเกินความคาดหมาย รองรับ paged attention, dynamic batching, prompt caching, การขจัดข้อมูลซ้ำของ KV cache, การสร้างแบบเป็นชุด, การสตรีม และ speculative decoding คำที่ต้องจำคือ ในเครื่อง มันทำให้โมเดลควอนไทซ์เร็วบน GPU CUDA สมัยใหม่ โดยเฉพาะการ์ดสำหรับผู้บริโภค

เหมาะที่สุด: เครื่อง RTX 3090/4090/5090 เครื่องเดียว, ผู้ช่วยเขียนโค้ดในเครื่อง, แชทในเครื่อง, โมเดลควอนไทซ์ EXL2 และการใช้งานเวิร์กสเตชันสำหรับผู้บริโภคขั้นสูง

ExLlamaV3 ขยายปรัชญาไปสู่อินเฟอเรนซ์แบบหลาย GPU และ MoE ในเครื่อง เพิ่มรูปแบบ quantization EXL3 ที่ใช้ QTIP, tensor-parallel และ expert-parallel แบบยืดหยุ่นสำหรับฮาร์ดแวร์สำหรับผู้บริโภค, เซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI ผ่าน TabbyAPI, continuous dynamic batching และการรองรับ multimodal

V3 น่าสนใจเมื่อคุณมี GPU NVIDIA สำหรับผู้บริโภค 2-4+ ตัวหรือต้องการ MoE ในเครื่อง คาดว่าจะมีข้อแม้: โมเดลบางตัวไม่รองรับ tensor หรือ expert parallelism ใน ExLlamaV3

คำตัดสิน: ExLlamaV2 คือ CUDA เอนจินในเครื่องสำหรับผู้ที่ชื่นชอบ ExLlamaV3 คือขอบเขตใหม่สำหรับการตั้งค่าในเครื่องแบบหลาย GPU (2-4) คาดหวังขอบที่หยาบกว่าเพื่อความสามารถที่ดีกว่า

vLLM: เซิร์ฟเวอร์โปรดักชันโอเพนซอร์สเริ่มต้น

vLLM คือเอนจินแรกที่ทีมส่วนใหญ่ควรประเมินสำหรับการให้บริการ LLM โอเพนซอร์สที่จริงจัง

มีระบบจัดการหน่วยความจำ KV ที่ใช้ PagedAttention, continuous batching, chunked prefill, prefix caching, CUDA/HIP graphs, quantization ที่ครอบคลุม (FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ, AWQ, GGUF), เคอร์เนล attention และ GEMM/MoE ที่ปรับให้เหมาะสม, speculative decoding, torch.compile และ prefill/decode/encode ที่แยกส่วน

นอกจากนี้ยังยืดหยุ่น: tensor/pipeline/data/expert/context parallelism, การสตรีม, structured outputs, การเรียกใช้เครื่องมือ, OpenAI-compatible และ Anthropic Messages APIs, gRPC, multi-LoRA และรองรับ NVIDIA, AMD, x86/ARM/PowerPC CPUs รวมถึงปลั๊กอินสำหรับ TPU, Gaudi, Ascend, Apple Silicon และอื่นๆ

เอกสารของ vLLM ระบุว่าการปรับใช้แบบหลายโหนดมักใช้ Ray และหากไม่มี NVLink pipeline parallelism อาจดีกว่า tensor parallelism กับดักคือการสันนิษฐานว่า vLLM ขจัดความจำเป็นในการคิดเชิงระบบ คุณยังต้องปรับแต่งการทำเป็นชุด ความยาวบริบท การใช้งานหน่วยความจำ GPU เค้าโครงความขนาน และการกำหนดเส้นทาง vLLM ให้เอนจินที่ดีมากแก่คุณ มันยังคงต้องมี System Design ที่ดี

คำตัดสิน: ถ้ามีคนพูดว่า "เราจำเป็นต้องให้บริการโมเดลโอเพนซอร์สในโปรดักชัน" vLLM คือจุดเริ่มต้นเริ่มต้น

SGLang: ลูกพี่ลูกน้องที่ชาญฉลาดด้านระบบของ vLLM

SGLang คือสิ่งที่คุณใช้เมื่อเวิร์กโหลดการให้บริการนั้นยุ่งยาก: structured outputs, บริบทยาว, MoE, การแยกส่วน และการกำหนดเส้นทาง

มี RadixAttention prefix caching, การแยกส่วน prefill-decode, speculative decoding, continuous batching, paged attention, tensor/pipeline/expert/data parallelism, structured outputs, chunked prefill และ multi-LoRA batching รองรับ NVIDIA, AMD, Intel Xeon, Google TPU, Ascend NPU และอื่นๆ

จุดแตกต่างของ SGLang คือสถาปัตยกรรมการให้บริการ การแยกส่วน prefill-decode ของมันแยก prefill ที่ใช้การคำนวณสูงออกจาก decode ที่ใช้หน่วยความจำสูงไปยังอินสแตนซ์เฉพาะ โดยโอน KV cache ระหว่างกัน สิ่งนี้ป้องกันไม่ให้แบตช์ prefill ยาวขัดจังหวะ decode และทำให้เวลาแฝงของโทเค็นพุ่งสูงขึ้น

คำตัดสิน: SGLang มีไว้สำหรับทีมที่คอขวดไม่ใช่ "เราสามารถรันโมเดลได้หรือไม่?" อีกต่อไป แต่เป็น "เราสามารถรันมันภายใต้ทราฟฟิกที่ไม่เป็นมิตรโดยไม่ทำให้เวลาแฝง หน่วยความจำ และต้นทุนไหม้ได้หรือไม่?"

TensorRT-LLM: ประสิทธิภาพสูงสุดของ NVIDIA

TensorRT-LLM คือสแตกประสิทธิภาพสูงสุดของ NVIDIA มันได้รับการปรับให้เหมาะสม เชี่ยวชาญ ทรงพลัง และไม่แสร้งทำเป็นว่าพกพาได้

มันให้ Python APIs เพื่อสร้าง TensorRT engines ด้วยการปรับให้เหมาะสมที่สุด รวมถึงรันไทม์ Python และ C++ รวมถึงเคอร์เนลที่กำหนดเองสำหรับ attention, GEMM และ MoE; การแยกส่วน prefill-decode, Wide Expert Parallelism, speculative decoding; และ Python API ระดับสูงที่รวมเข้ากับ NVIDIA Dynamo และ Triton Inference Server

GPU B200 สามารถโหลดเวท FP4 ด้วยเคอร์เนลที่ปรับให้เหมาะสม H100 และรุ่นหลังรองรับ quantization FP8 ที่สามารถเพิ่มประสิทธิภาพเป็นสองเท่าและลดการใช้หน่วยความจำครึ่งหนึ่งเมื่อเทียบกับ 16-bit โดยสูญเสียความแม่นยำเพียงเล็กน้อย

จุดที่มันโดดเด่น: ฝูงระดับ H100/H200/B200/GB200/GB300, ดาต้าเซ็นเตอร์ NVIDIA เท่านั้น, การปรับใช้ FP8/FP4, การให้บริการแบบหลายโหนด และ MoE ในระดับขนาดใหญ่ จุดที่มันอึดอัด: ความสะดวกในการพกพา AMD, Apple หรือ Intel; โมเดลทดลองที่เปลี่ยนแปลงเร็ว; การตั้งค่าในเครื่องขนาดเล็ก; และทีมที่ต้องการ "ทำงานได้ทุกที่"

คำตัดสิน: ถ้าคุณมุ่งมั่นกับ NVIDIA และสนใจประสิทธิภาพที่แท้จริง TensorRT-LLM อยู่ในรายการที่ควรเปรียบเทียบ คุณแลกความสะดวกในการพกพากับประสิทธิภาพ การปรับแต่งเฉพาะทางแต่มีฟีเจอร์น้อยกว่า

ส่วนที่เหลือของสนาม

TGI คือเซิร์ฟเวอร์โปรดักชันของ Hugging Face พร้อมการติดตาม, เมตริก, tensor parallelism และ continuous batching ใช้เมื่อการบูรณาการ HF และความเรียบง่ายมีความสำคัญ

MLC LLM คือเอนจินการปรับใช้สากลที่เน้นคอมไพเลอร์เป็นอันดับแรก พร้อม API ที่เข้ากันได้กับ OpenAI ผ่าน REST, Python, JavaScript, iOS และ Android เหมาะที่สุดสำหรับ "ส่ง LLM ไปทุกที่" โดยเฉพาะเบราว์เซอร์, มือถือ และแอปเนทีฟ

ONNX Runtime GenAI ใช้ลูป generative เต็มรูปแบบบน ONNX Runtime และขับเคลื่อน Foundry Local, Windows ML และ VS Code AI Toolkit รองรับ CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU และ AMD GPU เหมาะที่สุดสำหรับการปรับใช้แอปและเวิร์กโฟลว์ ONNX

OpenVINO GenAI คือเรื่องราวที่ปรับให้เหมาะสมสำหรับ Intel สำหรับ CPU Xeon, GPU Arc, Core Ultra และ NPU มีการให้บริการที่เข้ากันได้กับ OpenAI พร้อม continuous batching และ paged attention เหมาะที่สุดสำหรับฮาร์ดแวร์ Intel

LMDeploy คือชุดเครื่องมือที่เน้น CUDA พร้อม TurboMind สำหรับประสิทธิภาพและ PyTorch สำหรับการเข้าถึง น่าสนใจที่สุดสำหรับผู้ใช้ CUDA ที่ต้องการทางเลือกอื่นนอกเหนือจาก vLLM/SGLang/TensorRT-LLM

NVIDIA Dynamo คือเลเยอร์การประสานงานแบบกระจายที่อยู่เหนือเอนจินเช่น vLLM, SGLang และ TensorRT-LLM รองรับการแยกส่วน การกำหนดเส้นทางอัจฉริยะ และการแคช KV หลายระดับ ใช้เมื่อการให้บริการเอนจินเดี่ยวไม่เพียงพออีกต่อไป

หมายเหตุ: ห้ามใช้ Ollama

สูตรกลยุทธ์ฮาร์ดแวร์

เซิร์ฟเวอร์ CPU-only: llama.cpp ก่อน OpenVINO สำหรับ Intel Xeon ONNX Runtime GenAI สำหรับการปรับใช้แอป/ONNX

MacBook / Mac Studio: MLX / MLX-LM สำหรับเวิร์กโฟลว์เนทีฟของ Mac llama.cpp สำหรับความสะดวกในการพกพา GGUF

RTX 3090 / 4090 / 5090 ตัวเดียว: ExLlamaV2 สำหรับอินเฟอเรนซ์ในเครื่อง EXL2 llama.cpp สำหรับ GGUF หรือความสะดวกในการพกพา vLLM หากให้บริการผู้ใช้หลายคน

เครื่อง RTX สำหรับผู้บริโภคสองหรือสี่ตัว: ExLlamaV3 สำหรับอินเฟอเรนซ์ควอนไทซ์แบบหลาย GPU หรือ MoE vLLM หากพฤติกรรมการให้บริการมีความสำคัญ SGLang หากทดสอบการกำหนดเส้นทางหรือรูปแบบบริบทยาว

โหนด 8×H100 / H200: เริ่มต้นด้วย vLLM หรือ SGLang เปรียบเทียบ TensorRT-LLM หากใช้ NVIDIA เท่านั้นและประสิทธิภาพรับประกันการปรับแต่ง ใช้ Dynamo เมื่อการประสานงานแบบหลายโหนดจำเป็น

โครงสร้างพื้นฐานระดับ B200 / GB200 / GB300: เปรียบเทียบ TensorRT-LLM, SGLang และ vLLM เพิ่ม Dynamo สำหรับการประสานงานระดับฝูง, การกำหนดเส้นทางที่คำนึงถึง KV และการปรับขนาดอัตโนมัติ

AMD MI300 / MI325 / MI350 / MI355: เริ่มต้นด้วย vLLM หรือ SGLang บน ROCm หลีกเลี่ยงการสมมติว่าเกณฑ์มาตรฐานของ NVIDIA ถ่ายโอนอย่างราบรื่น

Intel Xeon / Core Ultra / Arc: OpenVINO GenAI หรือ OpenVINO Model Server ONNX Runtime GenAI หากการฝังแอปมีความสำคัญ

เบราว์เซอร์, มือถือ, แอปเนทีฟ: MLC LLM / WebLLM หรือ ONNX Runtime GenAI

การวัดประสิทธิภาพ: สิ่งที่ต้องวัด

เกณฑ์มาตรฐานที่ไม่ดี: "ฉันได้ 180 tok/s"

เกณฑ์มาตรฐานที่ดีประกอบด้วย:

โมเดล: โมเดลที่แน่นอน, สถาปัตยกรรม, จำนวนพารามิเตอร์, พารามิเตอร์ MoE ที่ทำงานอยู่

เวท: dtype, รูปแบบ quant, ขนาดกลุ่ม, การสอบเทียบ

เอนจิน: เวอร์ชัน, คอมมิต, แบ็กเอนด์, แฟล็ก

ฮาร์ดแวร์: SKU GPU, ความจุหน่วยความจำ, แบนด์วิดท์, อินเตอร์คอนเนกต์, CPU, RAM

เวิร์กโหลด: การกระจายความยาวอินพุต/เอาต์พุต, ความพร้อมกัน, การสตรีม, คำนำหน้าที่แชร์, structured output

เมตริก: TTFT, TPOT, เวลาแฝงแบบ end-to-end, p50/p95/p99, โทเค็นต่อวินาที, คำขอต่อวินาที, การใช้งานหน่วยความจำ GPU, อัตราการตี KV cache, ปริมาณงาน prefill, ปริมาณงาน decode, ต้นทุนต่อ 1M โทเค็น

กฎการวัดประสิทธิภาพ:

1. อย่าเปรียบเทียบเอนจินโดยใช้เฉพาะโทเค็นต่อวินาทีของผู้ใช้คนเดียว
2. ทดสอบการกระจายพรอมต์และเอาต์พุตจริงของคุณ
3. ทดสอบด้วยความพร้อมกันที่สมจริง
4. แยก prefill ออกจาก decode
5. ติดตาม p95 และ p99 ไม่ใช่แค่ค่าเฉลี่ย
6. วัดพื้นที่ว่างหน่วยความจำที่ความยาวบริบทเป้าหมาย
7. ทดสอบการนำแคชกลับมาใช้ใหม่หากแอปของคุณมีคำนำหน้าที่ซ้ำกัน
8. วัดประสิทธิภาพ structured output แยกต่างหาก ไวยากรณ์เพิ่มโอเวอร์เฮด
9. วัดประสิทธิภาพ LoRA และ multi-LoRA แยกต่างหาก
10. ทดสอบซ้ำหลังจากอัปเกรดไดรเวอร์, CUDA, ROCm, โมเดล หรือเอนจิน

ข้อผิดพลาดทั่วไป

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

การใช้ tensor parallelism บนอินเตอร์คอนเนกต์ที่อ่อนแอ หากไม่มี NVLink หรือ NVSwitch ให้ทดสอบ pipeline parallelism เอกสารของ vLLM ระบุสิ่งนี้สำหรับการตั้งค่าแบบ L40S

การละเว้น KV cache บริบทยาวและความพร้อมกันอาจทำให้ KV cache เป็นปัจจัยจำกัด PagedAttention, prefix caching, KV quantization และการแยกส่วนไม่ใช่ทางเลือกในระดับขนาดใหญ่

การปฏิบัติต่อเอนจินในเครื่องเป็นเซิร์ฟเวอร์โปรดักชัน เซิร์ฟเวอร์ llama.cpp มีความสามารถ เซิร์ฟเวอร์ MLX-LM สะดวก Ollama น่าใช้แต่ไม่ควรใช้

อย่างไรก็ตาม โปรดักชันหมายถึงความปลอดภัย การสังเกตการณ์ backpressure การกำหนดเส้นทาง การปรับขนาดอัตโนมัติ และพฤติกรรม SLA MLX-LM เองเตือนว่าเซิร์ฟเวอร์ของมันไม่แนะนำสำหรับโปรดักชัน

การสมมติว่ารูปแบบ quantization ทุกแบบสามารถพกพาได้ GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, รูปแบบ MLX และ ONNX ไม่สามารถใช้แทนกันได้ รูปแบบที่ถูกต้องคือรูปแบบที่เอนจินของคุณมีเคอร์เนลที่ปรับให้เหมาะสม

การละเว้นสถาปัตยกรรมโมเดล โมเดล Dense, MoE, attention แบบไฮบริด, โมเดล multimodal และตัวแปรบริบทยาวทำให้ส่วนต่างๆ ของเอนจินเกิดความเครียด การรองรับที่กว้างไม่ได้หมายความว่าการปรับให้เหมาะสมทุกอย่างทำงานได้เท่าเทียมกัน

การเชื่อถือแผนภูมิเกณฑ์มาตรฐานโดยไม่มีรูปร่างของเวิร์กโหลด แผนภูมิสำหรับ Llama 3.1 8B ที่อินพุต 1K / เอาต์พุต 128 บอกอะไรได้น้อยเกี่ยวกับตัวแทนเขียนโค้ดที่มีบริบท 80K ที่รันบน Qwen 3.6 27B / Gemma 4 26B-A4B หรือบริการ RAG ที่มีผู้ใช้พร้อมกัน 500 คน

แผนที่สุดท้ายที่ยึดหลักการ

ผู้ใช้ AI ในเครื่อง: LM Studio หรือ Harbor เพื่อความสะดวก llama.cpp เพื่อการควบคุม MLX บน Mac ExLlamaV2/V3 สำหรับประสิทธิภาพ CUDA ในเครื่อง

การสร้างตัวแทนในเครื่อง: อันไหนก็ใช้ได้ แต่จากสิ่งที่คนส่วนใหญ่ใช้ llama.cpp เพื่อความสะดวกในการพกพา MLX ถ้าผู้ใช้ใช้ Apple Silicon vLLM ถ้าจำลองการให้บริการโปรดักชันในเครื่อง

การให้บริการทีมภายใน: เริ่มต้นด้วย vLLM ใช้ SGLang ถ้า structured outputs, บริบทยาว, multi-LoRA, MoE หรือการกำหนดเส้นทางมีความสำคัญ

การให้บริการลูกค้าในระดับขนาดใหญ่: เปรียบเทียบ vLLM, SGLang และ TensorRT-LLM ถ้าการกำหนดเส้นทางและการแยกส่วนมีความสำคัญ SGLang และ Dynamo สมควรได้รับความสนใจ

ดาต้าเซ็นเตอร์ NVIDIA: TensorRT-LLM เพื่อประสิทธิภาพสูงสุด vLLM เพื่อความยืดหยุ่น SGLang สำหรับการให้บริการที่ซับซ้อน Dynamo สำหรับการประสานงานฝูง

Apple Silicon: MLX สำหรับการพัฒนาเนทีฟ llama.cpp สำหรับ GGUF หน่วยความจำแบบรวมคือพลังพิเศษด้านความจุที่มีข้อแลกเปลี่ยนแบนด์วิดท์ ไม่ใช่ HBM

Edge, แอป, เบราว์เซอร์ หรือ Windows เนทีฟ: llama.cpp, MLC LLM, ONNX Runtime GenAI หรือ OpenVINO ขึ้นอยู่กับสแตก

หลักการสุดท้าย

อินเฟอเรนซ์เอนจินมีผลกระทบ

เลือกเอนจินหลังจากตอบคำถามเหล่านี้:

1. ฉันมีฮาร์ดแวร์อะไรจริงๆ?
2. โมเดลพอดีกับหน่วยความจำเร็วหรือพอดีกับหน่วยความจำระบบ/หน่วยความจำรวมเท่านั้น?
3. decode หรือ prefill เป็นคอขวด?
4. ความยาวบริบทและความพร้อมกันใดที่สำคัญ?
5. พรอมต์ถูกแชร์มากพอสำหรับ prefix caching หรือไม่?
6. โมเดลเป็นแบบ dense, MoE, multimodal หรือไฮบริด?
7. ฉันต้องการความสะดวกในเครื่อง การให้บริการโปรดักชัน หรือการประสานงานฝูง?
8. รูปแบบ quantization ใดมีเคอร์เนลที่ปรับให้เหมาะสมบนเอนจินเป้าหมายของฉัน?
9. อินเตอร์คอนเนกต์ของฉันคือ PCIe, NVLink, NVSwitch, Ethernet, RDMA หรือ Thunderbolt?
10. ฉันกำลังปรับให้เหมาะสมกับเวลาแฝง ปริมาณงาน ต้นทุน ความเป็นส่วนตัว ความสะดวกในการพกพา หรือความเร็วของนักพัฒนาหรือไม่?

เอนจินจะเป็นไปตามคำตอบ

แล้วพบกันครั้งหน้า

-อาหมัด