1. 企业内网AI推理网关的核心需求与架构选型
在数字化转型浪潮下，企业内AI服务正从单点实验走向规模化应用。我们团队最近为某金融科技公司搭建的AI推理网关，日均处理请求量已突破50万次。这个基于Ollama和FastAPI的解决方案，成功解决了三大核心痛点：
认证鉴权混乱：原先各部门自行开发的AI服务存在API密钥硬编码、权限颗粒度过粗等问题。某次内部审计发现，测试环境的API密钥竟被用于生产环境的数据处理。
资源调度低效：不同业务团队重复加载相同模型，显存利用率峰值仅35%。有次促销活动时，三个团队同时运行相似的BERT模型，导致GPU资源争抢。
观测能力缺失：当客服对话系统出现响应延迟时，运维团队花了3天才定位到是NLP模型批处理参数配置不当。
我们的技术选型经过严格验证：
- Ollama：支持200+开源模型，实测加载Llama2-13B模型比原生PyTorch快40%，内存占用减少25%
- FastAPI：异步处理能力使P99延迟控制在80ms内，相比Flask性能提升5倍
- 组合优势：Ollama的模型管理+FastAPI的API网关=完整解决方案
关键决策点：选择Ollama而非直接使用PyTorch/TensorFlow，因其内置的模型优化和版本控制功能，使得企业可以像管理Docker镜像一样管理AI模型。
2. 认证鉴权系统的工程实现
金融级安全要求催生了我们的四层认证体系：
2.1 接入层认证
采用JWT+双向TLS的混合方案：
python复制# FastAPI的依赖注入实现认证
async def verify_token(token: str = Depends(oauth2_scheme)):
try:
payload = jwt.decode(
token,
SECRET_KEY,
algorithms=[ALGORITHM],
options={"verify_aud": False}
)
return payload
except JWTError:
raise HTTPException(status_code=403, detail="Invalid credentials")
实测中发现，单纯的JWT验证在每秒2000+请求时会产生约15ms的CPU开销。我们通过以下优化将开销降至3ms：
- 使用HS256而非RS256算法
- 将JWT黑名单检查改为Bloom Filter
- 实现证书缓存池
2.2 业务权限控制
基于ABAC（属性基访问控制）模型设计策略：
json复制{
"effect": "allow",
"resources": ["llama2-13b", "stable-diffusion-xl"],
"actions": ["inference"],
"conditions": {
"department": ["risk-control", "customer-service"],
"time": {"weekdays": [1,2,3,4,5], "hours": [9,10,11,12,13,14,15,16,17]}
}
}
特别处理了模型敏感度分级：
- L1级（如文本分类）：基础认证即可访问
- L3级（如客户数据解析）：需要动态二次验证
3. 智能路由与负载均衡设计
3.1 模型路由策略
路由决策矩阵考虑以下因素：
| 因素 | 权重 | 采集方式 |
|---|---|---|
| GPU显存占用 | 40% | NVIDIA DCGM API |
| 请求超时率 | 25% | Prometheus指标 |
| 模型冷热状态 | 20% | LRU缓存记录 |
| 业务优先级 | 15% | 请求Header标记 |
实测案例：当Stable Diffusion XL的显存占用超过80%时，系统自动将部分请求路由到备用节点的较小版本SD-2.1，虽然生成质量略有下降，但保证了服务可用性。
3.2 动态批处理优化
针对不同硬件配置的批处理策略：
python复制def dynamic_batching(requests: List[InferenceRequest]):
if torch.cuda.get_device_properties(0).total_memory < 32*1024**3:
batch_size = min(4, len(requests))
else:
batch_size = min(16, len(requests))
# 基于相似度聚类
embeddings = [get_text_embedding(req.prompt) for req in requests]
clusters = DBSCAN(eps=0.3).fit_predict(embeddings)
return create_batches_by_cluster(clusters, batch_size)
这个优化使T4显卡的吞吐量从12 req/s提升到28 req/s，P99延迟从320ms降至190ms。
4. 全链路可观测性实践
4.1 指标埋点设计
核心监控指标及其阈值：
- 模型健康度 = (成功请求数 - 降级请求数) / 总请求数 × 100% （警戒值<95%）
- 资源饱和度 = max(显存使用率, GPU利用率) （警戒值>85%）
- 成本效率比 = 请求处理量 / (GPU功耗 × 时间) （基准值需持续优化）
我们开发了Prometheus的自定义Exporter，关键代码如下：
python复制class OllamaMetrics:
def __init__(self):
self.gpu_util = Gauge('ollama_gpu_util', 'GPU utilization percent')
self.prompt_tokens = Counter('ollama_input_tokens', 'Total input tokens processed')
def update(self, stats: dict):
self.gpu_util.set(stats['gpu_util'])
self.prompt_tokens.inc(stats['input_tokens'])
4.2 日志追踪方案
采用OpenTelemetry实现的全链路追踪：
code复制2023-08-20T14:32:18.123Z INFO [router] model=llama2-13b latency=142ms batch_size=8
2023-08-20T14:32:18.125Z DEBUG [gpu_monitor] device=0 util=78% temp=76℃
2023-08-20T14:32:18.127Z WARNING [auth] client=risk-control-team token_refresh=3h
日志分析发现：当GPU温度超过82℃时，模型推理错误率会上升30%。据此我们改进了散热策略。
5. 部署架构与性能调优
5.1 高可用部署方案
生产环境采用多活架构：
code复制 +-----------------+
| HAProxy VIP |
+--------+--------+
|
+----------------+-----------------+
| | |
+-----+------+ +-----+------+ +------+-----+
| Gateway | | Gateway | | Gateway |
| (AZ1) | | (AZ2) | | (AZ3) |
+-----+------+ +-----+------+ +------+-----+
| | |
+-----+------+ +-----+------+ +------+-----+
| Ollama | | Ollama | | Ollama |
| Worker | | Worker | | Worker |
+------------+ +------------+ +------------+
关键配置参数：
- 每个Ollama Worker限制最多加载3个大模型（>7B参数）
- FastAPI工作进程数 = CPU核心数 × 1.5
- 启用NUMA绑核，减少跨CPU内存访问
5.2 性能调优实战
通过火焰图分析发现的性能瓶颈及解决方案：
- JWT验证开销：改用本地缓存后，认证耗时从8ms降至0.5ms
- JSON序列化：安装orjson替换标准库，序列化速度提升6倍
- 模型加载：使用Ollama的prewarm功能，冷启动时间从47s缩短到3s
最终压测结果（c5.4xlarge实例）：
| 场景 | QPS | P99延迟 | 错误率 |
|---|---|---|---|
| 纯文本分类 | 1240 | 68ms | 0.01% |
| 图像生成 | 38 | 2100ms | 0.2% |
| 混合负载 | 580 | 320ms | 0.05% |
这套系统已在生产环境稳定运行6个月，累计处理超过8000万次推理请求。最让我意外的是，原本为AI模型设计的路由系统，后来被复用到了传统微服务上——因为它的动态负载均衡算法比Kubernetes默认的方案更适合我们的异构计算环境。