Giới thiệu: Thách thức Inference LLM trên hạ tầng CPU

Trong kỷ nguyên bùng nổ của các mô hình ngôn ngữ lớn (LLM), DeepSeek-R1 và các phiên bản rút gọn (Distilled) của nó đã chứng minh được năng lực suy luận vượt trội, tiệm cận với các siêu mô hình hàng đầu hiện nay. Tuy nhiên, rào cản lớn nhất đối với các doanh nghiệp vừa và nhỏ khi triển khai các mô hình này chính là chi phí hạ tầng GPU vô cùng đắt đỏ.

Việc tận dụng hạ tầng VPS CPU AMD EPYC sẵn có hoặc tối ưu chi phí bằng CPU được xem là một chiến lược thông minh. Dù vậy, hiệu năng inference trên CPU mặc định thường gặp tình trạng nghẽn cổ chai (bottleneck) về băng thông bộ nhớ và năng lực tính toán xử lý ma trận số thực. Bài viết này sẽ đi sâu vào các giải pháp kỹ thuật chuyên sâu giúp doanh nghiệp tối ưu hóa cấu hình, tinh chỉnh runtime để nâng mốc Token/s (Tokens per second) lên mức tối đa trên vi xử lý AMD EPYC.

1. Hiểu rõ kiến trúc AMD EPYC và cơ chế nghẽn bộ nhớ (Memory Bandwidth)

Trước khi bắt tay vào cấu hình, chúng ta cần hiểu tại sao kiến trúc CPU lại gặp khó khăn với các tác vụ Autoregressive Generation của LLM. Khác với GPU sở hữu băng thông bộ nhớ lên tới hàng TB/s (như H100 hay A100), hệ thống CPU phụ thuộc vào các kênh RAM DDR4 hoặc DDR5.

Kiến trúc NUMA (Non-Uniform Memory Access): Các dòng vi xử lý AMD EPYC thường được chia thành nhiều chiplet (Core Complex Dies - CCD) kết nối thông qua Infinity Fabric. Mỗi nhóm nhân CPU sẽ có quyền truy cập ưu tiên vào một vùng nhớ RAM cụ thể. Nếu một thread chạy trên CCD 1 nhưng lại truy cập dữ liệu trọng số mô hình nằm ở vùng RAM thuộc quản lý của CCD 2, độ trễ (latency) sẽ tăng vọt, làm sụt giảm nghiêm trọng tốc độ tạo token.
Memory-Bound Task: Giai đoạn sinh từ (Generation Phase) của LLM yêu cầu nạp toàn bộ trọng số mô hình từ RAM vào bộ nhớ đệm (Cache) của CPU cho mỗi hệ số token được sinh ra. Do đó, tốc độ sinh từ bị giới hạn trực tiếp bởi băng thông RAM thay vì sức mạnh tính toán thuần túy của CPU.

2. Các bước chuẩn bị và lựa chọn phiên bản DeepSeek-R1 Distilled phù hợp

Để đạt được hiệu năng tối ưu trên VPS CPU AMD EPYC, việc lựa chọn đúng kích cỡ mô hình và định dạng lượng hóa (Quantization) là điều kiện tiên quyết.

Lựa chọn kích cỡ mô hình (Model Size)

Dòng DeepSeek-R1 Distilled có các phiên bản phổ biến dựa trên nền tảng Qwen hoặc Llama như 7B, 8B, 14B, và 32B. Đối với cấu hình VPS CPU tiêu chuẩn (thường từ 8 đến 32 vCPU), phiên bản DeepSeek-R1-Distilled-Qwen-8B hoặc 14B là điểm cân bằng hoàn hảo giữa độ chính xác và tốc độ xử lý.

Ứng dụng kỹ thuật Lượng hóa GGUF (Quantization)

Tuyệt đối không chạy mô hình ở định dạng FP16 gốc trên CPU. Hãy chuyển sang định dạng GGUF, vốn được tối ưu hóa đặc biệt cho CPU thông qua thư viện llama.cpp. Hãy ưu tiên chọn các mức lượng hóa sau:

Q4_K_M (4-bit): Mức tối ưu nhất cho hiệu năng. Giảm dung lượng mô hình xuống gần 4 lần, giúp giảm áp lực lên băng thông RAM, tăng tốc độ Token/s vượt trội trong khi độ suy giảm độ chính xác (perplexity) ở mức không đáng kể.
Q5_K_M (5-bit): Lựa chọn thay thế nếu ứng dụng của bạn đòi hỏi tính logic cực kỳ khắt khe, đánh đổi khoảng 10-15% tốc độ so với Q4.

3. Kỹ thuật cấu hình nâng cao trên Runtime (llama.cpp / Ollama)

Để hiện thực hóa sức mạnh của AMD EPYC, chúng ta cần can thiệp sâu vào các tham số vận hành của công cụ Inference (như llama.cpp hoặc bộ core của Ollama).

Tối ưu hóa số lượng Thread (-t hoặc --threads)

Quy tắc vàng: Không bao giờ thiết lập số lượng thread bằng tổng số vCPU của VPS nếu hệ thống có Hyper-Threading (SMT). Việc bật quá nhiều thread vượt quá số lượng nhân thực (Physical Cores) sẽ gây ra tình trạng tranh chấp tài nguyên bộ nhớ đệm L3 (L3 Cache Thrashing).

Công thức tối ưu cho AMD EPYC là thiết lập số thread bằng chính xác số lượng nhân thực thuộc cùng một nút NUMA, thường là bằng Tổng số vCPU / 2 (nếu VPS bật SMT) hoặc giới hạn ở mức tối đa từ 8 đến 16 threads tùy thuộc vào kiến trúc cache.

Ràng buộc tài nguyên với NUMA và Taskset

Để giải quyết triệt để bài toán độ trễ vùng nhớ như đã phân tích ở mục 1, bạn cần kích hoạt chế độ NUMA trong lệnh thực thi của llama.cpp bằng tham số --numa numactl. Sử dụng lệnh khởi chạy kết hợp công cụ của hệ điều hành Linux:

numactl --interleave=all llama-cli -m deepseek-r1-distilled-qwen-8b-Q4_K_M.gguf --threads 8 --ctx-size 4096 --numa

Cấu hình --interleave=all giúp phân bổ đều dữ liệu trọng số mô hình qua các kênh RAM, tận dụng tối đa băng thông tổng thể của hệ thống AMD EPYC đa kênh.

4. Tận dụng tập lệnh AVX2 và FMA

Các thế hệ CPU AMD EPYC (từ Zen 2 đến Zen 4, Zen 5) đều hỗ trợ mạnh mẽ các tập lệnh vector hóa như AVX2 (Advanced Vector Extensions) và FMA3. Các tập lệnh này cho phép CPU thực hiện nhiều phép tính nhân-cộng ma trận đồng thời trong một chu kỳ xung nhịp.

Khi biên dịch thư viện llama.cpp từ mã nguồn trên VPS của bạn, hãy đảm bảo rằng trình biên dịch đã tối ưu hóa riêng cho kiến trúc CPU hiện tại bằng cách sử dụng các flag tối ưu:

make Clean && LLAMA_NATIVE=1 make -j

Biến môi trường LLAMA_NATIVE=1 sẽ tự động phát hiện kiến trúc AMD EPYC của máy chủ ảo và bật toàn bộ các tập lệnh tối ưu hóa phần cứng cao nhất hiện có, giúp gia tăng từ 20% đến 40% hiệu suất xử lý ma trận so với bản build generic.

5. Tối ưu hóa bộ đệm ẩn KV Cache (Key-Value Cache)

Trong quá trình sinh từ, việc tính toán lại các token cũ là một sự lãng phí tài nguyên lớn. Tối ưu hóa cấu hình KV Cache giúp CPU tiết kiệm chu kỳ xử lý quý giá:

Giới hạn Context Window hợp lý: Chỉ cấu hình tham số --ctx-size ở mức vừa đủ cho nhu cầu sử dụng (ví dụ: 4096 thay vì để mặc định quá cao như 8192 hay 16384). Kích thước context càng lớn, KV cache chiếm dụng RAM càng nhiều, làm chậm tốc độ xử lý của CPU theo thời gian phản hồi.
Sử dụng FlashAttention (nếu có hỗ trợ): Đảm bảo kích hoạt flag --flash-attn trong các phiên bản phần mềm mới nhất để tối ưu hóa việc tính toán cơ chế Attention trực tiếp trên cấu trúc cache của CPU AMD.

Kết luận và Kết quả kỳ vọng

Bằng việc áp dụng đồng bộ các giải pháp từ lựa chọn định dạng lượng hóa GGUF Q4_K_M, tối ưu hóa số lượng Thread phù hợp với nhân thực, cấu hình phân bổ vùng nhớ NUMA, cho đến việc tận dụng tập lệnh AVX2 của vi xử lý AMD EPYC, doanh nghiệp hoàn toàn có thể đạt được mốc hiệu năng ấn tượng từ 15 đến 25 Token/s cho phiên bản DeepSeek-R1 Distilled 8B trên một cấu hình VPS CPU tầm trung.

Tốc độ này hoàn toàn đáp ứng tốt cho các tác vụ nội bộ như Chatbot chăm sóc khách hàng, Trợ lý ảo phân tích tài liệu, hoặc hệ thống phân loại dữ liệu tự động. Đây chính là giải pháp tối ưu hóa chi phí hạ tầng (TCO) bền vững nhất cho bài toán ứng dụng Trí tuệ nhân tạo vào vận hành doanh nghiệp hiện nay.

Tối ưu hóa Inference cho DeepSeek-R1 (Distilled) trên VPS CPU AMD EPYC: Kỹ thuật nâng mốc Token/s lên tối đa