AI全栈知识16AI应用架构设计 - 从单体到平台写在前面公司里第一个AI应用上线时架构很简单一个应用直接调一个模型完事了。但AI应用会越来越多知识库问答、智能客服、运维Agent、代码助手、数据分析……每个都需要调大模型。这时候面临选择每个应用各自部署一套模型GPU成本爆炸所有应用共用一个模型一个应用突增拖垮全部怎么设计架构既省钱又稳定这篇帮你从单应用走到AI平台建立清晰的分层架构。从一个真实场景说起假设你的公司有这些AI应用应用调用量优先级模型需求智能客服高每天1万次高面向客户qwen-turbo内部知识库中每天2000次中qwen-turbo运维Agent低每天200次低qwen-turbo代码助手中每天3000次中qwen-max需要更强的模型方案A各自独立部署智能客服 → 自己的vLLM实例1张T4 知识库 → 自己的vLLM实例1张T4 运维Agent → 自己的vLLM实例1张T4 代码助手 → 自己的vLLM实例1张A10 总计3张T4 1张A10 每月3-4万问题运维Agent每天才200次调用一张T4 24小时空跑太浪费。方案B全部共享一个实例所有应用 → 同一个vLLM实例1张T4 总计1张T4 每月7000问题某天客服流量突增所有应用都变慢。内部知识库的人也在等运维Agent也用不了。方案C分层架构推荐应用层各做各的互不关心模型在哪 网关层OneAPI统一入口负责限流/鉴权/路由 模型层vLLM集群按需弹缩 好处 - 成本可控共享GPU资源池 - 有隔离网关限流高优先级优先 - 可扩展加应用不用加GPU只要总量够三层架构详解第一层应用层每个AI应用独立开发和部署只关心业务逻辑智能客服Python/FastAPI - RAG搜知识库 调模型回答 - 不关心模型跑在哪只调API 运维AgentPython - Agent循环思考 调工具 观察 - 不关心模型跑在哪只调API 知识库问答FastGPT/Dify - 现成的RAG平台 - 配置模型API地址就行应用层的原则不直接连模型通过网关调用。就像你的Pod不直接访问数据库实例通过Service访问。第二层网关层OneAPIOneAPI是一个模型API网关做的事情功能说明类比统一入口所有应用都调同一个地址Nginx反向代理鉴权不同应用用不同API KeyIngress的Auth限流按应用设QPS上限/Token配额K8s ResourceQuota路由不同模型请求转发到不同后端Ingress Path路由负载均衡同一模型多实例分流Service负载均衡计费统计记录每个应用消耗了多少Token监控打点熔断降级后端模型挂了自动切备用熔断器模式你部署过OneAPI你知道它本质就是一个API代理。应用以为自己在调OpenAI的API实际上请求被OneAPI转发到了你自己的vLLM。网关层限流配置示例OneAPI中的渠道和令牌配置 渠道1vLLM-qwen-turbo后端地址http://vllm-turbo:8000 渠道2vLLM-qwen-max后端地址http://vllm-max:8000 令牌配置 智能客服团队 - 可用模型qwen-turbo - 每分钟限流100次 - 每日Token上限500万 - 优先级高 知识库团队 - 可用模型qwen-turbo - 每分钟限流30次 - 每日Token上限200万 - 优先级中 运维团队 - 可用模型qwen-turbo - 每分钟限流10次 - 每日Token上限50万 - 优先级低关键通过网关的限流和优先级实现共享但不争抢。第三层模型层vLLM集群模型实例池 vllm-turbo-1Qwen2-7B-INT4T4 GPU vllm-turbo-2Qwen2-7B-INT4T4 GPU← 弹缩时自动加 vllm-max-1Qwen2-72B-INT4A10 GPU 特点 - 应用无感知不知道有几个实例 - 通过网关负载均衡 - 按队列长度HPA弹缩 - 闲时缩容省钱类比K8s架构你管K8s集群的经验在这里完全适用K8s概念AI架构对应作用PodAI应用客服/Agent/知识库业务逻辑ServiceOneAPI网关统一入口负载均衡NodeGPU实例vLLM底层计算资源ResourceQuotaToken配额/QPS限流防止争抢PriorityClass请求优先级关键业务优先HPA模型实例弹缩按需扩缩Taint/Toleration模型独占/共享隔离关键业务Namespace团队/应用分组多租户管理你已经会管K8s集群了管AI平台本质上是同一套思路。隔离策略怎么防止一个应用拖垮全部策略一限流最基本每个应用有QPS上限 客服100 req/min 知识库30 req/min 运维Agent10 req/min 超出限流的请求直接返回429不会影响其他应用。策略二Token配额控制成本每个应用有每日Token预算 客服500万Token/天 知识库200万Token/天 用完了当天就拒绝不会把GPU资源耗光。策略三优先级队列当GPU满载时按优先级处理 高优先级客服立刻处理不排队 中优先级知识库排队等1-2秒 低优先级运维Agent排队等久一点也无所谓策略四关键业务独占如果客服SLA要求特别高延迟2秒 给客服单独部署一个vLLM实例不共享 其他应用共享另一个实例 相当于K8s里给关键Pod设nodeAffinityTaint独占节点。怎么选场景推荐策略应用少5个流量都不大全部共享 限流就够有一个高优先级应用面客户高优独占 其他共享应用多10个流量大共享资源池 优先级队列 Token配额多团队/多租户按团队设独立配额网关层隔离从单应用到平台的演进阶段一单应用起步期一个应用 → 直接调一个模型 架构FastGPT → vLLM 组件数2个 适合刚开始探索AI只有一个场景你们公司现在大概在这个阶段。阶段二分层成长期多个应用 → 通过网关 → 共享模型池 架构 多个应用 → OneAPI → vLLM集群 组件数5-10个 适合3-5个AI应用需要统一管理关键动作部署OneAPI做统一入口应用从直连模型改为调OneAPI加上限流和配额模型层加弹缩阶段三平台成熟期AI平台 网关 模型管理 应用市场 监控 计费 架构 ┌──────────────────────────────────┐ │ AI Platform Portal │ ← 管理面板 ├──────────────────────────────────┤ │ 应用层各种AI应用自研/接入 │ ├──────────────────────────────────┤ │ 能力层RAG引擎 / Agent引擎 │ ← 共享能力 ├──────────────────────────────────┤ │ 网关层OneAPI鉴权/限流/路由 │ ├──────────────────────────────────┤ │ 模型层vLLM集群多模型多实例 │ ├──────────────────────────────────┤ │ 基础设施K8s GPU 监控 日志 │ └──────────────────────────────────┘ 组件数20 适合AI是公司核心能力10应用平台比分层多出来的能力说明模型管理一键上下线模型、版本管理、灰度应用接入新应用自助注册申请配额共享能力RAG引擎/Agent引擎作为公共服务计费系统按团队/应用统计成本监控中心全链路Token/延迟/成本可视化管理面板非技术人员也能管理AI应用实际部署架构K8s视角# Namespace划分namespaces:ai-gateway:# OneAPIai-models:# vLLM实例ai-apps:# 各AI应用ai-infra:# 向量数据库、Embedding服务等ai-monitoring:# Prometheus Grafana# 模型层ai-models/ ├── vllm-qwen-turbo (Deployment,replicas:1-3,HPA) ├── vllm-qwen-max (Deployment,replicas:1) └── embedding-service (Deployment,replicas:2)# 网关层ai-gateway/ └── oneapi (Deployment,replicas:2,高可用)# 应用层ai-apps/ ├── customer-service-bot (Deployment) ├── internal-knowledge-qa (Deployment) ├── ops-agent (Deployment) └── code-assistant (Deployment)# 基础设施层ai-infra/ ├── milvus (StatefulSet,向量数据库) ├── redis (Token缓存/会话存储) └── postgresql (应用数据)NetworkPolicy隔离# 应用只能访问网关不能直接访问模型层apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:apps-to-gateway-onlynamespace:ai-appsspec:podSelector:{}policyTypes:-Egressegress:-to:-namespaceSelector:matchLabels:name:ai-gatewayports:-port:8080-to:-namespaceSelector:matchLabels:name:ai-infra# 允许访问向量数据库技术选型参考层级组件推荐备选网关API管理OneAPILiteLLM / 自研模型推理LLM ServingvLLMTGI / Triton向量数据库语义检索Milvuspgvector / QdrantEmbedding文本向量化bge-large-zhtext-embedding-3RAG引擎检索增强LangChain / 自研LlamaIndexAgent引擎智能体LangGraph / 自研CrewAI监控可观测性PrometheusGrafanaLangFuse缓存响应缓存Redis本地缓存面试怎么说如果被问你怎么设计一个AI应用平台的架构我的设计是三层分离应用层、网关层、模型层。应用层各自独立开发只关心业务逻辑。网关层用OneAPI做统一入口负责鉴权、限流、路由和负载均衡。模型层是vLLM集群按需弹缩。隔离策略方面通过网关按应用设QPS限流和Token配额防止一个应用拖垮全部。关键业务可以独占模型实例非关键业务共享。本质上跟K8s的ResourceQuotaPriorityClass是一个思路。演进路径是单应用直连模型 → 加网关分层 → 最终形成AI平台含模型管理、计费、监控。我们公司目前在分层阶段OneAPIvLLM多应用的架构。延伸思考问题答案OneAPI挂了怎么办OneAPI部署2副本负载均衡它是无状态的挂了重启即可能不能不用OneAPI可以。流量小时应用直连vLLM也行。但应用多了后统一管理很痛苦多个模型版本怎么管理不同版本部署不同vLLM实例OneAPI里配渠道路由公有云API和自部署混用可以。OneAPI支持混合路由优先调自部署超载时fallback到公有云API小公司需要搞平台吗不需要。3个以下AI应用用分层就够了别过度设计小结本篇核心收获三层分离应用层业务逻辑/ 网关层OneAPI/ 模型层vLLM共享隔离并存通过限流、配额、优先级实现共享但不争抢类比K8s管AI平台跟管K8s集群是同一套思路演进路径单应用 → 分层 → 平台按实际需求演进别过早搞平台OneAPI的定位AI的Nginx/Ingress统一入口限流路由关键业务可独占像K8s的Taint一样SLA要求高的给独占资源下一篇预告AI全栈知识17AIOps - 用AI做运维最后一篇回归运维本行智能告警降噪AI过滤无效告警日志异常检测AI发现异常模式根因分析AI定位故障原因容量预测AI预判资源瓶颈参考链接OneAPI项目vLLM多模型部署LiteLLM另一个API网关K8s多租户最佳实践 AI全栈知识16：AI应用架构设计 - 从单体到平台
AI全栈知识16AI应用架构设计 - 从单体到平台写在前面公司里第一个AI应用上线时架构很简单一个应用直接调一个模型完事了。但AI应用会越来越多知识库问答、智能客服、运维Agent、代码助手、数据分析……每个都需要调大模型。这时候面临选择每个应用各自部署一套模型GPU成本爆炸所有应用共用一个模型一个应用突增拖垮全部怎么设计架构既省钱又稳定这篇帮你从单应用走到AI平台建立清晰的分层架构。从一个真实场景说起假设你的公司有这些AI应用应用调用量优先级模型需求智能客服高每天1万次高面向客户qwen-turbo内部知识库中每天2000次中qwen-turbo运维Agent低每天200次低qwen-turbo代码助手中每天3000次中qwen-max需要更强的模型方案A各自独立部署智能客服 → 自己的vLLM实例1张T4 知识库 → 自己的vLLM实例1张T4 运维Agent → 自己的vLLM实例1张T4 代码助手 → 自己的vLLM实例1张A10 总计3张T4 1张A10 每月3-4万问题运维Agent每天才200次调用一张T4 24小时空跑太浪费。方案B全部共享一个实例所有应用 → 同一个vLLM实例1张T4 总计1张T4 每月7000问题某天客服流量突增所有应用都变慢。内部知识库的人也在等运维Agent也用不了。方案C分层架构推荐应用层各做各的互不关心模型在哪 网关层OneAPI统一入口负责限流/鉴权/路由 模型层vLLM集群按需弹缩 好处 - 成本可控共享GPU资源池 - 有隔离网关限流高优先级优先 - 可扩展加应用不用加GPU只要总量够三层架构详解第一层应用层每个AI应用独立开发和部署只关心业务逻辑智能客服Python/FastAPI - RAG搜知识库 调模型回答 - 不关心模型跑在哪只调API 运维AgentPython - Agent循环思考 调工具 观察 - 不关心模型跑在哪只调API 知识库问答FastGPT/Dify - 现成的RAG平台 - 配置模型API地址就行应用层的原则不直接连模型通过网关调用。就像你的Pod不直接访问数据库实例通过Service访问。第二层网关层OneAPIOneAPI是一个模型API网关做的事情功能说明类比统一入口所有应用都调同一个地址Nginx反向代理鉴权不同应用用不同API KeyIngress的Auth限流按应用设QPS上限/Token配额K8s ResourceQuota路由不同模型请求转发到不同后端Ingress Path路由负载均衡同一模型多实例分流Service负载均衡计费统计记录每个应用消耗了多少Token监控打点熔断降级后端模型挂了自动切备用熔断器模式你部署过OneAPI你知道它本质就是一个API代理。应用以为自己在调OpenAI的API实际上请求被OneAPI转发到了你自己的vLLM。网关层限流配置示例OneAPI中的渠道和令牌配置 渠道1vLLM-qwen-turbo后端地址http://vllm-turbo:8000 渠道2vLLM-qwen-max后端地址http://vllm-max:8000 令牌配置 智能客服团队 - 可用模型qwen-turbo - 每分钟限流100次 - 每日Token上限500万 - 优先级高 知识库团队 - 可用模型qwen-turbo - 每分钟限流30次 - 每日Token上限200万 - 优先级中 运维团队 - 可用模型qwen-turbo - 每分钟限流10次 - 每日Token上限50万 - 优先级低关键通过网关的限流和优先级实现共享但不争抢。第三层模型层vLLM集群模型实例池 vllm-turbo-1Qwen2-7B-INT4T4 GPU vllm-turbo-2Qwen2-7B-INT4T4 GPU← 弹缩时自动加 vllm-max-1Qwen2-72B-INT4A10 GPU 特点 - 应用无感知不知道有几个实例 - 通过网关负载均衡 - 按队列长度HPA弹缩 - 闲时缩容省钱类比K8s架构你管K8s集群的经验在这里完全适用K8s概念AI架构对应作用PodAI应用客服/Agent/知识库业务逻辑ServiceOneAPI网关统一入口负载均衡NodeGPU实例vLLM底层计算资源ResourceQuotaToken配额/QPS限流防止争抢PriorityClass请求优先级关键业务优先HPA模型实例弹缩按需扩缩Taint/Toleration模型独占/共享隔离关键业务Namespace团队/应用分组多租户管理你已经会管K8s集群了管AI平台本质上是同一套思路。隔离策略怎么防止一个应用拖垮全部策略一限流最基本每个应用有QPS上限 客服100 req/min 知识库30 req/min 运维Agent10 req/min 超出限流的请求直接返回429不会影响其他应用。策略二Token配额控制成本每个应用有每日Token预算 客服500万Token/天 知识库200万Token/天 用完了当天就拒绝不会把GPU资源耗光。策略三优先级队列当GPU满载时按优先级处理 高优先级客服立刻处理不排队 中优先级知识库排队等1-2秒 低优先级运维Agent排队等久一点也无所谓策略四关键业务独占如果客服SLA要求特别高延迟2秒 给客服单独部署一个vLLM实例不共享 其他应用共享另一个实例 相当于K8s里给关键Pod设nodeAffinityTaint独占节点。怎么选场景推荐策略应用少5个流量都不大全部共享 限流就够有一个高优先级应用面客户高优独占 其他共享应用多10个流量大共享资源池 优先级队列 Token配额多团队/多租户按团队设独立配额网关层隔离从单应用到平台的演进阶段一单应用起步期一个应用 → 直接调一个模型 架构FastGPT → vLLM 组件数2个 适合刚开始探索AI只有一个场景你们公司现在大概在这个阶段。阶段二分层成长期多个应用 → 通过网关 → 共享模型池 架构 多个应用 → OneAPI → vLLM集群 组件数5-10个 适合3-5个AI应用需要统一管理关键动作部署OneAPI做统一入口应用从直连模型改为调OneAPI加上限流和配额模型层加弹缩阶段三平台成熟期AI平台 网关 模型管理 应用市场 监控 计费 架构 ┌──────────────────────────────────┐ │ AI Platform Portal │ ← 管理面板 ├──────────────────────────────────┤ │ 应用层各种AI应用自研/接入 │ ├──────────────────────────────────┤ │ 能力层RAG引擎 / Agent引擎 │ ← 共享能力 ├──────────────────────────────────┤ │ 网关层OneAPI鉴权/限流/路由 │ ├──────────────────────────────────┤ │ 模型层vLLM集群多模型多实例 │ ├──────────────────────────────────┤ │ 基础设施K8s GPU 监控 日志 │ └──────────────────────────────────┘ 组件数20 适合AI是公司核心能力10应用平台比分层多出来的能力说明模型管理一键上下线模型、版本管理、灰度应用接入新应用自助注册申请配额共享能力RAG引擎/Agent引擎作为公共服务计费系统按团队/应用统计成本监控中心全链路Token/延迟/成本可视化管理面板非技术人员也能管理AI应用实际部署架构K8s视角# Namespace划分namespaces:ai-gateway:# OneAPIai-models:# vLLM实例ai-apps:# 各AI应用ai-infra:# 向量数据库、Embedding服务等ai-monitoring:# Prometheus Grafana# 模型层ai-models/ ├── vllm-qwen-turbo (Deployment,replicas:1-3,HPA) ├── vllm-qwen-max (Deployment,replicas:1) └── embedding-service (Deployment,replicas:2)# 网关层ai-gateway/ └── oneapi (Deployment,replicas:2,高可用)# 应用层ai-apps/ ├── customer-service-bot (Deployment) ├── internal-knowledge-qa (Deployment) ├── ops-agent (Deployment) └── code-assistant (Deployment)# 基础设施层ai-infra/ ├── milvus (StatefulSet,向量数据库) ├── redis (Token缓存/会话存储) └── postgresql (应用数据)NetworkPolicy隔离# 应用只能访问网关不能直接访问模型层apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:apps-to-gateway-onlynamespace:ai-appsspec:podSelector:{}policyTypes:-Egressegress:-to:-namespaceSelector:matchLabels:name:ai-gatewayports:-port:8080-to:-namespaceSelector:matchLabels:name:ai-infra# 允许访问向量数据库技术选型参考层级组件推荐备选网关API管理OneAPILiteLLM / 自研模型推理LLM ServingvLLMTGI / Triton向量数据库语义检索Milvuspgvector / QdrantEmbedding文本向量化bge-large-zhtext-embedding-3RAG引擎检索增强LangChain / 自研LlamaIndexAgent引擎智能体LangGraph / 自研CrewAI监控可观测性PrometheusGrafanaLangFuse缓存响应缓存Redis本地缓存面试怎么说如果被问你怎么设计一个AI应用平台的架构我的设计是三层分离应用层、网关层、模型层。应用层各自独立开发只关心业务逻辑。网关层用OneAPI做统一入口负责鉴权、限流、路由和负载均衡。模型层是vLLM集群按需弹缩。隔离策略方面通过网关按应用设QPS限流和Token配额防止一个应用拖垮全部。关键业务可以独占模型实例非关键业务共享。本质上跟K8s的ResourceQuotaPriorityClass是一个思路。演进路径是单应用直连模型 → 加网关分层 → 最终形成AI平台含模型管理、计费、监控。我们公司目前在分层阶段OneAPIvLLM多应用的架构。延伸思考问题答案OneAPI挂了怎么办OneAPI部署2副本负载均衡它是无状态的挂了重启即可能不能不用OneAPI可以。流量小时应用直连vLLM也行。但应用多了后统一管理很痛苦多个模型版本怎么管理不同版本部署不同vLLM实例OneAPI里配渠道路由公有云API和自部署混用可以。OneAPI支持混合路由优先调自部署超载时fallback到公有云API小公司需要搞平台吗不需要。3个以下AI应用用分层就够了别过度设计小结本篇核心收获三层分离应用层业务逻辑/ 网关层OneAPI/ 模型层vLLM共享隔离并存通过限流、配额、优先级实现共享但不争抢类比K8s管AI平台跟管K8s集群是同一套思路演进路径单应用 → 分层 → 平台按实际需求演进别过早搞平台OneAPI的定位AI的Nginx/Ingress统一入口限流路由关键业务可独占像K8s的Taint一样SLA要求高的给独占资源下一篇预告AI全栈知识17AIOps - 用AI做运维最后一篇回归运维本行智能告警降噪AI过滤无效告警日志异常检测AI发现异常模式根因分析AI定位故障原因容量预测AI预判资源瓶颈参考链接OneAPI项目vLLM多模型部署LiteLLM另一个API网关K8s多租户最佳实践