Small Language Models、On-device AI 与边缘部署趋势：从“小模型”到端侧智能系统

Small Language Models、On-device AI 与边缘部署趋势从“小模型”到端侧智能系统系列AI 论文盘点 / 技术趋势第二轮2026 AI 系统与 Agent 基础设施专题日期2026-07-06适合读者研究生、端侧 AI/推理系统工程师、关注小模型产品化的技术读者检索日期2026-07-06摘要2025 到 2026 年小语言模型Small Language Models, SLM和端侧 AI 的讨论明显从“能不能把大模型塞进手机”转向“如何设计一套可治理、可更新、可评测的本地智能系统”。这背后有三个同时发生的变化第一Gemma、Qwen、Llama、Phi、SmolLM 等模型家族持续发布 0.5B 到 4B 级别的密集模型或稀疏激活模型强调蒸馏、多语言、长上下文和设备侧适配第二INT8/INT4、weight-only quantization、KV cache 优化、1-bit/低比特研究和专用运行时把“参数量”之外的瓶颈暴露出来第三Apple Foundation Models、ExecuTorch、ONNX Runtime GenAI、llama.cpp、MLC/WebLLM、MLX 等框架让本地推理从研究 demo 进入应用栈。这篇文章的核心判断是SLM 不是大模型的廉价替代品而是另一种系统形态。它的价值不只来自低成本还来自低延迟、离线可用、隐私边界、个性化、边缘实时控制和云端兜底策略。真正的竞争点也不只是某个小模型在公开榜单上的分数而是模型、数据蒸馏、量化格式、runtime kernel、硬件后端、更新机制、权限隔离和评测回放能否组成稳定闭环。目录研究背景为什么小模型重新变成主线近一年路线图从 compact LLM 到本地 Agent代表论文与系统分组解读方法对比表关键技术趋势工程落地启发局限与争议接下来值得关注的问题总结参考资料1. 研究背景为什么小模型重新变成主线过去两年大模型能力跃迁主要由更大参数、更大数据和更长训练推动。但当 LLM 进入真实产品后单纯扩大模型并不能解决所有问题。移动端键盘补全、会议摘要、照片检索、离线翻译、可穿戴助手、车载交互、浏览器内 AI、企业内网工具、工业边缘设备等场景对延迟、功耗、隐私、网络可用性和单位成本有硬约束。一个 70B 或 400B 级别模型即使能力更强也不可能在所有交互里被实时调用。SLM 的机会来自这个约束面。它把“更强”拆成“足够强、足够快、足够便宜、足够私密、足够可控”。对很多任务用户并不需要通用研究级推理只需要稳定完成少数高频动作抽取日程、总结通知、生成短回复、改写语气、解释页面、执行本地快捷指令、在设备文件中检索、把语音转成结构化操作。小模型如果能在 100-300 ms 级别启动或流式返回并且不上传原始隐私数据产品价值会非常直接。另一个变化是数据蒸馏和 post-training 让小模型不再只是“训练不够大的模型”。Phi 系列、Gemma/Qwen/Llama 的小尺寸版本、SmolLM、MobileLLM 等工作都说明小模型能力越来越依赖高质量数据、teacher 模型、合成指令、推理轨迹和任务配方。换句话说SLM 的核心问题不是“参数少所以能力差”而是“参数预算有限时哪些知识和行为最值得被压进去”。同时端侧 AI 把推理系统问题放大了。云端服务可以用批处理、张量并行、PagedAttention、连续 batching 和大 GPU 内存摊薄成本设备侧则要面对几 GB 内存、NPU/GPU/CPU 后端差异、热 throttling、电池、应用沙箱、模型下载包体、增量更新、不同操作系统 API 和隐私合规。SLM 的研究脉络因此必须同时看模型结构、压缩、运行时和产品策略。2. 近一年路线图从 compact LLM 到本地 Agent2023-2024小模型从“参数压缩”变成“数据配方”。Phi-2/Phi-3、MobileLLM、TinyLlama、DistilGPT 类工作强调高质量数据、架构选择和训练预算。Meta 在 Llama 3.2 官方发布中把 1B/3B 文本模型定位为 edge/mobile 场景Microsoft 的 Phi-3 技术报告标题就强调“locally on your phone”。这一阶段的关键词是小模型可以在局部任务上达到可用但必须通过严格数据选择和 post-training 获得行为能力。2024-2025端侧运行时和量化成为基础设施。llama.cpp/GGUF、MLC/WebLLM、ExecuTorch、ONNX Runtime GenAI、Apple MLX 等项目把模型分发、低比特权重、kernel、KV cache 和硬件后端做成开发者能用的工具链。研究侧则继续推进 SmoothQuant、AWQ、GPTQ、QLoRA、KIVI、1-bit LLM 等压缩路线。这个阶段的重点不是“能跑一次”而是“能在不同设备上稳定、可测、可升级地跑”。2025小模型家族开始和大模型家族同步发布。Qwen3 官方博客列出从 0.6B 到 235B-A22B 的 dense/MoE 系列强调 thinking/non-thinking 模式与多语言Gemma 3 发布 1B/4B/12B/27B其中 1B 明确是轻量文本模型Gemma 3n 文档进一步面向移动端提到 MatFormer、Per-Layer Embeddings 和 2B/4B 有效参数规模。SmolLM3 则展示 3B 级开源模型在长上下文、多语言和 reasoning 上的定位。2026端侧模型开始从“本地问答”走向“本地 Agent 基础设施”。Google AI for Developers 页面已经列出 Gemma 4 1B/4B/12B/27B 与 Gemma 4n E2B/E4B 等新一代模型信息Apple Foundation Models framework 把本地模型能力暴露给应用开发者浏览器、本地 IDE、隐私敏感企业应用和消费电子设备开始把小模型用作 intent router、local planner、隐私过滤器、草稿生成器和云端调用前的预处理器。这里许多产品可用性和区域限制变化很快发布前应以官方文档再次核验。3. 代表论文与系统分组解读3.1 小模型家族能力来自参数、数据和蒸馏的共同设计Phi 系列是理解 SLM 的经典入口。Phi-3 技术报告认为通过高质量网络数据和合成数据训练小尺寸模型可以在移动设备可部署的约束下获得较强语言能力。Phi-4-mini-reasoning 则把目标进一步收窄到数学推理强调从 Phi-4 中蒸馏高质量数学推理轨迹并面向教育和移动场景。这里的工程启发是小模型通常不该追求“什么都还不错”而应围绕目标任务分布做数据配方。Llama 3.2 的 1B/3B 模型代表了另一路径大模型家族把小模型作为边缘和移动设备成员同步维护。Meta 官方发布称 1B/3B 模型支持本地 summarization、instruction following 和改写类任务并与移动硬件伙伴合作优化。它的意义在于小模型不再是社区二次裁剪的副产品而是模型家族设计中的正式部署目标。Qwen3 则展示了更宽的尺寸梯度。官方博客列出 0.6B、1.7B、4B、8B、14B、32B 等 dense 模型以及 30B-A3B、235B-A22B 等 MoE 模型。对端侧 AI 而言0.6B-4B 区间特别重要因为它们允许产品在“本地快速处理”和“云端高质量处理”之间做路由。Qwen3 还强调 thinking mode 和 non-thinking mode 的切换这对边缘系统很关键不是所有请求都值得花推理时计算。Gemma 3/Gemma 3n/Gemma 4 的官方文档把“设备侧”放到更显眼位置。Gemma 3 发布页称 1B 模型可在低资源环境运行Gemma 3n 文档明确面向 mobile/edge使用 MatFormer 和 Per-Layer Embeddings让 E2B/E4B 模型在内存占用上接近 2B/4B 有效参数Gemma 4 文档截至 2026-07-06 列出 1B 到 27B 的模型卡和 4n 版本。这里值得关注的不是单个 benchmark而是 Google 把小模型、移动端和多模态能力放在同一条产品线上维护。SmolLM3 是 2025 年开源社区值得看的 3B 级模型。Hugging Face 官方博客把它描述为 smol、multilingual、long-context reasoner并提供开放权重。它提醒我们3B 级模型不是只能做 toy demo如果数据、训练 recipe 和评测足够认真它可以成为本地开发者、浏览器和轻量 Agent 的默认候选之一。3.2 架构与训练小模型不是均匀缩小的大模型MobileLLM 的贡献在于系统研究 sub-billion 参数模型如何为 on-device use cases 优化。论文强调直接缩放大模型架构并不一定适合小参数区间需要重新权衡 depth、width、attention、embedding 和 FFN 配置。对工程读者来说这说明“同样 1B 参数”并不等价架构分配会显著影响延迟、内存和准确率。MatFormer 是另一个有代表性的思路在同一个训练好的模型中嵌入多个粒度的子模型从而按设备能力或请求难度选择不同计算路径。Gemma 3n 文档提到使用 MatFormer 架构这说明可弹性缩放的模型结构开始进入官方端侧模型。未来的端侧系统可能不再只下载一个固定模型而是下载一个可按功耗/延迟/质量动态裁剪的模型家族。MoE 对小模型也有启发但要谨慎。Qwen3 的 MoE 版本和许多前沿大模型都使用稀疏激活来提高参数效率在端侧MoE 可以让“总参数较大、每 token 激活较少”成为可能。但它也引入 expert routing、权重分页、存储包体和冷启动问题。对手机或嵌入式设备来说active parameters 低并不自动等于体验好权重加载和内存带宽往往更致命。训练数据方面小模型越来越依赖 teacher model 和合成数据。Phi、DeepSeek-R1 distill、Qwen/Gemma 的小尺寸版本都说明大模型可以把推理轨迹、工具格式、对话风格和领域知识压缩给学生模型。但这也带来一个隐患小模型会继承 teacher 的错误、拒答边界、语言偏好和幻觉模式。因此小模型必须单独做端侧任务评测而不能只引用 teacher 的能力叙述。3.3 量化与压缩真正的瓶颈常常是内存带宽端侧部署首先遇到的是内存。一个 3B 参数模型即使用 FP16 也需要约 6GB 权重内存还不包括 KV cache、runtime buffer、tokenizer、应用本身和操作系统压力。INT8/INT4 weight-only quantization 能显著降低包体和内存带宽是端侧 LLM 的基本工具。GPTQ、AWQ、SmoothQuant、QLoRA 等路线分别从训练后量化、activation-aware 权重保护、激活平滑和低秩适配角度推进低比特部署。对产品团队来说问题不是“哪种量化论文最优”而是目标设备后端是否有对应 kernel量化格式是否能被 runtime 支持长上下文下 KV cache 是否爆内存低比特是否破坏结构化输出、函数调用和安全策略。KV cache 是另一个经常被低估的端侧瓶颈。权重量化只压缩模型参数长对话、多轮 Agent、RAG 和本地文件检索会快速拉高 KV cache。KIVI 等工作把 KV cache 量化作为重点说明在长上下文和流式交互里内存管理与权重量化同样重要。端侧 Agent 如果需要保留多轮状态必须设计摘要、截断、缓存复用和云端兜底而不是无限堆上下文。1-bit/极低比特 LLM 是 2024-2026 年很活跃的方向。BitNet b1.58 论文提出把 LLM 权重压到三值/1.58 bit 表示目标是显著降低内存和能耗Microsoft 的 BitNet.cpp 项目则尝试给 1-bit LLM 提供高效 CPU 推理框架。需要注意的是这类路线仍在快速演进不同模型、任务和硬件上的收益需要实测不能把论文中的理想吞吐直接当作产品承诺。3.4 运行时端侧 AI 的“模型能力”很大一部分在 runtimellama.cpp 和 GGUF 的影响力在于把本地 LLM 推理变成了广大开发者可操作的事情。它支持多种量化格式和 CPU/GPU 后端社区模型分发也围绕 GGUF 形成生态。对于研究生和工程团队它是快速验证“某个模型在本机是否可用”的常用基线。ExecuTorch 代表 PyTorch 生态对 edge/on-device inference 的系统化投入。它面向移动和边缘设备把模型导出、图优化、delegate/backend 和运行时整合起来。对企业团队而言这类官方运行时的价值在于长期维护、设备覆盖和与训练框架的衔接而不只是单次性能。ONNX Runtime GenAI 提供了另一条跨平台路径强调使用 ONNX Runtime 运行 generative AI 模型并支持多硬件后端。它适合已有 ONNX/Windows/Azure/企业部署生态的团队。MLC LLM/WebLLM 则把浏览器和 WebGPU 纳入端侧 AI 视野使“无需安装本地应用的私有推理”成为可能。Apple MLX 和 Core ML/Apple Foundation Models 则更偏 Apple 设备栈。这里的现实判断是端侧 LLM 没有一个统一 runtime 会赢下所有场景。浏览器、iOS、Android、macOS、Windows、嵌入式 Linux、车载系统、NPU SDK 都有不同约束。工程上更稳妥的做法是定义模型中间格式、量化策略、评测集和 fallback contract再按目标平台选择 runtime。3.5 产品形态本地模型常常是云端模型的前置层端侧 AI 并不意味着“所有事情都离线完成”。更现实的产品形态是分层本地小模型负责低风险、高频、隐私敏感、低延迟任务云端大模型负责复杂推理、跨文档综合、长链工具执行和高风险输出中间用 policy router 决定是否上传、上传什么摘要、是否需要用户确认。Apple Foundation Models framework 是这种趋势的代表。官方文档把 on-device foundation model 能力开放给应用使开发者可以在设备内调用模型完成文本生成、结构化输出等任务。Apple 研究页也介绍了 Apple Intelligence 的 server 与 on-device foundation language models强调适配设备约束。由于地区、系统版本和 API 可用性变化很快具体调用能力需要以最新开发者文档为准。本地 Agent 还需要权限治理。一个能读剪贴板、邮件、相册、文件和日历的本地模型并不因为“没有上传云端”就天然安全。它需要最小权限、用户可见的工具调用、数据保留策略、可撤销记忆、敏感信息过滤和 prompt injection 防护。端侧 AI 的隐私价值来自系统设计而不是模型位置本身。4. 方法对比表路线代表工作/系统适合场景优势风险与注意点0.5B-4B dense SLMPhi、Qwen3 0.6B/1.7B/4B、Gemma 1B/4B、SmolLM3本地摘要、改写、分类、轻量问答包体小、延迟低、易部署复杂推理和长上下文上限有限小尺寸 MoE/稀疏激活Qwen3 MoE、端侧可变计算设想云边协同、可变算力设备参数效率高能力/成本可调权重加载、路由和内存管理复杂蒸馏小模型Phi-4-mini-reasoning、DeepSeek-R1 distill 类路线数学、代码、格式化任务、垂直领域能把 teacher 行为压到小模型继承 teacher 错误和偏见INT8/INT4 量化GPTQ、AWQ、SmoothQuant、GGUF 量化大多数端侧 LLM 部署降低内存和带宽生态成熟结构化输出、安全边界需重测KV cache 量化/管理KIVI、长上下文 runtime 优化多轮对话、本地 RAG、Agent缓解长上下文内存压力可能影响长程一致性1-bit/极低比特BitNet b1.58、BitNet.cppCPU/低功耗探索、未来硬件协同潜在能耗和带宽收益大生态和模型覆盖仍需实测浏览器/本地运行时WebLLM、MLC LLM、llama.cpp、ExecuTorch、ONNX Runtime GenAI、MLX跨平台本地推理降低云依赖便于隐私场景后端碎片化性能差异大云边协同 routerApple/Google/企业私有架构产品级 AI 助手兼顾隐私、质量和成本策略、权限、日志治理复杂5. 关键技术趋势趋势一小模型家族化。领先模型提供方不再只发布一个最大模型而是同时维护 1B、3B、7B、30B、MoE、端侧多模态等多个点位。产品团队未来选型会更像选择数据库或搜索引擎看生态、license、runtime、更新频率和稳定性而不是只看排行榜。趋势二端侧 AI 走向“任务专用小脑”。一个设备上可能同时存在 intent classifier、隐私过滤器、摘要模型、embedding 模型、视觉编码器、语音模型和云端 router。它们未必共享同一个大模型而是由多个小模型组成 pipeline。趋势三量化格式成为事实接口。GGUF、ONNX、Core ML、ExecuTorch export、MLX checkpoint 等格式会影响模型能否流通。研究论文如果只给 FP16 权重而没有主流量化版本和端侧评测离真实部署还有距离。趋势四NPU/CPU/GPU 后端差异决定体验。设备侧不是一个抽象 GPU 集群。某些 NPU 对特定 op、shape、精度和 batch size 很敏感CPU 可能更稳定但功耗高GPU 可能与 UI 渲染争资源。模型设计必须和 kernel/backend 一起看。趋势五本地记忆和个性化会成为 SLM 的主要卖点。小模型未必能回答世界知识难题但它可以在本地理解用户习惯、文件、日程和上下文。这个能力必须和可删除、可查看、可导出、可隔离的记忆系统一起设计。趋势六评测从通用榜单转向设备回放。一个模型在 MMLU 或 GSM8K 上高几分不一定能在某款手机上低延迟、低功耗、稳定输出 JSON。端侧 AI 更需要固定设备、固定量化、固定 runtime、固定温度和真实任务日志回放。6. 工程落地启发第一从任务定义开始而不是从模型大小开始。先把任务分成本地必做、本地优先、云端优先和禁止自动化四类。比如通知摘要、短文本改写、隐私过滤和简单 intent routing 适合本地跨文档复杂推理、医疗法律建议和高风险决策更适合云端或人工确认。第二为端侧建立独立 eval harness。评测输入应来自真实设备日志的脱敏样本、常见 UI 状态、离线模式、弱网、长对话、低电量和热限制场景。指标至少包括首 token 延迟、tokens/s、峰值内存、能耗、崩溃率、结构化输出有效率、拒答率和云端 fallback 比例。第三不要只评估 FP16 模型。最终产品如果使用 INT4/GGUF/Core ML/ONNX 版本就必须在该版本上评测安全、格式、工具调用、长上下文和多语言表现。量化可能不会显著影响平均分但会破坏边界案例。第四把模型包体和更新机制当作产品问题。移动应用需要考虑首次下载、增量更新、弱网恢复、版本回滚、用户存储空间和地区合规。对于企业内网设备还要考虑模型签名、供应链扫描和离线分发。第五设计明确的 cloud fallback contract。本地模型应该知道什么时候“不确定”“需要更多上下文”“必须请求用户同意上传”。上传给云端的也不一定是原始数据可以是本地抽取的摘要、特征、候选草稿或用户确认后的片段。第六把权限和审计做进 Agent 工具层。本地模型调用日历、文件、相册、剪贴板、浏览器历史和邮件时需要可见的权限边界。Prompt injection 攻击在本地同样存在特别是模型读取网页、PDF、邮件和共享文档时。第七给小模型配“窄而硬”的工具。SLM 在自由生成上可能不如大模型但如果配合模板、schema、检索、规则验证、轻量排序器和有限工具它可以在垂直任务上非常可靠。工程重点是约束输出空间而不是让小模型裸聊。7. 局限与争议小模型不会自动更安全。本地运行降低了数据外传风险但也可能让错误输出更难被服务端监控。安全策略、红队样本、敏感信息检测和权限控制仍然必要。端侧 benchmark 很难横向比较。模型、量化、runtime、设备温度、系统负载、prompt 长度和采样参数都会影响结果。论文或博客中的速度数字往往不可直接迁移到你的产品。压缩会改变模型行为。低比特量化、剪枝、蒸馏和 KV cache 压缩可能只在平均指标上损失很小却在结构化输出、罕见语言、长尾安全请求上出现异常。发布前必须做任务级回归。小模型与云模型的边界会引发隐私争议。用户可能以为“AI 在本地运行”意味着所有数据都不出设备但产品实际可能在复杂请求时调用云端。界面、隐私政策和技术架构需要保持一致。开源权重不等于可商用部署。License、训练数据来源、模型使用条款、专利和第三方 runtime license 都要核验。本文只做技术盘点不构成法律意见。8. 接下来值得关注的问题端侧多模态小模型会不会成为默认入口文本小模型已经可用下一步是本地视觉、语音、屏幕理解和多模态工具调用。可变计算模型能否成熟MatFormer、early exit、speculative decoding 和 dynamic routing 都指向“按任务难度花不同算力”。小模型如何做长期个性化本地 LoRA、adapter、memory store、用户反馈和隐私删除机制可能成为新基础设施。浏览器内 AI 会不会改变 Web 应用架构WebGPU/WebNN 与 WebLLM 类项目让轻量 AI 功能无需服务端推理但也带来模型下载和设备差异问题。端侧 Agent 如何防 prompt injection当本地模型读取邮件、网页和文件并能调用系统工具时安全边界比普通聊天更复杂。1-bit/极低比特路线能否和硬件协同落地如果模型、kernel 和芯片一起优化SLM 的能耗曲线可能出现新的断点。9. 总结Small Language Models 和 On-device AI 的价值不在于证明“小模型也能打败大模型”而在于把 AI 能力放到云端大模型到本地设备之间的完整系统里重新分工。小模型负责快速、私密、低成本、可离线的高频任务大模型负责复杂推理和高风险任务运行时、量化、硬件后端和策略 router 决定这套系统能否稳定工作。对研究者来说值得关注的是小模型架构、蒸馏数据、低比特表示、KV cache 管理和设备级评测。对工程团队来说最务实的路径是从一个高频、低风险、可验证的本地任务开始选一个小模型、一个量化格式、一个 runtime、一个真实设备评测集然后把云端 fallback 和权限治理补齐。只有当这些组件一起被验证小模型才真正从“缩小版 LLM”变成可交付的端侧智能基础设施。参考资料检索日期均为 2026-07-06。模型可用性、官方文档版本、license、benchmark 排名、硬件支持矩阵和 API 区域限制变化较快发布前建议再次人工核验。Microsoft Research. “Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone.” arXiv, 2024. https://arxiv.org/abs/2404.14219Microsoft. “Phi-4-Mini-Reasoning: Exploring the Limits of Small Reasoning Language Models in Math.” arXiv, 2025. https://arxiv.org/abs/2504.21233Meta AI. “Llama 3.2: Revolutionizing edge AI and vision with open, customizable models.” Official blog, 2024-09-25. https://ai.meta.com/blog/llama-3-2-connect-2024-vision-edge-mobile-devices/An Yang et al. “Qwen3 Technical Report.” arXiv, 2025. https://arxiv.org/abs/2505.09388Qwen Team. “Qwen3: Think Deeper, Act Faster.” Official blog, 2025-04-28. https://qwenlm.github.io/blog/qwen3/Google. “Gemma 3: Google’s most capable open AI model.” Official blog, 2025-03-12. https://blog.google/technology/developers/gemma-3/Google AI for Developers. “Gemma 3n model overview.” Official documentation, accessed 2026-07-06. https://ai.google.dev/gemma/docs/gemma-3nGoogle AI for Developers. “Gemma 4 model card.” Official documentation, accessed 2026-07-06. https://ai.google.dev/gemma/docs/core/model_card_4Hugging Face. “SmolLM3: smol, multilingual, long-context reasoner.” Official blog, 2025. https://huggingface.co/blog/smollm3Jianwei Yang et al. “MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases.” arXiv, 2024. https://arxiv.org/abs/2402.14905Han Lab et al. “AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration.” arXiv, 2023. https://arxiv.org/abs/2306.00978Elias Frantar et al. “GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers.” arXiv, 2022. https://arxiv.org/abs/2210.17323Guangxuan Xiao et al. “SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models.” arXiv, 2022. https://arxiv.org/abs/2211.10438Tim Dettmers et al. “QLoRA: Efficient Finetuning of Quantized LLMs.” arXiv, 2023. https://arxiv.org/abs/2305.14314Zirui Liu et al. “KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache.” arXiv, 2024. https://arxiv.org/abs/2402.02750Shuming Ma et al. “The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits.” arXiv, 2024. https://arxiv.org/abs/2402.17764Microsoft Research. “BitNet.cpp: Efficient Edge Inference for Ternary LLMs.” GitHub repository, accessed 2026-07-06. https://github.com/microsoft/BitNetggml-org. “llama.cpp.” GitHub repository, accessed 2026-07-06. https://github.com/ggml-org/llama.cppPyTorch. “ExecuTorch documentation.” Official documentation, accessed 2026-07-06. https://pytorch.org/executorch/stable/Microsoft. “ONNX Runtime GenAI.” Official documentation, accessed 2026-07-06. https://onnxruntime.ai/docs/genai/MLC AI. “MLC LLM documentation.” Official documentation, accessed 2026-07-06. https://llm.mlc.ai/docs/Apple. “Apple Intelligence Foundation Language Models.” Machine Learning Research, accessed 2026-07-06. https://machinelearning.apple.com/research/apple-intelligence-foundation-language-modelsApple Developer Documentation. “Foundation Models framework.” Official documentation, accessed 2026-07-06. https://developer.apple.com/documentation/foundationmodels