So sánh kiến trúc suy luận AI: Server-side vs Client-side với WebAssembly
Chúng ta cần hiểu rõ sự khác biệt về luồng dữ liệu và độ trễ giữa hai mô hình trước khi đi sâu vào chi tiết kỹ thuật.
Khi chạy AI trên Server-side truyền thống, trình duyệt gửi dữ liệu đầu vào (image, text, audio) qua mạng đến API Gateway, sau đó vào container chạy Python/TensorFlow trên Kubernetes, xử lý xong rồi trả về kết quả. Quá trình này tạo ra độ trễ mạng (Network Latency) đáng kể, thường từ 50ms đến 500ms tùy vào đường truyền và tải server.
Ngược lại, khi sử dụng TensorFlow Lite trên WebAssembly (WASM), mô hình AI được biên dịch thành mã máy (binary) chạy trực tiếp trong trình duyệt của người dùng. Dữ liệu không cần đi ra ngoài mạng. Độ trễ suy luận (Inference Latency) chỉ còn ở mức vài mili-giây, gần như tức thời, đồng thời giảm tải hoàn toàn cho cụm Kubernetes về mặt tính toán.
Kiểm chứng độ trễ bằng Benchmark
Để thấy rõ sự khác biệt, hãy tạo một script đơn giản giả lập độ trễ mạng so với thời gian xử lý local.
Trước tiên, tạo file script benchmark để so sánh thời gian xử lý local (WASM) và thời gian gọi API giả lập.
#!/bin/bash
# File: benchmark_latency.sh
# Mục đích: So sánh thời gian xử lý giả lập
echo "=== Benchmark: Server-side API Call (Mock) ==="
# Giả lập độ trễ mạng 200ms + thời gian xử lý server 50ms
start_server=$(date +%s%N)
sleep 0.25
end_server=$(date +%s%N)
latency_server=$(( (end_server - start_server) / 1000000 ))
echo "Latency Server-side: ${latency_server}ms"
echo ""
echo "=== Benchmark: Client-side WASM (Mock) ==="
# Giả lập thời gian xử lý local (không có độ trễ mạng)
start_client=$(date +%s%N)
# Giả lập tính toán nhanh
result=$(echo "123456789 * 987654321" | bc)
end_client=$(date +%s%N)
latency_client=$(( (end_client - start_client) / 1000000 ))
echo "Latency Client-side WASM: ${latency_client}ms"
echo ""
echo "=== Kết quả phân tích ==="
echo "Tiết kiệm độ trễ: $((latency_server - latency_client))ms"
echo "Tỷ lệ cải thiện: $(echo "scale=2; $latency_server / $latency_client" | bc) lần"
Chạy script trên terminal Linux để xem kết quả.
chmod +x benchmark_latency.sh && ./benchmark_latency.sh
Kết quả mong đợi: Độ trễ Server-side luôn lớn hơn nhiều lần so với Client-side do yếu tố sleep (giả lập mạng), chứng tỏ WASM loại bỏ được bottleneck về truyền tải dữ liệu.
Lợi ích của TensorFlow Lite trên WebAssembly về độ trễ
TensorFlow Lite (TFLite) được thiết kế tối ưu cho các thiết bị biên (Edge devices), nhưng khi chạy trên WebAssembly, nó mang lại lợi ích kép: tốc độ gần native code và khả năng chạy đa nền tảng trên trình duyệt.
Khi biên dịch mô hình sang TFLite và chuyển đổi sang WASM, chúng ta loại bỏ sự phụ thuộc vào runtime JavaScript (V8 engine) cho các phép tính tensor nặng nề. WASM chạy trong sandbox của trình duyệt với tốc độ rất cao, cho phép suy luận các mô hình phức tạp (như MobileNet, YOLO) ngay trên CPU của client mà không bị "lag" giao diện.
Xác minh tốc độ biên dịch và kích thước file
Chúng ta sẽ kiểm tra kích thước của một mô hình mẫu đã được chuyển đổi sang TFLite để thấy tính nhỏ gọn của nó, yếu tố then chốt giúp giảm thời gian tải (Load Time) trên web.
Giả sử bạn đã có một mô hình TensorFlow Python (`.pb`) hoặc mô hình PyTorch. Ở đây, chúng ta sẽ dùng một mô hình TFLite mẫu đã có sẵn (ví dụ: MobileNetV1) để đo kích thước file.
mkdir -p /tmp/tflite-wasm-demo
cd /tmp/tflite-wasm-demo
# Tải mô hình TFLite mẫu (MobileNetV1) từ kho của Google
wget https://storage.googleapis.com/download.tensorflow.org/models/tflite/mobilenet_v1_1.0_224_float16.zip
unzip mobilenet_v1_1.0_224_float16.zip
ls -lh mobilenet_v1_1.0_224_float16.tflite
Kết quả mong đợi: File `.tflite` có kích thước rất nhỏ (dưới 2MB), thường chỉ khoảng 500KB - 1.5MB tùy phiên bản. Kích thước nhỏ này đảm bảo trình duyệt tải mô hình xuống gần như ngay lập tức, đóng góp vào trải nghiệm Real-time.
Sơ đồ kiến trúc: Browser -> WASM -> TFLite -> K8s Service
Kiến trúc tổng thể của hệ thống Real-time AI không chỉ là chạy AI trên client, mà là sự phối hợp giữa Client-side AI và Server-side Orchestration. Kubernetes (K8s) đóng vai trò là nền tảng cung cấp dịch vụ (Service) và quản lý mở rộng, trong khi WASM xử lý phần tính toán nặng.
Luồng dữ liệu hoạt động như sau:
- Browser (Client): Người dùng tương tác, thu thập dữ liệu (Camera/Microphone). Mô hình TFLite đã được tải về dưới dạng file `.wasm` hoặc `.wasm.gz`.
- WASM Runtime: TensorFlow.js hoặc TFLite Interpreter trong WASM thực hiện suy luận (Inference) ngay tại đây. Dữ liệu đầu ra là tensor kết quả.
- Logic Business: Nếu kết quả cần lưu trữ, gửi lên backend, hoặc cần xử lý phức tạp hơn (Post-processing), dữ liệu được gửi qua HTTP/gRPC đến Kubernetes Service.
- Kubernetes Service: Tiếp nhận kết quả từ client, thực hiện logic business (lưu DB, gửi notification, trigger workflow) và trả về phản hồi (acknowledgement).
Thiết lập cấu trúc thư mục dự án
Để chuẩn bị cho các phần sau, chúng ta sẽ tạo cấu trúc thư mục chuẩn mô phỏng kiến trúc này.
mkdir -p /opt/ai-platform/{frontend,models,k8s-manifests,scripts}
cd /opt/ai-platform
# Tạo file mô tả kiến trúc để làm tài liệu tham chiếu
cat > ARCHITECTURE.md
Kết quả mong đợi: Cấu trúc thư mục được tạo thành công và file `ARCHITECTURE.md` hiển thị luồng kiến trúc rõ ràng, sẵn sàng cho việc triển khai code trong các phần tiếp theo.
Lựa chọn mô hình AI phù hợp để chuyển đổi sang TFLite
Không phải mô hình AI nào cũng phù hợp để chạy trên WebAssembly. Việc lựa chọn mô hình sai có thể dẫn đến file WASM quá lớn, thời gian khởi tạo lâu, hoặc không đủ sức mạnh tính toán trên thiết bị của người dùng.
Các tiêu chí lựa chọn mô hình cho TFLite/WASM:
- Loại mạng (Architecture): Ưu tiên các kiến trúc nhẹ như MobileNet, EfficientNet-Lite, SqueezeNet, hoặc Tiny-YOLO. Tránh các mô hình quá lớn như ResNet-152 hoặc BERT-base nếu không cần thiết.
- Độ chính xác (Precision): Sử dụng Float16 (FP16) hoặc Int8 (Quantization) thay vì Float32 (FP32). FP16 giảm kích thước file xuống 50% và tăng tốc độ xử lý trên GPU/CPU mà vẫn giữ độ chính xác chấp nhận được.
- Hỗ trợ Operator: Đảm bảo mô hình chỉ sử dụng các toán tử (ops) được TensorFlow Lite hỗ trợ trên Web. Một số ops đặc biệt trong TensorFlow Python có thể không được hỗ trợ trong TFLite.
Chuẩn bị danh sách mô hình và kiểm tra hỗ trợ
Chúng ta sẽ tạo một file cấu hình định nghĩa các mô hình phù hợp và kiểm tra tính tương thích.
cd /opt/ai-platform/models
cat > model_registry.yaml
Kết quả mong đợi: File YAML hiển thị rõ các mô hình được chấp nhận (MobileNet) và bị từ chối (ResNet50) dựa trên kích thước và độ lượng tử hóa, giúp định hướng cho việc tối ưu hóa trong Phần 3.
Verify kết quả phần này
Để đảm bảo bạn đã hiểu và thiết lập đúng kiến trúc, hãy chạy lệnh sau để kiểm tra toàn bộ cấu trúc đã tạo.
tree /opt/ai-platform -L 2
Kết quả mong đợi: Xuất hiện cây thư mục với các folder `frontend`, `models`, `k8s-manifests`, `scripts` và file `ARCHITECTURE.md`, cùng với file `model_registry.yaml` bên trong thư mục models.
Điều hướng series:
Mục lục: Series: Xây dựng nền tảng Real-time AI với WebAssembly, TensorFlow Lite và Kubernetes
« Phần 1: Chuẩn bị môi trường và yêu cầu hệ thống
Phần 3: Chuẩn bị và tối ưu hóa mô hình TensorFlow Lite »