1. Programı, parametrelerini ve ticari takibi ayırın
Kod, programın davranışını tanımlar. Yapılandırma yükü belirtir: model, veri, batch, hassasiyet ve hedef. Gizli bilgiler gerekli kaynaklara erişim sağlar. Bu öğeleri ayrı tutun ki kodu yeniden yazmadan veya paylaşılan bir dosyaya jeton kopyalamadan bir denemeyi değiştirebilesiniz.
Kernodeck komut referansı, hesabınızdaki kiralama bağlamını bulmanızı sağlar. Deneme kimliği, bu dönemde programınızın çalıştırmalarını ayırt eder. Yardımcı oluyorsa notlarınızda bunları ilişkilendirin, ancak betiğinizden ödeme durumundan hesaplama durumunu çıkarmasını istemeyin.
Aynı örnek üzerinde birkaç kez çalıştırılması gereken bir belge sınıflandırma projesini ele alalım. Programın sözleşmesi giriş dosyasını, kabul edilen parametreleri, çıktı klasörünü ve hataların nasıl bildirileceğini tanımlar. Verilere ilişkin kılavuz, içeriğin doğrulanmasını açıklar; burada ise bu adımları birbirine bağlayan arayüzü düzenliyoruz.
2. Açık ve sürümlenmiş bir giriş sözleşmesi yazın
Zorunlu alanları ve kabul edilen değerleri belgeleyin. Model veya cihaz gibi sonucu değiştiren bir karar için sessiz varsayılan değerlerden kaçının. Bir şema numarası, yapılandırmanın biçimini kodun sürümünden ayırır; onun yerini almaz.
Bu öğretici örnekte JSON dosyası bir şema, bir giriş yolu, bir batch ve istenen cihazı içerir. Göreli yollar yapılandırma klasöründen itibaren okunur. Örnek için seçilen bu kural, bir iş arkadaşının komutu hangi dizinden çalıştırdığına bağlı olmayı önler.
Geçerli JSON okumak yalnızca söz dizimini doğrular. Programınız ardından türleri, alanları ve proje kısıtlarını denetlemelidir. Hata durumunda, maliyetli bir kaynağı yüklemeden önce durmalı ve düzeltilecek parametreyi adlandıran bir mesaj vermelidir.
{
"schema_version": 1,
"input": "../data/pilote.jsonl",
"batch_size": 4,
"device": "cuda"
}3. Basit hataları reddeden bir giriş noktası hazırlayın
argparse, seçenekler tanımlamanıza ve komutunuz için bir yardım metni üretmenize olanak tanır. Aşağıdaki örnek yalnızca bir ön kontroldür: yapılandırmayı okur, alanlarını denetler ve hâlihazırda kullanılan bir çıktı klasörünü tespit eder. Belleğe ne model ne veri yükler ve GPU'nun kullanılabilirliğini test etmez.
Bu öğretici kodu uyarlamak isterseniz prepare_run.py içine kaydedin. Onaylanmış bir çalıştırma olmadan sunulmaktadır. Ardından iş kurallarınızı, nihai mesajı bir hesaplama sonucu saymak yerine uygulamaya ekleyin. cuda cihazı bir istek olarak kalır; PyTorch bu adı ROCm ile de kullanır.
Mevcut bir çıktı dizininin reddedilmesi, burada denemelerin karışmasına karşı bir koruma kuralıdır. Gerçek bir devam ettirme komutu ayrı bir seçenek ve ayrı kontroller almalıdır. Dosyalar mevcut diye yeni bir başlatmayı örtük bir devam ettirmeye dönüştürmeyin.
import argparse
import json
from pathlib import Path
parser = argparse.ArgumentParser(description="Bir proje çalıştırmasını doğrula")
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"Yapılandırma okunamıyor: {exc}")
expected = {"schema_version", "input", "batch_size", "device"}
if not isinstance(config, dict) or set(config) != expected:
parser.error("Beklenen alanlar: schema_version, input, batch_size, device")
if type(config["schema_version"]) is not int or config["schema_version"] != 1:
parser.error("schema_version 1 olmalıdır")
if type(config["batch_size"]) is not int or config["batch_size"] < 1:
parser.error("batch_size pozitif bir tam sayı olmalıdır")
if config["device"] not in ("cpu", "cuda"):
parser.error("device cpu veya cuda olmalıdır")
if not isinstance(config["input"], str) or not config["input"]:
parser.error("input boş olmayan bir yol olmalıdır")
input_path = (config_path.parent / config["input"]).resolve()
run_dir = args.run_dir.resolve()
if not input_path.is_file():
parser.error("Giriş dosyası yok")
if run_dir.exists():
parser.error("Yeni bir çıkış klasörü seçin")
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))python prepare_run.py --config config/pilote.json --run-dir runs/pilote-0014. Çalıştırmalara ve sonuçlarına bir kimlik verme
Her çalıştırmayı kampanyanızda benzersiz, kısa bir tanımlayıcıyla ilişkilendirin. Kod revizyonunu, şemayı ve gerçekte kullanılan parametreleri, ardından veri ve model referansını not edin. Bu değerleri çıktılarla birlikte saklayın ki bir sonuç, sonradan değiştirilmiş bir yapılandırma dosyasına bağlı kalmasın.
İki batch boyutunu karşılaştırmak için iki deneme ve iki dizin oluşturun. Aynı örneği koruyun ve kasıtlı farkı belirtin. pilote-001 ve pilote-002 adları tek başına neyin değiştiğini açıklamaz: manifest, adı parametrelere bağlar.
Araçlarınızın okuyabileceği bir bilanço biçimi ayırın. Alınan, başarılı, reddedilen ve işlenmeyi bekleyen öğeleri ayırt edebilir. Eksiksiz bir başarı kuralı seçin ve ilk sonucun yazılmasıyla bir denemeyi tamamlanmış olarak işaretlemeyin. Programın dönüş kodu bu sonuçla tutarlı kalmalıdır.
Tüm sütunları görmek için tabloyu kaydırın.| Dosya veya durum | Rol | Beklenen kontrol |
|---|---|---|
| manifest.json | Kodun, verinin ve parametrelerin kimliği | Gerçekte kullanılan değerler, sır olmadan. |
| results.jsonl | Kabul edilen her öğe için bir çıktı | Bilinen tanımlayıcılar ve uygun biçim. |
| errors.jsonl | Reddedilen öğeler ve faydalı gerekçe | Sessiz kaybolma veya gereksiz hassas içerik olmamalı. |
| summary.json | Denemenin sonucu ve sayaçlar | Tutarlı toplam, nihai durumdan önce yeniden okunan dosyalar. |
5. Araçlarınız için faydalı olayları açığa çıkarma
Birkaç geçişi görünür kılın: yapılandırma kabul edildi, veriler erişilebilir, model yüklendi, ilk çıktı yazıldı ve işlem sona erdi. Bir iz, belgeleri veya prompt'ları kopyalamadan "bu çalıştırma nerede?" sorusunu yanıtlamayı sağlamalıdır. Aşamayı ve deneme tanımlayıcısını mesajla ilişkilendirin.
Python'un logging modülü, mesajları seviye ve hedefe göre düzenlemeyi sağlar. Ardından kendi olay sözleşmenizi seçin ve belgeleyin. Bir hata yazıp sonra başarıyla sonlanan bir uygulama otomasyonu yanıltıcı kılar; tersine, her uyarı sonucun kullanılamaz olduğu anlamına gelmez.
Yayılan olay ile kalıcı sonucu karıştırmayın: "yedekleme başladı" mesajı bir dosyanın yeniden okunduğunu kanıtlamaz. Uzun süren bir çalıştırma için özel kılavuz, süreç ile oturum arasındaki bağlantıyı açıklar. Arayüzünüz özellikle etkileşimli bağlantı sona erdikten sonra erişilebilir bir sonuç saklamalıdır.
6. Başarısızlığı, devam etmeyi ve nihai doğrulamayı tanımlama
Faydalı hataları sınıflandırın: geçersiz yapılandırma, eksik kaynak, hesaplama hatası ve uygun olmayan sonuç. Her biri için bir sonraki adımı belirtin. Hangi etkilerin yinelenebileceğine karar vermeden otomatik yeniden başlatma kurmayın: zaten kabul edilmiş bir çıktıyı yeniden yazmak ve bir kontrol noktasından devam etmek farklı kurallar gerektirir.
Son prosedürünüz nasıl başlatılacağını, izleneceğini, durdurulacağını, devam ettirileceğini ve dışa aktarılacağını açıklar. Belge işleme için tamamlanan ve yeniden işlenecek kimliklerin listesini tutun. Eğitim için kaydedilen durumları yeni bir süreçte doğrulayan bir protokol kullanın. Boş olmayan bir klasör doğru devam ettirmenin kanıtı değildir.
Son olarak projeyi yeni bir çağrıdan, bilinen bir yapılandırmayla ve ayrı bir hedefle kontrol edin. Beklenen redleri, ardından küçük bir tam akışı doğrulayın. Bu sayfanın ön kontrolü ne eşzamanlı erişimleri, ne bir hizmetin herkese açık sunumunu, ne de depolama izinlerini kapsar: bu konular kendi tasarımlarını gerektirir.