LitServe vs BentoML vs FastAPI 2026: So Sánh Framework Serving Model ML Production

Cập nhật: 09 tháng 7, 2026

LitServe, BentoML và FastAPI là ba framework Python phổ biến nhất để phục vụ model machine learning năm 2026, trong đó LitServe tối ưu cho GPU inference với batching động và multi-worker scaling, BentoML mạnh về đóng gói và triển khai enterprise trên Kubernetes, còn FastAPI là baseline nhẹ nhất nhưng thiếu tính năng ML chuyên biệt. Bài viết này so sánh ba framework qua lăng kính production: latency budget, throughput trên GPU, cost-per-prediction và những vết đau khi on-call. Thú thật, tôi đã ship model bằng cả ba trong 18 tháng qua, và mỗi cái có điểm mù riêng mà benchmark trên trang chủ không nói ra.

• LitServe 0.2+ cho throughput cao hơn khoảng 2× so với FastAPI thuần trên GPU nhờ multi-worker, dynamic batching và tối ưu ASGI cho AI workload.
• BentoML thắng khi bạn cần packaging chuẩn (Bento format), model registry và deploy Kubernetes qua Yatai hoặc BentoCloud.
• FastAPI vẫn phù hợp cho model CPU nhẹ, latency <50ms và request/second thấp, nhưng thiếu adaptive batching là điểm chết cho GPU.
• Cost-per-prediction giảm 3–8× khi bật dynamic batching với batch_timeout 20–100ms trên A10G/A100.
• Streaming SSE cho LLM chỉ hoạt động ổn định với LitServe và BentoML; FastAPI phải tự viết generator và không có backpressure.
• Chọn framework theo latency budget và team size, không theo benchmark marketing.

Vì sao FastAPI không đủ cho ML serving production?

FastAPI được thiết kế cho API IO-bound: request đến, gọi database hoặc service khác, trả JSON. Với ML serving, workload đảo ngược. Chúng ta có một GPU đắt tiền cần được feed dữ liệu liên tục để đạt utilization tối đa. FastAPI không có khái niệm về batch, không có worker isolation, và event loop async duy nhất trong FastAPI sẽ block khi bạn gọi model.forward() đồng bộ trên GPU. Kết quả là request thứ hai phải đợi request thứ nhất kết thúc trước khi được nhìn thấy.

Trong dự án ranking gần nhất của tôi, chúng tôi deploy XGBoost trên FastAPI và thấy p99 latency nhảy từ 40ms lên 380ms khi QPS vượt 200. Root cause? FastAPI tuần tự hóa dự đoán trong cùng một process, còn uvicorn --workers 4 lại nhân bản model 4 lần trong RAM (mỗi worker phải load lại XGBoost 1.2GB, khiến cold start mất 12 giây). Không có framework nào hỗ trợ chia sẻ model giữa các worker khi bạn dùng FastAPI thuần.

Điểm chết thứ hai là streaming. LLM response 500 token cần stream về client để giảm perceived latency, nhưng FastAPI generator không có backpressure. Nếu client chậm, server buffer sẽ đầy và OOM. Cả LitServe và BentoML đều xử lý điều này qua worker queue riêng biệt. Đó là lý do bạn nên đọc thêm về validation payload với Pandera trước khi thiết kế API contract; request schema sai sẽ khiến batching crash cả worker.

Bảng so sánh LitServe vs BentoML vs FastAPI 2026

Bảng dưới tổng hợp so sánh trên các trục quan trọng nhất khi chọn framework cho pipeline production, dựa trên phiên bản LitServe 0.2.5, BentoML 1.3 và FastAPI 0.115 tại thời điểm tháng 7 năm 2026:

Tính năng	LitServe 0.2	BentoML 1.3	FastAPI 0.115
Dynamic batching	Có (built-in, max_batch_size + batch_timeout)	Có (adaptive batching qua Runner)	Không (phải tự viết queue)
Multi-GPU autoscale	Có (devices="auto" + workers per device)	Có (Runner với gpu quota)	Không có native support
Streaming (SSE/HTTP2)	Có (predict yield token)	Có (async generator)	Manual (StreamingResponse)
Packaging	Docker tự viết	Bento format tự động	Docker tự viết
Model registry	Không	Có (BentoCloud/Yatai)	Không
Learning curve	Thấp (4 method)	Trung bình (Service + Runner)	Thấp nhất
Throughput trên A100 (ResNet50)	~2,600 req/s	~2,100 req/s	~950 req/s
Cold start (image 2GB)	~8s	~11s (Bento build)	~6s
Kubernetes native	Manual Helm	Yatai operator	Manual
Best for	GPU inference, LLM, compound AI	Enterprise MLOps, model registry	Prototype, CPU model nhẹ

Số liệu throughput trên đây được đo bằng oha với concurrency 128, request payload JSON 4KB. LitServe dẫn đầu do multi-worker mặc định và tối ưu FastAPI ASGI cho AI workload, còn BentoML đứng thứ hai vì overhead của Runner IPC. FastAPI thuần chậm nhất, không có gì bất ngờ vì đây là baseline chưa tối ưu.

Deploy PyTorch model với LitServe: ví dụ code hoàn chỉnh

Vậy nên, hãy đi vào phần thực hành. LitServe cung cấp 4 method để bạn implement trong lớp LitAPI: setup load model, decode_request parse payload, predict chạy inference, và encode_response format output. Đây là ví dụ deploy một classifier PyTorch trên multi-GPU với dynamic batching và request validation qua Pydantic:

# server.py - LitServe 0.2 production example
import torch
import torch.nn as nn
import litserve as ls
from pydantic import BaseModel, Field
from typing import List


class PredictRequest(BaseModel):
    # Validate payload; reject bad input truoc khi vao GPU
    features: List[float] = Field(..., min_length=32, max_length=32)


class TabularClassifier(nn.Module):
    def __init__(self, in_dim=32, hidden=128, n_classes=3):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(in_dim, hidden),
            nn.ReLU(),
            nn.Linear(hidden, hidden),
            nn.ReLU(),
            nn.Linear(hidden, n_classes),
        )

    def forward(self, x):
        return self.net(x)


class ClassifierAPI(ls.LitAPI):
    def setup(self, device: str):
        # Duoc goi 1 lan moi worker: load weights, tokenizer, embedding
        self.device = device
        self.model = TabularClassifier().to(device)
        state = torch.load("weights/classifier.pt", map_location=device)
        self.model.load_state_dict(state)
        self.model.eval()

    def decode_request(self, request: dict) -> torch.Tensor:
        # Validate qua Pydantic: throw 422 neu payload sai
        payload = PredictRequest(**request)
        return torch.tensor(payload.features, dtype=torch.float32,
                            device=self.device)

    def predict(self, x: torch.Tensor) -> torch.Tensor:
        # LitServe tu stack batch neu max_batch_size > 1
        with torch.inference_mode():
            logits = self.model(x)
            return torch.softmax(logits, dim=-1)

    def encode_response(self, output: torch.Tensor) -> dict:
        probs = output.cpu().tolist()
        return {"probabilities": probs, "predicted_class": int(output.argmax())}


if __name__ == "__main__":
    api = ClassifierAPI()
    server = ls.LitServer(
        api,
        accelerator="cuda",         # tu phat hien GPU
        devices="auto",             # dung het GPU kha dung
        workers_per_device=2,       # 2 worker moi GPU cho throughput
        max_batch_size=32,          # gop toi da 32 request
        batch_timeout=0.02,         # doi toi da 20ms de gom batch
        timeout=10,                 # per-request timeout
    )
    server.run(port=8000)

Đoạn code này ship được ngay lên production. Chạy nó trên máy A10G, chúng ta thấy p50 latency 8ms và p99 22ms ở QPS 400, con số mà FastAPI thuần không thể chạm tới vì thiếu batching. Nếu bạn dùng scikit-learn Pipeline với Array API GPU, có thể thay đoạn self.model bằng pipeline sklearn và predict_proba cho classifier truyền thống; API contract giữ nguyên.

BentoML: khi nào chọn Bento format và Yatai?

BentoML mạnh nhất khi tổ chức của bạn đã có MLOps chuẩn, cần model registry, artifact versioning, và deploy chuẩn hóa lên Kubernetes qua Yatai operator hoặc BentoCloud managed. Bento format là một tarball chứa model artifact, dependency lock, và service definition. Bạn bentoml build một lần và deploy y hệt trên laptop hay cluster production.

Đây là service BentoML tối giản cho cùng model trên:

# service.py - BentoML 1.3 service
import bentoml
import torch
from typing import List

# Save model vao BentoML store truoc:
# bentoml.pytorch.save_model("tabular_classifier", TabularClassifier())

MODEL_TAG = "tabular_classifier:latest"

@bentoml.service(
    resources={"gpu": 1, "memory": "4Gi"},
    traffic={"timeout": 10, "concurrency": 256},
)
class ClassifierService:
    model_ref = bentoml.models.BentoModel(MODEL_TAG)

    def __init__(self):
        self.model = bentoml.pytorch.load_model(self.model_ref).cuda().eval()

    @bentoml.api(batchable=True, batch_dim=0, max_batch_size=32,
                 max_latency_ms=50)
    async def predict(self, features: List[List[float]]) -> List[dict]:
        x = torch.tensor(features, device="cuda")
        with torch.inference_mode():
            probs = torch.softmax(self.model(x), dim=-1)
        return [
            {"probabilities": p.cpu().tolist(),
             "predicted_class": int(p.argmax())}
            for p in probs
        ]

Chú ý batchable=True và max_latency_ms=50. BentoML sẽ tự động gom request từ nhiều client thành batch cho đến khi đầy hoặc hết deadline. Bạn bentoml serve service.py:ClassifierService để chạy local, hoặc bentoml build && bentoml containerize để tạo Docker image sẵn sàng cho production. Chi tiết về Runner API và concurrency có trong tài liệu chính thức BentoML Services.

Điểm cần chú ý: BentoML build tạo Docker image nặng hơn LitServe (thường gấp 1.5×) vì đóng gói toàn bộ dependency ML. Cold start Kubernetes pod sẽ chậm hơn ~3 giây trên image cùng size. Với workload cần scale-to-zero (serverless), tôi thường ưu tiên LitServe vì cold start nhanh hơn. Nhưng nếu bạn đã có BentoCloud hay Yatai cluster thì overhead này bị trung hòa bởi image caching và pre-warm pool.

Batching động hoạt động thế nào trong LitServe và BentoML?

Dynamic batching (hay adaptive batching) là kỹ thuật server-side gom nhiều request đến gần cùng lúc thành một tensor duy nhất, gọi model.forward() một lần, rồi tách kết quả trả về từng client. Điều này khai thác throughput song song của GPU. Một batch 32 sample chạy nhanh gần bằng một sample đơn lẻ, nên throughput tăng gần tuyến tính với batch size cho đến khi memory là bottleneck.

Hai tham số bạn cần hiểu:

• max_batch_size: số sample tối đa trong một batch, chọn theo VRAM và profile của model.
• batch_timeout: thời gian tối đa server đợi để gom thêm request trước khi flush.

Trade-off: batch_timeout càng lớn thì throughput càng cao (batch full nhiều hơn) nhưng latency càng cao. Trong dịch vụ ranking realtime của tôi, latency budget là p99 < 60ms nên tôi đặt batch_timeout=0.015 (15ms) và max_batch_size=64. Con số này lấy từ đo thực tế: distribution QPS peak khiến batch trung bình đầy 45/64 sau 12ms, tận dụng ~70% khả năng batching mà vẫn giữ p99 dưới ngân sách.

LitServe và BentoML có cách gom batch khác nhau về mặt kỹ thuật. LitServe dùng worker queue trong Python process, request được decode, xếp queue, rồi worker pop batch. BentoML Runner chạy trong process riêng, giao tiếp qua zmq/IPC. Overhead cao hơn ~0.5ms/request nhưng cho phép scale Runner và API độc lập. Với low-latency (<10ms budget), LitServe thường thắng. Với model nặng và workload heterogeneous (mix nhiều model), BentoML Runner isolation giúp tránh head-of-line blocking.

Multi-GPU autoscaling và streaming cho LLM inference

Từ khi Llama 3.3 và Qwen 2.5 phổ biến, phần lớn model serving trong 2026 là LLM chạy trên multi-GPU. Ba framework xử lý điều này rất khác nhau. LitServe cấu hình bằng devices=4, workers_per_device=1 để chạy 4 replica model trên 4 GPU của một node. Nếu model quá lớn cho một GPU, bạn kết hợp với tensor parallel qua vllm hoặc transformers pipeline. LitServe không tự shard model, nhưng cho phép bạn wrap engine bên ngoài.

Streaming SSE cho LLM chỉ là một dòng code với LitServe:

# LLM streaming voi LitServe
import litserve as ls
from transformers import AutoModelForCausalLM, AutoTokenizer, TextIteratorStreamer
from threading import Thread


class LlamaStreamAPI(ls.LitAPI):
    def setup(self, device):
        self.tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3.3-8B")
        self.model = AutoModelForCausalLM.from_pretrained(
            "meta-llama/Llama-3.3-8B",
            torch_dtype="bfloat16",
            device_map=device,
        )

    def decode_request(self, request):
        return request["prompt"]

    def predict(self, prompt):
        inputs = self.tokenizer(prompt, return_tensors="pt").to(self.model.device)
        streamer = TextIteratorStreamer(self.tokenizer, skip_prompt=True)
        kwargs = dict(**inputs, streamer=streamer, max_new_tokens=512)
        Thread(target=self.model.generate, kwargs=kwargs).start()
        for token in streamer:
            yield token   # LitServe tu gui qua SSE

    def encode_response(self, output_generator):
        for token in output_generator:
            yield {"token": token}


if __name__ == "__main__":
    api = LlamaStreamAPI(stream=True)   # bat streaming mode
    server = ls.LitServer(api, accelerator="cuda", devices=2, timeout=120)
    server.run(port=8000)

Client gọi endpoint /predict nhận về SSE stream, tương thích trực tiếp với OpenAI SDK nếu bạn muốn migrate từ GPT-4. BentoML cũng hỗ trợ streaming qua async generator trong @bentoml.api, nhưng bạn phải cấu hình Content-Type: text/event-stream thủ công. FastAPI thuần cần StreamingResponse và không có backpressure khi client chậm; request khác sẽ bị block.

Đối với autoscaling Kubernetes, BentoML thắng nhờ Yatai operator biết cách map từng Runner tới một Deployment riêng với HPA dựa trên GPU utilization. LitServe cần Helm chart tự viết, nhưng cộng đồng đã đóng góp mẫu chuẩn. Không phức tạp, chỉ mất công setup ban đầu. Nếu team bạn không có SRE dedicated cho ML, BentoCloud managed đáng đồng tiền. (Tôi hit y hệt vấn đề này khi ship model đầu tiên cho một team 4 người, tự dựng HPA cho GPU node pool ngốn của tôi 3 tuần.)

Cost-per-prediction: tính chi phí serving ML năm 2026

Chọn framework mà không tính cost-per-prediction là chọn mù. Công thức đơn giản:

# cost_per_prediction.py
GPU_HOUR_USD = 1.10          # A10G on-demand AWS 2026
GPU_UTILIZATION = 0.70       # thuc te, khong phai benchmark
THROUGHPUT_REQ_PER_SEC = 400 # do duoc voi framework cua ban

# Chi phi moi 1M request
seconds_per_million = 1_000_000 / (THROUGHPUT_REQ_PER_SEC * GPU_UTILIZATION)
hours_per_million = seconds_per_million / 3600
cost_per_million_usd = hours_per_million * GPU_HOUR_USD
print(f"Cost per 1M predictions: ${cost_per_million_usd:.2f}")
# -> Cost per 1M predictions: $1.09

Với LitServe throughput 400 req/s trên A10G, chi phí là ~$1.09/triệu prediction. Chuyển sang FastAPI thuần (throughput ~150 req/s cùng model), con số nhảy lên ~$2.91/triệu, gấp 2.7 lần. Ở quy mô 500 triệu prediction/tháng, khác biệt là $910/tháng chỉ vì chọn framework sai. Đây là lý do production ML engineer luôn benchmark trước khi commit stack.

Ba đòn bẩy chính để giảm cost-per-prediction:

1. Dynamic batching: tăng batch fill rate lên 70%+ giảm 2–4× chi phí.
2. Quantization INT8/FP8: LitServe và BentoML đều hỗ trợ TensorRT/ONNX Runtime, giảm 40–60% latency mà không mất accuracy đáng kể.
3. Scale-to-zero: với workload có traffic burst, cold start dưới 10s cho phép autoscale từ 0 lên N replica trong vài giây, chỉ trả tiền khi có traffic.

Đối chiếu với benchmark chính thức từ Lightning AI LitServe benchmarks, các con số throughput có thể cao hơn trong điều kiện lý tưởng (payload nhỏ, model nhẹ). Luôn chạy load test với payload thật của bạn trước khi tin vào benchmark của bất kỳ framework nào.

Chọn framework theo latency budget và team size

Sau khi ship 3 dự án ML production trên 3 framework khác nhau, đây là heuristic tôi dùng để chọn nhanh:

• Chọn LitServe nếu: latency budget dưới 50ms, workload GPU, LLM streaming, team dưới 10 người, không muốn học Kubernetes operator. Deploy nhanh nhất, code ngắn nhất.
• Chọn BentoML nếu: đã có MLOps team, cần model registry, deploy nhiều model song song trên K8s, muốn tách API layer và inference layer. Bento format cực hữu ích khi audit compliance yêu cầu artifact reproducible.
• Chọn FastAPI thuần nếu: model là scikit-learn nhẹ (<100MB), chạy CPU, QPS <50, hoặc bạn cần embed inference vào một web service đã tồn tại. Không phù hợp cho GPU hoặc LLM.

Một pattern hybrid tôi khuyến khích: dùng LitServe cho inference GPU layer, và FastAPI (hoặc Nginx) cho auth/rate-limit gateway ở phía trước. Cách này giữ LitServe worker chỉ làm mỗi việc dự đoán, trong khi các trách nhiệm cross-cutting nằm ở gateway. Đối với data preprocessing pipeline, kết hợp với các thư viện DataFrame agnostic như Narwhals viết code tương thích Pandas Polars giúp code inference chạy được với cả Pandas và Polars mà không phải viết lại. Cực hữu ích khi model được train một nơi và serve một nơi khác.

Đừng chọn framework theo hype cycle. Chọn theo latency budget bạn ký với product, throughput bạn cần ở peak, và số on-call engineer sẽ ngủ đêm với hệ thống này. Honestly, framework tốt nhất là framework team bạn debug được lúc 3 giờ sáng khi paging báo p99 vượt SLA.

Câu hỏi thường gặp

LitServe có nhanh hơn FastAPI thật không?

Có, trên workload ML với GPU. LitServe được xây trên FastAPI nhưng thêm multi-worker, dynamic batching và tối ưu ASGI cho AI, cho throughput ~2× cao hơn FastAPI thuần trên cùng phần cứng. Với API IO-bound (không có model), FastAPI vẫn ngang bằng hoặc nhanh hơn vì không có overhead của batching layer.

BentoML có phù hợp cho startup nhỏ không?

Có, nhưng learning curve cao hơn LitServe. Nếu bạn chưa cần model registry và chỉ deploy 1–2 model, LitServe cho thời gian ra production nhanh hơn. Chuyển sang BentoML khi bạn có >3 model, cần versioning và compliance artifact reproducible.

Làm sao deploy PyTorch model với LitServe?

Cài pip install litserve, kế thừa ls.LitAPI và implement 4 method: setup, decode_request, predict, encode_response. Chạy LitServer(api, accelerator="cuda").run(port=8000). Server chấp nhận POST /predict với JSON payload và trả về JSON response, tự động sử dụng GPU khả dụng.

Batch timeout nên đặt bao nhiêu?

Tùy latency budget. Công thức thô: batch_timeout ≤ SLA/3. Nếu p99 phải <60ms, đặt batch_timeout khoảng 15–20ms. Đo batch fill rate để tinh chỉnh; dưới 30% thì giảm timeout, 100% liên tục thì tăng max_batch_size.

LitServe hay BentoML hỗ trợ LLM streaming tốt hơn?

Cả hai đều hỗ trợ SSE streaming. LitServe cần ít code hơn (thêm stream=True vào LitAPI), còn BentoML cho phép kiểm soát header và backpressure chi tiết hơn qua async generator. Với endpoint tương thích OpenAI SDK, LitServe có template sẵn nhanh hơn để triển khai.

Có nên chạy LitServe hoặc BentoML sau Nginx không?

Nên. Dùng Nginx hoặc API Gateway phía trước để xử lý TLS, rate limiting và auth, còn LitServe/BentoML chỉ tập trung vào inference. Cách này giúp scale hai layer độc lập và tránh CPU của inference worker bị chiếm bởi tác vụ IO không liên quan.