組件最佳實務¶

此處列出了一些您可能希望使用組件執行的常見操作，以及相關的最佳實務。組件的設計非常靈活，因此您可以根據需要偏離這些實務，但這些是我們用於內建 TorchX 組件的最佳實務。

如需如何使用 TorchX 編寫應用程式的資訊，請參閱 :ref:應用程式最佳實務<app_best_practices:應用程式最佳實務>。

進入點¶

建議盡可能透過 python -m <module> 呼叫可重複使用的組件，而不是指定主模組的路徑。這使得它可以透過依賴 Python 模組解析而不是目錄結構，在多種不同的環境中使用，例如 Docker 和 Slurm。

如果您的應用程式不是基於 Python 的，您可以將應用程式放在 PATH 上的資料夾中，以便無論目錄結構如何都可以存取它。

def trainer(img_name: str, img_version: str) -> AppDef:
    return AppDef(roles=[
        Role(
            entrypoint="python",
            args=[
                "-m",
                "your.app",
            ],
        )
    ])

簡化¶

編寫組件時，您希望每個組件盡可能簡單，以便其他人更容易重複使用和理解。

參數處理¶

參數處理使得在其他環境中使用組件變得困難。特別是對於映像，我們希望將映像欄位直接傳遞給 AppDef，因為任何形式的操作都將使其無法在具有不同映像命名慣例的其他環境中使用。

def trainer(image: str):
    return AppDef(roles=[Role(image=image)...)

分支邏輯¶

您應該避免在組件中使用分支邏輯。如果您遇到覺得需要在組件中使用 if 語句的情況，您應該優先建立多個具有共用邏輯的組件。複雜的參數會讓其他人難以理解如何使用它。

def trainer_test():
    return _trainer(num_replicas=1)

def trainer_prod() -> AppDef:
    return _trainer(num_replicas=10)

# not a component just a function
def _trainer(num_replicas: int) -> AppDef:
     return AppDef(roles=[Role(..., num_replicas=num_replicas)])

文件¶

文件是可選的，但最佳實務是保持組件函數的文件化，尤其是當您想共用您的組件時。如需更多詳細資訊，請參閱 :ref:組件編寫<components/overview:編寫>。

命名資源¶

編寫組件時，最佳實務是使用 TorchX 的命名資源支援，而不是手動指定 CPU 和記憶體配置。命名資源允許您的組件與環境無關，並允許透過使用 T 恤尺寸來實現更好的排程行為。

如需更多資訊，請參閱 torchx.specs.get_named_resources()。

組合組件¶

對於常見的組件樣式，我們提供了基本組件定義。這些可以從您的自訂組件定義中呼叫，並且是從頭建立完整 AppDef 的替代方法。

請參閱

torchx.components.base 適用於簡單的單節點組件。
torchx.components.dist.ddp() 適用於分散式組件。

對於更複雜的組件，可以將多個現有組件合併到一個組件中。例如，您可以使用指標 UI 組件並將其角色合併到訓練組件角色中，以便為您的主訓練作業提供一個邊車服務。

分散式組件¶

如果您正在編寫用於分散式訓練或其他類似分散式計算的組件，我們建議使用 torchx.components.dist.ddp() 組件，因為它為 torch.distributed.elastic 作業提供了開箱即用的支援。

您可以透過編寫一個自訂組件來擴展 ddp 組件，該組件只需匯入 ddp 組件並使用您的應用程式配置呼叫它。

定義所有參數¶

最好將所有組件參數定義為函數參數，而不是使用參數字典。這使得使用者更容易找出選項，並且在與 pyre 或 mypy 一起使用時可以提供靜態型別。

單元測試¶

您可以像測試一般 Python 程式碼一樣對組件定義進行單元測試，因為它們是有效的 Python 定義。

我們建議使用 ComponentTestCase 來確保您的組件可以由 TorchX CLI 解析。CLI 要求文件字串的格式比純 Python 更嚴格，因為文件字串用於解析 CLI 參數。

class torchx.components.component_test_base.ComponentTestCase(methodName='runTest')[來源]¶

run_component(component: Callable[[...], AppDef], args: Optional[Dict[str, Any]] = None, scheduler_params: Optional[Dict[str, Any]] = None, scheduler: str = 'local_cwd', interval: float = 0.1, timeout: float = 1) → Optional[AppStatus][原始碼]¶

輔助函數，用於隱藏設置執行器和輪詢結果的複雜性。注意：此方法會阻塞，直到排程器退出或達到逾時（對於非阻塞排程器）。

參數：

components – 組件函數，AppDef 的工廠
args – 可選的組件工廠參數
scheduler_params – 排程器工廠方法的可選參數
scheduler – 排程器名稱
interval – 排程器完成輪詢間隔
timeout – 排程器完成的最長時間

setUp() → None[原始碼]¶: 在執行測試裝置之前設置它的鉤子方法。

tearDown() → None[原始碼]¶: 在測試測試裝置之後解構它的鉤子方法。

validate(module: module, function_name: str) → None[原始碼]¶

通過有效地運行來驗證組件

$ torchx run COMPONENT.py:FN --help

整合測試¶

您可以通過使用程式化執行器 API 或編寫 bash 腳本來呼叫 CLI，來設置與組件的整合測試。

您可以在核心 TorchX 排程器整合測試中看到這兩種樣式的使用。