Bạn không chọn inference engine trước. Bạn chọn chiến lược phần cứng, hình dạng khối lượng công việc và mô hình phục vụ trước. Engine sẽ theo sau.
Đó là cách hữu ích nhất để nghĩ về các LLM inference engine.
Ghi chú series: Đây là Phần 3 trong series của tôi về Self-hosted LLMs / Local AI.
- Phần 1: GPU Memory Math cho LLMs (Bản 2026).
- Phần 2: Memory Bandwidth cho Local AI Hardware (Bản 2026).
Hai phần đó giải thích về dung lượng phần cứng và toán học băng thông.
Phần này giải thích về lớp phần mềm biến phần cứng đó thành inference có thể sử dụng được.
Engines
Những công cụ này phục vụ các mục đích khác nhau / chiếm các lớp khác nhau
- Tính di động local
- CUDA tiêu dùng
- Quy trình làm việc bộ nhớ hợp nhất Apple
- Inference lượng tử hóa
- Phục vụ sản xuất
- Điều phối phân tán
- Thực thi trung tâm dữ liệu tối ưu hóa theo nhà cung cấp
Một mô hình tinh thần hữu ích:
Inference engine không phải là "mô hình." Nó là người điều khiển giao thông, quản lý bộ nhớ, bộ điều phối kernel, bộ lập lịch, kế toán bộ nhớ cache, bộ lập kế hoạch song song, bề mặt API, và đôi khi là khung triển khai.
Engine tốt nhất phù hợp với hệ thống phân cấp bộ nhớ, kết nối liên kết, định dạng lượng tử hóa, mục tiêu độ trễ và thông lượng, kiến trúc mô hình và mức độ trưởng thành vận hành của bạn.
Hướng dẫn quyết định một trang
- Laptop / edge / phần cứng kỳ lạ → llama.cpp
- Quy trình làm việc ưu tiên Mac → MLX / MLX-LM
- Inference local RTX đơn → ExLlamaV2
- 2-4+ GPU NVIDIA / CUDA → ExLlamaV3
- Phục vụ sản xuất tổng quát → vLLM
- Ngữ cảnh dài / MoE / định tuyến → SGLang
- Hiệu suất tối đa NVIDIA → TensorRT-LLM
- Điều phối cụm → NVIDIA Dynamo
Phần còn lại của hướng dẫn này giải thích lý do.
Inference engine thực sự làm gì
Một inference engine tải trọng số, token hóa đầu vào, chạy forward pass, lấy mẫu token, duy trì KV cache và phát trực tiếp kết quả. Các engine nghiêm túc cũng xử lý batching, lập lịch, prefix caching, lượng tử hóa, thực thi song song, phục vụ API, số liệu và thực thi phân tán.
Khối lượng công việc có hai giai đoạn:
Prefill đọc prompt và xây dựng KV cache ban đầu. Nó tốn nhiều tính toán.
Decode tạo ra từng token một, liên tục đọc trọng số và KV cache. Nó bị giới hạn bởi băng thông bộ nhớ. Tốc độ decode theo dõi băng thông bộ nhớ nhiều hơn là đỉnh tính toán.
Sự khác biệt đó giải thích hầu hết mọi thứ:
- Prompt ngắn, câu trả lời dài: decode chiếm ưu thế → băng thông bộ nhớ và batching quan trọng.
- Prompt dài, câu trả lời ngắn: prefill chiếm ưu thế → attention kernels và chunked prefill quan trọng.
- Nhiều người dùng: chất lượng bộ lập lịch quan trọng → continuous batching, cache paging, công bằng.
- Ngữ cảnh dài: KV cache chiếm ưu thế → paged attention, lượng tử hóa KV, offload.
- MoE: định tuyến chuyên gia chiếm ưu thế → expert parallelism, kết nối liên kết, grouped GEMMs.
- Đa nút: kết nối liên kết chiếm ưu thế → NVLink, RDMA, pipeline parallelism, phân tách.
PagedAttention giải quyết phân mảnh KV cache. FlashAttention sử dụng IO-aware tiling để giảm lưu lượng HBM (High Bandwidth Memory). Speculative decoding soạn thảo các token rẻ và xác minh chúng song song. Chủ đề lặp đi lặp lại: hiệu suất inference là di chuyển bộ nhớ cộng với lập lịch.
Các nút thắt thực sự
- Băng thông bộ nhớ, không chỉ dung lượng VRAM. VRAM quyết định khả năng chứa. Băng thông quyết định tốc độ decode. M3 Ultra của Apple cung cấp tới 819 GB/s băng thông bộ nhớ hợp nhất. H100 SXM của NVIDIA liệt kê 3.35 TB/s băng thông bộ nhớ GPU. Bộ nhớ hợp nhất cho phép bạn chứa các mô hình không vừa với VRAM tiêu dùng. HBM cho phép bạn phục vụ chúng nhanh hơn khi mô hình vừa vặn. Khả năng chứa không phải là tốc độ. Dung lượng không phải là băng thông.
- Sự tăng trưởng của KV cache. KV cache tăng lên cùng với kích thước batch và độ dài ngữ cảnh. Khối lượng công việc ngữ cảnh dài có thể hết bộ nhớ ngay cả khi trọng số vừa vặn. PagedAttention phân vùng KV cache thành các khối, tăng mức sử dụng và hỗ trợ các batch lớn hơn.
- Kết nối liên kết. Ngay khi mô hình vượt qua ranh giới GPU (đa GPU), bạn phải trả chi phí giao tiếp. Tensor parallelism cần các tập thể all-reduce thường xuyên. Pipeline parallelism giao tiếp tại ranh giới giai đoạn. Expert parallelism cần lưu lượng all-to-all cho MoE. Tài liệu của vLLM lưu ý rằng nếu không có NVLink, pipeline parallelism có thể vượt trội hơn tensor parallelism.
- Chất lượng bộ lập lịch. Một bộ lập lịch tốt quyết định yêu cầu nào vào batch, prefill và decode chia sẻ bộ tăng tốc như thế nào, liệu prompt dài có chặn decode ngắn hay không và cách tránh tình trạng đói tài nguyên. Hỗ trợ batching không giống như hoạt động như một bộ lập lịch sẵn sàng cho sản xuất.
- Chi phí runtime. CUDA graphs, kernel fusion, chi phí lấy mẫu, chi phí token hóa, chi phí HTTP, chuyển đổi LoRA và giải mã có cấu trúc đều quan trọng. Ở quy mô lớn, 2% chi phí khó chịu hợp thành một khối và đòi hỏi sự chú ý.
Các họ engine
Có bốn họ lớn:
Runtime di động local: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, các công cụ kiểu Ollama. Chúng quan tâm đến "làm cho nó chạy ở đây."
Runtime Apple/bộ nhớ hợp nhất: MLX và MLX-LM. Chúng quan tâm đến "sử dụng bộ nhớ dùng chung lớn và ngăn xếp của Apple tốt."
Engine lượng tử hóa CUDA tiêu dùng: ExLlamaV2 và ExLlamaV3. Chúng quan tâm đến "làm cho hộp 3090/4090/5090 của tôi gào thét với trọng số bit thấp."
Engine phục vụ sản xuất: vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. Chúng quan tâm đến người dùng đồng thời, KV cache, batching, song song, khả năng quan sát và chi phí mỗi token.
Sau đó là các lớp điều phối như Dynamo nằm trên các engine và điều phối cụm, prefill/decode phân tách, định tuyến và tự động mở rộng.
llama.cpp: vua về tính di động
llama.cpp là câu trả lời khi phần cứng kỳ lạ, hạn chế, ngoại tuyến, nặng về CPU, hướng đến edge hoặc không phải là một nút trung tâm dữ liệu NVIDIA gọn gàng.
Nó hỗ trợ Apple Silicon qua ARM NEON, Accelerate và Metal; x86 qua AVX/AVX2/AVX512/AMX; RISC-V; lượng tử hóa bit thấp; CUDA; AMD qua HIP; MUSA; Vulkan; SYCL; và offload kết hợp CPU+GPU. Đó là lý do tại sao llama.cpp chiếm lĩnh làn đường "chỉ cần làm cho nó chạy."
HTTP server có khả năng hơn một "trình chạy local đồ chơi." llama-server cung cấp các route tương thích OpenAI, tương thích Anthropic Messages API, xếp hạng lại, continuous batching, hỗ trợ đa phương thức, ràng buộc lược đồ JSON, gọi hàm, speculative decoding và giao diện web.
Hạn chế quan trọng: llama.cpp không dành cho phục vụ sản xuất đa nút nghiêm túc. Backend RPC của nó được ghi nhận rõ ràng là proof-of-concept, dễ vỡ và không an toàn.
Nhận định: Sử dụng llama.cpp khi tính di động, hoạt động ngoại tuyến, GGUF hoặc offload kết hợp quan trọng hơn phục vụ quy mô cụm.
KHÔNG sử dụng với Multi-GPUs
MLX và MLX-LM: vũ khí Apple Silicon
MLX là framework mảng của Apple cho Apple Silicon, và MLX-LM là gói LLM được xây dựng trên nó. Đây là ngăn xếp ML ưu tiên Mac.
Thực tế phần cứng chính là bộ nhớ hợp nhất. Apple Silicon cho CPU và GPU quyền truy cập trực tiếp vào cùng một nhóm bộ nhớ. Mảng MLX nằm trong bộ nhớ hợp nhất và bạn chọn thiết bị khi chạy thao tác thay vì di chuyển mảng giữa các không gian bộ nhớ riêng biệt.
Điều này thay đổi sự đánh đổi inference local. Trên hệ thống GPU rời rạc, câu hỏi là "nó có vừa với VRAM không?" Trên Mac dòng M có bộ nhớ hợp nhất lớn, câu hỏi trở thành "nó có vừa với bộ nhớ không và hệ thống bộ nhớ có thể cấp dữ liệu cho GPU đủ nhanh không?" Các mô hình lượng tử hóa lớn có thể vừa trên các máy mà cùng mô hình đó sẽ không thể trên GPU tiêu dùng 24 GB.
Tuy nhiên, nó cũng chậm hơn.
MLX-LM bổ sung tích hợp Hugging Face Hub, lượng tử hóa, tinh chỉnh LoRA và đầy đủ, inference phân tán và hệ sinh thái mô hình MLX Community lớn. MLX không còn chỉ dành cho Mac: nó cung cấp các gói CUDA và chỉ CPU cho Linux. Giao tiếp phân tán hỗ trợ MPI, Ring over TCP, JACCL cho RDMA qua Thunderbolt và NCCL cho CUDA.
Bản thân server của MLX-LM cảnh báo rằng nó không được khuyến nghị cho sản xuất vì chỉ thực hiện các kiểm tra bảo mật cơ bản.
Nhận định: Sử dụng MLX cho quy trình làm việc ML và LLM ưu tiên Mac. Đối với phục vụ công cộng có độ đồng thời cao, hãy bắt đầu với ngăn xếp phục vụ thực sự.
ExLlamaV2 và V3: CUDA tiêu dùng, tinh chỉnh và nhanh
ExLlamaV2 là engine lượng tử hóa CUDA local dành cho những người muốn GPU NVIDIA tiêu dùng hoạt động vượt trội so với sức mạnh của nó. Nó hỗ trợ paged attention, dynamic batching, prompt caching, khử trùng lặp KV cache, tạo hàng loạt, phát trực tiếp và speculative decoding. Từ cần nhớ là local. Nó làm cho các mô hình lượng tử hóa nhanh trên GPU CUDA hiện đại, đặc biệt là card tiêu dùng.
Phù hợp nhất: một hộp RTX 3090/4090/5090, trợ lý mã hóa local, chat local, mô hình lượng tử hóa EXL2 và sử dụng workstation chuyên nghiệp.
ExLlamaV3 mở rộng triết lý này sang inference đa GPU và MoE local. Nó bổ sung định dạng lượng tử hóa EXL3 dựa trên QTIP, tensor-parallel và expert-parallel linh hoạt cho phần cứng tiêu dùng, server tương thích OpenAI qua TabbyAPI, continuous dynamic batching và hỗ trợ đa phương thức.
V3 hấp dẫn khi bạn có 2-4+ GPU NVIDIA tiêu dùng hoặc muốn MoE local. Dự kiến có một số lưu ý: một số mô hình không hỗ trợ tensor hoặc expert parallelism trong ExLlamaV3.
Nhận định: ExLlamaV2 là engine CUDA local của người đam mê. ExLlamaV3 là biên giới cho thiết lập local đa GPU (2-4). Mong đợi các cạnh thô hơn để có khả năng tốt hơn.
vLLM: server mã nguồn mở sản xuất mặc định
vLLM là engine đầu tiên hầu hết các nhóm nên đánh giá để phục vụ LLM nguồn mở nghiêm túc.
Nó cung cấp quản lý bộ nhớ KV dựa trên PagedAttention, continuous batching, chunked prefill, prefix caching, CUDA/HIP graphs, lượng tử hóa mở rộng (FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ, AWQ, GGUF), attention và GEMM/MoE kernels được tối ưu hóa, speculative decoding, torch.compile và prefill/decode/encode phân tách.
Nó cũng linh hoạt: tensor/pipeline/data/expert/context parallelism, phát trực tiếp, đầu ra có cấu trúc, gọi công cụ, API tương thích OpenAI và Anthropic Messages, gRPC, multi-LoRA và hỗ trợ cho NVIDIA, AMD, CPU x86/ARM/PowerPC, cộng với plugin cho TPU, Gaudi, Ascend, Apple Silicon, v.v.
Tài liệu của vLLM lưu ý rằng các triển khai đa nút thường sử dụng Ray và nếu không có NVLink, pipeline parallelism có thể đánh bại tensor parallelism. Cái bẫy là cho rằng vLLM loại bỏ nhu cầu về tư duy hệ thống. Bạn vẫn cần điều chỉnh batching, độ dài ngữ cảnh, sử dụng bộ nhớ GPU, bố cục song song và định tuyến. vLLM cung cấp cho bạn một engine rất tốt; nó vẫn yêu cầu System Design tốt.
Nhận định: Nếu ai đó nói "chúng tôi cần phục vụ các mô hình mở trong sản xuất," vLLM là điểm khởi đầu mặc định.
SGLang: người anh em có tư duy hệ thống của vLLM
SGLang là thứ bạn sử dụng khi khối lượng công việc phục vụ xấu: đầu ra có cấu trúc, ngữ cảnh dài, MoE, phân tách và định tuyến.
Nó cung cấp prefix caching RadixAttention, phân tách prefill-decode, speculative decoding, continuous batching, paged attention, tensor/pipeline/expert/data parallelism, đầu ra có cấu trúc, chunked prefill và multi-LoRA batching. Nó hỗ trợ NVIDIA, AMD, Intel Xeon, Google TPU, Ascend NPU, v.v.
Sự khác biệt của SGLang là kiến trúc phục vụ. Tính năng phân tách prefill-decode của nó tách prefill tốn tính toán khỏi decode tốn bộ nhớ thành các phiên bản chuyên biệt, chuyển KV cache giữa chúng. Điều này ngăn các batch prefill dài làm gián đoạn decode và tăng đột biến độ trễ token.
Nhận định: SGLang dành cho các nhóm mà nút thắt không còn là "chúng ta có thể chạy mô hình không?" mà là "chúng ta có thể chạy nó dưới lưu lượng truy cập thù địch mà không làm tăng độ trễ, bộ nhớ và chi phí không?"
TensorRT-LLM: hiệu suất tối đa NVIDIA
TensorRT-LLM là ngăn xếp hiệu suất tối đa của NVIDIA. Nó được tối ưu hóa, chuyên biệt, mạnh mẽ và không giả vờ là di động.
Nó cung cấp Python API để xây dựng TensorRT engine với các tối ưu hóa tiên tiến nhất, cộng với runtime Python và C++. Nó bao gồm các kernel tùy chỉnh cho attention, GEMM và MoE; phân tách prefill-decode, Wide Expert Parallelism, speculative decoding; và Python API cấp cao tích hợp với NVIDIA Dynamo và Triton Inference Server.
GPU B200 có thể tải trọng số FP4 với kernel được tối ưu hóa. H100 trở lên hỗ trợ lượng tử hóa FP8 có thể tăng gấp đôi hiệu suất và giảm một nửa mức tiêu thụ bộ nhớ so với 16-bit với mất mát độ chính xác tối thiểu.
Nó tỏa sáng ở đâu: cụm H100/H200/B200/GB200/GB300-class, trung tâm dữ liệu chỉ NVIDIA, triển khai FP8/FP4, phục vụ đa nút và MoE ở quy mô lớn. Nó khó xử ở đâu: tính di động AMD, Apple hoặc Intel; các mô hình thử nghiệm thay đổi nhanh; thiết lập local nhỏ; và các nhóm cần "hoạt động trên mọi thứ."
Nhận định: Nếu bạn cam kết với NVIDIA và quan tâm đến hiệu suất tuyệt đối, TensorRT-LLM thuộc về cuộc cạnh tranh. Bạn đánh đổi tính di động để lấy hiệu suất. Chuyên môn hóa được điều chỉnh nhưng ít tính năng hơn.
Phần còn lại của lĩnh vực
TGI là server sản xuất của Hugging Face với tracing, số liệu, tensor parallelism và continuous batching. Sử dụng nó khi tích hợp HF và sự đơn giản quan trọng.
MLC LLM là engine triển khai phổ quát ưu tiên trình biên dịch với API tương thích OpenAI trên REST, Python, JavaScript, iOS và Android. Tốt nhất cho "gửi LLM đi khắp mọi nơi," đặc biệt là trình duyệt, thiết bị di động và ứng dụng gốc.
ONNX Runtime GenAI thực hiện vòng lặp tạo hoàn chỉnh trên ONNX Runtime và cung cấp năng lượng cho Foundry Local, Windows ML và VS Code AI Toolkit. Nó hỗ trợ CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU và AMD GPU. Tốt nhất cho triển khai ứng dụng và quy trình làm việc ONNX.
OpenVINO GenAI là câu chuyện tối ưu hóa Intel cho CPU Xeon, GPU Arc, Core Ultra và NPU. Nó cung cấp phục vụ tương thích OpenAI với continuous batching và paged attention. Tốt nhất cho phần cứng Intel.
LMDeploy là bộ công cụ tập trung vào CUDA với TurboMind cho hiệu suất và PyTorch cho khả năng tiếp cận. Thú vị nhất cho người dùng CUDA muốn một giải pháp thay thế cho vLLM/SGLang/TensorRT-LLM.
NVIDIA Dynamo là lớp điều phối phân tán bên trên các engine như vLLM, SGLang và TensorRT-LLM, hỗ trợ phân tách, định tuyến thông minh và KV caching đa tầng. Sử dụng nó khi phục vụ engine đơn không còn đủ.
Lưu ý: KHÔNG sử dụng Ollama.
Công thức chiến lược phần cứng
Máy chủ chỉ CPU: llama.pp trước tiên. OpenVINO cho Intel Xeon. ONNX Runtime GenAI cho triển khai ứng dụng/ONNX.
MacBook / Mac Studio: MLX / MLX-LM cho quy trình làm việc gốc Mac. llama.cpp cho tính di động GGUF.
RTX 3090 / 4090 / 5090 đơn: ExLlamaV2 cho inference local EXL2. llama.cpp cho GGUF hoặc tính di động. vLLM nếu phục vụ nhiều người dùng.
Hộp RTX tiêu dùng kép hoặc bốn: ExLlamaV3 cho inference lượng tử hóa đa GPU hoặc MoE. vLLM nếu hành vi phục vụ quan trọng. SGLang nếu kiểm tra định tuyến hoặc mẫu ngữ cảnh dài.
Nút 8×H100 / H200: Bắt đầu với vLLM hoặc SGLang. Benchmark TensorRT-LLM nếu chỉ NVIDIA và hiệu suất biện minh cho việc điều chỉnh. Sử dụng Dynamo khi điều phối đa nút trở nên cần thiết.
Cơ sở hạ tầng B200 / GB200 / GB300-class: Benchmark TensorRT-LLM, SGLang và vLLM. Thêm Dynamo để điều phối cấp cụm, định tuyến nhận biết KV và tự động mở rộng.
AMD MI300 / MI325 / MI350 / MI355: Bắt đầu với vLLM hoặc SGLang trên ROCm. Tránh giả định rằng điểm chuẩn NVIDIA chuyển giao sạch sẽ.
Intel Xeon / Core Ultra / Arc: OpenVINO GenAI hoặc OpenVINO Model Server. ONNX Runtime GenAI nếu nhúng ứng dụng quan trọng.
Trình duyệt, thiết bị di động, ứng dụng gốc: MLC LLM / WebLLM hoặc ONNX Runtime GenAI.
Benchmarking: đo lường gì
Benchmark tồi: "Tôi đạt 180 tok/s."
Benchmark tốt bao gồm:
Mô hình: mô hình chính xác, kiến trúc, số tham số, tham số MoE hoạt động.
Trọng số: dtype, định dạng lượng tử, kích thước nhóm, hiệu chuẩn.
Engine: phiên bản, commit, backend, cờ.
Phần cứng: GPU SKU, dung lượng bộ nhớ, băng thông, kết nối liên kết, CPU, RAM.
Khối lượng công việc: phân phối độ dài đầu vào/đầu ra, độ đồng thời, phát trực tiếp, tiền tố dùng chung, đầu ra có cấu trúc.
Số liệu: TTFT, TPOT, độ trễ đầu cuối, p50/p95/p99, token mỗi giây, yêu cầu mỗi giây, sử dụng bộ nhớ GPU, tỷ lệ truy cập KV cache, thông lượng prefill, thông lượng decode, chi phí mỗi 1M token.
Quy tắc Benchmarking:
- Không bao giờ so sánh engine chỉ bằng token mỗi giây của một người dùng.
- Kiểm tra phân phối prompt và đầu ra thực tế của bạn.
- Kiểm tra với độ đồng thời thực tế.
- Tách riêng prefill khỏi decode.
- Theo dõi p95 và p99, không chỉ trung bình.
- Đo lường khoảng trống bộ nhớ ở độ dài ngữ cảnh mục tiêu.
- Kiểm tra sử dụng lại cache nếu ứng dụng của bạn có tiền tố lặp lại.
- Benchmark đầu ra có cấu trúc riêng; ngữ pháp thêm chi phí.
- Benchmark LoRA và multi-LoRA riêng.
- Kiểm tra lại sau khi nâng cấp driver, CUDA, ROCm, mô hình hoặc engine.
Những sai lầm phổ biến
Chọn theo dung lượng VRAM đơn thuần. VRAM quyết định khả năng chứa. Băng thông và bộ lập lịch quyết định tốc độ. Một máy bộ nhớ hợp nhất lớn có thể chứa các mô hình khổng lồ, nhưng H100 giải mã nhanh hơn khi mô hình vừa vặn do băng thông HBM cao hơn nhiều.
Sử dụng tensor parallelism trên kết nối liên kết yếu. Nếu không có NVLink hoặc NVSwitch, hãy kiểm tra pipeline parallelism. Tài liệu của vLLM đề cập điều này cho các thiết lập giống L40S.
Bỏ qua KV cache. Ngữ cảnh dài và độ đồng thời có thể biến KV cache thành yếu tố giới hạn. PagedAttention, prefix caching, lượng tử hóa KV và phân tách không phải là tùy chọn ở quy mô lớn.
Coi các engine local là server sản xuất. llama.cpp server có khả năng. MLX-LM server thuận tiện. Ollama dễ chịu nhưng KHÔNG NÊN ĐƯỢC SỬ DỤNG.
Tuy nhiên, sản xuất có nghĩa là bảo mật, khả năng quan sát, backpressure, định tuyến, tự động mở rộng và hành vi SLA. Bản thân MLX-LM cảnh báo rằng server của nó không được khuyến nghị cho sản xuất.
Cho rằng mọi định dạng lượng tử hóa đều di động. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, định dạng MLX và ONNX không thể thay thế cho nhau. Định dạng đúng là định dạng mà engine của bạn có kernel được tối ưu hóa.
Bỏ qua kiến trúc mô hình. Mô hình dày đặc, MoE, attention kết hợp, mô hình đa phương thức và biến thể ngữ cảnh dài gây căng thẳng cho các phần khác nhau của engine. Hỗ trợ rộng rãi không có nghĩa là mọi tối ưu hóa đều hoạt động như nhau.
Tin tưởng vào biểu đồ benchmark mà không có hình dạng khối lượng công việc. Một biểu đồ cho Llama 3.1 8B ở đầu vào 1K / đầu ra 128 nói ít về một tác nhân mã hóa với ngữ cảnh 80K chạy trên Qwen 3.6 27B / Gemma 4 26B-A4B hoặc một dịch vụ RAG với 500 người dùng đồng thời.
Bản đồ cuối cùng mang tính chủ quan
Người dùng AI local: LM Studio hoặc Harbor cho sự tiện lợi. llama.cpp cho kiểm soát. MLX trên Mac. ExLlamaV2/V3 cho hiệu suất CUDA local.
Xây dựng tác nhân local: Bất kỳ cái nào cũng nên hoạt động, nhưng dựa trên những gì hầu hết mọi người sử dụng; llama.cpp cho tính di động. MLX nếu người dùng đang dùng Apple Silicon. vLLM nếu mô phỏng phục vụ sản xuất local.
Phục vụ một nhóm nội bộ: Bắt đầu với vLLM. Sử dụng SGLang nếu đầu ra có cấu trúc, ngữ cảnh dài, multi-LoRA, MoE hoặc định tuyến quan trọng.
Phục vụ khách hàng ở quy mô lớn: Benchmark vLLM, SGLang và TensorRT-LLM. Nếu định tuyến và phân tách quan trọng, SGLang và Dynamo đáng được chú ý.
Trung tâm dữ liệu NVIDIA: TensorRT-LLM cho hiệu suất tối đa. vLLM cho tính linh hoạt. SGLang cho phục vụ phức tạp. Dynamo để điều phối cụm.
Apple Silicon: MLX cho phát triển gốc. llama.cpp cho GGUF. Bộ nhớ hợp nhất là siêu năng lực dung lượng với sự đánh đổi băng thông, không phải HBM.
Edge, ứng dụng, trình duyệt hoặc gốc Windows: llama.cpp, MLC LLM, ONNX Runtime GenAI hoặc OpenVINO, tùy thuộc vào ngăn xếp.
Nguyên tắc cuối cùng
Inference Engines có hậu quả.
Chọn engine sau khi trả lời những câu hỏi này:
- Tôi thực sự có phần cứng gì?
- Mô hình có vừa với bộ nhớ nhanh không, hay chỉ vừa với bộ nhớ hệ thống/hợp nhất?
- Decode hay prefill là nút thắt?
- Độ dài ngữ cảnh và độ đồng thời nào quan trọng?
- Các prompt có đủ dùng chung cho prefix caching không?
- Mô hình là dày đặc, MoE, đa phương thức hay kết hợp?
- Tôi cần sự tiện lợi local, phục vụ sản xuất hay điều phối cụm?
- Định dạng lượng tử hóa nào có kernel được tối ưu hóa trên engine mục tiêu của tôi?
- Kết nối liên kết của tôi là PCIe, NVLink, NVSwitch, Ethernet, RDMA hay Thunderbolt?
- Tôi đang tối ưu hóa độ trễ, thông lượng, chi phí, quyền riêng tư, tính di động hay tốc độ nhà phát triển?
Engine theo sau các câu trả lời.
Hẹn gặp lại lần sau.
-Ahmad
