Deploy an AI Model

Deploy the defect-detector / 1-0-3 Edition prepared in Upload an AI Model, then confirm what happened on each device and whether your inference application uses the intended file.

Select an Edition and Target Devices

Before deploying, prepare:

• Edition: Confirm it is Uploaded. Retain the orgId, modelId and Edition string, and read its file metadata with Get Model Edition Detail.
• Devices: Select Activated WEDA Nodes in the same Org. Use Connected devices for this walkthrough so you can inspect the result immediately. A device's activation and connectivity are separate conditions.
• Application: When requesting a container restart, prepare a running inference container and its model-volume mount first. Follow Make Your Container Read the Model for that configuration.
• Container name: Use the actual running container name on each device, which can differ from the Compose service name or Stack name. List Stacks on Device helps inspect the deployed containers.
• API access: Use a bearer token with access to the Org. See User Authentication.

Note: Plan model storage and runtime resources

Reserve device storage for the model file, existing model files you retain, and working space during download and update. Separately check the inference application's RAM, GPU memory (where applicable) and runtime requirements. Model file size alone does not establish whether the device can run the application.

WEDA Console offers two starting points:

Starting point	What you select
AI Models in the Org	Find the Uploaded Edition, select Deploy, then choose its target devices. You can also open the Edition's Deployments tab and select Deploy.
Devices → device → AI Models	Select Deploy, then choose the Models and one Uploaded Edition for each.

The AI Models tab shows this device's model deployments. Select Deploy to choose Models and Editions.

For the example below, choose one WEDA Node and one Edition. Check the selected device ID before continuing.

Configure Deployment Options

Each target group can include a tasks array describing four device-action stages. These are predefined actions, not arbitrary shell commands.

Stage	Supported actions	What to configure
Pre-check (preCmd)	CHECK_DISK_USAGE, NOOP	For a disk check, supply maxUsagePercent as a string greater than 0 and at most 100, such as "95".
Validate (validateCmd)	CHECKSUM_VERIFY, NOOP	For verification, supply expectedChecksum and an algorithm: sha256 or sha512. The default algorithm is sha256.
Apply (applyCmd)	ATOMIC_SWAP_AND_RESTART_CONTAINER, NOOP	For a container restart, supply its name in params.name. The API also accepts containerName as an alias.
Post-check (postCmd)	NOOP	No post-deployment application health check is configured by this action.

For this walkthrough, use a disk check, SHA-256 verification and a restart of the prepared inference container. Copy the Edition's SHA-256 digest into expectedChecksum, removing the response's sha256: prefix. If you choose sha512, compute that file's SHA-512 digest instead; the SHA-256 value cannot be reused.

The upload's Cloud-side hash verification and this device-side validation are separate checks. Select CHECKSUM_VERIFY when you want the device to verify the downloaded file too.

NOOP, or an omitted hook, skips the corresponding additional action. In particular, Apply NOOP does not request a container restart. Check your application's own model-loading behavior before expecting it to use the delivered file.

Optional acl.allowedContainers and acl.allowedSubnets restrict access to the model file on the device. They serve a different purpose from selecting which devices receive the Edition; subnet entries use CIDR notation.

Note: Deployment success and container restart are separate results

The restart action requires an existing container and volume configuration. A container restart error can leave the model file deployed while the application has not restarted. Check the container and application after deployment, even when the device reports DEPLOYED.

Deploy the Model

In WEDA Console

After selecting the Edition and targets, select Submit and review the confirmation presented by your Console. Confirm the intended devices before submitting the deployment.

For the explicit checksum and restart settings in this walkthrough, use the API request below.

Through the API

Call Create Deployment, placing the selected Edition string in the path:

Use the following request template. Replace the illustrative device ID and container name with your own, and replace REPLACE_WITH_EDITION_SHA256 with the file's actual 64-character SHA-256 hex digest before sending it.

POST /api/v1/orgs/{orgId}/ai-models/{modelId}/editions/1-0-3:deploy

{
  "targets": [
    {
      "deviceIdList": ["74fe488d5d54"],
      "tasks": [
        {
          "preCmd": {
            "action": "CHECK_DISK_USAGE",
            "params": { "maxUsagePercent": "95" }
          },
          "validateCmd": {
            "action": "CHECKSUM_VERIFY",
            "params": {
              "algorithm": "sha256",
              "expectedChecksum": "REPLACE_WITH_EDITION_SHA256"
            }
          },
          "applyCmd": {
            "action": "ATOMIC_SWAP_AND_RESTART_CONTAINER",
            "params": { "name": "infer-svc" }
          },
          "postCmd": { "action": "NOOP" }
        }
      ]
    }
  ]
}

Place devices with the same settings in one deviceIdList. Use separate target groups when their settings differ, for example when their actual container names differ. Review every target group before sending a multi-device request.

The 202 Accepted response is the initial result of the request:

• Retain the returned modelDeploymentId and accepted targets' deviceDeploymentId values.
• Check each targets[] item. A target can be REJECTED before device execution; read its rejectReason. IDs may be absent when no deployment task was created.
• Accepted targets begin delivery processing. Use the query operations below to follow their subsequent states; the original HTTP response is not a continuously updated progress record.

An Activated device can be offline when a request is accepted. Reconnect it and monitor its reported state before expecting completion. A successful submission alone does not prove the model is available to the application.

Check the result: The intended targets were accepted, their IDs and initial outcomes were recorded, and subsequent device results are being monitored.

Monitor Deployment and Diagnose Failures

Use either query to inspect the selected Edition on each target:

View	API
Models on one device	GET /api/v1/devices/{deviceId}/ai-models
Devices for one Edition	GET /api/v1/orgs/{orgId}/ai-models/{modelId}/editions/{edition}/deployments

Both queries support skipCount / maxResultCount pagination and a state filter. The default page size is 10, with an allowed size of 1–1000. Read additional pages when checking a deployment across multiple devices.

In Console, inspect the Edition's Deployments tab or the device's AI Models tab. Use the API when you need failure fields that the Console view does not display.

Read the response fields in this order:

1. Identity: Match the device, Model and Edition, and retain deviceDeploymentId.
2. Progress: Read the device's state and lastTransitionTime.
3. Failure: If it is REJECTED, read rejectedReason, errorCode and errorMessage. These queried device-result fields are distinct from the create response's rejectReason.
4. Application: When deployment completes, use the returned edgeFilePath with the prepared volume mount and confirm that the application loads the intended model. Inspect its own behavior or output.

Deployment states and rejection reasons

The states below are listed in their logical progression. In v1.2.0, the old DOWNLOADED state is replaced by DOWNLOADING, VERIFYING and STAGING; update clients and filters accordingly.

Device state	Meaning
SENT	The request is awaiting further device processing or acknowledgement.
SERVERFILEPATH_OBTAINED	The source file location has been resolved.
EDGERECEIVED	The device has received the deployment instruction.
MODEL_STORAGE_CHECKED	The device's model-storage check stage has completed.
CAPACITY_CHECKED	The capacity-check stage has completed. Review the configured Pre-check action.
DOWNLOADING	The model file is being transferred to the device.
VERIFYING	The device is in the validation stage. The actual check depends on validateCmd.
STAGING	The device is preparing the file and running the configured apply stage.
VALIDATED	The deployment has passed its final configured preparation stages.
DEPLOYED	The device completed the configured file-deployment operation. Confirm the application's use of the model separately.
REJECTED	The deployment failed. Inspect the failure fields.
DELETED	Device reporting indicates the deployed file was removed. This is not the immediate delete API's dispatch result.

The create response's aggregate status uses IN_PROGRESS, COMPLETED, PARTIAL_FAILED or FAILED. These summarize deployment outcomes across targets; they are distinct from the per-device state.

Classified device rejection reasons include:

rejectedReason	Check
FAILED_SERVERFILEPATH	Source-file resolution.
FAILED_MODEL_STORAGE	Model storage availability and access.
FAILED_DOWNLOAD	File transfer to the device.
FAILED_VERIFICATION	Downloaded-file verification and the expected checksum.
FAILED_STAGING	Preparing the file for use.
FAILED_ACTIVATION	Applying the configured activation action.
FAILED_UNKNOWN	The raw errorCode and errorMessage.

FAILED_RECEIVE, FAILED_CAPACITY and FAILED_VALIDATION are reserved rejection classifications, not used by the v1.2 deployment-failure mapping. The delete response described below uses its own dispatch states.

Use lastTransitionTime to follow device-state changes. createdAt records request creation; updatedAt records user API operations. deploymentStartTime is set when the device reports DEPLOYED, and deploymentEndTime when it reports DELETED; nullable timestamps alone do not tell you whether an operation is currently running.

Note: v1.2 API client compatibility

• Audit fields: Deployment create/query responses include createdAt, createdBy, updatedAt and updatedBy. Nullable values can be null, including createdBy on older records. Read the values rather than using key presence to decide whether an update occurred.
• State filters: state=DOWNLOADED returns 400 in v1.2.0. Update existing scripts to use a supported state such as DOWNLOADING, VERIFYING or STAGING.

Check the result: Each intended device reports the expected deployment outcome, the file can be read by the prepared container, and the application uses the intended Edition. If a restart was requested, verify that it actually occurred.

Retry or Remove Deployments

Retry and Repeated Deployment

Investigate the failure before submitting another request. Check connectivity, activation, storage, the registered file, checksum settings and the actual container name as relevant to the reported error.

Retry uses Create Deployment again. To retain explicit checks and restart actions, send the intended tasks configuration again through the API.

Repeated deployment depends on the destination identity modelName + edition + fileName and file hash:

Compared with an existing deployment	Result
Same destination identity and same hash	409 Conflict; do not treat it as a successful retry.
Same destination identity, different hash	The file is replaced in place.
Model name, Edition or filename differs	The files coexist on the device.

The Model ID is not part of this destination key. Recreating a Cloud Model with the same names does not by itself avoid a collision. A 409 can reject the request because one of its targets already holds the file; inspect the conflict response and existing deployments before deciding what to retry.

Remove from Devices

Save the current device identities, Edition and edgeFilePath before removing deployments, and select the intended scope:

Scope	API
One device	DELETE /api/v1/devices/{deviceId}/ai-models/{modelId}/editions/{edition}
All devices for the Edition	DELETE /api/v1/orgs/{orgId}/ai-models/{modelId}/editions/{edition}/deployments

The 202 response reports dispatch, using operationStatus and a targets[] list:

• FILE_DELETE_PENDING: The removal command was dispatched. Device completion is not yet confirmed.
• FAILED_RECEIVE: Dispatch failed. Read the target's reason.

Caution: A disappearing Cloud record does not confirm device deletion

These removal requests clear the Cloud deployment records while reporting dispatch. Save the response and confirm the intended file was removed on the device, especially after an offline or failed dispatch. Repeating DELETE may return 404 because the Cloud record is already gone; contact your WEDA support team with the saved target details if cleanup remains unresolved.

Device-file removal and deleting a Cloud Model or Edition are separate operations. Cloud-record management is covered in Upload an AI Model. Confirm which device files you intend to remove before using the all-devices operation.