这两年在端侧设备上跑AI模型已经从新鲜事变成了很多产品的默认姿势尤其是教育类工具家长的手机里动辄躺着一堆拍照搜题、作文批改、口语评测的App。但一直在云端跑模型的产品一旦碰到“高并发”“隐私”“离线”这几个字就很容易露馅。我自己做的这个小项目就是围绕“错题辅导”这个具体场景尝试把整套AI能力尽量压到端侧从题目拍照识别、知识点归类再到讲解生成和错题重练全流程不依赖网络也能跑。这篇文章把架构选型、模型选配、端侧推理的调优思路和踩坑经验全部整理出来给准备做本地AI小程序或端侧推理项目的朋友一个可落地的参考。这个项目适合这几类人看想给自己的工具类小程序加AI功能、但不想被云端推理成本绑架的开发者正在做教育硬件或学习类App、需要离线辅导能力的团队以及对端侧模型量化、推理引擎接入感兴趣、想了解实际工程落地细节的算法工程师。接下来的内容不聊PPT式的概念只谈真实代码和流程里会遇到的问题。1. 方案设计与核心决策为什么把推理放到端侧1.1 场景痛点与边界分析错题辅导这个场景有几个很典型的特点决定了它天然适合端侧推理。第一个痛点是私密性。学生的作业、考卷、错题本属于非常敏感的数据。拍照上传到云端做OCR识别和题目分析很多家长是不放心的尤其是校内试卷和作业内容家长会担心数据被留存、被用于训练模型。把识别、分析、讲解全部放在本地从物理层面解决了“数据上传”这个心理门槛。第二个痛点是稳定性。传统拍照搜题类产品的体验依赖云端接口晚上作业高峰期并发上去以后经常出现响应慢、超时。端侧推理没有服务器带宽压力模型在手机本地跑时延只取决于用户手机的芯片性能晚上八点到十点的体验和凌晨两点没有区别。第三个痛点是离线可用。不少学生用户会在图书馆、地铁上、甚至没有信号的场所学习。云端方案在无网环境下直接瘫痪端侧方案则完全不受影响。除了这三点从成本角度算一笔账也很划算。如果所有请求都走云端大模型GPT级别的推理成本甚至高于用户的付费定价。而端侧模型的推理成本是零边际成本。正因为这些都是这个场景与生俱来的需求架构上选择“本地优先”就不是情怀问题是数学题。1.2 端侧推理与云端推理的取舍做端侧推理不等于彻底抛弃云端而是要看清楚边界。我的整体设计是“端侧为主云端兜底”但兜底只解决 5% 的极端需求。端侧做哪些事题目拍照后的OCR文字识别、错题的知识点标签分类、题目难易度评估、解析讲解生成、相似题编排。这些功能全部走本地模型关闭网络也能完成核心学习闭环。云端做哪些事模型热更新、跨设备的错题云同步、新题型数据的离线包下载。这个逻辑很简单数据计算不出去数据存储可以出去。用户把错题同步到云端是为了换设备时恢复数据而非为了让我方服务器去识别他的题目。从技术实现角度看端侧推理要面对的现实约束有三个内存、算力、功耗。小程序运行环境的承载能力比原生App更弱这就逼着你在模型选型上必须克制能跑0.5B参数的模型就不要用1B参数的能复用缓存就不重新计算。这个取舍贯穿了整个项目的始终。2. 端侧模型选型与算法流程拆解2.1 错题录入到解析生成的完整流水线整个错题辅导小程序的核心链路可以拆成五个环节图像预处理、文字识别、题目结构化、标签分类、讲解生成。每一步都有一个对应的端侧模型或算法模块。图像预处理不是模型但对识别效果的影响最大。试卷拍照经常遇到的问题包括倾斜、过暗、遮挡、手指入镜。我的做法是先用一个轻量级的图像方向分类模型判断图片是否需要旋转再做透视矫正最后用自适应阈值做图像增强。这一步做好了后端的OCR模型错误率能下降一大截。文字识别用的是某开源OCR模型的轻量版。这个模型的特点是参数量小、识别速度快在手机CPU上单张试卷的识别耗时控制在300毫秒以内足够满足交互需求。识别结果是带坐标的文本块我会把文本块按照题目序号重新组合把一道题从题干到选项、从选项到解答完整拼接起来。这一步看起来简单实际操作上要处理“题号识别”“栏目切分”“跨页拼接”等问题是工程里最容易出bug的地方。题目结构化之后进入分类阶段。这里我用了一个参数量很小的文本分类模型输入是题干和选项的文字内容输出是预先定义好的知识点标签和难度等级。标签体系我维护了一套分层的知识图谱第一层是学科第二层是章节第三层是具体知识点。分类模型只做第三层的细分类前两层通过规则字典过滤。这样既控制模型复杂度又保证分类准确率。2.2 模型轻量化的三个关键手段端侧跑模型最先要解决的问题就是模型太大。原始模型的体积通常以GB计手机小程序根本吃不消。我主要用了三个手段来压缩模型体积。第一个是量化。把浮点参数从FP32压到INT8模型体积直接缩到四分之一推理速度能提升两到三倍。实际测试时INT8量化对OCR和文本分类任务的影响很小准确率下降基本在0.5%以内。量化分为训练后量化和量化感知训练两种。前者简单粗暴直接用一批校准数据算出量化参数后者在训练阶段就模拟量化误差效果更好但需要重训模型。对这个小项目来说训练后量化已经足够。第二个是裁剪。把模型中贡献较小的通道或注意力头直接删掉。以文本分类模型为例原始的注意力头是12个裁剪到8个后准确率几乎没有变化但推理速度提升了15%左右。裁剪需要依赖结构化剪枝框架重点是不能手工乱删否则模型参数错位后会出现诡异的加载错误。第三个是蒸馏。用一个参数量较大的“教师模型”指导一个小“学生模型”学习。教师模型的输出概率分布比硬标签包含更多信息学生模型学到的决策边界更平滑。蒸馏后的小模型在同样参数量下准确率能比直接训练高2到3个百分点。这三个手段叠加以后我的OCR模型从原始的90MB压到12MB文本分类模型从50MB压到5MB讲解生成模型则选择了一个本身就小于1B参数的开源小模型再用GGUF格式做4-bit量化最终体积控制在300MB以内。2.3 规则引擎兜底与生成式讲解的配合很多人以为讲解生成一定得靠大模型实际操作中我发现直接让大模型从头到尾生成解析经常出现三种问题知识点讲错、步骤缺失、表述过于抽象学生看不懂。我的做法是“规则模板兜底、大模型润色”。题库里有大量典型题型我提前整理了一套知识点讲解模板库模板里嵌入了题目的具体数字和关键步骤。规则引擎先根据分类结果匹配到模板把标准答案、关键公式填进去。只有模板库覆盖不到的创新题、综合题才交给端侧大模型生成自由文本。最后我会专门用一个短文本改写模型把模板产出的内容润色成更口语化的讲解贴合学生的理解水平。这种组合的好处非常直观核心知识点讲解可控、稳定、不胡说八道同时保留处理长尾题型的能力。如果完全依赖大模型一次推理要消耗的电量和内存都不低有模板兜底日常练习的绝大多数题目都是规则引擎直接出结果大模型只处理少数疑难杂症功耗和延迟都近一步下降。3. 端侧推理引擎的接入与性能调优3.1 推理引擎选型与运行环境评估模型选好之后接下来要选推理引擎。所谓推理引擎就是加载模型并执行计算任务的底层库。当前主流的端侧推理引擎有好几个方向我根据自己的实际情况做了对比。我选的推理引擎需要同时满足这几个条件支持INT8量化模型、支持多线程CPU推理、支持GPU/Metal/NPU等硬件加速接口、包体积尽量小、社区活跃度足够高。有的引擎的C接口性能很好但包体积太大有的引擎适配了各种硬件但WASM环境下支持不全。最终我基于性能和包体积的综合平衡选择了某个开源推理引擎的预览版本。实际运行环境的评估也很重要。小程序目前的主流运行方式有两种一种是纯WebView技术栈所有计算逻辑通过WASM执行另一种是原生小程序框架可以通过官方插件机制调用原生代码库。我采用的是原生插件方案因为WASM在计算密集型任务上的性能还是明显弱于原生二进制尤其对OCR这种需要扫描大量像素的任务。原生插件让推理库直接运行在手机CPU上调度效率完全不同。选型时我拉了一张性能对比表量化模型在CPU和GPU上的表现差距很明显。深度可分离卷积这类算子GPU提升能到5倍但小模型、需要频繁拉起推理请求的场景GPU初始化开销反而会让整体时延变高。最终我决定对OCR图像处理任务走GPU对短文本分类和讲解生成走CPU。3.2 端侧性能调优的实操手段端侧模型跑起来以后性能调优才是真正花时间的部分。我记录了几个对时延影响最大的优化点。第一个是内存复用。每次拍照识别都要申请几百MB的输入输出内存如果不做复用频繁触达垃圾回收机制会带来明显的卡顿。我把输入图像缓冲区、中间特征图缓冲区、输出文本缓冲区统一做成内存池一次申请多次复用。这个小改动让连续识别一张试卷的耗时下降了20%。第二个是线程配置。多线程推理能大幅提升速度但线程数并非越大越好。手机上还有UI渲染、网络请求等其他任务在抢CPU资源线程数过多会导致CPU频率波动反而拖慢整体响应。我为不同任务设置了不同的线程数OCR用4线程文本分类用2线程讲解生成用2线程。经过真机对比这个组合在性能和功耗上最平衡。第三个是算子融合。推理引擎里有很多相邻的算子可以合并成一个算子执行比如卷积层后面的批归一化和激活函数层。算子融合减少了中间数据的读写次数加速比常能达到30%。我通过引擎的图优化配置打开了算子融合开关在模型加载阶段完成计算图优化推理时就不再重复处理。第四个是预热与常驻。第一次调用模型推理时操作系统要加载模型文件到内存、初始化算子库、分配显存这个过程可能长达一两秒。用户等不了。我的做法是在小程序首页完成初始化后立刻在后台加载全部模型并做一次空推理预热让用户真正拍照时模型已经处于就绪状态。3.3 冷启动、内存与耗电控制端侧模型最容易被人忽略的问题是冷启动和功耗。模型文件本身几百MB打进小程序包里完全不现实。我的方案是首次启动时从CDN下载模型文件并缓存到本地后续启动直接读取缓存。下载过程做断点续传和校验避免模型文件损坏导致推理异常。冷启动的另一个策略是分级加载。OCR模型体积小、加载快默认第一时间载入讲解生成模型体积大放在用户真正触发讲解功能时再懒加载。这样大部分用户只做拍照识别和标签分类时根本不需要加载最大的模型文件启动速度和内存占用都更友好。能耗控制主要靠降低无效计算。手机上跑模型时发热和掉电如果太夸张用户会直接卸载应用。我采用了两个控制策略单个任务结束后立刻释放计算资源不能在后台空转推理时限制CPU最高频率牺牲一点速度换取温控稳定。实测连续识别十张试卷后手机背面温度保持在微温状态不至于烫手。4. 实操过程从代码骨架到完整Demo落地4.1 项目结构与核心模块划分整个项目虽然是“小程序”但为了端侧推理的效率和工程维护的整洁我把它拆成了三个技术栈小程序前端、原生推理插件、模型仓库。小程序前端负责交互界面、错题展示、学习报告和设置页面这一层与常规小程序开发没有区别。原生推理插件是核心由C编写推理逻辑通过插件桥接给前端调用。模型仓库独立维护存放量化后的模型文件和标签字典跟随版本更新做增量下发。前端调用插件时传入图片的本地路径插件内部完成图像预处理、OCR识别、文本分类和讲解生成最后返回统一的JSON结构。这个JSON就是前端的渲染数据源。模型文件默认放在应用的私有目录不会暴露给用户直接访问。这个架构最大的好处是职责清晰。模型升级不用重发前端包只需要更新模型仓库版本前端性能问题和推理性能问题可以分开排查。模块划分越清楚后面调优越不费劲。4.2 关键实现步骤与数据链路下面以一次完整的“拍照录入错题”为例走一遍关键实现步骤。第一步是拍照。前端调用系统相机拍完的图片压缩到最大2000像素边控制单张图片体积在2MB以内。压缩比太大会损失文字清晰度影响OCR效果压缩比太小则加载和推理都变慢。这个平衡是反复测试出来的。第二步是图像预处理。插件接收到图片后先判断亮度是否低于阈值低于阈值则做亮度提升和对比度拉伸。然后检测图片的倾斜角度通过透视变换拉正。预处理完的图像传给OCR模型。第三步是OCR识别。OCR模型输出每个文本块的内容和坐标。我把输出按题号重新拼装用正则表达式匹配题号模式比如“1.”“(2)”等并按照页面上的坐标顺序排序。这一阶段会输出题目结构树。第四步是标签分类。把结构树中的题干文本截断到256个token以内送入文本分类模型得到知识点标签和难度等级。对应知识点的讲解模板从模板库中选中填好具体数值生成基础解析。第五步是讲解生成。如果题目匹配不到模板则调用端侧大模型生成解析。生成过程设置了三个约束最大输出长度256 token、温度0.6、禁止重复同样的知识点错误。生成的文本再经过敏感词过滤和标点矫正确保输出规范。第六步是把所有信息写入本地错题数据库。数据库记录题目图像、OCR文本、知识点标签、解析内容和掌握状态。用户之后查看错题本、复习错题时直接读取数据库不需要每次都跑模型。4.3 评测指标与验收标准端侧AI产品光凭感觉调优是不行的必须建立可量化的评测体系。我设计了四个核心指标。第一个是单题识别耗时。从用户点击拍照到看到解析结果端到端时间目标控制在2秒以内。拆解下来OCR识别300毫秒文本分类50毫秒讲解生成500毫秒剩下的时间被图像预处理和前后端通信消耗。第二个是OCR准确率。我用标注好的500张试卷图像做了评测字级准确率达到94.2%。这个数字看起来不高但试卷图像存在大量手写批注、印刷体模糊、公式特殊符号等干扰能到这个水平已经具备可用性。第三个是知识点分类准确率。对1000道已标注题目的正确率是91.5%错误集中在学科交叉的知识点比如物理题里涉及数学比例计算的场景。这类错误通过规则层做了兜底修正。第四个是讲解生成通过率。我组织了5名中学生实际使用了两周回收了他们对讲解内容的评分。平均4.2分满分5分主要扣分点是部分综合题的讲解仍显生硬。这一块后续靠补充模板库和优化生成提示词来改善。验收标准定完之后性能回归测试就变得很机械。每次更新模型或调整推理参数我都会跑一遍同样的测试集记录四项指标的波动任何一项明显回退都不会发布。5. 常见问题与排查技巧实录5.1 典型问题与根因排查端侧推理项目坑很多我挑几个自己真实遇到的问题分享。第一个坑是模型加载偶发崩溃。现象是用户反馈App闪退排查发现崩溃发生在模型加载阶段报错信息指向内存分配失败。原因是小程序的运行内存有限同时加载OCR模型和讲解生成模型超过了内存阈值。解决方案是改成懒加载OCR和分类模型打开即加载讲解生成模型等用户点了“查看详细讲解”再加载。这之后崩溃率几乎归零。第二个坑是OCR识别结果乱序。现象是同一张试卷图片有时识别顺序从上到下正常有时左右两栏交错乱序。根因是OCR模型输出的文本块坐标排序逻辑不够健壮我用了一个多级排序策略先按区块分组再按每区块内部Y坐标从上到下、X坐标从左到右排序。同类问题还出现在多栏排版试卷的题目拼接上。第三个坑是讲解生成模型输出过慢。端侧大模型虽然能跑但每生成200个token在低端手机上要跑到4秒以上。我尝试了几个方向最终把最大输出长度限制到128个token同时启用KV Cache缓存历史隐状态生成速度提升了一倍用户可感知的内容质量并没有明显下降。另一个常见的隐蔽问题是模型文件校验。下载模型时不小心用了HTTP明文传输中间被篡改或损坏导致运行时全部报错。我后来在模型加载前用配置文件里的哈希值强制校验任何一个文件的摘要对不上就拒绝加载并触发重新下载。5.2 端侧推理避坑清单我整理了一份端侧推理避坑清单方便后来者少走弯路。模型文件尽量用独立仓库管理不要和前端代码绑在一起发版否则每次模型迭代都要走一次构建发布流程效率太低。量化校准数据要覆盖真实场景。我第一版用纯印刷体文档做校准导致实际拍试卷、屏幕亮暗不均时识别率明显下降。后来改用真实手机拍摄的试卷照片做校准数据效果立刻好起来。文本分类模型要限制输入长度。直接塞入超长文本会显著拉长推理时间必须在送入模型前做好截断和关键信息保留。讲解生成必须设置超时和重试机制。端侧模型偶发卡死并不罕见超时后要先降级到规则引擎结果而非一直转圈。端侧模型版本要与推理引擎版本严格匹配。换模型后出现不明原因的推理异常先想想是不是引擎版本不兼容导致的。5.3 第二次迭代考虑的方向当前版本跑通以后我在规划第二轮迭代时留了几个扩展方向供参考。第一个方向是增加语音讲解。端侧有了文本生成能力再接一个轻量语音合成模型让学生听完讲解再自己复述一遍学习闭环更好。语音模型同样可以量化压缩到很小的体积。第二个方向是增加手写识别。错题里的手写批改、手写答案非常常见目前OCR对印刷体识别效果好对手写体明显弱一些。接入手写识别模型后错题录入的覆盖范围会大大提高。第三个方向是加入间隔复习算法。现在错题只是被记录下来什么时候推送复习还比较粗暴。我打算在端侧实现一套轻量的间隔重复算法根据用户的答题正确率和复习时间自动调整题目出现频率实现个性化训练。第四个方向是模型在线联邦微调。在保护隐私的前提下把用户在端侧的答题结果抽象成梯度或统计信号用于后续模型版本的迭代优化。这个方向会更复杂但教育类产品的数据飞轮很值钱有条件值得做。最后说点动手做过才知道的事这个项目做下来我最深的体会是端侧推理的难点从来不是“模型能不能跑”而是“在有限资源里跑得又快又稳又省”。模型再先进加载时间三秒、回答时间五秒用户照样不会用。很多优化手段看起来不酷比如内存池复用、线程数调参、输入长度截断但正是这些琐碎细节决定了端到端的体验。如果你正准备做类似项目我的建议是先明确一个最低可用的性能指标把架构和流程跑通再去优化单个模型的准确率。端侧AI项目的试错成本比较高每次改模型都要重新做量化、实测、回归节奏控制不住很容易陷在细节里。另外一个很重要的心得是规则引擎和传统算法不要急着丢。端侧推理和小模型配合成熟的规则逻辑效果比纯大模型方案更稳定也更容易解释。AI在做端侧落地时真正重要的不是追求最聪明的模型而是找到最合适的那条路径。希望这篇复盘能帮你在自己的项目里少踩几个坑。