CoreWeave đặt PostgreSQL trong cụm Kubernetes chạy AI

Một trợ lý AI có thể dùng GPU để đọc và tạo văn bản, nhưng trước mỗi bước nó vẫn phải hỏi cơ sở dữ liệu xem công việc đang ở đâu, ai có quyền và hành động nào đã hoàn tất. Nếu cơ sở dữ liệu ở một nhà cung cấp khác, chuỗi yêu cầu ngắn đó phải đi qua một đường mạng dài hơn. Ngày 11/11/2026, CoreWeave công bố cung cấp rộng rãi dịch vụ PostgreSQL được quản lý chạy bên trong cụm Kubernetes của khách hàng. Sự thay đổi nằm ở vị trí đặt dữ liệu và cách vận hành, không phải ở việc biến PostgreSQL thành phần mềm chạy trên GPU.

Ứng dụng AI đi tới cơ sở dữ liệu nhiều lần vì sao?

PostgreSQL là hệ quản trị cơ sở dữ liệu quan hệ, nơi ứng dụng lưu và truy vấn những bản ghi có cấu trúc. Một công cụ theo dõi quá trình huấn luyện có thể ghi cấu hình, số liệu đo và liên kết tới tệp kết quả. Một trợ lý xử lý công việc nhiều bước có thể đọc trạng thái trước khi gọi công cụ và ghi lại kết quả sau đó. Dù tác vụ nặng chạy trên GPU, các lượt trao đổi ngắn với dữ liệu vẫn nằm trong đường đi của một yêu cầu.

Khi mỗi bước phải đợi bước trước, phần thời gian chờ có thể cộng dồn. Giả sử một tác vụ phải thực hiện nhiều lượt đọc và ghi nối tiếp, rút ngắn đường mạng có thể giúp rõ hơn so với một tác vụ chỉ đọc một lần rồi chạy tính toán lâu. Đây là khác biệt về cấu trúc công việc, không phải kết quả đo của CoreWeave. Với ứng dụng đang chậm vì câu truy vấn quét nhiều bản ghi hoặc vì kết nối chờ khóa, đưa máy tới gần dữ liệu không xử lý được nguyên nhân đó.

Cùng cụm nhưng khác máy và khác loại tài nguyên

Theo bài giới thiệu của CoreWeave, cơ sở dữ liệu chạy trên các nút CPU. Ứng dụng kết nối qua một địa chỉ dịch vụ nội bộ của cụm. Các công việc cần GPU tiếp tục dùng các nút dành cho tính toán tăng tốc. Cách bố trí này giúp đội vận hành không phải mở đường kết nối tới một nhà cung cấp cơ sở dữ liệu khác chỉ để thực hiện truy vấn thường xuyên.

Cùng cụm không có nghĩa ứng dụng và cơ sở dữ liệu ở cùng máy, hoặc mọi truy vấn đi qua cùng một đường truyền. Đội vẫn cần xem vị trí của các bản sao, đường truyền tới bộ lưu trữ và việc chia sẻ tài nguyên. Bảng số liệu trung bình cũng có thể che mất những lúc phản hồi rất chậm. Một phép đo có ích nên so cùng loại truy vấn dưới tải đại diện, xem độ trễ của các yêu cầu chậm và tách thời gian chờ mạng khỏi thời gian xử lý trong cơ sở dữ liệu.

Dịch vụ quản lý làm thay phần nào?

CoreWeave cho biết dịch vụ dùng CloudNativePG, phần mềm điều phối PostgreSQL trong Kubernetes. Dịch vụ có máy chính, bản sao đọc, chuyển vai khi máy chính gặp sự cố và lưu dữ liệu trên hệ thống lưu trữ phân tán của hãng. CoreWeave quản lý vá lỗi, sao lưu và khôi phục theo thời điểm trong khoảng lưu giữ. Khách hàng vẫn quyết định cấu trúc dữ liệu, truy vấn, tài khoản và quyền truy cập. Ví dụ, đội ứng dụng phải sửa câu truy vấn tốn tài nguyên hoặc thu hồi tài khoản cấp quá rộng; đây không phải việc bản sao tự giải quyết.

Chuyển vai và khôi phục theo thời điểm trả lời hai câu hỏi khác nhau. Nếu máy chính ngừng hoạt động, một bản sao có thể tiếp nhận vai trò chính để dịch vụ tiếp tục. Nếu ứng dụng ghi sai dữ liệu và thay đổi đã lan tới bản sao, việc đổi máy chính không đưa dữ liệu về trước thời điểm ghi sai. Lúc đó mới cần khôi phục từ bản sao lưu và nhật ký thay đổi. Tài liệu CloudNativePG cũng phân biệt các lựa chọn sao chép; không nên suy ra mọi cấu hình đều giữ được mọi giao dịch trong mọi kiểu sự cố.

Khi nào nên giữ cơ sở dữ liệu ở vị trí hiện tại?

Nếu phần lớn ứng dụng ở CoreWeave và thường xuyên chờ dữ liệu, đưa cơ sở dữ liệu vào cùng cụm đáng thử. Nhưng nếu nhiều dịch vụ ngoài cụm cũng cần cùng nguồn dữ liệu, chuyển vị trí có thể làm một nhóm nhanh hơn và khiến nhóm khác phải đi xa hơn. Việc chuyển còn ảnh hưởng tới cách cấp quyền, sao lưu và kết nối. Đội kỹ thuật cần lập bản đồ những thành phần đọc và ghi trước khi chọn nơi đặt, thay vì chỉ nhìn một dịch vụ AI nổi bật.

Gom nhiều thành phần vào cùng nền tảng cũng thay đổi phạm vi sự cố. Các bản sao trên nhiều máy giúp chống hỏng một máy, nhưng đội phải hỏi chuyện gì xảy ra khi cụm, mạng hoặc khu vực không truy cập được. Đừng chỉ xác nhận rằng có bản sao lưu. Hãy thử khôi phục dữ liệu vào môi trường riêng, đo thời gian và kiểm tra ứng dụng thực sự đọc được dữ liệu ở mốc mong muốn. Khi thử chuyển, cần kiểm tra cả các phần mở rộng PostgreSQL, cách kết nối và kế hoạch đưa dữ liệu ra nếu sau này đổi nền tảng.

CoreWeave Database giảm một đường kết nối và chuyển một số việc vận hành cho nhà cung cấp. Lợi ích thực tế sẽ rõ nhất khi đội có thể chỉ ra đường mạng nào đang gây chậm và chứng minh cấu hình mới vẫn đáp ứng yêu cầu phục hồi. Nếu đo được cả hai, quyết định đặt dữ liệu gần hay xa sẽ dựa trên cách ứng dụng hoạt động, thay vì chỉ dựa trên vị trí của GPU.

Nguồn: CoreWeave — công bố dịch vụ ngày 11/11/2026; CoreWeave — thông cáo và phạm vi dịch vụ; CloudNativePG — kiến trúc sao chép và chuyển vai.

Ảnh tư liệu phòng giám sát trung tâm dữ liệu NERSC, không phải cơ sở CoreWeave — Derrick Coetzee. Trang nguồn; CC0 1.0. Dùng nguyên bản.