Cost-Governed RAG: Unified Per-Tenant Cost Attribution Across Retrieval and Generation in Multi-Tenant LLM Systems

# 成本管控型RAG：多租户LLM系统中跨检索与生成的统一每租户成本归属
来源：https://arxiv.org/html/2607.12188

###### 摘要

企业级检索增强生成（RAG）部署面临一个关键的治理缺口：虽然LLM生成成本按token计费，但检索层——向量内存、相似度计算和嵌入API调用——仍是一笔无法归属的共享成本，导致租户间出现不可见的交叉补贴。我们提出成本管控型RAG（Cost-Governed RAG），该架构将无码本向量索引（TurboVec）与多租户LLM治理网关集成，构建一个统一的观测性堆栈，使得嵌入、检索和生成成本均可按租户联合归属。该架构利用TurboVec确定性的闭式内存公式，实现近乎精确的每租户检索成本计算——这一特性在具有非线性内存开销的图索引中无法实现。该系统部署在云数据平台治理边界内的Snowpark Container Services上，在100个模拟租户（1000万向量，对数正态规模分布）下实现99.96%的端到端成本归属准确率，遥测开销低于查询延迟的0.04%。根据第IV节详述的定价假设，该架构相比托管向量数据库服务可将检索基础设施成本降低3.1–9.0倍。我们形式化了一个三层成本模型，并证明无码本量化不仅能够实现确定性的每租户成本归属，还能消除训练量化器中存在的共享码本泄漏面——后一发现为探索性结果，受第VII节所述限制约束。

## I. 引言

企业LLM部署越来越多地使用检索增强生成（RAG）[1 (https://arxiv.org/html/2607.12188#bib.bib1)]将模型输出扎根于专有知识库。虽然近期工作通过模型级联[5 (https://arxiv.org/html/2607.12188#bib.bib5)]、提示压缩[6 (https://arxiv.org/html/2607.12188#bib.bib6)]和token级计量[17 (https://arxiv.org/html/2607.12188#bib.bib17)]来处理LLM推理的*生成*成本，但*检索*成本——向量索引消耗的内存、相似性搜索消耗的计算以及嵌入API调用——仍是企业成本治理中的盲区。

这一缺口在多租户部署中尤为严重，因为多个业务单元或客户共享基础设施。一个拥有1000万文档且以全精度（FP32）索引的租户会消耗约57 GiB的向量内存，而一个拥有10万文档的租户仅消耗约0.57 GiB——然而两者可能被收取相同的固定基础设施费率。没有检索层的成本归属，交叉补贴对FinOps团队来说是不可见的[21 (https://arxiv.org/html/2607.12188#bib.bib21)]。

现代向量索引的不透明性加剧了这一挑战。图索引（HNSW[14 (https://arxiv.org/html/2607.12188#bib.bib14)]）具有非线性的、依赖图拓扑的内存开销，难以进行简单的每租户归属。训练码本量化器（PQ[11 (https://arxiv.org/html/2607.12188#bib.bib11)]）跨租户共享码本状态，这既造成了成本归属的模糊性，也带来了潜在的隐私问题[3 (https://arxiv.org/html/2607.12188#bib.bib3)]。

我们通过集成两个互补系统来解决这一缺口：

1. **TurboVec**[2 (https://arxiv.org/html/2607.12188#bib.bib2),3 (https://arxiv.org/html/2607.12188#bib.bib3)]：一种无码本向量索引，其内存消耗精确为 \(n_t \times d \times b/8\) 每租户——确定、线性且易于归属。
2. **GovLLM**：一个多租户LLM治理网关，提供每租户token归属、身份验证、模型RBAC和观测性追踪[4 (https://arxiv.org/html/2607.12188#bib.bib4)]。

它们共同构成了**成本管控型RAG**堆栈，其中检索成本（内存、QPS）、生成成本（token、积分）和嵌入成本（API调用）均在云数据平台内统一归入每租户观测性层——无需外部数据移动。

**贡献：**

1. 一个三层成本模型，形式化每租户的嵌入、检索和生成成本，表明无码本量化能够实现具有有限残差的近乎精确的检索归属（第III-B节 (https://arxiv.org/html/2607.12188#S3.SS2)）。
2. 一种架构，将完整的成本管控型RAG堆栈部署在Snowpark Container Services上，并集成遥测（第III节 (https://arxiv.org/html/2607.12188#S3)）。
3. 在100租户模拟（1000万向量）上的实证验证：端到端成本归属准确率99.96%，相比托管替代方案成本降低3.1–9.0倍，遥测开销低于0.04%（第IV节 (https://arxiv.org/html/2607.12188#S4)）。

## II. 背景与动机

### II-A RAG成本堆栈

一个完整的RAG查询在三个不同层级产生成本，每个层级具有不同的归属特性：

**表I：RAG成本层级及归属特性**

| 层级 | 成本驱动因素 | 归属机制 | 现有覆盖率 |
|------|-------------|----------|------------|
| 嵌入 | 每个查询的token数 × token价格 | 按租户计量API调用 | ✅ 按租户（API密钥） |
| 检索 | 内存（索引+租户数据）；计算（扫描的块数） | 确定性的每租户内存 | ❌ 统一视为固定成本 |
| 生成 | 输入token + 输出token × 模型价格 | 按租户计量LLM调用 | ✅ 按租户（Langfuse等） |

现有LLM观测性平台（Langfuse[17 (https://arxiv.org/html/2607.12188#bib.bib17)]、LangSmith[18 (https://arxiv.org/html/2607.12188#bib.bib18)]、Helicone[19 (https://arxiv.org/html/2607.12188#bib.bib19)]）按租户追踪生成成本，但将检索视为统一分摊的固定基础设施成本。这造成了一个系统性治理失败：拥有大型语料库的租户补贴小型语料库的租户，而检索密集型工作负载（大量查询，大top-k）在成本仪表板中不可见。

### II-B 为何现有向量索引难以进行成本归属

**HNSW**[14 (https://arxiv.org/html/2607.12188#bib.bib14)]：图索引存储可导航的小世界图，其边结构依赖于语料库并在所有向量间共享。一个租户的向量参与连接其他租户向量的边，使得没有物理分区就无法实现每租户内存隔离。

**训练PQ**[11 (https://arxiv.org/html/2607.12188#bib.bib11)]：乘积量化通过在整个语料库上执行k-means学习 \(m \times K\) 个质心。该码本在所有租户间共享，编码整个语料库的分布结构。每租户的码本归属无法定义，且码本本身可能泄漏跨租户统计信息[3 (https://arxiv.org/html/2607.12188#bib.bib3)]。

**TurboVec**[2 (https://arxiv.org/html/2607.12188#bib.bib2)]：无码本量化通过解析方式从已知的L2归一化向量经随机旋转后的边际分布推导出边界。码本不包含任何依赖于语料库的信息，也不包含任何每租户状态。每个租户的服务总内存可分解为：

\[
M_t = \underbrace{\frac{n_t \times d \times b}{8}}_{\text{量化码}} + \underbrace{n_t \times 4}_{\text{范数}} + \underbrace{n_t \times 8}_{\text{ID}} + \underbrace{n_t \times \alpha}_{\text{块元数据}} + \underbrace{\frac{d^2 \times 4}{T}}_{\text{旋转矩阵（共享）}}
\]
其中 \(n_t\) = 租户的向量数，\(d\) = 维度，\(b\) = 位宽，\(\alpha \approx 0.5\) 字节/向量（用于32向量块头部），\(T\) = 共享旋转矩阵的租户数。除最后一项外，所有项都是确定的且与 \(n_t\) 线性相关；旋转矩阵（\(d^2 \times 4 = 9.0\) MB，当 \(d=1536\) 时）是共享的，在规模下可忽略不计。对于10万向量的4位量化：
- 码：100K × 1536 × 4/8 = 76.8 MB
- 范数：100K × 4 = 0.4 MB
- ID：100K × 8 = 0.8 MB
- 块元数据：100K × 0.5 = 0.05 MB
- 每租户总计：≈78.0 MB（载荷主导）

这种确定性——每个组件都是 \(n_t\)、\(d\) 和 \(b\) 的闭式函数——是近乎精确成本归属的关键推动因素。

### II-C GovLLM：多租户LLM治理

GovLLM[4 (https://arxiv.org/html/2607.12188#bib.bib4)]通过FastAPI网关提供每租户token归属，具有以下特性：
- 每租户身份验证（PAT/JWT/OAuth）及可配置速率限制
- 模型RBAC，限制哪些租户可以访问哪些LLM以及哪个层级
- 与Langfuse兼容的追踪，遥测闭合到云数据平台内
- 每查询成本记录写入平台原生表

## III. 架构

### III-A 在Snowpark Container Services上部署

成本管控型RAG堆栈部署在Snowpark Container Services（SPCS）内，这是Snowflake治理边界内的一个容器运行时。这种部署拓扑确保：
- 数据永远不会离开平台的治理边界
- 计算通过平台的原生积分计量计费
- 遥测直接写入平台表（无外部出口）
- 通过VPC级控制实现网络隔离

**治理边界**
租户请求 → GovLLM网关 → 嵌入服务 → TurboVec (SPCS) → LLM (Cortex API)
响应 + 成本记录
auth + rate limit
C_embed 记录
C_retrieve 记录
C_generate 记录

**图1：** 成本管控型RAG架构。每层将每租户成本遥测发射到平台治理边界内的统一观测性表中。

### III-B 每租户成本归属模型

对于发出查询 \(q\) 的租户 \(t\)，总归属成本为：

\[
C(t,q) = C_{\text{embed}}(q) + C_{\text{retrieve}}(t,q) + C_{\text{generate}}(q)
\]

其中每个组成部分定义为：

\[
C_{\text{embed}}(q) = \text{tokens}(q) \times r_{\text{embed}}
\]

\[
C_{\text{retrieve}}(t,q) = \underbrace{\frac{M_t}{M_{\text{total}}} \times r_{\text{mem}}}_{\text{内存份额}} + \underbrace{\text{blocks\_scanned}(t,q) \times r_{\text{cpu}}}_{\text{计算}}
\]

\[
C_{\text{generate}}(q) = (T_{\text{in}} + T_{\text{out}}) \times r_{\text{model}}
\]

检索成本分解为两个可归属的组成部分：
- **内存份额**：租户 \(t\) 在总索引内存中的占比，由公式（1）计算。由于TurboVec的内存是确定的且与 \(n_t\) 线性相关，该占比的误差仅源于摊销的共享旋转矩阵（在1000万向量下远小于0.1%）。
- **计算份额**：租户 \(t\) 的查询实际扫描的32向量SIMD块数。通过内核级白名单过滤，只有租户自己的块被评分，使得计算归属精确。

**关键见解：** TurboVec的无码本设计使得检索成本归属近乎精确（准确率超过99.88%），原因是：(1) 内存对每个租户是确定的，只有一个小型共享旋转矩阵需要摊销；(2) 内核级过滤确保每个查询的计算在物理上隔离。据我们所知，这种组合在HNSW或基于PQ的索引中不可用，因为共享的图边或训练码本状态无法进行干净的每租户分解。

### III-C 遥测管道

每次TurboVec搜索会产生一条结构化的遥测记录：

```json
{tenant_id, query_id, timestamp,
 vectors_scanned, blocks_skipped,
 latency_us, k_returned,
 index_memory_bytes_tenant,
 bit_width, compression_ratio}
```

该记录与GovLLM生成追踪（消耗的token、使用的模型、成本）在平台的统一遥测表中连接，生成跨所有三个层级的完整每查询成本记录。针对该表的标准SQL查询可以支持成本仪表板、异常检测和成本分摊报告。

### III-D 成本仪表板集成

统一遥测表支持原生SQL成本分析：

```sql
SELECT tenant_id,
  SUM(embed_cost + retrieve_cost
      + generate_cost) as total_cost,
  SUM(retrieve_cost)/SUM(total_cost)
      as retrieval_pct
FROM cost_telemetry
WHERE ts >= DATEADD('day', -30, CURRENT_DATE)
GROUP BY tenant_id ORDER BY total_cost DESC;
```

这个查询在外部向量数据库（Pinecone、Qdrant）中并不直接可行，因为据我们所知，它们不暴露每租户内存利用率的API，无法直接馈送到治理层的表中。

## IV. 评估

### IV-A 实验设置

我们模拟一个100租户的部署，配置如下：
- 总语料库：1000万向量，\(d=1536\)（OpenAI text-embedding-3-large，维度=1536）
- 租户分布：对数正态（\(\mu=11.5, \sigma=1.0\)），每个租户向量数从约1万到约50万不等
- 查询负载：聚合1000 QPS，与租户规模成比例分配
- 量化：TurboVec 4位（8倍压缩）
- 计算：SPCS CPU_X64_S 实例系列（1个节点），用于10万规模基准测试

### IV-B 成本归属准确率

我们将归属成本（来自遥测记录）与基础设施层面测量的实际资源消耗进行比较。每个租户 \(i\) 的归属准确率定义为 \(A_i = 1 - |\hat{C}_i - C_i| / C_i\)，其中 \(\hat{C}_i\) 为遥测推导的归属成本，\(C_i\) 为基于直接内存测量和CPU周期计数器计算的地面实况成本。报告的端到端数据计算如下：对于10,000个模拟查询中的每一个，我们计算每查询归属误差；然后在每个租户内对查询求平均以获得 \(A_i\)；最后报告所有100个租户的 \(A_i\) 的均值。由于模拟使用固定的随机种子（42），且所有索引操作都是确定性的（平面扫描，无随机成分），重复运行产生相同的结果——方差仅来自租户规模分布，而非算法随机性。

**表II：各层成本归属准确率（100个租户，1000万向量，对数正态分布）。准确率 = 跨租户的 \(1 - |\hat{C}_i - C_i| / C_i\) 均值；最大误差 = 最坏情况下的单租户偏差。**

| 层级 | 准确率（均值） | 最大误差 |
|------|---------------|----------|
| 嵌入 | 100.00% | 0.00% |
| 检索 | 99.88% | 0.23% |
| 生成 | 100.00% | 0.00% |
| **端到端** | **99.96%** | **0.23%** |

0.12%的检索归属误差完全源于公式（1）中的共享旋转矩阵项：当 \(d=1536\) 时，矩阵占用 \(d^2 \times 4 = 9.0\) MB，该部分在所有租户间平均摊销，而非按语料库大小比例归属。所有其他项（码、范数、ID、块元数据）与 \(n_t\) 严格线性相关，因此完美可归属。在1000万总向量下，共享的9.0 MB仅占7.3 GiB总索引的远小于0.12%，从而产生观察到的归属差距。

### IV-C 内存成本降低

**表III：月度检索基础设施成本比较（1000万向量，\(d=1536\)，1000 QPS）。内存由公式（1）推导。**

| 方法 | 内存（GiB） | 月度成本 | 归属支持 |
|------|-------------|----------|----------|
| Pinecone（Serverless） | ~17.0（估计） | $8,670 | ❌ 无每租户API |
| Qdrant（Cloud） | ~19.2 | $9,840 | ❌ 无每租户API |
| 自托管HNSW（FP32） | 57.3 | $3,780 | ⚠️ 理论上可归属 |
| 自托管PQ（4位） | 7.2 | $596 | ❌ 训练码本共享 |
| TurboVec SPCS（4位） | 7.3 | $1,093 | ✅ 精确归属（99.88%） |

“归属”列突出显示了一个关键区分：据我们所知，托管向量数据库不提供每租户内存消耗报告的API，使得检索层的成本治理变得困难。自托管的FP32索引理论上可以归属（内存与向量数线性相关），但缺乏压缩优势。

**定价假设：** TurboVec SPCS成本假设在Snowflake公布的SPCS信用费率下（us-west-2，2026年6月）使用单个CPU_X64_S节点。Pinecone估算采用Serverless计划，存储1000万向量