AI 推理采用本地 + Serverless 混合架构：让敏感数据不出户，算力成本更低

每一个 AI 开发团队最终都会面临同样的抉择：是自己托管 AI 推理业务------购买或租用 GPU，承担繁重的运维成本，眼睁睁看着它们在没有请求的空闲时段白白烧钱；还是完全依赖云端推理 API------虽然启动极快，但每次调用都要付费，数据必须离开本地边界，而且还会被供应商支持的模型生态深度绑定。

大多数架构讨论都将此视为非黑即目的二选一。然而事实并非如此。最优雅的解法往往不在两个极端之间：你应该在工作负载内部划一条清晰的界线，将一部分推理任务留给现有的本地硬件，而将剩下的部分以 Serverless（无服务器）方式托管到云端。关键在于如何明确这条界线------而这个决策其实比想象中更有章可循。

本文将以一个实际运行的项目为主线：一个语音转英文的翻译工具。它在本地运行自动语音识别（ASR），并在 DigitalOcean 的 Serverless 推理平台上完成翻译。这个演示项目是完全真实的，且已在 GitHub 上开源。不过，工具只是载体，并非核心。我们重点探讨的是一种可复用的架构方案，帮助你判断 AI 推理工作中哪些部分适合留在本地，哪些部分应该放上云端，而且还能帮你降低成本。

本项目的GitHub地址：github.com/Jameshskelt...

一张图看懂该模式

以下是整个系统的架构设计，而非代码层面的逻辑：

[ 本地硬件 ]              [ DIGITALOCEAN SERVERLESS ]
音频输入      →   Nemotron ASR 模型   →   转写文本   →   Nemotron 翻译   →   英文文本
（麦克风/文件）    本地设备 (MPS/CPU)       （纯文本）      nemotron-3-nano-omni

两步推理，运行在两个截然不同的环境。语音识别在用户的本地机器上完成。转写出的纯文本（不含任何音频数据）通过网络发送给 DigitalOcean，由云端规模更大的语言模型完成翻译，最终返回英文文本结果。

其底层原则听起来很简单，却极易被误用：原则是应根据工作负载的特征来划分架构，而非图一时方便。 将所有任务堆在一个地方运行确实更省事，但更合理的做法是让每个阶段各得其所，运行在最符合其最佳性价比和约束条件的环境中。本文接下来的内容将帮助你掌握这种判断方法。

应该本地运行推理，还是使用 Serverless？

核心原则很简单：如果某个阶段的输入数据高度敏感，或者触发频率极高，应优先考虑本地运行；如果模型体量过大、托管成本高昂，或者业务调用呈突发性、偶尔才发生，则更适合采用 Serverless 方式。这一条规则基本能覆盖绝大多数场景------接下来我们深入探讨如何理性地应用它。

在评估一个推理步骤应该留在本地还是走向 Serverless 时，以下四个维度几乎决定了所有的架构走向。你可以将流水线中的每个阶段逐一对照：

维度	倾向于选择本地运行	倾向于选择Serverless
隐私 / 数据驻留	原始敏感输入，不应离开设备	已完成脱敏、可安全传输的数据
成本形态	高频触发、每轮会话需持续运行	突发性、偶发性请求------按量计费更划算
运维负担	本地硬件即可轻松驾驭的小型模型	宁愿直接消费、不想自行托管的大型模型
能力获取	本地现有的硬件算力已足够支持	需要免预置、即开即用的托管模型

我们可以看看上述翻译项目是如何像公式一样套用这个评估框架的：

隐私维度。 音频是最敏感的输入类型之一------它包含了声纹、身份，甚至往往携带了位置和情绪信息。在这套方案中，原始音频永远不会离开本地设备，只有转写后的文本才会通过网络传输。当然，这并不意味着数据流绝对零风险------转写文本中仍可能包含个人敏感信息（PII）。如果业务场景有严格要求，应在数据离设备前对其进行脱敏。但这已经极大地收敛了传输内容的边界：最原始、最具身份特征的信息（声纹）被彻底阻断在网络之外。在一次典型运行中，离开设备的原始音频为零字节；2.65 MB 的录音文件在本地处理完毕后，仅有 883 字节的转写文本被发送出去------相比直接传输原始音频所需的 3.7 MB，网络载荷暴跌了 99.98%。对于涉及合规或高敏感输入的工作负载，这种可审计的风险降级极具实操价值，面临的审计压力也会小得多。

成本构成。 用户说话时，ASR（语音识别）需要持续运行，属于典型的高频交互。如果为这种高频触发的操作对接到商业 API，调用费用会迅速滚雪球。而将 ASR 放在已有硬件上运行，其边际成本几乎为零。相反，翻译是一个突发性步骤：每说一句话才触发一次，频率低且每次都是结构清晰的文本块。这正是 Serverless "按量付费"大显身手的场景，远比让一台 GPU 服务器 7x24 小时待机更经济。在同一次运行中，单次翻译按 Token 费率折算仅需约 $0.0006（也就是说 1 美元可以处理约 1600 次对话），而音频端的本地调用成本为零。（关于 Serverless 推理的延迟与成本表现，可以参考我们的 LLM 推理基准测试报告。）

运维负担。 本地运行的 ASR 模型体量很小（nvidia/nemotron-3.5-asr-streaming-0.6b，参数量远低于 10 亿）。这种规模的模型在消费级硬件（包括 Apple Silicon）上运行毫无压力，几乎没有维护成本。而翻译模型则是典型的"宁愿消费、不想拥有"资产：你不会想去处理它的下载、版本管理、安全补丁，更不想小心翼翼地维护一台全天候加载该模型的服务器。Serverless 帮你抹平了所有的运维底座。

能力获取。 这是开发者和决策者最能直接感受到的痛点。使用 Serverless 推理意味着没有 GPU 采购周期、无需繁琐的初始化配置、不用编写复杂的弹性扩缩容策略。你只需要一个托管模型和 API 端点，从零到上线往往只需几分钟。对于那些不需要深度定制的阶段，直接"租用"能力远比"自建"更有吸引力。

需要明确的是，这个框架并非出于某种非理性的意识形态。我们并不是在盲目宣扬"本地一定好"或"云端一定对"。这条边界的划分，完全是对每个阶段诚实回答上述四个具体问题后的自然结果。只要务实地评估，架构往往会自我演进出最佳形态。

当客观约束帮你做决定

上述方案并非最初的设计。之所以演进成现在的模样，其中折射出的原因非常值得剖析。最初的计划其实是直接 将音频发送到 DigitalOcean 的 nemotron-3-nano-omni（多模态模型），让云端在一次调用中同时搞定转写和翻译。那样的架构图更简洁，移动组件也更少。

但在实际测试中碰了壁。音频数据确实到达了 DigitalOcean，但模型返回的结果却像完全没有收到音频一样。最可能的解释是，Serverless 网关当时没有正确转发音频切片，或者它需要某种未公开的载荷格式，而该项目当时未能成功适配。

面对这种技术撞墙，通常有两种应对方式：一是花上整个 Sprint 的时间去逆向工程这个黑盒网关的载荷格式；二是反思这个约束是否暗示了更好的设计？事实证明，第二种思路带来了意外的收获。将 ASR 移到本地不仅绕过了网关限制，反而催生了更健壮的架构：敏感音频足不出户，高频调用成本归零。约束反而倒逼了系统的优化。

这个经验完全可以外推。混合架构的边界往往是在实践中被发现 的，而非闭门造车预设出来的。那些迫使你将任务推回本地的硬件或网络约束，往往会让最终的系统变得更稳健，而非更糟糕。在设计你的技术评估流程时，应尽可能让这些限制尽早、低成本地暴露出来。例如在这个演示项目中，我们专门保留了一个 Audio Probe（音频探针）诊断标签页，就是为了让团队能够独立验证网关行为，而不是盲目相信书面理论上的架构边界。

最小可行性代码证明

不需要堆砌完整的业务实现，只需两段核心代码，就足以证明这种模式的工程可行性。

第一段是 Serverless 调用。它的亮点恰恰在于其"普通"：

from openai import OpenAI

client = OpenAI(
    base_url="https://inference.do-ai.run/v1",
    api_key=os.environ["MODEL_ACCESS_KEY"],
)

response = client.chat.completions.create(
    model=os.environ.get("DO_MODEL", "nemotron-3-nano-omni"),
    messages=[
        {"role": "system", "content": "Translate the user's text to English."},
        {"role": "user", "content": transcript},
    ],
    timeout=float(os.environ.get("DO_TIMEOUT_SECONDS", "90")),
)

这就是一个标准且常见的 OpenAI 风格调用，只是将端点指向了 DigitalOcean。集成成本几乎为零------如果你的团队之前调用过 Chat Completions API，那就可以直接上手。模型名称、Base URL 和超时时间都由环境变量控制，后续切换模型或微调行为无需修改任何一行代码。混合系统中属于 Serverless 的这一半，实现起来就是这么轻量。（关于该平台支持的完整能力------如路由、提示词缓存、可观测性等------可通过卓普云AI droplet了解更多）

第二段是连接本地与云端的交接处------将本地转写出的文本递交给远程调用的关键几行：

# 本地 ASR 返回转写文本，有时会带有语言标签（例如 "<es-ES> hola..."）
transcript = strip_language_tags(local_asr_result)   # 清洗数据，去除 "<es-ES>" 等标签
english = translate_remote(transcript)               # 触发上述远程 DigitalOcean 调用

这也是混合系统能否平稳运行的关键所在。本地 ASR 模型输出时常常带有语言标签（如 <es-ES>），如果不加处理直接传给下游，翻译模型可能会产生误判。在边界处进行一步简单的数据清洗即可解决。这种处理虽然琐碎，但也让人安心------本地与 Serverless 之间的交接面非常小、足够显式，且完全可控。这里没有任何黑魔法，只有一份明确的"哪些文本可以通过网络传输"的契约。

为了让上述权衡更具说服力，以下是一次典型运行的真实生产数据：

指标	实际测得数据
ASR 运行设备（请求值 → 实际值）	auto → MPS（Apple 硬件加速）
本地处理的原始音频大小	2.65 MB
发送至设备外的原始音频	0 字节
发送至设备外的转写文本载荷	883 字节
传统方案直接发送音频所需的载荷	3.70 MB
网络载荷缩减率	99.98%（约 4,000 倍）
翻译响应延迟	3.30 秒
Token 消耗（输入 / 输出 / 总计）	180 / 597 / 777
单次对话翻译成本	$0.00063（约 1,600 次/美元）

为了防止这些数据被误读，需要作三点客观说明：首先，这只是单次运行的代表性数据，而非严谨的基准测试分布。3.3 秒的延迟应视为一个样本参考，而非承诺的 SLA 保证，在实际业务性能分析中会有所波动。其次，成本估算基于假设的 Token 费率（输入每百万 $0.50，输出每百万0.50，输出每百万$ 0.50，输出每百万0.90），请在引用前核对最新的官方定价。最后，这里提及的隐私优势特指"音频/字节级"的传输裁剪，并非指文本层面的 PII（个人身份信息）自动擦除。在这个滑翔伞话题的测试样本中，正则扫描未发现邮箱、电话或社保号，是因为输入内容本身不包含这些。在实际生产中，转写出的纯文本仍可能包含敏感 PII，这也是为什么文本清洗和脱敏操作必须在设备端完成、并在发起 Serverless 调用前执行的原因。

为了让技术架构讨论更加聚焦，本文特意略过了虚拟环境配置、依赖包安装以及首次运行的模型下载等琐碎步骤。这些工程细节可以去项目仓库的 README 中查阅。

极低成本的架构技术评估

对于精明的架构评估者来说，这个项目有一个非常贴心的设计：你可以在没有 API Key 且零云端开销的情况下体验完整系统。只需设置环境变量 TRANSLATION_FAKE_MODE=true 启动，整个前端 UI 就能跑起来，系统会返回 Mock 的占位翻译文本，而不会真正调用 DigitalOcean。这能让团队在投入一分钱预算、配置任何凭证之前，就能评估用户体验、交互流程和整体架构。

此外，项目还内置了一个就绪检查脚本 scripts.asr_status，用于检查 PyTorch 和 ASR 运行环境是否就绪，以及本地硬件加速（如 Apple 的 MPS）是否被真正激活。这个功能虽然不起眼，却释放了一个强烈的信号：混合系统的本地端同样是可观测、可调试的，完全符合生产环境的运维规范。混合架构并不意味着要把本地端变成一个无法监控的黑盒。

泛化到更多业务场景

语音翻译只是该架构的一个具体范例。这种模式可以完美推广到任何兼具"敏感/高频"与"重量级/偶发性"特征的 AI 处理流水线中。一旦你掌握了这个视角，会发现这种业务场景无处不在：

• 本地脱敏 → Serverless 摘要。 在本地设备端剔除客户的个人隐私信息（PII），然后将绝对安全的清洗后文本发送给云端托管的大模型进行长文摘要。
• 本地向量化（Embedding） → Serverless 推理。 在数据源所在的本地服务器上生成向量嵌入，只将向量或检索出的相关片段发送给云端更大的模型进行最终推理。
• 边缘端数据采集 → Serverless 智能增强。 在本地设备上对物联网传感器或多媒体数据进行采集和初步清洗，仅将提炼后的特征值发往云端进行高阶分析。

无论场景怎么变，核心公式都是一贯的：将敏感的、持续高频运行的、边缘硬件能轻松消化的任务留在本地；将模型体量大、偶发性强、依赖高阶通用能力的步骤交由云端 Serverless 按量租用。

如果要为你的下一次技术规划会议提炼一句话，那就是：让本地硬件能轻松搞定且必须保证私密的工作留在本地，剩下的统统按需租用。

这种混合架构的战略价值在于，它为团队提供了一条渐进式落地 AI 的平滑路径。你不需要在"完全自托管"和"完全绑死云端"之间豪赌。你可以只将那些最能享受托管红利的阶段推向云端，同时牢牢掌控核心的敏感数据流与高频计算，并随着后续成本、模型和约束条件的变化随时调整那条边界线。这种在不重构系统的前提下自由调整边界的可选性，正是混合模式带来的最大底气。

相关资源

• 开源参考实现： github.com/Jameshskelt...
• DigitalOcean Serverless Inference ------产品深度解析 与 可用模型目录
• 延伸阅读： LLM 推理基准测试报告
• 涉及模型参考： nvidia/nemotron-3.5-asr-streaming-0.6b（本地 ASR）与 nemotron-3-nano-omni（Serverless 翻译）

说到底，光抄这个翻译项目的代码是没用的。最有效的做法是拿你们团队现在的业务开刀，对照文章里的四个维度，看看哪些该留、哪些该上云。接着，把两端连接处的那几行契约代码敲出来。连接本地与云端，其实就几行代码的事儿，一点都不玄学；真正值钱的，是你想明白"线画在哪里"的架构思维。

最后的最后，如果你考虑不清怎么来为AI推理设计合理的架构，或如何利用Serverless 推理服务来降本，可以直接咨询DigitalOcean中国区战略合作伙伴卓普云（aidroplet.com）。