Posted inAI

Từ Notebook đến Production: Triển khai mô hình AI với FastAPI và Docker

AI tutorial - IT technology blog
AI tutorial - IT technology blog

Cái bẫy “Chạy tốt trên máy tôi”

Bạn đã dành hàng tuần để làm sạch các tập dữ liệu hỗn độn và tinh chỉnh siêu tham số (hyperparameters) cho đến khi cuối cùng đạt được mức độ chính xác 98%. Cảm giác thật tuyệt vời. Tuy nhiên, đối với nhiều data scientist, hành trình này kết thúc trong một Jupyter Notebook, để lại một loạt các tệp .pkl dung lượng 500MB mà không ai khác có thể sử dụng. Nếu mô hình của bạn không thể truy cập được thông qua một endpoint ổn định, nó coi như vô hình đối với phần còn lại của công ty.

Tôi đã chứng kiến các đội ngũ kỹ thuật lãng phí cả một sprint chỉ để cố gắng tái lập môi trường cục bộ trên một máy chủ đám mây. Một nhà phát triển sử dụng scikit-learn 1.2, người khác dùng 1.5, và đột nhiên mô hình ném ra lỗi AttributeError do sự không tương thích khi pickling. Khoảng cách giữa nghiên cứu và production này là nơi hầu hết các dự án AI thất bại. Để thu hẹp khoảng cách đó, bạn cần một môi trường nhất quán và một lớp giao tiếp hiểu được ngôn ngữ của web.

Tại sao việc triển khai thường thất bại

Việc chuyển một mô hình từ một script cục bộ sang một máy chủ thực tế thường thất bại vì ba lý do cụ thể sau:

1. Cơn ác mộng về phụ thuộc (Dependency)

Quản lý gói Python vốn nổi tiếng là mong manh. Các thư viện nặng ký như PyTorch hoặc TensorFlow dựa trên các tệp nhị phân C++ và phiên bản CUDA cụ thể. Nếu máy chủ production của bạn chạy NumPy 2.0 trong khi mô hình được huấn luyện trên 1.26, bạn có thể đối mặt với các lỗi tính toán âm thầm hoặc sập hệ thống hoàn toàn. Nếu không có sự cô lập (isolation), bạn đang chơi một trò chơi may rủi với các phiên bản.

2. Điểm nghẽn API

Frontend hoặc ứng dụng di động của bạn không hiểu các đối tượng Python; chúng giao tiếp qua JSON thông qua HTTP. Nhiều người mới bắt đầu cố gắng sử dụng một script cơ bản để tải lại mô hình cho mỗi request. Đây là kẻ thù của hiệu suất. Một mô hình Random Forest nặng 200MB không nên được tải từ đĩa mỗi khi người dùng nhấp vào nút—nó cần được lưu trú trong bộ nhớ (RAM).

3. Cạn kiệt tài nguyên

Các mô hình AI cực kỳ ngốn tài nguyên. Một mô hình LLM hoặc computer vision đơn lẻ có thể dễ dàng nuốt chửng 4GB RAM. Chạy trực tiếp những mô hình này trên máy chủ vật lý (bare-metal) khiến việc mở rộng quy mô theo chiều ngang (horizontal scaling) gần như là không thể. Khi lưu lượng truy cập tăng đột biến, bạn không thể chỉ “sao chép-dán” cấu hình máy chủ mà không gặp phải những rào cản lớn về cấu hình.

Lựa chọn Stack: FastAPI và các lựa chọn thay thế

Trước khi viết code, bạn phải chọn một framework. Dưới đây là bối cảnh hiện tại:

  • Flask: Người bạn cũ đáng tin cậy. Nó dễ học nhưng xử lý các yêu cầu một cách tuần tự (synchronously). Nếu một lần suy luận (inference) của mô hình mất 500ms, Flask sẽ chặn tất cả những người dùng khác trong khoảng thời gian đó.
  • Managed Services (SageMaker/Vertex AI): Những dịch vụ này mạnh mẽ nhưng đắt đỏ. Bạn thường kết thúc bằng việc bị khóa vào hệ sinh thái của một nhà cung cấp cụ thể, trả phí cao cho một “hộp đen” khó debug cục bộ.
  • FastAPI: Tiêu chuẩn công nghiệp hiện đại. Được xây dựng trên Starlette và Pydantic, đây là một trong những framework Python nhanh nhất hiện nay. Nó xử lý các yêu cầu không đồng bộ (asynchronous) một cách tự nhiên, một cứu cánh khi mô hình của bạn cần thực hiện các tác vụ I/O nặng hoặc chờ tính toán GPU.

Tôi khuyên dùng sự kết hợp giữa FastAPI và Docker cho 90% các trường hợp sử dụng. Nó mang lại sự cân bằng tốt nhất giữa hiệu suất thuần túy và tính linh hoạt cho nhà phát triển.

Xây dựng Wrapper được Container hóa

Chúng ta sẽ giải quyết vấn đề môi trường bằng cách bao bọc mô hình trong FastAPI và đóng gói nó bên trong một Docker container. Điều này đảm bảo mã chạy chính xác trên laptop của bạn cũng như trên một instance AWS EC2.

Bước 1: Logic FastAPI

Chúng ta cần một script tải mô hình vào bộ nhớ đúng một lần duy nhất khi máy chủ khởi động. Chúng ta sử dụng Pydantic để bắt buộc các kiểu dữ liệu nghiêm ngặt cho đầu vào API.

import joblib
from fastapi import FastAPI
from pydantic import BaseModel

# Định nghĩa dữ liệu đầu vào mong đợi
class PredictionRequest(BaseModel):
    feature_1: float
    feature_2: float
    feature_3: float

app = FastAPI(title="API AI cho Production")

# Tải mô hình vào RAM một lần duy nhất khi khởi động
model = joblib.load("model.pkl")

@app.get("/health")
def health_check():
    return {"status": "đang hoạt động"}

@app.post("/predict")
def predict(data: PredictionRequest):
    # Chuẩn bị các đặc trưng cho mô hình
    input_data = [[data.feature_1, data.feature_2, data.feature_3]]
    prediction = model.predict(input_data)
    
    return {"prediction": int(prediction[0])}

Bằng cách định nghĩa mô hình ở cấp cao nhất, chúng ta tránh được chi phí đọc từ đĩa cho mỗi request gửi đến.

Bước 2: Chốt phiên bản các phụ thuộc

Các yêu cầu (requirements) mơ hồ dẫn đến việc build bị lỗi. Luôn sử dụng các phiên bản chính xác trong tệp requirements.txt để ngăn các bản cập nhật bất ngờ làm hỏng mã của bạn.

fastapi==0.110.0
uvicorn==0.29.0
joblib==1.3.2
scikit-learn==1.4.1
pydantic==2.6.4

Bước 3: Docker hóa cấu hình

Dockerfile là bản thiết kế của bạn. Nó đóng gói hệ điều hành, Python và các thư viện của bạn vào một image duy nhất. Tôi sử dụng image python:3.10-slim để giữ cho dung lượng nhẹ; một bản Python tiêu chuẩn nặng khoảng 900MB, trong khi bản slim chỉ khoảng 120MB.

FROM python:3.10-slim

WORKDIR /app

# Cài đặt các phụ thuộc trước để tận dụng cache của Docker
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

# Khởi động server
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Kiểm tra việc triển khai

Với các tệp đã sẵn sàng, hãy build và chạy container của bạn bằng hai lệnh sau:

# Build image với một thẻ phiên bản
docker build -t ai-service:v1 .

# Ánh xạ cổng 8000 trên máy của bạn vào cổng 8000 trong container
docker run -p 8000:8000 ai-service:v1

Mô hình của bạn hiện đã sẵn sàng. Bạn có thể truy cập http://localhost:8000/docs để xem giao diện Swagger UI tương tác. Trang này cho phép bạn kiểm tra API trực tiếp từ trình duyệt, điều này cực kỳ hữu ích cho các nhà phát triển frontend khi tích hợp sản phẩm của bạn.

Mở rộng cho lưu lượng truy cập thực tế

Uvicorn rất tuyệt vời cho quá trình phát triển, nhưng đối với production, bạn nên sử dụng **Gunicorn** làm trình quản lý tiến trình. Nó cho phép bạn chạy nhiều “worker” để xử lý các yêu cầu đồng thời trên các lõi CPU khác nhau. Một quy tắc thông thường là sử dụng (2 x số_lõi) + 1 worker.

Cập nhật lệnh CMD trong Dockerfile của bạn như sau để có độ ổn định tốt hơn:

CMD ["gunicorn", "-w", "4", "-k", "uvicorn.workers.UvicornWorker", "main:app", "--bind", "0.0.0.0:8000"]

Thay đổi đơn giản này cho phép API của bạn xử lý lưu lượng truy cập lớn hơn đáng kể mà không làm tăng độ trễ (latency).

Lời kết

Triển khai AI không nhất thiết phải là một cơn đau đầu về sai lệch phiên bản hay sập máy chủ. Bằng cách bao bọc mô hình trong FastAPI và container hóa nó với Docker, bạn biến một script mỏng manh thành một phần mềm chuyên nghiệp, có khả năng mở rộng. Quy trình làm việc này đã trở thành tiêu chuẩn của tôi vì nó tôn trọng nhu cầu của cả data scientist và kỹ sư DevOps.

Share:
Tags: