[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BY5BY9H6SDG9GRRTT04EWA":3,"skill-same:01M6BY5BY9H6SDG9GRRTT04EWA":92},{"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":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6BY5BY9H6SDG9GRRTT04EWA","litert-conversion-workflow",null,"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.","google-ai-edge\u002Flitert-samples","google-ai-edge","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F150697620?v=4","01M6BY4NHMZF88PJAC1E1QJY8N","01M6BY4NNXP8PC95Y6CABCJXP9",494,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Flitert-conversion-workflow\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"litert","workflow","litert conversion workflow","conversion","face","source","hugging face","verified","export","quantize","at","result","classify","message","recipe","creation","architecture","pick","model","publish","2026-11-10 10:12:30",false,"---\nname: litert-conversion-workflow\ndescription: 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.\n---\n\n# LiteRT-LM conversion workflow\n\nA conversion is done when three things hold, in this order:\n\n1. the bundle loads and generates through the LiteRT-LM engine (not just\n   the raw `.tflite` graphs),\n2. **output quality is gated against the source model** — a floor gate plus\n   a task-level parity check, not a smoke test,\n3. it holds up on the deployment path it claims: the target backend, the\n   target device, and multi-turn conversation.\n\nEach step can pass while the next one fails. A bundle that converts can\ndie at engine creation; an engine that generates can be quantization\ngarbage; a model that answers 8\u002F8 single-turn can crash on message two.\nThe gates exist because every one of these has happened.\n\nScope: models producing a `.litertlm` bundle consumed by the LiteRT-LM\nengine (`pip install litert-lm`) — text LLMs and vision-language models\n(a VLM bundle is an LLM bundle plus two vision graphs;\n`references\u002Fvlm-conversion.md` covers the delta). Standalone\u002Fclassic\n`.tflite` models go through the `gpu-clean-conversion` →\n`accuracy-safe-quantization` → `on-device-verification` lane; this skill\nis the LM sibling and reuses their discipline where it applies.\n\n## Step 0: classify before you convert\n\nLook at `config.json` (`model_type`, `layer_types`, MoE fields, size)\n**before** running anything. Architecture decides everything downstream,\nand some structures die at a known point no recipe can route around.\n`references\u002Farchitecture-walls.md` is the lookup table: structure → where\nit dies (export \u002F load \u002F engine \u002F backend) → the error signature you'll\nsee. Check it first; it turns a day of debugging into a table lookup.\n\nThen pick the lane in `references\u002Frecipe-selector.md`: plain dense\ndecoders ride a standard export; hybrids (SSM \u002F linear-attention \u002F\nshort-conv) need state-aware export plus executor metadata; reasoning\nmodels need template care; MoE and MLA are currently walls.\n\n## Loop\n\n**1. Export with a minimal, extraction-safe template.** The single most\ncommon ship-killer is not math — it is the chat template. Export with\n`use_jinja_template=False` and a minimal ChatML-style template swapped in,\nso the bundle carries plain prefix\u002Fsuffix markers and **no Jinja at all**.\nVendor templates routinely call Python methods (`.get()`, `.startswith()`,\n`.strip()`) that the runtime's minijinja renderer does not implement — such\na bundle imports fine and dies on the first message. Details, the\nmulti-turn prefix contract, and the tokenizer traps that pair with this:\n`references\u002Ftemplate-tokenizer-traps.md`.\n\n**2. Check the bundle before measuring anything.**\n\n```bash\npython -m litert_lm_builder.litertlm_peek_main --litertlm_file model.litertlm\n```\n\n`prompt_templates`-only = safe. A `jinja_prompt_template` carrying\nPython-method calls = the first-message crasher. Also confirm the stop\ntokens and (for hybrids) the executor-metadata section are present.\n\n**3. Quantize on the LLM lane.** int8 dynamic is the safe default;\nint4 must be **blockwise** (block-32 quality, block-128 for ~4B \u002F iPhone\nsection limits) — channelwise int4 collapses decoders while still passing\nsmoke tests. Conv\u002Fscan layers of hybrids stay float. The decision facts\nand the recipe mechanics: `references\u002Frecipe-selector.md` §Quantization,\nplus the `accuracy-safe-quantization` skill for the general ladder.\n\n**4. Gate quality — floor, parity, then structure.** Run the gate stack\nin `references\u002Fverification-gates.md`:\n\n- **8-question floor gate** on the engine (CPU, then the target backend).\n  Catches collapse, never proves parity.\n- **Task parity** (e.g. GSM8K n≥100) against the source model, same\n  prompt and extraction both sides. Reasoning models need\n  max-tokens ≥ 2048 or int4 falsely looks degraded.\n- **First-token length sweep** — chat-templated prompt lengths are\n  chunked by the engine's prefill planner, and state-carrying models\n  corrupt at *specific lengths* while answering perfectly at others.\n- **Multi-turn** — single-turn evals structurally cannot catch\n  template-contract violations that kill message two.\n\n**5. Gate on the target device.** Desktop GPU pass ≠ mobile GPU pass\n(different delegates, different compilers). Record device, backend,\nruntime version, and speeds next to the quality numbers — the\n`on-device-verification` skill's rules apply unchanged.\n\n**6. Publish behind the gate.** The upload step must mechanically refuse\nunless the quality report passed — a collapsed quant that reaches a public\nrepo costs more than every hour the gates cost. Card conventions and the\npublish checklist: `references\u002Fverification-gates.md` §Publish.\n\n## Symptom router\n\n| What you see | Where to look |\n|---|---|\n| Export raises in `torch.export` \u002F tracing | `architecture-walls.md` — data-dependent guards (MoE gating, dynamic rope), dtype-in-constant-path traps |\n| Export OK, engine creation fails: `No KV cache inputs found` | Hybrid on a pre-0.15 runtime — runtime too old for the architecture |\n| Engine OK, generation dies: `NOT_FOUND ... missing some output TensorBuffers` | Hybrid bundle missing the executor-metadata section (`recipe-selector.md` §Hybrids) |\n| First message crashes: `unknown method: map has no method named get` | Vendor Jinja embedded in the bundle — re-export per Loop step 1 |\n| Output is fluent garbage \u002F prompt seems ignored | Tokenizer packaging (`template-tokenizer-traps.md` §Tokenizer) |\n| Runtime crash: `Token id N is out of range` | Added special tokens dropped from the packaged tokenizer — same file, §Added tokens |\n| Stop token printed as literal text \u002F model never stops | Stop-token metadata incomplete — §Stop tokens |\n| Answers fine at some prompt lengths, garbage\u002Fempty at others | Prefill-padding state corruption — run the length sweep, `verification-gates.md` |\n| Message two fails (or message three, after a reply that carried a thought) or quality drops mid-conversation | Template prefix contract violated — `template-tokenizer-traps.md` §Multi-turn |\n| int4 passes the 8-question gate but tanks the benchmark | The floor-gate trap — gate is a floor, parity is the verdict (`verification-gates.md`) |\n| Every build scores 8\u002F8 and the gate never discriminates | Floor items are saturated — rebuild the gate from borderline cases (`verification-gates.md` §1) |\n| The converted model *beats* its source | Suspect the harness, not the recipe: a mis-prompted or mis-rendered reference (`verification-gates.md` §2, `vlm-conversion.md` §Gates) |\n| Scored numbers look plausible but wrong; generation is fine | The scoring-API traps — session reuse and `apply_prompt_template=True` (`verification-gates.md` §0) |\n| Quality flips only on one backend | 4-layer triage: torch → torch-control → engine-CPU → engine-GPU (`verification-gates.md` §Triage) |\n| GPU rejects the graph (`not fully delegated`, named op) | `architecture-walls.md` §Backend walls; classic-op rewrites live in `gpu-clean-conversion` |\n| Vision tower aborts export (`grid_thw`, `cu_seqlens` guards) | Dynamic-resolution tower — static rewrite (`vlm-conversion.md`) |\n| VLM bundle: \"Failed to create conversation\" | Structured prompt_templates missing from metadata (`vlm-conversion.md`) |\n| VLM engine creation fails on device naming GATHER_ND | Patch reorder in the vision tower — raster-order rewrite (`vlm-conversion.md`) |\n| VLM answers ignore the image \u002F describe the wrong thing | Preprocessing contract (mean\u002Fstd, NCHW) or embedder injection — gates in `vlm-conversion.md` |\n\n## Watch for\n\n- **Pin and record the toolchain.** litert-torch \u002F litert-converter \u002F\n  litert-lm-builder \u002F ai-edge-quantizer \u002F transformers versions decide\n  what exports and what runs; several walls in the references are\n  version-bounded facts. A conversion note without versions is not\n  reproducible.\n- **Pinned is not yet byte-identical.** Two builds of the same inputs\n  still differ: litert_lm_builder writes a fresh `uuid` and\n  `creation_timestamp` into the header (google-ai-edge\u002FLiteRT-LM#4064),\n  and `export_hf` writes the stop tokens in an order that changes with\n  Python's hash seed (google-ai-edge\u002Flitert-torch#1346; export with\n  `PYTHONHASHSEED=0`).\n  [hf-to-litertlm](https:\u002F\u002Fgithub.com\u002Fjohn-rocky\u002Fhf-to-litertlm) holds\n  both fixed and writes a lock; its `scripts\u002Fverify_lock.py` rebuilds\n  from the lock and compares the bytes.\n- **The runtime moves under you.** A wall table entry is a dated fact,\n  not a law — re-test walls on each runtime\u002Fconverter release, in both\n  directions: walls fall (blocked architectures start working) and\n  regressions appear (bundles that ran stop running). Both have happened\n  in the same release.\n- **Never diagnose quality without a control.** Run the same eval on the\n  source model with the same prompt and extraction; a broken harness\n  undermeasures everyone and reads as a conversion bug.\n- **The engine adds behavior the graph does not have** — start-token\n  prepending, prefill chunking, cross-conversation caching. When engine\n  output differs from a raw-graph replay, reproduce the engine's exact\n  token stream before blaming the graph.\n- **One variable at a time at ship time.** Repair published artifacts\n  from the published files, not from local experiments; verify by\n  checksum that what you gated is what you shipped.\n\n## Output layout\n\nShip each conversion as a recipe, the same split the model-recipe skills\nuse — export, verification, and repair each separately re-runnable:\n\n```\n\u003Cmodel>\u002F\n  convert_\u003Cmodel>.py       export driver: flags, template swap, quant recipe\n  templates\u002F\u003Cmodel>.jinja  the minimal template the bundle embeds\n  verify\u002F                  gate scripts + their JSON results\n  README.md                versions, recipe, gate numbers (device + backend\n                           + runtime named), known limitations — honest ones\n```\n\nState known limitations on the card in actionable form (\"prompts whose\ntemplated length lands on 33–37 tokens can end the reply early; adding or\nremoving a word avoids it\" — a real example). An honest limitation note\nsurvives contact with users; a hidden one becomes an issue report.\n","# LiteRT-LM conversion workflow\n\nA conversion is done when three things hold, in this order:\n\n1. the bundle loads and generates through the LiteRT-LM engine (not just\n   the raw `.tflite` graphs),\n2. **output quality is gated against the source model** — a floor gate plus\n   a task-level parity check, not a smoke test,\n3. it holds up on the deployment path it claims: the target backend, the\n   target device, and multi-turn conversation.\n\nEach step can pass while the next one fails. A bundle that converts can\ndie at engine creation; an engine that generates can be quantization\ngarbage; a model that answers 8\u002F8 single-turn can crash on message two.\nThe gates exist because every one of these has happened.\n\nScope: models producing a `.litertlm` bundle consumed by the LiteRT-LM\nengine (`pip install litert-lm`) — text LLMs and vision-language models\n(a VLM bundle is an LLM bundle plus two vision graphs;\n`references\u002Fvlm-conversion.md` covers the delta). Standalone\u002Fclassic\n`.tflite` models go through the `gpu-clean-conversion` →\n`accuracy-safe-quantization` → `on-device-verification` lane; this skill\nis the LM sibling and reuses their discipline where it applies.\n\n## Step 0: classify before you convert\n\nLook at `config.json` (`model_type`, `layer_types`, MoE fields, size)\n**before** running anything. Architecture decides everything downstream,\nand some structures die at a known point no recipe can route around.\n`references\u002Farchitecture-walls.md` is the lookup table: structure → where\nit dies (export \u002F load \u002F engine \u002F backend) → the error signature you'll\nsee. Check it first; it turns a day of debugging into a table lookup.\n\nThen pick the lane in `references\u002Frecipe-selector.md`: plain dense\ndecoders ride a standard export; hybrids (SSM \u002F linear-attention \u002F\nshort-conv) need state-aware export plus executor metadata; reasoning\nmodels need template care; MoE and MLA are currently walls.\n\n## Loop\n\n**1. Export with a minimal, extraction-safe template.** The single most\ncommon ship-killer is not math — it is the chat template. Export with\n`use_jinja_template=False` and a minimal ChatML-style template swapped in,\nso the bundle carries plain prefix\u002Fsuffix markers and **no Jinja at all**.\nVendor templates routinely call Python methods (`.get()`, `.startswith()`,\n`.strip()`) that the runtime's minijinja renderer does not implement — such\na bundle imports fine and dies on the first message. Details, the\nmulti-turn prefix contract, and the tokenizer traps that pair with this:\n`references\u002Ftemplate-tokenizer-traps.md`.\n\n**2. Check the bundle before measuring anything.**\n\n```bash\npython -m litert_lm_builder.litertlm_peek_main --litertlm_file model.litertlm\n```\n\n`prompt_templates`-only = safe. A `jinja_prompt_template` carrying\nPython-method calls = the first-message crasher. Also confirm the stop\ntokens and (for hybrids) the executor-metadata section are present.\n\n**3. Quantize on the LLM lane.** int8 dynamic is the safe default;\nint4 must be **blockwise** (block-32 quality, block-128 for ~4B \u002F iPhone\nsection limits) — channelwise int4 collapses decoders while still passing\nsmoke tests. Conv\u002Fscan layers of hybrids stay float. The decision facts\nand the recipe mechanics: `references\u002Frecipe-selector.md` §Quantization,\nplus the `accuracy-safe-quantization` skill for the general ladder.\n\n**4. Gate quality — floor, parity, then structure.** Run the gate stack\nin `references\u002Fverification-gates.md`:\n\n- **8-question floor gate** on the engine (CPU, then the target backend).\n  Catches collapse, never proves parity.\n- **Task parity** (e.g. GSM8K n≥100) against the source model, same\n  prompt and extraction both sides. Reasoning models need\n  max-tokens ≥ 2048 or int4 falsely looks degraded.\n- **First-token length sweep** — chat-templated prompt lengths are\n  chunked by the engine's prefill planner, and state-carrying models\n  corrupt at *specific lengths* while answering perfectly at others.\n- **Multi-turn** — single-turn evals structurally cannot catch\n  template-contract violations that kill message two.\n\n**5. Gate on the target device.** Desktop GPU pass ≠ mobile GPU pass\n(different delegates, different compilers). Record device, backend,\nruntime version, and speeds next to the quality numbers — the\n`on-device-verification` skill's rules apply unchanged.\n\n**6. Publish behind the gate.** The upload step must mechanically refuse\nunless the quality report passed — a collapsed quant that reaches a public\nrepo costs more than every hour the gates cost. Card conventions and the\npublish checklist: `references\u002Fverification-gates.md` §Publish.\n\n## Symptom router\n\n| What you see | Where to look |\n|---|---|\n| Export raises in `torch.export` \u002F tracing | `architecture-walls.md` — data-dependent guards (MoE gating, dynamic rope), dtype-in-constant-path traps |\n| Export OK, engine creation fails: `No KV cache inputs found` | Hybrid on a pre-0.15 runtime — runtime too old for the architecture |\n| Engine OK, generation dies: `NOT_FOUND ... missing some output TensorBuffers` | Hybrid bundle missing the executor-metadata section (`recipe-selector.md` §Hybrids) |\n| First message crashes: `unknown method: map has no method named get` | Vendor Jinja embedded in the bundle — re-export per Loop step 1 |\n| Output is fluent garbage \u002F prompt seems ignored | Tokenizer packaging (`template-tokenizer-traps.md` §Tokenizer) |\n| Runtime crash: `Token id N is out of range` | Added special tokens dropped from the packaged tokenizer — same file, §Added tokens |\n| Stop token printed as literal text \u002F model never stops | Stop-token metadata incomplete — §Stop tokens |\n| Answers fine at some prompt lengths, garbage\u002Fempty at others | Prefill-padding state corruption — run the length sweep, `verification-gates.md` |\n| Message two fails (or message three, after a reply that carried a thought) or quality drops mid-conversation | Template prefix contract violated — `template-tokenizer-traps.md` §Multi-turn |\n| int4 passes the 8-question gate but tanks the benchmark | The floor-gate trap — gate is a floor, parity is the verdict (`verification-gates.md`) |\n| Every build scores 8\u002F8 and the gate never discriminates | Floor items are saturated — rebuild the gate from borderline cases (`verification-gates.md` §1) |\n| The converted model *beats* its source | Suspect the harness, not the recipe: a mis-prompted or mis-rendered reference (`verification-gates.md` §2, `vlm-conversion.md` §Gates) |\n| Scored numbers look plausible but wrong; generation is fine | The scoring-API traps — session reuse and `apply_prompt_template=True` (`verification-gates.md` §0) |\n| Quality flips only on one backend | 4-layer triage: torch → torch-control → engine-CPU → engine-GPU (`verification-gates.md` §Triage) |\n| GPU rejects the graph (`not fully delegated`, named op) | `architecture-walls.md` §Backend walls; classic-op rewrites live in `gpu-clean-conversion` |\n| Vision tower aborts export (`grid_thw`, `cu_seqlens` guards) | Dynamic-resolution tower — static rewrite (`vlm-conversion.md`) |\n| VLM bundle: \"Failed to create conversation\" | Structured prompt_templates missing from metadata (`vlm-conversion.md`) |\n| VLM engine creation fails on device naming GATHER_ND | Patch reorder in the vision tower — raster-order rewrite (`vlm-conversion.md`) |\n| VLM answers ignore the image \u002F describe the wrong thing | Preprocessing contract (mean\u002Fstd, NCHW) or embedder injection — gates in `vlm-conversion.md` |\n\n## Watch for\n\n- **Pin and record the toolchain.** litert-torch \u002F litert-converter \u002F\n  litert-lm-builder \u002F ai-edge-quantizer \u002F transformers versions decide\n  what exports and what runs; several walls in the references are\n  version-bounded facts. A conversion note without versions is not\n  reproducible.\n- **Pinned is not yet byte-identical.** Two builds of the same inputs\n  still differ: litert_lm_builder writes a fresh `uuid` and\n  `creation_timestamp` into the header (google-ai-edge\u002FLiteRT-LM#4064),\n  and `export_hf` writes the stop tokens in an order that changes with\n  Python's hash seed (google-ai-edge\u002Flitert-torch#1346; export with\n  `PYTHONHASHSEED=0`).\n  [hf-to-litertlm](https:\u002F\u002Fgithub.com\u002Fjohn-rocky\u002Fhf-to-litertlm) holds\n  both fixed and writes a lock; its `scripts\u002Fverify_lock.py` rebuilds\n  from the lock and compares the bytes.\n- **The runtime moves under you.** A wall table entry is a dated fact,\n  not a law — re-test walls on each runtime\u002Fconverter release, in both\n  directions: walls fall (blocked architectures start working) and\n  regressions appear (bundles that ran stop running). Both have happened\n  in the same release.\n- **Never diagnose quality without a control.** Run the same eval on the\n  source model with the same prompt and extraction; a broken harness\n  undermeasures everyone and reads as a conversion bug.\n- **The engine adds behavior the graph does not have** — start-token\n  prepending, prefill chunking, cross-conversation caching. When engine\n  output differs from a raw-graph replay, reproduce the engine's exact\n  token stream before blaming the graph.\n- **One variable at a time at ship time.** Repair published artifacts\n  from the published files, not from local experiments; verify by\n  checksum that what you gated is what you shipped.\n\n## Output layout\n\nShip each conversion as a recipe, the same split the model-recipe skills\nuse — export, verification, and repair each separately re-runnable:\n\n```\n\u003Cmodel>\u002F\n  convert_\u003Cmodel>.py       export driver: flags, template swap, quant recipe\n  templates\u002F\u003Cmodel>.jinja  the minimal template the bundle embeds\n  verify\u002F                  gate scripts + their JSON results\n  README.md                versions, recipe, gate numbers (device + backend\n                           + runtime named), known limitations — honest ones\n```\n\nState known limitations on the card in actionable form (\"prompts whose\ntemplated length lands on 33–37 tokens can end the reply early; adding or\nremoving a word avoids it\" — a real example). An honest limitation note\nsurvives contact with users; a hidden one becomes an issue report.\n",{"name":5,"description":7},"main","fb7bd2edd795f0c61a09757f94456b5d19e66bc7","skills\u002Flitert-conversion-workflow",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-13 14:36:51",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add google-ai-edge\u002Flitert-samples --skill litert-conversion-workflow",{"tool":62,"command":63},"bunx","bunx skills add google-ai-edge\u002Flitert-samples --skill litert-conversion-workflow",{"tool":65,"command":66},"pnpm","pnpm dlx skills add google-ai-edge\u002Flitert-samples --skill litert-conversion-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Flitert-conversion-workflow\u002FSKILL.md",true,[70,76,80,84,88],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Farchitecture-walls.md","REFERENCE","参考文档",19574,"https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Flitert-conversion-workflow\u002Freferences\u002Farchitecture-walls.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Frecipe-selector.md",16768,"https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Flitert-conversion-workflow\u002Freferences\u002Frecipe-selector.md",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Ftemplate-tokenizer-traps.md",11512,"https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Flitert-conversion-workflow\u002Freferences\u002Ftemplate-tokenizer-traps.md",{"path":85,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fverification-gates.md",21385,"https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Flitert-conversion-workflow\u002Freferences\u002Fverification-gates.md",{"path":89,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fvlm-conversion.md",11242,"https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Flitert-conversion-workflow\u002Freferences\u002Fvlm-conversion.md",[93,108,131,148,167,180],{"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":99,"publishedAt":43},"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",[],[100,101,102,103,104,105,106,41,23,107],"on device verification","verification","graph","api","FP16","compile","diagnose","gpu",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":43},"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",[],[115,116,117,23,118,119,120,121,122,41,123,124,107,125,126,127,128,129,105,130],"google","litert google tensor","tensor","windows","benchmarking","benchmark","baseline","tpu","packages","android","play","package","kotlin","linux","performance","memory",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":43},"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",[],[138,41,23,139,140,141,142,143,144,145,146,103,101,124,147,105],"litert compiled model migration","library","open","open source","migrate","jit","support","github","test","tensorflow",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":43},"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",[],[107,155,156,26,157,29,30,158,159,160,161,162,37,163,103,164,165,166,41,23],"gpu clean conversion","clean","as","CPU","via","with","output","use","back","convert","pytorch","correct",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":43},"01M6BY52X9KX3VRXQJS622DZH3","compiled-model-app-scaffolding","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.","https:\u002F\u002Fgithub.com\u002Fgoogle-ai-edge\u002Flitert-samples\u002Fblob\u002Fmain\u002Fskills\u002Fcompiled-model-app-scaffolding\u002FSKILL.md",[],[41,174,39,175,127,176,130,177,23,124,103,178,179],"compiled model app scaffolding","ui","lifecycle","product","inference","demo",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"publishedAt":43},"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",[],[187,120,188,189,190,191,192,129,193,194,195,130,41,23],"benchmark on ddp","data","developer","commit","release","collect","json","run","page"]