thinker-model-pack-validation

Thinker Model Packaging and Consistency Verification

Perform the complete Thinker algorithm adaptation on the quantized ONNX computation graph exported by Linger: starting from model inspection, complete packaging, splitting analysis, parameter optimization, and consistency verification. When the input information is complete, execute autonomously; do not merely provide suggested commands; you need to actually run, inspect results, iterate parameters, complete verification, and report conclusions.

Required Inputs

Before packaging, obtain or reliably infer the following information:

Quantized ONNX path.
Actual target platform:venus、arcs or venusa。
The actually available shared memory and PSRAM limits of the deployment target.
The shape range of each symbolic dimension for dynamic models.
Optional fixed .npy inputs; the order must match the ONNX graph inputs.
Optional existing libthinker.so, which must be built for the same platform and have result dump enabled.
Optional subgraph boundaries or streaming mode, used only when the deployment design explicitly requires them.

Ask a single brief question only when the necessary information cannot be safely inferred. Fabricating hardware memory capacity is prohibited. If the user does not provide memory limits, you may temporarily use the platform defaults from the documentation or tools, but this assumption must be explicitly marked in the results.

Information Sources

Read the current repository files before execution; do not rely on parameters from memory:

docs/thinker_packer.md
docs/thinker_validator.md
docs/thinker_compile.md
tools/tpacker/argument_parser.py
When threshold behavior is unclear, read tools/tpacker/graph_optimizer/op_split.py
tools/tpacker/load_model.py and tools/tpacker/graph/Graph.pyto confirm subgraph boundaries and the clipping direction.
tools/tpacker/graph_analysis/combine.py and memory.pyto confirm tensor placement, DMA buffers, and total memory planning.
auto_test/arcs_test.sh、auto_test/venus_test.sh、auto_test/venusa_test.shto find verified configurations for the same platform and the same operator family. They may only be used as candidate starting points; you must not copy their tensor names or assume their memory limits equal the actual deployment limits.

If the installed commands may differ from the source code, run tpacker -h and tvalidator -h. When verifying local source code modifications, prefer the currently checked-out source code and the reinstalled pythinker。

Three Types of Splitting That Must Be Distinguished

In analysis and reporting, the following terms must be used explicitly; the three must not be collectively referred to as "subgraph splitting":

Mechanism	Parameter or artifact	Effect	Whether multiple independent resources are produced
Deployment subgraph partitioning	`--inputs`、`--outputs`	Redefine resource boundaries using graph entry/tensor names and clip the computation graph	Each `tpacker` produces one resource; multiple calls can form a resource DAG
Streaming graph rewriting	`--isstream split_h\|split_w`	Rewrite convolution padding along the H/W directions and add history/state inputs and outputs; it also handles GRU/LSTM states	No, it is still one resource for a single call
Hardware operator splitting	`threshold1~3`、`7_graph_op_split.onnx`	Split overly large Conv/Linear and other operators within one resource to satisfy kernel limits	No, it is invisible to the application

threshold4、-m、--dma_prefetch and the total memory limit belong to memory placement and planning, not deployment subgraph partitioning.7_graph_op_split.onnx The existence of --inputs/--outputs。

Deployment Subgraph Boundary Rules

--inputs and --outputs Accepts comma-separated graph entry/tensor names, not operator node names; do not add spaces.
--outputs is the root of reverse dependency pruning,--inputs is the stop boundary of the reverse traversal.
When only --outputs is specified, the original input boundary is preserved; when only --inputs is specified, the original output boundary is preserved.
Before splitting, a resource DAG must be generated from the ONNX graph connectivity, listing the ordered inputs and outputs of each resource, as well as the producer and consumer of each cross-resource tensor.
Forks and joins must be handled explicitly; the model must not be assumed to be a linear chain. For example, auto_test already has the following mature topologies:
- ARCS cat-face: part1 simultaneously produces two bypass features and the part2 input, and part3 joins the bypass features with the part2 output.
- VenusA body detect/text detect: the prefix resource produces multiple features, and subsequent resources fork for processing and then join.
- ARCS translation encoder: uses consecutive boundaries to form a linear four-segment chain.
Successful packaging of each segment individually does not mean the whole-graph split is correct. You must check that all original final outputs are reachable, that no cross-segment dependencies are missed, that the dtype/shape/scale/layout of boundary tensors are consistent, and perform end-to-end runtime verification in DAG order.
Do not split deployment subgraphs first merely to solve a single operator. Deployment splitting is suitable when the overall resource cannot satisfy memory, when the application already has scheduling boundaries, when stage reuse is needed, or when there are clear fork/join interfaces; single-operator problems should first adjust threshold1~3。

Streaming graph modification rules

Use only when the model semantics allow chunking along the spatial axis and the application can maintain the newly added history/state.
split_h and split_w are streaming directions, not "generate multiple bins by height/width".
After modifying the graph, recheck the resource public I/O; newly added history/state must be included in fixed inputs, runtime tests, and deployment interfaces.
Mature usages in auto_test include VenusA TRUNet's split_h, and the split_wconfigured for VenusA decoder/encoder. These only prove that the corresponding models are usable and cannot be generalized as a universal memory-fix switch.

Safety and reproducibility

Keep the input ONNX; do not modify it in place.
Execute from the Thinker repository root, because both tools use the relative paths workspace/、data/、data.ignore/ and build/。
The result directory must be located outside workspace/<model> , because tvalidator will delete and rebuild that workspace.
Record the complete command, exit code, effective parameters, resource sizes, and split metrics for each attempt.
Modify only one class of parameters at a time, and save the current best successful resource before trying a new candidate.
It is forbidden to raise --ramsize or --psramsize above the real hardware limits. The threshold is not the total capacity, but platform hard limits or final memory planning verification must not be skipped just to reduce splits.
It is forbidden to use --inputs、--outputs or --isstreamsolely to reduce the number of splits. These parameters change the deployment computation graph or execution mode and must have a clear functional requirement.
After parameter optimization, it is forbidden to omit tvalidator -r. Omitting -r will cause tvalidator to repackage using default parameters, making it impossible to verify the optimized candidate resource.
Prefer fixed inputs. If tvalidator automatically generates inputs, save workspace/<model>/*_linger.npy, and use -i Only after re-running with fixed inputs can the issue be considered reproducible.
Do not rely solely on the shell exit code to determine tpacker success. Also confirm that the resource file exists and is non-empty, and check that the logs contain no Error occurred。

Execution flow

1. Pre-checks

Obtain the absolute paths of the repository, model, results directory, optional inputs, and simulation library.
Check whether python、tpacker、tvalidator、cmake and all input files exist.
Record concise environment information:
- python --version
- python -c 'import linger; print(linger.__version__)'
- python -c 'from importlib.metadata import version; print(version("pythinker"))'
- ONNX package version
- Thinker Git commit, and whether the workspace has uncommitted changes
Use onnx.load to load the model, execute onnx.checker.check_modelwhen supported, and check:
- IR and opset versions
- Graph input names, data types, and shapes
- Symbolic dimensions
- Node count and operator type statistics
- Model metadata or node attributes identifying the target platform
Confirm that the requested platform is consistent with the computation graph. A platform mismatch is a configuration error and cannot be bypassed by tuning parameters.
A dynamic graph must provide a valid name=min:max:factor。tpacker -c and tvalidator --cfg for every required symbol must use the same configuration.

The following results directory is recommended:

<result_dir>/
├── attempts.tsv
├── commands.txt
├── best/
├── logs/
└── failure-report/       # 仅在失败时创建

2. Establish a packaging baseline

Execute baseline packaging with an explicit platform and deployment memory constraints, and enable dump:

tpacker \
  -g <model.onnx> \
  -o <result_dir>/baseline.bin \
  -d True \
  -p <platform> \
  -r <真实共享内存字节数> \
  --psramsize <真实PSRAM字节数> \
  --dma_prefetch True \
  --threshold1 <初始值> \
  --threshold2 <初始值> \
  --threshold3 <初始值> \
  --threshold4 <初始值> \
  [动态shape或子图参数]

First establish two baselines:

A full-graph baseline that does not change the deployment boundary, used to determine whether the failure comes from a single-operator limitation, total shared memory, PSRAM, DMA buffer, or full-graph lifecycle.
Only when the deployment design explicitly requires graph partitioning, then establish a segmented baseline with --inputs/--outputs .

Do not mechanically set all threshold1~4 to the shared memory size. The CLI defaults are all 655360, but they are not four synonymous total memory limits, and the shared memory platform limit for ARCS/VenusA is only 393216. Candidates should be derived from the auto_test configuration of the same platform and same operator family, tool defaults, and the real memory budget, and the final memory plan shall prevail.-m The shared memory keyword in must be written as share-mem。

Retain for each attempt:

Complete standard output and error logs.
Resource files generated on success.
Via --export_config exported valid configuration.
workspace/<model>/<model>_memory_report.txt。
workspace/<model>/model.ignore/6_graph_layout_convert.onnx。
workspace/<model>/model.ignore/7_graph_op_split.onnx。

Only after packaging succeeds and the generated resources satisfy the real memory constraints can consistency verification proceed.

3. Count operator splitting

Compare the computation graph before and after hardware splitting:

Before splitting:6_graph_layout_convert.onnx。
After splitting:7_graph_op_split.onnx。

At minimum, count:

The node count before and after splitting.
Changes in the number of operator types.
Newly added Split、iqCat and other combination nodes.
Original large operators replaced by numbered copies such as <name>_0、<name>_1 .
The number of shards for each original operator.
The total number of additional shards, i.e., the sum of all 分片数 - 1 .
The public inputs and outputs of each resource; when using deployment subgraphs, additionally output the resource DAG and the total bytes of cross-resource tensors.

Be conservative when normalizing copy names, and verify inferences through computation graph connectivity and operator types. Do not rely solely on names starting with _0 or _1 At the end, the original model node is misjudged as a split copy. If precise grouping is not possible, report both the computation graph structure changes and the split count explicitly marked as "estimated".

Use the following lexicographic objective to select the best candidate:

Packing succeeds within the real memory limit.
The number of original operators that are split is minimized.
The total number of extra shards is minimized.
The node growth after splitting is minimized.
Runtime shared memory, PSRAM, and resource files are smaller.

Correctness or actual deployability must not be traded for lower splitting metrics.

4. First locate the source of memory pressure

Read <model>_memory_report.txt, and split and record at least the following items:

share-mem margin of the peak and real --ramsize .
PSRAM usage and margin of real --psramsize .
Occupancy of workspace, runtime tensor, parameters, and DMA buffer respectively.
The largest tensor and its lifetime; boundary outputs usually persist across resources for a long time, so after graph splitting you cannot look only at the peak of a single segment while ignoring simultaneous residency on the application side.
For large operators, the input, weight, and output shapes in 6_graph_layout_convert.onnx , and the actual sharding direction and count in 7_graph_op_split.onnx .

Choose the mechanism according to the symptom:

Primary pressure	Preferred action	What should not be done first
A single Conv/ConvTranspose is split too much	Adjust the corresponding `threshold1/2`, and check the platform hard lower limit	Directly use `--inputs/--outputs` to split the entire model
A single Linear is split too much	Adjust according to the actual platform implementation `threshold3`	Assume that on all platforms `threshold3` controls the output
DMA buffer causes shared memory to exceed the limit	Compare `--dma_prefetch False`, then adjust weight-related thresholds	Increase `--ramsize` beyond the hardware value
Large or long-lived intermediate tensors occupy SRAM	Lower `threshold4` or use `-m tensor:psram`	Move a large number of unknown tensors all to PSRAM at once
High-frequency hot tensors are automatically placed in PSRAM and SRAM still has margin	`-m tensor:share-mem`	Blindly increase the global `threshold4`
Each segment is feasible but the whole-graph lifetime still exceeds the limit	Design the deployment resource DAG, split, and compute cross-segment residency	Only verify that each bin can run independently

5. Parameter optimization to reduce splitting

Adjust only the parameters related to the operators actually being split:

Symptom	Preferred parameter	Direction to try
`Conv1dInt`、`Conv2dInt` or `ConvTranspose2dInt` due to weight or output channel splitting	`threshold1`、`threshold2`	Increase within the real single-operator and shared memory budget, and confirm that the platform branch actually uses this threshold
Convolution is split due to output or workspace pressure	`threshold2`	Increase cautiously, checking the full memory plan each time
`LinearInt` splitting	`threshold3`	Confirm by platform and weight dtype whether it controls the left matrix or the right matrix, then adjust within the constraints
Large runtime tensors are placed in PSRAM	`threshold4`、`-m`	Specify only when the full memory plan allows `share-mem`, otherwise selectively use `psram`
DMA buffer occupancy is relatively large	`threshold1`、`threshold3`、`--dma_prefetch`	Compare prefetch switches, and keep the setting that meets the runtime requirements and has fewer splits
Intermediate tensors cause shared memory pressure	`-m <node>:psram`	Move only large or long-lived tensors confirmed in the memory report

Optimization rules:

Before modifying parameters, first analyze 7_graph_op_split.onnx and the memory report.
Adjust only one threshold category at a time, or a small group of clearly related node storage locations.
First use bounded coarse-grained stepping, then perform a binary search between the best successful value and the most recent failed value.
After each success, re-count the splits; do not infer improvement solely from threshold changes.
If a candidate increases splits, exceeds memory limits, fails serialization, or increases data movement without improving the split objective, discard that candidate.
Stop when no legal candidate can continue to improve, when the remaining splits are forced by hardware lower bounds, or when the iteration budget is reached.

The actual source-code semantics of the thresholds are more specific than the CLI help:

threshold1: Conv weight/kernel split candidates; the effective upper limit for Venus ordinary convolution is usually capped at 32768, and increasing it further is often ineffective. ARCS ordinary convolution has a 8192 lower bound; the restriction directions for VenusA ordinary Conv and ConvTranspose are not exactly the same.
threshold2: Conv output split candidates; common Venus/VenusA paths have a 65536 lower bound, and common ARCS paths have a 32768 lower bound. Configurations below the lower bound do not necessarily produce changes.
threshold3: Platform-dependent. Venus/ARCS mainly affect the Linear right-side/weight matrix restriction, while VenusA mainly affects the left-side/input matrix restriction; different weight dtypes also have fixed hard limits.
threshold4: Automatic placement threshold for a single tensor. When the payload is larger than it, the default is PSRAM; otherwise, the default is shared memory; explicit -m takes priority. It is not the total shared memory capacity.
The documentation describes the threshold as bytes, but several implementations of threshold1~3 calculate by the number of aligned elements; for int8 the value is equivalent to bytes, but for other dtypes it should not be directly inferred as bytes.threshold4 actually compares by payload bytes.

When source-code branches are uncertain, threshold adjustments have no effect, or behavior does not match the documentation, you must read the current version of op_split.py, and must not rely on generic tables. Pay special attention that constraints such as platform hard limits and maximum split counts cannot be bypassed by increasing thresholds.

The representative candidates used by CI/runtime in the current auto_test are as follows. Use them as first-round search seeds only when the platform, operator family, dtype, and shape are close:

Platform and model characteristics	Representative configuration	Reflected strategy
Venus ordinary CV Conv	`threshold1=32768`	Corresponds to the common kernel upper limit for Venus ordinary convolution; increasing it further usually yields no benefit
Venus OCR/Linear	`threshold3=110016` or `123840`，`threshold4=100000`	restrict Linear splitting and automatically place larger tensors into PSRAM
Venus dynamic encoder	`threshold3=32768~81920`，`threshold4=163800~204000`	Control Linear and tensor placement segment by segment under the maximum dynamic shape
ARCS translation encoder	`threshold3=131072` or `180224`, specify several intermediate tensors to PSRAM, and disable DMA prefetch	Joint tuning of Linear and long-lived tensors for segmented transformer blocks
ARCS translation decoder	`threshold3=384000`, disable DMA prefetch	Large Linear candidates close to but below the total ARCS SRAM, still subject to the memory plan
ARCS cat-face Conv subgraph	`threshold1=32768`、`threshold2=65536`、`threshold4=65536` or `102000`	balance Conv sharding, tensor placement, and DMA buffer separately for different resources
VenusA body detect	`threshold1=65536~131072`、`threshold2=65536`、`threshold4=61440~92160`	tune Conv weights, output blocks, and PSRAM placement resource by resource
VenusA text detect/OCR	`threshold2/3=65536`、`threshold4=32768~204700`, with some tensors explicitly assigned to PSRAM or shared memory	`threshold4` varies widely, proving that it must be adjusted according to the resource lifecycle
VenusA streaming decoder/encoder	`32768/65536/16384/65536`，SRAM `393216`、PSRAM `8388608`	`split_w` uses a more conservative combination of Conv/Linear/tensor thresholds after graph modification

When deriving candidates from these configurations, first copy the "parameter relationships" rather than the numbers. For example, if the target is found to be a VenusA Conv subgraph, first try a smaller threshold4、threshold2=65536 and targeted PSRAM placement, then adjust based on the actual split graph and memory report; do not directly apply threshold1=131072 just because another model uses it.

The platform kernel has alignment, input size, weight block, split count, and workspace constraints that cannot be bypassed. Infinitely raising thresholds cannot break through hardware constraints. Such splits should be recorded as unavoidable rather than continuously tuned blindly.

Recommended search range:

Establish a baseline using the documentation or default thresholds.
For each actually relevant threshold, with other parameters fixed, test up to the upper bound allowed by the source platform branch and tolerable by the final memory plan; this upper bound is not necessarily equal to the shared memory capacity.
If the upper bound value succeeds and reduces splits, binary search downward for the minimum threshold that maintains that split metric.
When DMA memory usage is significant, test --dma_prefetch False。
Test targeted -m placement only for tensors confirmed by the memory report.
By default, keep it to 8 to 20 candidates unless the user requests exhaustive search.

6. Design deployment subgraphs

Perform this section only when the whole-graph baseline cannot satisfy the real constraints, or when the deployment itself explicitly requires multiple resources.

Choose boundaries from the ONNX topology and memory report. Prefer natural boundaries between operator blocks with low fan-out, small tensors, clear quantization and layout.
Avoid cutting between a large number of parallel features. If a cut must be made at a fork, include all bypass tensors still needed downstream in the upstream --outputs。
For each segment, explicitly list --inputs、--outputs; names must come from the graph entries after loading in the stage to be split.
Package each segment separately, and record each segment's memory plan, resource size, internal operator splits, and public I/O.
Calculate cross-resource data cost: bytes per transfer, peak of simultaneously resident boundary tensors, whether PSRAM is needed, and whether layout copy is introduced.
Use the resource DAG for end-to-end runtime verification; do not run independent random inputs on each segment only. Downstream inputs must use the upstream's real outputs.
The consistency reference for each segment should be the ONNX subgraph consistent with that segment's boundary or a fixed intermediate tensor; do not directly compare intermediate resources using the full model's final output.

auto_test patterns that can be referenced:

Platform/model family	Verified pattern	Learnable point
ARCS OCR 4-bit	Original input to intermediate tensor, then from intermediate tensor and lengths to final output	Auxiliary original inputs may need to be used again as boundary inputs in later segments
ARCS translation encoder	Four-segment linear chain, with different settings per segment for `threshold3` and PSRAM tensor	The same block may also use different thresholds due to different lifecycles in the first segment
ARCS cat-face	Three-resource fork/join DAG	The upstream must output bypass features, not just the direct input to the next segment
VenusA body detect/text detect	Multiple output prefixes, branch handling, final merge	Boundary selection and `threshold4/-m/dma_prefetch` require segment-by-segment tuning
VenusA OCR	Three-segment linear chain	The later Linear and earlier Conv can use different threshold strategies
VenusA decoder/encoder	Deployment boundary and `split_w` used simultaneously	Streaming graph modification adds history/state interfaces beyond the explicit boundaries

Do not treat the numbers in auto_test as universally optimal values for the platform. They are verified instances for specific graph, shape, dtype, and deployment boundaries.

7. Freeze the best resources

Copy the best candidate to <result_dir>/best/：

Packaged resources.
Valid tpacker JSON configuration.
Exact packaging command.
Packaging log.
Memory report.
ONNX before and after splitting.
Splitting metrics compared with the baseline.

After cleaning the packaging workspace, re-execute the best command once. Confirm the exit status, non-empty resources, valid configuration, and consistent splitting metrics. If serialization is deterministic, prefer comparing resource checksums.

8. Verify Linger and Thinker consistency

Using the original quantized ONNX and the best resources:

tvalidator \
  -g <model.onnx> \
  -r <result_dir>/best/<model.bin> \
  -l <同平台且开启dump的libthinker.so> \
  [-i <input_0.npy> <input_1.npy> ...] \
  [--cfg <与打包相同的动态shape配置>] \
  --param_check ON \
  --runtime_check ON

If no usable dynamic library is available, only allow tvalidator to build automatically from the Thinker repository root. You must confirm that the build platform matches the ONNX, and enable result dumping. Prefer explicitly passing -l, to avoid silent rebuilds or selecting the wrong library.

Consistency passing must simultaneously satisfy:

Linger reference inference succeeds.
Thinker loads and runs exactly the best resources.
There are dumps that can be paired for comparison.
tvalidator explicitly outputs Consistency verification passed。

Do not judge consistency passing based only on the process exit code, because some comparison failures may only print logs without returning a non-zero status.

If the first round uses random inputs:

Immediately save workspace/<model>/*_linger.npy。
Pass these files in ONNX input order via -i and rerun.
Use the retest results with fixed inputs as the final conclusion.

For dynamic models, when time and resources permit, verify at least one legal shape near the minimum, one typical value, and one near the maximum, and retain all fixed inputs used for failures.

Multi-resource models must also add an end-to-end verification: run in resource DAG order, directly use the upstream Thinker output as the downstream input, and compare the final result with the complete Linger model. Segmented tvalidator all pass but end-to-end fails, first check boundary tensor order, dtype, scale, layout, shape, and bypass dependencies.

9. Troubleshooting

Classify by the earliest failing stage:

前置检查: dependencies, ONNX validity, unsupported platform/operator, or dynamic configuration format errors.
打包: computation graph optimization, hardware adaptation, memory planning, serialization, or resource write failures.
构建/加载: simulation library build, loading, or platform mismatch.
运行时: model initialization, memory allocation, input setting, shape update, or operator execution failures.
一致性比较: the first inconsistent tensor, or no comparable dump.

Do not let a complete log obscure the first actionable error. Save the complete log as an attachment, and cite only the shortest relevant error stack in the report.

When consistency comparison fails, record:

The first inconsistent tensor, and the corresponding producing node and operator type in the original ONNX.
The tensor shape, data type, and available quantization attributes or scale.
tvalidator The first batch of inconsistent indices in the output and the values on both sides.
The paths of the two corresponding dump files.
Whether the earlier comparable tensor is consistent.

By default, do not collect all dumps. Usually only the fixed model input and the first inconsistent tensor pair are needed; only when it is necessary to prove where the difference begins should the immediately preceding consistent tensor pair be added.

Minimal reproduction report

Only create <result_dir>/failure-report/report.mdwhen packaging or consistency verification cannot be completed successfully. The report should be self-contained but as concise as possible:

# Thinker 打包/一致性验证故障

## 摘要
- 失败阶段：<前置检查|打包|构建/加载|运行时|一致性比较>
- 现象：<一句话>
- 首个可处理错误或不一致：<一句话>

## 环境
- 操作系统/架构：<值>
- Python：<值>
- linger：<值>
- pythinker：<值>
- onnx：<值>
- Thinker 提交：<值及工作区状态>
- 目标平台：<值>

## 输入
- ONNX：<报告内相对路径和校验和>
- 固定输入：<有序路径和校验和，或尚未进入该阶段>
- 动态配置：<精确值或无>

## 复现步骤
```bash
<涉及打包时的最小打包命令>
<涉及验证时的最小验证命令>
```

## 有效打包配置
- ramsize / psramsize：<字节数>
- dma_prefetch：<值>
- threshold1~4：<值>
- 节点存储位置：<值或无>
- 拆分指标：<值>

## 实际结果
<简短错误块，或首个不一致张量、shape、索引和数值>

## 预期结果
<在限制内打包成功，或一致性验证通过>

## 附件
<最小文件列表及用途>

Attach only the necessary files according to the failure stage:

Failure stage	Minimal attachments
Pre-check	Shareable ONNX, check error logs, environment information
Packaging	ONNX, valid tpacker configuration, exact commands, packaging logs
Build/load	Packaged resources, exact build/verification commands, platform and build logs; add ONNX when resources need to be rebuilt
Runtime	ONNX, resources, fixed and ordered inputs, exact verification commands, runtime logs
Consistency comparison	ONNX, resources, fixed and ordered inputs, exact verification commands, the first inconsistent Linger/Thinker dump pair, comparison log excerpts

Unless it has been proven necessary, do not attach:

The entire workspace directory.
All intermediate ONNX files.
All tensor dumps.
Build directories or compiled object files.
Absolute paths, usernames, tokens, irrelevant private files, or machine caches.

If the model or weights cannot be shared, do not claim that the report can be reproduced independently. Clearly state the limitations, and provide the model checksum, computation graph/operator summary, failing node metadata, and exact commands as a diagnostic report.

Final reply

On success, report:

The best resource and configuration paths.
The target platform and the memory limit actually used.
Baseline and final split metrics.
The parameters modified and the reasons.
A summary of resource size and memory planning.
The exact verification commands and fixed inputs.
Consistency results and the dynamic shape points that have been tested.
The remaining unavoidable splits and known hardware reasons.

On failure, first state the failure stage and the first actionable error, then give the report directory and the minimal attachments in it. Clearly distinguish verified facts from assumptions.