CapordiaTập hợp một hồ sơ xuất phát gọn nhẹ nhưng có thể tái dựng
Hãy lưu lại các phiên bản của hệ thống, ứng dụng và các phụ thuộc, quy trình khởi chạy và một bộ nhỏ đại diện. Thêm các đường dẫn mong đợi, các quyền và cách kiểm tra đầu ra. Bản kê này mô tả một mốc tham chiếu đã biết. Với một thay đổi, hãy tạo một phiên bản ứng viên bên cạnh mốc tham chiếu đó; các bí mật vẫn nằm trong hệ thống quản lý truy cập của bạn. Hãy nêu tên các hạng mục còn thiếu và người phụ trách thay vì che giấu chúng sau một dòng “môi trường sẵn sàng”.
Hãy chỉ định một người phụ trách tiếp nhận và một người khác phụ trách quyết định chuyển đổi khi tổ chức của bạn yêu cầu. Họ phải biết các tiêu chí trước khi xử lý mới trở thành phụ thuộc cho phần còn lại của nhóm. Tùy chọn Ubuntu, PyTorch, Blender hay tùy chỉnh được chọn khi đặt hàng định hướng việc chuẩn bị; nó không thay thế bản kiểm kê chính xác ứng dụng của bạn.
Kiểm tra các tài nguyên thực sự hiển thị
Khi nhận bàn giao, hãy đối chiếu mô hình được phát hiện, số lượng card và dung lượng bộ nhớ của chúng với phạm vi mong đợi. Bạn cũng nên ghi nhận các yếu tố cần thiết cho dự án mà chỉ riêng GPU không mô tả được: hệ thống, không gian làm việc, quyền và khả năng truy cập đến các đích đến. Một sai lệch sẽ trở thành một câu hỏi cụ thể cần giải quyết, không nên giả định có năng lực CPU, mạng hay ổ đĩa không có trong bảng thông số.
Trên môi trường NVIDIA có nvidia-smi, lệnh được đề xuất sẽ đọc tên, tổng dung lượng bộ nhớ do công cụ công bố và phiên bản trình điều khiển. Lệnh này không đánh giá hiệu năng cũng như mọi phụ thuộc CUDA. Với AMD, hãy dùng tài liệu tương ứng với phần cứng và tổ hợp ROCm đã chọn; tránh áp dụng một kiểm tra NVIDIA như bằng chứng cho thấy MI300X hoạt động.
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csvThực hiện một lượt đầy đủ với các tiêu chí riêng biệt
Hãy lần lượt kiểm tra quyền truy cập, cấu hình, tải dữ liệu, thực thi và xuất kết quả. Với mỗi bước, ghi lại một quan sát và một quyết định. Một chương trình kết thúc không lỗi chưa chắc đã tạo ra đầy đủ các tệp mong đợi. Ngược lại, việc hiển thị đúng card không chứng minh phần mềm đang dùng GPU đã chọn.
Hãy xác định kết quả chấp nhận được trước khi thử nghiệm. Đó có thể là số lượng thư mục chính xác, một hình ảnh được kiểm tra bằng mắt hoặc một tiêu chí số. PyTorch lưu ý rằng không đảm bảo khả năng tái lập hoàn toàn giữa các phiên bản và nền tảng. Vì vậy, hãy chọn dung sai phù hợp với công việc cùng người phụ trách; đừng nới rộng nó sau đó chỉ để cho bài kiểm tra đạt.
| Bước | Quan sát mong đợi | Quyết định nếu thất bại |
|---|---|---|
| Truy cập | Người được phép truy cập đúng môi trường | Sửa quyền truy cập trước khi nhập |
| Tải dữ liệu | Mọi đầu vào của bộ dữ liệu thử đều đọc được | Sửa gói hoặc quyền của nó |
| Thực thi | Quá trình xử lý dùng đúng tài nguyên dự kiến và hoàn tất | Xác định phụ thuộc hoặc thiết lập cần sửa |
| Kết quả | Nội dung đáp ứng các tiêu chí đã ghi | Tạm dừng mở rộng chiến dịch |
| Xuất | Kết quả sử dụng được từ đích đến của nó | Sửa đầu ra trước khi chuyển |
Ví dụ cụ thể: nhận một trăm thư mục, chín mươi chín kết quả
Trong trường hợp giả định này, một nhóm thay phiên bản A của một bước tiền xử lý bằng phiên bản B. Bản kê của họ nêu rõ mã, các phụ thuộc và định dạng đầu ra trước và sau; bộ dữ liệu nghiệm thu vẫn gồm đúng 100 thư mục được đánh số từ 001 đến 100. Phiên bản A tạo ra 100 kết quả. Phiên bản B kết thúc nhưng chỉ xuất 99 mã định danh riêng biệt: thiếu thư mục 057. Tiêu chí đã ghi yêu cầu 100 kết quả không trùng lặp. Do đó, thay đổi này bị từ chối ở giai đoạn hiện tại.
Một phụ thuộc cần cho thư mục 057 bị thiếu trong gói ứng viên. Nhóm khôi phục nó trong một phiên bản mới của bản kê, kiểm tra thư mục này, rồi chạy lại 100 đầu vào trên ứng viên đã sửa. Họ thu được 100 mã định danh riêng biệt và mở gói từ đích đến cuối cùng. Lượt thử đầy đủ xác minh rằng bản sửa không chỉ khắc phục trường hợp riêng lẻ. Kết quả này giải quyết sai lệch đã mô tả; nó chưa chứng minh hoạt động trên khối lượng lớn hơn hay tải liên tục.
So sánh bản kê trước và sau, rồi quyết định áp dụng
Phiếu thay đổi chỉ gồm vài dòng: lý do, yếu tố đã sửa, yếu tố được giữ nguyên, tiêu chí và người phụ trách. Hãy giữ một bản sao có thể sử dụng của cấu hình tham chiếu. Nếu bạn thay đổi đồng thời trình điều khiển, framework và định dạng dữ liệu, bạn sẽ nhân lên các nguyên nhân khả dĩ gây sai lệch. Hãy chia nhỏ khi có thể; nếu không, hãy xử lý rõ ràng tổ hợp này như một thay đổi lớn hơn.
Sau khi sửa, hãy để chủ sở hữu kết quả phê duyệt tham chiếu mới. Bảng dưới đây tổ chức quyết định này; nó không phải là bản liệt kê phần mềm được cung cấp. Một phiên bản được chọn chỉ trở thành tham chiếu sau các kiểm tra đã thống nhất. Hãy ghi ngày áp dụng và nêu rõ các tác vụ mà nó áp dụng, để hai người không âm thầm khởi chạy hai biến thể của cùng một chiến dịch.
| Yếu tố | Trước | Ứng viên được chọn sau khi sửa lỗi |
|---|---|---|
| Ứng dụng | Phiên bản A | Phiên bản B, đã bao gồm bản sửa lỗi phụ thuộc |
| Đầu vào nghiệm thu | 100 hồ sơ cố định | Cùng 100 hồ sơ đó |
| Kết quả yêu cầu | 100 mã định danh riêng biệt | 100 mã định danh riêng biệt, đúng định dạng được chấp nhận |
| Phát hành | Bản tham chiếu được nhóm sử dụng | Áp dụng có ghi ngày sau khi người phụ trách đồng ý |
Duy trì khả năng quay lại mà không trộn lẫn kết quả
Trước khi áp dụng, hãy kiểm tra rằng bản tham chiếu trước đó vẫn đọc được đầu vào và khôi phục được trạng thái của nó. Phân tách đầu ra của ứng viên, tránh phát hành trùng lặp và xác định ai có quyền quyết định quay lại. Nếu phần mềm mới thay đổi không thể đảo ngược các tệp làm việc, việc chỉ giữ lại chương trình cũ là chưa đủ: còn cần một trạng thái dữ liệu tương thích. Hướng dẫn chuyển đổi đề cập đến việc chuyển giữa các môi trường; ở đây, quyết định liên quan đến thay đổi phần mềm đã được đánh giá chất lượng.
Việc xác nhận thanh toán và việc bàn giao vẫn tách biệt với các kiểm tra kỹ thuật này. Nút “Tôi đã thanh toán” báo hiệu một khoản thanh toán; nút này không xác nhận quyền truy cập cũng như thay đổi phần mềm. Hãy thực hiện các bài thử nghiệm khi môi trường thực sự truy cập được, sau đó liên kết kết quả của chúng với mã đơn hàng của bạn trong hồ sơ nội bộ.
Kết thúc với một nhóm có khả năng vận hành và bàn giao
Kết quả bàn giao mong đợi là một hồ sơ ngắn gọn: môi trường đã ghi nhận, bộ dữ liệu nghiệm thu, các kiểm tra đã đạt, các sai lệch còn lại và người quyết định bước tiếp theo. Hãy để một người không tham gia chuẩn bị cài đặt đọc lại quy trình khởi chạy. Nếu người này phải hỏi về một đường dẫn hay một thiết lập thiết yếu, hãy bổ sung hồ sơ trước khi chuyển giao vận hành cho họ.
Hãy lên kế hoạch cả việc thu hồi cuối cùng và kiểm tra việc đó. Các lỗi thường gặp là mở rộng khối lượng trước khi nghiệm thu, thay đổi nhiều phiên bản trong lúc chẩn đoán và chỉ phát hiện việc xuất dữ liệu khi đến hạn. Trong 3, 7 hoặc 30 ngày, hãy dành thời gian cho các bước này trong khoảng thời gian đã chọn, không coi chúng là những thao tác nhất thiết phải tức thời.
Câu hỏi để quyết định
Chỉ cần phát hiện được card là đủ để chấp nhận triển khai?
Không. Việc phát hiện chỉ kiểm tra một phần phạm vi phần cứng. Vẫn còn phải nạp đầu vào, chạy phần mềm, kiểm tra kết quả và thu hồi chúng từ đích đến. Mỗi kiểm tra phải có một tiêu chí riêng.
Có cần đầu ra hoàn toàn giống nhau sau khi đổi GPU không?
Điều đó phụ thuộc vào quy trình của bạn. Hãy xác định những gì phải giữ nguyên tuyệt đối và những gì thuộc mức dung sai có lý do chính đáng. Ghi lại các phiên bản và thông số; không nên mặc định có sự giống nhau hoàn hảo cho mọi phần mềm và mọi môi trường.
Ai quyết định một sai lệch là chấp nhận được?
Người phụ trách được chỉ định cho tiêu chí liên quan, cùng với người quyết định chuyển đổi khi sai lệch ảnh hưởng đến dịch vụ. Người chạy thử nghiệm mô tả quan sát; người này không tự động thay thế người phụ trách nghiệp vụ hay người phụ trách dữ liệu.