Tweet
OODA là gì? Vì sao nó quan trọng khi thiết kế một hệ thống AI?
Trong slide này, Cisco sử dụng mô hình OODA Loop để mô tả tư duy thiết kế một hệ thống AI. Đây là một mô hình ra quyết định do Đại tá John Boyd của Không quân Hoa Kỳ phát triển. Ban đầu OODA được dùng trong chiến lược quân sự, nhưng ngày nay được áp dụng rộng rãi trong kinh doanh, an ninh mạng và thiết kế hạ tầng CNTT.
OODA gồm 4 bước lặp liên tục:
Điểm quan trọng là đây không phải quy trình thực hiện một lần, mà là một vòng lặp liên tục. Sau khi hành động, bạn lại quay về quan sát để đánh giá kết quả và điều chỉnh thiết kế.
1. Observe – Quan sát và thu thập thông tin
Đây là giai đoạn quan trọng nhất. Nếu thu thập sai yêu cầu thì toàn bộ thiết kế phía sau sẽ sai.
Một kiến trúc sư hệ thống cần tìm hiểu:
Ví dụ:
Một doanh nghiệp nói:
Đây chưa phải yêu cầu kỹ thuật.
Người thiết kế sẽ tiếp tục đặt câu hỏi:
Observe chính là quá trình thu thập càng nhiều thông tin càng tốt.
2. Orient – Phân tích và định hướng
Sau khi có dữ liệu, bước tiếp theo là phân tích.
Đây là lúc kiến trúc sư đánh giá:
Trong slide Cisco có nhắc đến rất nhiều yếu tố cần cân nhắc: Greenfield hay Brownfield?
Greenfield
Brownfield
Điều này ảnh hưởng rất lớn đến thiết kế.
Single Site hay Multi Site?
Nếu chỉ một Data Center:
Nếu nhiều Data Center:
AI Workload là gì?
Cisco nhấn mạnh phải hiểu vòng đời của AI:
Training
↓
Inference
↓
Serving
Mỗi workload sẽ cần kiến trúc mạng khác nhau.
On-premise, Cloud hay Hybrid?
Đây là một trong những quyết định lớn nhất.
Ví dụ:
Training:
Inference:
=> Hybrid trở thành lựa chọn tối ưu.
3. Decide – Ra quyết định
Sau khi phân tích, kiến trúc sư sẽ lựa chọn phương án phù hợp nhất.
Ví dụ:
Không phải doanh nghiệp nào cũng cần:
Nếu chỉ phục vụ chatbot nội bộ cho vài nghìn người dùng thì một hạ tầng Ethernet tốc độ 25G hoặc 100G cùng Kubernetes đã có thể đáp ứng tốt.
Ngược lại, nếu xây dựng cụm AI huấn luyện hàng trăm GPU thì cần thiết kế hoàn toàn khác, với các công nghệ như Leaf-Spine, RDMA và RoCE.
Mục tiêu của bước này là chọn giải pháp phù hợp với nhu cầu, thay vì chạy theo công nghệ mới nhất.
4. Act – Triển khai
Sau khi đã quyết định:
Nhưng đây chưa phải là kết thúc.
Sau khi triển khai:
Nếu hệ thống chưa đạt mục tiêu, bạn sẽ quay trở lại bước Observe để tiếp tục cải tiến.
Ví dụ thực tế
Giả sử doanh nghiệp muốn triển khai AI để phân tích camera trong nhà máy.
Observe
↓
Orient
↓
Decide
↓
Act
Đây chính là một chu kỳ OODA hoàn chỉnh.
Kết luận
OODA không chỉ là một mô hình ra quyết định, mà còn là tư duy thiết kế hệ thống hiện đại. Thay vì vội vàng chọn công nghệ, kiến trúc sư cần liên tục quan sát – phân tích – ra quyết định – triển khai, rồi quay lại đánh giá và cải tiến.
Đối với các hệ thống AI, nơi yêu cầu về GPU, băng thông, độ trễ và chi phí có thể thay đổi rất nhanh, OODA giúp đảm bảo kiến trúc luôn phù hợp với nhu cầu thực tế, tránh đầu tư dư thừa và dễ dàng thích ứng khi workload hoặc mục tiêu kinh doanh thay đổi.
Trong slide này, Cisco sử dụng mô hình OODA Loop để mô tả tư duy thiết kế một hệ thống AI. Đây là một mô hình ra quyết định do Đại tá John Boyd của Không quân Hoa Kỳ phát triển. Ban đầu OODA được dùng trong chiến lược quân sự, nhưng ngày nay được áp dụng rộng rãi trong kinh doanh, an ninh mạng và thiết kế hạ tầng CNTT.
OODA gồm 4 bước lặp liên tục:
- Observe (Quan sát)
- Orient (Định hướng, phân tích)
- Decide (Ra quyết định)
- Act (Hành động)
Điểm quan trọng là đây không phải quy trình thực hiện một lần, mà là một vòng lặp liên tục. Sau khi hành động, bạn lại quay về quan sát để đánh giá kết quả và điều chỉnh thiết kế.
1. Observe – Quan sát và thu thập thông tin
Đây là giai đoạn quan trọng nhất. Nếu thu thập sai yêu cầu thì toàn bộ thiết kế phía sau sẽ sai.
Một kiến trúc sư hệ thống cần tìm hiểu:
- Mục tiêu kinh doanh là gì?
- Hệ thống AI dùng để làm gì?
- Bao nhiêu người sử dụng?
- Khối lượng dữ liệu là bao nhiêu?
- Dữ liệu nằm ở đâu?
- Yêu cầu bảo mật thế nào?
- SLA là bao nhiêu?
- Có yêu cầu HA hay DR không?
Ví dụ:
Một doanh nghiệp nói:
"Chúng tôi muốn xây dựng AI."
Đây chưa phải yêu cầu kỹ thuật.
Người thiết kế sẽ tiếp tục đặt câu hỏi:
- AI để chatbot hay Computer Vision?
- Huấn luyện mô hình hay chỉ suy luận (Inference)?
- Bao nhiêu GPU?
- Có cần xử lý video thời gian thực?
- Có dữ liệu nhạy cảm không?
Observe chính là quá trình thu thập càng nhiều thông tin càng tốt.
2. Orient – Phân tích và định hướng
Sau khi có dữ liệu, bước tiếp theo là phân tích.
Đây là lúc kiến trúc sư đánh giá:
- đâu là yêu cầu thật sự
- đâu là giới hạn
- đâu là ưu tiên
Trong slide Cisco có nhắc đến rất nhiều yếu tố cần cân nhắc: Greenfield hay Brownfield?
Greenfield
- xây dựng hoàn toàn mới
- tự do lựa chọn công nghệ
Brownfield
- phải tích hợp với hệ thống hiện có
- bị giới hạn bởi hạ tầng cũ
Điều này ảnh hưởng rất lớn đến thiết kế.
Single Site hay Multi Site?
Nếu chỉ một Data Center:
- đơn giản
- ít chi phí
Nếu nhiều Data Center:
- cần replication
- routing phức tạp hơn
- DR
- HA
- đồng bộ dữ liệu
AI Workload là gì?
Cisco nhấn mạnh phải hiểu vòng đời của AI:
Training
- dùng nhiều GPU
- băng thông rất lớn
- độ trễ cực thấp
↓
Inference
- ít GPU hơn
- nhiều request từ người dùng
↓
Serving
- phân phối mô hình
- mở rộng theo số lượng client
Mỗi workload sẽ cần kiến trúc mạng khác nhau.
On-premise, Cloud hay Hybrid?
Đây là một trong những quyết định lớn nhất.
Ví dụ:
Training:
- GPU cực đắt
- có thể thuê Cloud
Inference:
- dữ liệu nhạy cảm
- triển khai On-prem
=> Hybrid trở thành lựa chọn tối ưu.
3. Decide – Ra quyết định
Sau khi phân tích, kiến trúc sư sẽ lựa chọn phương án phù hợp nhất.
Ví dụ:
Không phải doanh nghiệp nào cũng cần:
- 400Gb Ethernet
- InfiniBand
- EVPN VXLAN
- RoCE
Nếu chỉ phục vụ chatbot nội bộ cho vài nghìn người dùng thì một hạ tầng Ethernet tốc độ 25G hoặc 100G cùng Kubernetes đã có thể đáp ứng tốt.
Ngược lại, nếu xây dựng cụm AI huấn luyện hàng trăm GPU thì cần thiết kế hoàn toàn khác, với các công nghệ như Leaf-Spine, RDMA và RoCE.
Mục tiêu của bước này là chọn giải pháp phù hợp với nhu cầu, thay vì chạy theo công nghệ mới nhất.
4. Act – Triển khai
Sau khi đã quyết định:
- thiết kế topology
- chọn switch
- chọn NIC
- chọn GPU
- cấu hình routing
- triển khai automation
- kiểm thử
- đưa vào vận hành
Nhưng đây chưa phải là kết thúc.
Sau khi triển khai:
- theo dõi latency
- throughput
- GPU utilization
- packet loss
- congestion
- chi phí vận hành
Nếu hệ thống chưa đạt mục tiêu, bạn sẽ quay trở lại bước Observe để tiếp tục cải tiến.
Ví dụ thực tế
Giả sử doanh nghiệp muốn triển khai AI để phân tích camera trong nhà máy.
Observe
- 1.000 camera
- Video 4K
- AI nhận diện lỗi sản phẩm
- Phản hồi dưới 100 ms
↓
Orient
- cần inference thời gian thực
- dữ liệu không được đưa lên Cloud
- độ trễ thấp
- cần GPU tại Edge
↓
Decide
- triển khai Edge AI
- sử dụng Leaf-Spine Ethernet 100G
- Kubernetes
- lưu trữ cục bộ
- kết nối về Data Center để quản lý
↓
Act
- triển khai hệ thống
- đo độ trễ
- tối ưu QoS
- theo dõi hiệu năng
- điều chỉnh khi cần
Đây chính là một chu kỳ OODA hoàn chỉnh.
Kết luận
OODA không chỉ là một mô hình ra quyết định, mà còn là tư duy thiết kế hệ thống hiện đại. Thay vì vội vàng chọn công nghệ, kiến trúc sư cần liên tục quan sát – phân tích – ra quyết định – triển khai, rồi quay lại đánh giá và cải tiến.
Đối với các hệ thống AI, nơi yêu cầu về GPU, băng thông, độ trễ và chi phí có thể thay đổi rất nhanh, OODA giúp đảm bảo kiến trúc luôn phù hợp với nhu cầu thực tế, tránh đầu tư dư thừa và dễ dàng thích ứng khi workload hoặc mục tiêu kinh doanh thay đổi.
Attached Files