Merge pull request #3210 from madeline-underwood/v9

V9 retail

Author: jasonrandrews

content/learning-paths/cross-platform/multimodel_mnn_v9/1_mnn_v9.md

@@ -4,26 +4,26 @@ layout: learningpathall
 weight: 2
 ---
 
-## Introduction
+## Understand MNN and multimodal inference on Armv9
 
-This section introduces the software stack used throughout this Learning Path. You will use **[MNN](https://github.com/alibaba/MNN)** to run a prebuilt **Omni multimodal model** on an Armv9 Linux system using only the CPU.
+This section introduces the software stack used throughout this Learning Path. You will use **[MNN](https://github.com/alibaba/MNN)** (Mobile Neural Network), a lightweight inference engine, to run a prebuilt **Omni multimodal model** on an Armv9 Linux system using only the CPU.
 
-By the end of this section, you will understand why this combination is a practical starting point for reproducible multimodal inference on Armv9. A retail restocking workflow that combines local image and audio inputs is used as the example throughout.
+By the end of this section, you'll understand why this combination is a practical starting point for reproducible multimodal inference on Armv9. A retail restocking workflow that combines local image and audio inputs is used as the example throughout.
 
 ## Why use MNN on Armv9
 
-MNN is a lightweight inference engine designed for deployment across mobile, embedded, and edge platforms. It is a good fit for this Learning Path for four reasons:
+MNN is a lightweight inference engine designed for deployment across mobile, embedded, and edge platforms. It's a good fit for this Learning Path for four reasons:
 
-- It provides a **portable runtime** that can be built and reused across different device classes.
-- It supports a **CPU-first deployment flow**, which is useful when you want to validate multimodal inference on Armv9 without depending on a discrete GPU or dedicated accelerator.
-- Native builds can take advantage of **Armv9-specific CPU features and optimizations** when they are enabled in the build, making this a practical path for efficient local inference.
-- The same runtime approach can be reused across **Arm Linux, Android, iOS, and x86-based development hosts**, which improves portability from development to deployment.
+- Provides a **portable runtime** that can be built and reused across different device classes
+- Supports a **CPU-first deployment flow**, useful when you want to validate multimodal inference on Armv9 without depending on a discrete GPU or dedicated accelerator
+- Native builds take advantage of **Armv9-specific CPU features and optimizations** when enabled in the build, making this a practical path for efficient local inference
+- The same runtime approach can be reused across **Arm Linux, Android, iOS, and x86-based development hosts**, improving portability from development to deployment
 
 For this Learning Path, MNN gives you a practical way to build a reproducible multimodal inference workflow on Armv9 while keeping the software stack compact and deployment-oriented.
 
 ## Why use an Omni multimodal model
 
-An Omni model combines **text, image, and audio** understanding in a single inference pipeline. This makes it useful for building compact edge applications that need to reason over more than one input type.
+An Omni model combines **text, image, and audio** understanding in a single inference pipeline, making it useful for building compact edge applications that need to reason over more than one input type.
 
 In this Learning Path, you use the model to:
 
@@ -49,6 +49,12 @@ To keep the workflow reproducible, this Learning Path uses a deliberately narrow
 
 This scope keeps the focus on setup, validation, and multimodal application flow.
 
-## Next steps
+## What you've learned and what's next
 
-In the next section, you will build MNN on Armv9 and prepare the model files and local assets used in the remaining examples.
+In this section, you learned:
+
+- Why MNN is a practical inference engine for multimodal workflows on Armv9
+- How an Omni model combines text, image, and audio understanding in one pipeline
+- The deliberate scope choices that keep this Learning Path reproducible and focused on CPU-first inference
+
+In the next section, you'll build MNN natively on Armv9 and prepare the model files and local assets used in the remaining examples.

content/learning-paths/cross-platform/multimodel_mnn_v9/2_mnn_build.md

@@ -4,13 +4,13 @@ weight: 3
 layout: learningpathall
 ---
 
-## Introduction
+## Build MNN for Armv9 multimodal inference
 
-In this section, you will build **MNN** natively on your Armv9 Linux system and verify that the `llm_demo` binary can load a prebuilt Omni MNN model package. This sets up everything needed for the text, vision, and audio demos in later sections.
+In this section, you'll build **MNN** natively on your Armv9 Linux system and verify that the `llm_demo` binary can load a prebuilt Omni MNN model package. This sets up everything needed for the text, vision, and audio demos in later sections.
 
-This section uses a native CPU-only MNN build on Armv9. That is a deliberate design choice, not a fallback. The goal is to show how a compact, reproducible, deployment-friendly software stack can run directly on an Armv9 CPU without depending on a discrete GPU or separate accelerator.
+This section uses a native CPU-only MNN build on Armv9 — a deliberate design choice, not a fallback. The goal is to show how a compact, reproducible, deployment-friendly software stack can run directly on an Armv9 CPU without depending on a discrete GPU or separate accelerator.
 
-At the end of this section, you will have:
+At the end of this section, you'll have:
 
 - a working `llm_demo` binary
 - a validated model directory that includes `config.json`
@@ -28,7 +28,7 @@ cd ~/mnn
 
 ## Why build natively on Armv9
 
-Building, running inference, and deploying all happen directly on the Armv9 device. There is no cross-compilation involved. This keeps the toolchain simple, eliminates environment drift between build and target, and means any library or configuration issue you encounter is the same one you would hit in production.
+Building, running inference, and deploying all happen directly on the Armv9 device. There's no cross-compilation involved. This keeps the toolchain simple, eliminates environment drift between build and target, and means any library or configuration issue you encounter is the same one you'd hit in production.
 
 Building on the target also makes it straightforward to confirm that the binary, shared libraries, and model assets all resolve correctly in the same environment where you will run the model.
 
@@ -168,9 +168,7 @@ ls -lh ~/mnn/Qwen2.5-Omni-7B-MNN/llm.mnn ~/mnn/Qwen2.5-Omni-7B-MNN/llm.mnn.weigh
 
 If either file is only a few hundred bytes, the LFS download did not complete. Run `git lfs pull` again to resume it.
 
-{{% notice Note %}}
-This package is already prepared for MNN deployment. You do not need to export the model from PyTorch or run additional quantization steps before using it in this Learning Path.
-{{% /notice %}}
+{{% notice Note %}}This package is already prepared for MNN deployment. You do not need to export the model from PyTorch or run additional quantization steps before using it in this Learning Path.{{% /notice %}}
 
 ## Check your setup
 
@@ -182,3 +180,14 @@ cd ~/mnn/MNN/build
 ```
 
 The binary starts an interactive session. Type `exit` or press Ctrl+C to quit. If the binary loads without `undefined symbol` errors or missing library messages, your environment is ready for the next section.
+
+## What you've learned and what's next
+
+In this section, you:
+
+- Built MNN natively on Armv9 with multimodal and KleidiAI support enabled
+- Verified that shared libraries resolve correctly to avoid runtime conflicts
+- Downloaded and validated the prebuilt Omni model package and weights
+- Confirmed that `llm_demo` can load the model configuration
+
+In the next section, you'll run a text-only baseline to verify that the core inference path works correctly before adding vision and audio inputs.

content/learning-paths/cross-platform/multimodel_mnn_v9/3_mnn_text_baseline.md

@@ -4,7 +4,7 @@ weight: 4
 layout: learningpathall
 ---
 
-## Introduction
+## Run text-only baseline inference with MNN Omni
 
 In this section, you run a **text-only baseline** using the Omni model on an Armv9 Linux system. Before adding image and audio inputs, this baseline helps you confirm that the core inference path is working correctly with a simple prompt and predictable output behavior.
 
@@ -24,11 +24,9 @@ You are an on-device inference assistant. In one short sentence, describe the be
 EOF
 ```
 
-{{% notice Note %}}
-`llm_demo` commonly treats each line in the file as a separate prompt. Keep each prompt on a single line.
-{{% /notice %}}
+{{% notice Note %}}`llm_demo` commonly treats each line in the file as a separate prompt. Keep each prompt on a single line.{{% /notice %}}
 
-## Run `llm_demo` with the prompt file
+## Run llm_demo with the prompt file
 
 Run `llm_demo` from the MNN build directory and pass both the model configuration and prompt file:
 
@@ -39,7 +37,7 @@ cd ~/mnn/MNN/build
 
 A successful run should load the model, report the detected CPU features, and return a text response for the prompt.
 
-Example output:
+The output is similar to:
 
 ```text
 config path is /home/radxa/mnn/Qwen2.5-Omni-7B-MNN/config.json
@@ -59,12 +57,21 @@ prompt file is /home/radxa/mnn/text_baseline_prompt.txt
 Multimodal on-device inference has several benefits, including reducing the need for cloud-based services, allowing usage in areas with poor internet connectivity, saving on data transfer costs, enabling real-time processing, and enhancing privacy during data processing. It's a great way to handle various tasks efficiently, especially when you don't want to rely too much on the cloud.
 ```
 
-
 {{% notice Note %}}
-When you run `llm_demo`, you may see a line like:
-`The device supports: i8sdot:1, fp16:1, i8mm: 1, sve2: 1, sme2: 0`
-This line reports hardware feature support on your CPU: **i8sdot**, **fp16**, **i8mm**, **sve2**, and **sme2**.  
-A value of `1` means the feature is supported in hardware, and `0` means it is not.
+When you run `llm_demo`, you may see a line reporting CPU hardware features:
+
+```
+The device supports: i8sdot:1, fp16:1, i8mm: 1, sve2: 1, sme2: 0
+```
+
+This shows the Arm architecture features are available on your CPU:
+- **i8sdot** - 8-bit integer dot product
+- **fp16** - 16-bit floating point
+- **i8mm** - 8-bit integer matrix multiplication  
+- **sve2** - Scalable Vector Extension 2
+- **sme2** - Scalable Matrix Extension 2
+
+A value of `1` means supported, `0` means not supported.
 {{% /notice %}}
 
 ## Check how prompt files are processed
@@ -106,7 +113,7 @@ Arm is a processor architecture. It's used in mobile phones, embedded systems, e
 Output length and coherence can vary significantly without a generation length limit. If a response repeats itself, this is normal model behavior without a `max_new_tokens` constraint. Focus on confirming that two distinct responses appear, one for each prompt line.
 {{% /notice %}}
 
-If you want to quickly sanity-check interactive mode:
+If you want to quickly verify interactive mode:
 
 ```bash
 cd ~/mnn/MNN/build
@@ -115,15 +122,14 @@ cd ~/mnn/MNN/build
 
 Enter a short prompt and confirm that the model returns a reply. Press Ctrl+C to quit.
 
-## Check your results
+## What you've learned and what's next
 
-You have completed this section when:
+In this section, you:
 
-- `llm_demo` loads `config.json` successfully
-- the prompt file produces one response per line
-- the model returns non-empty text output
-- the runtime completes without crashes or missing-library errors
+- Ran a text-only baseline to confirm the MNN runtime and Omni model load correctly
+- Verified that prompt files are processed line by line
+- Established a working text inference baseline on Armv9 CPU
 
-## Next steps
+You've confirmed that `llm_demo` loads `config.json` successfully, processes prompts correctly, and returns non-empty text output without crashes.
 
-In the next section, you will add an image input and validate the vision path of the Omni model on Armv9.
+In the next section, you'll add an image input and validate the vision path of the Omni model on Armv9.

content/learning-paths/cross-platform/multimodel_mnn_v9/4_mnn_vision.md

@@ -4,7 +4,7 @@ weight: 5
 layout: learningpathall
 ---
 
-## Introduction
+## Analyze retail shelf images with vision inference
 
 This section shows how Armv9 can run lightweight operational vision reasoning locally without requiring cloud round trips, making it a practical fit for store-side restocking workflows.
 
@@ -27,22 +27,22 @@ Create a local directory for assets:
 mkdir -p ~/mnn/assets
 ```
 
-Download the tutorial image and verify that it is a valid JPEG file:
+Download the tutorial image and verify that it's a valid JPEG file:
 
 ```bash
 wget -P ~/mnn/assets https://upload.wikimedia.org/wikipedia/commons/e/e6/Pet_Food_Aisle.jpg
 file ~/mnn/assets/Pet_Food_Aisle.jpg
 ```
 
-You should see output similar to:
+The output is similar to:
 
 ```text
 JPEG image data, JFIF standard 1.02, resolution (DPI), density 72x72, segment length 16, Exif Standard: [TIFF image data, little-endian, direntries=12, description=                               , manufacturer=SONY, model=DSC-W50, orientation=upper-left, xresolution=203, yresolution=211, resolutionunit=2, software=Adobe Photoshop CS Macintosh, datetime=2007:04:10 17:45:47], progressive, precision 8, 2816x2112, components 3
 ```
 
 The key detail is that the output starts with `JPEG image data`, confirming the file is a valid JPEG. The remaining EXIF metadata can be ignored.
 
-![Pet food aisle shelf with multiple levels stocked with pet food products, used as the vision prompt input for the shelf audit#center](pet_food_aisle.jpg "Pet food aisle shelf used for the vision audit prompt")
+![Pet food aisle shelf with multiple levels stocked with pet food products, showing top, middle, and bottom shelf zones that will be analyzed by the vision model#center](pet_food_aisle.jpg "Pet food shelf for vision audit")
 
 ## Create the vision prompt
 
@@ -76,7 +76,7 @@ cd ~/mnn/MNN/build
 ./llm_demo ~/mnn/Qwen2.5-Omni-7B-MNN/config.json ~/mnn/prompt_picture_coverage.txt
 ```
 
-You should see output similar to:
+The output is similar to:
 
 ```text
 config path is /home/radxa/mnn/Qwen2.5-Omni-7B-MNN/config.json
@@ -98,23 +98,29 @@ The exact wording can vary, but the structured fields should be present. If the
 
 ## Why a coarse coverage estimate is enough for edge workflows
 
-In many edge retail workflows, you do not need a perfectly precise inventory measurement to make a useful decision. A coarse estimate such as `High`, `Medium`, or `Low` coverage is often enough to identify which shelf area needs attention first and to generate a practical restocking signal.
+In many edge retail workflows, you don't need a perfectly precise inventory measurement to make a useful decision. A coarse estimate such as `High`, `Medium`, or `Low` coverage is often enough to identify which shelf area needs attention first and to generate a practical restocking signal.
 
-This keeps the prompt and output simple, reduces post-processing requirements, and makes the result easier to validate during early on-device prototyping. For this Learning Path, the goal is not to build a full inventory counting system, but to show how local vision reasoning on Armv9 can produce an operationally useful input for a restocking workflow.
+Keeping the prompt and output simple reduces post-processing requirements and makes the result easier to validate during early on-device prototyping. For this Learning Path, the goal isn't to build a full inventory counting system, but to show how local vision reasoning on Armv9 can produce an operationally useful input for a restocking workflow.
 
 ## Verify the result
 
 Check that the output meets these conditions:
 
-- it includes coverage estimates for **top**, **middle**, and **bottom**
-- it identifies one **priority zone**, such as `middle-center`
-- it provides a short reason tied to visible shelf sparsity
-- it uses `NOT_SURE` only when the image is genuinely ambiguous
+- includes coverage estimates for **top**, **middle**, and **bottom**
+- identifies one **priority zone**, such as `middle-center`
+- provides a short reason tied to visible shelf sparsity
+- uses `NOT_SURE` only when the image is genuinely ambiguous
 
 If the model returns extra conversational text, tighten the prompt further by repeating `Output ONE line only`.
 
-## Next steps
+## What you've learned and what's next
 
-You have now validated image-based multimodal inference with MNN Omni on Armv9.
+In this section, you:
 
-In the next section, you extend this workflow by running an audio-based restock instruction demo using an `<audio>...</audio>` prompt.
+- Ran vision-based inference using a shelf image as input
+- Generated a structured shelf audit with coverage estimates and priority zones
+- Validated that MNN Omni can process local images on Armv9 CPU for operational retail workflows
+
+You've confirmed that image-based multimodal inference works correctly and produces actionable output.
+
+In the next section, you'll extend this workflow by running an audio-based restock instruction demo using an `<audio>...</audio>` prompt.