# 本地大語言模型手機：從 AI 功能手機到個人 AI Runtime **系列：狀態驅動的本地具身 AI｜第 7 篇** **版本：v0.1** **日期：2026-08-01** --- ## 摘要 2026 年的旗艦手機已經明確跨過「能不能在手機上運行生成式模型」這道門檻。Google 的 Gemini Nano 已透過 Android AICore 在超過一億台裝置上提供本地生成式能力；Gemini Nano 4 與 Gemma 4 開始進一步支援更強的 reasoning 與 tool calling；Google 的 LiteRT-LM 也已能讓開發者在 Android 上直接部署自訂 LLM。官方基準甚至顯示，Gemma-4-E2B 在 Samsung S26 Ultra 上以 GPU backend 可達約 52 tokens/s decode、約 0.3 秒 time-to-first-token。Qualcomm Snapdragon 8 Elite Gen 5 與 MediaTek Dimensity 9500 也把 on-device agentic AI、personal knowledge graph、always-on light AI、長上下文與本地大模型壓縮列為晶片級設計目標。 因此，「本地大語言模型手機」已經不是遙遠的硬體幻想。 然而，今天大多數產品仍然更接近： $$ \text{Phone} + \text{On-device AI Features} $$ 而不是： $$ \text{Phone} = \text{Persistent Personal AI Runtime}. $$ 真正的「本地 AI 主腦手機」必須同時具備：可持續世界狀態、長期個人記憶、多模型路由、可替換本地模型、Agent 工具執行、裝置權限仲裁、跨機器人／眼鏡／電腦的狀態同步，以及在雲端斷線時仍能保持基本智能連續性。 本文因此將手機 AI 的演化分為三階段：AI 功能手機、可部署本地模型的 AI 計算手機，以及個人 AI Runtime 手機。本文主張，2026 年硬體與本地推理 Runtime 已大致進入第二階段，但第三階段真正的瓶頸已從純算力轉向作業系統權限、背景生命週期、記憶體／散熱、模型可替換性、跨應用授權與持久狀態治理。 本文最後提出一個 Personal AI Runtime Phone 參考架構： $$ \boxed{ \text{Always-on Sensors} \rightarrow \text{Event Bus} \rightarrow \text{World State} \rightarrow \text{Router} \rightarrow \text{Local Model Pool} \rightarrow \text{Permission Broker} \rightarrow \text{Apps / Robots / Devices} } $$ 在這個架構中，手機不再只是 AI 的顯示終端，而成為使用者隨身攜帶的「狀態與智能核心」。 **關鍵詞：** 本地大語言模型、AI 手機、Gemini Nano、AICore、LiteRT-LM、Snapdragon、Dimensity、Agent Runtime、世界狀態、個人 AI 主腦 --- # 1. 先定義：本文說的不是一般「AI 手機」 「AI 手機」這個詞已經被用得太寬。 只要有： - AI 修圖； - 通話摘要； - 錄音整理； - 翻譯； - 圈選搜尋； - 文字改寫； 都可能被稱為 AI 手機。 本文要討論的不是這一類。 可以先定義三個層級。 --- ## Level A：AI Feature Phone $$ \text{Phone} + \text{AI Features}. $$ 特點： - AI 是若干 App 功能； - 模型由 OEM／OS 提供； - 使用者通常不能替換核心模型； - 記憶主要屬於各 App； - AI 沒有統一世界狀態； - 不一定有持久 Agent。 今天大部分量產 AI 手機仍主要在這一層。 --- ## Level B：Local Model-Capable Phone $$ \text{Phone} + \text{Local Model Runtime}. $$ 特點： - 可本地部署 LLM／VLM； - 可以離線； - 可以使用 GPU／NPU； - 開發者可選擇模型； - App 能建立自己的 Agent。 2026 年的 Android 已經相當明確進入這一階段。 --- ## Level C：Personal AI Runtime Phone $$ \boxed{ \text{Phone} = \text{Personal AI Runtime} } $$ 特點： - 持續世界狀態； - 長期記憶； - 可替換本地模型； - 多模型路由； - 系統級 Agent； - 跨 App 操作； - 權限與風險仲裁； - 跨身體狀態同步； - 離線仍保持基本人格／任務連續性。 本文真正討論的是 Level C。 --- # 2. 2026 年：手機本地生成式 AI 已經是現實 Google 目前的 Android 文件明確指出，Gemini Nano 可以在 Android 裝置本地執行，不必連網，也不必把資料送到雲端。 它不是普通 App 直接自行管理模型，而是運行在： $$ \text{AICore} $$ 這個 Android 系統服務中。 AICore 負責： - 模型分發； - 模型更新； - 安全處理； - 硬體加速； - App 與模型之間的隔離。 因此： $$ \boxed{ \text{OS-managed on-device foundation model} } $$ 已經正式存在。 這是一個非常重要的歷史節點。 --- # 3. Gemini Nano 4：本地模型正在從「摘要器」走向 agentic capability 2026 年 4 月，Android 宣布 Gemma 4 進入 AICore Developer Preview，並指出這些模型將成為下一代 Gemini Nano 4 的基礎。 Android 官方目前也直接使用： > local agentic intelligence 來描述 Gemma 4 的 Android 能力方向，並提到 advanced reasoning 與 tool calling。 到了 2026 年 7 月，Android 官方開發者文章表示，Gemini Nano 已在超過： $$ 140\,\text{million} $$ 台裝置上運行。 這意味著： > 裝置端基礎模型已不再只是幾款實驗手機的展示，而開始成為 OS 級基礎設施。 這一點非常關鍵。 因為從「手機有模型」到「手機 OS 有模型服務」只差一步，就會進入： $$ \text{AI Runtime as System Infrastructure}. $$ --- # 4. 但 AICore 還不是本文所說的 Personal AI Runtime AICore 很重要，但它目前主要解決： $$ \text{Model Deployment} + \text{Inference Service}. $$ 它並沒有自動提供： - 使用者自定義的完整世界狀態； - 跨 App 長期記憶； - 任意模型替換； - 多機器人共享狀態； - 系統級任務生命週期； - 完整 Agent 權限治理。 所以： $$ \boxed{ \text{AICore} \neq \text{Personal Agent OS}. } $$ 它更像 Personal Agent OS 的一個重要底層元件。 --- # 5. LiteRT-LM：另一條更開放的路線 Google AI Edge 在 2026 年提供 LiteRT-LM： > 在 Android、iOS、Web、Desktop 與 Embedded 裝置上運行本地 LLM。 這與 AICore 很不一樣。 AICore 比較像： $$ \text{OS-managed model service}. $$ LiteRT-LM 則更像： $$ \text{developer-controlled local inference runtime}. $$ 這意味著開發者可以： - 自己選模型； - 自己打包； - 自己控制推理流程； - 在支援裝置上離線執行。 因此真正的 Personal AI Runtime 很可能不是二選一。 而是： $$ \boxed{ \text{System Model Service} + \text{Custom Local Model Runtime} } $$ 共同存在。 --- # 6. 一個非常重要的 2026 基準：手機已經可以「像樣地」跑小型 LLM Google LiteRT-LM 官方 benchmark 中，Gemma-4-E2B： - 模型檔約 2.58 GB； - 在 Samsung S26 Ultra 上： - CPU decode 約 47 tokens/s； - GPU decode 約 52 tokens/s； - GPU time-to-first-token 約 0.3 秒。 這不是大型 70B 模型。 但這個速度已經足以支援： - 即時文字對話； - intent parsing； - task routing； - 狀態摘要； - 簡單 tool calling； - 本地 Agent 決策。 也就是說： $$ \boxed{ \text{Small Local Agent Model} } $$ 在 2026 年已經不是慢到不可用。 而真正重要的是： > 它不需要處理所有問題。 第 5 篇的按需智能意味著，只要小模型能處理大部分高頻事件，大模型便可以稀疏啟動。 --- # 7. Qualcomm：手機 SoC 已經開始直接設計「個人 Agent」 Snapdragon 8 Elite Gen 5 的官方定位已經不只寫 generative AI，而明確使用： $$ \text{personalized Agentic AI}. $$ 其 Sensing Hub 包含： - always-sensing camera； - AI processor； - Personal Scribe； - Personal Knowledge Graph。 Qualcomm 甚至把： > understand and adapt to user habits, preferences, and conversations 直接作為晶片級 agentic AI 使用情境。 更有意思的是，Qualcomm 的 Mobile AI 頁面目前宣稱 Snapdragon 8 Elite Gen 5 已能在手機處理器上運行 GPT-OSS，峰值標示最高約： $$ 20\text{ tokens/s}. $$ 這是廠商公布的特定展示數字，不代表所有手機、所有上下文與所有量化設定都能長時間維持相同速度。 但它至少說明： $$ \boxed{ \text{20B-class local inference is no longer physically absurd on mobile silicon.} } $$ 真正剩下的是 sustained power、RAM 與產品化問題。 --- # 8. MediaTek：always-on AI 與大模型記憶體效率已經進入晶片設計 Dimensity 9500 的官方資料同樣非常值得注意。 它包含： - NPU 990； - Generative AI Engine 2.0； - Transformer 專用處理； - LLM memory compression； - BitNet 1.58-bit model support； - Super-Efficient NPU； - always-on light AI； - 最高 128K 級長文字處理能力。 這說明手機 SoC 的設計方向已經從： $$ \text{camera AI} $$ 逐漸變成： $$ \boxed{ \text{persistent personal AI workload}. } $$ 尤其是： $$ \text{always-on light model} + \text{large model on demand} $$ 這與本系列提出的多時間尺度、多模型路由幾乎是同一個工程方向。 --- # 9. 真正的瓶頸開始從 TOPS 轉向記憶體 對本地 LLM，粗略的 4-bit 權重估算可以寫成： $$ M_{\mathrm{weights}} \approx 0.5P\text{ GB}, $$ 其中 $P$ 是十億參數。 例如： | 模型規模 | 4-bit 權重粗估 | |---:|---:| | 3B | 約 1.5 GB | | 7B | 約 3.5 GB | | 14B | 約 7 GB | | 20B | 約 10 GB | | 32B | 約 16 GB | 但這只是權重。 實際執行還需要： - KV cache； - runtime； - GPU/NPU buffer； - vision encoder； - ASR/TTS； - Android； - App； - 世界狀態； - 資料庫。 因此： $$ M_{\mathrm{runtime}} > M_{\mathrm{weights}}. $$ 所以未來真正的 AI-native phone 很可能需要： $$ 24\text{ GB} \sim 32\text{ GB} $$ 甚至更大的可用記憶體，才能讓較大的本地模型、長上下文與多模態服務同時存在得比較舒服。 這不是對某款未來產品的保證，而是依目前模型記憶體需求所做的工程推估。 --- # 10. 但「大 RAM 手機」本身仍然不等於 AI 主腦 就算明天出現： $$ 32\text{ GB RAM} + \text{fast NPU}, $$ 仍然缺少最重要的 Runtime。 真正的 Personal AI Phone 必須有： $$ \mathcal P = ( S, K, R, M, A, D ), $$ 其中： - $S$ ：World State； - $K$ ：Long-term Memory； - $R$ ：Model Router； - $M$ ：Model Pool； - $A$ ：Authority / Permission Runtime； - $D$ ：Device Mesh。 手機晶片只解決： $$ M $$ 的一部分。 剩下五個結構才真正決定它是不是「個人 AI」。 --- # 11. 世界狀態必須成為手機的一級系統 今天手機裡其實已經有大量世界訊號： - 時間； - 位置； - 相機； - 麥克風； - 藍牙； - Wi-Fi； - 通知； - 行事曆； - 聯絡人； - 裝置狀態； - 穿戴設備； - 汽車； - 智慧家庭。 但它們大多分散在各 App 與系統服務中。 Personal AI Runtime 需要建立： $$ S_t^{\mathrm{personal}} $$ 例如： ```text current_location current_device current_task active_conversation nearby_robot headset_state calendar_context user_attention battery_budget network_state ``` 其中每一項還應有： - timestamp； - source； - confidence； - permission scope。 於是手機不必每次問 LLM： > 我現在在哪裡？剛剛在幹嘛？ 它只需要： $$ \phi(S_t^{\mathrm{personal}}) $$ 作為模型上下文。 --- # 12. 個人記憶不能只等於聊天紀錄 如果手機真的成為 AI 主腦： $$ \text{Memory} \neq \text{Chat History}. $$ 至少要分： $$ K= K_{\mathrm{episodic}} \cup K_{\mathrm{semantic}} \cup K_{\mathrm{procedural}} \cup K_{\mathrm{preference}}. $$ 包括： - 事件記憶； - 人物／世界知識； - 已學技能； - 穩定偏好； - 長期任務。 同時必須與當前世界狀態區分： $$ \boxed{ \text{Memory says what happened;} \quad \text{State says what is happening now.} } $$ 這是手機從聊天工具變成長期 Agent 的必要條件。 --- # 13. 真正困難的問題其實是 Android 權限 目前 Android 的安全模型刻意假設： > App 不應任意控制其他 App 與整個 OS。 每個 App 都運行在有限權限的 sandbox 中。 要存取： - 麥克風； - 相機； - 聯絡人； - 裝置； - 其他敏感系統資源； 需要明確權限。 有些權限甚至只允許： $$ \text{system / signature app} $$ 使用。 這對一般 App 是好事。 但對 Personal AI Runtime 會形成根本矛盾： > 如果 AI 不能跨 App、不能管理背景狀態、不能調用系統工具，它就很難成為真正的「主 Agent」。 因此： $$ \boxed{ \text{AI Phone} } $$ 最終很可能不是靠普通 App 完成。 而需要： $$ \boxed{ \text{OS-integrated Agent Runtime}. } $$ --- # 14. Background Runtime 也是大問題 Android 長期限制背景執行，原因很合理： - 省電； - 控制 RAM； - 防止 App 長期偷偷運作； - 改善使用者體驗。 但 Personal AI 恰恰需要： $$ \text{persistent background state}. $$ 解法不應是： > 讓一個 App 永遠在背景跑 20B 模型。 而應該把系統拆成： $$ \text{Tiny Always-on Service} + \text{Event Wakeup} + \text{On-demand Model}. $$ 也就是： - 世界狀態服務常駐； - 低功耗事件偵測常駐； - 小 Router 常駐或快速喚醒； - 大模型休眠。 這完全吻合手機 OS 原本的省電哲學。 --- # 15. 所以真正的 AI 手機 Runtime 應該長這樣 可以建立： ```text Sensors / Apps / Devices │ ▼ Event Gateway │ ▼ ┌──────────────────┐ │ Personal World │ │ State Runtime │ └────────┬─────────┘ │ ┌──────────┴───────────┐ │ │ ▼ ▼ Long-term Memory Model Router │ ┌──────────────┬───────┴────────┐ ▼ ▼ ▼ Tiny Model Local Daily LLM Local Large │ ▼ Cloud │ ▼ Structured Proposal │ ▼ Permission Broker │ ┌──────────────┬───────────┴─────────┐ ▼ ▼ ▼ Apps Robot Glasses ``` 核心是： $$ \boxed{ \text{State First} \rightarrow \text{Model Second} \rightarrow \text{Permission Before Effect}. } $$ --- # 16. Permission Broker 會是比模型更重要的系統元件 假設 AI 說： > 「我幫你把門打開。」 這不是普通 tool call。 Runtime 應該檢查： $$ \operatorname{Allow} ( \text{agent}, \text{action}, \text{resource}, \text{context} ). $$ 例如： - AI 有沒有控制門鎖的權限？ - 使用者是否在附近？ - 現在是不是深夜？ - 是否需要二次確認？ - 這是高風險操作嗎？ - 指令是否來自本人？ 所以： $$ \boxed{ \text{Agent Tool Calling} \neq \text{Unrestricted Device Control}. } $$ 真正成熟的 AI Phone 必須有 Agent-specific authority model。 --- # 17. 手機最適合成為「主腦」的原因不是 NPU 手機有幾個其他硬體很難同時具備的條件： $$ \boxed{ \text{Always with the user} } $$ 它同時擁有： - 身分驗證； - 安全晶片； - 5G； - Wi-Fi； - Bluetooth； - UWB； - GPS； - camera； - microphone； - battery； - display； - 私人資料； - App ecosystem。 因此手機天然知道： > 「這個人的目前數位世界」。 迷你機器人只知道： > 「這個房間」。 眼鏡只知道： > 「目前視野」。 電腦只知道： > 「目前工作環境」。 手機則可以成為： $$ \boxed{ \text{Personal State Anchor}. } $$ --- # 18. AI 可以換身體，但狀態錨點仍在手機 假設個人 AI 有三個 embodiment： $$ D= \{ \text{Phone}, \text{Robot}, \text{Glasses} \}. $$ 早上： ```text AI → phone speaker ``` 出門： ```text AI → glasses + earbuds ``` 回家： ```text AI → robot ``` 如果所有長期記憶與世界狀態都存在手機： $$ S_t^{\mathrm{personal}} $$ 那麼身體切換並不代表： $$ \text{new AI instance}. $$ 而只是： $$ \text{change embodiment endpoint}. $$ 這已經開始接近第 8 篇要討論的問題。 --- # 19. 本地模型也不應只有一個 一台真正的 AI-native phone 更可能有： $$ \mathcal M= \{ M_{\mathrm{sense}}, M_{\mathrm{router}}, M_{\mathrm{daily}}, M_{\mathrm{reason}}, M_{\mathrm{cloud}} \}. $$ 例如： ### Always-on $$ M_{\mathrm{sense}} $$ 做： - wake word； - event detection； - attention； - 簡單分類。 ### Router $$ M_{\mathrm{router}} $$ 判斷： - 要不要推理； - 用哪一層模型。 ### Daily $$ M_{\mathrm{daily}} $$ 處理： - 對話； - 摘要； - local tools； - 日常 Agent 任務。 ### Reason $$ M_{\mathrm{reason}} $$ 較大、較耗電，只在必要時喚醒。 ### Cloud 最後才升級。 因此手機不是： $$ \text{one model device}. $$ 而是： $$ \boxed{ \text{model orchestration device}. } $$ --- # 20. 模型可替換性是一條非常重要的分界 今天 AICore 的優點是： - OS 幫你管模型； - App 不需操心部署； - 有安全與硬體最佳化。 但真正的 Personal AI Runtime 還需要另一種能力： > 使用者是否能選擇自己的模型？ 例如： ```text Daily model = Model A Coding model = Model B Private model = Model C Vision model = Model D ``` 因此未來可能形成： $$ \text{System Model} + \text{User Model} + \text{Task Model}. $$ 這比「只有一個官方助手」更接近個人計算平台的歷史。 手機當年真正變成電腦，不是因為它可以打電話。 而是因為： > 使用者可以裝不同 App。 AI-native phone 真正成熟的類似指標可能是： > 使用者可以裝不同模型與 Agent Runtime。 --- # 21. NPU 生態仍然沒有完全統一 2026 年 Google LiteRT 的 NPU delegate 文件本身透露出一個重要現實： 不同 Android 廠商的 NPU runtime 仍有差異。 目前 Google 官方已提供／整合 Qualcomm AI Engine Direct delegate，而 Pixel 與 Samsung System LSI 的 NPU delegates 仍列為後續支援。 也就是： $$ \boxed{ \text{Android NPU ecosystem} } $$ 還沒有完全像： $$ \text{GPU + standardized API} $$ 那麼透明。 這會直接影響「任意本地模型」跨手機部署的難度。 因此未來真正 AI-native OS 必須把： $$ \text{model} \rightarrow \text{best available accelerator} $$ 進一步標準化。 --- # 22. 散熱會決定「能跑」與「能常用」之間的差異 手機 demo 可以短時間做到： $$ 20\text{ tokens/s}, $$ 不代表可以： $$ 20\text{ tokens/s}\times24\text{ hours}. $$ 長期負載會遇到： - thermal throttling； - battery drain； - RAM pressure； - background scheduling。 因此： $$ \boxed{ \text{Peak Capability} \neq \text{Sustained Personal AI}. } $$ 真正 AI Runtime 的解法仍然是第 5 篇的： $$ \text{Sparse Invocation}. $$ 大模型應該像： > CPU 的 turbo。 不是： > 永遠滿功耗運作。 --- # 23. 一個合理的 2026–2030 時間線 以下是基於目前晶片、Runtime 與 OS 發展所做的**研究預測**，不是確定產品發布資訊。 ## 2026：基礎件已到位 已經存在： - OS-managed on-device model； - custom local LLM runtime； - on-device agentic model； - flagship NPU； - local small-model real-time inference； - always-on light AI。 因此： $$ \boxed{ \text{hardware feasibility} \approx \text{yes}. } $$ 但 Personal AI Runtime 尚未完整形成。 --- ## 2027–2028：第一批真正 AI-native phone 很可能出現 較可能具有： - 24 GB 或更高記憶體； - 多本地模型； - 長期記憶； - 本地 Agent； - 更深 OS tool access； - 裝置間 AI continuity； - local/cloud routing。 這個時間區間是工程推估，不是已公布 roadmap。 --- ## 2028–2030：個人 AI 主機可能成為旗艦機新形態 此時競爭可能不再只是： $$ \text{camera} + \text{benchmark}. $$ 而是： - 你的 AI 記得多少？ - 離線能做多少？ - 能不能換模型？ - 能不能跨設備？ - Agent 有多穩定？ - 世界狀態是否屬於使用者？ - 能不能把手機當 AI hub？ 到這時： $$ \text{Phone} $$ 才真正可能從「AI 入口」變成： $$ \boxed{ \text{Personal Intelligence Host}. } $$ --- # 24. 這與 Ryzen AI Max+ 395 的關係 Ryzen AI Max+ 395 本身顯然不是手機晶片。 它的參考意義是： $$ \boxed{ \text{large shared memory} + \text{heterogeneous compute} } $$ 對本地模型非常重要。 未來手機不可能直接縮成： $$ 128\text{ GB},120\text{ W} $$ 的 AI Max+ 395。 但設計思想可能收斂： $$ \text{CPU} + \text{GPU} + \text{NPU} + \text{shared memory} + \text{model-aware runtime}. $$ 手機真正需要的是： > 把同樣的「本地模型優先」思想壓縮進幾瓦到十幾瓦的持續功耗範圍。 因此 AI PC 與 AI Phone 的差異，未來可能越來越像： $$ \text{power envelope} + \text{memory ceiling}, $$ 而不是「一個能跑 LLM、一個不能」。 --- # 25. 最重要的轉變：手機從 App Host 變成 Agent Host 傳統智慧手機： $$ \text{Phone} = \text{App Host}. $$ 使用者主動： 1. 找 App； 2. 打開； 3. 輸入； 4. 執行； 5. 關閉。 Personal AI Runtime 則可能變成： $$ \text{Phone} = \text{Agent Host}. $$ Agent： - 持續知道任務； - 接收事件； - 在權限內調用 App； - 按需推理； - 在不同裝置切換 embodiment。 於是 App 反而可能逐漸變成： $$ \text{Agent Tools}. $$ 這不是說 GUI App 會消失。 而是： > App 不再是使用者唯一的執行入口。 這是一個比「手機裡多一個聊天機器人」大得多的轉變。 --- # 26. 結論：真正的本地 AI 手機已經不是硬體科幻，而是 Runtime 問題 2026 年已經可以確認： $$ \boxed{ \text{On-device LLM on phones is real}. } $$ 真正尚未完成的是： $$ \boxed{ \text{On-device Persistent Personal Agent Runtime}. } $$ 兩者之間的差距主要不再是： > 手機晶片夠不夠快？ 而是： - 世界狀態； - 長期記憶； - 背景 Runtime； - 權限； - 模型切換； - 多設備同步； - 熱與能源； - 個人資料治理。 所以本文最後把「AI 本地大語言模型手機」定義為： $$ \boxed{ \text{AI Phone} = \text{Local Model Pool} + \text{Persistent World State} + \text{Long-term Memory} + \text{Agent Runtime} + \text{Permission Broker} + \text{Device Mesh}. } $$ 當這六個部分同時成立，手機才不只是「能跑本地大模型」。 它會變成： > **一個隨身攜帶、持續維持個人世界狀態、可以把智能投射到不同身體上的個人 AI 主機。** 因此最後一篇的問題已經自然出現： 如果手機只是狀態錨點，而 AI 可以透過機器人、眼鏡、耳機、汽車與電腦行動， 那麼： > **AI 的「身體」到底還是不是單一裝置？** --- # 參考資料 1. Android Developers. *Gemini Nano*. Updated 2026-04-02. https://developer.android.com/ai/gemini-nano 2. Android Developers Blog. *Announcing Gemma 4 in the AICore Developer Preview*. 2026-04-02. https://developer.android.com/blog/posts/announcing-gemma-4-in-the-ai-core-developer-preview 3. Android Developers Blog. *Build intelligent Android apps: On-device inference*. 2026-07-22. https://developer.android.com/blog/posts/build-intelligent-android-apps-on-device-inference 4. Google AI Edge. *LiteRT-LM Overview*. https://developers.google.com/edge/litert-lm/overview 5. Google AI Edge. *LiteRT Overview*. https://developers.google.com/edge/litert/overview 6. Google AI Edge. *LiteRT delegate for NPUs*. Updated 2026-06-02. https://developers.google.com/edge/litert/android/npu/overview 7. Qualcomm. *Snapdragon 8 Elite Gen 5 Mobile Platform*. https://www.qualcomm.com/smartphones/products/8-series/snapdragon-8-elite-gen-5 8. Qualcomm. *Mobile AI — Built for Generative AI at the Edge*. https://www.qualcomm.com/smartphones/features/mobile-ai 9. MediaTek. *Dimensity 9500 — Flagship 5G Agentic AI Platform*. https://www.mediatek.com/dimensity-9500 10. Android Developers. *Permissions on Android*. Updated 2026-07-14. https://developer.android.com/guide/topics/permissions/overview 11. Android Open Source Project. *Application Sandbox*. https://source.android.com/docs/security/app-sandbox 12. Android Developers. *Background Execution Limits*. Updated 2026-03-03. https://developer.android.com/about/versions/oreo/background