Add sound type annotations: model execution and adapters
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Active
- Domain
- machine-learning
Research direction
Claim one slice first, then pick one file such as nemo_automodel/components/models/common/utils.py, attention/flex_attention.py, _peft/lora_experts.py, moe/load_balance_metrics.py, quantization/qlora.py or speculative/bench_common.py. Read CODING_GUIDELINES.md and AGENTS.md, trace its callers, and run the configured ty check and Ruff on it. Done means truthful signatures with no Any or new suppressions, and before/after signatures recorded.
Written by the indexing model from the issue text.
Description
Parent: NVIDIA-NeMo/Automodel#4607 / GitHub #4607.
Scope: Model execution and adapters
models/: Shared model utilities and model-owned configuration, forward, and adapter contracts. Start with one shared utility or one model family, not a repository-wide model rewrite.attention/: Attention masks, attention call signatures, and backend inputs/outputs; document mask shapes and semantics._peft/: LoRA adapter inputs, expert adapter state, module matching, and PEFT configuration.moe/: Routing/dispatch/expert contracts, load-balancing metrics, and configuration; preserve placement, synchronization, and tensor layouts.quantization/: Quantization config and conversion interfaces; preserve module/parameter identity, backend behavior, and dtype semantics.speculative/: Speculative benchmark/evaluation records and draft-model interfaces; begin with a small utility before kernel or decoding paths.
Suggested first contribution
Pick one module below, inspect its actual callers, and propose a few missing/imprecise signatures or one boundary contract. Already-correct code needs no cosmetic rewrite. Claim the slice in this issue before starting; keep the group open until its remaining scope is covered.
models/common/utils.pyattention/flex_attention.py_peft/lora_experts.pymoe/load_balance_metrics.pyquantization/qlora.pyspeculative/bench_common.py
Required annotation-policy branch
Until draft PR #4653 is merged, base annotation work on akoumpa/ci/annotation-policy from akoumpa/Automodel. This branch adds the annotation-policy checker alongside ty; it is not yet part of upstream main. Current policy commit: ef93d5e70.
From a clean checkout, create your contribution branch with:
git fetch https://github.com/akoumpa/Automodel.git akoumpa/ci/annotation-policy
git switch -c my-annotation-slice FETCH_HEAD
For an existing contribution branch, fetch the same policy branch and merge FETCH_HEAD into your branch instead of creating a new one. Link #4653 as a dependency in your PR; after it merges, update your branch onto upstream main.
Run the shared entry point from the repository root in the configured development environment:
uv run --group linting python tools/check_types.py
ty.toml owns type-checker settings and the existing opt-in module list. tools/annotation_policy.toml owns exact annotation-slot exceptions and the legacy inventory. New object annotations fail unless a maintainer reviews a specific exception with a reason for genuinely opaque values. Do not add to or increase the legacy inventory; remove/reduce entries when fixing their annotations. Runtime object() sentinels and Literal/Annotated metadata are unaffected.
The policy scans nemo_automodel and examples, but ty still checks only its configured opt-in modules through this entry point. Also run a targeted uv run --group linting ty check <affected-path> for your slice when it falls outside that scope, and report any exclusions or missing dependencies. A passing policy check does not establish type soundness: it does not infer types or resolve cross-module aliases, and all requirements below still apply.
Annotation requirements (applies to every sub-issue)
Read CODING_GUIDELINES.md and AGENTS.md. This campaign requires real contracts, not annotation-count improvements alone.
- Trace actual callers and implementations before choosing types. Annotate parameters, returns, and relevant stored attributes; include
-> Nonefor constructors and methods that return nothing. Preserve supported inputs, defaults, return forms, and subclass compatibility. - Use concrete types and parameterized containers. Prefer
Sequence[T],Mapping[K, V],Iterable[T], and precisely typed callbacks when those are the operations the consumer needs. UseT | Noneonly whenNonereally is supported, and narrow it before use. - Reuse existing typed configs and interfaces. Use small consumer-owned
Protocols for genuine structural contracts,TypedDictfor fixed-key records, and dataclasses for owned configuration/state. Use generics and overloads only for relationships demonstrated by real callers. Do not introduce cross-component imports or move types intosharedmerely to evade import boundaries. - No
Any, including nestedAny, aliases to it,**kwargs: Any, or newly propagated implicit Any from untyped containers/callbacks/decorators/dependencies. No baredict,list,Callable, orCallable[..., ...]used to erase a known signature. Parameterize generic bases as well. - No escape hatches: do not add
typing.cast,# type: ignore,# ty: ignore,# pyright: ignore,@no_type_check, blanketnoqa, checker exclusions, disabled diagnostics, or fake stubs/protocols that merely assert an unverified interface. Existing suppressions are not precedent; remove them in the completed slice where feasible and explicitly track anything that remains. objectis valid for a genuinely opaque value or an unvalidated boundary input, not as a replacement forAnyor a bag that hides a known schema. Validate external data at its boundary; do not add reflection, speculativegetattr/hasattr, runtime-checkable Protocol probes, or assertions solely to convince the checker. Retain real validation and supported compatibility behavior.- For untyped third-party APIs, first use available upstream types; otherwise provide a narrow, truthful boundary adapter/stub whose contract is verified against the supported dependency. Do not spread dependency uncertainty through component interfaces. Report a blocked boundary instead of masking it.
torch.Tensordoes not encode shape, dtype, device, or distributed placement. Document relevant tensor and semantic contracts, including axis order, optional fields, aliasing, token/label alignment, and storage versus compute dtype where applicable.- Preserve runtime behavior, public APIs, optional-dependency import safety, and tensor math. Use deferred annotations /
TYPE_CHECKINGimports where appropriate without making runtime annotation consumers fail. No new import-time GPU/dependency requirements. Keep behavioral fixes and broad refactors separate.
Validation and completion
- Claim a small slice (one module or a few related functions) in the sub-issue before implementation. Inspect current main: already-correct code needs no cosmetic rewrite. Larger components require multiple small PRs; one starter PR does not complete the component.
- Record before/after missing or imprecise signatures and remaining
Any/suppression sites for that slice. Use the repository's annotation coverage reporter / Python annotation coverage CI as supporting evidence, not proof of type soundness. - Run
uv run --group linting python tools/check_types.pyfrom the annotation-policy branch, plus targetedtychecking and Ruff on the affected files, and appropriate existing tests. Record exact commands, dependency versions, results, and any pre-existing diagnostics. Confirm the changed files were actually checked;ty.tomlcurrently excludes checkpoint_backportsand relaxes some diagnostics. Do not weaken configuration. If a slice is excluded, supply a targeted check that includes it and report the limitation. - Audit actual callers and concrete implementations against the declared contracts; a green checker with untyped dependencies is insufficient. Run import checks for optional-dependency/type-only import changes. If runtime tensor/distributed behavior changes, require the corresponding real forward/backward or multi-process validation rather than mocks alone.
- A completed slice has fully specified, truthful contracts with no new escape hatches and no new diagnostics. Keep the group issue open until remaining public APIs/config contracts and required internal helpers are covered, or explicitly document an audited no-change result. Keep the parent table current when group work is complete.
- Dominant language
- Python
- Stars
- 1.1k
- Forks
- 366
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 281
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from NVIDIA-NeMo/Automodel
-
community-request waiting-on-maintainers
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
NVIDIA-NeMo/Automodel#3767 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 5/100
NVIDIA-NeMo/Automodel#4627 ·
Maintainers usually reply within 1 day
-
Add sound type annotations: training lifecycle and optimizersPossibly taken @akoumpa claimed this 3 days ago. Opengood first issue help wanted PoR
NVIDIA-NeMo/Automodel#4626 · 1 comment · 1 assignee ·
Maintainers usually reply within 1 day
-
Add sound type annotations: data, evaluation, and objectivesPossibly taken @Alan-donk claimed this 3 days ago. Opengood first issue help wanted PoR
Difficulty 3/5 Half a day Newbie friendliness 55/100
NVIDIA-NeMo/Automodel#4614 · 1 comment ·
Maintainers usually reply within 1 day
-
Add sound type annotations: configuration, launchers, and utilitiesPossibly taken @zahidSkywalker claimed this 3 days ago. Opengood first issue help wanted PoR
Difficulty 3/5 1-2 days Newbie friendliness 48/100
NVIDIA-NeMo/Automodel#4612 · 3 comments ·
Maintainers usually reply within 1 day
All issues in NVIDIA-NeMo/Automodel
Similar issues
-
area/test type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Clodmony/starship-coop#70 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
punitarani/fli#270 ·
-
🐛 Bug 🔔 Pending processing
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
jumpserver/jumpserver#17980 ·
Maintainers usually reply within 1 day
-
community enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
namespace
Difficulty 2/5 1-3 hours Newbie friendliness 60/100
EclipseFdn/open-vsx.org#15341 ·
Maintainers usually reply within 1 day