Mục lục bài viết
Một startup đang xây AI assistant cho khách hàng. Trong giai đoạn prototype, team dùng một frontier model qua API. Chất lượng tốt, integration mất vài ngày, không có GPU nào cần quản lý và sản phẩm nhanh chóng chạy được với user thật.
Vài tháng sau, traffic tăng. Hóa đơn inference bắt đầu đáng kể. Một engineer đề xuất: “Chuyển sang open-source đi, model miễn phí mà.” Một engineer khác phản đối: “Không được, open-source yếu hơn frontier model.” Security team lại có câu hỏi khác: “Dữ liệu khách hàng có được gửi sang provider không?” Còn product team chỉ quan tâm một chuyện: nếu đổi model, chất lượng có giảm không?
Tất cả đều đang tranh luận về cùng một quyết định, nhưng thực ra họ đang nói về những vấn đề khác nhau.
Đó là lý do câu hỏi:
“Nên dùng open-source hay closed-source LLM?”
thường quá đơn giản để đưa ra một quyết định production tốt.
Cách nhìn hữu ích hơn là tách nó thành ba câu hỏi độc lập: model mở đến mức nào, inference được vận hành ở đâu, và team cần kiểm soát model sâu tới mức nào.
Một model có weights tải được không đồng nghĩa với một hệ thống AI “open-source” theo nghĩa đầy đủ. Một open-weight model không bắt buộc phải self-host. Và một proprietary model chạy qua API cũng không mặc nhiên có nghĩa dữ liệu của bạn được dùng để train model.
Quan trọng hơn, model mạnh nhất trên benchmark không nhất thiết là model tốt nhất cho sản phẩm của bạn.
Trong production, lựa chọn đúng thường là model hoặc architecture nhỏ nhất, rẻ nhất và đơn giản nhất vẫn vượt qua được quality bar, latency SLO, security requirement và legal requirement của workload.
Bài toán thực sự vì thế không phải:
OPEN
vs
CLOSED
mà gần hơn với:
Production Fit
Quality ───────────────┐
Latency ───────────────┤
Reliability ────────────┤
Cost ───────────────────┤
Security ───────────────┼──► Architecture phù hợp
Control ────────────────┤
Operability ────────────┤
Legal / License ────────┤
Customization ──────────┘
Đây là mental model chúng ta sẽ dùng xuyên suốt bài viết.
1. Trước tiên: “open-source LLM” thực ra đang nói về điều gì?
Trong cộng đồng AI, cụm từ “open-source model” thường được dùng rất rộng. Developer có thể gọi bất kỳ model nào tải weights về được là open-source.
Về mặt thực dụng điều đó dễ hiểu, nhưng khi đưa model vào production, sự khác biệt về terminology bắt đầu quan trọng.
Open Source Initiative định nghĩa Open Source AI dựa trên bốn quyền: use, study, modify và share. Để thực hiện được các quyền đó, chỉ có weights là chưa đủ; định nghĩa còn yêu cầu những thông tin cần thiết về training data, code dùng để train/run hệ thống và model parameters.
Vì vậy có thể hình dung một spectrum như sau:
MỨC ĐỘ MỞ / KIỂM SOÁT
Closed / Proprietary
│
│ Không có weights
│ Truy cập chủ yếu qua API
│
▼
Open-weight
│
│ Có thể tải weights
│ Có thể self-host
│ Thường có thể fine-tune
│
▼
Open-source AI
│
│ weights
│ training / inference code
│ data information
│ quyền use / study / modify / share
▼
Higher reproducibility
Điểm cần nhớ là:
Open-weight là một thuộc tính của model artifact. Self-host là một quyết định deployment. Hai thứ không giống nhau.
Một model open-weight có thể được chạy trên GPU của chính bạn, nhưng cũng có thể được deploy lên một managed inference platform. Ngược lại, việc một model được cung cấp qua API không nói lên toàn bộ cách provider vận hành model bên dưới.
License còn quan trọng hơn tên gọi
Ngay cả giữa các model có thể tải weights, quyền sử dụng cũng khác nhau đáng kể.
| Model family | Cách phân phối / license | Production implication |
|---|---|---|
| Qwen3 | Open-weight, Apache 2.0 | Khá permissive cho commercial deployment |
| DeepSeek-R1 | Code + weights theo MIT | Cho phép commercial use, modification và derivative works |
| Llama 4 | Llama 4 Community License | Có additional terms và commercial conditions |
| Gemma | Gemma Terms of Use | Cho phép nhiều hình thức sử dụng nhưng kèm conditions và prohibited-use terms |
Qwen hiện mô tả các open-weight model Qwen3 của mình là Apache 2.0. DeepSeek-R1 công bố repository và model weights theo MIT, đồng thời nêu rõ commercial use và derivative works được phép. Trong khi đó Llama 4 sử dụng Community License riêng, bao gồm các điều kiện redistribution và additional commercial terms; Gemma cũng sử dụng bộ Terms of Use riêng chứ không đơn giản là Apache/MIT.
Do đó:
Download được weights
≠
OSI Open Source
≠
Muốn dùng thế nào cũng được
🏗️ Production Note
License review nên nằm trong model-evaluation pipeline ngay từ đầu. Đừng đợi đến lúc đã fine-tune model, benchmark xong và chuẩn bị launch mới hỏi legal team xem có được deploy thương mại hay không.
2. Đừng chia thế giới thành hai lựa chọn: thực tế có ít nhất ba architecture
Nếu chỉ nhìn “open vs closed”, chúng ta bỏ mất một lựa chọn cực kỳ quan trọng: open-weight model chạy trên managed infrastructure.
Trong production, ba architecture phổ biến hơn là:
MODEL / INFRASTRUCTURE SPECTRUM
Closed API Managed Open Self-host Open
───────────── ─────────────── ─────────────────
Vendor owns You choose model You choose model
model + serving Provider runs GPU You run GPU
│ │ │
▼ ▼ ▼
Your App Your App Your App
│ │ │
▼ ▼ ▼
Vendor API Managed Endpoint Your Inference
Cluster
Mỗi architecture chuyển một phần responsibility khác nhau giữa team của bạn và provider.
Architecture A — Proprietary model qua API
Đây là cách đơn giản nhất:
┌─────────────────┐
│ Application │
└────────┬────────┘
│
▼
┌─────────────────┐
│ LLM Gateway │
└────────┬────────┘
│ HTTPS
▼
┌─────────────────┐
│ Model Provider │
└────────┬────────┘
│
▼
Response
Team không quản lý weights, GPU, CUDA runtime, model sharding, batching hay capacity planning.
Đó là một lợi thế khổng lồ khi mục tiêu là đưa product ra thị trường.
Một API call có thể thay thế hàng loạt vấn đề infrastructure:
result = llm.generate(
messages=messages,
response_schema=OrderExtraction,
)
Ẩn phía sau interface đơn giản đó là GPU provisioning, model loading, scheduling, batching, failure recovery và serving infrastructure mà provider vận hành thay bạn.
Vì vậy closed API đặc biệt hấp dẫn khi:
- product đang ở giai đoạn MVP;
- traffic chưa đoán được;
- team nhỏ;
- chưa có ML infrastructure expertise;
- workload cần frontier reasoning;
- tốc độ ship quan trọng hơn việc tối ưu từng phần trăm inference cost.
Điều bạn mua không chỉ là model.
Bạn đang mua cả operational simplicity.
Architecture B — Open-weight model trên managed inference
Đây là middle ground thường bị bỏ qua:
Open-weight Model
│
▼
Managed Infrastructure
│
┌────────────┼────────────┐
▼ ▼ ▼
GPU Scaling Monitoring
│
▼
API Endpoint
│
▼
Your App
Ví dụ, managed inference platforms có thể cho phép bạn chọn model repository, inference engine, hardware và scaling configuration trong khi platform xử lý phần lớn lifecycle của deployment. Hugging Face Inference Endpoints hiện hỗ trợ dedicated managed infrastructure, autoscaling, nhiều inference engines và private-networking options như PrivateLink trong các cấu hình phù hợp.
Bạn giữ được một số lợi thế của open-weight:
- chọn model;
- pin model revision;
- fine-tune model của riêng mình;
- thay đổi serving engine;
- giảm mức độ phụ thuộc vào một proprietary model API.
Nhưng chưa cần lập tức trở thành một GPU infrastructure company.
Với rất nhiều team, đây mới là điểm cân bằng hợp lý.
Architecture C — Self-host open-weight
Ở đầu còn lại của spectrum:
┌──────── GPU 1
│
User ├──────── GPU 2
│ │
▼ │
API Gateway ──► vLLM ──► Model
│
├──────── GPU 3
└──────── GPU N
Ở đây team kiểm soát gần như toàn bộ serving stack:
- exact model weights;
- tokenizer;
- quantization;
- inference engine;
- GPU topology;
- batching;
- parallelism;
- network;
- logging;
- autoscaling;
- deployment lifecycle;
- artifact versioning.
Các inference engine hiện đại như vLLM đã làm self-hosting thực tế hơn đáng kể. vLLM hiện hỗ trợ continuous batching, prefix caching, nhiều dạng quantization, structured outputs, tool calling, streaming và nhiều chiến lược distributed inference; nó cũng cung cấp OpenAI-compatible APIs.
Nhưng đừng nhầm:
Self-hosting dễ hơn trước
≠
Self-hosting đơn giản
Demo chạy được model và production vận hành model là hai bài toán khác nhau.
3. Production model selection phải bắt đầu bằng quality bar, không phải benchmark leaderboard
Giả sử một frontier model đạt score 97 trên evaluation của bạn.
Một model nhỏ hơn đạt 94.
Nếu requirement của product là:
minimum acceptable quality = 92
thì 3 điểm quality còn lại có thể không tạo thêm bất kỳ business value nào.
Trong khi đó model nhỏ có thể:
Quality 94
Cost ↓↓↓
Latency ↓↓
Throughput ↑↑
Operational fit ↑
Đây là một trong những nguyên tắc quan trọng nhất của production AI:
Đừng deploy model mạnh nhất bạn có quyền truy cập. Hãy deploy model nhỏ/rẻ nhất vượt qua được quality bar của workload.
Public benchmark vẫn hữu ích. Nó giúp shortlist candidate và biết model nào đáng thử.
Nhưng production benchmark phải đo task của bạn.
Một legal reasoning agent, customer-support classifier và information-extraction pipeline không cần cùng một capability profile.
Eval nên đứng trước model decision
Pipeline tốt hơn là:
Production Samples
│
▼
Eval Dataset
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
Model A Model B Model C
│ │ │
└───────────┼───────────┘
▼
Scorecard
Ví dụ một scorecard:
| Metric | Business weight |
|---|---|
| Task accuracy | 35% |
| Hallucination / factual errors | 15% |
| p95 latency | 15% |
| Cost per successful task | 15% |
| Structured-output validity | 10% |
| Tool-call correctness | 10% |
Sau đó:
Production Score
=
Σ(metric_score × business_weight)
Điều đặc biệt quan trọng ở đây là cost per successful task, không chỉ cost per token.
Giả sử:
Model A
cost/request = $0.01
success rate = 60%
Model B
cost/request = $0.015
success rate = 98%
Nếu request thất bại cần retry hoặc human review, Model A chưa chắc rẻ hơn.
Một model “cheap per token” nhưng thường xuyên:
- tạo JSON invalid;
- gọi sai tool;
- hallucinate;
- cần retry;
- tạo output dài không cần thiết;
có thể có effective cost cao hơn nhiều.
💡 Mental model
Benchmark công khai trả lời:
“Model này mạnh đến đâu nói chung?”
Production eval trả lời:
“Model này có hoàn thành công việc mà sản phẩm của tôi cần với cost và reliability chấp nhận được không?”
Câu thứ hai mới quyết định architecture.
4. Economics: vì sao “open-source rẻ hơn API” không phải một định luật
Đây là nơi nhiều so sánh bị sai ngay từ đầu.
Closed API thường có cost model gần với:
API Cost
=
Input Tokens × Input Price
+
Output Tokens × Output Price
+
Feature / Tool Costs
Traffic ít đi thì inference cost thường giảm theo.
Self-host thì khác:
Self-host TCO
=
GPU Hours
+ CPU / RAM
+ Storage
+ Networking
+ Redundancy
+ Monitoring
+ Idle Capacity
+ Engineering
+ Operations
GPU không quan tâm hôm nay user có dùng app của bạn hay không.
Nếu GPU đang chạy, bạn vẫn trả tiền.
Utilization mới là biến số quan trọng
Hãy tưởng tượng GPU có khả năng cung cấp:
Capacity
████████████████████ 100%
Actual workload
████░░░░░░░░░░░░░░░ 20%
Nếu utilization chỉ ở khoảng 20%, phần lớn capacity bạn trả tiền đang nhàn rỗi.
Một workload có 10 triệu requests/tháng chưa chắc self-host hiệu quả nếu traffic cực kỳ bursty.
Ngược lại, một workload ít “hào nhoáng” hơn nhưng chạy batch processing đều đặn 24/7 có thể tận dụng GPU rất tốt.
So sánh hai sản phẩm.
Product A — traffic bursty
00:00 ██
06:00 █
09:00 ███████████████
12:00 ███
18:00 ████████████████████
23:00 ██
Bạn phải provision capacity cho peak.
Nhưng phần lớn ngày GPU có thể không được sử dụng hết.
API provider hấp thụ bài toán multiplexing traffic từ rất nhiều customer khác nhau. Đây chính là một phần giá trị bạn đang trả tiền.
Product B — traffic lớn và ổn định
00:00 ███████████████
06:00 ███████████████
12:00 ███████████████
18:00 ███████████████
23:00 ███████████████
Nếu request đủ nhiều và predictable, GPU có thể chạy gần capacity trong phần lớn thời gian.
Economics của self-host lúc đó thay đổi hoàn toàn.
Vì vậy:
High volume chưa đủ. Self-host hấp dẫn nhất khi high volume đi cùng predictable traffic và utilization tốt.
Continuous batching là lý do inference engineering ảnh hưởng trực tiếp đến cost
Giả sử ba requests tới gần nhau:
R1 ███████████
R2 ████████████
R3 ████████
Nếu xử lý theo kiểu tuần tự:
GPU
R1 ███████████
R2 ████████████
R3 ████████
GPU không được tận dụng tối đa.
Một serving engine có continuous batching có thể đưa request mới vào execution scheduling trong khi các request khác đang decode, nhờ đó tăng mức độ sử dụng accelerator. vLLM liệt kê continuous batching là một trong các cơ chế cốt lõi của serving stack hiện tại.
Điều này dẫn đến một kết luận quan trọng:
Open model cost
≠
GPU list price
Cost thực tế phụ thuộc vào:
model architecture
×
quantization
×
batching
×
context length
×
output length
×
concurrency
×
KV-cache behavior
×
parallelism
×
traffic distribution
Cách nghĩ về break-even
Đừng hỏi:
“GPU này bao nhiêu tiền một giờ?”
Hãy hỏi:
effective self-host cost
per successful production request
và so sánh với:
effective API cost
per successful production request
Một phiên bản simplified:
Self-host cost/month
=
fixed compute
+ autoscaled compute
+ idle capacity
+ redundancy
+ infra
+ engineering
+ operations
Break-even chỉ thực sự xuất hiện khi:
API Cost
>
Self-host Total Cost of Ownership
trong một khoảng thời gian đủ dài để bù cả migration và operational complexity.
🔬 Deep Dive — Vì sao scale-to-zero không hoàn toàn biến GPU thành serverless
Managed inference platforms có thể scale model endpoint xuống zero khi idle, giúp giảm đáng kể waste cho workload không liên tục. Tuy nhiên model lớn cần thời gian download/load weights và initialize accelerator khi scale trở lại; Hugging Face cũng cảnh báo scale-to-zero tạo cold start và có thể không phù hợp với application cần response ngay lập tức.
Vì vậy bạn vẫn đang trade:
Lower idle cost
↕
Higher cold-start latency
Không có architecture nào loại bỏ trade-off; nó chỉ di chuyển trade-off sang nơi khác.
5. Open-weight thắng lớn nhất ở control — không nhất thiết ở intelligence hay cost
Một lợi thế thực sự khó thay thế của open-weight là quyền kiểm soát artifact.
Bạn có thể freeze:
Model weights
+
Tokenizer
+
Inference engine
+
Quantization
+
Prompt
+
Safety layer
+
Eval set
thành một release:
AI Release 2026.08
Điều này đặc biệt có giá trị trong những hệ thống cần reproducibility, validation hoặc audit nghiêm ngặt.
Với proprietary API, provider kiểm soát model lifecycle. Ngay cả khi API surface tương thích, prompting behavior giữa model snapshots vẫn có thể thay đổi. OpenAI chẳng hạn khuyến nghị pin model versions và chạy evals để kiểm soát sự thay đổi hành vi giữa snapshots.
Đó là lý do vendor lock-in trong AI không chỉ là:
Price lock-in
Nó còn có thể là:
Prompt behavior
Tool calling
Structured output
Reasoning behavior
Safety behavior
Latency profile
Evaluation assumptions
Một model khác nhận cùng request schema chưa chắc xử lý task giống nhau.
API-compatible không đồng nghĩa behavior-compatible
Giả sử application dùng interface:
result = model.generate(
messages=messages,
tools=tools,
response_schema=Invoice,
)
Bên dưới có thể là:
Provider A
Provider B
vLLM
Managed Open Model
vLLM hiện cung cấp nhiều OpenAI-compatible endpoints, giúp việc xây abstraction layer dễ hơn.
Nhưng:
API compatibility
≠
Model compatibility
Hai model cùng nhận messages, tools và JSON schema vẫn có thể khác nhau về:
- tool-selection accuracy;
- reasoning style;
- schema adherence;
- hallucination;
- output length;
- refusal behavior.
Do đó abstraction layer giảm integration lock-in, nhưng không loại bỏ behavior lock-in.
Mỗi lần đổi model vẫn cần regression eval.
6. Customization: open-weight cho bạn một tầng tự do khác
Nếu có weights, model có thể được biến đổi theo nhiều hướng:
Base Model
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Quantization LoRA Distillation
│ │ │
└─────────────┼─────────────┘
▼
Specialized Model
Điều quan trọng ở đây không phải là “fine-tuning lúc nào cũng tốt”.
Điểm quan trọng là bạn có quyền lựa chọn sâu hơn.
Một task rất narrow như:
- classify support ticket;
- extract fields từ một document format ổn định;
- normalize domain-specific text;
- sinh một structured response cố định;
có thể không cần frontier model.
Nếu một model nhỏ được tune đúng task đạt quality bar, architecture có thể chuyển từ:
Every request
↓
Large general model
sang:
Common repetitive task
↓
Small specialized model
và chỉ escalate các trường hợp khó.
Closed models cũng có customization
Không nên biến sự khác biệt này thành:
Open = fine-tune được
Closed = fine-tune không được
Customization của proprietary platforms phụ thuộc provider và model. Google Cloud, chẳng hạn, hiện cung cấp supervised fine-tuning cho một số Gemini models trên Vertex AI.
Khác biệt chính xác hơn là:
Open-weight
↓
Control trực tiếp lên weights
và serving stack
Closed / proprietary
↓
Customization surface
do provider quyết định
Nếu task cần custom training rất sâu hoặc architecture-specific optimization, open-weight trở nên hấp dẫn hơn.
Nếu prompt engineering + RAG + structured output đã giải quyết được vấn đề, việc xây thêm một fine-tuning pipeline có thể chỉ tạo ra complexity không cần thiết.
7. Privacy: “sensitive data = phải self-host” cũng quá đơn giản
Một reasoning phổ biến là:
Dữ liệu nhạy cảm
↓
Không được dùng API
↓
Phải self-host
Đôi khi đúng.
Nhưng không phải lúc nào cũng đúng.
OpenAI hiện nêu rằng dữ liệu gửi qua API không được dùng để train hoặc cải thiện model theo mặc định nếu customer không opt in; tài liệu cũng mô tả retention controls, trong đó abuse-monitoring logs mặc định có thể được giữ tối đa 30 ngày và một số endpoint/workload đủ điều kiện cho Zero Data Retention. Các feature cụ thể có rule riêng nên cần kiểm tra theo endpoint.
Anthropic tương tự cho biết inputs/outputs của commercial offerings không được dùng để train model theo mặc định. Với API, standard retention hiện là tối đa 30 ngày trong trường hợp thông thường, trong khi một số enterprise API customers có thể có Zero Data Retention arrangement; các feature nhất định có exception riêng.
Vì vậy câu hỏi security tốt hơn là:
Data
│
├── được gửi tới đâu?
├── được lưu bao lâu?
├── có dùng để training không?
├── có regional processing/storage không?
├── private networking có không?
├── encryption thế nào?
├── logs chứa gì?
├── subprocessor nào tham gia?
└── compliance requirement là gì?
Chỉ sau khi trả lời những câu đó mới quyết định API có phù hợp hay không.
Self-host cho data control rất mạnh
Self-host có thể giữ đường đi của dữ liệu như sau:
User
│
▼
Private Network
│
▼
Application
│
▼
Private Inference Endpoint
│
▼
Your GPU
Đây là lợi thế rất lớn nếu requirement là:
- air-gapped environment;
- strict data sovereignty;
- private source code;
- confidential R&D;
- một số highly regulated workloads;
- network boundary không cho phép gửi payload ra ngoài.
Managed open inference cũng có thể cung cấp middle ground. Chẳng hạn Hugging Face hỗ trợ private endpoints/PrivateLink trong các deployment phù hợp, cho phép traffic không cần đi qua public Internet.
Nhưng cần phân biệt hai khái niệm:
Data control
≠
Security
Self-host chỉ có nghĩa bạn nhận thêm responsibility.
Bạn phải quản lý:
IAM
Network security
Secrets
Container images
GPU hosts
Runtime patching
Observability
Access logs
Model artifacts
Dependencies
Supply chain
Nếu những phần đó được vận hành kém, một private GPU cluster vẫn có thể kém an toàn hơn một managed service được cấu hình đúng.
⚠️ Cẩn thận
“Data không rời VPC” là một security property quan trọng.
Nó không phải bằng chứng rằng toàn bộ hệ thống secure.
8. Open-weight còn tạo thêm một supply chain mà bạn phải sở hữu
Khi dùng proprietary API, phần model artifact nằm sau trust boundary của provider.
Self-hosting di chuyển boundary đó về phía bạn.
Pipeline có thể trở thành:
Model Registry / Hub
│
▼
Weights
│
▼
Tokenizer
│
▼
Model-specific code
│
▼
Inference Engine
│
▼
CUDA / kernels / drivers
│
▼
Production Deployment
Mỗi layer trở thành một dependency cần quản lý.
Do đó một production workflow tốt hơn nên giống:
Trusted source
│
▼
License review
│
▼
Pin revision / artifact
│
▼
Hash verification
│
▼
Security scanning
│
▼
Quality evaluation
│
▼
Internal model registry
│
▼
Controlled deployment
thay vì:
download random-model
docker run
ship production
Đây là một ví dụ điển hình cho quy luật lớn hơn:
Control và responsibility luôn đi cùng nhau.
Closed API lấy đi nhiều control, nhưng đồng thời provider gánh nhiều operation.
Self-host trả control lại cho bạn, nhưng cũng trả lại failure modes.
9. Architecture trưởng thành thường không chọn một model — nó route giữa nhiều model
Giả sử product có 100.000 requests.
Không phải tất cả đều khó như nhau.
Một distribution giả định:
Easy 70%
Medium 20%
Hard 10%
Nếu toàn bộ request đều đi vào model đắt nhất:
100% Requests
│
▼
Frontier Model
thì bạn đang trả frontier-level cost cho cả những task không cần frontier-level intelligence.
Một architecture trưởng thành hơn:
Request
│
▼
Model Router
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Easy Medium Hard
│ │ │
▼ ▼ ▼
Small Model Mid Model Frontier Model
Ví dụ:
"Extract customer email"
↓
Small local model
"Summarize support conversation"
↓
Mid-size model
"Investigate ambiguous contract clause"
↓
Frontier reasoning model
Lúc này câu hỏi “open hay closed” gần như biến mất.
Architecture có thể dùng cả hai.
Hybrid architecture
┌──────────────┐
│ LLM Gateway │
└──────┬───────┘
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Local Open Managed Open Frontier API
Model Model
│ │ │
└──────────────┼──────────────┘
▼
Result
Routing policy có thể nhìn vào nhiều signal:
def select_model(request):
if request.contains_restricted_data:
return LOCAL_MODEL
if request.task in CHEAP_TASKS:
return SMALL_MODEL
if request.requires_high_reasoning:
return FRONTIER_MODEL
return DEFAULT_MODEL
Production implementation tất nhiên phức tạp hơn. Router có thể dựa vào task type, estimated complexity, latency budget, tenant policy, data classification hoặc provider health.
Nhưng mental model rất mạnh:
Model selection
↓
per workload
thay vì:
Model selection
↓
per company
Một công ty không cần tuyên bố “chúng tôi là open-source shop” hay “chúng tôi dùng closed models”.
Mỗi workload có thể có architecture khác nhau.
10. Một LLM gateway giúp architecture này không biến application thành mớ vendor-specific code
Nếu business logic chứa đầy:
openai.xxx(...)
rồi:
anthropic.xxx(...)
rồi logic riêng cho local inference, migration sẽ rất đau.
Một abstraction tốt hơn:
Application
│
▼
┌─────────────────┐
│ Model Gateway │
└────────┬────────┘
│
┌─────┼───────────┬────────────┐
▼ ▼ ▼ ▼
Model A Model B vLLM Managed Open
Internal contract có thể trông như:
generate(
messages=messages,
tools=tools,
response_schema=schema,
policy={
"max_cost": 0.02,
"data_class": "internal",
"quality_tier": "high",
},
)
Gateway chịu trách nhiệm:
- provider authentication;
- retry;
- fallback;
- rate limiting;
- logging;
- cost tracking;
- routing;
- model policy;
- normalization.
Nhưng một lỗi thiết kế khác cần tránh là cố tạo abstraction quá thấp đến mức xóa sạch khác biệt giữa các model.
Tool calling của mỗi model có thể khác.
Reasoning controls có thể khác.
Caching semantics có thể khác.
Multimodal capabilities có thể khác.
Do đó abstraction tốt thường che đi:
transport differences
nhưng vẫn cho application biểu diễn:
capability differences
11. Framework thực tế để chọn architecture
Thay vì bắt đầu bằng danh sách model, hãy bắt đầu từ requirement.
Bước 1 — Xác định quality bar
Ví dụ:
Task success >= 95%
JSON validity >= 99.5%
Critical hallucination <= 0.5%
Tool-call accuracy >= 98%
Một con số cụ thể buộc team chuyển từ “model này có vẻ thông minh hơn” sang một requirement đo được.
Bước 2 — Build evaluation dataset
Dataset nên lấy từ distribution thật của production, bao gồm:
normal cases
edge cases
long inputs
multilingual inputs
badly formatted data
tool calls
known failure cases
adversarial cases
Không nhất thiết phải bắt đầu với hàng chục nghìn sample.
Một vài trăm case có chất lượng tốt thường đã giúp loại bỏ rất nhiều decision dựa trên cảm giác.
Bước 3 — Shortlist nhiều tầng model
Đừng chỉ test:
Frontier A
vs
Frontier B
Hãy thử cả:
Frontier API
Mid-tier API
Large open-weight
Small open-weight
Specialized / fine-tuned model
Nhiều team bất ngờ khi một task narrow không hưởng lợi đáng kể từ model lớn hơn.
Bước 4 — Benchmark quality
Đo:
task success
hallucination
structured output
tool use
reasoning quality
retry rate
Bước 5 — Benchmark serving
Với API:
TTFT
p50 latency
p95 latency
p99 latency
rate-limit behavior
Với self-host, thêm:
tokens/sec
requests/sec
GPU utilization
KV-cache usage
max concurrency
queue time
OOM behavior
Benchmark phải mô phỏng context length, output length và concurrency gần với production.
Một benchmark chạy từng request đơn lẻ không nói được nhiều về serving economics của hệ thống có hàng trăm concurrent users.
Bước 6 — Tính TCO
API:
tokens
+ retries
+ tools
+ caching
+ provider-specific features
Self-host:
GPU
+ idle capacity
+ redundancy
+ autoscaling overhead
+ storage
+ networking
+ observability
+ engineering
+ operations
Bước 7 — Apply hard constraints trước
Ví dụ:
Quality >= requirement
Latency <= SLO
Security = PASS
Compliance = PASS
License = PASS
Reliability = PASS
Candidate không pass một hard requirement nên bị loại ngay.
Sau đó mới:
minimize(total cost)
hoặc optimize theo business score.
Đây là điểm khác biệt giữa benchmark engineering và production engineering.
Model có intelligence score cao nhất không tự động thắng.
12. Decision matrix: khi nào architecture nào hợp lý hơn?
Không có bảng nào thay thế được benchmark thực tế, nhưng matrix sau là một mental model tốt để shortlist:
| Tiêu chí | Closed API | Managed Open | Self-host Open |
|---|---|---|---|
| Time to market | ★★★★★ | ★★★★ | ★★ |
| Infra simplicity | ★★★★★ | ★★★★ | ★ |
| Frontier capability | ★★★★★ | ★★★★ | ★★★–★★★★ |
| Model control | ★ | ★★★★ | ★★★★★ |
| Fine-tuning flexibility | ★★–★★★ | ★★★★ | ★★★★★ |
| Data-path control | ★★★ | ★★★★ | ★★★★★ |
| Version/artifact control | ★★ | ★★★★ | ★★★★★ |
| Low-volume economics | ★★★★★ | ★★★★ | ★★ |
| Stable high-volume economics | ★★★ | ★★★★ | ★★★★★* |
| Operational complexity | ★★★★★ | ★★★★ | ★ |
| Vendor independence | ★★ | ★★★★ | ★★★★★ |
| Air-gapped deployment | ★ | ★–★★ | ★★★★★ |
★★★★★* chỉ có ý nghĩa nếu workload đủ lớn, predictable và serving stack đạt utilization tốt.
Closed API thường phù hợp nhất khi
Bạn đang:
- build MVP;
- cần launch nhanh;
- traffic chưa rõ;
- team nhỏ;
- cần frontier capability;
- không muốn vận hành GPU.
Một startup thường hợp lý hơn khi đi:
Idea
↓
API
↓
Users
↓
Product-market fit
↓
Real traffic data
↓
Optimize
thay vì:
Idea
↓
GPU cluster
↓
Inference optimization
↓
Autoscaling
↓
Observability
↓
...
↓
Maybe users
Managed open thường hấp dẫn khi
Bạn muốn:
Own / choose model
+
More customization
+
Less proprietary dependency
+
No full GPU operations team
Nó cũng là một migration step đẹp:
Closed API
↓
Managed Open
↓
Self-host
Team chỉ nhận thêm operational responsibility khi economics thực sự chứng minh điều đó cần thiết.
Self-host open-weight thường mạnh khi nhiều điều kiện cùng xuất hiện
High volume
+
Predictable traffic
+
Need data control
+
Need model control
+
Need customization
+
Strong infrastructure capability
Không nhất thiết phải có cả sáu, nhưng càng nhiều yếu tố xuất hiện cùng lúc, business case cho self-host càng mạnh.
13. Sáu misconception dễ khiến team chọn sai
1. “Open-source là miễn phí”
Weights có thể download miễn phí.
Inference thì không.
Model license = $0
không làm:
GPU
People
Monitoring
Networking
Redundancy
Operations
biến thành $0.
2. “Closed API nghĩa là provider dùng data của tôi để train”
Không thể kết luận như vậy.
Các commercial API hiện có policies riêng về training, retention và data controls; OpenAI và Anthropic đều nêu rằng commercial/API inputs và outputs không được dùng để train theo mặc định trong các điều kiện đã công bố, nhưng retention và feature-specific exception vẫn phải được kiểm tra kỹ.
3. “Open-weight luôn rẻ hơn”
Chỉ khi workload economics phù hợp.
Một GPU chạy 20% utilization có thể đắt hơn API.
4. “Self-host có nghĩa là secure”
Self-host cho bạn quyền kiểm soát data path.
Nó đồng thời chuyển nhiều security responsibility về phía bạn.
5. “Open-source nghĩa là Apache hoặc MIT”
Không đúng.
Các downloadable model families hiện sử dụng nhiều loại license và terms khác nhau; Llama 4 và Gemma là hai ví dụ rõ ràng cho việc model có weights public nhưng điều khoản không đơn giản là permissive OSS license.
6. “Chúng ta phải chọn một model cho toàn bộ sản phẩm”
Đây có lẽ là misconception quan trọng nhất.
Một application hiện đại có thể dùng:
small model
for repetitive cheap tasks
+
managed open model
for private/custom workloads
+
frontier API
for difficult long-tail reasoning
Kiến trúc đó thường tối ưu hơn việc ép mọi workload đi qua cùng một model.
14. Chiến lược migration ít rủi ro hơn: optimize sau khi đã có dữ liệu thật
Nếu chưa biết traffic distribution của sản phẩm, quyết định self-host ngay từ ngày đầu thường dựa trên giả định.
Một con đường an toàn hơn có thể gồm nhiều phase.
Phase 1 — Frontier API
100% requests
↓
Frontier API
Mục tiêu chưa phải optimize inference.
Mục tiêu là:
prove product
collect traffic
collect failures
build eval dataset
Phase 2 — Phân tích workload
Sau một thời gian, bạn có thể phát hiện:
Requests
│
├── easy 70%
├── medium 20%
└── hard 10%
Đây là dữ liệu bạn không có ở giai đoạn prototype.
Phase 3 — Offload easy tasks
70% ──► small / open model
30% ──► frontier model
Nếu quality vẫn giữ được, inference cost giảm mà không cần migrate toàn bộ architecture.
Phase 4 — Specialize
Những task cực kỳ ổn định có thể được fine-tune hoặc distill vào model nhỏ hơn.
Frontier / teacher
│
│ high-quality task examples
▼
Specialized smaller model
Phase 5 — Routing trở thành default
Cuối cùng:
Router
┌──────┼──────┐
│ │ │
▼ ▼ ▼
Local Managed Frontier
Model Open API
70% 20% 10%
Con số chỉ mang tính minh họa.
Điểm quan trọng là architecture được quyết định từ measurement, không phải ideology.
Kết luận: câu hỏi tốt hơn không phải “open hay closed?”
Quay lại team ở đầu bài.
Security team hỏi liệu dữ liệu có được gửi ra khỏi trust boundary hay không.
Infrastructure team quan tâm GPU utilization.
Product team cần quality.
Finance quan tâm TCO.
Legal quan tâm license.
Engineering muốn giảm vendor lock-in.
Tất cả đều hợp lý.
Sai lầm chỉ xuất hiện khi chúng ta cố ép tất cả những yêu cầu đó vào một binary decision:
OPEN
vs
CLOSED
Một framework tốt hơn là:
Workload
│
▼
Quality Bar
│
▼
Hard Constraints
security / legal / SLO
│
▼
Candidate Models
│
▼
Benchmark
│
▼
TCO
│
▼
Architecture
Với MVP hoặc traffic thấp, proprietary API thường là lựa chọn cực kỳ hợp lý vì bạn mua được cả model capability lẫn operational simplicity.
Khi cần thêm model control nhưng chưa muốn sở hữu GPU operations, managed open inference có thể là middle ground tốt.
Khi workload lớn, ổn định, predictable, có requirement cao về privacy/customization và team đủ khả năng vận hành inference stack, self-host open-weight bắt đầu trở nên rất hấp dẫn.
Và khi hệ thống trưởng thành hơn nữa, đáp án thường không phải chọn một trong hai.
Nó có thể trông như:
┌──────────────┐
│ Model Router │
└──────┬───────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Small Local Managed Open Frontier API
Model Model
│ │ │
cheap flexible powerful
private scalable long-tail
Đó là sự thay đổi mental model quan trọng nhất:
Model selection trong production ngày càng giống một bài toán routing, economics và risk management hơn là một cuộc thi xem model nào đứng đầu benchmark.
Vì vậy, đừng bắt đầu bằng:
“Công ty nên dùng open-source hay closed-source?”
Hãy bắt đầu bằng:
“Workload này cần quality nào, data được phép đi đâu, latency bao nhiêu, traffic có hình dạng thế nào, team muốn sở hữu bao nhiêu operational complexity — và architecture rẻ nhất nào đáp ứng được toàn bộ những constraint đó?”
Khi câu hỏi đúng, lựa chọn model thường trở nên rõ ràng hơn rất nhiều.
Nguồn tham khảo
- Open Source Initiative — The Open Source AI Definition 1.0.
- OpenAI — Data controls in the OpenAI platform và tài liệu backward compatibility/model behavior.
- Anthropic Privacy Center — Is my data used for model training?, API retention và Zero Data Retention.
- vLLM — tài liệu serving, continuous batching, distributed inference và OpenAI-compatible APIs.
- Hugging Face — Inference Endpoints, autoscaling, security và PrivateLink configuration.
- Qwen Team — Qwen3 repository và Apache 2.0 licensing information.
- DeepSeek — DeepSeek-R1 repository và MIT licensing information.
- Meta — Llama 4 Community License Agreement.
- Google — Gemma Terms of Use.
- Google Cloud — Vertex AI supervised fine-tuning documentation.
