1. 这不是画PPT是给AI系统搭骨架“图解AI应用架构设计”——这六个字一出来很多人第一反应是又要看一堆方框箭头、云朵数据库、虚线连接线的PPT了别急先放下对“架构图”的刻板印象。我干这行十年从最早手绘UML图贴在白板上到后来用draw.io拖拽组件再到今天用Mermaid写代码生成拓扑图踩过太多把“图解”当装饰的坑。真正能落地的AI应用架构图从来不是汇报材料里的静态截图而是一张可执行、可验证、可演进的系统施工蓝图。它得回答清楚三件事数据从哪来、模型在哪跑、结果怎么用它得标出每个模块的边界、接口协议、容错策略和性能瓶颈点它得让算法工程师知道该调哪个API让运维同事明白要监控哪几个指标让产品经理一眼看出用户请求走哪条路径、卡在哪一环。核心关键词“图解”二字本质是用视觉语言降低系统复杂度的认知门槛但前提是图里每一个节点都对应真实存在的服务、配置或代码逻辑。比如你画一个“大模型推理服务”不能只写个方框加个名字必须注明用的是vLLM还是Triton部署在K8s还是裸机GPU型号和显存占用是多少输入token长度限制多少超时时间设为几秒这些参数不写进图里这张图就只是幻灯片。而“AI应用架构”这个短语重点在“应用”——不是纯研究型的模型训练Pipeline而是面向真实业务场景、承载用户请求、需要7×24小时稳定运行的生产系统。它必然涉及模型服务化、前后端协同、数据闭环、安全合规、成本控制等一整套工程实践。适合谁看不是只给CTO看的战略图而是给一线开发、测试、运维、产品共同使用的协作底图。我见过最有效的架构图是贴在团队共享屏幕上的实时更新版本上面连“当前Redis缓存命中率低于70%”这种告警状态都用颜色标注。所以这篇内容我们不讲理论不堆概念直接拆解一张能真正指导开发、部署、排障的AI应用架构图该怎么画、为什么这么画、哪些地方最容易画错。2. 架构图不是装饰画是系统设计的决策记录本2.1 为什么必须用图来表达AI应用架构AI应用和传统Web应用最大的区别在于它的“不确定性”——模型输出不可完全预知、推理延迟波动大、数据漂移会悄无声息地腐蚀效果。这种不确定性让文字描述变得苍白无力。举个例子如果文档里写“用户查询经过预处理后送入大模型”这信息量几乎为零。但一张图里你能清晰看到用户请求先打到API网关再经Nginx做限流然后由Python微服务做Query清洗去噪、纠错、实体识别接着通过gRPC调用部署在A10 GPU上的vLLM服务返回结果后由另一个服务做后处理格式标准化、敏感词过滤最后才返回前端。这条路径上每个环节的输入输出、协议、超时、重试策略、监控埋点都能在图中用不同颜色、线型、图标直观呈现。更关键的是架构图是跨角色共识的锚点。算法同学说“模型精度够了”后端同学说“QPS扛不住”运维同学说“GPU显存总爆”产品同学说“响应太慢用户流失”。这些争论往往源于对系统全貌理解的偏差。一张准确的架构图能把所有人拉到同一张地图上你看瓶颈不在模型本身而在中间那个Python清洗服务——它用单线程同步调用外部API成了整个链路的木桶短板。图一摆出来问题根源立刻浮现讨论焦点自然转向如何重构清洗服务。我带过的项目里凡是跳过架构图直接写代码的90%会在联调阶段暴露出接口定义不一致、数据格式错位、重试逻辑冲突等低级错误返工成本是前期画图时间的5倍以上。图不是为了好看是为了把隐性的设计决策显性化、可追溯、可验证。2.2 真实架构图的四个致命误区很多团队画的架构图表面看着专业实际全是“皇帝的新衣”。我整理了最常见的四类陷阱都是血泪教训第一类抽象层级混乱。图里同时出现“用户”、“React前端”、“Kubernetes集群”、“CUDA驱动”、“Transformer层”……这就像在一张城市地图上既标出北京三环路又标出某栋楼里第三层第四个插座的位置。正确的做法是分层建模业务层用户旅程、功能模块、应用层服务、API、数据库、基础设施层容器、网络、GPU。每一层图只展示该层关心的实体和依赖层与层之间用明确的接口契约如REST API规范、消息Schema连接。我见过最典型的反例是把PyTorch模型代码片段直接截图贴在架构图里——这已经不是架构图是代码审查清单了。第二类忽略非功能性需求。图里密密麻麻全是服务方框却找不到一个标着“SLA: 99.95%”、“P95延迟800ms”、“日志保留30天”的标签。非功能性需求性能、可用性、安全性、可观测性不是附加项而是架构设计的约束条件。比如要求“用户查询5秒内返回”这就决定了你不能把大模型推理放在跨城专线另一端的GPU集群上要求“用户数据不出本地机房”就排除了所有公有云SaaS模型服务。这些硬性约束必须以可视化方式嵌入架构图否则设计就是空中楼阁。第三类静态快照脱离演进。一张图定终身上线后再也不更新。现实是AI应用迭代极快昨天用的Llama2-7B今天换成Qwen1.5-4B明天可能接入RAG增强上周还在用PostgreSQL存向量这周就切到Milvus。架构图必须是活的文档每次关键变更模型升级、服务拆分、中间件替换都要同步更新图并附上变更原因和影响范围。我们团队的做法是把架构图源文件Mermaid代码和部署脚本、CI/CD流水线放在一起管理图一改自动触发相关服务的健康检查。第四类责任归属模糊。图里所有连线都是双向箭头所有服务都标着“负责XX功能”但没人知道当某个服务超时失败时该找谁。真正的架构图必须明确标注每个组件的Owner个人或团队、SLI/SLO指标、应急预案入口。比如“向量检索服务”旁边要小字注明“Owner: 搜索组SLO: 查询成功率≥99.9%降级方案超时300ms切回关键词搜索联系人zhangsan”。没有责任边界的架构图就是一张无法追责的废纸。2.3 图解的核心价值从“能跑”到“可控、可优化、可扩展”一张合格的AI应用架构图最终要服务于三个目标可控、可优化、可扩展。可控意味着任何异常都能快速定位。当用户投诉“回答总是重复”图能帮你立刻锁定是RAG检索模块没返回相关文档还是大模型生成模块的temperature参数设得太低。图里每个服务都应标注关键监控指标如vLLM的vllm:gpu_cache_usage_ratio每条链路都应标出熔断阈值如Hystrix的失败率50%触发降级。可优化意味着性能瓶颈一目了然。图中用不同粗细的连线表示流量权重粗线高频路径用红色高亮标出已知瓶颈如“文本向量化服务CPU使用率常达95%”用虚线标出未来优化方向如“计划将向量化迁移至专用GPU节点”。我们曾靠一张图发现80%的流量其实只访问3个核心API其余20个API常年闲置——果断下线节省了40%的服务器成本。可扩展意味着新增能力不破坏现有结构。比如要加多模态支持图能清晰显示只需在“输入预处理”模块旁新增“图像编码器”服务通过标准消息队列接入无需改动下游所有服务。图里预留的“扩展点”Extension Point标识就是系统生命力的保障。所以“图解”不是把系统画出来而是把系统的决策逻辑、约束条件、演化路径画出来。它是一份活的契约一份技术债的记账本一份新成员入职的速成指南。接下来我们就从一张真实的AI问答应用架构图开始逐层拆解每个模块的设计原理、选型依据和实操细节。3. 一张真实AI问答应用架构图的逐层拆解3.1 整体分层视图业务层、应用层、基础设施层我们以一个典型的B端智能客服问答系统为例非Demo是已上线服务。这张图不是凭空想象而是基于真实生产环境提炼。它严格遵循三层分层原则每层聚焦不同关注点业务层蓝色区域站在用户视角描述“做什么”。包含用户终端Web/App、核心业务流程提问→理解→检索→生成→反馈、关键业务实体知识库、用户会话、意图分类。这一层不出现任何技术名词全是业务语言。比如“知识库”不叫“Milvus Vector DB”就叫“企业FAQ知识库”“意图分类”不写“BERT微调模型”就写“用户问题意图识别”。应用层绿色区域站在开发者视角描述“怎么做”。这是架构图的主体包含所有可部署的服务单元、数据存储、消息中间件。每个服务都标注了技术栈如“Python FastAPI”、“Go Gin”、部署形态StatefulSet/K8s Deployment、关键配置如“vLLM实例2xA10, max_model_len4096”。服务间连线标注协议HTTP/gRPC/Kafka和关键参数如“gRPC超时3s”、“Kafka Topicuser_query_events”。基础设施层灰色区域站在运维视角描述“在哪做”。包含K8s集群标注Region/AZ、GPU资源池A10/V100混合、对象存储MinIO/S3、网络拓扑VPC、Service Mesh Istio。这一层不画具体服务只画资源池和网络边界体现资源隔离和安全域划分。三层之间用虚线框明确分隔跨层依赖用带箭头的虚线连接并标注契约如“业务层依赖应用层提供‘问答API’SLAP951.2s”。这种分层确保每个角色只关注自己该管的部分又清楚上下游的接口约定。3.2 应用层核心模块详解为什么这样设计3.2.1 API网关不只是流量入口更是第一道防线图中最上游的“API Gateway”服务绝非简单的反向代理。我们选用Kong而非Nginx核心原因是它原生支持AI场景的特殊需求动态路由根据用户Token中的权限等级自动将请求路由到不同模型集群VIP用户走A10集群普通用户走T4集群精细化限流不是按IP限流而是按“用户ID模型类型”组合限流防止单个用户刷爆Qwen模型不影响Llama2调用请求改写自动注入TraceID、用户会话ID到Header供下游服务链路追踪熔断降级当vLLM服务健康检查失败时自动切换到备用规则引擎基于关键词匹配的轻量级Fallback。配置示例Kong declarative configservices: - name: ai-qa-service url: http://vllm-service.default.svc.cluster.local:8000 routes: - name: vllm-route paths: [/v1/chat/completions] plugins: - name: rate-limiting config: minute: 60 # VIP用户每分钟60次 policy: local - name: circuit-breaker config: failure_threshold: 5 timeout: 30000 # 30秒 reset_timeout: 300 # 5分钟提示网关层必须做“请求瘦身”。我们强制要求前端传入的messages数组单条content长度不得超过2000字符超长自动截断并记录告警。否则一个恶意构造的超长Prompt会直接打满vLLM的KV Cache导致整个集群雪崩。3.2.2 模型服务集群vLLM为何成为事实标准图中“Large Model Inference Service”模块我们采用vLLM而非HuggingFace TGI或自研Flask服务理由非常实在吞吐量碾压实测同配置下vLLM的QPS是TGI的3.2倍是Flasktransformers的8倍以上。核心在于PagedAttention——它把KV Cache像操作系统管理内存一样分页极大减少显存碎片让A10这种中端卡也能跑7B模型动态批处理Continuous Batching不用等凑满batch_size才推理新请求来了就插队显著降低P95延迟开箱即用的API完全兼容OpenAI Chat Completions API前端代码零改造。部署细节每个vLLM Pod独占2块A10 GPU避免多租户干扰--max-model-len 4096模型最大上下文--block-size 16PagedAttention分页大小需与GPU显存匹配--tensor-parallel-size 22卡并行Prometheus exporter暴露关键指标vllm:gpu_cache_usage_ratio显存利用率、vllm:request_waiting_time_seconds排队等待时间。注意vLLM的--swap-space参数慎用它会把部分KV Cache换出到SSD虽能提升并发数但SSD IO延迟会导致P95飙升。我们线上禁用此选项宁可少接请求也要保延迟稳定。3.2.3 RAG增强模块向量检索不是加个Milvus就完事图中“Retrieval Augmented Generation”模块包含三个紧密耦合的子服务Document Ingestion Service负责PDF/Word/网页等原始文档的解析、分块chunking、向量化。关键点分块策略不是固定512字符而是按语义分割用semantic-chunking库基于句子嵌入相似度Vector Database (Milvus)我们用Milvus 2.4而非FAISS单机或Chroma功能弱。Milvus支持分布式、强一致性、丰富的索引类型IVF_PQ适合海量数据HNSW适合低延迟。集群配置2个QueryNode处理检索、3个DataNode存储、1个IndexNode建索引Hybrid Search Service不只做向量检索还融合关键词检索BM25。因为纯向量检索对专有名词、缩写、数字不敏感。我们用rank_fusion算法加权合并两种结果实测准确率提升22%。一个典型RAG流程用户问“报销流程需要哪些发票”Document Ingestion Service已将《财务制度V3.2》PDF解析为500个语义块并入库Hybrid Search Service同时发起向量检索Embedding Query和BM25检索关键词“报销 发票”返回Top5文档块这些块作为Context拼接到Prompt中送入vLLM生成答案。3.2.4 后处理与反馈闭环让AI学会“反思”图中最容易被忽视却是价值最高的模块——“Post-processing Feedback Loop”。它包含Output Sanitizer不是简单过滤敏感词而是用规则小模型双重校验。例如检测到回答含“医疗建议”立即触发人工审核流程发送Slack告警检测到“法律条款”自动插入免责声明User Feedback Collector在回答下方提供“有用/无用”按钮。点击“无用”时强制弹出表单“您希望得到什么信息必填”。这些结构化反馈直接进入“Feedback Queue”Offline Evaluation Pipeline每天凌晨用反馈数据自动构建测试集评估各模型在“无用”样本上的表现生成报告。若某模型在“政策解读”类问题上“无用率”连续3天15%自动触发模型微调任务。这个闭环让系统不是静态的而是持续进化的。我们上线3个月后“无用率”从初期的35%降至8.7%核心就靠这个模块。3.3 基础设施层关键设计GPU资源不是越多越好3.3.1 GPU资源池化A10与V100的混部策略图中“GPU Resource Pool”标注了A10和V100两种卡。这不是随意选择而是基于成本与性能的精确计算A1024GB显存INT8算力150 TOPS功耗150W。适合7B-13B模型的在线推理性价比极高V10032GB显存FP16算力125 TOPS功耗250W。适合30B大模型或需要高精度计算的场景如金融风控模型。混部策略所有A10节点加入inference-poolNamespace运行vLLM服务V100节点单独划为training-pool只跑离线训练和批量推理K8s调度器配置nodeSelector和tolerations确保A10 Pod绝不调度到V100节点反之亦然避免资源争抢。实操心得GPU显存不是越大越好。我们曾用V100跑7B模型显存只用掉40%但QPS反而比A10低15%——因为V100的Tensor Core针对大矩阵优化小模型无法充分利用。选卡必须匹配模型规模。3.3.2 网络与存储延迟杀手往往藏在看不见的地方图中“Service Mesh (Istio)”和“Object Storage (MinIO)”看似普通实则暗藏玄机Istio启用mTLS强制加密所有服务间通信但关闭了默认的Envoy Sidecar对gRPC流式响应的缓冲streaming模式下缓冲会增加100ms延迟。我们在DestinationRule中显式配置trafficPolicy: connectionPool: http: http1MaxPendingRequests: 1000 maxRequestsPerConnection: 1000 tcp: connectTimeout: 5sMinIO用于存储原始文档和模型Checkpoint。我们部署在本地NVMe SSD集群上而非网络存储。实测对比读取1GB PDF本地SSD耗时1.2sNAS耗时8.7s。对于RAG文档加载这8秒就是用户等待的全部时间。4. 从图到代码关键环节的实操实现与避坑指南4.1 架构图落地第一步用Mermaid写出可执行的源码架构图必须是代码而非图片。我们团队统一用Mermaid Live Editorhttps://mermaid.live编写源码存于Git仓库/docs/architecture.mmd。好处是可Review、可Diff、可CI检查、可一键渲染为PNG/PDF。一个真实片段简化版flowchart TD A[Web Browser] --|HTTPS| B[API Gateway Kong] B --|gRPC| C[vLLM Servicebr/2xA10br/P95800ms] B --|HTTP| D[Hybrid Search Service] D --|gRPC| E[Milvus Vector DBbr/2 QueryNodebr/3 DataNode] C --|HTTP| F[Output Sanitizer] F --|Kafka| G[Feedback Queue] classDef service fill:#4CAF50,stroke:#388E3C,color:white; classDef db fill:#2196F3,stroke:#0D47A1,color:white; classDef queue fill:#FF9800,stroke:#EF6C00,color:white; class C,D,F service; class E db; class G queue; click C https://github.com/org/vllm-deploy vLLM部署文档关键技巧click语法链接到真实代码仓库让架构图成为导航入口classDef统一配色不同颜色代表不同责任域绿色计算服务蓝色存储橙色消息br/换行保持节点紧凑。每次PR提交CI会自动检查Mermaid语法并用mermaid-cli渲染成PNG插入Confluence。4.2 vLLM服务部署从镜像到上线的完整步骤步骤1构建定制化Docker镜像官方vLLM镜像vllm/vllm-cpu不包含我们所需的依赖。我们基于nvidia/cuda:11.8.0-devel-ubuntu22.04构建FROM nvidia/cuda:11.8.0-devel-ubuntu22.04 RUN apt-get update apt-get install -y python3-pip python3-dev rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip3 install --no-cache-dir -r requirements.txt # 包含vllm0.4.2, transformers4.41.0 COPY entrypoint.sh /entrypoint.sh ENTRYPOINT [/entrypoint.sh]requirements.txt关键项vllm0.4.2 transformers4.41.0 torch2.3.0cu118 sentence-transformers2.3.0 # 用于RAG的embedding步骤2K8s Deployment配置核心参数apiVersion: apps/v1 kind: Deployment metadata: name: vllm-service spec: replicas: 3 selector: matchLabels: app: vllm-service template: metadata: labels: app: vllm-service spec: nodeSelector: kubernetes.io/os: linux gpu-type: a10 # 调度到A10节点 tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: vllm image: our-registry/vllm:0.4.2-a10 ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 2 # 独占2块A10 memory: 32Gi requests: nvidia.com/gpu: 2 memory: 32Gi command: [python3, -m, vllm.entrypoints.api_server] args: - --model/models/Qwen1.5-7B-Chat - --tensor-parallel-size2 - --max-model-len4096 - --block-size16 - --enable-prefix-caching - --disable-log-requests # 生产环境关闭请求日志防隐私泄露 env: - name: VLLM_ATTENTION_BACKEND value: FLASHINFER # A10卡用FlashInfer比默认更快避坑指南--disable-log-requests必须开启否则vLLM会把用户完整Prompt写入日志违反GDPR。我们曾因未关此选项被安全审计扣分。步骤3健康检查与自动扩缩容Liveness Probe用vLLM自带的/health端点但Readiness Probe需自定义因为/health只检查进程存活不检查GPU是否ReadylivenessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 60 periodSeconds: 30 readinessProbe: exec: command: - sh - -c - | # 检查GPU显存是否被vLLM正常占用 nvidia-smi --query-gpumemory.used --formatcsv,noheader,nounits | head -1 | awk {if ($1 1000) print ready; else exit 1} initialDelaySeconds: 120 periodSeconds: 60HPAHorizontal Pod Autoscaler基于vllm:request_waiting_time_seconds指标apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: vllm-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: vllm-service minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metric: name: vllm_request_waiting_time_seconds target: type: AverageValue averageValue: 0.2 # P95等待时间超过200ms扩容4.3 RAG模块实操从文档入库到检索生效文档入库PipelineAirflow DAG# airflow/dags/rag_ingestion.py from airflow import DAG from airflow.operators.python import PythonOperator from datetime import datetime, timedelta def ingest_document(**context): doc_path context[dag_run].conf.get(doc_path) # 1. 解析PDF from pypdf import PdfReader reader PdfReader(doc_path) text .join([page.extract_text() for page in reader.pages]) # 2. 语义分块 from semantic_chunkers import RegexChunker chunker RegexChunker(chunk_size512, overlap128) chunks chunker.chunk(text) # 3. 向量化并入库 from sentence_transformers import SentenceTransformer model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) embeddings model.encode(chunks) # 写入Milvus省略连接代码 collection.insert([chunks, embeddings]) dag DAG( rag_ingestion, default_args{retries: 1}, schedule_intervalNone, start_datedatetime(2024, 1, 1), ) ingest_task PythonOperator( task_idingest_doc, python_callableingest_document, dagdag, )注意paraphrase-multilingual-MiniLM-L12-v2模型虽小但对中文语义捕捉足够好且推理快。别用all-MiniLM-L6-v2它对中文支持弱。Hybrid Search服务FastAPI# search_service/main.py from fastapi import FastAPI from milvus import Collection from rank_bm25 import BM25Okapi import numpy as np app FastAPI() # 初始化Milvus Collection和BM25索引从DB加载 milvus_collection Collection(rag_docs) bm25_index load_bm25_from_db() # 加载预计算的BM25索引 app.post(/hybrid_search) def hybrid_search(query: str): # 1. 向量检索 query_embedding embed_model.encode([query])[0] results_vector milvus_collection.search( data[query_embedding], anns_fieldembedding, param{metric_type: COSINE, params: {nprobe: 10}}, limit10 ) # 2. BM25检索 tokenized_query query.split() scores_bm25 bm25_index.get_scores(tokenized_query) top_bm25 np.argsort(scores_bm25)[-10:][::-1] # 3. Rank Fusion fused_scores {} for i, (id, score) in enumerate(results_vector[0]): fused_scores[id] 0.7 * score 0.3 * (scores_bm25[id] if id in scores_bm25 else 0) # 返回Top5 return sorted(fused_scores.items(), keylambda x: x[1], reverseTrue)[:5]实操心得Rank Fusion权重0.7/0.3是调参结果。纯向量检索召回率高但相关性差纯BM25相关性好但泛化性差。加权融合后NDCG5提升31%。5. 常见问题排查与独家避坑技巧实录5.1 典型问题速查表问题现象根本原因排查步骤解决方案vLLM服务启动后GPU显存占用100%但无法响应请求--max-model-len设置过大超出GPU显存容量1.nvidia-smi看显存分配2.kubectl logs vllm-pod看启动日志是否有OOM报错计算公式显存需求 ≈ (模型参数量 × 2字节) (max_model_len × batch_size × 2 × 1024)A10 24GB卡7B模型max_model_len建议≤4096RAG检索结果相关性差返回无关文档文档分块策略错误语义断裂1. 抽样检查入库的chunk文本2. 用similarity库计算query与chunk的余弦相似度改用semantic-chunking库基于句子嵌入聚类分块确保每个chunk语义完整API网关返回503但vLLM Pod状态正常Kong的Upstream健康检查失败1.kubectl exec -it kong-pod -- curl http://vllm-service:8000/health2. 检查vLLM是否启用了--disable-log-requests影响健康检查响应速度在Kong中配置health_check的healthy阈值将http_get的timeout从1s改为3s用户反馈“回答重复”但日志显示vLLM返回正常Output Sanitizer的去重逻辑有Bug1. 在Sanitizer前加日志打印原始vLLM输出2. 对比Sanitizer前后文本发现是正则表达式r(.)\1{2,}误删了正常重复词如“好好学习”改为用difflib.SequenceMatcher做语义去重5.2 我踩过的五个深坑与解决方案坑1模型版本漂移无人知晓现象某天突然发现回答质量下降回溯发现vLLM镜像Tag是latest自动拉取了新版vLLM0.4.1→0.4.2其PagedAttention实现有细微差异。→解决方案所有镜像Tag必须用SHA256哈希vllm:0.4.2sha256:abc123...CI流水线强制校验在架构图中每个服务旁标注Image: vllm:0.4.2sha256:...。坑2K8s Service的headless与ClusterIP混用现象vLLM Pod间gRPC通信偶尔超时。→真相vLLM的--tensor-parallel-size2要求2个Pod必须在同一节点共享GPU但我们用ClusterIP ServiceK8s负载均衡把请求随机分发到不同节点。→解决方案为vLLM StatefulSet创建Headless ServiceclusterIP: None用DNS SRV记录直接解析Pod IP确保Pod间直连。坑3Milvus的AutoIndex失效现象新文档入库后检索速度极慢。→根因Milvus 2.4默认auto_idtrue但我们的文档ID是业务生成的UUID导致AutoIndex未触发。→修复在Collection Schema中显式设置auto_idfalse并在insert时传入ids参数。坑4Prometheus指标采集丢失现象Grafana看板中vLLM指标为空。→排查发现vLLM的/metrics端点返回的是OpenMetrics格式而我们的Prometheus配置了honor_labels: true导致label冲突。→解决在Prometheus scrape config中添加honor_labels: false并用relabel_configs重写job名称。坑5安全审计发现Prompt泄露现象审计报告指出vLLM日志包含用户完整Prompt。→紧急补救立即在Deployment中添加--disable-log-requests同时在API网关层用Kong Plugin过滤X-Prompt-DebugHeader防止前端误传调试信息。5.3 架构图演进的三个阶段一张架构图的生命始于设计终于废弃。我们总结出三个必经阶段Phase 1设计草图Design Sketch用draw.io快速勾勒聚焦核心路径和关键决策如“选vLLM而非TGI”不纠结样式目的是对齐认知Phase 2生产蓝图Production Blueprint转为Mermaid代码嵌入所有真实配置IP、端口、参数链接