SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillslnn-model-design

lnn-model-design

Design & creation

View repository

Updated 10-16 00:00

About this skill

LNN Model-Assisted Design

Core Workflow

Treat this skill as an architecture gate before training or deployment. Advance in a short loop of "audit -> modify -> re-review" until the model can pass Linger export and Thinker packaging.

  1. Requirements Gathering: Collect the application goal, target platform (venus、mars、arcs、venusa), input shape/range, latency/memory/accuracy targets, current model source, and whether the model is currently in float, constrained, QAT, or already-exported ONNX state.
    If the target platform is missing, have the user confirm it first before doing a capability scan or pass/fail judgment.
    If the model input size, input shape, or dynamic input range is missing, have the user confirm it first before doing parameter, activation, memory, or compatibility analysis.
  2. Capability Scan: Run scripts/collect_toolchain_capabilities.pyagainst the local toolchain root. When you need to look up source paths, documentation, or command variants, read references/toolchain-sources.md. When you need the hands-on order for Linger -> tpacker -> x86 -> tvalidator -> tprofile , read references/workflow-playbook.md。
  3. Static Model Audit: If ONNX already exists, run scripts/inspect_onnx_model.py; otherwise estimate tensor/parameter size from the PyTorch module or structure description, and identify unsupported PyTorch ops before export.
  4. Adaptation Decision: Compare ops, precision, parameter bytes, activation bytes,tpacker threshold, SRAM/PSRAM, dynamic shape range, and customer requirements. Before proposing structural modification suggestions, read references/adaptation-guidelines.md. Before deciding whether the fix is architecture shrinkage, threshold tuning, stream split, or explicit op split, read references/npu-split-strategy.md. When the gate failure reason is unclear, first run scripts/triage_gate_blocker.pyto rank structure / split-policy / threshold / toolchain hypotheses before changing the model.
  5. Full-Process Gate: Export with Linger, package with Thinker tpacker , and when the runtime library / input is available, verify via tvalidator or the direct test_thinker / test_dynamic path. Refer to references/full-flow.md, or you can directly use scripts/run_toolchain_gate.py. If you already have a failing tvalidator log or runtime log, feed it back into run_toolchain_gate.pyso the gate can triage runtime/consistency issues and automatically generate an author issue bundle as needed.
  6. Toolchain Bug Handoff: If Linger / Thinker / tpacker / tvalidator itself behaves abnormally, or the packaged model shows a consistency mismatch that looks more like a toolchain issue than an architecture issue, stop large-scale repeated structural modification. Read references/author-handoff-template.md, run scripts/generate_author_issue_bundle.py, generate problem.md and repro.sh, and save a minimal reproducible bundle for the author to investigate.
  7. Results Reporting: Output the pass/fail matrix, explicit blockers, precise tuning suggestions, commands/logs/artifacts, next-round actions, and, when applicable, the author handoff bundle path. For the report structure, refer to references/report-template.md。

Sub-skill Modules

  • requirements-to-candidate: Convert customer constraints into a small number of LNN-friendly candidate blocks. Prefer ops already listed by Linger and Thinker; avoid unconventional control flow, unsupported normalization, unsupported activation, and overly large single tensors.
  • capability-discovery: From the local linger/ and thinker/ Extract the current hardware, op, precision, threshold, and x86 validation flow information from the source tree, rather than relying on memory.
  • model-static-audit: Inspect the existing architecture or ONNX, covering op support, dtype/precision risks, dynamic axes, parameter size, large initializers, and activation/input shapes.
  • blocker-triage: Combine ONNX and the optional tpacker / memory / tvalidator log to decide whether the next step should prioritize changing the structure, split policy, threshold tuning, or going directly to toolchain bug handoff.
  • adaptation-loop: Propose the smallest possible structural modifications to remove the blocker: replace ops, adjust kernel/stride/dilation, adjust channel/resolution, split layers, streaming, restrict dynamic shapes, or adjust the memory threshold. First check the single-compute limit, then distinguish whether it is an architecture problem or a toolchain split-policy problem.
  • export-pack-validation: When conditions permit, actually run the Linger export, Thinker tpacker and tvalidator/runtime checks. Treat packaging success as necessary evidence before final sign-off.
  • toolchain-bug-handoff: When the blocker looks more like a Linger/Thinker program defect or a runtime consistency defect, generate an author-facing issue file and a minimal reproducible ONNX/pkg/input/script bundle.

Necessary Evidence

This skill has two working modes:

  1. Full LNN validation mode: When Linger/Thinker tools are available locally, use the tpacker / tvalidator / runtime results as the final evidence.
  2. Offline architecture-audit mode: When the LNN environment is unavailable, still use the skill's built-in hardware, operator, precision, memory, and split constraints to provide a static compatibility assessment.

Unless the tools cannot run, do not draw compatibility conclusions based on documentation alone. The evidence priority order is as follows:

  1. The exported ONNX tpacker successfully on the target platform.
  2. tvalidator consistency passes, or there is a clear explanation of why it cannot be run.
  3. Static ONNX audit plus capability scan.
  4. Manual estimation based on architecture text and source doc.

If a tool cannot run, explicitly state the missing dependency or artifact, then continue to provide the strongest static assessment currently possible. In offline mode, recommendations must be based on the platform limits, operator/precision support, memory thresholds, and split rules stored in the skill, and must clearly note that the result is only preflight guidance, not final runtime proof. If a tool appears not to be "unavailable" but rather "problematic in its own behavior," do not just summarize in prose; directly generate an author handoff bundle.

Inputs That Must Be Confirmed When Missing

The following inputs are mandatory for reliable assessment:

  • Target platform。
  • Model input size, input shape, or dynamic input range.

If any of these is missing or ambiguous, first ask the user to confirm. When making a compatibility verdict, do not assume a default platform or default image size on your own.

Usage Overview

Brief user-facing usage instructions are in references/usage-intro.md. For a quick reference of platform hardware limits, see 聆思芯片硬件限制.md。

Common Commands

Under a toolchain root that contains both linger/ and thinker/ , run:

python3 lnn-model-design/scripts/collect_toolchain_capabilities.py --platform venusa --format markdown
python3 lnn-model-design/scripts/inspect_onnx_model.py model.onnx --capabilities-json capabilities.json --platform venusa --format markdown
python3 lnn-model-design/scripts/run_toolchain_gate.py --onnx model.onnx --platform venusa --out-dir design_gate
python3 lnn-model-design/scripts/run_toolchain_gate.py --onnx model.onnx --platform venusa --out-dir design_gate --tvalidator-log design_gate/tvalidator.log --auto-author-bundle
python3 lnn-model-design/scripts/run_toolchain_gate.py --onnx model.onnx --platform venusa --out-dir design_gate --runtime-log design_gate/test_thinker.log --auto-author-bundle
python3 lnn-model-design/scripts/run_toolchain_gate.py --onnx model.onnx --platform venusa --dynamic_shape seq=32:384:32 --out-dir design_gate --runtime-log design_gate/test_dynamic.log --auto-author-bundle
python3 lnn-model-design/scripts/triage_gate_blocker.py --onnx model.onnx --platform venusa --tpacker-log design_gate/tpacker.log --memory-report workspace/model/model_memory_report.txt --format markdown
python3 lnn-model-design/scripts/generate_author_issue_bundle.py --case-name venusa_case1 --platform venusa --onnx model.onnx --tpacker-log design_gate/tpacker.log --triage-json design_gate/blocker_triage.json --repro-cmd 'PYTHONPATH=thinker/tools python3 -m tpacker.tpacker -g model.onnx -p venusa -o model.pkg -d True'

If you run this skill from another directory, add --toolchain-root。

When you need to report a suspected Linger/Thinker bug, save the issue bundle under lnn_model_design_reports/<case>_author_issue/ , and include at least problem.md、repro.sh、bundle_manifest.json, minimal model artifact, required inputs, and failure logs.

Decision Rules

  • If an op is missing on either the Linger export support or Thinker target-platform support side, first propose a supportable alternative, then discuss accuracy tuning.
  • If the target platform is missing, before running collect_toolchain_capabilities.py、inspect_onnx_model.py or run_toolchain_gate.py , have the user confirm first.
  • If the model input size or dynamic range is missing, before estimating activation memory, evaluating dynamic shape, or giving a final adaptation conclusion, have the user confirm first.
  • If tpacker reports memory overflow, first determine whether the greatest pressure comes from the DMA buffer, workspace, or intermediate output; then, in combination with the single-compute split rule in references/npu-split-strategy.md , decide whether to reduce channels, split height/width, or readjust the threshold / memory placement.
  • If tpacker / tvalidator reports an internal assertion or invalid runtime parameter on a graph that should be supported, or a consistency mismatch still occurs after successful packaging, treat it as a potential toolchain defect; first prepare an author handoff bundle, then consider continuing with large-scale structural rewriting.
  • For toolchain bug handoff, minimize the case as aggressively as possible: keep the same target platform and input shape, remove irrelevant layers, isolate the first failing op/subgraph as much as possible, preserve the exact tool flags, and include the minimal set of script / ONNX / pkg / input that can still reproduce the problem.
  • Before long training runs, prioritize doing a quick preflight: make quant-init at least sufficient to export ONNX, run tpacker, and first confirm that the graph is structurally deployable.
  • If the input shape is dynamic, evaluate using the declared maximum shape rather than only the common runtime shape.
  • If the model is still only a proposal, first build a minimal dummy model/export harness, run the gate once with randomly initialized weights, and then decide whether it is worth investing in training.
  • For each round of changes, try to keep it "small and testable": one blocker, one hypothesis, one revised command, one new result.