Hạ tầng AI Đa phương thức: Hướng dẫn Triển khai Mô hình Ngôn ngữ-Thị giác

Cập nhật ngày 11 tháng 12 năm 2025

Cập nhật tháng 12/2025: Các VLM mã nguồn mở (Qwen2.5-VL-72B, InternVL3-78B) hiện chỉ còn kém 5-10% so với các mô hình độc quyền của OpenAI/Google. Google Gemini được xây dựng từ đầu như một hệ thống đa phương thức (văn bản, mã, âm thanh, hình ảnh, video). Meta Llama 4 giới thiệu kỹ thuật hợp nhất sớm (early fusion) để tạo không gian tiềm ẩn chung giữa các phương thức. Khối lượng công việc đa phương thức đòi hỏi nhiều bộ nhớ hơn, chiến lược batching khác biệt, và cấu hình phục vụ chuyên biệt so với các LLM chỉ xử lý văn bản.

Các mô hình ngôn ngữ-thị giác mã nguồn mở như Qwen2.5-VL-72B và InternVL3-78B hiện đạt hiệu suất chỉ kém 5-10% so với các mô hình độc quyền từ OpenAI và Google.¹ Sự hội tụ về hiệu suất này đã biến AI đa phương thức từ một khả năng chỉ dành riêng cho các API của hyperscaler thành hạ tầng mà các tổ chức có thể triển khai, tinh chỉnh và kiểm soát. Tuy nhiên, khối lượng công việc đa phương thức đòi hỏi hạ tầng khác biệt căn bản so với các LLM chỉ xử lý văn bản—việc xử lý đồng thời hình ảnh, video và văn bản đòi hỏi nhiều bộ nhớ hơn, chiến lược batching khác biệt, và cấu hình phục vụ chuyên biệt.

Các mô hình đa phương thức đại diện cho hướng phát triển của AI. Google xây dựng Gemini từ đầu như một hệ thống đa phương thức, xử lý văn bản, mã, âm thanh, hình ảnh và video trong một kiến trúc thống nhất.² Meta Llama 4 giới thiệu thiết kế hợp nhất sớm tạo ra không gian tiềm ẩn chung giữa các phương thức.³ Hiểu rõ các yêu cầu hạ tầng để phục vụ những mô hình này—phân bổ bộ nhớ, lựa chọn GPU, các mẫu kiến trúc, và chiến lược triển khai—giúp các tổ chức chuẩn bị cho những khối lượng công việc ngày càng định hình AI trong sản xuất.

Nền tảng kiến trúc đa phương thức

Chiến lược hợp nhất

Cách các mô hình kết hợp thông tin thị giác và văn bản quyết định các yêu cầu hạ tầng:⁴

Hợp nhất sớm (Early fusion): Các mô hình xử lý đầu vào đa phương thức thô cùng nhau ngay từ đầu. Các token thị giác và token văn bản đi vào cùng một kiến trúc transformer, tạo ra các biểu diễn chung.

• Ví dụ: Chameleon, Gemini, Llama 4
• Ưu điểm: Hiểu xuyên phương thức tốt hơn, nắm bắt tương tác chi tiết
• Yêu cầu: Tài nguyên tính toán cao hơn, đầu vào đồng bộ
• Tác động hạ tầng: Cần nhiều bộ nhớ hơn cho chuỗi token kết hợp

Hợp nhất muộn (Late fusion): Các mô hình xử lý từng phương thức độc lập, kết hợp kết quả tại thời điểm quyết định. Các bộ mã hóa riêng biệt xử lý thị giác và ngôn ngữ trước khi tích hợp.

• Ví dụ: Các kiến trúc dựa trên CLIP trước đây
• Ưu điểm: Linh hoạt, chịu lỗi tốt, suy luận đơn giản hơn
• Yêu cầu: Ít áp lực bộ nhớ hơn trong quá trình mã hóa riêng lẻ
• Tác động hạ tầng: Có thể song song hóa xử lý theo từng phương thức

Phát hiện từ Apple Research (tháng 4/2025): Nghiên cứu chứng minh rằng các phương pháp hợp nhất sớm và hợp nhất muộn hoạt động tương đương khi huấn luyện từ đầu, với hợp nhất sớm cho thấy lợi thế ở ngân sách tính toán thấp hơn đồng thời hiệu quả hơn khi huấn luyện. Các kiến trúc thưa sử dụng Mixture of Experts tự nhiên phát triển chuyên môn hóa theo từng phương thức, cải thiện hiệu suất mà không tăng chi phí suy luận.

Các mẫu kiến trúc

Dựa trên adapter (bộ mã hóa thị giác + LLM):⁵ Một bộ mã hóa thị giác đã được huấn luyện trước (như SigLIP hoặc ViT) trích xuất các đặc trưng thị giác, sau đó một lớp adapter chiếu chúng vào không gian embedding của LLM. LLM sau đó xử lý các token thị giác và văn bản kết hợp.

Hình ảnh → Bộ mã hóa thị giác → Adapter → LLM (với các token văn bản) → Đầu ra

• Bộ nhớ: Trọng số bộ mã hóa thị giác + adapter + LLM
• Ví dụ: LLaVA, Qwen-VL, InternVL
• Suy luận: Mã hóa thị giác diễn ra một lần cho mỗi hình ảnh; sinh văn bản theo mẫu LLM tiêu chuẩn

Đa phương thức gốc (kiến trúc thống nhất):⁶ Mô hình xử lý tất cả các phương thức trong một kiến trúc duy nhất, được huấn luyện đồng thời trên dữ liệu đa phương thức ngay từ đầu.

[Token hình ảnh + Token văn bản] → Transformer thống nhất → Đầu ra

• Bộ nhớ: Một bộ trọng số mô hình duy nhất (thường lớn hơn)
• Ví dụ: Gemini, GPT-4V
• Suy luận: Tất cả các token được xử lý cùng nhau

Đa phương thức Mixture of Experts (MoE): Các kiến trúc expert thưa kích hoạt tập con tham số cho mỗi token. DeepSeek-VL2 chỉ kích hoạt 1-2,8 tỷ trong tổng số 4,5 tỷ tham số cho mỗi đầu vào, giảm độ trễ suy luận 50-70% so với các mô hình dày đặc.⁷

Yêu cầu bộ nhớ

Kích thước mô hình và VRAM

Các mô hình đa phương thức đòi hỏi nhiều bộ nhớ hơn các mô hình chỉ xử lý văn bản tương đương do có bộ mã hóa thị giác và ngữ cảnh dài hơn từ các token hình ảnh:⁸

Tính toán bộ nhớ:

Bộ nhớ trọng số = Số tham số × Số byte mỗi tham số

FP16: Số tham số × 2 byte
FP8:  Số tham số × 1 byte
INT4: Số tham số × 0,5 byte

Ví dụ (mô hình 72B ở FP16):
72B × 2 = 144 GB VRAM chỉ riêng cho trọng số

KV cache cho hình ảnh: Mỗi hình ảnh tạo ra hàng trăm đến hàng nghìn token trong KV cache. Một hình ảnh 1024×1024 đơn lẻ có thể tạo ra 256-1024 token thị giác, mỗi token đòi hỏi lưu trữ cache tỷ lệ với độ dài chuỗi và kích thước batch.

Cấu hình GPU

Tác động của độ phân giải hình ảnh: Hình ảnh có độ phân giải cao hơn tạo ra nhiều token hơn. Các mô hình hỗ trợ đầu vào 4K có thể tạo ra gấp 4-16 lần token thị giác so với đầu vào 512×512, làm tăng đáng kể yêu cầu bộ nhớ.

Tối ưu hóa bộ nhớ

Chiến lược lượng tử hóa:⁹

AWQ (Lượng tử hóa trọng số nhận biết kích hoạt): Mang lại tiết kiệm bộ nhớ gấp 4 lần với khả năng bảo toàn chất lượng tốt hơn GPTQ. Thường chạy nhanh gấp 2 lần trên GPU. Khuyến nghị cho triển khai VLM sản xuất.

Lượng tử hóa FP8: Có sẵn trên phần cứng H100/H200/B200. Giảm 2 lần bộ nhớ với mất mát chất lượng tối thiểu. Cho phép chạy các VLM 70B+ trên các node 8-GPU đơn lẻ.

Flash Attention: Giảm độ phức tạp bộ nhớ cho tính toán attention từ O(n²) xuống O(n). Rất quan trọng cho các chuỗi token hình ảnh dài.

Tối ưu hóa KV cache: PagedAttention (vLLM) quản lý KV cache hiệu quả thông qua phân trang. Ngăn chặn phân mảnh bộ nhớ tích lũy với các đầu vào hình ảnh có độ dài biến thiên.

Hạ tầng phục vụ

vLLM cho đa phương thức

vLLM hỗ trợ các mô hình đa phương thức với cấu hình cụ thể:¹⁰

from vllm import LLM, SamplingParams

# Khởi tạo mô hình đa phương thức
llm = LLM(
    model="Qwen/Qwen2.5-VL-72B-Instruct",
    tensor_parallel_size=4,  # Phân phối trên 4 GPU
    gpu_memory_utilization=0.9,
    max_model_len=32768,
    trust_remote_code=True,
)

# Xử lý hình ảnh + văn bản
sampling_params = SamplingParams(
    temperature=0.7,
    max_tokens=2048,
)

outputs = llm.generate(
    [
        {
            "prompt": "Mô tả chi tiết hình ảnh này:",
            "multi_modal_data": {"image": image_data}
        }
    ],
    sampling_params=sampling_params
)

Các cấu hình quan trọng: - tensor_parallel_size: Phân phối mô hình trên các GPU cho các VLM lớn - gpu_memory_utilization: Cân bằng giữa thông lượng và dự phòng - max_model_len: Tính đến các token hình ảnh trong ngân sách ngữ cảnh

TensorRT-LLM đa phương thức

Suy luận tối ưu hóa của NVIDIA với hỗ trợ đa phương thức:¹¹

Các mô hình được hỗ trợ: - Các biến thể LLaVA - Qwen-VL - InternVL - Các kiến trúc ngôn ngữ-thị giác tùy chỉnh

Tính năng tối ưu hóa: - Lượng tử hóa FP8 cho H100/B200 - Tensor parallelism trên các GPU - Batching trong khi bay cho các khối lượng công việc hỗn hợp - Tối ưu hóa bộ mã hóa thị giác

Triton Inference Server

Triển khai các pipeline đa phương thức với Triton:¹²

Yêu cầu từ Client
     │
     ▼
┌─────────────────────┐
│  Triton Ensemble    │
├─────────────────────┤
│  ┌───────────────┐  │
│  │ Image Encoder │  │ (Tiền xử lý thị giác)
│  └───────┬───────┘  │
│          │          │
│  ┌───────▼───────┐  │
│  │  VLM Backend  │  │ (Suy luận mô hình chính)
│  └───────┬───────┘  │
│          │          │
│  ┌───────▼───────┐  │
│  │ Postprocessor │  │ (Định dạng phản hồi)
│  └───────────────┘  │
└─────────────────────┘

Lợi ích: - Điều phối pipeline cho các quy trình công việc phức tạp - Quản lý phiên bản mô hình - Chỉ số và giám sát - Hỗ trợ đa framework

Chiến lược batching

Batching đa phương thức khác với các LLM chỉ xử lý văn bản:¹³

Batching tiền xử lý hình ảnh: Batch mã hóa hình ảnh riêng biệt với sinh văn bản. Các bộ mã hóa thị giác xử lý hình ảnh song song trước khi suy luận LLM.

Batching động với số lượng hình ảnh biến thiên: Các yêu cầu với số lượng hình ảnh khác nhau tạo ra sự phức tạp trong batching. Padding đến số hình ảnh tối đa mỗi batch lãng phí tính toán.

Batching liên tục: PagedAttention của vLLM cho phép batching liên tục cho các mô hình đa phương thức, mặc dù việc xử lý token hình ảnh đòi hỏi quản lý bộ nhớ cẩn thận.

Khuyến nghị: Tách biệt mã hóa hình ảnh khỏi sinh văn bản trong các pipeline sản xuất. Xử lý hình ảnh theo batch, sau đó đưa các embedding thị giác vào LLM cùng với văn bản.

Các mô hình đa phương thức hàng đầu

Các lựa chọn độc quyền

GPT-4V/GPT-4o (OpenAI):¹⁴ - Ngữ cảnh: Lên đến 128K token - Khả năng: Hiểu hình ảnh, phân tích tài liệu, suy luận thị giác - Hạ tầng: Chỉ qua API (không tự lưu trữ) - Giá cả: Theo token với chi phí token hình ảnh

Gemini Pro/Ultra (Google): - Ngữ cảnh: Lên đến 1M token - Khả năng: Đa phương thức gốc (văn bản, hình ảnh, âm thanh, video) - Hạ tầng: Vertex AI hoặc API - Tối ưu hóa: Được tối ưu cho TPU v4/v5

Claude 3.5 (Anthropic): - Ngữ cảnh: 200K token - Khả năng: Hiểu hình ảnh, phân tích tài liệu - Hạ tầng: API hoặc Amazon Bedrock - Thế mạnh: Hiểu tài liệu và biểu đồ

Các lựa chọn mã nguồn mở

Qwen2.5-VL (Alibaba):¹⁵ - Kích thước: 3B, 7B, 72B - Ngữ cảnh: 32K token tiêu chuẩn - Khả năng: Suy luận ngôn ngữ-thị giác, các tác vụ agentic - Hạ tầng: Tự lưu trữ được, hỗ trợ vLLM - Phù hợp nhất cho: Quy trình công việc agentic, triển khai sản xuất

InternVL3 (OpenGVLab): - Kích thước: Lên đến 78B tham số - Khả năng: Hiệu suất gần GPT-4V - Hạ tầng: Trọng số mở hoàn toàn - Phù hợp nhất cho: Thị giác tự lưu trữ chất lượng cao

Llama 3.2 Vision (Meta): - Kích thước: 11B, 90B - Khả năng: Hiểu hình ảnh - Hạ tầng: Hỗ trợ hệ sinh thái rộng - Phù hợp nhất cho: Các tổ chức đã sử dụng Llama

DeepSeek-VL2: - Kiến trúc: MoE với 1-2,8B tham số hoạt động - Hiệu quả: Giảm độ trễ 50-70% so với các mô hình dày đặc - Phù hợp nhất cho: Các triển khai nhạy cảm chi phí

Tiêu chí lựa chọn mô hình

Các mẫu triển khai sản xuất

Triển khai đám mây

Suy luận GPU đơn (mô hình nhỏ):

# Kubernetes pod cho VLM 7B
resources:
  limits:
    nvidia.com/gpu: 1
    memory: "32Gi"
  requests:
    nvidia.com/gpu: 1
    memory: "24Gi"

Suy luận đa GPU (mô hình lớn):

# Kubernetes deployment cho VLM 72B
resources:
  limits:
    nvidia.com/gpu: 4  # 4× H100 cho 72B FP8
    memory: "512Gi"

Cân nhắc về tự động mở rộng: - Khởi động nguội VLM chậm hơn (tải bộ mã hóa thị giác + LLM) - Duy trì các instance ấm cho các khối lượng công việc nhạy cảm độ trễ - Mở rộng dựa trên sử dụng GPU và độ sâu hàng đợi

Triển khai biên

Triển khai VLM biên cho phép trí tuệ thị giác trên thiết bị:¹⁶

Triển khai RamaLama: Triết lý container-native đơn giản hóa triển khai biên:

# Triển khai VLM đến thiết bị biên
ramalama run qwen2.5-vl-3b

# Tạo artifact triển khai cho Kubernetes
ramalama generate --kubernetes qwen2.5-vl-3b

Các mô hình tối ưu cho biên: - Các VLM nhẹ của Mistral cho di động/biên - MiniCPM-V vượt trội GPT-4V trong khi chạy trên điện thoại - DeepSeek-VL2 MoE cho suy luận biên hiệu quả

Các trường hợp sử dụng: - Kính thông minh và kính AR - Trợ lý trong xe hơi - Hệ thống kiểm tra công nghiệp - Tự động hóa bán lẻ

[Nội dung bị cắt ngắn để dịch]