Argus Gateway 性能基线 — 接进生产之前，先看这 4 个场景

一句话

4 个场景 × 2 种脱敏模式，Apple Silicon Mac 10 核，upstream = ASGI in-process mock。L1 fast 3 runs × 200 iters median；L2 NER 1 run × 30 iters（数据稳定度 p99 极差 < 70ms，multi-run median 不影响结论）。下面是原始数字 + 你自己复现的命令。

数字

L1 fast 模式（正则引擎，覆盖 36 类中文 PII）

场景	N	p50 (ms)	p95 (ms)	p99 (ms)	错误率	RPS	Overhead vs baseline (ms)
pure_forward（纯转发基线）	200	1.73	2.22	2.41	0.00	558.1	0.00
pii_redact_forward（小包 PII 脱敏）	200	2.24	2.69	2.99	0.00	438.7	0.58
pii_redact_large（大包 PII 脱敏）	200	3.40	3.79	3.96	0.00	290.7	1.55
streaming_sse（流式响应还原）	200	2.61	3.04	3.53	0.00	370.2	1.12

L2 NER 模式（argus-redact[zh]，中文命名实体识别）

同机 1 run × 30 iter × 4 scenario（数字非常稳定，20 次曲线 p50/p95/p99 极差 < 70ms，multi-run median 不会改变结论）：

场景	N	p50 (ms)	p95 (ms)	p99 (ms)	错误率	RPS	Overhead vs baseline (ms)
pure_forward（基线，启用 NER 扫描但无 PII 可识别）	30	1850	1911	1921	0.00	0.5	0.00
pii_redact_forward（小包 PII 脱敏）	30	1850	1919	2058	0.00	0.5	+0.24
pii_redact_large（大包 PII 脱敏）	30	1940	2031	2076	0.00	0.5	+89.83
streaming_sse（流式响应还原）	30	1856	1930	1980	0.00	0.5	+5.60

关键洞察：NER 模式 p50 ≈ 1850 ms / call，几乎全部来自 HanLP ELECTRA-base 模型 forward pass，和文本长度 / PII 密度相关性弱（pure_forward 和 pii_redact_forward 几乎同数字）。相对 L1 fast 模式的 ~2ms 差 1000 倍。这不是 argus-redact 的 overhead，是 Transformer 中文 NER 在 CPU 上的根本成本。

本次 device=CPU。尝试 MPS（Apple Silicon GPU）反而更慢（~2600ms），原因是 short-text batch=1 的 kernel launch 开销 + HanLP 多阶段 pipeline 的 CPU↔GPU 往返抵消了 GPU 算子加速。真实 GPU 收益需 batching 多请求 + 服务端 NVIDIA/CUDA 环境。

生产部署建议（根据 L1 vs L2 的 1000× 差异）

• 同步 chat 路径（客户发请求 → 等响应）：只用 L1 fast。2ms overhead 用户无感。
• 异步 audit / 后台 sanitize（日志持久化前清洗 / 离线检索索引前清洗）：L2 NER 可用。~2s/call 在后台不影响用户体感。
• GPU 服务端（需自行部署）：ELECTRA-base batch=8-32 在 A100/H100 上摊到 50-100ms/call，L2 可上 chat 路径。本次未测。

并发吞吐（仅 RPS + 错误率，L1 fast 模式）

场景	N 并发	RPS	错误率
concurrent_50（50 并发请求）	50	536.9	0.00
concurrent_100（100 并发请求）	100	583.5	0.00
concurrent_200（200 并发请求）	200	607.5	0.00

环境：Apple Silicon Mac（Darwin arm64，10 核）。Python 3.11.3，argus-redact 0.4.14，upstream = ASGI in-process mock（消除网络抖动），每组 3 次 run × 200 iters 取中位。复现命令见下方"5 行命令复现"段，自己跑一份比读别人数字可信。

为什么这些数字重要

典型 LLM API 请求往返延迟（国内直连国外云厂商）在 300–1500 ms 级别。在这个基数上，个位数毫秒的 overhead 意味着 PII 治理对用户体感基本不可见。你可以把 Argus Gateway 接进所有 chat 请求的主路径，而不是只用在"高合规场景"。

但数字本身不是产品价值。产品价值是三件事：

中文 PII 覆盖的完整度

开源 PII 工具（如 Microsoft Presidio）对中文身份证、中文地址、中国手机号的识别能力有限，需要自己写 pattern 补。Argus Gateway 的 L1 正则模式内置 36 类中文 PII（身份证、手机号、统一社会信用代码、银行卡、住址、车牌、护照、军官证、病历号等），L2 NER 模式在此之上用中文模型识别姓名 / 组织机构 / 地名。见 argus-redact 开源仓库了解完整规则清单。

Fail-safe 默认

脱敏失败（配置错误 / 引擎挂了 / 超时）时 Argus Gateway 拒绝转发明文，不静默 fallback。数字上这意味着 L1 引擎任何异常都会表现为错误率上升，而不是悄悄漏掉 PII 到 OpenAI / DeepSeek 的日志里。上表的错误率 0 说明引擎在单机 8GB 条件下稳定，不代表"没事"——合规的前提正是"坏了你会看见"。

审计粒度 + 成本透明

每次代理请求都写一行审计日志：请求 SHA 哈希、脱敏版本、upstream 模型、token 数、费用。这意味着事后追责、按部门分摊成本、合规审计都有单一真相源。这层审计本身在上表 overhead 数字里已经算进，不是"关掉审计才能跑这么快"。

自己测一份

网关代码仍在 pre-alpha 私有阶段，但 PII 脱敏引擎 argus-redact 是独立开源的 Python 包（Apache 2.0）。上面 p99 overhead 的 core 工作量就是 redact() 调用本身 —— 你 pip install 就能复测：

pip install argus-redact

python3 -c "
import time
from argus_redact import redact

payload = '我叫张伟, 手机 13800138000, 身份证 110101199003075678。'

# Warmup
for _ in range(20):
    redact(payload, mode='fast', lang='zh')

# 200 iters, sorted, 取分位
ts = []
for _ in range(200):
    t0 = time.perf_counter()
    redact(payload, mode='fast', lang='zh')
    ts.append((time.perf_counter() - t0) * 1000)
ts.sort()
print(f'p50={ts[99]:.2f}ms  p95={ts[189]:.2f}ms  p99={ts[197]:.2f}ms')
"

这段是 redact 引擎本身的 p99，不含 HTTP / FastAPI / audit 层的 overhead；那些在上表 pii_redact_forward 的数字里已经算进 —— 减去 pure_forward baseline 就是网关 wrapper 的 overhead (≈0.58ms p99 小包)。

想跑 L2 NER 模式：pip install 'argus-redact[zh]' 约 400MB（含中文 tokenizer）。把上面 mode='fast' 换成 mode='ner' 即可。警告：首次运行 HanLP 冷启动 + 迭代重加载，在 Apple Silicon Mac 上单次可达数秒 — 见上面 L2 NER 说明。

我们没测的部分（诚实清单）

• 多地域延迟：本次测试单机，无跨地域 upstream。真实企业环境中 upstream 延迟方差更大。
• 真实 upstream 争用：用 mock 排除了 DeepSeek / OpenAI 官方 rate limit、queue 延迟、5xx 重试的影响。真实环境中 p99 尾部更难看。
• 冷启动 / pip install 时长：首次启动（包括 NER 模型加载）未计入延迟，稳态之后测。
• Python GIL 上界：当前是纯 Python 实现，单进程 uvicorn 受 GIL 约束。多核吞吐靠 worker 数量扩展。
• 真实长文档：pii_redact_large 的"大包"是 5–10KB 范围，企业文档类（50KB+）未单独建 scenario。
• L2 NER 的 GPU 加速：本次 L2 NER 在 Apple Silicon CPU 路径测。MPS（Apple GPU）实验反慢（small-batch kernel launch 开销 > 收益）。NVIDIA GPU + batching 的 NER benchmark 未做。
• 低成本 ARM 硬件：本次在 Apple Silicon Mac 10 核上测。低频单核 ARM（例如某些边缘 / 嵌入式设备）未覆盖，实际数字会更保守。

如何读这些数字

不要把这组数字当 SLA 承诺。把它当最低标尺：如果你在自己环境跑出明显更差的数字（比如 L1 p99 超过 50ms），先排查这几个方向：

1. upstream 连接池大小（默认 100，并发 > 100 会排队）
2. audit log 的落盘介质（SQLite on SD card vs NVMe 差异巨大）
3. Python 版本（3.10 vs 3.11 在 regex 热路径有 ~15% 差异）
4. argus-redact 版本（0.4.x 每个 minor 都有引擎优化，pin 太老会吃亏）

也欢迎你把数字发给我们—— 极端长尾场景是真实客户教出来的，不是我们 scenario 里能凭空想到的。