[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BY52X9KX3VRXQJS622DZH3":3,"skill-same:01M6BY52X9KX3VRXQJS622DZH3":58},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":41,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":43,"install":44,"resources":57},"01M6BY52X9KX3VRXQJS622DZH3","compiled-model-app-scaffolding",null,"Build a new Android app (Kotlin, Compose) around a verified LiteRT model using the CompiledModel API - the app architecture, the inference-layer lifecycle rules, model delivery, and the UI traps that masquerade as model bugs. Use when turning a converted and device-verified model into a demo or product app, when an app's inference layer leaks memory or blocks the UI, or when a model that verified clean looks wrong inside an app.","google-ai-edge\u002Flitert-samples","google-ai-edge","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F150697620?v=4","01M6BY4NHMZF88PJAC1E1QJY8N","01M6BY4NNXP8PC95Y6CABCJXP9",492,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Fcompiled-model-app-scaffolding\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30],"model","compiled model app scaffolding","android","inference","memory","litert","architecture","product","ui","demo","lifecycle","api","kotlin","2026-11-10 10:12:30",false,"---\nname: compiled-model-app-scaffolding\ndescription: Build a new Android app (Kotlin, Compose) around a verified LiteRT model using the CompiledModel API - the app architecture, the inference-layer lifecycle rules, model delivery, and the UI traps that masquerade as model bugs. Use when turning a converted and device-verified model into a demo or product app, when an app's inference layer leaks memory or blocks the UI, or when a model that verified clean looks wrong inside an app.\n---\n\n# CompiledModel app scaffolding\n\nAn app around a verified model is done when three things hold, in this order:\n\n1. the app reproduces the model recipe's verification numbers on the\n   accelerator the recipe verified — **before any UI exists**,\n2. inference is confined and leak-free: one dispatcher owns the model,\n   every buffer is closed, benchmarks include the readback,\n3. the inference code is liftable — another app could take the helper\n   file unchanged.\n\nScope: this scaffolds a **new** app from a model recipe. Migrating an\nexisting TFLite Interpreter app to CompiledModel is a different task with\nits own skill, `litert-compiled-model-migration`. LLMs are served through\nthe LiteRT-LM Engine rather than raw CompiledModel —\n`samples\u002Flitert\u002Ftext_to_speech_lm` is the reference for that case;\neverything below is the non-LLM CompiledModel app.\n\n## Step 0: prove parity before building UI\n\nThe first milestone has no UI: a bare harness that loads the `.tflite`,\nruns the recipe's verification input on the target accelerator, and\nreproduces the numbers recorded in the recipe README (correlation,\nresidency). If they do not reproduce, stop — that is an\n`on-device-verification` problem, and no amount of app code fixes it.\nOnly then build the ViewModel and the screen.\n\n## The shape\n\nOne sample = one standalone Gradle project, four layers:\n\n```\napp\u002Fsrc\u002Fmain\u002Fjava\u002F\u003Cpkg>\u002F\n  \u003CTask>Helper.kt        inference infra: owns the CompiledModel and its\n                         buffers; pre\u002Fpost-processing; NO Android UI types\n  MainViewModel.kt       state machine: drives the helper on a confined\n                         dispatcher, exposes UiState\n  UiState.kt             one immutable data class\n  MainActivity.kt        ComponentActivity + setContent, nothing else\n  view\u002F                  Screen.kt, Theme.kt, Color.kt — Compose only\napp\u002Fsrc\u002Fmain\u002Fres\u002Fvalues\u002F strings.xml etc. — no UI strings in Kotlin\n```\n\nThe worked example of the full shape is\n`samples\u002Flitert\u002Fimage_segmentation\u002Fkotlin_cpu_gpu\u002Fandroid` (litert 2.3.0: the\nGPU accelerator ships in `litert-gpu`, so declare `litert:2.3.0` and\n`litert-gpu:2.3.0`; without the second the runtime logs `GPU accelerator could\nnot be loaded and registered` and a GPU + CPU set runs on the CPU — Galaxy\nS26. The sample keeps Kotlin 2.2.21 with `-Xskip-metadata-version-check`;\nthe 2.3.0 classes carry Kotlin 2.4 metadata). The layer\nboundary that matters most is the helper's: pre\u002Fpost-processing is part of\nthe model contract (it must match what the recipe exported against), so it\nlives with the model, not in the screen. Reusable inference code is worth\nmore than UI polish — a reader will lift `\u003CTask>Helper.kt` and delete the\nrest.\n\n## Inference-layer rules\n\n1. **One serial dispatcher owns the model.**\n   `Dispatchers.IO.limitedParallelism(1, \"ModelDispatcher\")` in the helper\n   (the named form needs kotlinx-coroutines 1.9+; `litert-api` 2.3.0 pulls in\n   1.8.0); create, run, and close the model only inside\n   `withContext(modelDispatcher)` — it serializes calls without pinning a\n   thread. Not a bare executor in the Activity, and never the main thread.\n2. **Buffers are created once, reused every frame, and closed.**\n   `TensorBuffer` is `AutoCloseable`; forgetting the buffers leaks native\n   memory even when the model itself is closed. Close in `onCleared()` on\n   the dispatcher of rule 1 (`viewModelScope` is already cancelled there, so\n   a `launch` never runs). The vendored `CompiledModelRunner` (below) gets\n   the buffer lifecycle right.\n3. **`run()` enqueues; the readback waits.** `run()` may return before\n   the GPU finishes — the output read is the synchronization point.\n   Benchmark run + readback together, never `run()` alone.\n4. **Warm up once at init.** The first GPU inference includes shader\n   compilation. Run one inference on dummy input right after create, so\n   the first user action is not the compile, and no first-run number\n   ever gets quoted as latency.\n5. **Ask for the strict accelerator the recipe verified.**\n   `Accelerator.GPU` alone makes `create` throw when the GPU cannot take\n   the graph (Kotlin `LiteRtException` `Failed to compile model`, Galaxy S26,\n   litert 2.2.0 and 2.3.0). Surface it as a visible error and route it back\n   to the model recipe; do not paper over it with a CPU fallback that makes a\n   slow app look like a working one. The exception: a node the delegate\n   declines while building (`TopK requires src tensor C dimension to be\n   divisible by 4`, 2.2.0 and 2.3.0 wheels on a Mac) runs on the CPU with only\n   a log line — also read the runtime's `operations will run on the GPU` line.\n6. **Stateful and multi-graph models: move references, not data.** Feed\n   step N's output buffers as step N+1's inputs (buffer ping-pong)\n   instead of copying state through the host. When one app creates many\n   `CompiledModel`s (pipelines, chunked models), create one `Environment`\n   and pass it to every `CompiledModel.create` call, and close per-run\n   buffers. An `Environment` created and closed per model reloads the GPU\n   accelerator library each time (one reload aborted the process, once in 50\n   loads, Galaxy S26, litert 2.2.0). Treat the GPU program-cache option\n   (`GpuOptions` key `SERIALIZE_PROGRAM_CACHE`) as untested per device, and\n   note that the compiler-cache environment option targets NPU JIT, not GPU\n   shader caching.\n\n## Vendor the helpers, don't rewrite them\n\n`utilities\u002Fcommon\u002Fkotlin\u002F` holds the canonical copies of the code every\napp needs and every app gets subtly wrong when written from scratch:\n\n| File | What it provides |\n|---|---|\n| `CompiledModelRunner.kt` | the buffer lifecycle of rules 2–3 (its factories take no `Environment`; create the model yourself when rule 6 applies) |\n| `ImageTensor.kt` | Bitmap → float tensor; mean\u002Fstd, NCHW\u002FNHWC, RGB\u002FBGR, letterbox with coordinate mapping back |\n| `AudioCapture.kt` | 16 kHz mono `AudioRecord` loop delivering float chunks |\n| `RealtimeCameraPipeline.kt` | CameraX capture → pooled Bitmap incl. rotation |\n| `MathOps.kt` | softmax, argmax, IoU, NMS |\n\nVendor a copy with `utilities\u002Ftools\u002Fsync_common.py --apply` (it writes the\nprovenance line), keep model-specific values in constructor arguments, and\nfix bugs in the canonical first — `--check` is the drift gate (exit 1 on a\ndiverged copy). The\npreprocessing arguments **are** the model contract: a wrong mean\u002Fstd or\nRGB\u002FBGR looks exactly like a broken model, and it is the first thing to\ndiff against the recipe's export script when app output is subtly wrong.\n\n## Model delivery\n\nWeights are never committed.\n\n- **Bundleable models**: fetch at build with a `download_model.gradle`\n  (Hugging Face URL → `assets\u002F`), and set `androidResources { noCompress +=\n  \"tflite\" }` (Kotlin DSL) so the asset stays mmappable. Worked example:\n  `samples\u002Flitert\u002Fimage_segmentation\u002Fkotlin_cpu_gpu\u002Fandroid`.\n- **Models too big to bundle**: stage into the app's private `filesDir`\n  with an `install_to_device.sh` (`adb push` to `\u002Fdata\u002Flocal\u002Ftmp`, then\n  `run-as \u003Cpkg> cp`, debug builds only), and load with the from-file path. Worked example:\n  `samples\u002Flitert\u002Ftext_to_speech\u002Fkotlin_cpu_gpu\u002Fandroid`.\n\nLink the model recipe (`models\u002F\u003Cfamily>\u002F\u003Cmodel>\u002F`) from the app README;\nconversion and verification scripts belong to the recipe, not the app.\n\n## UI traps that masquerade as model bugs\n\n- **The tiny-output trap.** `Image(contentScale = Fit)` with\n  `fillMaxWidth()` inside a `verticalScroll` renders the bitmap at native\n  pixel size: with no height constraint the row is exactly as tall as the\n  bitmap and Fit never upscales, so a 256-px model output looks broken on\n  a 1080-px screen. Drop the scroll and give each image `weight(1f)` in\n  the Column.\n- **Audio I\u002FO belongs to the ViewModel.** Mic capture and `AudioTrack`\n  playback run on their own serial dispatcher in the ViewModel, not the\n  model's (a blocking `AudioRecord.read` loop would hold inference); the screen\n  only requests permission (`rememberLauncherForActivityResult`) and\n  renders state. For file input use `OpenDocument` with audio MIME types\n  — the photo picker cannot see audio.\n- **A \"slow model\" is often the UI thread.** If the app stutters, check\n  that every helper call site goes through the ViewModel's dispatcher\n  before profiling the model — a verified model that benchmarked fine in\n  step 0 did not get slower by being in an app.\n\n## Output layout\n\n```\nsamples\u002Flitert\u002F\u003Ctask>\u002Fkotlin_cpu_gpu\u002Fandroid\u002F\n  app\u002Fsrc\u002Fmain\u002Fjava\u002F...   the four layers above\n  app\u002Fdownload_model.gradle   or install_to_device.sh at the app root\n  README.md               what it demos, which model recipe it consumes,\n                          device + accelerator it was verified on\n```\n\nState the device the app was verified on, the same way the model recipe\ndoes. An app README that names no device inherits none of the recipe's\nverification.\n","# CompiledModel app scaffolding\n\nAn app around a verified model is done when three things hold, in this order:\n\n1. the app reproduces the model recipe's verification numbers on the\n   accelerator the recipe verified — **before any UI exists**,\n2. inference is confined and leak-free: one dispatcher owns the model,\n   every buffer is closed, benchmarks include the readback,\n3. the inference code is liftable — another app could take the helper\n   file unchanged.\n\nScope: this scaffolds a **new** app from a model recipe. Migrating an\nexisting TFLite Interpreter app to CompiledModel is a different task with\nits own skill, `litert-compiled-model-migration`. LLMs are served through\nthe LiteRT-LM Engine rather than raw CompiledModel —\n`samples\u002Flitert\u002Ftext_to_speech_lm` is the reference for that case;\neverything below is the non-LLM CompiledModel app.\n\n## Step 0: prove parity before building UI\n\nThe first milestone has no UI: a bare harness that loads the `.tflite`,\nruns the recipe's verification input on the target accelerator, and\nreproduces the numbers recorded in the recipe README (correlation,\nresidency). If they do not reproduce, stop — that is an\n`on-device-verification` problem, and no amount of app code fixes it.\nOnly then build the ViewModel and the screen.\n\n## The shape\n\nOne sample = one standalone Gradle project, four layers:\n\n```\napp\u002Fsrc\u002Fmain\u002Fjava\u002F\u003Cpkg>\u002F\n  \u003CTask>Helper.kt        inference infra: owns the CompiledModel and its\n                         buffers; pre\u002Fpost-processing; NO Android UI types\n  MainViewModel.kt       state machine: drives the helper on a confined\n                         dispatcher, exposes UiState\n  UiState.kt             one immutable data class\n  MainActivity.kt        ComponentActivity + setContent, nothing else\n  view\u002F                  Screen.kt, Theme.kt, Color.kt — Compose only\napp\u002Fsrc\u002Fmain\u002Fres\u002Fvalues\u002F strings.xml etc. — no UI strings in Kotlin\n```\n\nThe worked example of the full shape is\n`samples\u002Flitert\u002Fimage_segmentation\u002Fkotlin_cpu_gpu\u002Fandroid` (litert 2.3.0: the\nGPU accelerator ships in `litert-gpu`, so declare `litert:2.3.0` and\n`litert-gpu:2.3.0`; without the second the runtime logs `GPU accelerator could\nnot be loaded and registered` and a GPU + CPU set runs on the CPU — Galaxy\nS26. The sample keeps Kotlin 2.2.21 with `-Xskip-metadata-version-check`;\nthe 2.3.0 classes carry Kotlin 2.4 metadata). The layer\nboundary that matters most is the helper's: pre\u002Fpost-processing is part of\nthe model contract (it must match what the recipe exported against), so it\nlives with the model, not in the screen. Reusable inference code is worth\nmore than UI polish — a reader will lift `\u003CTask>Helper.kt` and delete the\nrest.\n\n## Inference-layer rules\n\n1. **One serial dispatcher owns the model.**\n   `Dispatchers.IO.limitedParallelism(1, \"ModelDispatcher\")` in the helper\n   (the named form needs kotlinx-coroutines 1.9+; `litert-api` 2.3.0 pulls in\n   1.8.0); create, run, and close the model only inside\n   `withContext(modelDispatcher)` — it serializes calls without pinning a\n   thread. Not a bare executor in the Activity, and never the main thread.\n2. **Buffers are created once, reused every frame, and closed.**\n   `TensorBuffer` is `AutoCloseable`; forgetting the buffers leaks native\n   memory even when the model itself is closed. Close in `onCleared()` on\n   the dispatcher of rule 1 (`viewModelScope` is already cancelled there, so\n   a `launch` never runs). The vendored `CompiledModelRunner` (below) gets\n   the buffer lifecycle right.\n3. **`run()` enqueues; the readback waits.** `run()` may return before\n   the GPU finishes — the output read is the synchronization point.\n   Benchmark run + readback together, never `run()` alone.\n4. **Warm up once at init.** The first GPU inference includes shader\n   compilation. Run one inference on dummy input right after create, so\n   the first user action is not the compile, and no first-run number\n   ever gets quoted as latency.\n5. **Ask for the strict accelerator the recipe verified.**\n   `Accelerator.GPU` alone makes `create` throw when the GPU cannot take\n   the graph (Kotlin `LiteRtException` `Failed to compile model`, Galaxy S26,\n   litert 2.2.0 and 2.3.0). Surface it as a visible error and route it back\n   to the model recipe; do not paper over it with a CPU fallback that makes a\n   slow app look like a working one. The exception: a node the delegate\n   declines while building (`TopK requires src tensor C dimension to be\n   divisible by 4`, 2.2.0 and 2.3.0 wheels on a Mac) runs on the CPU with only\n   a log line — also read the runtime's `operations will run on the GPU` line.\n6. **Stateful and multi-graph models: move references, not data.** Feed\n   step N's output buffers as step N+1's inputs (buffer ping-pong)\n   instead of copying state through the host. When one app creates many\n   `CompiledModel`s (pipelines, chunked models), create one `Environment`\n   and pass it to every `CompiledModel.create` call, and close per-run\n   buffers. An `Environment` created and closed per model reloads the GPU\n   accelerator library each time (one reload aborted the process, once in 50\n   loads, Galaxy S26, litert 2.2.0). Treat the GPU program-cache option\n   (`GpuOptions` key `SERIALIZE_PROGRAM_CACHE`) as untested per device, and\n   note that the compiler-cache environment option targets NPU JIT, not GPU\n   shader caching.\n\n## Vendor the helpers, don't rewrite them\n\n`utilities\u002Fcommon\u002Fkotlin\u002F` holds the canonical copies of the code every\napp needs and every app gets subtly wrong when written from scratch:\n\n| File | What it provides |\n|---|---|\n| `CompiledModelRunner.kt` | the buffer lifecycle of rules 2–3 (its factories take no `Environment`; create the model yourself when rule 6 applies) |\n| `ImageTensor.kt` | Bitmap → float tensor; mean\u002Fstd, NCHW\u002FNHWC, RGB\u002FBGR, letterbox with coordinate mapping back |\n| `AudioCapture.kt` | 16 kHz mono `AudioRecord` loop delivering float chunks |\n| `RealtimeCameraPipeline.kt` | CameraX capture → pooled Bitmap incl. rotation |\n| `MathOps.kt` | softmax, argmax, IoU, NMS |\n\nVendor a copy with `utilities\u002Ftools\u002Fsync_common.py --apply` (it writes the\nprovenance line), keep model-specific values in constructor arguments, and\nfix bugs in the canonical first — `--check` is the drift gate (exit 1 on a\ndiverged copy). The\npreprocessing arguments **are** the model contract: a wrong mean\u002Fstd or\nRGB\u002FBGR looks exactly like a broken model, and it is the first thing to\ndiff against the recipe's export script when app output is subtly wrong.\n\n## Model delivery\n\nWeights are never committed.\n\n- **Bundleable models**: fetch at build with a `download_model.gradle`\n  (Hugging Face URL → `assets\u002F`), and set `androidResources { noCompress +=\n  \"tflite\" }` (Kotlin DSL) so the asset stays mmappable. Worked example:\n  `samples\u002Flitert\u002Fimage_segmentation\u002Fkotlin_cpu_gpu\u002Fandroid`.\n- **Models too big to bundle**: stage into the app's private `filesDir`\n  with an `install_to_device.sh` (`adb push` to `\u002Fdata\u002Flocal\u002Ftmp`, then\n  `run-as \u003Cpkg> cp`, debug builds only), and load with the from-file path. Worked example:\n  `samples\u002Flitert\u002Ftext_to_speech\u002Fkotlin_cpu_gpu\u002Fandroid`.\n\nLink the model recipe (`models\u002F\u003Cfamily>\u002F\u003Cmodel>\u002F`) from the app README;\nconversion and verification scripts belong to the recipe, not the app.\n\n## UI traps that masquerade as model bugs\n\n- **The tiny-output trap.** `Image(contentScale = Fit)` with\n  `fillMaxWidth()` inside a `verticalScroll` renders the bitmap at native\n  pixel size: with no height constraint the row is exactly as tall as the\n  bitmap and Fit never upscales, so a 256-px model output looks broken on\n  a 1080-px screen. Drop the scroll and give each image `weight(1f)` in\n  the Column.\n- **Audio I\u002FO belongs to the ViewModel.** Mic capture and `AudioTrack`\n  playback run on their own serial dispatcher in the ViewModel, not the\n  model's (a blocking `AudioRecord.read` loop would hold inference); the screen\n  only requests permission (`rememberLauncherForActivityResult`) and\n  renders state. For file input use `OpenDocument` with audio MIME types\n  — the photo picker cannot see audio.\n- **A \"slow model\" is often the UI thread.** If the app stutters, check\n  that every helper call site goes through the ViewModel's dispatcher\n  before profiling the model — a verified model that benchmarked fine in\n  step 0 did not get slower by being in an app.\n\n## Output layout\n\n```\nsamples\u002Flitert\u002F\u003Ctask>\u002Fkotlin_cpu_gpu\u002Fandroid\u002F\n  app\u002Fsrc\u002Fmain\u002Fjava\u002F...   the four layers above\n  app\u002Fdownload_model.gradle   or install_to_device.sh at the app root\n  README.md               what it demos, which model recipe it consumes,\n                          device + accelerator it was verified on\n```\n\nState the device the app was verified on, the same way the model recipe\ndoes. An app README that names no device inherits none of the recipe's\nverification.\n",{"name":5,"description":7},"main","9467001474dc4e072ebc588e5eb9b5fdcf63abbc","skills\u002Fcompiled-model-app-scaffolding",134,"https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples","https:\u002F\u002Fdevelopers.google.com\u002Fedge\u002Flitert","https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge","2026-11-11 08:30:40",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add google-ai-edge\u002Flitert-samples --skill compiled-model-app-scaffolding",{"tool":50,"command":51},"bunx","bunx skills add google-ai-edge\u002Flitert-samples --skill compiled-model-app-scaffolding",{"tool":53,"command":54},"pnpm","pnpm dlx skills add google-ai-edge\u002Flitert-samples --skill compiled-model-app-scaffolding","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Fcompiled-model-app-scaffolding\u002FSKILL.md",true,[],[59,73,93,122,139,158],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":31},"01M6BY5T6RQENC1DMWZ8NZ8JFF","on-device-verification","Prove a converted or quantized LiteRT model on the actual device via the CompiledModel API - confirm GPU residency, compare device output against the source model, and diagnose device-only failures such as silent CPU fallback, whole-graph compile ceilings, and fp16 range breaks. Use after conversion or quantization, when device output is wrong or NaN, when a clean graph fails to compile only on device, or when GPU and CPU outputs are suspiciously identical.","https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Fon-device-verification\u002FSKILL.md",[],[66,67,68,29,69,70,71,18,23,72],"on device verification","verification","graph","FP16","compile","diagnose","gpu",{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":31},"01M6BY5F447DRN3YDJVRWDG9MZ","litert-google-tensor","Compiles LiteRT (.tflite) models ahead-of-time for Google Tensor TPUs (Tensor G5 on Pixel 10, Tensor G6 on Pixel 11) locally on Linux x86_64 or remotely via Google Colab (--colab on macOS, Windows, or ARM hosts), benchmarks them on a USB-attached Pixel with LiteRT's benchmark_model (NPU latency, peak memory, TPU tile time, TPU energy, optional CPU baseline), and packages compiled models for an Android Gradle app as a Google Play AI pack with the Tensor NPU runtime module and a Kotlin loader, applies it to the app and verifies it on a Pixel. Use when the user asks to compile, AOT-compile, or prepare a .tflite model for the Pixel TPU\u002FNPU, check whether a .tflite is already Tensor-compiled, measure on-device NPU performance of a compiled model, or package or deploy a compiled model into their Android app (or replace the one it ships). Don't use for Qualcomm, MediaTek, or Samsung NPUs, GPU-only benchmarking, LiteRT-LM or LLM (.litertlm) models, on-device JIT compilation, non-Gradle builds, or publishing to Google Play.","https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Flitert-google-tensor\u002FSKILL.md",[],[80,81,82,23,83,84,70,22,18,85,86,87,88,89,90,91,20,72,92,30],"google","litert google tensor","tensor","performance","package","windows","benchmark","linux","baseline","tpu","benchmarking","packages","play",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":104,"publishedAt":31},"01M6BY5BY9H6SDG9GRRTT04EWA","litert-conversion-workflow","Convert a Hugging Face LLM or vision-language model checkpoint into a .litertlm bundle that runs on the LiteRT-LM runtime with verified quality - classify the architecture against known runtime walls, pick the recipe family (dense, reasoning, hybrid SSM, VLM), export, quantize, gate the result against the source model, and publish. Use when converting a new LLM or VLM to LiteRT-LM, when a converted bundle crashes on the first message or dies at engine creation, when a quantized model answers worse than its source, or when deciding whether a model is convertible at all.","https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Flitert-conversion-workflow\u002FSKILL.md",[99],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[105,106,23,107,108,109,110,111,112,113,114,115,116,117,118,24,119,18,120,121],"conversion","workflow","litert conversion workflow","face","source","hugging face","verified","export","quantize","at","result","classify","message","creation","pick","publish","recipe",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":31},"01M6BY5835F3RMMW9KCCZ006JM","litert-compiled-model-migration","Rapidly migrate an Android application from legacy TensorFlow Lite (TFLite) to the modern LiteRT CompiledModel API (2.x) in Open Source GitHub repositories, keeping the TensorFlow Lite Support Library as LiteRT Support (litert-support 2.3.0). Covers buffer reuse, NPU JIT compilation, a reference implementation, and a two-stage verification gate (compile check, then an on-device parity test against a golden output).","https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Flitert-compiled-model-migration\u002FSKILL.md",[],[129,18,23,70,130,131,132,133,134,135,136,67,20,29,137,138],"litert compiled model migration","tensorflow","open","library","jit","support","github","test","migrate","open source",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":31},"01M6BY55P8GVX66H0FG8JHXHWF","gpu-clean-conversion","Convert a PyTorch or Hugging Face model into a LiteRT model that runs fully on the GPU via the CompiledModel API with verified-correct output, and lay it out as a model recipe. Use when converting a new model, or when a converted model is rejected by the GPU, falls back to CPU, or returns wrong numbers on device.","https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Fgpu-clean-conversion\u002FSKILL.md",[],[105,146,72,147,148,110,111,149,150,151,152,121,153,154,29,155,156,157,18,23],"clean","gpu clean conversion","output","CPU","via","with","use","as","back","convert","pytorch","correct",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":31},"01M6BY501NESZTA4NSEKX9BSDE","benchmark-on-ddp","Measure a LiteRT .tflite model with `benchmark_model` on Developer Device Platform (DDP) lab phones through `litert benchmark --ddp`, or on the Mac you run it from, and turn the session into rows of the performance leaderboard under benchmark\u002Fleaderboard - one matrix entry per model, one session per accelerator, collect results.pb and runtime_info.pb, rebuild board.json, check the page, commit the data. Use when a model needs latency and memory numbers per platform, device and accelerator, or when a new benchmark_model release means re-measuring the board.","https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Fbenchmark-on-ddp\u002FSKILL.md",[],[165,86,18,22,166,167,23,168,169,170,171,83,172,173],"benchmark on ddp","page","run","data","commit","developer","json","collect","release"]