Small Language Model vs Large Language Model: Khi Nào Model Nhỏ Lại Tốt Hơn?

Giả sử bạn đang xây một AI Agent cho hệ thống chăm sóc khách hàng. Một request của user có thể yêu cầu phân tích khiếu nại phức tạp, đối chiếu nhiều tài liệu rồi đề xuất phương án xử lý. Nhưng phần lớn request khác lại đơn giản hơn rất nhiều: xác định intent, lấy customer_id, chọn một trong 20 API, điền vài arguments rồi trả về JSON đúng schema.

Nếu dùng cùng một frontier model cho cả hai loại request, hệ thống chắc chắn dễ thiết kế hơn ở giai đoạn đầu. Chỉ cần một model, một prompt và một inference API. Nhưng khi traffic tăng từ vài nghìn lên vài triệu request mỗi tháng, câu hỏi bắt đầu thay đổi.

Bạn không còn chỉ hỏi:

“Model nào thông minh nhất?”

Mà phải hỏi:

“Request này thực sự cần bao nhiêu intelligence?”

Nếu 90% request chỉ cần một model đủ tốt để phân loại, extract fields hoặc chọn đúng function, việc trả chi phí cho frontier-level reasoning ở 100% request có thể là một quyết định kiến trúc không tối ưu.

Đó là điểm khiến cuộc tranh luận Small Language Model (SLM) vs Large Language Model (LLM) trở nên thú vị. Model nhỏ không nhất thiết phải đánh bại model lớn trên mọi benchmark. Nó chỉ cần giải quyết workload mà sản phẩm thực sự có đủ chính xác, nhanh và đáng tin cậy hơn xét trên toàn bộ hệ thống.

Đây cũng là thesis quan trọng nhất:

Model nhỏ không thắng model lớn bằng cách trở thành một phiên bản thu nhỏ của model lớn. Nó thắng bằng cách giải một bài toán nhỏ hơn, chuyên biệt hơn và phù hợp với constraints của production hơn.

Vì vậy, câu hỏi đúng cho AI Engineer không phải là “SLM hay LLM tốt hơn?”.

Câu hỏi đúng là:

Model nhỏ nhất nào vẫn đạt quality target của workload này?

1. Trước tiên: “Small Language Model” thực sự nhỏ đến mức nào?

Có một vấn đề ngay từ tên gọi: ngành AI hiện không có một ranh giới tuyệt đối kiểu:

SLM < 10B parameters
LLM ≥ 10B parameters

Một position paper về SLM cho agentic AI của các nhà nghiên cứu NVIDIA sử dụng mốc thực dụng khoảng dưới 10B parameters. Nhưng Microsoft vẫn gọi Phi-4, một model 14B parameters, là Small Language Model. Trong khi đó, các architecture mới còn khiến parameter count trở nên khó diễn giải hơn nữa.

Google chẳng hạn sử dụng khái niệm effective parameters cho các model Gemma 4 E2B và E4B. Chữ E biểu thị lượng parameters có ý nghĩa hơn với computational footprint của model thay vì đơn giản nhìn vào tổng số weights. Apple đi xa hơn với AFM 3 Core Advanced: model có khoảng 20B total parameters nhưng sử dụng sparse architecture và chỉ kích hoạt khoảng 1–4B parameters tùy request.

Điều này buộc chúng ta phải tách một số khái niệm vốn thường bị gom thành “model size”.

Với AI Engineer, cột cuối thường quan trọng nhất.

Một model 14B quantized có thể phù hợp với deployment hơn một model ít parameters hơn nhưng chạy ở precision cao và cần context cực dài. Tương tự, một sparse model có tổng parameter count lớn nhưng chỉ activate một phần weights trong mỗi request có computational profile hoàn toàn khác dense model cùng số parameters.

Vì vậy, trong bài này, SLM không nên được hiểu như một con số tuyệt đối. Cách hiểu hữu ích hơn là:

SLM là một language model được tối ưu để cung cấp đủ capability trong một compute và deployment budget nhỏ hơn đáng kể so với general-purpose frontier model.

Định nghĩa này sát hơn với cách chúng ta thực sự phải đưa ra quyết định trong production.

2. Nếu model lớn thường mạnh hơn, tại sao model nhỏ lại có cơ hội?

Trước khi nói về lợi thế của SLM, cần thừa nhận một điều quan trọng: model lớn thường có lợi thế về general capability.

Capacity lớn hơn cho phép model học và giữ lại nhiều statistical patterns hơn từ training distribution: kiến thức rộng hơn, nhiều long-tail concepts hơn, nhiều linguistic patterns hơn và khả năng xử lý những tình huống model chưa từng được optimize trực tiếp tốt hơn. Đây là một trong những lý do general-purpose LLM mạnh đặc biệt hữu ích cho open-ended reasoning, coding phức tạp, ambiguous instructions và những task khó dự đoán trước. Các nghiên cứu và technical reports về SLM cũng thường xem reasoning phức tạp là vùng mà model nhỏ vẫn cần model mạnh hơn hỗ trợ.

Nhưng có một bước suy luận sai rất phổ biến:

bigger model
    ↓
better benchmark
    ↓
better production system

Hai mũi tên này không phải lúc nào cũng đúng.

Một model general-purpose phải phân bổ capacity cho rất nhiều loại capability:

┌────────────────────────────────┐
│ Mathematics                    │
│ Programming                    │
│ Literature                     │
│ History                        │
│ Translation                    │
│ World knowledge                │
│ Open-ended reasoning           │
│ Conversation                   │
│ Tool calling      ← app dùng   │
│ Structured extraction ← app dùng│
└────────────────────────────────┘

Nhưng application của bạn có thể chỉ cần:

User request
     │
     ▼
Detect intent
     │
     ▼
Choose one of 20 functions
     │
     ▼
Extract 3–5 arguments
     │
     ▼
Return valid JSON

Phần lớn general capability của frontier model lúc này gần như không tham gia vào việc tạo business value.

Đây là nơi task distribution trở thành khái niệm quan trọng hơn parameter count.

Nếu output space rộng, instruction mơ hồ và task thay đổi liên tục, general capability rất có giá trị.

Nếu output space nhỏ, schema rõ và workload lặp lại hàng triệu lần, specialization bắt đầu có lợi thế.

Mental model: model lớn học thế giới, model nhỏ có thể học workflow

Hãy tưởng tượng hai nhân viên.

Người thứ nhất có kiến thức cực rộng và có thể xử lý gần như mọi câu hỏi mà khách hàng đưa ra.

Người thứ hai chỉ được đào tạo cho đúng một quy trình:

đọc ticket
→ nhận diện intent
→ lấy thông tin cần thiết
→ gọi đúng API
→ kiểm tra kết quả

Người thứ nhất rõ ràng “thông minh tổng quát” hơn.

Nhưng nếu công việc là thực hiện quy trình trên 500.000 lần mỗi ngày, nhân viên thứ hai có thể là lựa chọn vận hành tốt hơn.

SLM specialization hoạt động theo logic tương tự.

3. Model nhỏ không chỉ là model lớn bị cắt bớt

Một hiểu nhầm khác là xem SLM đơn giản như một LLM yếu hơn vì nó có ít parameters.

Thực tế, chất lượng của một model phụ thuộc vào nhiều thứ hơn parameter count:

Model quality
     │
     ├── Architecture
     ├── Training data
     ├── Number of training tokens
     ├── Synthetic data
     ├── Distillation
     ├── Post-training
     ├── Fine-tuning
     └── Inference techniques

Phi-4 là một ví dụ nổi tiếng cho hướng thiết kế này. Microsoft đặc biệt nhấn mạnh vai trò của high-quality và synthetic training data trong việc giúp dòng Phi đạt reasoning capability mạnh so với quy mô parameter của nó. Phi-4 và Phi-4-reasoning đều có khoảng 14B parameters nhưng được Microsoft định vị trong nhóm small language models.

Ở vùng nhỏ hơn nữa, MobileLLM cho thấy architecture optimization có thể cực kỳ quan trọng. Nghiên cứu này tập trung vào model 125M và 350M parameters, sử dụng thiết kế deep-and-thin, embedding sharing và Grouped Query Attention để cải thiện model trong resource budget rất nhỏ. Trong benchmark API calling của paper, MobileLLM đạt correctness gần Llama 2 7B trong setup thử nghiệm của tác giả.

Nói cách khác:

Ít parameters hơn không nhất thiết đồng nghĩa với việc cùng một architecture bị thu nhỏ một cách ngây thơ.

Một SLM tốt thường là kết quả của việc tối ưu đồng thời architecture, data và workload.

Knowledge distillation: dùng model lớn để tạo model nhỏ tốt hơn

Một pattern rất có giá trị khác là knowledge distillation.

Mental model đơn giản:

        Large Teacher Model
                │
                │ high-quality behavior
                ▼
        Training examples
                │
                ▼
        Small Student Model

Ý tưởng không phải là “copy toàn bộ knowledge” của teacher vào student. Điều đó bất khả thi nếu capacity chênh lệch lớn.

Thay vào đó, teacher giúp student học một distribution hẹp hơn hiệu quả hơn.

Trong production, điều này tạo ra một kiến trúc rất thú vị:

Expensive LLM
     │
     │ offline
     ▼
Generate / curate examples
     │
     ▼
Fine-tune SLM
     │
     ▼
SLM serves production traffic

Frontier LLM lúc đó được dùng ở nơi capability cao thực sự có leverage: tạo dữ liệu, gắn nhãn, bootstrap reasoning traces hoặc hỗ trợ các edge cases khó.

Nó không nhất thiết phải xử lý từng request của user.

Fine-tuning thay đổi câu hỏi “model nào mạnh hơn?”

Giả sử bạn so sánh:

3B generic model
vs.
70B generic model

Trong zero-shot task phức tạp, model 70B thường có lợi thế đáng kể.

Nhưng production comparison thực tế có thể là:

3B model
+ domain dataset
+ QLoRA
+ constrained output
+ validator

so với:

general-purpose large model
+ prompt

Đây là hai systems khác nhau, không còn là phép so parameter count trực tiếp.

Các kỹ thuật parameter-efficient fine-tuning như LoRA/QLoRA làm specialization này dễ tiếp cận hơn nhiều. QLoRA, chẳng hạn, giữ pretrained model ở dạng quantized 4-bit trong khi train các low-rank adapters, giúp giảm đáng kể memory requirement của quá trình adaptation.

Google hiện cũng cung cấp workflow QLoRA cho Gemma trên các task chuyên biệt như Text-to-SQL, cho thấy domain adaptation của small/open models đã trở thành một workflow triển khai thực tế thay vì chỉ là research technique.

4. Khi nào model nhỏ thực sự có lợi thế?

Điểm chung của những workload phù hợp với SLM không phải là chúng “dễ” theo nghĩa tuyệt đối.

Điểm chung là chúng bounded: phạm vi task, output hoặc hành vi mong muốn được giới hạn đủ rõ để model không cần toàn bộ general intelligence của frontier LLM.

4.1 Classification: khi output chỉ có vài lựa chọn

Ví dụ:

Customer ticket
      │
      ▼
┌─────────────┐
│    Model    │
└──────┬──────┘
       │
       ├── billing
       ├── refund
       ├── technical
       ├── account
       └── spam

Output space chỉ có năm classes.

Một frontier model có thể làm task này rất tốt. Nhưng câu hỏi production không phải “nó có làm tốt không?” mà là:

Có cần frontier model để làm tốt đến mức business yêu cầu không?

Nếu một SLM đạt 99,2% accuracy và model lớn đạt 99,4%, nhưng model nhỏ xử lý traffic rẻ hơn đáng kể, latency thấp hơn và dễ self-host hơn, 0,2% chênh lệch chưa chắc đủ lớn để biện minh cho việc dùng model lớn.

Ngược lại, nếu classification quyết định một hành động có hậu quả lớn, 0,2% đó có thể cực kỳ quan trọng.

Đây là lý do quality target phải đến trước model selection.

4.2 Information extraction: khi output có schema rõ

Ví dụ:

"Please ship three MacBooks to our Tokyo office."

Application không cần một bài luận.

Nó cần:

{
  "product": "MacBook",
  "quantity": 3,
  "location": "Tokyo"
}

Đây là workload hấp dẫn đối với model nhỏ vì output có thể được kiểm tra bằng software thông thường.

Input
  │
  ▼
SLM
  │
  ▼
Structured JSON
  │
  ▼
JSON Schema Validator
  │
  ├── valid ─────► continue
  │
  └── invalid ───► retry / fallback

Model không còn là thành phần duy nhất quyết định reliability.

Một phần reliability được chuyển sang deterministic software.

Đây là một engineering principle cực kỳ quan trọng:

Càng có thể externalize correctness khỏi model, bạn càng ít phụ thuộc vào raw model capability.

4.3 Function calling: sweet spot của specialized SLM

Function calling là một trong những ví dụ rõ nhất.

Google phát hành FunctionGemma như một biến thể chuyên biệt của Gemma 3 270M được tune cho function calling. Google cũng nói rõ model này không được thiết kế như một general conversational model; nó được xây để trở thành nền tảng cho những agent nhanh, private và local sau khi specialization thêm cho workload cụ thể.

Ví dụ:

"Turn off the bedroom lights."

Model chỉ cần biến request thành một representation dạng:

{
  "function": "set_light",
  "arguments": {
    "room": "bedroom",
    "state": "off"
  }
}

Để làm việc đó, model không cần khả năng viết tiểu thuyết, phân tích lịch sử hoặc giải một bài toán đại số khó.

Google thậm chí đã demo FunctionGemma thực hiện function calling trực tiếp trên thiết bị di động. Điều đáng chú ý ở đây không phải 270M là “đủ cho mọi agent”, mà là nó chứng minh rằng function calling chuyên biệt có thể nằm trong một capability envelope nhỏ hơn rất nhiều so với general assistant.

4.4 Agentic workloads: không phải node nào cũng cần frontier reasoning

Một AI Agent thực tế thường không thực hiện một inference duy nhất.

Nó có thể có pipeline như sau:

                    ┌─────────────┐
                    │   Planner   │
                    └──────┬──────┘
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
        Search query    Tool choice    DB request
             │             │             │
             ▼             ▼             ▼
        summarize       arguments      parse rows
             └─────────────┼─────────────┘
                           ▼
                       Final answer

Sai lầm phổ biến là đặt cùng một frontier model ở mọi node.

Trong thực tế, planner có thể cần reasoning mạnh, nhưng những bước như:

• intent routing;
• schema filling;
• entity extraction;
• format transformation;
• tool selection;
• short summarization;

có distribution hẹp hơn nhiều.

Position paper của các nhà nghiên cứu NVIDIA về SLM cho agentic AI lập luận chính xác theo hướng này: agent thường lặp đi lặp lại một số task chuyên biệt, vì vậy heterogeneous architecture — dùng model nhỏ cho các invocation phù hợp và model lớn khi cần general capability — có thể hợp lý hơn việc dùng LLM lớn ở mọi nơi.

4.5 On-device AI: lợi thế mà benchmark khó thể hiện

Có một nhóm use case mà SLM không chỉ “rẻ hơn”.

Nó mở ra architecture mà cloud-only LLM không thể thay thế trực tiếp:

User data
   │
   ▼
Local device
   │
   ▼
Local model
   │
   ▼
Result

Không có network round-trip tới inference server.

Điều này có thể mang lại:

• offline operation;
• giảm cloud traffic;
• dữ liệu nhạy cảm không cần rời thiết bị trong bước inference;
• marginal inference cost dễ dự đoán hơn;
• latency tương tác tốt trong những workload phù hợp.

Apple là ví dụ rõ ràng. Thế hệ 2025 có on-device foundation model khoảng 3B parameters và sử dụng các kỹ thuật như KV-cache sharing cùng quantization-aware training. Đến 2026, Apple giới thiệu AFM 3 Core Advanced 20B với sparse architecture chỉ kích hoạt khoảng 1–4B parameters tùy request.

Google cũng thiết kế nhiều variant Gemma hướng tới mobile và edge deployment, từ Gemma 3 1B đến Gemma 4 E2B/E4B.

Điểm cần nhớ là privacy không tự động được giải quyết chỉ vì model chạy local. Logging, analytics, storage, telemetry và các tool mà application gọi vẫn có thể làm dữ liệu rời thiết bị.

Lợi thế nằm ở việc local inference cho kiến trúc sư thêm một lựa chọn mà cloud inference không có.

5. Architecture mạnh nhất thường không phải “SLM hoặc LLM”

Nếu model nhỏ tốt cho bounded tasks còn model lớn tốt cho difficult/open-ended tasks, cách tự nhiên nhất không phải chọn một bên.

Hãy dùng cả hai.

Một production pattern rất hữu ích là:

                     Incoming request
                            │
                            ▼
                     ┌────────────┐
                     │   Router   │
                     └─────┬──────┘
                           │
                    normal request
                           │
                           ▼
                     ┌────────────┐
                     │    SLM     │
                     └─────┬──────┘
                           │
                           ▼
                     ┌────────────┐
                     │ Validator  │
                     └─────┬──────┘
                           │
                  valid / confident?
                     /           \
                   yes            no
                    │              │
                    ▼              ▼
                  DONE        ┌─────────┐
                              │   LLM   │
                              └─────────┘

Đây có thể gọi là:

SLM-first, LLM-on-demand.

Điều quan trọng nhất của architecture này không phải router.

Mà là validator.

Nếu hệ thống không biết khi nào SLM đang sai, model cascade chỉ đang tạo ra một pipeline rẻ hơn nhưng có thể âm thầm giảm quality.

Validator có thể dựa trên nhiều tín hiệu:

Schema validation
Business rules
Confidence model
Retrieval groundedness
Tool execution result
Consistency check
Secondary verifier

Ví dụ, với function calling:

result = small_model(request)

if (
    not schema_valid(result)
    or not function_allowed(result)
    or confidence(result) < THRESHOLD
):
    result = large_model(request)

return result

Code này rất đơn giản, nhưng nó biểu diễn một thay đổi kiến trúc lớn.

Thay vì hỏi:

Which single model should process everything?

hệ thống hỏi:

What is the cheapest reliable path
for this particular request?

Routing không chỉ là một heuristic

RouteLLM nghiên cứu chính xác vấn đề này: học một router để chọn giữa model mạnh nhưng đắt và model yếu nhưng rẻ hơn dựa trên request. Trong một số thiết lập benchmark của paper, các router giảm chi phí hơn 2× mà vẫn giữ target response quality. Đây không phải guarantee rằng mọi production workload cũng đạt con số tương tự, nhưng nó cho thấy routing có thể được xem như một optimization problem nghiêm túc thay vì vài if/else thủ công.

FrugalGPT trước đó cũng nghiên cứu model cascade, trong đó request được điều phối qua những model có cost/capability khác nhau để tối ưu quality-cost trade-off. Kết quả cụ thể của paper phụ thuộc các model và dataset tại thời điểm nghiên cứu, nhưng architecture principle vẫn rất quan trọng: không phải mọi query đều đáng trả cùng một inference budget.

6. Cost per token là metric quá đơn giản

Giả sử có hai model:

Model A
cost/request = 1.00
task success = 99%

Model B
cost/request = 0.10
task success = 90%

Có thể nói B rẻ hơn không?

Chưa chắc.

Nếu 10% request thất bại phải retry ba lần, cần human review hoặc cuối cùng vẫn gọi Model A, economics thay đổi hoàn toàn.

Một metric hữu ích hơn là:

Cost per Successful Task

Giả sử SLM có:

SLM inference cost = 0.10
fallback rate      = 15%
fallback LLM cost  = 1.00

Expected inference cost:

0.10 + 0.15 × 1.00
= 0.25

So với:

LLM for every request
= 1.00

SLM-first architecture vẫn rẻ hơn đáng kể.

Nhưng nếu fallback rate tăng tới 80%:

0.10 + 0.80 × 1.00
= 0.90

Lợi ích gần như biến mất, trong khi hệ thống lại phức tạp hơn.

Đó là lý do production benchmark phải đo toàn bộ pipeline, không phải isolated model call.

Cost thực tế còn rộng hơn token price

Đặc biệt khi self-host model, cost nên bao gồm:

GPU / accelerator
CPU
RAM
Storage
Electricity
Serving infrastructure
Autoscaling
Observability
Engineering time
Fine-tuning
Failed requests
Retries
Fallback traffic

Một application chỉ có 100 requests mỗi ngày hoàn toàn có thể rẻ hơn khi gọi managed frontier API thay vì duy trì GPU server riêng cho SLM.

Ngược lại, với hàng chục triệu requests mỗi tháng, inference economics có thể đảo ngược.

Vì vậy:

“SLM luôn rẻ hơn” cũng sai giống như “LLM luôn tốt hơn”.

7. Model nhỏ cũng không đảm bảo latency thấp

Một phép suy luận phổ biến khác là:

fewer parameters
    ↓
less compute
    ↓
lower latency

Ở level compute, điều này thường có cơ sở.

Nhưng latency mà user trải nghiệm là:

Total latency
 =
 network
 + queue
 + tokenization
 + prefill
 + generation
 + tool calls
 + post-processing

Một on-device SLM tránh được network latency nhưng chạy trên mobile NPU/GPU yếu hơn datacenter accelerator.

Ngược lại, một cloud model lớn có thể được phục vụ trên GPU mạnh với optimized kernels, batching và serving infrastructure hiệu quả.

Do đó production evaluation nên đo ít nhất:

Không thể suy ra những metric này chính xác chỉ từ parameter count.

Memory mới là nơi model size thể hiện rất rõ

Approximation đơn giản:

weight_memory
≈ parameters × bits_per_parameter

Nếu bỏ qua overhead:

Đây chỉ là weight memory.

Runtime còn phải chứa KV cache, activations, buffers và serving overhead.

Quantization vì vậy có thể thay đổi deployment envelope mạnh tới mức comparison:

8B vs 14B

không còn đủ ý nghĩa.

Phải so:

model architecture
+ precision
+ context length
+ KV cache
+ batch size
+ hardware
+ serving engine

Google chẳng hạn đã phát hành quantization-aware trained variants của Gemma để giảm mạnh memory footprint cho local deployment, còn QLoRA cho thấy quantization cũng có thể được kết hợp với parameter-efficient fine-tuning.

8. Khi nào bạn vẫn nên chọn model lớn?

Một bài về SLM rất dễ biến thành câu chuyện “small model đang thay thế LLM”.

Đó không phải kết luận đúng.

SLM có lợi nhất khi task distribution đủ bounded để specialization hoạt động.

Khi distribution mở rộng, advantage của general model quay trở lại.

Open-ended reasoning

Ví dụ:

Phân tích chiến lược của công ty, chỉ ra các assumption ẩn, so sánh năm phương án, mô hình hóa trade-off rồi đề xuất migration plan.

Ở đây không có một output space nhỏ.

Model phải hiểu nhiều loại concept, tự hình thành intermediate reasoning và xử lý những tình huống khó dự đoán trước.

General capability trở thành tài sản thực sự.

Ambiguous instructions

User có thể chỉ viết:

“Cái này không ổn, sửa giúp tôi.”

Một model phải infer:

• “cái này” là gì;
• “không ổn” ở khía cạnh nào;
• user đang kỳ vọng loại output nào;
• constraint nào quan trọng;
• có cần hỏi lại hay tự suy luận hay không.

Task càng ambiguous, specialization càng khó.

Long-horizon planning

Một agent có thể phải:

Plan
  ↓
Call tool
  ↓
Observe
  ↓
Reason
  ↓
Change plan
  ↓
Call another tool
  ↓
Recover from failure
  ↓
Continue

Error có thể tích lũy qua nhiều bước.

Một model chỉ mạnh ở tool selection hoặc schema filling chưa chắc đủ để giữ coherence qua toàn bộ trajectory.

Đây cũng là lý do heterogeneous architecture hợp lý: SLM xử lý các primitive operations, còn stronger model chịu trách nhiệm cho planning hoặc difficult escalation. Quan điểm này tương thích với kết luận của nghiên cứu về SLM trong agentic systems.

Novel và out-of-distribution tasks

Nếu production task thay đổi liên tục và bạn không thể dự đoán trước user sẽ hỏi gì, việc fine-tune một SLM cho từng distribution trở nên khó duy trì.

Frontier model lúc đó mua cho bạn một loại “capability insurance”: khả năng xử lý những vấn đề nằm ngoài các workflow đã được thiết kế trước.

Nó đắt hơn, nhưng đôi khi đó chính là thứ sản phẩm cần.

9. Đừng benchmark model; hãy benchmark hệ thống

Giả sử bạn đang chọn giữa bốn candidate:

Quality
  ▲
  │                            ● Large model
  │
  │                   ● Medium model
  │
  │             ● Tuned SLM
  │
  │        ● Tiny model
  │
  └────────────────────────────────────► Cost

Không có một model “tốt nhất” nếu không định nghĩa objective.

Nếu Large Model tốt hơn 1% nhưng tốn gấp 15 lần, lựa chọn phụ thuộc 1% đó đáng giá bao nhiêu đối với application.

Nếu Tuned SLM chỉ thấp hơn 0,2%, có latency tốt hơn và cho phép scale concurrency gấp nhiều lần trên cùng infrastructure, nó có thể nằm ở vị trí hấp dẫn hơn trên Pareto frontier.

Một model nằm trên Pareto frontier khi không tồn tại lựa chọn khác vừa:

cheaper
AND
better

cho workload đang xét.

Eval set phải đại diện cho production

Đây là nơi nhiều team chọn model sai.

Họ benchmark bằng:

MMLU
HumanEval
general reasoning benchmarks
leaderboard score

trong khi production task thực tế là:

customer message
→ choose API
→ emit schema-valid arguments

Public benchmark có thể hữu ích để hiểu capability chung, nhưng model selection cuối cùng nên dựa trên representative eval set của chính workload.

Với function calling, chẳng hạn, bạn có thể đo:

function selection accuracy
argument exact match
schema validity
execution success rate

Với extraction:

field precision
field recall
exact match
critical-field error rate

Với RAG:

answer correctness
retrieval groundedness
citation correctness
hallucination rate

Sau đó ghép quality với system metrics:

Bây giờ model selection mới trở thành engineering problem thay vì leaderboard contest.

10. Quy trình chọn SLM hay LLM cho production

Một workflow hợp lý có thể bắt đầu như sau:

Build representative eval set
             │
             ▼
Define minimum acceptable quality
             │
             ▼
Try smallest plausible model
             │
             ▼
Prompt + constrained outputs
             │
             ▼
Evaluate
             │
       ┌─────┴─────┐
       │ good enough?
       │
   yes ▼           ▼ no
Production      RAG / fine-tune
                    │
                    ▼
                 Evaluate
                    │
              still insufficient?
                    │
                    ▼
                Larger model

Điểm quan trọng nằm ở thứ tự.

Nhiều team làm ngược:

Choose strongest available model
           ↓
Launch
           ↓
Traffic grows
           ↓
Bill grows
           ↓
Try to optimize later

Architecture này dễ khởi đầu nhưng dễ tạo technical debt.

Cách tiếp cận tốt hơn là:

Scale model capability khi evaluation chứng minh bạn cần nó.

Không phải giảm model size bằng mọi giá.

Mà là tránh mua capability chưa có evidence rằng workload cần.

Bước 1 — Định nghĩa quality floor

Ví dụ:

function execution success ≥ 99.5%
critical argument error < 0.1%
schema validity ≥ 99.99%
p95 latency < 300 ms

Bây giờ “good enough” đã có nghĩa cụ thể.

Bước 2 — Thử model nhỏ nhất có vẻ hợp lý

Không nhất thiết bắt đầu từ 270M.

Nếu task cần moderate reasoning, candidate hợp lý có thể là 3B, 7B hoặc 14B.

“Smallest plausible” quan trọng hơn “smallest possible”.

Bước 3 — Thêm deterministic structure trước khi đổi model

Trước khi kết luận model quá yếu, hãy xem correctness có thể được externalize không:

JSON Schema
grammar-constrained decoding
validators
retrieval
calculator
database lookup
business rules

Nếu model đang phải tự “nhớ” điều mà database có thể trả chính xác, tăng parameter count chưa chắc là giải pháp tốt nhất.

Bước 4 — Specialize

Nếu distribution đủ ổn định:

prompt optimization
→ few-shot
→ RAG
→ LoRA / QLoRA
→ distillation

có thể tạo cải thiện đáng kể mà không cần nhảy ngay sang frontier model.

Bước 5 — Chỉ escalate những request khó

Cuối cùng, vẫn nên giữ escape hatch:

SLM
 │
 ├── confident + valid ──► DONE
 │
 └── uncertain ─────────► LLM

Điều này cho phép system giữ efficiency của SLM mà không tự giới hạn capability ceiling.

11. Insight quan trọng hơn cả SLM vs LLM: model capability không phải system capability

Đây có lẽ là mental model quan trọng nhất để mang sang các bài toán AI Engineering khác.

So sánh:

SYSTEM A

Huge general-purpose LLM

với:

SYSTEM B

Small specialized model
        +
Retriever
        +
Search
        +
Calculator
        +
Tools
        +
JSON Schema
        +
Validators
        +
Large-model fallback

Không có quy luật nào nói System A luôn đáng tin hơn chỉ vì base model mạnh hơn.

Trong một bounded workflow, System B có thể:

• đưa factual knowledge ra khỏi model qua retrieval;
• đưa arithmetic ra calculator;
• đưa state ra database;
• đưa output correctness vào schema;
• đưa permission vào policy layer;
• đưa difficult reasoning sang fallback model.

SLM lúc đó không còn phải làm mọi thứ.

Nó chỉ phải thực hiện phần language intelligence mà system giao cho nó.

Đây là sự khác biệt giữa model engineering và AI systems engineering.

Một model có thể yếu hơn nhưng hệ thống quanh nó mạnh hơn.

12. Tương lai có thể không còn là “Small vs Large”

Các architecture mới đã bắt đầu làm mờ chính câu hỏi mà bài này đặt ra.

Google dùng effective parameters cho một số Gemma 4 variants thay vì chỉ nói về raw parameter count. Apple AFM 3 Core Advanced có 20B parameters nhưng chỉ activate 1–4B tùy request. Những architecture này gợi ý một hướng phát triển rộng hơn: compute có thể trở thành resource được cấp phát linh hoạt theo độ khó của input thay vì cố định theo một model duy nhất.

Mental model tương lai có thể giống:

                       REQUEST
                          │
                          ▼
                 Estimate difficulty
                          │
            ┌─────────────┼─────────────┐
            ▼             ▼             ▼
        cheap compute  medium compute  expensive compute
            │             │             │
            ▼             ▼             ▼
        easy task      normal task    hard task

Ở level application, routing giữa SLM và LLM đã thực hiện một phiên bản thô của ý tưởng này.

Ở level model architecture, sparse activation và effective-parameter designs đưa optimization xuống sâu hơn bên trong model.

Vì vậy, câu hỏi dài hạn có thể không còn là:

“Small model hay large model?”

Mà là:

“Request này đáng được cấp bao nhiêu compute?”

Kết luận: đừng trả tiền cho intelligence mà request không cần

Quay lại hệ thống chăm sóc khách hàng ở đầu bài.

Một số request thực sự cần model mạnh: khiếu nại phức tạp, ambiguous intent, multi-document reasoning hoặc planning nhiều bước.

Nhưng nếu hàng triệu invocation khác chỉ là:

classify
extract
route
call function
validate JSON

thì việc chạy frontier LLM cho tất cả chúng không còn là một quyết định mặc định hiển nhiên.

SLM trở nên hấp dẫn khi workload có bốn đặc điểm:

1. Task đủ bounded để specialization có hiệu quả.
2. Correctness có thể được hỗ trợ bởi schema, validators, tools hoặc retrieval.
3. Volume đủ lớn để latency, memory và cost trở thành system constraint quan trọng.
4. Hệ thống có đường fallback khi model nhỏ không chắc chắn.

Ngược lại, model lớn vẫn có lợi thế rõ rệt khi workload đòi hỏi open-ended reasoning, broad knowledge, ambiguous instruction, long-horizon planning hoặc khả năng thích nghi với những request chưa biết trước.

Vì vậy, không có câu trả lời phổ quát cho:

“SLM hay LLM tốt hơn?”

Một AI Engineer nên hỏi:

Workload này cần bao nhiêu intelligence, và đâu là model nhỏ nhất có thể cung cấp lượng intelligence đó một cách đáng tin cậy?

Khi nhìn vấn đề theo cách này, model selection không còn là cuộc thi parameter count.

Nó trở thành bài toán tối ưu:

                 Quality
                    │
        ┌───────────┼───────────┐
        │           │           │
      Latency      Cost       Privacy
        │           │           │
        └───────────┼───────────┘
                    │
                 Reliability
                    │
                    ▼
           Production architecture

Và trong rất nhiều workload thực tế, kiến trúc tốt nhất có thể không phải:

Small
vs.
Large

mà là:

Small by default
       │
       ▼
Validate
       │
  ┌────┴────┐
  │         │
 valid    uncertain
  │         │
  ▼         ▼
DONE    Large model
        fallback

Dùng đúng lượng model capability cho đúng request.

Đó mới là optimization mà production AI thực sự cần.

Nguồn tham khảo

• Google AI for Developers — FunctionGemma model overview.
• Google Developers Blog — A Guide to Fine-Tuning FunctionGemma.
• Apple Machine Learning Research — Third Generation of Apple’s Foundation Models.
• NVIDIA researchers — Small Language Models are the Future of Agentic AI.
• Ong et al. — RouteLLM: Learning to Route LLMs with Preference Data.
• Liu et al. — MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases.
• Dettmers et al. — QLoRA: Efficient Finetuning of Quantized LLMs.
• Microsoft — Phi-4 / Phi-4-reasoning technical material.
• Google AI for Developers — Gemma 4 model overview.