金融文档推理部署：自托管与托管方案的成本隐私权衡

金融文档处理中的推理部署选型，往往被简化成一个非此即彼的问题：要么自托管 GPU 集群，要么用托管 API。但真正做过这件事的团队会发现，把所有金融文档当成一个整体来做架构决策，几乎必然出错。

Superlinked 的 SIE 引擎采用「同一引擎、两种部署」的思路：公开 filings 放在 SIE Cloud 上按用量付费，客户和内部文档则自托管在自己的 GPU 上，两边共享同一套 SDK 和模型 ID。Apache 2.0 开源权重，一个 API 覆盖 OCR、抽取、embedding 和 reranking。这个方案背后的决策逻辑，比产品本身更值得拆解。

第一步：先分类文档，再选基础设施

「金融文档」至少分三类，每类对推理运行位置的要求完全不同：

公开 filings 本质上是公开数据。SEC 自己发布这些文件，EDGAR 的全文本搜索覆盖了 2001 年以来的电子申报，data.sec.gov 的 API 无需认证就能拿到结构化数据。

客户和投资组合文档 承载的是对他人的义务。这取决于你和客户签了什么协议，而不是某个通用的行业法规。

内部研究 涉及的是自身的竞争优势。一份标注了客户持仓的公开 10-K，文档本身是公开的，但标注不是。

分类时需要在边界上足够精确。先做一个清单：每类文档有多少量、分别走哪些任务（OCR、抽取、embedding、reranking、生成）。做完这个表通常会发现一个矛盾——公开 filings 占据了大头流量，而私有文档集中了主要风险。这两股力量方向相反，所以「全流程统一方案」往往是错的。

EDGAR（Electronic Data Gathering, Analysis, and Retrieval）是美国 SEC 的电子申报系统，自 1993 年起逐步取代纸质申报，要求所有上市公司和某些其他主体以电子方式提交注册声明、定期报告（10-K、10-Q、8-K）、代理声明等文件。EDGAR 的全文检索覆盖 2001 年以来的电子申报，任何人都可以通过 efts.sec.gov 的全文搜索接口或 data.sec.gov 的结构化数据 API 免费访问，无需 API key，但有速率限制（通常每秒不超过 10 次请求）和 User-Agent 声明要求。理解 EDGAR 的开放性对架构决策很关键：既然原始文件对任何第三方都可见，把公开 filings 送到托管推理服务通常不会引入新的数据暴露面。真正的敏感点在于查询日志本身，而非文档内容——例如分析师在建仓前集中检索哪些 ticker、哪些财季，这些元数据能反推投资意图，因此查询模式管理应与文档托管策略分开考虑。

第二步：按类别确定隐私要求

对公开 filings 来说，文档文本本身的隐私要求接近于零。但查询模式可能仍然敏感——你在分析哪些公司、什么时候分析。对研究机构来说，观察名单就是 alpha，一份记录了建仓前一周内查询某几只中盘股 filings 的日志，比任何内部笔记都更能暴露持仓意图。这个风险是否需要管理，取决于团队自身判断。

对客户和内部文档，问题变成了「你承诺了什么、对谁承诺」。应该去读客户协议和内部数据政策，而不是泛泛的监管条文，然后用平实的语言写下答案：这些文档能否由第三方处理、在哪些区域、按什么条款。这个答案——而不是「金融」这个词——决定了托管推理在该类别中是否可接受。

需要强调的是，没有任何通用指南能替你回答合规义务，但分类是必须做的，因为三类文档的答案几乎不可能相同。

第三步：按利用率比较成本，而不是看标价

托管和自托管推理的计价单位不同，必须放在同一工作负载上对比：

• 托管：按处理单位付费（token、页数或配对），空闲时不花钱
• 自托管：按 GPU 小时付费，无论是否忙碌，再加上集群本身的成本，单位成本随利用率上升而下降

Filings 工作负载有明显的季节性。年报在财年结束后集中到达，10-K 截止期限根据申报人规模分为 60、75 或 90 天，季报在各季度结束后 40 或 45 天跟进。波峰之间，一个按峰值配置的自托管集群大部分时间处于闲置状态，除非它能缩容。

用一个示意性算例（所有数字均为虚构说明，非 Superlinked 的定价或基准）：

自托管、常开：2 块 GPU × $2.50/小时 × 730 小时 = 每月 $3,650，无论忙闲。

实际负载：申报季每周 360,000 页，加上淡季 90,000 页 = 每季度 450,000 页，即每月 150,000 页。有效成本：$3,650 / 150,000 ≈ $0.024/页。

假设托管价格为 $0.01/页：150,000 × $0.01 = 每月 $1,500。自托管只有在月度处理量超过 365,000 页时才能追平，这还没有计算工程时间。

换一组输入，答案就会移动。能在波峰之间缩容到零的集群会压低第一行；全年稳定的量会抬高第二行。把你自己真实的量、GPU 费率和利用率代入这三行，加上运维工程时间，交叉点完全取决于负载有多稳定。

利用率是自托管成本模型中最关键的变量，定义为 GPU 实际执行推理的时间占总挂钟时间的比例。假设集群按峰值配置为每月处理 360,000 页，但淡季只有 90,000 页，则平均利用率约为 25%，这意味着单位有效成本被放大了约 4 倍。托管推理天然将这种波动转嫁给供应商，因为用量定价在空闲时账单为零。自托管只有在工作负载稳定、可预测且接近集群容量时才具备成本优势。缩容到零（scale-to-zero）能部分缓解季节性问题：声明季保留最小热实例、淡季降到零，可显著提高平均利用率，但冷启动延迟（GPU 节点调度、镜像拉取、模型权重加载）通常在 30 秒到数分钟之间，对交互式查询不友好。因此在实际测算中，需要把「可接受的首请求延迟」转成「必须保留的最小实例数」，再代入成本公式。

第四步：决定谁来 on-call

运营成本是电子表格里最容易被忽略的部分。自托管意味着你的团队要负责：

• 云账户中的 GPU 容量和配额
• Kubernetes、自动扩缩和节点池
• 模型升级、回滚和安全补丁
• 监控、告警和事故响应——尤其在申报季推理中断时

托管推理把这些转移给了供应商，留在你手里的是集成、评估，以及决定发什么出去。需要诚实评估团队是否有平台能力把 GPU 服务跑好。跑得差往往比不跑更糟，因为故障总会出现在季度最忙的时候。

GPU 集群的运维与常规 Web 服务有显著差异。KEDA（Kubernetes Event-driven Autoscaling）是 CNCF 毕业项目，通过消费外部事件源（如消息队列深度、cron 表达式）来驱动 Kubernetes 的 Horizontal Pod Autoscaler，弥补了原生 HPA 只能基于 CPU/内存指标扩缩的局限。在推理场景中，KEDA 可以根据待处理文档队列长度决定是否拉起 GPU 节点池，从而实现任务间缩容到零。另一个常见名词是 配额（quota）：AWS、GCP、Azure 对 GPU 实例默认配额通常较低（如单账号 0-8 块 A100），在申报季前若未提前申请提额，会出现「有钱也开不出机器」的情况。此外，GPU 节点的驱动升级、CUDA 版本兼容、模型权重与推理框架的绑定都是自托管独有的运维负担，出现故障时往往没有现成的托管服务兜底，团队必须具备从内核到应用层的排查能力。

第五步：设计混合架构

对很多构建文档产品的金融团队来说，走完前四步后的答案是一个拆分方案：

• 公开 filings 走托管推理，用量定价天然吸收季节性峰值
• 客户和内部文档走自托管推理，因为协议要求如此
• 一个路由层，按文档类别分配路径，而不是按调用代码是谁写的
• 两条路径使用相同的模型、模型 ID 和客户端代码，结果可比较，工作负载可以迁移而不需要返工
• 随着量和协议变化，定期重新审视这个拆分

第四项决定了这个混合架构是低成本运行还是长期漂移的根源。两套不同的技术栈会产生两组不同的答案、两轮评估和两套 bug。

同一引擎两种部署的实践

SIE 的核心卖点就在这里：同一个引擎跑在两种模式下，混合架构才具备可操作性。SIE Cloud 上由 Superlinked 运行 GPU，按用量付费，无闲置 GPU，提供 SOC 2 Type 2 认证和 US/EU 数据驻留选项。自托管版本是 Apache 2.0，运行在你自己的 VPC 中，通过 Terraform 和 Helm 部署到 AWS、GCP 或 Azure，在 Kubernetes（而非普通 Docker）上通过 KEDA 实现任务间缩容到零。

缩容到零本身也有代价。空闲期后的第一个请求需要等待 GPU 节点启动和模型权重加载。所以在申报季保留一个热最小实例，在波峰之间降到零，是更务实的做法。自托管指南还覆盖了从镜像模型快照进行气隙安装的场景。

两种模式共用 SDK 和模型 ID，路由层只需要改 base URL：

from sie_sdk import SIEClient
public_path = SIEClient(api_key="sk-sie-…", base_url="https://api.superlinked.com")
private_path = SIEClient("http://sie.internal:8080")  # 你的自托管集群
client = private_path if doc.cls in ("client", "internal") else public_path
result = client.extract("docling", {"document": doc.payload})

第三种模式是本地开发：用 pip install "sie-server[local]" 和 sie-server serve 在同一批模型上跑在开发者自己的机器上。

气隙安装（air-gapped installation）指目标环境与公网完全物理隔离，常见于对冲基金、投行自营部门和受监管的资产管理机构。在这种场景下，容器镜像、模型权重、Python 依赖包都必须预先打包成可离线传输的介质（如加密硬盘或内部制品库），其中模型快照通常体积较大（数 GB 到数十 GB），需要通过增量同步工具分发。气隙环境还意味着无法从 Hugging Face 或云端动态拉取模型，因此模型版本管理、回滚策略和签名校验必须在内部完成。数据驻留（data residency）则要求数据在特定地理区域内处理与存储，SIE Cloud 提供的 US/EU 选项即对应这一需求；但自托管时，数据驻留由你的 VPC 所在区域和节点池配置决定，需要确认云厂商的区域内 GPU 可用性，必要时跨可用区调度。气隙与数据驻留往往同时出现在合规要求中，是私有文档托管方案选型时的硬约束。

常见问题

托管供应商会看到我们的文档吗？

会，托管服务本质上就是处理它们。SIE Cloud 在 Superlinked 的环境中处理文档，提供 US/EU 数据驻留，Cloud 页面声明 SOC 2 Type 2。对公开 filings 这通常不是问题；对客户和内部文档，要检查你的协议。如果协议排除第三方处理，就把这些文档放到自托管 SIE 上，prompt 和文档都留在自己的基础设施内。

自托管在什么利用率下开始划算？

没有通用数字，任何不结合你工作负载给出的具体数值都是猜测。算法是：取每月各任务的处理量、托管单价、GPU 小时费率，以及你在整个季度（包括淡季）实际能维持的利用率，再加上运行集群的工程时间。稳定、高、可预测的负载有利于自托管；季节性申报波峰有利于用量定价——除非你的集群能在波峰之间缩容到零。

可以先托管、以后再迁移吗？

可以，前提是选择的栈在两边运行方式一致。先托管能让产品在用户面前跑起来而不必先建 GPU 基础设施，用量账单也会给你真实的量数据用于自托管计算。风险是锁定在一个没有自托管等价物的 API 上。SIE 的 Cloud 和自托管共享同一引擎、SDK 和模型 ID，开源仓库可以提前评估。

核心结论

金融领域的隐私论点真实存在，但它属于客户和内部文档，而不是任何人都能下载的 filings。先分类，再按利用率比较成本，明确谁负责运维，然后在类别不同的地方拆分工作负载。公开 filings 这一侧可以立刻上托管方案，私有那一侧随后用相同的 SDK 和模型 ID 迁移到自己的集群上。