AI Infrastructure gồm những gì? #22

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: AI Infrastructure là tập hợp tài nguyên và control giúp đội ngũ chuẩn bị dữ liệu, deploy ứng dụng, gọi model, lưu state, bảo vệ kết nối và quan sát hệ thống AI khi chạy thật. Nó gồm hai đường build/ingest và serving, cùng các nền tảng dùng chung; GPU chỉ là một lựa chọn compute.

Đọc xong, bạn sẽ hiểu:

• Vì sao hạ tầng AI không chỉ là GPU, model endpoint hay vector database.
• Hai đường build/ingest và serving khác nhau ở input, công suất và failure mode.
• Cách lập Capacity & Ownership Matrix trước khi chọn cloud service.

1. AI Infrastructure là gì, và vì sao không chỉ là GPU?

Khi nghe “hạ tầng AI”, nhiều người nghĩ ngay tới GPU. Nhưng một app dùng model qua API có thể không sở hữu GPU nào mà vẫn cần network, runtime, queue, state store, secret, monitoring và pipeline deploy.

AI Infrastructure là phần nền để build, release và vận hành hệ thống AI. Nó biến sơ đồ kiến trúc thành tài nguyên có owner, capacity, dependency, failure mode và evidence.

Có thể hình dung một quán ăn. Bếp lớn không cứu được giờ cao điểm nếu cửa nhận đơn nghẽn, kho thiếu nguyên liệu hoặc quầy trả món không ghi đúng số bàn. Ẩn dụ này chỉ giải thích bottleneck; nó không mô tả chất lượng model.

Hai đường chạy chính:

• build/ingest plane chuẩn bị code, prompt, data, vector đại diện, index và đầu ra release có version;
• online serving plane xử lý request thật từ edge tới response.

Hai plane dùng chung identity, network, secrets, state, queue, observability và delivery. Chúng có thể nằm trên cùng cloud account nhưng không nên dùng chung quyền hoặc capacity budget một cách mơ hồ.

AI Infrastructure không có nghĩa là:

• mọi app phải tự host model;
• mọi hệ thống cần Kubernetes;
• có vector database là có RAG tốt;
• nhiều bản sao tự động tạo khả dụng cao;
• mua GPU lớn nhất sẽ xóa mọi bottleneck.

Bài AI Architecture #20 giải thích ranh giới và control plane. Bài này đi sâu vào nền tài nguyên để các ranh giới đó chạy được.

2. Hai đường chạy: build/ingest và online serving

a. Build/ingest plane

Một flow truy xuất tăng cường (RAG) có thể đi:

SOURCE → PARSE → CHUNK → EMBED → INDEX → VALIDATE → RELEASE

Nguồn dữ liệu được lấy đúng scope, parser tạo text, chunker chia đoạn, embedding job tạo vector, indexer xây index, validator kiểm quality rồi release gate mới promote.

Nếu index v3 chưa pass, serving nên tiếp tục dùng v2. Build failure không được âm thầm làm hỏng đường request đang chạy.

Google Cloud RAG infrastructure reference cũng tách ingestion subsystem khỏi serving subsystem. Đây là một kiến trúc tham khảo dùng RAG và Vector Search, không phải yêu cầu cho mọi app AI.

b. Online serving plane

Đường request có thể đi:

EDGE → API → ORCHESTRATOR → RETRIEVE → MODEL → VERIFY → RESPONSE

Edge xác thực, API gắn trace ID, orchestrator giữ state, retrieval lấy context, model tạo output, verifier kiểm và response trả kết quả. Mỗi chặng có timeout và capacity riêng.

Compute/runtime là nơi app, worker và job chạy. Model endpoint là cửa gọi model; quota là giới hạn công suất được cấp. Scale worker không làm model quota tự tăng.

Queue giữ công việc chờ. Backpressure là cơ chế làm chậm hoặc từ chối có kiểm soát khi downstream đầy. Queue vô hạn chỉ dời lỗi sang độ trễ và chi phí bộ nhớ.

Hình 1 — Hạ tầng AI phải phục vụ cả đường chuẩn bị lẫn đường trả lời người dùng.

Azure reference architecture cho Foundry trong landing zone cho thấy hệ thống AI còn dựa vào networking, identity, policy và monitoring, đồng thời tách trách nhiệm đội ứng dụng và đội nền tảng. Sơ đồ cụ thể là của Azure; nguyên tắc ownership rõ có thể áp dụng rộng hơn.

3. Tám nhóm hạ tầng và contract vận hành

Mỗi component cần trả lời: ai sở hữu, metric capacity nào, phụ thuộc gì, lỗi lan tới đâu và evidence nằm đâu.

1. Edge và network

Ingress là luồng vào; egress là luồng ra. Network policy, firewall và private endpoint giới hạn tuyến kết nối. Evidence gồm denied connection, DNS/egress log và certificate expiry.

2. App compute và worker runtime

App nhận request; worker xử lý job nền. Capacity có thể là concurrent requests, CPU, memory hoặc queue throughput. Kubernetes HPA có thể tăng số Pod theo metric, nhưng resource requests và metric phải tồn tại. Đây là cơ chế cụ thể, không phải khuyến nghị mọi đội dùng Kubernetes.

3. Model access và gateway

Gateway quản lý route, version, quota, timeout và cost. Nếu model là dịch vụ bên ngoài, network và quota trở thành dependency. Fallback chỉ dùng khi policy, quality và budget cho phép.

4. Data, object storage và index

Object storage giữ file; database giữ metadata; index là cấu trúc phục vụ tìm kiếm. Cần version, freshness, ACL, backup và release gate. AWS Generative AI Lens nhấn mạnh data quality, hạ tầng dữ liệu co giãn và data observability.

5. State, cache và queue

State store giữ run state/checkpoint. Cache giảm lặp nhưng cần key và invalidation. Queue tách producer khỏi consumer; capacity của queue không thay capacity downstream.

6. Identity và secrets

Workload identity là danh tính của service. Secret store giữ credential được quản lý. Secret không nằm trong prompt, source code, image hoặc log. Mỗi runtime chỉ nhận quyền tối thiểu cần thiết.

7. Observability và operations

Observability gồm logs, metrics, traces và alerts giúp trả lời hệ thống đang làm gì. Nó cần thời hạn lưu, che dữ liệu nhạy cảm, dashboard có owner và hướng dẫn xử lý. Bài AI Observability #23 sẽ đi sâu phần này.

8. Delivery và infrastructure as code

Infrastructure as code (IaC) là khai báo hạ tầng bằng code. CI/CD là pipeline build, test và deploy đầu ra có version. Release cần đường quay lui, kế hoạch chuyển đổi và evidence, không chỉ “pipeline xanh”.

Hình 2 — Tên service chưa đủ; mỗi component cần contract vận hành.

Case demo INFRA-22: mức thường 60 request/phút (RPM), hai worker, model quota 8 call đồng thời. Khi tải tăng lên 120 RPM, worker scale 2→4 nhưng quota model không đổi. Queue peak 38.

Ở ingest plane, D7 lỗi parser nên index v3 không pass release gate. Serving giữ index v2. Hệ thống bật backpressure, retry parser 1/1, dropped 0, duplicate 0, không bật model fallback. Terminal state là serving_degraded_grounded.

Hình 3 — Scale worker không xóa được bottleneck ở model quota và data release.

Các số trên là demo, không phải benchmark hay mục tiêu ngành.

4. Sai lầm, giới hạn và rủi ro

Sai lầm thứ nhất là scale nhầm lớp. Thêm worker khi model quota nghẽn chỉ làm queue tiến nhanh hơn tới cùng một cổng.

Sai lầm thứ hai là dùng chung dependency mà không ghi owner. Ba bản sao app vẫn cùng lỗi nếu dùng một secret hết hạn, một DNS path hoặc một index hỏng.

Sai lầm thứ ba là gọi backup là recovery. Backup chỉ có giá trị khi restore được kiểm thử và đáp ứng thời gian phục hồi cần thiết.

Failure domain là phạm vi một lỗi có thể lan. Redundancy là có bản sao dự phòng. Hai bản sao cùng vùng, cùng network và model endpoint chưa bảo vệ khỏi mọi failure domain.

Giới hạn: không có stack “chuẩn” cho mọi hệ thống. App 20 request/ngày và app 2.000 request/giây cần quyết định khác nhau. Nhiều vùng, GPU tự host hoặc vector database chỉ nên có khi requirement và evidence biện minh chi phí.

Câu đoán chắc là “thêm Pod sẽ làm hệ thống nhanh”. Câu có điều kiện đúng hơn là “thêm Pod giúp khi app compute là bottleneck và downstream còn capacity”. Nếu metric cho thấy model quota mới là nghẽn, phải nhận giả thuyết scale worker là sai.

5. Checklist và bài tập Capacity & Ownership Matrix

a. Bắt đầu từ đâu?

• Vẽ riêng build/ingest và serving flow.
• Liệt kê component, owner và môi trường.
• Ghi capacity metric, quota và timeout từng hop.
• Ghi dependency, failure domain và fallback.
• Xác định secret/identity/network boundary.
• Gắn logs, metrics, traces, alert owner và runbook.
• Kiểm backup, restore, release và rollback.
• Load test bằng mock trước khi mua capacity.

Đứng ngoài Kubernetes, GPU tự host hoặc nhiều vùng khi chưa có hồ sơ tải và owner vận hành. Dừng triển khai nếu index release, đổi secret hoặc đường phục hồi chưa có evidence.

b. Mẫu đối chiếu

Dùng Google Sheets hoặc Excalidraw miễn phí trong 15 phút:

Trace mẫu INFRA-22: 60→120 rpm, worker 2→4, quota 8, queue peak 38, D7 parser fail, v3 không promote, serving giữ v2, dropped 0, duplicate 0.

Chưa tạo cloud resource, chưa nhập credential và chưa tốn tiền. Kết quả cần có là một bottleneck được nêu bằng metric và owner, không phải danh sách sản phẩm.

6. Tổng kết

a. Năm ý chính

• AI Infrastructure phục vụ cả build/ingest và online serving.
• GPU, model endpoint và vector database chỉ là vài component có điều kiện.
• Mỗi component cần owner, capacity, dependency, failure mode và evidence.
• Scale đúng lớp; queue và bản sao không xóa quota hoặc dependency dùng chung.
• Capacity Matrix nên có trước quyết định mua hoặc deploy hạ tầng.

b. Câu hỏi tự kiểm tra

• Build/ingest plane khác serving plane ở nhiệm vụ nào?
• Vì sao worker 2→4 chưa chắc giải quyết spike?
• Redundancy khác recovery ở đâu?

c. Gợi ý đáp án

Xem gợi ý câu 1

Build/ingest chuẩn bị và release artifact/data; serving xử lý request thật. Xem mục 2.

Xem gợi ý câu 2

Nếu bottleneck là model quota hoặc index, thêm worker không tăng capacity downstream. Xem mục 3.

Xem gợi ý câu 3

Redundancy có bản sao; recovery còn cần phục hồi hoặc chuyển dự phòng được kiểm thử đúng thời gian. Xem mục 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• Azure — Baseline Foundry chat in a landing zone
• Google Cloud — RAG infrastructure reference
• AWS — Generative AI Lens: Data architecture
• Kubernetes — Horizontal Pod Autoscaling

Bài trước, AI Automation #21, dùng control để chạy workflow. Bài tiếp theo, AI Observability #23, sẽ chỉ cách đo và điều tra hạ tầng cùng hành vi AI.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.