本地部署 vs. 代理 — 如何在不泄露敏感数据的情况下部署 LLMs
发布: (2026年3月19日 GMT+8 18:19)
4 分钟阅读
原文: Dev.to
Source: Dev.to

您的 SOC 2 认证覆盖供应商的基础设施——而不是用户在提示中粘贴的数据。一旦客户数据被发送到云模型,责任就由您承担。解决方案在于架构。
以下是三种部署选项以及何时使用每种选项的指导。
本地部署
模型运行在您自己的硬件上。没有任何数据离开您的网络,满足空气隔离要求和严格的数据驻留规定。
适用场景
- 需要空气隔离或严格的驻留规定
- 涉及政府、国防或情报数据
- 您每天处理 > 2 百万 token,使得基础设施的总拥有成本(TCO)与 API 支出具有竞争力
现实检查
- 前期成本: $80 K – $250 K+
- 上线时间: 3 – 6 个月
- 持续运维: 0.5 – 1 名全职等效(FTE)DevOps
- 硬件更新周期: 每 3 – 4 年
在您自己的硬件上提供 OpenAI 兼容的端点
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-4-Scout-17B-16E-Instruct \
--host 0.0.0.0 --port 8000 --tensor-parallel-size 4
代理 / 网关
模型保持在云端,但中心网关控制 control plane。每个请求都会通过网关,在到达云模型之前进行 PII 脱敏、强制访问控制并记录交互。
适用场景
- 影子 AI(员工在没有治理的情况下使用 AI)是主要风险
- 本季度需要治理,而不是明年
- 更倾向于 OPEX 而非 CAPEX
推荐方案
| Solution | Type | Highlights |
|---|---|---|
| LiteLLM | Open‑source | 内置 Presidio PII 防护,支持 100+ 提供商 |
| Portkey | Managed | 分析,回退路由 |
| Kong AI Gateway | Enterprise | 全功能 API 层 |
使用 PII 防护的 LiteLLM (litellm_config.yaml)
guardrails:
guardrail_name: pii-masking
litellm_params:
# add your provider‑specific parameters here
混合 — 本地脱敏 + 云推理
敏感数据在本地被遮蔽,然后匿名化的文本发送到云模型。这在不违反驻留要求的情况下提供前沿模型质量——许多受监管企业采用的模式。
- 本地 Presidio 代理 在数据离开您的基础设施之前对所有数据进行匿名化。
- LLM 网关 强制执行 RBAC 并记录每一次交互。
- 云模型 处理干净的、匿名化的文本,永不看到 PII。
Presidio 配置(在模型看到提示之前进行脱敏)
mode: pre_call # redact BEFORE model sees prompt
一目了然
| 功能 | 本地部署 | 代理 / 网关 | 混合 |
|---|---|---|---|
| 数据会离开吗? | 永不 | 仅匿名化 | 仅匿名化 |
| 防空隙安全? | 是 | 否 | 否 |
| 部署时间 | 3 – 6 个月 | 2 – 6 周 | 4 – 10 周 |
| 成本 | $80 K – $250 K+ | 低(软件) | 中等 |
| 前沿模型? | 否 | 是 | 是 |
| 最佳适用场景 | 严格居住地要求 | 影子 AI / 治理 | 受监管 + 云 |
进一步阅读
- 完整的决策框架和基础设施规格: LinkedIn Pulse
- 面向领导层/合规的版本: Substack
- 技术深度解析及完整代码: Hashnode