
发布日期:2026年7月10日
GitHub Release:
https://github.com/bfenetworks/bfe/releases/tag/v1.8.3
项目地址:
https://github.com/bfenetworks/bfe
一、版本概览
BFE(Beyond Front End)作为 CNCF 沙盒项目、百度开源的企业级七层负载均衡软件,于 2026 年 7 月 10 日 正式发布 v1.8.3 版本。本次版本聚焦 AI 网关能力增强 与 流量治理精细化,在 v1.8.0 引入 AI 网关基础能力、v1.8.1 完善Kubernetes 部署与 AI 功能修复、v1.8.2 增强 SSE 与负载均衡之后,继续深耕 AI 推理场景的流量管理需求。
特别说明 :BFE v1.8.3 的 AI 网关功能可与 **瑛菲AI网关 v0.1.0**配套使用,共同构建企业级大模型推理服务的全栈流量治理方案。瑛菲 AI 网关 v0.1.0 已于2026 年 7 月发布,在配额控制、限流等维度进行了增强,详情可参见此前发布内容。
二、核心更新亮点
1. AI 网关功能开关:EnableAiGateway Flag
新增 EnableAiGateway 配置标志,允许用户按需启用或禁用 AI 网关功能模块。这一改进带来了两大价值:
-
生产环境更可控
在不需要 AI 推理转发的场景下,可完全关闭相关模块,减少资源占用与攻击面;
-
灰度演进更平滑
支持功能渐进式上线,便于企业在现有 BFE 集群中逐步引入 AI 网关能力。
2. 新增 AI 限流模块:mod_ai_rate_limit
v1.8.3 引入全新的mod_ai_rate_limit 模块,针对大模型推理服务的突发流量 与成本敏感 特性,提供三种分布式限流能力:
2.1 三种限流维度
| 维度 | 机制 | 适用场景 |
|---|---|---|
| RPM (Requests Per Minute) | 基于请求数的令牌桶限流 | 控制单位时间内的请求总量,防止 QPS 突增压垮后端 |
| TPM (Tokens Per Minute) | 基于 Token 数的滑动窗口限流 | 控制单位时间内的 Token 消耗总量,直接关联 GPU 算力成本 |
| Concurrency | 基于 Redis 的分布式并发连接数控制 | 限制同时处理的请求数,保护后端推理服务的内存与显存资源 |
2.2 Policy(策略)与API Key 绑定机制
mod_ai_rate_limit 采用策略-绑定的灵活架构:
-
RateLimitPolicies
定义一组限流策略,每个策略包含 RPM / TPM / Concurrency 规则,可按模型(Models)维度过滤,支持 "*" 通配符匹配所有模型;
-
ApikeyRateLimitPolicyBindings
将 API Key 与多个策略绑定,实现同一 Key 的多策略叠加管控;
-
策略开关
每个 Policy 拥有独立的 Enabled 字段,支持在线启停,无需修改规则逻辑即可临时放开或收紧限流。
💡场景示例:某金融客户拥有 400 张算力卡,可为不同业务团队分配独立的 API Key,每个 Key 绑定不同的 Policy(如"基础团队"绑定 RPM=100 + TPM=100K 的策略,"核心团队"绑定RPM=500 + TPM=500K 的策略),实现租户级的差异化限流。
2.3 TPM 预消费与差额补偿机制
TPM 限流引入预消费 +差额补偿机制:
-
预消费
请求到达时,根据 ReservedX * promptTokens + ReservedOff 公式预测本次请求的总 Token 消耗量,预先从 TPM 配额中扣除;
-
实际结算
请求完成后,从后端响应中精确解析 usage.total_tokens,计算实际消耗与预消费的差额;
-
差额补偿
通过 UpdateTokenUsage 将多扣的 Token 返还(或少扣的补充),确保 TPM 计费的精确性。
这一机制解决了大模型推理中"请求前无法准确预知输出 Token 数"的经典难题,在保护后端资源的同时避免过度限流。
2.4 标准化错误响应(OpenAI兼容)
当请求触发限流时,mod_ai_rate_limit 返回与 mod_ai_token_auth 一致的 OpenAI 风格错误响应:
{
"error": {
"code": "RPM_LIMIT_EXCEEDED",
"type": "rate_limit_error",
"message": "Rate limit exceeded for policy team_a_policy",
"details": {
"api_key": "sk-xxx",
"limit_type": "rpm"
}
}
}
支持三种命中动作(Action):
-
ActionClose
直接关闭连接;
-
ActionFinish
返回上述 JSON 错误体,HTTP 状态码 429;
-
ActionPass
放行,可用于灰度观察或特定白名单场景。
2.5 Redis 分布式限流与故障降级
所有限流维度均基于 Redis实现分布式状态共享,支持多实例 BFE 集群的一致性限流。同时提供 isRejectOnRedisError 配置:
-
当 Redis 不可用时,若设置为 true,则拒绝所有请求( fail-safe 模式);
-
若设置为 false,则降级为放行,优先保障服务可用性。
2.6 Prometheus 可观测性
模块内置 Prometheus 指标导出,涵盖:
-
tpm_match_total / tpm_hit_total / tpm_token_total TPM 匹配、触发、Token 消耗统计;
-
rpm_match_total / rpm_hit_total RPM 匹配与触发统计;
-
con_match_total / con_hit_total 并发限流匹配与触发统计。
所有指标均按 policy_id 和inst_id(规则实例 ID)打标签,便于 Grafana 等工具进行多维度可视化分析。
3. AI Token 认证模块升级:mod_ai_token_auth
本次对 mod_ai_token_auth 进行了架构级重构,核心改进包括:
3.1 多配额计划(QuotaPlan)机制
彻底重构了 Token 的配额管理模型,从单一的全局配额升级为多配额计划架构:
-
一个 Token 可绑定多个 QuotaPlan
支持为同一 API Key 配置多个配额计划(如 API-Key配额 + 个人配额 + 部门配额),实现灵活的配额组合策略;
-
周期性 / 非周期性配额
ResetMode 支持 0(非周期性,一次性配额)和 1(周期性配额包,可按周期重置),适配月度/季度/年度等多样化计费场景;
-
Redis 原子扣减
每个 QuotaPlan 通过独立的 Redis Key 管理余额,实现原子扣减,确保高并发场景下的配额一致性;
-
仅成功请求扣费
配额仅在后端返回 HTTP 200 时扣减,失败请求不计费,避免用户为异常流量买单。
3.2 模型级黑白名单管控
Token 配置新增BlockModels(黑名单)与 Models(白名单)双重管控:
-
白名单
精确指定 API Key 可访问的模型列表;
-
黑名单
直接禁止访问特定模型(如限制高成本模型),与白名单组合使用,实现更精细的模型权限控制。
3.3 标准化错误响应(OpenAI兼容)
全面重构了认证失败的错误返回格式,遵循 OpenAI API 风格的错误响应规范:
{
"error": {
"code": "QUOTA_EXHAUSTED",
"type": "quota_error",
"message": "Quota plan basic_plan exhausted.",
"details": {
"api_key": "sk-xxx",
"quota_plan_id": "basic_plan",
"limit_type": "api_key_quota",
"model": "gpt-4o"
}
}
}
-
完整错误码体系
覆盖认证错误(INVALID_API_KEY、KEY_DISABLED、KEY_EXPIRED)、配额错误(QUOTA_EXHAUSTED、QUOTA_EXPIRED)、限流错误(RPM_LIMIT_EXCEEDED、TPM_LIMIT_EXCEEDED)、模型错误(MODEL_NOT_ALLOWED)、网络错误(BACKEND_TIMEOUT)等 20+ 个场景;
-
HTTP 状态码映射
401(认证失败)、403(禁用/过期)、429(配额耗尽/限流)、502(后端不可用)、504(超时)等,便于客户端统一处理;
-
错误详情(details)
包含 api_key、quota_plan_id、limit_type、model、retry_after_seconds 等字段,便于上层平台精准定位问题并给出用户提示。
3.4 精确 Usage 解析
从后端响应JSON 中精确解析 usage.total_tokens、usage.prompt_tokens、usage.completion_tokens:
-
替代了之前基于 ContentLength / 4 的粗略估算方式,计费精度大幅提升;
-
若响应中未包含 usage 字段,则回退到按内容长度估算,确保兼容性。
3.5 Token 生命周期管理增强
-
新增 Enabled 字段:支持软删除/禁用 API Key,无需物理删除即可即时停用;
-
新增 Tags 字段:支持为 Token 打标签,便于多维度分组管理与统计分析。
4. 访问日志增强:mod_access_pb
v1.8.3 新增mod_access_pb 模块,将 BFE 访问日志输出格式从文本升级为 Protocol Buffers二进制格式。该模块配套独立仓库 bfe-access-pb 维护 PB 定义与工具库,具备以下特点:
4.1 独立 PB 定义仓库,支持版本化依赖
bfe-access-pb 仓库(https://github.com/bfenetworks/bfe-access-pb)专门存放 BFE 访问日志的 Protocol Buffers 定义及生成的 Go 代码:
-
.proto 文件
定义了 BfeLog 消息结构,包含 RequestLog 和 SessionLog 两种类型,字段覆盖请求基础信息、连接信息、Header 信息、AI 网关扩展字段等;
-
.go 文件
通过 build.sh 自动由 .proto 生成,外部项目可直接依赖该仓库的 Go 包,无需本地安装 protoc 编译器;
-
版本化升级
通过升级仓库版本号即可同步获取最新的 PB 定义变更,降低编译复杂度。
4.2 内置 b2log 二进制日志工具库
仓库附带 b2log 子包,提供二进制PB 日志的读写工具:
-
b2log_write.go
支持将 PB 消息高效写入二进制日志文件;
-
b2log_read.go
支持按顺序读取二进制日志并反序列化为 PB 消息;
-
相比文本日志,二进制格式体积更小、解析更快,适合大规模流量场景下的日志采集与离线分析。
4.3 AI 网关原生字段支持
PB 日志定义中新增了 AI 网关场景的关键字段:
-
ApikeyTag
记录 API Key 的标签信息(tagname / tagvalue),便于按租户/部门维度聚合分析;
-
RateLimitHit
记录限流命中详情,包括 rate_limit_policy_id(策略 ID)、rate_limit_type(tpm/rpm/concurrency)、rule_names(触发的规则名列表),为成本归因与限流审计提供精确数据;
-
与 mod_ai_rate_limit 和 mod_ai_token_auth 深度联动,完整记录 AI 请求的全链路治理信息。
4.4 与列式存储无缝衔接
PB 格式日志天然适配 Doris、ClickHouse等列式存储:
-
字段强类型化,无需文本解析即可直接导入;
-
体积压缩率高,降低存储与传输成本;
-
配合 b2log 工具库,可快速构建从 BFE 网关到日志分析平台的端到端流水线。
5. 会话保持能力:mod_session_sticky
v1.8.3 新增mod_session_sticky 模块,为 AI 推理等有状态场景提供企业级会话保持支持。与传统负载均衡的会话保持不同,该模块专为 AI 多轮对话、流式推理等场景设计,具备以下核心特性:
5.1 双模式架构:Cookie模式 vs Sticky 模式
mod_session_sticky 提供两种会话保持机制,适应不同业务场景:
| 模式 | 机制 | 适用场景 |
|---|---|---|
| Cookie 模式 (RuleTypeCookie) | 将后端实例信息(Addr/Port/SubCluster)经掩码加密后写入 Cookie | 通用 Web 场景,客户端支持 Cookie |
| Sticky 模式 (RuleTypeSticky) | 使用外部 Sticky ID(从 Cookie/Header/URI/JSON 体提取)作为键,后端信息存入缓存 | AI 对话场景,Sticky ID 由业务层生成 |
5.2 四层 Sticky ID提取(Sticky 模式)
Sticky 模式支持按优先级从请求中提取会话标识:
-
Cookie
从指定 Cookie Key 读取;
-
Header
从指定 HTTP Header 读取;
-
URI 参数
从 URL Query 参数读取;
-
JSON 请求体字段
从请求 JSON 体中指定字段提取(如 previous_response_id)。
💡AI 场景适配:针对 OpenAI 风格的多轮对话 API,可从请求 JSON 体中提取 previous_response_id 作为 Sticky ID,确保同一对话链路的请求始终路由到同一后端推理实例,维持对话上下文一致性。
5.3 响应体 Sticky ID 提取(Sticky 模式)
在响应阶段,模块同样支持从响应 JSON 体中指定字段提取 Sticky ID(如 response_id),并将其与当前后端实例绑定存入缓存。这实现了"首次请求由负载均衡分配后端,后续请求按响应中的对话 ID 保持会话"的完整闭环。
5.4 双缓存后端:本地 LRU + Redis 分布式
模块支持两种缓存后端,适应单机到集群的不同部署规模:
-
本地 LRU 缓存
(CacheTypeLocal):适用于单实例或会话保持范围在单节点内的场景,配置 CacheSize 控制缓存容量;
-
Redis 分布式缓存
(CacheTypeRedis):适用于多实例 BFE 集群,会话状态通过 Redis 共享,支持 ExpireSeconds 配置过期时间,Redis Key 前缀为 bfe:stickyid:。
5.5 Cookie 模式安全增强
Cookie 模式内置多层安全机制:
-
XOR 掩码 + Base64 编码
使用 MaskCode 对后端信息进行 XOR 掩码,再经 Base64 编码写入 Cookie,防止客户端直接解析后端拓扑;
-
双掩码平滑切换
支持 MaskCode(活跃掩码)和 StandbyMaskCode(备用掩码),便于密钥轮换时无损过渡;
-
Cookie 属性控制
支持 Domain、Path、MaxAge、HttpOnly、Secure 等标准 Cookie 属性;
-
自动续期
支持 RenewWindow 配置,当 Cookie 接近过期时自动重新设置,避免会话中断。
5.6 后端变化自动检测
Cookie 模式内置后端变化检测逻辑:
-
若请求中已携带会话 Cookie,但对应的后端实例地址、端口或子集群发生变化(如后端扩容/缩容/故障转移),模块自动检测到变化并重新设置 Cookie,确保客户端后续请求路由到正确的后端;
-
若后端未变化且在续期窗口内,则无需重复设置 Cookie,减少响应开销。
5.7 条件表达式驱动
与 BFE 其他模块一致,mod_session_sticky的规则通过条件表达式(Condition)匹配请求,可按域名、路径、Header、请求体内容等维度灵活配置会话保持策略,实现精细化的会话保持控制。
三、版本演进脉络:从负载均衡到 AI 网关
回顾 BFE v1.8.x 系列的演进路径,可以清晰看到项目从传统七层负载均衡向AI 原生网关 的战略转型:
| 版本 | 发布时间 | 核心特性 |
|---|---|---|
| v1.8.0 | 2025-09 | 引入 AI 网关基础功能、支持第三方 WAF 集成、后端 HTTPS 转发 |
| v1.8.1 | 2026-02 | 外部 Web Server 支持、完整 Kubernetes Demo、AI 功能 Bug 修复 |
| v1.8.2 | 2026-05 | EPP 负载均衡、SSE 支持增强 |
| v1.8.3 | 2026-07 | AI 限流(RPM/TPM/Concurrency)、Token 认证升级(多配额计划/OpenAI 错误格式)、PB 日志(bfe-access-pb)、会话保持(Cookie+Sticky 双模式/Redis/JSON 体提取)、功能开关 |
四、下载与升级
预编译二进制
| 平台 | 架构 | 包大小 |
|---|---|---|
| Linux | amd64 | ~19.8 MB |
| Linux | arm64 | ~18.5 MB |
| macOS | amd64 | ~19.3 MB |
| Windows | amd64 | ~19.7 MB |
快速升级
# 下载对应平台二进制
curl -LO https://github.com/bfenetworks/bfe/releases/download/v1.8.3/bfe_1.8.3_linux_amd64.tar.gz
# 解压并替换现有二进制
tar -xzf bfe_1.8.3_linux_amd64.tar.gz
# 验证版本
./bfe -v
配置示例:启用 AI 网关并配置限流与认证
bfe.conf
[Server]
EnableAiGateway = true
[Module]
# 启用 AI 限流与认证
mod_ai_rate_limit = true
mod_ai_token_auth = true
mod_session_sticky = true
mod_access_pb = true
mod_ai_rate_limit.conf
{
"Version": "v1.8.3",
"Config": {
"ai_gateway": [
{
"cond": "req_host_in("api.example.com") && req_path_prefix_in("/v1/chat")",
"hit_action": { "Cmd": "FINISH" }
}
]
},
"RateLimitPolicies": {
"team_a_policy": {
"name": "team_a_policy",
"enabled": true,
"models": ["gpt-4o", "gpt-4o-mini"],
"rules": {
"tpm": [
{
"name": "tpm_1m",
"window_minutes": 1,
"max_tokens": 100000,
"step_minutes": 1
}
],
"rpm": [
{
"name": "rpm_1m",
"window_minutes": 1,
"max_requests": 100,
"burst": 10
}
],
"max_concurrency": 20
}
}
},
"ApikeyRateLimitPolicyBindings": {
"sk-abc123": ["team_a_policy"]
}
}
mod_ai_token_auth.conf
{
"Version": "v1.8.3",
"QuotaPlans": {
"ai_gateway": [
{
"Id": "basic_plan",
"Quota": 1000000,
"ResetMode": 1,
"ExpiredTime": -1
}
]
},
"Tokens": {
"ai_gateway": {
"sk-abc123": {
"key": "sk-abc123",
"enabled": 1,
"status": 0,
"name": "team_a_key",
"allow_models": "gpt-4o,gpt-4o-mini",
"block_models": "gpt-4o-vision",
"quota_plans": ["basic_plan"],
"unlimited_quota": false
}
}
},
"Config": {
"ai_gateway": [
{
"Cond": "req_host_in("api.example.com") && req_path_prefix_in("/v1/chat")",
"Action": { "Cmd": "CHECK_TOKEN" }
}
]
}
}
mod_session_sticky.conf --- Sticky****模式(AI多轮对话)
{
"Version": "v1.8.3",
"Config": {
"ai_gateway": [
{
"cond": "req_host_in("api.example.com") && req_path_prefix_in("/v1/chat")",
"type": "Sticky",
"cookie_key": "bfe_chat_id",
"header": "X-Chat-Session",
"sticky_request_field": "previous_response_id",
"sticky_response_field": "response_id",
"max_age": 3600,
"renew_window": 1800
}
]
}
}
五、结语
BFE v1.8.3 的发布,标志着这款源自百度万亿级流量锤炼的七层负载均衡软件,在AI 原生网关 赛道上迈出了坚实的一步。从功能开关的精细化控制,到 AI 限流(RPM/TPM/Concurrency 三层分布式限流)、多配额计划 Token 认证、PB 二进制日志(bfe-access-pb)、会话保持(Cookie+Sticky 双模式/Redis/JSON 体提取)等专项能力的补齐,BFE 正在为企业私有化部署的大模型推理服务提供越来越完善的流量治理方案。
BFE v1.8.3 的 AI 网关功能可与 瑛菲AI网关 v0.1.0配套使用,前者作为底层数据面引擎提供高性能七层负载均衡与 AI 流量治理,后者在配额控制、限流等维度提供增强的管理能力,二者协同可构建覆盖数据面到控制面的完整企业级 AI 网关解决方案。
对于正在规划或建设 AI 网关基础设施的团队而言,BFE v1.8.3 值得认真评估与试用。
反馈
对本次发布的功能和优化,还有哪些问题?您在BFE使用中有什么疑问?访问下面的链接,提交您的反馈: