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.
- omni_train_cli-0.1.29/PKG-INFO +9 -0
- omni_train_cli-0.1.29/README.md +201 -0
- omni_train_cli-0.1.29/pyproject.toml +39 -0
- omni_train_cli-0.1.29/setup.cfg +4 -0
- omni_train_cli-0.1.29/src/omni_cli/__init__.py +1 -0
- omni_train_cli-0.1.29/src/omni_cli/__main__.py +5 -0
- omni_train_cli-0.1.29/src/omni_cli/bundled_skills/__init__.py +0 -0
- omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/SKILL.md +194 -0
- omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/assets/algorithm.params.example.yaml +60 -0
- omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/assets/deploy.example.yaml +18 -0
- omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/assets/train.example.yaml +31 -0
- omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/references/cli-commands.md +145 -0
- omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/references/custom-image-algorithms.md +473 -0
- omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/references/deployment.md +82 -0
- omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/references/error-handling.md +17 -0
- omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/references/train-schema.md +126 -0
- omni_train_cli-0.1.29/src/omni_cli/client.py +425 -0
- omni_train_cli-0.1.29/src/omni_cli/commands.py +1489 -0
- omni_train_cli-0.1.29/src/omni_cli/config.py +48 -0
- omni_train_cli-0.1.29/src/omni_cli/credentials.py +25 -0
- omni_train_cli-0.1.29/src/omni_cli/deploy_schema.py +109 -0
- omni_train_cli-0.1.29/src/omni_cli/main.py +302 -0
- omni_train_cli-0.1.29/src/omni_cli/output.py +45 -0
- omni_train_cli-0.1.29/src/omni_cli/schema.py +412 -0
- omni_train_cli-0.1.29/src/omni_cli/uploads.py +241 -0
- omni_train_cli-0.1.29/src/omni_train_cli.egg-info/PKG-INFO +9 -0
- omni_train_cli-0.1.29/src/omni_train_cli.egg-info/SOURCES.txt +29 -0
- omni_train_cli-0.1.29/src/omni_train_cli.egg-info/dependency_links.txt +1 -0
- omni_train_cli-0.1.29/src/omni_train_cli.egg-info/entry_points.txt +3 -0
- omni_train_cli-0.1.29/src/omni_train_cli.egg-info/requires.txt +6 -0
- 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 @@
|
|
|
1
|
+
__version__ = "0.1.29"
|
|
File without changes
|
|
@@ -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.
|
omni_train_cli-0.1.29/src/omni_cli/bundled_skills/omni-train/assets/algorithm.params.example.yaml
ADDED
|
@@ -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
|