DPTCloud
Back to articles
Technology Insight

Tự Dựng Trạm Inference DeepSeek-R1-Distill-Llama-8B: Tối Ưu Hóa Tối Đa Trên VPS CPU AMD EPYC

May 30, 2026

Giới thiệu xu hướng dịch chuyển sang kiến trúc CPU Inference trong doanh nghiệp

Trong bối cảnh thị trường trí tuệ nhân tạo (AI) tăng trưởng bùng nổ, việc triển khai các mô hình ngôn ngữ lớn (LLM) như DeepSeek-R1-Distill-Llama-8B luôn đi kèm thách thức lớn về mặt chi phí hạ tầng. Phần lớn doanh nghiệp và kỹ sư phần mềm mặc định lựa chọn hệ thống máy chủ tích hợp GPU chuyên dụng từ NVIDIA để chạy các tác vụ sinh token (inference). Tuy nhiên, chi phí thuê máy chủ GPU liên tục duy trì ở mức đắt đỏ và tình trạng khan hiếm nguồn cung diện rộng khiến giải pháp này khó tiếp cận đối với các dự án vừa và nhỏ, hoặc các môi trường thử nghiệm (staging).

Thực tế công nghệ hiện nay đã thay đổi nhờ sự bứt phá của kiến trúc vi xử lý máy chủ hiện đại, tiêu biểu là dòng chip AMD EPYC™. Với mật độ lõi (core density) vượt trội, dung lượng bộ nhớ đệm L3 Cache khổng lồ và băng thông bộ nhớ RAM đa kênh (Multi-channel DDR4/DDR5), CPU AMD EPYC không còn đóng vai trò hỗ trợ điều phối mà hoàn toàn đủ khả năng vận hành như một thực thể xử lý tính toán độc lập cho mô hình AI. Bài viết này hướng dẫn chi tiết phương pháp thiết lập một trạm DeepSeek-R1-Distill-Llama-8B Inference Server tối ưu hóa chuyên sâu trên nền tảng VPS sử dụng CPU AMD EPYC, mang lại hiệu năng cao với mức ngân sách tối ưu nhất.

---

Tại sao AMD EPYC là lựa chọn tối ưu cho hạ tầng CPU Inference?

Để hiểu tại sao CPU AMD EPYC có thể gánh vác được khối lượng công việc tính toán ma trận của LLM, chúng ta cần phân tích các rào cản vật lý cốt lõi của tác vụ Inference. Khác với giai đoạn huấn luyện (Training) phụ thuộc nặng nề vào năng lực tính toán dấu phẩy động của GPU, giai đoạn Auto-regressive Decode (sinh từng token nối tiếp) của mô hình LLM bị giới hạn phần lớn bởi băng thông bộ nhớ (Memory Bandwidth Bound) chứ không hẳn là năng lực tính toán đơn thuần (Compute Bound).

Mỗi khi một token được tạo ra, toàn bộ trọng số (weights) của mô hình kích thước nhiều Gigabyte bắt buộc phải được nạp từ bộ nhớ RAM vào bộ xử lý trung tâm. Do đó, tốc độ đọc ghi của RAM chính là chiếc van cổ chai quyết định tốc độ sinh chữ (Tokens per second).

Các ưu thế phần cứng cốt lõi của AMD EPYC bao gồm:

  • Kiến trúc bộ nhớ đa kênh (8-Channel đến 12-Channel Memory): Cho phép đẩy băng thông bộ nhớ lên tới hàng trăm GB/s, vượt xa các dòng CPU thông thường dành cho máy tính để bàn hoặc các dòng chip máy chủ phân khúc thấp.
  • Dung lượng L3 Cache khổng lồ (Kiến trúc 3D V-Cache): Giúp lưu trữ các phần dữ liệu ma trận quan trọng và trạng thái hội thoại ngay sát nhân xử lý, hạn chế tối đa độ trễ khi phải truy xuất liên tục ra RAM ngoài.
  • Tập lệnh chuyên dụng tăng tốc AI: Hỗ trợ các tập lệnh vector tiên tiến bao gồm AVX2, AVX-512, và đặc biệt là AVX-512 VNNI (Vector Neural Network Instructions) giúp tăng tốc độ tính toán tích vô hướng trên các kiểu dữ liệu lượng hóa như INT8 hoặc INT4.
---

Chuẩn bị môi trường phần cứng và lựa chọn phiên bản định dạng GGUF phù hợp

Để xây dựng hệ thống hoạt động ổn định, bạn cần chuẩn bị cấu hình VPS đáp ứng tối thiểu các tiêu chí kỹ thuật sau:

  • CPU: Tối thiểu 4 đến 8 Cores chuyên dụng (Dedicated Cores) thuộc dòng AMD EPYC (thế hệ Rome, Milan hoặc Genoa).
  • RAM: Tối thiểu 16 GB RAM (DDR4 ECC hoặc DDR5). Tốc độ RAM càng cao, tốc độ sinh token càng nhanh.
  • Lưu trữ: Ổ cứng NVMe SSD trống ít nhất 20 GB để đảm bảo tốc độ nạp mô hình vào RAM diễn ra nhanh chóng dưới 15 giây.
  • Hệ điều hành: Ubuntu Server 22.04 LTS hoặc Ubuntu 24.04 LTS sạch.

Lựa chọn mức Lượng hóa (Quantization) cho DeepSeek-R1-8B

Mô hình nguyên bản ở định dạng BF16 yêu cầu gần 16 GB bộ nhớ chỉ để lưu trọng số, vượt quá khả năng xử lý mượt mà của một VPS tầm trung và gây nghẽn băng thông nghiêm trọng. Do đó, chúng ta bắt buộc phải sử dụng định dạng GGUF đi kèm kỹ thuật lượng hóa (Quantization). Dưới đây là bảng so sánh các tùy chọn để bạn đưa ra quyết định tối ưu giữa độ chính xác (Perplexity) và tốc độ (Speed):

Định dạng GGUF Dung lượng file RAM khuyến nghị Đánh giá hiệu năng trên AMD EPYC
Q4_K_M (4-bit) ~4.8 GB >= 8 GB Tốc độ sinh token nhanh nhất, độ suy giảm logic rất thấp. Khuyên dùng cho môi trường thương mại.
Q5_K_M (5-bit) ~5.5 GB >= 12 GB Cân bằng hoàn hảo giữa độ chính xác tư duy logic sâu và tốc độ xử lý của CPU.
Q8_0 (8-bit) ~8.5 GB >= 16 GB Giữ nguyên vẹn chất lượng mô hình gốc nhưng tốc độ sinh token sẽ giảm khoảng 30-40% trên CPU.

Khuyến nghị cho bài viết này: Chúng ta chọn phiên bản Q4_K_M để đạt hiệu năng sinh chuỗi văn bản tối đa trên kiến trúc CPU.

---

Quy trình triển khai và cấu hình tối ưu hóa sâu (Step-by-Step)

Chúng ta sẽ sử dụng công cụ Ollama làm backend chính vì công cụ này tích hợp sẵn lõi llama.cpp tối ưu cực tốt cho tập lệnh x86 và hỗ trợ cơ chế quản lý luồng tính toán linh hoạt.

Bước 1: Cập nhật hệ thống và cài đặt Ollama

Đầu tiên, truy cập vào VPS qua SSH và thực hiện cập nhật toàn bộ các gói thư viện cơ bản nhằm tránh xung đột mã nguồn:

sudo apt update && sudo apt upgrade -y
sudo apt install curl htop numactl -y

Tiến hành cài đặt Ollama thông qua kịch bản cài đặt tự động chính thức:

curl -fsSL [https://ollama.com/install.sh](https://ollama.com/install.sh) | sh

Bước 2: Tải mô hình DeepSeek-R1-Distill-Llama-8B tối ưu

Khởi chạy tiến trình tải trực tiếp phiên bản lượng hóa được tinh chỉnh sẵn từ thư viện của Ollama:

ollama run deepseek-r1:8b

Sau khi quá trình tải xuống hoàn tất, bạn có thể thử nghiệm gõ văn bản trực tiếp tại giao diện dòng lệnh để xác nhận mô hình hoạt động ổn định. Gõ /exit để thoát khỏi chế độ tương tác trực tiếp.

Bước 3: Cấu hình biến môi trường nâng cao nhằm ép xung hiệu năng phần cứng

Mặc định, Ollama tự động phát hiện số nhân của hệ thống, tuy nhiên trên kiến trúc đa luồng phức tạp như AMD EPYC, cơ chế tự động thường nhận diện sai hoặc phân bổ luồng không tối ưu dẫn đến hiện tượng nghẽn liên kết bộ nhớ NUMA (Non-Uniform Memory Access). Chúng ta cần can thiệp sâu bằng cách cấu hình file dịch vụ hệ thống systemd.

sudo systemctl edit ollama.service

Giao diện soạn thảo hiện ra, thêm chính xác các dòng cấu hình môi trường dưới đây vào giữa phần hệ thống chỉ định:

[Service]
Environment="OLLAMA_NUM_PARALLEL=2"
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OMP_NUM_THREADS=8"
Environment="OLLAMA_KV_CACHE_TYPE=q4_0"

Giải thích chi tiết các tham số tối ưu hóa chuyên sâu:

  • OLLAMA_NUM_PARALLEL=2: Cho phép máy chủ xử lý đồng thời 2 yêu cầu truy vấn cùng lúc mà không làm sụp đổ tốc độ sinh từ nhờ cơ chế chia sẻ bộ nhớ đệm thông minh.
  • OLLAMA_CONTEXT_LENGTH=8192: Mở rộng cửa sổ ngữ cảnh lên mức 8k tokens giúp mô hình lưu giữ luồng suy nghĩ tư duy dài (Chain-of-Thought) mà không bị mất dấu nội dung phía trước.
  • OMP_NUM_THREADS=8: Giới hạn số luồng tính toán song song bằng chính xác số nhân vật lý thực tế được cấp cho VPS (Ví dụ VPS có 8 Cores). Việc đặt quá số core vật lý (vượt sang Hyper-threading) sẽ gây phản tác dụng do xung đột tài nguyên L3 cache.
  • OLLAMA_KV_CACHE_TYPE=q4_0: Kỹ thuật nén bộ nhớ đệm Key-Value xuống định dạng 4-bit, giúp tiết kiệm bộ nhớ RAM cực lớn khi xử lý các đoạn văn bản đầu vào dài, đẩy nhanh tốc độ phản hồi từ đầu tiên (Time to First Token - TTFT).

Lưu lại cấu hình, sau đó tiến hành làm mới cấu trúc hệ thống và khởi động lại dịch vụ background:

sudo systemctl daemon-reload
sudo systemctl restart ollama
---

Kỹ thuật cô lập tài nguyên bộ nhớ bằng giải pháp NUMA Control (Nâng cao)

Đối với các dòng CPU có số lượng lõi siêu lớn như AMD EPYC, vi xử lý được chia nhỏ thành các phân vùng die silicon khác nhau gọi là NUMA Nodes. Nếu một luồng xử lý nằm ở Node 0 nhưng lại cố gắng truy cập dữ liệu RAM thuộc quyền quản lý của Node 1, độ trễ hệ thống sẽ tăng vọt, kéo tụt hiệu năng Inference.

Để giải quyết triệt để vấn đề này, doanh nghiệp nên vận hành tiến trình phục vụ AI thông qua lệnh điều phối bộ nhớ numactl. Thay vì khởi chạy dịch vụ mặc định, chúng ta liên kết tiến trình trực tiếp với vùng nhớ cục bộ có độ trễ thấp nhất:

numactl --interleave=all ollama serve

Cấu hình này ép hệ thống phân bổ đều các mảng dữ liệu trọng số lớn của DeepSeek-R1 qua toàn bộ các kênh bộ nhớ khả dụng, tối đa hóa tận gốc băng thông tổng thể của phần cứng AMD EPYC.

---

Đánh giá hiệu năng thực tế và những lưu ý vận hành thương mại

Sau khi áp dụng toàn bộ chuỗi tối ưu hóa trên một cấu hình VPS AMD EPYC chuẩn (8 Cores Milan, 16GB RAM DDR4), kết quả hiệu năng thực tế thu được vô cùng khả quan đối với một hệ thống không có GPU:

  • Tốc độ xử lý Prefill (Đọc hiểu Prompt đầu vào): Đạt mức ~25 - 35 tokens/giây.
  • Tốc độ xử lý Decode (Sinh chuỗi tư duy reasoning và trả lời): Duy trì ổn định ở mức ~12 - 18 tokens/giây.

Mức tốc độ này hoàn toàn đáp ứng tốt cho trải nghiệm đọc trực tiếp của con người (bởi tốc độ đọc trung bình của mắt người chỉ rơi vào khoảng 5-7 tokens/giây). Hệ thống hoàn toàn đủ sức phục vụ các tác vụ nội bộ như: Tóm tắt văn bản tài liệu dài, trích xuất dữ liệu hợp đồng kinh tế, hoặc vận hành các AI Chatbot chăm sóc khách hàng ở mức độ cơ bản.

Kết luận chiến lược

Tận dụng năng lực xử lý mạnh mẽ của dòng chip AMD EPYC phối hợp cùng các thuật toán lượng hóa GGUF hiện đại là phương án kiến trúc hạ tầng cực kỳ thông minh. Giải pháp này giúp loại bỏ hoàn toàn sự phụ thuộc vào các dòng GPU đắt đỏ, tối ưu hóa triệt để chi phí vận hành hàng tháng cho doanh nghiệp mà vẫn duy trì khả năng khai thác sức mạnh tư duy logic đỉnh cao của dòng mô hình DeepSeek-R1 danh tiếng.

Tự Dựng Trạm Inference DeepSeek-R1-Distill-Llama-8B: Tối Ưu Hóa Tối Đa Trên VPS CPU AMD EPYC | DPTCloud