企业对 AI 的判断可能截然不同：有人把它视为新一轮生产力跃迁，也有人对成本、可靠性和实际收益保持谨慎。但无论立场如何，AI 已经逐渐进入企业技术战略。随之而来的关键问题不是“要不要追逐 AI”，而是“具体工作负载应该在哪里运行”。
这个问题不能只比较 GPU 单价。训练数据是否允许跨境、模型是否包含核心知识产权、业务能否接受公网依赖、团队能否运维加速器集群，都会改变最终答案。更现实的做法是按工作负载分类，在公有云、主权云、本地数据中心和边缘环境之间做可解释的选择。
不要把所有 AI 任务当成同一种负载
“AI 工作负载”至少可以拆成四类：
- 模型训练与微调：消耗大量算力，通常需要高速互联、分布式存储和弹性 GPU 资源。
- 在线推理：更关心延迟、并发、可用性，以及请求和响应中的敏感数据。
- 批量推理：例如文档分类、离线摘要和风险扫描，对实时性要求较低，更容易按成本调度。
- 数据准备与检索：包括清洗、向量化、索引和 RAG 检索，往往比模型本身接触更多原始业务数据。
因此，同一个系统完全可能采用混合部署：在弹性资源丰富的环境中训练模型，在受监管区域构建向量索引，再把低延迟推理放到本地或边缘节点。部署边界应跟随数据和风险，而不是跟随某个云平台的产品目录。
“主权”不只是服务器位于哪个国家
数据驻留是主权要求的一部分，但不是全部。一个可执行的主权评估至少应覆盖以下控制面：
| 控制问题 | 需要确认的内容 |
|---|---|
| 数据位置 | 原始数据、备份、日志、向量索引和模型缓存分别存放在哪里 |
| 管理权限 | 哪些组织、运维人员和支持团队能够访问控制面或数据面 |
| 加密控制 | 密钥由谁持有，是否能够使用客户托管密钥，以及密钥是否跨区域复制 |
| 软件供应链 | 模型、镜像、驱动和依赖包从哪里取得，能否审计和固定版本 |
| 法律管辖 | 服务商、子处理方和技术支持受哪些司法辖区约束 |
| 可退出性 | 模型权重、数据、提示词、评估集和审计记录能否完整迁移 |
这里最容易被忽略的是派生数据。提示词日志、embedding、微调权重和模型输出未必等同于原始记录，但仍可能泄露客户身份、内部流程或商业知识。治理范围不能停在上传文件这一层。
用决策矩阵代替“云端还是本地”的争论
可以为每个工作负载建立一张评分表，重点比较六个维度：
- 监管与数据敏感度：是否涉及个人信息、医疗数据、金融记录或国家、行业监管要求。
- 延迟与连通性：业务能否容忍跨区域网络延迟和公网中断。
- 算力弹性：需求是稳定运行，还是会出现短时间的大规模训练峰值。
- 单位经济性：同时计算硬件、机房、电力、网络、平台授权和运维人员成本。
- 运营能力：团队是否具备 GPU 调度、驱动升级、容量规划和模型服务监控能力。
- 可移植性：模型格式、推理引擎、对象存储和身份系统是否被专有接口锁定。
一般而言，弹性训练和实验适合资源供应充足的平台；高度敏感的数据处理更倾向于本地、主权云或受严格控制的专属环境；需要毫秒级响应或断网运行的推理则可能更接近业务现场。这里没有统一答案，只有能够被审计和复核的取舍。
可以这样实践：给敏感推理任务加上调度与网络边界
下面是一个可改造的 Kubernetes 示例。这里明确作出两个假设：集群已经安装支持 networking.k8s.io/v1 的网络策略插件，并且受监管区域的 GPU 节点带有 data-zone=sovereign 标签。示例不会自动提供法律合规，只是把部署决策固化为可检查的基础设施规则。
先给目标节点设置标签，将 <NODE_NAME> 替换为实际节点名：
kubectl label node <NODE_NAME> data-zone=sovereign
kubectl label node <NODE_NAME> accelerator=nvidia-gpu
然后应用以下清单。运行前需要把 registry.example.com/ai/inference:1.0.0 替换为经过组织审核的推理镜像，并按实际模型调整端口、资源和健康检查：
apiVersion: v1
kind: Namespace
metadata:
name: sovereign-ai
labels:
data-classification: restricted
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: inference-api
namespace: sovereign-ai
spec:
replicas: 2
selector:
matchLabels:
app: inference-api
template:
metadata:
labels:
app: inference-api
spec:
nodeSelector:
data-zone: sovereign
accelerator: nvidia-gpu
containers:
- name: server
image: registry.example.com/ai/inference:1.0.0
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 8080
resources:
requests:
cpu: "2"
memory: 8Gi
nvidia.com/gpu: "1"
limits:
cpu: "4"
memory: 16Gi
nvidia.com/gpu: "1"
readinessProbe:
httpGet:
path: /health/ready
port: http
initialDelaySeconds: 10
periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
name: inference-api
namespace: sovereign-ai
spec:
selector:
app: inference-api
ports:
- port: 80
targetPort: http
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-by-default
namespace: sovereign-ai
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-approved-callers
namespace: sovereign-ai
spec:
podSelector:
matchLabels:
app: inference-api
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
ai-access: approved
ports:
- protocol: TCP
port: 8080
应用并验证调度结果：
kubectl apply -f sovereign-inference.yaml
kubectl -n sovereign-ai rollout status deployment/inference-api
kubectl -n sovereign-ai get pods -o wide
kubectl -n sovereign-ai describe networkpolicy
这份配置解决的是“工作负载只能落到指定节点”和“默认拒绝网络流量”两个基础问题。生产环境还需要补上受控的 DNS 与镜像仓库出口、密钥管理、镜像签名验证、审计日志、备份策略和节点管理员权限隔离。尤其要注意：默认拒绝出站流量后，应用可能无法访问 DNS、对象存储或监控端点，应按实际依赖逐项放行，而不是直接开放整个互联网。
采用前检查：从一个可迁移工作负载开始
企业不必一次决定未来所有 AI 的运行位置。更稳妥的路径是选择一个数据边界清晰、指标可量化的工作负载，分别测量延迟、吞吐、GPU 利用率、每次请求成本和运维投入，再验证迁移与退出流程。
上线前至少确认以下事项：
- 数据、日志、缓存、embedding 和备份的位置都有记录。
- 身份权限遵循最小授权，平台管理员不能默认读取业务数据。
- 加密密钥、模型权重和容器镜像有明确所有者。
- 模型质量、漂移、幻觉和拒答行为拥有持续评估指标。
- 供应商中断或网络隔离时，关键业务有降级方案。
- 成本模型包含利用率不足、人员值守、网络传输和硬件更新。
- 可以导出模型资产、配置、评估集和审计记录，并在另一环境恢复。
“主权”和“务实”并不矛盾。主权提供必须遵守的边界，工程与经济指标决定在边界内如何部署。最可靠的架构通常不是把所有 AI 都放在同一个地方，而是让每类工作负载运行在风险、性能和运营能力都匹配的位置。