Tinh chỉnh (Fine-Tuning) vs Kỹ thuật đặt câu lệnh (Prompt Engineering): Cẩm nang quyết định năm 2026

🇬🇧 Read the English version of this article on tanhdev.com

Trả lời nhanh (Answer-first): Hãy chọn kỹ thuật đặt câu lệnh (prompt engineering) cho việc thử nghiệm nhanh và các lĩnh vực chung. Triển khai RAG khi ứng dụng của bạn yêu cầu truy xuất thời gian thực từ một cơ sở tri thức được cập nhật thường xuyên. Chỉ áp dụng tinh chỉnh (fine-tuning) QLoRA khi bạn cần định dạng đầu ra nghiêm ngặt, tuân thủ phong cách nhất quán trước các đầu vào độc hại, hoặc cần nén lượng lớn token của câu lệnh.

Những gì bạn sẽ học được mà AI không nói cho bạn

• Ngưỡng so sánh chi phí-lợi ích thực tế giữa việc tinh chỉnh một mô hình 7B cục bộ so với việc gọi các API thương mại để tạo schema có cấu trúc.
• Cách cấu trúc prompt engineering để xử lý 95% nhận diện ý định thương mại điện tử, và ranh giới chính xác nơi tinh chỉnh bắt đầu có hiệu quả về mặt chi phí.

Ba kỹ sư trong cùng một nhóm đang tranh luận về việc xây dựng cùng một sản phẩm: một con bot (customer support assistant) trả lời khách hàng theo phong cách hỗ trợ khách hàng đặc thù của công ty, sử dụng các thuật ngữ lấy từ tài liệu hướng dẫn sản phẩm (product documentation). Một kỹ sư nói: “Chỉ cần viết một câu lệnh hệ thống (system prompt) tốt là xong”. Người khác lại tranh luận: “Chúng ta cần tinh chỉnh (fine-tune) lại mô hình”. Người cuối cùng phán: “Đây rõ ràng là một bài toán RAG rồi”.

Cả ba đều đúng một phần, nhưng cũng đều có điểm chưa chính xác tùy thuộc vào yêu cầu thực tế cụ thể. Khoảng cách giữa “prompt engineering”, “RAG”, và “fine-tuning” không chỉ nằm ở khía cạnh kỹ thuật — đó là sự khác biệt trong việc hiểu rõ mỗi phương pháp thực chất tác động vào phần nào của mô hình.

Bài viết này cung cấp một khung quyết định thực chiến dành cho kỹ sư AI. Chúng ta sẽ phân tích khi nào kỹ thuật đặt câu lệnh (prompt engineering) là đủ, khi nào việc tích hợp truy xuất thông tin (RAG) là lựa chọn kiến trúc tối ưu, và khi nào cần áp dụng tinh chỉnh (fine-tuning) bằng LoRA hoặc QLoRA — bao gồm cả bài toán chi phí của từng giải pháp. Các chi tiết triển khai cụ thể cho từng phương pháp được trình bày chi tiết trong Chuỗi tài liệu hướng dẫn SLM (SLM Playbook Series).

Câu hỏi cốt lõi: Tại sao kỹ thuật đặt câu lệnh thường thất bại trong môi trường thực tế (Production)

Kỹ thuật đặt câu lệnh thường là phương pháp đầu tiên được các kỹ sư lựa chọn, và điều đó hoàn toàn hợp lý: nó không yêu cầu thay đổi cơ sở hạ tầng, không cần chạy huấn luyện mô hình, và mang lại kết quả nhanh chóng chỉ trong vài phút. Tuy nhiên, phương pháp này thường thất bại một cách dễ đoán trong một số trường hợp cụ thể:

Sự lệch tông và phong cách phản hồi (Style and tone drift): Một câu lệnh hệ thống (system prompt) được tối ưu hóa có thể yêu cầu mô hình phản hồi một cách chính xác, ngắn gọn và chuyên nghiệp giống như một đội ngũ hỗ trợ doanh nghiệp. Tuy nhiên, trước các đầu vào độc hại (adversarial inputs), các câu hỏi mơ hồ (ambiguous queries), hoặc các cuộc hội thoại kéo dài (long conversations), mô hình sẽ có xu hướng dần quay trở lại phong cách mặc định được định hình qua quá trình huấn luyện RLHF (RLHF-trained default style). Các cuộc tấn công chèn câu lệnh (prompt injection attacks) cũng có thể dễ dàng vô hiệu hóa hoàn toàn các chỉ dẫn về phong cách phản hồi.

Thuật ngữ chuyên ngành và từ vựng đặc thù (Terminology and domain vocabulary): Nếu ứng dụng của bạn sử dụng các thuật ngữ đặc thù mà mô hình gốc chưa từng được tiếp cận (dữ liệu độc quyền, thuật ngữ nội bộ), một câu lệnh thông thường không thể giúp mô hình hiểu được ý nghĩa thực sự của chúng. Nó chỉ có thể cố gắng đưa các từ đó vào phản hồi, từ đó dẫn đến hiện tượng phản hồi sai lệch (hallucination) khi mô hình tự suy đoán ý nghĩa.

Khả năng tuân thủ định dạng đầu ra nhất quán (Consistent output format adherence): Yêu cầu mô hình “luôn phản hồi dưới dạng JSON hợp lệ chứa các trường {name, category, action}” có thể hoạt động tốt trong các bản thử nghiệm (demo) nhưng thường thất bại trước các đầu vào phức tạp hoặc các trường hợp biên (edge cases) trong môi trường thực tế (production). Bản chất mô hình chưa thực sự học được cấu trúc định dạng này — nó chỉ đang cố gắng tuân theo một chỉ dẫn, điều này thường xung đột với cơ chế dự đoán từ tiếp theo (next-token prediction) được thiết lập trong quá trình huấn luyện.

Hiệu quả kinh tế của cửa sổ bối cảnh (Context window economics): Khi bạn đưa quá nhiều chỉ dẫn hành vi vào câu lệnh hệ thống (system prompt), độ dài câu lệnh tăng lên khiến mỗi lượt gọi API trở nên tốn kém hơn. Một câu lệnh hệ thống dài 2.000 token chạy 1 triệu lượt mỗi ngày sẽ tiêu tốn ngân sách đáng kể, và chi phí này tăng tuyến tính theo số lượng yêu cầu.

Hiểu rõ các kịch bản thất bại này là bước khởi đầu quan trọng để lựa chọn giải pháp công nghệ phù hợp.

Hiểu rõ các phương pháp (Understanding the Spectrum): Prompting → RAG → Fine-Tuning → Huấn luyện tiền đề (Full Pre-Training)

Bốn phương pháp này nằm trên một dải phân loại dựa trên mức độ tác động và tính lâu dài của chúng:

graph LR
    P[Kỹ thuật đặt câu lệnh] -->|tác động| CTX[Bối cảnh tại thời điểm suy luận - Context at inference time]
    R[Tích hợp RAG] -->|tác động| CTX
    FT[Tinh chỉnh LoRA/QLoRA] -->|tác động| WEIGHTS[Trọng số mô hình - Model weights]
    PT[Huấn luyện tiền đề - Full Pre-Training] -->|tác động| WEIGHTS

    CTX -->|hiệu ứng| TEMP[Tạm thời - đặt lại sau mỗi yêu cầu]
    WEIGHTS -->|hiệu ứng| PERM[Lâu dài - tích hợp sẵn vào mô hình]

Kỹ thuật đặt câu lệnh và RAG hoạt động hoàn toàn tại thời điểm suy luận (inference time). Chúng điều chỉnh cửa sổ bối cảnh (context window) — lượng thông tin mà mô hình tiếp nhận khi tạo phản hồi. Trọng số gốc (weights) của mô hình không hề thay đổi và mỗi yêu cầu được xử lý độc lập từ đầu.

Tinh chỉnh (LoRA/QLoRA) tác động trực tiếp vào trọng số của mô hình — cụ thể là các ma trận phụ trợ (adapter matrices) được thêm vào các lớp chú ý (attention layers) đối với LoRA hoặc trên mô hình lượng tử hóa đối với QLoRA. Hành vi được huấn luyện đã được tích hợp trực tiếp vào mô hình, giúp duy trì sự nhất quán qua các yêu cầu mà không làm tăng chi phí quản lý cửa sổ bối cảnh.

Huấn luyện tiền đề (Full Pre-Training) xây dựng lại mô hình từ đầu trên một tập dữ liệu mới. Phương pháp này thường được các tổ chức lớn sử dụng để xây dựng các mô hình nền tảng chuyên biệt (ví dụ: mô hình LLM y tế được huấn luyện trên hồ sơ bệnh án). Quá trình này đòi hỏi tài nguyên tính toán cực kỳ lớn và nằm ngoài phạm vi của tài liệu hướng dẫn này.

Câu hỏi thực tế đối với hầu hết các đội ngũ kỹ sư là: Phương pháp nào trong ba phương pháp đầu tiên giải quyết được vấn đề cụ thể của họ với tổng chi phí thấp nhất?

Khi nào kỹ thuật đặt câu lệnh là lựa chọn tối ưu (và khi nào không)

✅ Hãy sử dụng kỹ thuật đặt câu lệnh khi:

• Mô hình đã có sẵn kiến thức nền tảng và thuật ngữ chuyên ngành (ví dụ: yêu cầu GPT-4 giải thích các khái niệm kiến trúc phần mềm chung).
• Bạn cần thử nghiệm và lặp lại nhanh chóng — thay đổi hành vi trong vài phút thay vì vài giờ hoặc vài ngày.
• Nhiệm vụ đủ đơn giản để mô tả đầy đủ trong vài trăm token.
• Bạn đang xây dựng bản thử nghiệm (prototype) hoặc đánh giá tính khả thi trước khi đầu tư vào giải pháp phức tạp hơn.

❌ KHÔNG phụ thuộc vào kỹ thuật đặt câu lệnh khi:

• Bạn yêu cầu tuân thủ định dạng đầu ra nhất quán ở quy mô lớn (>100.000 lượt yêu cầu/ngày).
• Lĩnh vực yêu cầu các thuật ngữ độc quyền hoặc kiến thức không có trong dữ liệu huấn luyện của mô hình gốc.
• Việc tuân thủ phong cách và tông giọng phản hồi là yêu cầu bắt buộc (chẳng hạn như trong các điều khoản hợp đồng hỗ trợ hoặc quy chuẩn thương hiệu).
• Người dùng có thể chèn các câu lệnh độc hại để phá vỡ câu lệnh hệ thống.

Đánh giá thực tế: Thử nghiệm giải pháp câu lệnh của bạn với 200 đầu vào biên phức tạp. Nếu tỷ lệ lỗi vượt quá ngưỡng chấp nhận được, chỉ riêng kỹ thuật đặt câu lệnh sẽ không đáp ứng được yêu cầu.

Khi nào RAG là giải pháp tối ưu: Truy xuất kiến thức so với Thay đổi hành vi (Knowledge Retrieval vs. Behavior Change)

RAG (Tích hợp truy xuất thông tin - Retrieval-Augmented Generation) là lựa chọn chính xác khi vấn đề cốt lõi nằm ở kiến thức (knowledge) chứ không phải hành vi (behavior).

Nếu mô hình của bạn cần trả lời chính xác về:

• Tài liệu kỹ thuật của sản phẩm (thay đổi thường xuyên).
• Quy định nội bộ, hướng dẫn nhân sự hoặc các quy tắc tuân thủ (compliance).
• Dữ liệu tài khoản khách hàng, lịch sử đơn hàng hoặc lịch sử hỗ trợ.
• Tin tức, nghiên cứu khoa học hoặc bất kỳ tập dữ liệu nào xuất hiện sau thời điểm giới hạn dữ liệu huấn luyện (training cutoff) của mô hình.

…thì tinh chỉnh (fine-tuning) là hướng đi không phù hợp. Tinh chỉnh lưu lại một trạng thái kiến thức tĩnh. Nếu tài liệu của bạn thay đổi hàng tháng, việc tinh chỉnh lại mô hình định kỳ sẽ rất tốn kém và dẫn đến vấn đề kiến thức bị lỗi thời (knowledge freshness problem).

RAG giải quyết vấn đề này bằng cách truy xuất các đoạn tài liệu liên quan tại thời điểm suy luận và đưa chúng vào cửa sổ bối cảnh:

graph LR
    Q[Câu hỏi người dùng] --> EMBED[Mô hình nhúng - Embedding Model]
    EMBED --> VS[Tìm kiếm Vector - pgvector / Pinecone]
    VS --> CHUNKS[Các đoạn tài liệu liên quan nhất]
    CHUNKS --> CONTEXT[Cửa sổ bối cảnh được mở rộng]
    Q --> CONTEXT
    CONTEXT --> LLM[LLM tạo câu trả lời]

✅ Sử dụng RAG khi:

• Cơ sở tri thức quá lớn (không thể đưa hết vào cửa sổ bối cảnh).
• Dữ liệu thay đổi thường xuyên (tài liệu cập nhật hàng tuần hoặc hàng tháng).
• Bạn cần trích dẫn nguồn gốc rõ ràng (mô hình có thể chỉ ra chính xác tài liệu tham khảo).
• Nhiệm vụ chính là truy xuất thông tin, không phải thay đổi hành vi của mô hình.

❌ KHÔNG sử dụng RAG khi:

• Vấn đề nằm ở cách mô hình định dạng hoặc phong cách tạo câu trả lời (RAG không thay đổi hành vi của mô hình).
• Chất lượng truy xuất thấp (dữ liệu đầu vào kém chất lượng sẽ tạo ra phản hồi kém — mô hình nhúng không tốt sẽ làm hỏng hệ thống RAG).
• Độ trễ là yếu tố cực kỳ quan trọng và bước truy xuất thông tin làm tăng độ trễ vượt mức cho phép.

Case Study: Bẫy ảo tưởng khi chọn RAG thay vì Fine-Tuning

Một đội ngũ nội bộ từng cố gắng tinh chỉnh một SLM bằng toàn bộ kho tài liệu kỹ thuật của công ty thay vì thiết lập một đường ống RAG. Khi người dùng đặt câu hỏi về các trường hợp biên, mô hình đã tự tạo ra (hallucinate) các tính năng giả lập vì cố gắng mã hóa kiến thức thực tế vào các trọng số tĩnh của nó.

• Mô hình chuẩn: Sử dụng RAG để lấy dữ liệu thô từ cơ sở dữ liệu vector ở thời gian chạy. Sử dụng tinh chỉnh (LoRA) để dạy mô hình cách cấu trúc, định dạng và lập luận dựa trên dữ liệu được truy xuất đó.

Một nhận định quan trọng: RAG và tinh chỉnh thường mang tính bổ trợ cho nhau (complementary) chứ không phải là hai giải pháp thay thế hoàn toàn. Một mô hình tinh chỉnh để định dạng chuẩn và hành xử đúng phong cách, kết hợp với RAG để truy xuất kiến thức, là một kiến trúc phổ biến trong môi trường thực tế.

Khi nào tinh chỉnh (LoRA/QLoRA) là lựa chọn tối ưu: Thay đổi hành vi và Phong cách phản hồi (Behavior and Style)

Tinh chỉnh thực sự thay đổi cách thức hoạt động của mô hình. Hãy áp dụng tinh chỉnh khi vấn đề không thể giải quyết bằng cách hướng dẫn mô hình (prompting) hoặc cung cấp thêm thông tin (RAG).

✅ Sử dụng tinh chỉnh khi:

1. Định dạng đầu ra nhất quán ở quy mô lớn (Consistent output format): Nếu mọi phản hồi bắt buộc phải tuân theo cấu trúc JSON, một schema XML cụ thể hoặc một định dạng log độc quyền — và phương pháp prompt thất bại ở các trường hợp biên — việc tinh chỉnh để mô hình tự động tạo ra định dạng đó sẽ loại bỏ các lỗi xử lý ở thời gian chạy.

2. Duy trì phong cách nhất quán trước các đầu vào độc hại (Style and tone): Một mô hình được tinh chỉnh sẽ lưu giữ phong cách trực tiếp trong trọng số của nó. Điều này giúp ngăn chặn việc người dùng cố ý ghi đè các chỉ dẫn hệ thống.

3. Từ vựng chuyên ngành mô hình gốc chưa biết (Domain vocabulary): Nếu lĩnh vực của bạn sử dụng các thuật ngữ không xuất hiện trong dữ liệu huấn luyện gốc của mô hình, việc tinh chỉnh trên một tập dữ liệu chuyên ngành sẽ giúp mô hình hiểu rõ nghĩa thực tế thay vì chỉ bắt chước bề nổi.

4. Giảm chi phí suy luận nhờ nén câu lệnh (Prompt compression): Nếu bạn tự vận hành một mô hình nhỏ (Llama 3, Mistral, Phi-3) và câu lệnh hệ thống dài hơn 2.000 token, việc tinh chỉnh trực tiếp các hành vi mong muốn vào mô hình giúp loại bỏ hầu hết các chi phí của câu lệnh hệ thống — giảm cả chi phí tài nguyên và độ trễ trên mỗi yêu cầu.

5. Căn chỉnh ưu tiên (Preference alignment): Điều chỉnh các xu hướng mặc định của mô hình (như độ dài câu trả lời, sự né tránh rủi ro) bằng các kỹ thuật như DPO (Direct Preference Optimization - Tối ưu hóa tùy chọn trực tiếp) yêu cầu phải tinh chỉnh. Kỹ thuật đặt câu lệnh thông thường khó có thể vượt qua các thiết lập mặc định của RLHF. Chi tiết triển khai được trình bày tại Kỳ 5: Căn chỉnh ưu tiên (Preference Alignment DPO, KTO, GRPO).

LoRA vs. QLoRA: Sự khác biệt thực tế (The Practical Difference)

LoRA (Low-Rank Adaptation) thêm các ma trận huấn luyện nhỏ (thường có rank từ 4 đến 64) vào các lớp chú ý (attention layers) của mô hình gốc đã đóng băng (frozen base model). Trong quá trình tinh chỉnh, chỉ có các ma trận bổ sung này được cập nhật, giữ nguyên các trọng số của mô hình gốc.

QLoRA áp dụng LoRA trên một phiên bản mô hình gốc đã được lượng tử hóa (quantized) (thường là lượng tử hóa 4-bit NF4). Phương pháp này giúp giảm đáng kể dung lượng bộ nhớ GPU (VRAM) cần thiết để chạy mô hình trong quá trình huấn luyện từ khoảng 80GB (với mô hình BFloat16 Llama 3 70B) xuống còn khoảng 20GB. Nhờ đó, các kỹ sư có thể tinh chỉnh các mô hình lớn trên các phần cứng phổ thông (như một GPU A100 đơn lẻ hoặc hai card RTX 4090 24GB).

Đánh đổi: Huấn luyện QLoRA sẽ chậm hơn một chút so với LoRA trên mô hình độ chính xác đầy đủ (full-precision) do chi phí nén/giải nén trọng số (quantization/dequantization overhead), và mô hình gốc được lượng tử hóa có thể cho ra kết quả có chất lượng kém hơn một chút ở các tác vụ lập luận phức tạp.

Đối với phần lớn các tác vụ tinh chỉnh trong thực tế (định dạng đầu ra, căn chỉnh phong cách, thuật ngữ chuyên ngành), QLoRA là lựa chọn tối ưu — sự khác biệt về chất lượng là không đáng kể trong khi tiết kiệm được rất nhiều chi phí hạ tầng. Các bước triển khai thực hành LoRA và QLoRA với các script huấn luyện, lựa chọn siêu tham số và đánh giá adapter được trình bày chi tiết tại Kỳ 3: Thực hành tinh chỉnh LoRA & QLoRA.

Bài toán kinh tế: So sánh Chi phí, Độ trễ và Bảo trì (Cost, Latency, and Maintenance Tradeoffs)

Chỉ số hiệu năng và chi phí trong môi trường thực tế (Tipping Points)

Đội ngũ kỹ sư của chúng tôi đã thực hiện các bài đo kiểm thực tế so sánh giữa việc gọi API đám mây của OpenAI (kèm theo câu lệnh few-shot phức tạp) và việc tự vận hành mô hình Llama-3 8B đã được tinh chỉnh. Kết quả chỉ ra các ngưỡng quyết định quan trọng trên hai phương diện:

1. Ngưỡng tối ưu về mặt chi phí tài chính

Khi bắt buộc mô hình tạo ra cấu trúc JSON phức tạp, kỹ thuật đặt câu lệnh đòi hỏi nhiều ví dụ minh họa (few-shot), làm phình to câu lệnh hệ thống.

• Quy mô thấp (<1.000 yêu cầu/ngày): Sử dụng GPT-4o qua API đám mây là tối ưu nhất vì không phát sinh chi phí vận hành hạ tầng cố định.
• Quy mô cao (>50.000 yêu cầu/ngày): Khi số lượng token đầu vào tăng cao (thường vượt quá 10.000 token trên mỗi yêu cầu), chi phí gọi API biến đổi tăng theo cấp số nhân. Việc tinh chỉnh một SLM cục bộ (ví dụ: Llama-3-8B) bằng QLoRA cho phép mô hình hiểu cấu trúc đầu ra một cách tự nhiên mà không cần các ví dụ few-shot. Điều này thu nhỏ kích thước câu lệnh và chuyển đổi chi phí biến đổi (theo token) thành chi phí cố định (cho tài nguyên tính toán chạy máy chủ).

2. Biểu đồ so sánh Độ trễ (TTFT) vs. Chi phí

Bảng dưới đây so sánh chi tiết thời gian phản hồi từ đầu vào đến token đầu tiên (TTFT) và chi phí vận hành thực tế cho các phương án triển khai:

Bẫy bảo trì trong tinh chỉnh (The maintenance trap in fine-tuning): Khi nhà cung cấp mô hình gốc ra mắt phiên bản mới (như GPT-4o Turbo, Llama 3.2, Mistral Nemo), các adapter được tinh chỉnh trên mô hình cũ sẽ không thể chuyển trực tiếp sang mô hình mới. Bạn bắt buộc phải chạy lại quy trình tinh chỉnh. Đối với các đội ngũ sử dụng API thương mại, điều này tạo ra một sự phụ thuộc chặt chẽ giữa hành vi vận hành thực tế của bạn và lộ trình cập nhật của nhà cung cấp.

Tự vận hành (Self-hosting) with vLLM (được đề cập ở phần tiếp theo) giúp bạn kiểm soát hoàn toàn tần suất cập nhật mô hình, tránh việc bị ép buộc tinh chỉnh lại.

Sa bàn quyết định: Khung thực chiến dành cho đội ngũ của bạn

Hãy duyệt qua cây quyết định dưới đây trước khi lựa chọn phương pháp triển khai:

Vấn đề liên quan đến KIẾN THỨC mà mô hình cần biết?
├─ Có → Kiến thức đó có thay đổi thường xuyên không?
│  ├─ Có → RAG
│  └─ Không → RAG hoặc Tinh chỉnh (nếu kho tri thức đủ nhỏ để huấn luyện)
└─ Không → Vấn đề liên quan đến CÁCH phản hồi của mô hình?
   ├─ Về ĐỊNH DẠNG hoặc PHONG CÁCH?
   │  ├─ Prompting có đảm bảo định dạng chuẩn trong hơn 99% trường hợp không?
   │  │  ├─ Có → Kỹ thuật đặt câu lệnh (kết hợp kiểm tra và phân tích cú pháp đầu ra)
   │  │  └─ Không → Tinh chỉnh (LoRA/QLoRA)
   ├─ Về TỪ VỰNG CHUYÊN NGÀNH?
   │  ├─ Từ vựng đó có sẵn trong dữ liệu huấn luyện của mô hình gốc không?
   │  │  ├─ Có → Kỹ thuật đặt câu lệnh (cung cấp định nghĩa trong bối cảnh)
   │  │  └─ Không → Tinh chỉnh trên tập dữ liệu chuyên ngành
   └─ Muốn GIẢM CHI PHÍ SUY LUẬN?
      ├─ Có → Tinh chỉnh để nén và giảm độ dài câu lệnh hệ thống
      └─ Không → Xem xét và đánh giá lại các yêu cầu

Tự vận hành với vLLM: Những thay đổi khi tinh chỉnh SLM riêng

Khi bạn tự tinh chỉnh một mô hình ngôn ngữ nhỏ (như Llama 3.1 8B, Phi-3 Mini, Mistral 7B) và tự vận hành nó bằng vLLM, bức tranh kỹ thuật sẽ thay đổi đáng kể so với việc sử dụng các API thương mại.

Tải động các LoRA Adapter trong vLLM

vLLM hỗ trợ phục vụ đồng thời nhiều adapter LoRA trên cùng một mô hình gốc. Một tiến trình vLLM tải mô hình gốc một lần duy nhất và hoán đổi động các adapter LoRA theo từng yêu cầu ở thời gian chạy:

vllm serve meta-llama/Llama-3.1-8B-Instruct \
    --enable-lora \
    --lora-modules \
      support-style=/models/adapters/support-v2 \
      legal-drafting=/models/adapters/legal-v1 \
    --max-lora-rank 64

Cơ chế này mở ra khả năng phục vụ đa khách hàng tinh chỉnh (multi-tenant fine-tuned serving) — nhiều nhóm phát triển có thể chia sẻ chung một cụm tài nguyên GPU, mỗi nhóm sở hữu các hành vi và phong cách phản hồi riêng biệt mà không cần khởi chạy các phiên bản mô hình gốc độc lập.

Lượng tử hóa và Hiệu năng suy luận

vLLM hỗ trợ vận hành các mô hình đã lượng tử hóa (như GGUF, AWQ, GPTQ) với hiệu năng suy luận giảm thiểu không đáng kể so với mô hình độ chính xác đầy đủ (full-precision). Một mô hình Llama 3.1 8B lượng tử hóa 4-bit AWQ có thể chạy mượt mà trên một GPU 24GB duy nhất, đạt tốc độ xử lý khoảng 500–800 token/giây with batch size bằng 1 — hoàn toàn đáp ứng được nhu cầu thực tế của hầu hết ứng dụng SLM.

Để tìm hiểu hướng dẫn triển khai vLLM toàn diện, bao gồm quản lý adapter LoRA và tự động co giãn (autoscaling) trên Kubernetes, vui lòng xem Kỳ 2: Vận hành vLLM & Tối ưu hóa suy luận. Việc triển khai các dịch vụ AI trong thực tế cũng đòi hỏi quy trình xác thực và kiểm soát phiên bản câu lệnh chặt chẽ — được trình bày tại OAuth 2.1 & Quản lý phiên bản Prompt cho Đại lý AI. Đối với các hệ thống đa đại lý tự động chạy bằng SLM tự vận hành, hãy xem Triển khai hệ thống Swarm AI trong thực tế: OpenClaw & LiteLLM.

Các câu hỏi thường gặp (FAQ)