一句话看懂：一位开发者用微信小程序做“电子病例夹”，本地跑 Qwen2.5-VL 3B 识别病历照片，单张推理 40-60 秒，正撞上 wx.request 的 60 秒硬上限；他的解法是异步任务加轮询，并给出多引擎热切换、TC3 签名、模型预热等落地细节。
事件核心：发生了什么
2026 年 10 月底，掘金作者“小小善后师”记录了一个个人项目：前端为微信小程序原生开发，四个页面；后端只用 Node.js 内置模块，零第三方依赖。AI 识别部分支持三种引擎热切换——本地 Ollama 跑 Qwen2.5-VL 3B（量化后约 3.2GB）、腾讯云 OCR、OpenAI 兼容接口。作者实测纯 CPU 推理单张病历照片约 40-60 秒，而小程序 wx.request 上限是 60 秒，同步等待会直接报“网络异常”。目前公开信息显示，这是一个个人项目，并非已上线产品。
为什么重要
这暴露了 AI 应用落地的常见错配：推理时长由算力和模型决定，客户端请求窗口却是平台写死的。作者的核心判断是：长耗时 AI 任务 + 受限客户端，答案是异步化，而不是把 timeout 调大。他让后端先返回 jobId（HTTP 202），推理放到内存 Map 任务队列后台执行，客户端每 1.2 秒轮询，进度层层透传给 UI——40 秒等待从“疑似卡死”变成“可感知过程”。此外，用 Provider 模式统一 {result, error} 返回结构、通过健康检查接口暴露“未配置/模型未装/正常”三种状态，这类设计对任何接入多模型的 AI 应用都有参考价值。
对用户/开发者/创作者的影响
对开发者，可直接借鉴三点：轮询间隔由服务端下发（pollAfterMs），便于按负载调速；内存任务队列设上限和超时淘汰，个人项目不必上 Redis；Ollama 冷启动约 50 秒，且纯文本预热不会加载视觉编码器，需发一张 1×1 像素 PNG 触发完整视觉链路，作者称预热后可降到约 6 秒。数据不出家门、零 API 成本是本地模型的吸引力，但代价就是延迟。对用户，医疗影像是否上云仍是取舍问题。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
观察点包括：本地视觉大模型在小程序这类受限环境里是否有更成熟的异步方案；云 OCR 与本地模型混合路由能否成为默认设计；以及微信是否会调整请求超时策略。目前这些数据均来自作者单机实测，尚不代表普遍性能水平。
来源：juejin
