- CommaAI thực hiện toàn bộ việc huấn luyện mô hình và xử lý dữ liệu trong trung tâm dữ liệu riêng, đồng thời trực tiếp vận hành hạ tầng trị giá khoảng 5 triệu USD
- Phụ thuộc vào cloud có thể dẫn đến chi phí tăng cao và mất quyền kiểm soát, trong khi tự vận hành compute giúp nâng cao chất lượng kỹ thuật và giảm chi phí
- Trung tâm dữ liệu được cấu thành từ khoảng 450kW điện năng, 600 GPU, 4PB SSD storage, cùng cấu trúc làm mát và mạng đơn giản
- Stack phần mềm được thiết kế với Ubuntu + Salt, storage minikeyvalue(mkv), scheduler Slurm, huấn luyện phân tán PyTorch, và compute phân tán miniray
- comma.ai thông qua cấu trúc này đã tự động hóa hoàn toàn việc huấn luyện mô hình lái xe tự động, đồng thời đạt mức tiết kiệm chi phí khoảng 5 lần so với cloud
Lý do vận hành trung tâm dữ liệu riêng
- Nếu phụ thuộc vào cloud sẽ phát sinh chi phí gia tăng và bị khóa vào nhà cung cấp
- Các công ty cloud thiết kế để onboarding thì dễ nhưng offboarding lại khó
- Khi sử dụng liên tục, rất dễ bị mắc kẹt trong cấu trúc chi phí cao
- Tự vận hành compute thúc đẩy năng lực tự chủ công nghệ và văn hóa kỹ thuật hiệu quả
- Cloud đòi hỏi quản lý xoay quanh API và hệ thống thanh toán, còn trung tâm dữ liệu yêu cầu giải quyết các bài toán kỹ thuật thực tế xoay quanh điện năng, tính toán và băng thông
- Xét ở góc độ kỹ thuật ML, ràng buộc tài nguyên cũng thúc đẩy tối ưu code và cải tiến tận gốc
- Trên cloud, người ta thường chỉ tăng ngân sách để giải quyết, nhưng với hạ tầng tự có thì cải thiện hiệu năng là bắt buộc
- Về chi phí, comma.ai đã đầu tư khoảng 5 triệu USD; họ ước tính nếu thực hiện cùng khối lượng công việc trên cloud thì sẽ cần hơn 25 triệu USD
Các thành phần của trung tâm dữ liệu
-
Điện năng
- Mức sử dụng tối đa 450kW, chi phí điện năm 2025 là 540.112 USD
- Đơn giá điện tại San Diego là 40 cent/kWh, cao gấp 3 lần mức trung bình toàn cầu
- Có đề cập kế hoạch tự sản xuất điện trong tương lai
-
Làm mát
- Sử dụng phương thức làm mát bằng không khí ngoài trời, hiệu quả điện năng hơn hệ thống CRAC
- Tuần hoàn không khí bằng 2 quạt hút và 2 quạt xả 48 inch
- Vòng điều khiển PID tự động điều chỉnh nhiệt độ và độ ẩm (duy trì dưới 45%)
- Mức tiêu thụ điện ở quy mô vài chục kW
-
Máy chủ và storage
- Gồm 75 TinyBox Pro (tổng cộng 600 GPU), do công ty tự chế tạo
- Mỗi thiết bị có 2 CPU + 8 GPU, dùng cho huấn luyện và tính toán tổng quát
- Tự chế tạo giúp dễ bảo trì
- Storage dựa trên Dell R630/R730, tổng cộng 4PB SSD
- Cấu trúc không dự phòng (non-redundant), tốc độ đọc 20Gbps mỗi node
- Mạng gồm 3 switch Z9264F 100Gbps và 2 switch Infiniband
Hạ tầng phần mềm
-
Thiết lập cơ bản
- Tất cả server dùng Ubuntu + PXE boot, được quản lý bằng Salt
- Duy trì 99% uptime với cấu trúc single master
-
Storage phân tán — minikeyvalue (mkv)
- Lưu trữ dữ liệu lái xe phục vụ huấn luyện trên 3PB storage không dự phòng
- Tốc độ đọc 1TB/s, có thể huấn luyện trực tiếp mà không cần caching
- Có mảng 300TB cho cache và mảng lưu trữ dự phòng để lưu model cùng metric
- Mỗi mảng được quản lý bởi một server master duy nhất
-
Quản lý job — Slurm
- Lập lịch cho các job huấn luyện PyTorch và các job phân tán miniray
-
Huấn luyện phân tán — PyTorch + FSDP
- Vận hành hai phân vùng huấn luyện được kết nối bằng mạng Infiniband
- Tự động hóa training loop bằng framework huấn luyện nội bộ
- Cung cấp dịch vụ theo dõi thí nghiệm mô hình
-
Compute phân tán — miniray
- Task scheduler mã nguồn mở gọn nhẹ, chạy Python code trên các máy nhàn rỗi
- Đơn giản hơn Dask, quản lý task bằng Redis server trung tâm
- GPU worker thực hiện suy luận mô hình bằng Triton Inference Server
- Có thể mở rộng song song lên hàng trăm máy
- Ví dụ: kỷ lục Controls Challenge đã đạt được chỉ với 1 giờ sử dụng trung tâm dữ liệu
-
Quản lý code — monorepo dựa trên NFS
- Toàn bộ codebase dưới 3GB, được sao chép tới mọi workstation
- Khi bắt đầu công việc, đồng bộ code và package cục bộ, hoàn tất trong vòng 2 giây
- Đảm bảo mọi job phân tán đều chạy trong cùng một code và môi trường
Pipeline huấn luyện tích hợp
- Công việc phức tạp nhất tại comma là huấn luyện mô hình lái xe theo phương pháp on-policy
- Để thực hiện kiểu huấn luyện này, cần chạy mô phỏng lái xe với trọng số mô hình mới nhất để tạo dữ liệu huấn luyện
- Toàn bộ pipeline có thể được chạy bằng một lệnh duy nhất như sau
./training/train.sh N=4 partition=tbox2 trainer=mlsimdriving dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 data.shuffle_size=125k optim.scheduler=COSINE bs=4
- Khi chạy quá trình huấn luyện này, toàn bộ hạ tầng đã mô tả ở trên đều được sử dụng
- Chỉ là một lệnh đơn giản, nhưng nó đóng vai trò điều phối nhiều thành phần khác nhau
Kết luận
- comma.ai đã đạt được giảm chi phí và tự chủ công nghệ bằng cách vận hành trung tâm dữ liệu riêng
- Cùng cách tiếp cận này, doanh nghiệp hoặc cá nhân cũng có thể tự xây dựng hạ tầng riêng
3 bình luận
Bộ nhớ đắt lắm mà!
kkkkkkkkkkkkkkkk
Ý kiến Hacker News
Trong ngành của chúng ta, sở hữu vs cloud nằm ở hai đầu của một phổ
① Cloud có chi phí đầu tư ban đầu (capex) và gánh nặng nhân sự thấp, nhưng chi phí vận hành (opex) cao và biến động lớn
② Managed Private Cloud là việc chúng tôi đang làm: quản lý dựa trên mã nguồn mở và rẻ hơn AWS khoảng 50%
③ Rented Bare Metal là mô hình đứng ra lo phần tài chính cho phần cứng, rẻ hơn AWS 90%
④ Mua trực tiếp rồi colocate là cách rẻ nhất nếu bạn có đủ năng lực kỹ thuật và quy mô
Các công ty như Hetzner vận hành dựa trên ROI 3 năm, và lựa chọn 3~4 phù hợp với doanh nghiệp có quy mô lớn hoặc xem hạ tầng là cốt lõi
Startup thực tế hơn với phương án 1, còn doanh nghiệp vừa và nhỏ phù hợp với phương án 2 (lithus.eu)
Vấn đề là cấu trúc chi phí của cloud không chỉ đến từ giá phần cứng, mà còn do nó dẫn dắt người dùng vào kiến trúc phức tạp, làm tăng sự kém hiệu quả
Các ‘managed service’ của AWS có cấu trúc khiến doanh thu của AWS giảm đi nếu người dùng tối ưu hiệu quả máy chủ
Nếu chỉ đơn giản là đặt 4 Java server và một DB nhân bản trên EC2 thì sẽ hiệu quả hơn nhiều
Cuối cùng, hóa đơn AWS vô lý xuất hiện khi bạn lạm dụng vô số dịch vụ của họ
(derek@ của Carolina Cloud) Chúng tôi cũng thích mô hình (4), nhưng những người dùng thiếu năng lực kỹ thuật sẽ dừng ở 1~3 và bị mắc kẹt trong cấu trúc chi phí cao của public cloud
Nghe thì là trả theo mức dùng, nhưng thực tế còn có phí cơ bản và mức dùng tối thiểu, nên đắt hơn rất nhiều (carolinacloud.io)
Hetzner là một lựa chọn hấp dẫn
Việc phải tự quản lý các dịch vụ như Postgres hay VPN là một gánh nặng, nhưng nếu chi hơn 10.000~15.000 USD/tháng thì có lợi hơn AWS
Có rủi ro, nhưng đáng để chấp nhận
Tôi đang thuê một máy chủ bare metal giá 500 USD/tháng, và thời gian quản trị chỉ vài giờ mỗi năm
Có thể là vì yêu cầu của tôi đơn giản, nhưng tôi vẫn thấy nó tốt hơn cloud quá phức tạp rất nhiều
Tôi đã chuyển sang colocate từ 2 năm trước, và giờ có dung lượng lớn hơn với 30% chi phí
Cũng có lợi từ việc giá RAM/lưu trữ giảm theo thời gian
Tuy vậy, quản lý compliance cần được chú ý hơn một chút
Ngày trước người ta chỉ gọi đây là data center
Đây là khái niệm đã có từ trước khi có cloud, và rốt cuộc chỉ là sự lặp lại của sở hữu vs thuê, tập trung hóa vs phân tán hóa
Khi doanh nghiệp chọn cực đoan hẳn về một phía, họ sẽ lại gặp những vấn đề cũ
Điều thú vị là cloud từng hấp dẫn đội tài chính vì hiệu quả giảm thuế
Nhưng gần đây, với đạo luật mới (OBB) cho phép hạch toán CapEx như chi phí, xu hướng quay lại on-prem đang nổi lên
Vậy tại sao không xuất hiện giải pháp thay thế cloud có giá cạnh tranh?
AWS và Azure thống trị thị trường nên không có động lực giảm giá, còn Google thì có rủi ro khai tử dịch vụ quá lớn
Trước thời cloud, đội hạ tầng nội bộ là nút thắt cổ chai
Cloud đã chuẩn hóa điều này và đơn giản hóa bằng hệ thống billing thống nhất
Ngoài ra, ở các khu vực ngoài Mỹ, việc mua sắm server chậm hơn nên lợi thế về tốc độ của cloud càng lớn
Data center on-prem có gánh nặng vận hành lớn và tiêu tốn nhiều nguồn lực kỹ thuật
Vì thế cuộc tranh luận này cứ lặp đi lặp lại
Đổi mới thực sự của cloud là “làm cho chi phí theo từng dịch vụ trở nên rõ ràng”
Thay vì kiểu ngày xưa là “phải nhờ ai đây?”, giờ có thể truy cập qua API
Bối cảnh liên quan được tóm tắt khá hay trong bài viết này
Ngay cả ở nơi dễ điều hòa nhiệt độ như San Diego, làm mát bằng không khí ngoài trời vẫn rủi ro
Độ ẩm và chất ô nhiễm sẽ làm hỏng server nhanh chóng
Thay vào đó, các cách như enthalpy wheel cooler (kyotocooling) hiệu quả hơn và tiêu thụ ít điện hơn so với hiệu quả làm mát đạt được
Cần cẩn trọng vì làm mát bằng không khí ngoài trời có nguy cơ làm giảm tuổi thọ thiết bị rất lớn
Cũng có trường hợp đạt kết quả khá tốt nhờ lọc khí và giữ độ ẩm dưới 45%
Tôi không biết là phải để ý đến những chuyện như vậy
Vì thế tôi cứ dùng cloud thôi — có thể tránh được những kiểu ‘rủi ro mình không biết’ này
Kết hợp on-prem và cloud là hướng thực tế
Hạ tầng cốt lõi giao cho một cloud đáng tin cậy, còn những thứ như job Slurm thì chạy trên server riêng
Colocation vẫn là một lựa chọn còn nguyên giá trị, và HPC phục vụ nghiên cứu cũng đáng để cân nhắc
Ở Na Uy, ngay cả doanh nghiệp tư nhân cũng có thể trả phí để dùng HPC nghiên cứu
Tôi từng vận hành server farm ở hai khu vực tại Ý, với 5 nhân viên quản lý và duy trì gần 100% uptime
Với 800.000 euro mỗi năm, chúng tôi tiết kiệm được 7~8 triệu euro chi phí cloud
Nhiều developer lầm tưởng rằng mình không thể tự host
Thực ra nó dễ hơn nghĩ nhiều, và còn có cái thú của việc giải quyết các vấn đề kỹ thuật
Nếu thuê không gian ở những nơi như Equinix hay Global Switch, họ sẽ lo hết điện, làm mát, cáp mạng...
Ngay cả việc tự có phòng server ở hai khu vực cũng hoàn toàn khả thi
Chúng tôi vẫn dùng Azure cho các dịch vụ hướng tới người dùng
Những web service không cần GPU thì cloud hiệu quả hơn
GitHub cũng vẫn đang được dùng như một dịch vụ đáng tin cậy
(nói đùa) Đã từng có lúc Postgres daemon vướng vào Slurm pool khiến Rust bùng nổ
Cuối cùng cũng ổn định lại được, nhưng từ góc nhìn của kỹ sư phần cứng thì thế giới phần mềm thật hỗn loạn
Ở giai đoạn đầu dự án, hãy bắt đầu với AWS ở mức 250 USD/tháng, rồi khi lên đến 30.000 USD/tháng thì chuyển sang colocation
Cốt lõi là khả năng tính toán chi phí — kỹ sư giỏi phải có thể dựa vào đó để đề xuất với ban lãnh đạo
Không chỉ là tính toán đơn thuần, mà còn phải cân nhắc muốn thu hút kiểu nhân tài nào và xây dựng kiểu kinh doanh nào
Nếu là công ty huấn luyện mô hình ML, hạ tầng riêng có thể phù hợp hơn
Nhưng ở đa số công ty, kỹ sư không thể tham gia vào việc chọn nền tảng
Trong 99.999999% trường hợp, ban lãnh đạo đã quyết rồi mới thông báo xuống
Đầu sự nghiệp, cloud là lựa chọn hiển nhiên, nhưng giờ on-prem lại đang thịnh hành trở lại
Có khi 10 năm nữa xu hướng lại đảo chiều lần nữa
Theo kinh nghiệm của tôi, các team ủng hộ on-prem luôn đánh giá thấp sự mệt mỏi vì bảo trì
Ở những nơi cần phát triển nhanh như startup, nó lại càng dễ trở thành lực cản
Ngược lại, với công ty đã vào chế độ duy trì, on-prem lại hiệu quả
Càng lớn tuổi, người ta càng coi trọng việc “làm cho xong nhanh, đúng ngân sách”, và sức hấp dẫn của việc tự vận hành hạ tầng cũng giảm đi
Tôi nghĩ làn sóng lần này không chỉ là chu kỳ công nghệ đơn thuần, mà là phản ứng trước một xã hội không thể sở hữu
Khi âm nhạc, nhà cửa, xe cộ đều thành mô hình thuê bao, doanh nghiệp cũng bắt đầu muốn giành lại chủ quyền điện toán
Kiểu chu kỳ này lúc nào cũng tồn tại
Từ mainframe → PC → phòng server → cloud → edge computing, đó là sự lặp lại của tập trung hóa ↔ phân tán hóa
Cuối cùng, khi công nghệ và ưu tiên thay đổi, mọi thứ lại quay trở lại
Khi câu “mạng là máy tính” lại xuất hiện, nghĩa là bánh xe đã quay trọn thêm một vòng nữa
(nói đùa) Có lẽ bước tiếp theo sẽ là giai đoạn space (Skynet)
Lý do hầu hết doanh nghiệp tránh on-prem là vì quản trị rủi ro
Doanh nghiệp giỏi sẽ tập trung rủi ro vào năng lực cạnh tranh cốt lõi
Không nên đánh giá chỉ bằng chi phí đơn thuần, mà phải nhìn theo chi phí đã điều chỉnh theo rủi ro
Nhưng dạo này tôi còn nghi ngờ liệu doanh nghiệp có đủ năng lực để đánh giá chính xác rủi ro đó hay không
Vì năng lực cạnh tranh về giá cuối cùng cũng là một yếu tố khác biệt hóa
Cốt lõi là tập trung vào nghiệp vụ chính
Nếu nó không giúp bán tốt hơn những sản phẩm vốn bán không được, thì đừng lãng phí thời gian vào data center
Chỉ những trường hợp như Google, nơi bản thân hạ tầng là lợi thế cạnh tranh của sản phẩm, mới là ngoại lệ
Rốt cuộc, trong đa số trường hợp, đây là cuộc chiến mà Opex thắng Capex
Lợi thế thật sự của on-prem là tự do, kiểm soát và quyền riêng tư
Đây không chỉ là chuyện tiền bạc, mà giống như chuyện sở hữu nhà hay đi thuê
Giáo điều kiểu MBA trong thập niên 2010 là “hãy chuyển mọi thứ lên cloud”
Chuyển rủi ro và chi phí cho bên thứ ba được xem là đáp án đúng
Nhưng thực tế thì data center của chúng tôi rẻ hơn rất nhiều, và tốc độ tăng giá của phí thuê bao phần mềm còn cao hơn phần cứng rất nhiều
Nhưng nếu tính cả nhân công và chi phí quản lý thì việc so sánh chi phí đơn thuần là vô nghĩa
Chỉ một cơn lốc xoáy cũng có thể thổi bay cả công ty, nên cuối cùng vẫn phải đánh giá theo giá trị so với rủi ro