omni-train-cli 0.1.29__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (31) hide show
  1. omni_train_cli-0.1.29/PKG-INFO +9 -0
  2. omni_train_cli-0.1.29/README.md +201 -0
  3. omni_train_cli-0.1.29/pyproject.toml +39 -0
  4. omni_train_cli-0.1.29/setup.cfg +4 -0
  5. omni_train_cli-0.1.29/src/omni_cli/__init__.py +1 -0
  6. omni_train_cli-0.1.29/src/omni_cli/__main__.py +5 -0
  7. omni_train_cli-0.1.29/src/omni_cli/bundled_skills/__init__.py +0 -0
  8. omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/SKILL.md +194 -0
  9. omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/assets/algorithm.params.example.yaml +60 -0
  10. omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/assets/deploy.example.yaml +18 -0
  11. omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/assets/train.example.yaml +31 -0
  12. omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/references/cli-commands.md +145 -0
  13. omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/references/custom-image-algorithms.md +473 -0
  14. omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/references/deployment.md +82 -0
  15. omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/references/error-handling.md +17 -0
  16. omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/references/train-schema.md +126 -0
  17. omni_train_cli-0.1.29/src/omni_cli/client.py +425 -0
  18. omni_train_cli-0.1.29/src/omni_cli/commands.py +1489 -0
  19. omni_train_cli-0.1.29/src/omni_cli/config.py +48 -0
  20. omni_train_cli-0.1.29/src/omni_cli/credentials.py +25 -0
  21. omni_train_cli-0.1.29/src/omni_cli/deploy_schema.py +109 -0
  22. omni_train_cli-0.1.29/src/omni_cli/main.py +302 -0
  23. omni_train_cli-0.1.29/src/omni_cli/output.py +45 -0
  24. omni_train_cli-0.1.29/src/omni_cli/schema.py +412 -0
  25. omni_train_cli-0.1.29/src/omni_cli/uploads.py +241 -0
  26. omni_train_cli-0.1.29/src/omni_train_cli.egg-info/PKG-INFO +9 -0
  27. omni_train_cli-0.1.29/src/omni_train_cli.egg-info/SOURCES.txt +29 -0
  28. omni_train_cli-0.1.29/src/omni_train_cli.egg-info/dependency_links.txt +1 -0
  29. omni_train_cli-0.1.29/src/omni_train_cli.egg-info/entry_points.txt +3 -0
  30. omni_train_cli-0.1.29/src/omni_train_cli.egg-info/requires.txt +6 -0
  31. omni_train_cli-0.1.29/src/omni_train_cli.egg-info/top_level.txt +1 -0
@@ -0,0 +1,9 @@
1
+ Metadata-Version: 2.4
2
+ Name: omni-train-cli
3
+ Version: 0.1.29
4
+ Summary: CLI and agent Skill for Omni Train
5
+ Requires-Python: <3.13,>=3.9
6
+ Requires-Dist: httpx<1,>=0.28
7
+ Requires-Dist: PyYAML<7,>=6.0
8
+ Requires-Dist: keyring<26,>=25
9
+ Requires-Dist: tomli<3,>=2.0; python_version < "3.11"
@@ -0,0 +1,201 @@
1
+ # Omni Train CLI
2
+
3
+ Python support: 3.9 through 3.12. Python 3.9 and 3.10 install the small
4
+ `tomli` compatibility dependency automatically.
5
+
6
+ Install the internal Wheel with:
7
+
8
+ ```powershell
9
+ uv tool install omni-train-cli --index-url https://pypi.company.example/simple
10
+ ```
11
+
12
+ For an offline release:
13
+
14
+ ```powershell
15
+ uv tool install .\omni_train_cli-0.1.25-py3-none-any.whl
16
+ ```
17
+
18
+ On Debian/Ubuntu, do not install the Wheel into the system Python with
19
+ `pip install`. Those distributions enable PEP 668 and mark the environment as
20
+ externally managed. Use one of the isolated installation methods instead:
21
+
22
+ ```bash
23
+ # Recommended for a command-line application
24
+ pipx install ./omni_train_cli-0.1.25-py3-none-any.whl
25
+
26
+ # Or use a project virtual environment
27
+ python3 -m venv .venv
28
+ . .venv/bin/activate
29
+ python -m pip install ./omni_train_cli-0.1.25-py3-none-any.whl
30
+
31
+ # If uv is available
32
+ uv tool install ./omni_train_cli-0.1.25-py3-none-any.whl
33
+ ```
34
+
35
+ If `pipx` is not installed, install it with the OS package manager first (for
36
+ example, `sudo apt install pipx`) and then run `pipx ensurepath`. Avoid
37
+ `--break-system-packages` unless the machine is disposable and you explicitly
38
+ accept the risk of modifying the system Python.
39
+
40
+ Configure the platform and personal scoped API Key:
41
+
42
+ ```powershell
43
+ omni config set endpoint https://omni.company.example
44
+ omni auth set-key
45
+ omni context show --output json
46
+ omni skill install
47
+ ```
48
+
49
+ `org_id` is optional. When omitted, the API uses the account's default
50
+ Workspace. List accessible Workspaces, persist a selection, or restore the
51
+ default with:
52
+
53
+ ```powershell
54
+ omni workspace list --output json
55
+ omni workspace use <workspace_id> --output json
56
+ omni workspace reset --output json
57
+ ```
58
+
59
+ The CLI validates a Workspace before persisting it. Global `--org-id` remains
60
+ a one-command override. If `OMNI_ORG_ID` is set, unset it before running
61
+ `workspace use` or `workspace reset`, because the environment variable has
62
+ higher priority than the saved profile.
63
+
64
+ When `--target` is omitted, the CLI installs the Skill into the shared Agent
65
+ Skills directory (`~/.agents/skills`). Tools that support the Agent Skills
66
+ standard can discover it from there. Use an explicit target when a tool-specific
67
+ personal directory is preferred:
68
+
69
+ - Shared Agent Skills (default): `~/.agents/skills`
70
+ - GitHub Copilot: `~/.copilot/skills` (or `$COPILOT_HOME/skills` when `COPILOT_HOME` is set)
71
+ - Codex: `%USERPROFILE%\.codex\skills` (or `%CODEX_HOME%\skills` when `CODEX_HOME` is set)
72
+ - Claude Code: `%USERPROFILE%\.claude\skills`
73
+ - Platform: `.omni-skills` in the current directory
74
+
75
+ ```powershell
76
+ omni skill install --target copilot
77
+ omni skill install --target codex
78
+ omni skill install --target claude-code
79
+ ```
80
+
81
+ `--destination` overrides the selected target's default Skill directory.
82
+
83
+ Automation uses `OMNI_API_KEY` instead of storing a Key in the profile. Training is declared in `train.yaml`; validate it with `omni train validate` and submit it with `omni train submit`.
84
+
85
+ Detailed training output is available with
86
+ `omni train logs <run_id> --log-type client --output json` (`client` is the
87
+ default). Use `--log-type task` for workflow-stage messages or
88
+ `--log-type all` for separate snapshots of both streams. Log paging supports
89
+ `--offset` and `--limit`; `--follow` follows one `client` or `task` stream.
90
+
91
+ List commands support pagination:
92
+
93
+ ```powershell
94
+ omni dataset list --page 2 --page-size 50
95
+ omni algorithm list --available --page-size 50
96
+ omni task list --page-size 50
97
+ omni train list --all
98
+ ```
99
+
100
+ Use `--all` to request the complete result set (`page_size=all`).
101
+
102
+ Create a private dataset and upload a local ZIP into a new subset with TUS
103
+ resumable upload:
104
+
105
+ ```powershell
106
+ omni dataset create --name demo-dataset --type classification --labels cat,dog --output json
107
+ omni dataset upload .\dataset.zip --dataset-id 25 --subset-name train --output json
108
+ ```
109
+
110
+ Run the same upload command again after an interruption to resume from the
111
+ server offset. Add `--wait --timeout 1800` only when the command must wait for
112
+ background parsing. The output reports file upload and dataset parsing as
113
+ separate states. Personal API Keys need the `dataset` scope for creation and
114
+ upload.
115
+
116
+ Upload a custom algorithm package and submit its build in one command. The ZIP
117
+ must contain exactly one top-level directory with the six required files from
118
+ the custom algorithm specification:
119
+
120
+ ```powershell
121
+ omni algorithm base-images --output json
122
+
123
+ omni algorithm upload `
124
+ --name demo-classifier `
125
+ --type classification `
126
+ --archive .\algorithm.zip `
127
+ --output json
128
+ ```
129
+
130
+ To upload a new build to an existing algorithm, replace `--name` and `--type`
131
+ with `--algorithm-id <id>`. The command creates the algorithm when needed,
132
+ uploads the archive, and submits the platform build workflow. `--params-file`
133
+ can be used to provide the algorithm's custom parameter object in YAML or JSON.
134
+ The CLI reads available images from the platform. When `--base-image` is
135
+ omitted, it uses the option marked as the platform default; an explicitly
136
+ provided value is validated against the same list.
137
+
138
+ For Skill-generated image algorithms, start from
139
+ `assets/algorithm.params.example.yaml`, save it as `algorithm.params.yaml`, and
140
+ pass it explicitly with `--params-file`. The template declares the base
141
+ `epochs`, `batch_size`, and `input_size` controls plus recommended `train`
142
+ custom parameters such as `lr` and `optimizer`. The CLI does not discover this
143
+ file inside the ZIP automatically.
144
+
145
+ When `--algorithm-id` and `--params-file` are used together, the CLI updates
146
+ the existing algorithm parameters through the standard algorithm PATCH before
147
+ uploading the archive. Without `--params-file`, existing parameters remain
148
+ unchanged.
149
+
150
+ The upload response includes `algorithm_id` and `build_id`. Query the build
151
+ list, status, and logs with:
152
+
153
+ ```powershell
154
+ omni algorithm builds 27 --all --output json
155
+ omni algorithm build-status 27 103 --output json
156
+ omni algorithm build-logs 27 103 --offset 0 --limit 200 --output json
157
+ ```
158
+
159
+ Personal API Keys need the `train` scope for algorithm creation, source
160
+ upload, build listing, status, and log queries.
161
+
162
+ Deploy a completed training model by first listing the platform targets, then
163
+ using a deployment configuration:
164
+
165
+ ```powershell
166
+ omni deploy platforms --output json
167
+ omni deploy submit --file .\deploy.yaml --output json
168
+ omni deploy status 12 --output json
169
+ omni deploy logs 12 --offset 0 --limit 200 --output json
170
+ omni deploy wait 12 --output json
171
+ omni deploy download 12 --output-path .\artifacts\deployed-model.zip --output json
172
+ omni deploy sdk 12 --output-path .\artifacts\omni-sdk.zip --output json
173
+ ```
174
+
175
+ `deploy submit --file` creates and starts the workflow. Use
176
+ `deploy create --file` for a create-only record, then start it with
177
+ `deploy submit --deploy-id <id>`. Stop and delete remain separate explicit
178
+ commands. Personal API Keys need the `deploy` scope for the deployment
179
+ lifecycle. SDK download always uses the deployment's stored system and
180
+ platform; the CLI does not accept target overrides.
181
+
182
+ Update resources without changing lifecycle state:
183
+
184
+ ```powershell
185
+ omni algorithm update 27 --file .\algorithm-update.yaml --output json
186
+ omni project list --all --output json
187
+ omni project update 45 --file .\project-update.yaml --output json
188
+ omni train update 53 --file .\train.yaml --output json
189
+ omni deploy update 12 --file .\deploy.yaml --output json
190
+ ```
191
+
192
+ Algorithm updates are limited to `name`, `description`, `type`, and `params`;
193
+ upload a new ZIP separately when source code changes. Project type is
194
+ immutable. Training and deployment configuration can be updated only while
195
+ their status is `new`. These commands do not submit, start, stop, delete, or
196
+ rebuild a resource.
197
+
198
+ The underlying REST mapping keeps standard partial-update routes for
199
+ algorithms, projects, and training tasks (`/api/algorithms/{id}`,
200
+ `/api/trains/{id}`, and `/api/models/{id}`). Only deployment configuration
201
+ uses the dedicated `/api/deploys/{id}/config` endpoint.
@@ -0,0 +1,39 @@
1
+ [project]
2
+ name = "omni-train-cli"
3
+ version = "0.1.29"
4
+ description = "CLI and agent Skill for Omni Train"
5
+ requires-python = ">=3.9,<3.13"
6
+ dependencies = [
7
+ "httpx>=0.28,<1",
8
+ "PyYAML>=6.0,<7",
9
+ "keyring>=25,<26",
10
+ "tomli>=2.0,<3; python_version < '3.11'",
11
+ ]
12
+
13
+ [build-system]
14
+ requires = ["setuptools>=68", "wheel"]
15
+ build-backend = "setuptools.build_meta"
16
+
17
+ [project.scripts]
18
+ omni = "omni_cli.main:main"
19
+ omni-train-cli = "omni_cli.main:main"
20
+
21
+ [tool.pytest.ini_options]
22
+ pythonpath = ["src"]
23
+ testpaths = ["tests"]
24
+
25
+ [dependency-groups]
26
+ dev = ["pytest>=8,<9"]
27
+
28
+ [tool.setuptools.package-dir]
29
+ "" = "src"
30
+
31
+ [tool.setuptools.packages.find]
32
+ where = ["src"]
33
+
34
+ [tool.setuptools.package-data]
35
+ omni_cli = [
36
+ "bundled_skills/omni-train/*",
37
+ "bundled_skills/omni-train/references/*",
38
+ "bundled_skills/omni-train/assets/*",
39
+ ]
@@ -0,0 +1,4 @@
1
+ [egg_info]
2
+ tag_build =
3
+ tag_date = 0
4
+
@@ -0,0 +1 @@
1
+ __version__ = "0.1.29"
@@ -0,0 +1,5 @@
1
+ from .main import main
2
+
3
+
4
+ if __name__ == "__main__":
5
+ raise SystemExit(main())
@@ -0,0 +1,194 @@
1
+ ---
2
+ name: omni-train
3
+ description: Use when operating Omni Train through the CLI, preparing custom image algorithm packages, or running dataset, training, deployment, and algorithm build workflows.
4
+ ---
5
+
6
+ # Omni Train agent workflow
7
+
8
+ Use the `omni` CLI as the only platform interface. Use `--output json` for every command and make decisions from the JSON envelope and exit code.
9
+
10
+ 1. Run `omni context show --output json` before platform work.
11
+ When the user has not selected a Workspace, keep the account's default Workspace
12
+ and do not persist an override. When the user asks which
13
+ Workspaces are available, run `omni workspace list --output json`. Only
14
+ switch after an explicit user request, using
15
+ `omni workspace use <workspace_id> --output json`; never guess a Workspace ID.
16
+ Restore the account default with
17
+ `omni workspace reset --output json`.
18
+ 2. Discover real dataset, task, and algorithm IDs with `omni dataset`, `omni task`, and `omni algorithm`; never guess IDs. Use `omni task list --page`, `--page-size`, or `--all` when the task list is paginated.
19
+ Use `--page`, `--page-size`, or `--all` when a list response is paginated.
20
+ When the user needs a new dataset, run
21
+ `omni dataset create --name <name> --type <type> --labels <label1,label2> --output json`
22
+ and retain the returned `dataset_id`. To upload a local ZIP, run
23
+ `omni dataset upload <archive.zip> --dataset-id <dataset_id> --subset-name <subset> --output json`.
24
+ This command creates the dataset subset and uses persistent TUS resumable
25
+ upload state. Keep resume enabled by default; use `--restart` only when the
26
+ user explicitly asks to discard the current upload session. File upload
27
+ completion is not dataset parsing completion. Use `--wait` only when the
28
+ user asks to wait for parsing, and report the returned upload and parse
29
+ states separately.
30
+ When the user explicitly says the ZIP contains LabelMe annotations, add
31
+ `--labeled-format json`. Each annotated image must have a `.json` file in
32
+ the same directory with the same filename stem. When a classification ZIP
33
+ is organized by label directory, add `--labeled-format folder`; every image
34
+ must be below a directory whose name exactly matches an existing dataset
35
+ label. The target must be a classification dataset using tag annotations.
36
+ A single common wrapper directory is allowed. Do not infer labeled mode
37
+ from ZIP contents when the user has not declared it.
38
+ 3. Read the selected algorithm's `params` from
39
+ `omni algorithm get <algorithm_id> --output json`, then create `train.yaml`
40
+ using `references/train-schema.md`. Standard training defaults are declared
41
+ under `params.base`. When the user does not specify `epochs`, `batch_size`,
42
+ or `input_size`, omit those fields instead of inventing values; the CLI
43
+ applies the selected algorithm's defaults. Put custom overrides under
44
+ `configuration.advanced_conf.<stage>` using only stages and keys declared
45
+ by that algorithm. Never guess a custom parameter name.
46
+ For `dataset.splits`, follow the split rules in `references/train-schema.md`:
47
+ a single subtask uses ratio split and defaults to 8:2 (`0.8`/`0.2`) when
48
+ `train`/`val` are omitted. With multiple subtasks, ask the user whether to
49
+ use ratio split (fractions on every subtask) or independent split
50
+ (`mode: independent` with `1`/`0`, naming which subtasks are train and which
51
+ are val); do not guess the strategy.
52
+ 4. Run `omni train validate --file train.yaml --output json`.
53
+ 5. Run `omni train create --file train.yaml --output json` and retain
54
+ `train_id`, `run_id`, and `invocation_id`.
55
+ 6. By default, create and start it without pausing for confirmation. Immediately
56
+ run `omni train submit --run-id <run_id> --output json` after a successful
57
+ creation. Only stop after creation when the user explicitly asks for
58
+ create-only, no start, a draft, or inspection before starting.
59
+ 7. Wait only when requested with `omni train wait <run_id>`. Do not poll indefinitely.
60
+ 8. Diagnose failures with `omni train status <run_id> --output json` and
61
+ `omni train logs <run_id> --log-type client --output json`. The `client`
62
+ log is the default and contains detailed training output such as per-epoch
63
+ metrics. Use `--log-type task` for workflow-stage messages and
64
+ `--log-type all` for a snapshot of both streams. Add `--follow` only to a
65
+ single `client` or `task` stream.
66
+ 9. Run `omni train stop <run_id>` only after the user explicitly asks to stop.
67
+ 10. On completion, use `omni train result <run_id>` for metrics and `omni train download` only when artifacts are requested.
68
+
69
+ ## Updating existing resources
70
+
71
+ Use the dedicated CLI update command. The CLI follows the platform REST
72
+ contract: algorithms, projects, and training tasks use their standard resource
73
+ `PATCH` endpoints; only deployment configuration uses a dedicated `config`
74
+ endpoint. Updates do not start, stop, delete, upload, rebuild, or resubmit
75
+ anything.
76
+
77
+ - Algorithm metadata: `omni algorithm update <algorithm_id> --file algorithm-update.yaml --output json`.
78
+ Only `name`, `description`, `type`, and `params` are editable. Use
79
+ `omni algorithm upload --algorithm-id` when source code changes.
80
+ - Project metadata: `omni project update <project_id> --file project-update.yaml --output json`.
81
+ Only `name` and `description` are editable; project type is immutable.
82
+ - Training configuration: `omni train update <run_id> --file train.yaml --output json`.
83
+ The task must still be `new`. Keep `project.train_id` and `run.type`
84
+ unchanged. The selected algorithm is read again so omitted base/custom
85
+ parameters use that algorithm's defaults. When `dataset` or `configuration`
86
+ is supplied, it replaces that entire nested section.
87
+ - Deployment configuration: `omni deploy update <deploy_id> --file deploy.yaml --output json`.
88
+ The deployment must still be `new`. The CLI and server revalidate the
89
+ completed model, ONNX artifact, chip, system, framework, and quantization.
90
+ Deployment format remains ONNX.
91
+
92
+ Always inspect the JSON returned after an update. The CLI re-fetches the
93
+ resource so the response reflects server-authoritative values. If a training
94
+ task or deployment has started, create a new one instead of trying to mutate
95
+ runtime state.
96
+
97
+ `omni train submit --file train.yaml --output json` remains a
98
+ backward-compatible shortcut that creates and immediately starts a task. Use
99
+ the explicit create-then-submit flow when the task must be inspected before
100
+ starting.
101
+
102
+ During `omni train create` and the compatible file-based submit shortcut, the
103
+ CLI fetches the selected algorithm, fills omitted base and custom values from
104
+ its defaults, applies the values in `train.yaml` as overrides, and validates
105
+ types, choices, and ranges. The supported image algorithm stages are
106
+ `dataset_preprocess`, `train`, `val`, `dataset_postprocess`, and
107
+ `convert_onnx`. `omni train validate` is offline and checks only the file
108
+ structure; create-time validation is authoritative for the selected algorithm.
109
+
110
+ ## Completed model deployment
111
+
112
+ When the user asks to convert, package, or deploy a completed training model,
113
+ **MUST read** `references/deployment.md` completely before acting.
114
+
115
+ 1. Run `omni deploy platforms --output json` and select only a target returned
116
+ by the current Workspace.
117
+ 2. Confirm the selected model is completed with
118
+ `omni train get <model_id> --output json`. Never deploy an unfinished model.
119
+ 3. Create `deploy.yaml` from `assets/deploy.example.yaml`. Use only the chip,
120
+ framework, system, quantization, and input values supported by the selected
121
+ platform. Never send web-only fields such as `vendor`, `vendoor`,
122
+ `platform`, `compiler`, or `model_name`.
123
+ 4. By default, create and start the deployment without pausing for confirmation
124
+ with `omni deploy submit --file deploy.yaml --output json`. Only stop after
125
+ creation when the user explicitly asks for create-only, no start, a draft,
126
+ or inspection before starting; in that case use
127
+ `omni deploy create --file deploy.yaml --output json`.
128
+ 5. Query `omni deploy status <deploy_id> --output json` and
129
+ `omni deploy logs <deploy_id> --output json`. Use
130
+ `omni deploy wait <deploy_id> --output json` only when the user asks to wait,
131
+ and never poll indefinitely.
132
+ 6. Download the completed package only when requested. When the deployment SDK
133
+ is requested, use
134
+ `omni deploy sdk <deploy_id> --output-path ./artifacts/omni-sdk.zip --output json`.
135
+ The deployment's stored `system` and `platform` are authoritative: never
136
+ invent or send target overrides for SDK download.
137
+ 7. Stop or delete a deployment only after an explicit user request. Preserve
138
+ failed and stopped records and their logs by default.
139
+
140
+ ## Custom image algorithm development
141
+
142
+ When asked to generate, modify, validate, package, or troubleshoot a local
143
+ custom image algorithm, **MUST read**
144
+ `references/custom-image-algorithms.md` completely before acting. Treat that
145
+ reference as the authoritative contract for entrypoints, configuration,
146
+ LabelMe data, stage inputs and outputs, metrics, ONNX artifacts, local
147
+ verification, packaging, and troubleshooting. Do not invent paths or rebuild
148
+ platform-managed configuration fields.
149
+
150
+ When generating a new image algorithm, follow the advisory per-epoch logging
151
+ pattern in `references/custom-image-algorithms.md`. Skill-generated image
152
+ algorithms should emit one progress record after every completed epoch to both
153
+ standard output and `config["log_path"]`. This is not an upload requirement:
154
+ do not reject, rewrite, or diagnose an independently developed algorithm only
155
+ because its logs use another format.
156
+
157
+ For Skill-generated algorithms, apply the headless image dependencies rules in
158
+ the reference. Never generate GUI-enabled OpenCV or Ultralytics requirements
159
+ for the platform training container.
160
+
161
+ For every Skill-generated custom image algorithm, generate a separate
162
+ `algorithm.params.yaml` from `assets/algorithm.params.example.yaml`. Its
163
+ `params.base` configuration must declare `epochs`, `batch_size`, and
164
+ `input_size`. Recommend at least one `params.train` custom group using only
165
+ values the generated training code actually reads, normally including `lr`
166
+ and `optimizer`. Adjust ranges and defaults to the real algorithm instead of
167
+ copying the example mechanically.
168
+
169
+ Pass the file explicitly during upload with
170
+ `--params-file algorithm.params.yaml`. The CLI does not auto-discover parameter
171
+ metadata in the ZIP or working directory. A user-supplied algorithm may still
172
+ be uploaded without a parameter file; explain that its corresponding training
173
+ controls will not be declared until parameter metadata is added.
174
+
175
+ Before uploading or rebuilding an algorithm, **MUST also read**
176
+ `references/cli-commands.md` and use the documented `omni algorithm upload`
177
+ arguments. Run `omni algorithm upload --help` if the installed CLI may differ
178
+ from the bundled reference. Use `omni algorithm base-images --output json` to
179
+ inspect the platform-supported images. Never guess an algorithm ID or base
180
+ image value. When `--base-image` is omitted, the CLI uses the single image
181
+ marked as the platform default.
182
+
183
+ After local verification succeeds, use `omni algorithm upload`. The command
184
+ validates the ZIP archive locally, creates the algorithm when `--algorithm-id`
185
+ is not supplied, uploads the archive, and submits the platform build workflow.
186
+ The archive must have one top-level directory containing
187
+ `dataset_preprocess.py`, `train.py`, `val.py`, `dataset_postprocess.py`,
188
+ `convert_onnx.py`, and `requirements.txt` directly under that directory.
189
+ Retain the returned algorithm and build IDs. Diagnose the build with
190
+ `omni algorithm build-status <algorithm_id> <build_id>` and
191
+ `omni algorithm build-logs <algorithm_id> <build_id>`. Use
192
+ `omni algorithm builds <algorithm_id>` when the build ID must be discovered.
193
+
194
+ Never print or request an API Key in chat, call arbitrary REST URLs, access Django models, or parse human-readable CLI output.
@@ -0,0 +1,60 @@
1
+ # Parameter metadata uploaded with:
2
+ # omni algorithm upload ... --params-file algorithm.params.yaml
3
+ # Adjust ranges and defaults to match the algorithm implementation.
4
+
5
+ base:
6
+ epochs:
7
+ key: epochs
8
+ name: Epochs
9
+ choice_type: range
10
+ choice_value: [1, 200]
11
+ value_type: int
12
+ default: 100
13
+ step: 1
14
+ tips: Number of completed training epochs.
15
+
16
+ batch_size:
17
+ key: batch_size
18
+ name: Batch size
19
+ choice_type: range
20
+ choice_value: [1, 512]
21
+ value_type: int
22
+ default: 16
23
+ step: 1
24
+ tips: Number of samples processed in one training batch.
25
+
26
+ input_size:
27
+ key: input_size
28
+ name: Input size
29
+ choice_type: s_range
30
+ choice_value: [32, 2048]
31
+ value_type: int
32
+ default: [224, 224]
33
+ step: 1
34
+ tips: Model input size in [width, height] order.
35
+
36
+ train:
37
+ learning-rate:
38
+ key: lr
39
+ name: Learning rate
40
+ choice_type: range
41
+ choice_value: [0.000001, 1.0]
42
+ value_type: float
43
+ default: 0.001
44
+ step: 0.000001
45
+ tips: Initial optimizer learning rate.
46
+
47
+ optimizer:
48
+ key: optimizer
49
+ name: Optimizer
50
+ choice_type: choice
51
+ choice_value:
52
+ - label: SGD
53
+ value: SGD
54
+ - label: Adam
55
+ value: Adam
56
+ - label: AdamW
57
+ value: AdamW
58
+ value_type: string
59
+ default: AdamW
60
+ tips: Optimizer used by the train stage.
@@ -0,0 +1,18 @@
1
+ schema_version: 1
2
+ name: resnet18-qcs6490-int16
3
+ model_id: 53
4
+ format: ONNX
5
+ chip: QCS6490/QCM6490
6
+ system: Android
7
+ framework: Qualcomm
8
+ quantized: true
9
+ configuration:
10
+ weight_type: int16
11
+ use_weight_per_channel: true
12
+ inputs:
13
+ - name: input
14
+ type: image
15
+ data_size: [224, 224]
16
+ mean: [0.485, 0.456, 0.406]
17
+ std: [0.229, 0.224, 0.225]
18
+ built_in_dataset: coco
@@ -0,0 +1,31 @@
1
+ schema_version: 1
2
+ project:
3
+ name: vehicle-detection
4
+ type: image
5
+ run:
6
+ name: baseline
7
+ type: detection
8
+ algorithm_id: 18
9
+ dataset:
10
+ dataset_id: [25, 30]
11
+ label: [cat, dog]
12
+ splits:
13
+ - task_id: 69
14
+ mode: independent
15
+ train: 1
16
+ val: 0
17
+ - task_id: 68
18
+ mode: independent
19
+ train: 0
20
+ val: 1
21
+ configuration:
22
+ # Optional overrides. Omit them to use the selected algorithm's defaults.
23
+ # epochs: 1
24
+ # batch_size: 1
25
+ # input_size: [224, 224]
26
+ # Use only stages and keys declared by `omni algorithm get 18`.
27
+ # Omitted declared values are filled from that algorithm's defaults on submit.
28
+ advanced_conf:
29
+ train:
30
+ lr: 0.1786
31
+ optimizer: SGD