引言
客户端 AI 推理正从「能不能跑」进入「怎么跑好」的工程化阶段。本文基于我们为某工业检测客户交付的真实项目——在 Windows 10 工控机上跑通 Electron + llama.cpp 本地推理——拆解技术选型、性能踩坑与离线场景适配的完整路径。
三条技术路线对比
客户端 AI 应用当前有三条主流路线：
- 纯云端 API：调用远程大模型接口，开发快但延迟不可控，断网即不可用。
- Chromium 壳 + ONNX / llama.cpp 本地推理：安装包较大但离线可用，生态成熟。
- Tauri + Rust 原生推理：体积小、内存省，但 Rust 生态对模型推理的支持仍不成熟。
我们为某工业检测客户选的第二条——基于 Chromium 的桌面壳 + llama.cpp 绑定 + WebWorker 隔离，模型量化到 4GB，在老旧 Win10 工控机上稳定跑通。
三个关键踩坑
- 主进程阻塞 → UI 冻结：桌面壳主进程推理会锁死 UI。方案是将推理移到隐藏 renderer 进程，通过 IPC 通信。
- 模型首次加载 8 秒白屏：加骨架屏 + 流式 token 输出，用户感知等待降到 2 秒以内。
- Windows 7 兼容性：C++ 推理引擎部分指令在 Win7 不可用，最终与客户协商放弃旧系统支持。
离线场景适配
核心架构：断网时本地推理，联网后增量同步到云端知识库。本地 SQLite 存推理日志，联网时通过 CRDT 合并到服务端 PostgreSQL。
性能基准与反面教训
i5-12400 上 7B 量化模型：首 token 延迟 1.2s，生成速度 18 token/s，内存峰值 3.7GB——工控机场景完全可用。
反面教训：最初用 Python + PyInstaller 打包 exe，体积 2.1GB、冷启动 30 秒，用户无法接受。转向 Chromium 壳 + 原生 C++ 绑定后，安装包缩到 350MB，启动 4 秒。
关键洞察
- 行业拐点：本地 AI 推理正在从试验走向规模化交付，头部团队已形成可复用工程模板。
- 技术选型：按「业务复杂度 × 团队规模」评估，避免盲目追新。
- 落地路径：先 PoC 验证关键假设，再用 2-4 周做生产化集成。
- 成本结构：模型推理 + 工程交付 + 运维占比约 4:4:2，预算别全押模型。
- 风险控制：质量门禁、回滚、可观测性必须 day-1 就上。
实战建议
计划在 2026 年落地客户端 AI 的团队，建议从三条主线推进：
- 架构清晰：画出端到端调用链路，标清每段 latency / cost / 错误率
- 数据闭环：从第一天就埋点收集真实使用数据
- 持续演进：每 2 周一次 retro，根据反馈调优先级，避免大版本梭哈
FAQ
Q1：客户端 AI 推理项目的最小投入是多少？
A：PoC 阶段 2-4 周、3-5 人核心团队，预算 30-50 万；上线后月运维成本约为研发投入的 15%。
Q2：AI 推理应用跟传统软件开发的最大区别是什么？
A：核心差异在「不确定性」——模型输出非确定，质量门禁、灰度策略、回滚机制比代码更重要。
Q3：选自研还是用现成 SaaS？
A：涉及客户数据或行业知识库的核心流程自研值得；通用对话等场景直接用 SaaS 性价比更高。
总结
客户端 AI 推理已过「是否要做」阶段，进入「怎么做对」阶段。找一个有真实 AI 工程经验的合作伙伴，比自己摸索 6 个月省 70% 的踩坑成本。如果你的团队在评估相关项目，欢迎直接联系我们，或参考更多落地案例了解已交付项目的真实数据。