为什么远程AI服务让开发者头疼？

几乎所有开发者都厌恶按调用量付费的AI API。在快速迭代的开发阶段，每一次请求都意味着成本，团队常常被账单追着跑。Canonical提出了一种全新思路：让模型直接嵌入到你的应用中，而不是躲在远端的付费接口后面。本文将深入讲解嵌入式AI的核心理念——将本地大语言模型（LLM）推理集成到应用内部，并在NVIDIA DGX Spark上展示实际效果。

当前AI应用的典型架构是“中心辐射”模式：多个应用共同调用一个远程AI服务（如OpenAI、Anthropic、Google Gemini等）。这种服务负责推理、用量计费、速率限制，按token收费。

这种模式确实解决了一个问题——你不需要自己管理GPU基础设施。但它带来了更多麻烦：

• 成本不可预测。每次调用都有边际成本。开发阶段大量探索性请求会让费用迅速累积，常常在中途让团队措手不及。
• 网络延迟。每次远程API往返增加几十到几百毫秒。对于需要多次模型调用的应用（如Agent、RAG流水线、多步推理），延迟积累会严重破坏用户体验。
• 数据隐私。将敏感数据发送给第三方服务，需要信任其数据政策，增加合规复杂性，在受监管行业中甚至被明令禁止。
• 开发到生产的不一致。开发环境往往使用模拟API或不同凭据，导致配置漂移、模拟与实际不匹配、环境行为差异，因为开发中的“AI”和生产中的“AI”根本不是一回事。
• 运维复杂性。轮换API密钥、跨团队管理配额、应对上游故障、理解模型今天与上周行为差异——这些都是远程AI服务固有的问题。

从远程服务到本地推理：嵌入式AI的核心理念

嵌入式AI的思路很简单：将模型及其推理运行时视为应用的本地依赖项，就像你已经在用的软件包一样，而不是远程第三方服务。

传统模式是三个应用共享一个远程端点：

• 应用1 ──┐
• 应用2 ──┤──► AI服务（远程、按量计费、共享）
• 应用3 ──┘

而嵌入式AI模式下，每个应用自包含推理引擎：

• 应用1 + AI（本地、运行时免费、隔离）
• 应用2 + AI（本地、运行时免费、隔离）
• 应用3 + AI（本地、运行时免费、隔离）

这就像当年企业从服务器端数据库转向本地SQLite，或者从共享Redis集群转向进程内缓存一样。问题在于：硬件和打包工具是否已经成熟到让这种模式变得实用？

在2026年，答案是肯定的。

推理Snap：像安装软件包一样部署AI

过去运行本地LLM推理的痛点在于配置复杂：安装NVIDIA CUDA驱动、为GPU显存选择合适量化、配置推理服务器、管理更新。Canonical推出的推理Snap完美解决了这些问题。

一个推理Snap打包了以下内容：

• 模型权重——基于本地硬件优化的格式
• 推理运行时（自动选择llama.cpp、vLLM或其他引擎）
• 硬件特定优化（量化级别、批处理策略、推理引擎选择）
• 标准OpenAI兼容的HTTP API——在本地暴露
• 依赖管理与自动更新——通过Snap商店实现

Snap的引擎管理器在安装时自动检测你的硬件，并选择最适合CPU、GPU或NPU的引擎。你不必手动选择量化，也无须自行安装CUDA工具包。运行一条命令即可：

sudo snap install gemma3

至此，你的机器上就运行了一个本地Gemma 3推理服务器，提供OpenAI兼容的端点，经过硬件优化，并支持自动更新。任何能发起HTTP调用的应用都可以立即使用这个模型。

Snap还提供了内容接口机制，允许其他Snap（即你的应用）通过读取共享的status.json文件获取端点URL：

sudo snap connect demo-app:inference-snap-status gemma3:status

连接完成后，你的应用可以直接读取推理端点的位置，无需任何配置文件或环境变量管理。Snap系统自动处理了底层连接。

参考实现：两个具体的示例

embedded-ai仓库提供了两个实际的例子，它们本身也构建为Snap，因此可以干净地集成到推理Snap生态中。

示例1：简单聊天

第一个例子（_01_simple_chat）极其简约。它展示了核心模式：一个基于Snap打包的Python应用，从Gemma 3 Snap的状态接口读取推理端点，然后将聊天补全结果流式输出到终端。

构建与运行：

# 构建Snap
cd _01_simple_chat && snapcraft pack   # 或: make build

# 安装
sudo snap install demo-app_*.snap --dangerous --devmode

# 连接推理Snap
sudo snap connect demo-app:inference-snap-status gemma3:status

# 运行
demo-app

该应用使用推理Snap暴露的模型流式输出一次聊天补全。由于推理Snap提供了OpenAI兼容API，Python代码看起来与调用api.openai.com的代码几乎一样；唯一的区别是基础URL指向本地主机，且不需要API密钥。模型在你的机器上运行，每次调用的成本只是电费。

这一模式具有重要的架构意义：你的应用代码与具体模型解耦。只需将gemma3替换为其他推理Snap（比如qwen-vl或nemotron-3-nano），重新运行snap connect，你的应用就能零代码修改地切换到新模型上。

示例2：PDF摘要生成器

第二个例子（_02_pdf_summarizer）展示了一个更贴近实际的应用场景：处理文档并使用本地模型生成摘要。

构建与运行：

# 构建Snap
cd _02_pdf_summarizer && snapcraft pack   # 或: make build

# 安装
sudo snap install pdf-summarizer_*.snap --dangerous --devmode

# 连接推理Snap
sudo snap connect pdf-summarizer:inference-snap-status gemma3:status

# 运行摘要（命令略）

这段代码演示了如何读取PDF文档，将其内容传给本地模型，并输出结构化摘要。所有推理都在本地完成，无需联网，数据不会离开机器。

---

关注微信号：智享开源 ，及时了解更新信息。

原文链接：https://ubuntu.com//blog/developing-web-apps-with-local-llm-inference

投稿作者	作者网站

---

请支持IMCN发展！

谁在捐赠

微信捐赠	支付宝捐赠

扫码关注公众号：智享开源