build(python): move the Linux NPU worker to 3.14 (#13747)

[mrveiss]

Thinking Path

#10877 pinned the NPU worker to Python 3.11 because OpenVINO shipped no 3.14 wheels. That single pin is load-bearing beyond the worker: it is also why black's target-version stays at py312 (#13748), since PEP 758 except A, B: would be a hard SyntaxError on shared code the 3.11 worker imports.

I re-measured the premise rather than trusting the recorded reason. Against the PyPI JSON API on 2026-08-08:

Package	Latest	Python tags	3.14?
openvino	2026.3.0	cp310, cp311, cp312, cp313, cp314	✅
torch	2.13.0	cp310, cp311, cp312, cp313, cp314	✅
numpy	2.5.1	cp312, cp313, cp314	✅
onnxruntime-openvino	1.24.1	cp311, cp312, cp313	❌ no cp314

"openvino has a cp314 wheel" is weaker evidence than it looks, so I resolved the worker's actual requirements on 3.14 — the full graph, not one package:

$ venv/bin/python -m pip install --dry-run --ignore-installed -r autobot-npu-worker/requirements.txt
Would install ... numpy-2.5.1 openvino-2026.3.0 openvino-telemetry-2025.2.0 ... torch-2.13.0 triton-3.7.1 ...

No conflicts, no fallback to an sdist. That is the whole set the worker installs.

What Changed

Interpreter moved 3.11 → 3.14 in the two places that build the venv:

• roles/npu-worker/tasks/main.yml — the canonical path (interpreter install, ensure_venv_version, -m venv)
• playbooks/deploy-native-services.yml — the documented operator path (apt packages, ensure_venv_version, -m venv, virtualenv_python)

Plus the places that described the old split: the Phase 1.5 NPU play in deploy-full.yml, and the header comments in configure-python-provision-permissions.yml and provision-local-python.yml.

The upgrade-in-place hazard, and why it is already handled

The real risk is not a fresh install — it is a box that already has a 3.11 venv. Recreating it as 3.14 over existing site-packages leaves 3.11-built OpenVINO native extensions in place; that fails at import or first inference, long after the deploy reports success.

Both paths already call ensure_venv_version before creating the venv, which detects a wrong-version venv and removes it. That task is what makes this change safe in place, so I documented it as load-bearing rather than leaving it looking incidental.

Deliberately not in scope

The Windows NPU worker (autobot-npu-worker/resources/windows-npu-worker/) pins onnxruntime-openvino, which has no cp314. It is untouched — confirmed no Windows file appears in this diff.

I also kept the separate Phase 1.5 NPU play rather than folding it into the backend:aiml one. npu is a distinct host group that pattern does not reach, and the python314 role is idempotent, so a co-located host just skips the second install.

Verification

$ ansible-playbook --syntax-check -i inventory/hosts.yml <each changed playbook>
deploy-native-services.yml                    SYNTAX OK
deploy-full.yml                               SYNTAX OK
provision-local-python.yml                    SYNTAX OK
configure-python-provision-permissions.yml    SYNTAX OK

$ ansible-playbook --syntax-check -i inventory/hosts.yml playbooks/provision-fleet-roles.yml
SYNTAX OK          # this is the playbook that applies roles/npu-worker, so the role graph parses

No python3.11 pin remains for the Linux worker anywhere in ansible/. The one surviving mention is a parameter example in ensure_venv_version.yml's docstring, which documents the argument's form and is not a pin.

This PR does not close #13747

Its acceptance criteria require the worker to start and serve inference on 3.14, verified on a host — explicitly not by a successful pip install. OpenVINO failures are native-extension failures that surface at import or first inference, so a green resolution proves the dependency set solves, not that the NPU runs.

I have no NPU host to verify against, so the issue stays open pending that deploy evidence. Merging this is what makes the next NPU deploy use 3.14; confirming it worked is a separate, host-side step.

#13748 (black → py314) remains blocked and must not be taken as unblocked by this merge. It is unblocked only once the worker is running 3.14 — reversing that order writes PEP 758 syntax into shared code a still-3.11 worker imports, which is a SyntaxError at import, in production.

Model Used

Claude Opus 5 (1M context)

Part of #13743

[mrveiss]

Review — pre-merge pass

Reviewed against origin/Dev_new_gui at 8db4b879. Self-review recorded as a comment (GitHub blocks self-approval).

What this actually changes

Five files, all Ansible. Two of them build a venv and are the real change; three carry comments that named the old 3.11/3.14 split.

File	Change	Load-bearing?
roles/npu-worker/tasks/main.yml	interpreter install, ensure_venv_version, -m venv → 3.14	yes — canonical path
playbooks/deploy-native-services.yml	apt packages, ensure_venv_version, -m venv, virtualenv_python → 3.14	yes — documented operator path
playbooks/deploy-full.yml	Phase 1.5 NPU play → 3.14	yes, name + version var
configure-python-provision-permissions.yml, provision-local-python.yml	header comments	no

The risk I looked hardest at

Not the fresh install — the upgrade in place. A box with an existing 3.11 venv, recreated as 3.14 over the same site-packages, keeps 3.11-built OpenVINO native extensions. That fails at import or first inference, well after the deploy reports success, which is the worst shape of failure available here.

Both changed paths already call ensure_venv_version before creating the venv, and that task removes a wrong-version venv. So the hazard is handled by code that already existed — I documented it as load-bearing rather than leaving it looking incidental, because a future edit that drops it would silently reintroduce this.

Checks

Risk	Check	Result
Wheels exist but the graph does not solve	pip install --dry-run of the worker's real requirements.txt on 3.14	Solves: openvino-2026.3.0, torch-2.13.0, numpy-2.5.1, no conflicts, no sdist fallback
A 3.11 pin left behind	Grepped python3.11 across ansible/	Only a parameter example in ensure_venv_version.yml's docstring — documents the argument form, not a pin
Windows worker dragged along	git status for any Windows path	Untouched. It pins onnxruntime-openvino, which has no cp314 (1.24.1 = cp311–cp313)
Broken playbook syntax	ansible-playbook --syntax-check on all four changed playbooks	All OK
Broken role graph	--syntax-check on provision-fleet-roles.yml, which applies roles/npu-worker	OK

Judgement call

I kept the separate Phase 1.5 NPU play instead of folding it into the backend:aiml one now that both install 3.14. npu is a distinct host group the backend:aiml pattern does not reach, and the python314 role is idempotent so a co-located host just skips the second install. Consolidating would have been a behaviour change dressed as cleanup.

What this PR does not do

It does not close #13747. The AC requires the worker to start and serve inference on 3.14 verified on a host; a clean dependency resolution is not that evidence, because OpenVINO fails at import or first inference rather than at install. No NPU host is reachable from here.

It does not unblock #13748. That needs the worker running 3.14, not a merged config change — and the Windows-worker question is still open.

Verdict

No blocking findings.