做端侧 AI 应用，绝不等于强行跑大模型

【端侧 AI 实践】如何在 20MB 包体积限制下实现小程序的实时AR 视觉与 VLM 场景理解在构建基于 AI 的摄影辅助小程序时我们面临了一个非常经典且棘手的端侧 AI 架构矛盾。理想情况下我们希望通过视觉大模型VLM实时分析手机镜头的画面直接在屏幕上叠加高精度的 AR 构图引导。但在真实的工程落地中我们立刻撞上了系统瓶颈小程序平台的资源和性能限制。最大的痛点就在于设备的算力与包体积硬约束“Constraint: WMP cannot run Gemini Nano/MiniCPM-V locally (too large for 2MB/20MB limit and JS sandbox performance).”小程序无法在本地运行 Gemini Nano 或 MiniCPM-V 这样的大模型。无论是 2MB/20MB 的包体积限制还是 JS 沙盒的性能瓶颈都完全无法支撑。既然端侧跑不动 VLM那么把每一帧画面都传到云端做实时分析可行吗答案也是否定的。高帧率60fps的视频流不仅会带来难以忍受的云端带宽和算力成本几十毫秒甚至上百毫秒的网络延迟也会直接摧毁 AR 实景叠加的跟手性导致画面与引导线完全脱节。这就逼迫我们做出了一个核心架构折衷将 60fps 的实时渲染与低频的场景语义理解在物理层面上强行剥离开来。我们在架构设计上明确了端云协同的分工边界“Use client-side lightweight heuristics (OpenCV.js for WMP or simple geometric checks) for real-time feedback (lines, grids), only use VLM for ‘Scene Understanding’ trigger.”我们的解决方案是使用客户端轻量级启发式算法如适用于小程序的 OpenCV.js 或简单的几何检查来提供实时的线条、网格反馈仅仅将 VLM 用于’场景理解’的触发器。具体的架构落地方式如下1. 端侧轻量级 Math/Geometric 引擎负责极速实时反馈在小程序端我们通过原生的camera组件获取高性能视频流并利用z-index在其上叠加canvas type2d或基于 WebGL如three-platformize适配层作为 AR 渲染层。所有高频的实时反馈比如三分法网格、黄金螺旋构图引导、甚至是基于简单特征追踪的动态指示箭头全部通过纯数学和几何运算在端侧 JS 本地以 60fps 闭环完成。2. 云端低频 VLM 分析负责重度语义理解只有当系统需要真正看懂当前画面比如评估画面主体、进行拍照后打分或识别特定复杂场景时端侧才会截取一帧低分辨率图片通过 Serverless 云函数发送至后端的 Gemini Pro Vision 等云端 API 进行推理并返回场景的 Context 标签。正如我们在内部系统评审时向开发团队强调的那样“The flow will imply a network latency for ‘Scene Understanding’. Real-time AR guides (spirals, grids) will be local math-based.”这一流程必然意味着’场景理解’环节会存在网络延迟但实时的 AR 引导如黄金螺旋、网格将完全基于本地纯数学算法来保证流畅度。工程复盘与反直觉思考这种 Edge-Cloud Split云端分离的设计在实际落地中带来了超出预期的工程收益彻底突破了沙盒限制我们完全放弃了把几百 MB 到几 GB 权重塞进小程序的妄想直接绕过了小程序的包体积和内存红线。视觉体验不降级因为 AR 线条和构图提示是通过几何算法在端侧每秒计算 60 次视觉反馈极其丝滑而网络延迟被巧妙地掩盖在了相对低频的场景评估或打分环节在交互设计上用户是完全能够包容这种异步等待的。算力成本数量级下降避免了对视频流的逐帧大模型推理极大程度降低了 VLM 的 API 调用频次和 Token 消耗。在现阶段端侧大模型算力和内存尚未完全普及的情况下做端侧 AI 应用绝不等于强行在端侧跑大模型。相反用廉价且极速的经典算法甚至纯数学运算去扛 99% 的高频即时交互把宝贵而昂贵的 LLM 算力留给那 1% 需要真正智能的关键决策点这或许是当下算力受限时最具可行性的折衷方案。