GPU cho dự án của bạn · thanh toán crypto không cần KYC Cách thuê
Tiếng Việt
Mở console
Tích hợp vào dự án / KERNODECK

Hãy trao cho dự án của bạn một giao diện mà bạn có thể kiểm soát.

Hãy xác định những gì ứng dụng của bạn chấp nhận, cách nó khởi động và điều gì chứng minh thành công. Một lệnh ổn định và các đầu ra được mô tả cho phép khởi chạy lại cùng một dự án từ terminal, script hoặc công cụ của riêng bạn. Các ví dụ dưới đây liên quan đến chương trình của nhà phát triển và việc theo dõi nó, kèm theo một bước kiểm tra trước cấu hình để bạn điều chỉnh.

1. Tách chương trình, các tham số và việc theo dõi thương mại

Mã nguồn mô tả hành vi của chương trình. Cấu hình xác định khối lượng công việc: model, dữ liệu, batch, độ chính xác và đích đến. Các secret cấp quyền truy cập vào những tài nguyên cần thiết. Hãy giữ các yếu tố này tách biệt để thay đổi một lần thử mà không phải viết lại mã nguồn hay sao chép một token vào một tệp được chia sẻ.

Tham chiếu lệnh Kernodeck giúp tìm lại bối cảnh thuê trong tài khoản của bạn. Mã định danh lần thử phân biệt các lần thực thi chương trình của bạn trong khoảng thời gian đó. Hãy liên kết chúng trong ghi chú của bạn nếu điều đó hữu ích, nhưng đừng yêu cầu script của bạn suy ra trạng thái tính toán từ trạng thái thanh toán.

Hãy lấy ví dụ một dự án phân loại tài liệu cần được khởi chạy nhiều lần trên cùng một mẫu. Hợp đồng của chương trình mô tả tệp đầu vào, các tham số được chấp nhận, thư mục đầu ra và cách hiển thị lỗi. Hướng dẫn về dữ liệu trình bày việc xác thực nội dung; ở đây, chúng ta tổ chức giao diện kết nối các bước này.

2. Viết một hợp đồng đầu vào tường minh và có phiên bản

Hãy ghi tài liệu cho các trường bắt buộc và các giá trị được chấp nhận. Tránh các giá trị mặc định ngầm cho một quyết định làm thay đổi kết quả, như model hay thiết bị. Một số hiệu schema phân biệt hình dạng của cấu hình với phiên bản mã nguồn; nó không thay thế phiên bản đó.

Trong ví dụ minh họa này, tệp JSON chứa một schema, một đường dẫn đầu vào, một batch và thiết bị được yêu cầu. Các đường dẫn tương đối được đọc từ thư mục cấu hình. Quy tắc được chọn cho ví dụ này giúp tránh phụ thuộc vào thư mục mà đồng nghiệp dùng để chạy lệnh.

Đọc JSON chỉ xác thực cú pháp của nó. Sau đó chương trình của bạn phải kiểm tra các kiểu, các trường và các ràng buộc của dự án. Khi có lỗi, nó phải dừng lại trước khi tải một tài nguyên tốn kém, với một thông báo nêu tên tham số cần sửa.

config/pilote.json — ví dụ về hợp đồng tối thiểu
{
  "schema_version": 1,
  "input": "../data/pilote.jsonl",
  "batch_size": 4,
  "device": "cuda"
}

3. Chuẩn bị một điểm vào từ chối các lỗi đơn giản

argparse cho phép khai báo các tùy chọn và tạo phần trợ giúp cho lệnh của bạn. Ví dụ sau chỉ là một bước kiểm tra trước: nó đọc cấu hình, kiểm tra các trường và phát hiện một thư mục đầu ra đã được sử dụng. Nó không tải model hay dữ liệu vào bộ nhớ và không kiểm tra tính khả dụng của GPU.

Hãy lưu mã minh họa này vào prepare_run.py nếu bạn muốn điều chỉnh. Nó được cung cấp mà không có lần thực thi nào được chứng nhận. Sau đó hãy thêm các kiểm soát nghiệp vụ của bạn vào ứng dụng, thay vì coi thông báo cuối cùng là một kết quả tính toán. Thiết bị cuda vẫn chỉ là một yêu cầu; PyTorch cũng dùng tên này với ROCm.

Việc từ chối một thư mục đầu ra đã tồn tại ở đây là một quy ước bảo vệ chống trộn lẫn các lần thử. Một lệnh khôi phục thực sự phải nhận một tùy chọn và các kiểm soát riêng. Đừng biến một lần khởi chạy mới thành một lần khôi phục ngầm chỉ vì có sẵn các tệp.

Kiểm tra trước mang tính minh họa cho giao diện dự án
import argparse
import json
from pathlib import Path

parser = argparse.ArgumentParser(description="Xác thực một lần chạy dự án")
parser.add_argument("--config", type=Path, required=True)
parser.add_argument("--run-dir", type=Path, required=True)
args = parser.parse_args()

try:
    config_path = args.config.resolve()
    config = json.loads(config_path.read_text(encoding="utf-8"))
except (OSError, UnicodeError, json.JSONDecodeError) as exc:
    parser.error(f"Không đọc được cấu hình: {exc}")

expected = {"schema_version", "input", "batch_size", "device"}
if not isinstance(config, dict) or set(config) != expected:
    parser.error("Các trường mong đợi: schema_version, input, batch_size, device")
if type(config["schema_version"]) is not int or config["schema_version"] != 1:
    parser.error("schema_version phải bằng 1")
if type(config["batch_size"]) is not int or config["batch_size"] < 1:
    parser.error("batch_size phải là một số nguyên dương")
if config["device"] not in ("cpu", "cuda"):
    parser.error("device phải bằng cpu hoặc cuda")
if not isinstance(config["input"], str) or not config["input"]:
    parser.error("input phải là một đường dẫn không rỗng")

input_path = (config_path.parent / config["input"]).resolve()
run_dir = args.run_dir.resolve()
if not input_path.is_file():
    parser.error("Thiếu tệp đầu vào")
if run_dir.exists():
    parser.error("Hãy chọn một thư mục đầu ra mới")

print(json.dumps({
    "status": "configuration_validated",
    "input": str(input_path),
    "run_dir": str(run_dir),
    "device_requested": config["device"],
    "batch_size": config["batch_size"]
}, ensure_ascii=False))
Lệnh kiểm tra trước đề xuất
python prepare_run.py --config config/pilote.json --run-dir runs/pilote-001

4. Đặt danh tính cho các lần chạy và kết quả của chúng

Gắn mỗi lần chạy với một mã định danh ngắn, duy nhất trong chiến dịch của bạn. Ghi lại bản sửa đổi mã, lược đồ và các tham số thực sự được dùng, rồi đến tham chiếu dữ liệu và mô hình. Lưu giữ các giá trị này cùng với đầu ra để một kết quả không phụ thuộc vào một tệp cấu hình bị sửa đổi sau đó.

Để so sánh hai kích thước batch, hãy tạo hai thử nghiệm và hai thư mục. Giữ nguyên cùng một mẫu và xác định rõ khác biệt có chủ đích. Chỉ tên pilote-001 và pilote-002 không đủ để giải thích điều gì đã thay đổi: bản kê gắn tên với các tham số.

Hãy dành một định dạng tổng kết mà công cụ của bạn đọc được. Nó có thể phân biệt các phần tử đã nhận, thành công, bị từ chối và còn phải xử lý. Chọn một quy tắc thành công trọn vẹn và đừng đánh dấu một thử nghiệm là hoàn tất ngay khi ghi kết quả đầu tiên. Mã trả về của chương trình phải nhất quán với kết luận này.

Cuộn bảng để xem tất cả các cột.
Một hợp đồng đầu ra cho xử lý theo tài liệu
Tệp hoặc trạng tháiVai tròKiểm tra mong đợi
manifest.jsonDanh tính của mã, dữ liệu và tham sốCác giá trị thực sự được dùng, không có thông tin bí mật.
results.jsonlMột đầu ra cho mỗi phần tử được chấp nhậnCác mã định danh đã biết và định dạng hợp lệ.
errors.jsonlCác phần tử bị từ chối và lý do hữu íchKhông biến mất âm thầm cũng không có nội dung nhạy cảm không cần thiết.
summary.jsonKết luận của thử nghiệm và các bộ đếmTổng nhất quán, các tệp được đọc lại trước trạng thái cuối.

5. Bộc lộ các sự kiện hữu ích cho công cụ của bạn

Hãy để lộ ra một vài chuyển tiếp: cấu hình được chấp nhận, dữ liệu truy cập được, mô hình đã tải, đầu ra đầu tiên đã ghi và xử lý kết thúc. Một dấu vết phải cho phép trả lời câu hỏi "lần chạy này đang ở đâu?" mà không cần chép lại tài liệu hay prompt. Gắn bước và mã định danh thử nghiệm vào thông báo.

Mô-đun logging của Python cho phép tổ chức thông báo theo cấp độ và đích đến. Sau đó hãy chọn quy ước sự kiện của riêng bạn và ghi lại tài liệu cho nó. Một ứng dụng ghi lỗi rồi kết thúc với thành công sẽ khiến việc tự động hóa trở nên đánh lừa; ngược lại, mỗi cảnh báo không có nghĩa là kết quả không dùng được.

Đừng nhầm lẫn giữa sự kiện được phát ra và kết quả bền vững: một thông báo "đã bắt đầu sao lưu" không chứng minh rằng một tệp đã được đọc lại. Với một lần chạy dài, hướng dẫn riêng giải thích mối liên hệ giữa tiến trình và phiên. Giao diện của bạn trên hết phải giữ lại một kết luận có thể truy cập sau khi kết nối tương tác kết thúc.

6. Định nghĩa thất bại, việc tiếp tục và kiểm tra cuối cùng

Phân loại các lỗi hữu ích: cấu hình không hợp lệ, tài nguyên thiếu, lỗi tính toán và kết quả không đúng yêu cầu. Với mỗi loại, hãy đưa ra hành động tiếp theo. Đừng thiết lập tự động thử lại mà không quyết định những tác động nào có thể lặp lại: ghi đè một đầu ra đã được chấp nhận và khôi phục từ checkpoint đòi hỏi những quy tắc khác nhau.

Quy trình cuối cùng của bạn giải thích cách khởi chạy, theo dõi, dừng, tiếp tục và xuất dữ liệu. Với xử lý tài liệu, hãy giữ danh sách các mã định danh đã hoàn thành và những cái cần xử lý lại. Với huấn luyện, hãy dùng một giao thức kiểm tra các trạng thái đã lưu trong một tiến trình mới. Một thư mục không rỗng không phải là bằng chứng cho việc khôi phục đúng.

Cuối cùng, hãy kiểm tra dự án từ một lần gọi mới, với cấu hình đã biết và một đích đến riêng biệt. Kiểm tra các trường hợp từ chối như mong đợi, rồi chạy thử một luồng hoàn chỉnh nhỏ. Bước kiểm tra trước của trang này không bao gồm truy cập đồng thời, phơi bày dịch vụ công khai hay quyền lưu trữ: những chủ đề này cần thiết kế riêng.

Câu hỏi của bạn

Giao diện này có đặt thuê GPU không?

Không. Các lệnh trên trang này áp dụng cho chương trình của bạn và các tệp của nó. Việc chọn thuê và theo dõi vẫn nằm trong trình cấu hình và tài khoản Kernodeck.

Tôi có thể gọi cùng một chương trình từ dịch vụ web của riêng mình không?

Có, nếu bạn tự thiết kế tích hợp và các kiểm soát của nó. Hãy giữ một hợp đồng đầu vào và đầu ra rõ ràng, rồi xử lý quyền truy cập, truy cập đồng thời và lỗi. Bước kiểm tra trước minh họa ở đây không phải là một máy chủ sẵn sàng để phơi bày công khai.

configuration_validated có nghĩa là tính toán của tôi đã thành công không?

Không. Thông báo trong ví dụ chỉ xác nhận các kiểm tra có trong mã. GPU, mô hình, dữ liệu và đầu ra ứng dụng vẫn cần được kiểm tra khi chạy thực tế.

Có nên dùng mã đơn hàng làm mã định danh thử nghiệm không?

Thay vào đó, hãy giữ hai mã định danh liên kết với nhau. Một lần thuê có thể chứa nhiều thử nghiệm; mỗi thử nghiệm phải có thể được so sánh và tra cứu độc lập với hồ sơ thương mại.