简介面向具备一定IT基础的企业管理者、技术总监、数据科学家及IT工程师方案以一份Docx设计文档完整呈现AI大模型数字底座项目的规划与实施路径聚焦智能化决策支持、业务流程优化与客户体验提升。资源包共1个docx文件、约314KB内容按项目概述、业务需求分析、技术架构设计等章节组织沿基础设施层、数据层、模型层、应用层展开便于不同角色按需查阅。方案细化了高性能计算与分布式存储资源配置、数据采集存储处理和管理机制以及基于预训练大模型的微调与优化同时给出智能客服、数据分析平台、自动化流程引擎等业务应用的落地设计。文档还将数据治理与安全、模型部署与监控、用户培训与技术支持纳入全流程并做经济效益、效率提升、客户满意度与创新成果多维评估同时展望技术演进方向和业务扩展可能。目前已有70人浏览学习适合正在规划AI底座或开展数字化转型的团队作为方案参考和实施手册。1. 企业数字化转型推进到深水区AI大模型项目为什么需要一个数字底座企业数字化转型推进到深水区AI大模型项目不是死在POC而是死在规模化落地那一步业务部门各调各的API算法团队各起各的推理服务同一个模型在机房跑了几份实例数据却还在库里躺着。缺的从来不是模型而是数字底座。数字底座把算力、模型、数据、工具链收拢成一个统一平台层让业务线像用电用水一样按需申请模型能力。它不是某一个模型而是一套工程体系GPU调度、推理灰度、数据进RAG、业务编排Agent。下面按底座项目从立项到上线的顺序展开先定架构分层再落vLLM服务、RAG管道、微调与Agent编排最后是验证与成本。适合企业AI平台架构师和SRE参考。2. AI大模型数字底座的四层架构与选型判断先定骨架再谈其他2.1 从算力到业务底座通常切成四层方案阶段最常见的失败是直接画一张大模型平台全景图几十个组件堆在一起落到实施时谁都不知道先建什么。走得稳的做法是把数字底座按职责切成四层层与层之间只通过接口通信业务侧只接触最上面那一层。第一层是算力资源层负责GPU集群调度和权重存储通常由Kubernetes加GPU Operator组成配一个共享文件系统放模型和数据集。这一层最常见的错误是把GPU当CPU做静态分配一个业务一个命名空间独占一批卡底座从第一天就在制造显存浪费。第二层是模型平台层提供推理、微调、向量检索、模型仓库这些通用能力。推理引擎主流选vLLM或Triton微调作业用LLaMA-Factory这类工具管理向量检索用Milvus模型文件用Harbor加模型仓库做版本管理。这一层是底座里投入最大、复用价值也最高的部分。第三层是模型资产层管理基座模型、领域微调模型、Embedding模型、Rerank模型和安全审核模型。很多方案的PPT把这一层画成一个小方块实际业务效果恰恰由它决定同样的底座模型资产不同业务侧体感差异巨大。第四层是业务编排层把RAG服务、Agent编排、统一API网关、权限审计和用量计量收拢在一起对外暴露一个稳定的API入口。这样切分的价值在于骨架先立住算力归平台部模型归算法组业务归应用组各层独立演进不需要为了一个AI项目重写整个技术栈。2.2 选型先回答三个判断再看开源还是闭源立完四层骨架选型通常围绕三个判断展开。第一基座模型用开源私有化部署还是闭源API第二平台能力自建还是直接买公有云模型服务第三底座由集团统一建设还是各业务线自建。判断原则比较固定数据敏感度决定能不能走API调用规模决定自建成本是否划算组织现状决定统一底座能不能推得动。下面这组对比是开源私有化和闭源API在实际项目里的常见取舍对比项开源模型私有化部署闭源模型API调用数据合规数据不出域审计容易交代依赖供应商数据处理协议敏感场景受限成本结构一次性硬件投入与利用率强相关token计费规模上来后成本线性增长模型能力落后头部闭源模型节奏迭代快多模态能力更新频繁运维要求需要推理调优和GPU运维人力基本不碰底层适合场景金融、制造、研发代码等敏感环境营销、办公助手等非敏感场景值得留意的是现在不少数字底座最终走的是双轨制核心敏感场景用开源模型私有化兜底长尾场景和高阶能力用闭源API补充网关层统一路由和切换。多模态大模型能力也是一样底座里先留出接口能力到位再平滑接入。2.3 底座组件清单按最小闭环去排方案阶段不要急着上大而全的LLMOps平台先把最小闭环的组件按层排出来。下面这份清单里的组件名称可以换成团队熟悉的替代品但职责不要少layers: compute: - backend: kubernetes gpu-operator # 容器调度与GPU分配 - storage: juicefs / nfs # 模型权重与数据集共享存储 platform: - inference: vllm # OpenAI兼容推理服务 - vector-db: milvus # RAG向量检索 - finetune: llamafactory # LoRA/QLoRA微调作业 - registry: harbor modelscope # 模型文件版本管理 capability: - rag: question-answering-pipeline - agent: function-calling-orchestrator - gateway: unified-api / auth / throttle这份清单的排布逻辑是算力在最底层平台层承载所有模型类任务能力层对业务封装RAG和Agent能力。网关放在业务编排层而不是平台层是因为它要把模型路由、鉴权、限流、计量集中在一个出口业务方只认一个API地址。底座能不能立住就看这一层是否真正收口。3. 模型服务层落地用vLLM把大模型部署成统一推理服务3.1 推理引擎选vLLM的理由模型服务层是最直接影响体验的一层。底座里所有上层能力最终都要落到模型推理上RAG要调用模型Agent编排要调用模型业务侧接入也要调用模型。这一层的吞吐和延迟稳定性决定了整个底座的口碑。开源推理引擎里vLLM几乎是本地部署大模型的首选原因有三PagedAttention管理KV Cache配合continuous batching把GPU利用率拉高提供OpenAI兼容API业务侧改一下base_url就能接进来社区迭代快量化、多模态、多卡并行这些能力都能跟上。底座平台层的定位是统一出口vLLM的兼容性正好踩在这个点上。3.2 vLLM部署的最小命令与关键参数在GPU集群上起一个OpenAI兼容的推理服务最小命令是这个样子vllm serve Qwen/Qwen2.5-72B-Instruct \ --tensor-parallel-size 4 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --quantization awq \ --served-model-name qwen72b-chat \ --port 8001 \ --trust-remote-code这段命令做了四件事用张量并行把72B模型拆到4张卡上跑把输入输出总长度上限设为32768把显存留给KV Cache的比例调到90%用AWQ量化降低每张卡的显存压力。--served-model-name qwen72b-chat是网关里要用的对外模型名它和模型仓库里的名字可以不一致灰度时不用动业务代码。--trust-remote-code只在模型仓库可信时加第三方权重上传来源要先人工审查再启动。实际调参时下面几个参数是排障最常动的参数默认值影响面调参建议--tensor-parallel-size1单实例能装多大模型72B级别至少4卡起步--max-model-len模型默认输入输出总长度直接决定显存占用长文档场景显式调大--gpu-memory-utilization0.9留给KV Cache的显存比例显存吃紧先换量化再降这个值--max-num-seqs256单实例最大并发序列数延迟敏感场景调到64左右提示想要在模型服务层加一道保护可以把--max-num-seqs从256调低到64延迟敏感的业务宁可排队也不要让单实例超载拖垮所有请求。3.3 用统一网关把模型路由和灰度收口底座对外不能直接暴露vLLM实例否则业务绕过网关直连升级、审计、计量全部失控。常见做法是在网关维护一张模型路由表每个逻辑模型名对应一个后端服务并支持按权重灰度切换逻辑模型名后端地址当前权重说明qwen72b-chatvllm-instance-1:8001100%主力问答模型code-7bvllm-instance-2:8002100%代码生成专用qwen-legacyvllm-instance-3:8003灰度10%老版本流量缓慢回收网关还要统一做三件事API Key鉴权、按业务线配额限流、token用量计量与对账。验证链路连通的最小命令是直接模拟一次业务调用确认路由、鉴权和计量都正常curl -s http://gateway:8000/v1/chat/completions \ -H Authorization: Bearer sk-xxx \ -H Content-Type: application/json \ -d {model:qwen72b-chat,messages:[{role:user,content:测试网关连通性}],max_tokens:64}这里的sk-xxx是网关下发的测试密钥真实环境要按业务线独立下发便于审计和成本分摊。返回体里要核对model字段是不是命中了预期路由而不是只看HTTP状态码。3.4 并发上不去先查这三个指标本地部署大模型后排障第一步不是改参数而是看指标。vLLM自带Prometheus指标端点最有用的两个是curl -s http://localhost:8001/metrics | grep -E vllm:num_requests_running|vllm:gpu_cache_usage_percnum_requests_running表示正在处理的请求数如果长期贴近max-num-seqs说明实例已经满载排队时间会快速上升gpu_cache_usage_perc表示KV Cache利用率接近1说明显存跑满优先检查是不是输入长度异常偏长。三个指标的经验对应关系是cache打满看max-model-len和量化方式请求排队看max-num-seqs和副本数TTFT变慢看tensor-parallel-size是否匹配卡间通信带宽。另外压测一定要用业务侧真实prompt分布固定长度的短文本压出来的结果没有参考价值。4. 数据接入与RAG知识库让数字底座接上企业存量数据4.1 企业数据接入底座先分清三种形态大模型在企业落地的第一条路几乎都是RAG不训练模型把知识喂给底座让模型带着企业数据回答。RAG落地快但数据接入不能想当然企业数据通常分三种形态。结构化数据在库里通过SQL查询或CDC同步RAG检索的不是数据本身而是描述库表和字段的元数据非结构化数据是文档先解析成文本再切分入库实时数据走Kafka这类流管道用于补充动态上下文。底座里常见是一个统一的数据接入层把三种来源归一成文档片段加向量的格式交给RAG服务统一消费。4.2 文档入库的RAG最小管道最简链路是加载文档、切分、向量化、写向量库四步代码量不大from langchain_huggingface import HuggingFaceEmbeddings from langchain_milvus import Milvus from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.document_loaders import DirectoryLoader # 1. 加载指定目录下的文档 loader DirectoryLoader(./docs, glob*.md) docs loader.load() # 2. 按语义边界切分而不是按固定字符硬切 splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap64, separators[\n\n, \n, 。, , ] ) chunks splitter.split_documents(docs) # 3. 中文检索用BGE系列Embedding比通用英文模型稳 embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5 ) # 4. 写入Milvus集合 vector_store Milvus.from_documents( chunks, embeddings, connection_args{host: milvus, port: 19530}, collection_nameenterprise_kb )这段代码的关键点有三个。第一切分器用RecursiveCharacterTextSplitterseparators按中文标点优先排序避免一句话被拦腰切断chunk_overlap的意义是保留跨切片的上下文线索。第二Embedding模型用BGE系列中文检索效果明显优于通用英文Embedding中小规模场景bge-large-zh-v1.5就够多语种或长文本场景再看bge-m3。第三connection_args指向Milvus服务地址collection_name按知识域分开建集合便于权限控制和增量更新。4.3 切分参数不能一套走天下一份方案里最常见的坑是所有文档统一用一套chunk_size。十类文档用一个512合同问答上下文撕裂技术手册又被截断。比较实用的做法是按文档类型分开配置文档类型chunk_sizechunk_overlap切分理由合同、制度条款300–51230–64条款是独立语义单元切太碎丢失约束关系技术手册、方案800–1200100–150强依赖上下文切细了召回率高但答不准客服工单、对话记录150–30020–40短文本粒度细匹配查询意图更准调切分参数比反复换Embedding模型更见效。上线前花半天把存量文档按类型过一遍切分RAG的命中率通常有肉眼可见的提升。切分后建议做一次抽样检查确认没有把表格拆散、没有把条款编号和正文分开。4.4 检索召回不理想按顺序排查这四个位置文档入完库问答效果不行按顺序查四件事。第一查询和文档的术语体系是否一致不一致做query改写或用同义词扩展。第二Embedding模型是否匹配业务领域用50条真实问题逐条验证Hit3指标。第三向量检索的top_k结果直接透传不够稳加一层Rerank重排from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-v2-m3) pairs [(query, doc) for doc in candidates] scores reranker.predict(pairs)Rerank模型直接对查询-文档对打分把向量检索召回的几十条候选重新排序top5准确率通常提升明显。代价是额外时延几十条候选大约多几十毫秒对实时问答可接受但底座里不要同时挂多个Rerank模型。第四做增量更新文档变更后重算切片并upsert到向量库防止旧版本内容一直霸占召回。四件事做完还不行才考虑动Embedding模型。5. 模型微调与Agent编排在底座上长出企业自己的业务能力5.1 先判断该不该微调再谈框架RAG解决模型不知道微调解决模型不会按你的规矩做事。企业里真正该微调的通常是三类场景业务领域术语体系强、通用模型答不准输出格式有硬约束比如合同审查要按固定条目返回行为规范需要对齐比如客服不能乱承诺。反过来数据量不足、知识要实时更新、需求变化快的场景微调都不合适。下沉到实操我一般建议先用基座模型加RAG跑通业务收集足够多的坏case之后再决定是否微调。一上来就微调的数据质量和数据量都是过不去的坎。5.2 用LLaMA-Factory跑LoRA微调的命令与数据格式底座里的微调平台最常用的开源工具是LLaMA-Factory它把SFT、DPO等流程封装成命令行和WebUI配好数据集就能跑。微调数据用JSONL一行一条示例是这个样子{instruction: 根据合同条款判断付款条件是否满足, input: 合同编号HT-2024-001项目已验收……, output: 根据合同第5.2条验收合格后30日内付款……}指令、输入、输出三段式是SFT最通用的格式instruction写任务描述input写业务输入output写期望输出。数据量上一类任务起步500到1000条低于这个量级先别微调优先优化RAG。然后启动LoRA微调llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --peft lora \ --dataset contract_review \ --template qwen \ --output_dir ./checkpoints/qwen7b-contract-lora \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 1e-4 \ --num_train_epochs 3 \ --lora_rank 16这里的关键设计是冻结原模型权重只训练低秩适配器7B模型在一张24G显存的卡上也能跑。per_device_train_batch_size是单卡批大小gradient_accumulation_steps做梯度累积两者相乘才是有效批大小。learning_rate常用区间是1e-4到2e-4超出容易灾难遗忘。几个常见超参的经验值如下参数常用区间说明lora_rank8–32任务复杂取大简单取小learning_rate1e-4–2e-4超过2e-4容易灾难遗忘num_train_epochs2–5数据量小先跑2轮看loss走势max_seq_length2048–4096要和推理侧max-model-len匹配训练完不是直接部署要先把LoRA适配器合并回基座模型再注册到模型仓库llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path ./checkpoints/qwen7b-contract-lora \ --template qwen \ --export_dir ./merged/qwen7b-contract提示导出时基座模型必须和训练时完全一致版本不一致会出现tokenizer错位症状是回答开头乱码、中间莫名截断这类问题最难排查。合并后的权重上传模型仓库在网关路由表注册新版本按老版本100%、新版本5%起步、再逐步放量的节奏灰度。5.3 Agent编排让模型按业务规则调用工具而不是全自治微调解决单段式任务企业真实流程往往是多步的查合同、比对条款、再给出结论。Agent编排就是在这套流程上加一层可控的工具调用。底座里落地Agent建议从function calling开始先固定流程模板再谈自治from openai import OpenAI client OpenAI(base_urlhttp://gateway:8000/v1, api_keysk-xxx) tools [{ type: function, function: { name: query_contract, description: 按合同编号查询合同文本中的指定条款, parameters: { type: object, properties: { doc_id: {type: string, description: 合同编号}, item: {type: string, description: 条款关键词} }, required: [doc_id] } } }] resp client.chat.completions.create( modelqwen72b-chat, messages[{role: user, content: 查一下HT-2024-001的付款条件}], toolstools, tool_choiceauto )这段代码里模型不直接执行查询而是返回tool_calls由底座编排层去调用授权的业务接口把结果回填给模型生成最终回答。编排层的设计重点有三个工具定义要有JSON Schema校验和权限绑定工具执行要设超时和重试执行结果要截断长度再回填。企业Agent别一上来就追求完全自治先固定任务模板、限定工具范围、保留人工确认节点跑稳三个月再逐步放开。这一步的工程可靠性决定底座从能问答走到能干活。6. 数字底座上线后三个验证手段和一个成本压法6.1 评测集先行模型升级必须过门槛底座上线后的第一件正事是建一份golden评测集。从真实业务流量里攒50到200条标注数据每条含输入、期望输出和评分维度答案准确率、格式规范率、拒答正确率。每次模型升级、prompt调整、RAG参数变更都跑同一份评测集并记录结果。自动评测可以用LLM as judge打分但每周抽样人工复核一次防止评分模型被自己的话术带偏也防止评测集被过拟合。6.2 压测看三个数字TTFT、TPOT、吞吐第二件正事是压测。vLLM自带serving benchmark脚本可以直接对网关做端到端压测python benchmarks/benchmark_serving.py \ --model qwen72b-chat \ --base-url http://gateway:8000/v1 \ --num-prompts 500 \ --request-rate 20 \ --max-concurrency 64压测报告里固定看三个数字TTFT首token时延TPOT每token生成时延整体吞吐。内部办公场景经验值是TTFT低于2秒客服场景低于1.5秒超过就要排查是上游排队、显存瓶颈还是网卡带宽。压测的prompt必须来自业务真实分布同时包含长短文本、中英文混合、长上下文检索否则测出的数据不能用于容量规划。6.3 成本压不下来优先动这三个开关到最后底座通常会发现模型能力不是瓶颈成本才是。三个开关按实施顺序排列手段收益踩坑点AWQ/GPTQ量化显存占用接近减半复杂数学推理质量下降冷热模型分流高频场景成本明显下降分流规则要可观测、可回滚语义缓存重复问题零推理成本只用于静态知识问答开放生成禁用这三个手段常被误解为用质量换成本实际上对绝大多数业务场景量化后的质量损耗很小冷热分流靠网关规则实现规则要能统计命中率和回滚语义缓存只适用于RAG知识问答这类确定性场景开放生成不能用。把评测集通过率、压测TTFT、每万token成本三个数字固定进每日巡检后续任何模型替换、参数调整都有基线可对齐。这三个数字不达标之前不要谈新场景扩容。本文还有配套的精品资源点击获取 
长河君 · 2026/9/17 6:47:44 · 阅读 1.2k AI大模型数字底座建设指南：从架构到落地的完整实践
简介面向具备一定IT基础的企业管理者、技术总监、数据科学家及IT工程师方案以一份Docx设计文档完整呈现AI大模型数字底座项目的规划与实施路径聚焦智能化决策支持、业务流程优化与客户体验提升。资源包共1个docx文件、约314KB内容按项目概述、业务需求分析、技术架构设计等章节组织沿基础设施层、数据层、模型层、应用层展开便于不同角色按需查阅。方案细化了高性能计算与分布式存储资源配置、数据采集存储处理和管理机制以及基于预训练大模型的微调与优化同时给出智能客服、数据分析平台、自动化流程引擎等业务应用的落地设计。文档还将数据治理与安全、模型部署与监控、用户培训与技术支持纳入全流程并做经济效益、效率提升、客户满意度与创新成果多维评估同时展望技术演进方向和业务扩展可能。目前已有70人浏览学习适合正在规划AI底座或开展数字化转型的团队作为方案参考和实施手册。1. 企业数字化转型推进到深水区AI大模型项目为什么需要一个数字底座企业数字化转型推进到深水区AI大模型项目不是死在POC而是死在规模化落地那一步业务部门各调各的API算法团队各起各的推理服务同一个模型在机房跑了几份实例数据却还在库里躺着。缺的从来不是模型而是数字底座。数字底座把算力、模型、数据、工具链收拢成一个统一平台层让业务线像用电用水一样按需申请模型能力。它不是某一个模型而是一套工程体系GPU调度、推理灰度、数据进RAG、业务编排Agent。下面按底座项目从立项到上线的顺序展开先定架构分层再落vLLM服务、RAG管道、微调与Agent编排最后是验证与成本。适合企业AI平台架构师和SRE参考。2. AI大模型数字底座的四层架构与选型判断先定骨架再谈其他2.1 从算力到业务底座通常切成四层方案阶段最常见的失败是直接画一张大模型平台全景图几十个组件堆在一起落到实施时谁都不知道先建什么。走得稳的做法是把数字底座按职责切成四层层与层之间只通过接口通信业务侧只接触最上面那一层。第一层是算力资源层负责GPU集群调度和权重存储通常由Kubernetes加GPU Operator组成配一个共享文件系统放模型和数据集。这一层最常见的错误是把GPU当CPU做静态分配一个业务一个命名空间独占一批卡底座从第一天就在制造显存浪费。第二层是模型平台层提供推理、微调、向量检索、模型仓库这些通用能力。推理引擎主流选vLLM或Triton微调作业用LLaMA-Factory这类工具管理向量检索用Milvus模型文件用Harbor加模型仓库做版本管理。这一层是底座里投入最大、复用价值也最高的部分。第三层是模型资产层管理基座模型、领域微调模型、Embedding模型、Rerank模型和安全审核模型。很多方案的PPT把这一层画成一个小方块实际业务效果恰恰由它决定同样的底座模型资产不同业务侧体感差异巨大。第四层是业务编排层把RAG服务、Agent编排、统一API网关、权限审计和用量计量收拢在一起对外暴露一个稳定的API入口。这样切分的价值在于骨架先立住算力归平台部模型归算法组业务归应用组各层独立演进不需要为了一个AI项目重写整个技术栈。2.2 选型先回答三个判断再看开源还是闭源立完四层骨架选型通常围绕三个判断展开。第一基座模型用开源私有化部署还是闭源API第二平台能力自建还是直接买公有云模型服务第三底座由集团统一建设还是各业务线自建。判断原则比较固定数据敏感度决定能不能走API调用规模决定自建成本是否划算组织现状决定统一底座能不能推得动。下面这组对比是开源私有化和闭源API在实际项目里的常见取舍对比项开源模型私有化部署闭源模型API调用数据合规数据不出域审计容易交代依赖供应商数据处理协议敏感场景受限成本结构一次性硬件投入与利用率强相关token计费规模上来后成本线性增长模型能力落后头部闭源模型节奏迭代快多模态能力更新频繁运维要求需要推理调优和GPU运维人力基本不碰底层适合场景金融、制造、研发代码等敏感环境营销、办公助手等非敏感场景值得留意的是现在不少数字底座最终走的是双轨制核心敏感场景用开源模型私有化兜底长尾场景和高阶能力用闭源API补充网关层统一路由和切换。多模态大模型能力也是一样底座里先留出接口能力到位再平滑接入。2.3 底座组件清单按最小闭环去排方案阶段不要急着上大而全的LLMOps平台先把最小闭环的组件按层排出来。下面这份清单里的组件名称可以换成团队熟悉的替代品但职责不要少layers: compute: - backend: kubernetes gpu-operator # 容器调度与GPU分配 - storage: juicefs / nfs # 模型权重与数据集共享存储 platform: - inference: vllm # OpenAI兼容推理服务 - vector-db: milvus # RAG向量检索 - finetune: llamafactory # LoRA/QLoRA微调作业 - registry: harbor modelscope # 模型文件版本管理 capability: - rag: question-answering-pipeline - agent: function-calling-orchestrator - gateway: unified-api / auth / throttle这份清单的排布逻辑是算力在最底层平台层承载所有模型类任务能力层对业务封装RAG和Agent能力。网关放在业务编排层而不是平台层是因为它要把模型路由、鉴权、限流、计量集中在一个出口业务方只认一个API地址。底座能不能立住就看这一层是否真正收口。3. 模型服务层落地用vLLM把大模型部署成统一推理服务3.1 推理引擎选vLLM的理由模型服务层是最直接影响体验的一层。底座里所有上层能力最终都要落到模型推理上RAG要调用模型Agent编排要调用模型业务侧接入也要调用模型。这一层的吞吐和延迟稳定性决定了整个底座的口碑。开源推理引擎里vLLM几乎是本地部署大模型的首选原因有三PagedAttention管理KV Cache配合continuous batching把GPU利用率拉高提供OpenAI兼容API业务侧改一下base_url就能接进来社区迭代快量化、多模态、多卡并行这些能力都能跟上。底座平台层的定位是统一出口vLLM的兼容性正好踩在这个点上。3.2 vLLM部署的最小命令与关键参数在GPU集群上起一个OpenAI兼容的推理服务最小命令是这个样子vllm serve Qwen/Qwen2.5-72B-Instruct \ --tensor-parallel-size 4 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --quantization awq \ --served-model-name qwen72b-chat \ --port 8001 \ --trust-remote-code这段命令做了四件事用张量并行把72B模型拆到4张卡上跑把输入输出总长度上限设为32768把显存留给KV Cache的比例调到90%用AWQ量化降低每张卡的显存压力。--served-model-name qwen72b-chat是网关里要用的对外模型名它和模型仓库里的名字可以不一致灰度时不用动业务代码。--trust-remote-code只在模型仓库可信时加第三方权重上传来源要先人工审查再启动。实际调参时下面几个参数是排障最常动的参数默认值影响面调参建议--tensor-parallel-size1单实例能装多大模型72B级别至少4卡起步--max-model-len模型默认输入输出总长度直接决定显存占用长文档场景显式调大--gpu-memory-utilization0.9留给KV Cache的显存比例显存吃紧先换量化再降这个值--max-num-seqs256单实例最大并发序列数延迟敏感场景调到64左右提示想要在模型服务层加一道保护可以把--max-num-seqs从256调低到64延迟敏感的业务宁可排队也不要让单实例超载拖垮所有请求。3.3 用统一网关把模型路由和灰度收口底座对外不能直接暴露vLLM实例否则业务绕过网关直连升级、审计、计量全部失控。常见做法是在网关维护一张模型路由表每个逻辑模型名对应一个后端服务并支持按权重灰度切换逻辑模型名后端地址当前权重说明qwen72b-chatvllm-instance-1:8001100%主力问答模型code-7bvllm-instance-2:8002100%代码生成专用qwen-legacyvllm-instance-3:8003灰度10%老版本流量缓慢回收网关还要统一做三件事API Key鉴权、按业务线配额限流、token用量计量与对账。验证链路连通的最小命令是直接模拟一次业务调用确认路由、鉴权和计量都正常curl -s http://gateway:8000/v1/chat/completions \ -H Authorization: Bearer sk-xxx \ -H Content-Type: application/json \ -d {model:qwen72b-chat,messages:[{role:user,content:测试网关连通性}],max_tokens:64}这里的sk-xxx是网关下发的测试密钥真实环境要按业务线独立下发便于审计和成本分摊。返回体里要核对model字段是不是命中了预期路由而不是只看HTTP状态码。3.4 并发上不去先查这三个指标本地部署大模型后排障第一步不是改参数而是看指标。vLLM自带Prometheus指标端点最有用的两个是curl -s http://localhost:8001/metrics | grep -E vllm:num_requests_running|vllm:gpu_cache_usage_percnum_requests_running表示正在处理的请求数如果长期贴近max-num-seqs说明实例已经满载排队时间会快速上升gpu_cache_usage_perc表示KV Cache利用率接近1说明显存跑满优先检查是不是输入长度异常偏长。三个指标的经验对应关系是cache打满看max-model-len和量化方式请求排队看max-num-seqs和副本数TTFT变慢看tensor-parallel-size是否匹配卡间通信带宽。另外压测一定要用业务侧真实prompt分布固定长度的短文本压出来的结果没有参考价值。4. 数据接入与RAG知识库让数字底座接上企业存量数据4.1 企业数据接入底座先分清三种形态大模型在企业落地的第一条路几乎都是RAG不训练模型把知识喂给底座让模型带着企业数据回答。RAG落地快但数据接入不能想当然企业数据通常分三种形态。结构化数据在库里通过SQL查询或CDC同步RAG检索的不是数据本身而是描述库表和字段的元数据非结构化数据是文档先解析成文本再切分入库实时数据走Kafka这类流管道用于补充动态上下文。底座里常见是一个统一的数据接入层把三种来源归一成文档片段加向量的格式交给RAG服务统一消费。4.2 文档入库的RAG最小管道最简链路是加载文档、切分、向量化、写向量库四步代码量不大from langchain_huggingface import HuggingFaceEmbeddings from langchain_milvus import Milvus from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.document_loaders import DirectoryLoader # 1. 加载指定目录下的文档 loader DirectoryLoader(./docs, glob*.md) docs loader.load() # 2. 按语义边界切分而不是按固定字符硬切 splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap64, separators[\n\n, \n, 。, , ] ) chunks splitter.split_documents(docs) # 3. 中文检索用BGE系列Embedding比通用英文模型稳 embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5 ) # 4. 写入Milvus集合 vector_store Milvus.from_documents( chunks, embeddings, connection_args{host: milvus, port: 19530}, collection_nameenterprise_kb )这段代码的关键点有三个。第一切分器用RecursiveCharacterTextSplitterseparators按中文标点优先排序避免一句话被拦腰切断chunk_overlap的意义是保留跨切片的上下文线索。第二Embedding模型用BGE系列中文检索效果明显优于通用英文Embedding中小规模场景bge-large-zh-v1.5就够多语种或长文本场景再看bge-m3。第三connection_args指向Milvus服务地址collection_name按知识域分开建集合便于权限控制和增量更新。4.3 切分参数不能一套走天下一份方案里最常见的坑是所有文档统一用一套chunk_size。十类文档用一个512合同问答上下文撕裂技术手册又被截断。比较实用的做法是按文档类型分开配置文档类型chunk_sizechunk_overlap切分理由合同、制度条款300–51230–64条款是独立语义单元切太碎丢失约束关系技术手册、方案800–1200100–150强依赖上下文切细了召回率高但答不准客服工单、对话记录150–30020–40短文本粒度细匹配查询意图更准调切分参数比反复换Embedding模型更见效。上线前花半天把存量文档按类型过一遍切分RAG的命中率通常有肉眼可见的提升。切分后建议做一次抽样检查确认没有把表格拆散、没有把条款编号和正文分开。4.4 检索召回不理想按顺序排查这四个位置文档入完库问答效果不行按顺序查四件事。第一查询和文档的术语体系是否一致不一致做query改写或用同义词扩展。第二Embedding模型是否匹配业务领域用50条真实问题逐条验证Hit3指标。第三向量检索的top_k结果直接透传不够稳加一层Rerank重排from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-v2-m3) pairs [(query, doc) for doc in candidates] scores reranker.predict(pairs)Rerank模型直接对查询-文档对打分把向量检索召回的几十条候选重新排序top5准确率通常提升明显。代价是额外时延几十条候选大约多几十毫秒对实时问答可接受但底座里不要同时挂多个Rerank模型。第四做增量更新文档变更后重算切片并upsert到向量库防止旧版本内容一直霸占召回。四件事做完还不行才考虑动Embedding模型。5. 模型微调与Agent编排在底座上长出企业自己的业务能力5.1 先判断该不该微调再谈框架RAG解决模型不知道微调解决模型不会按你的规矩做事。企业里真正该微调的通常是三类场景业务领域术语体系强、通用模型答不准输出格式有硬约束比如合同审查要按固定条目返回行为规范需要对齐比如客服不能乱承诺。反过来数据量不足、知识要实时更新、需求变化快的场景微调都不合适。下沉到实操我一般建议先用基座模型加RAG跑通业务收集足够多的坏case之后再决定是否微调。一上来就微调的数据质量和数据量都是过不去的坎。5.2 用LLaMA-Factory跑LoRA微调的命令与数据格式底座里的微调平台最常用的开源工具是LLaMA-Factory它把SFT、DPO等流程封装成命令行和WebUI配好数据集就能跑。微调数据用JSONL一行一条示例是这个样子{instruction: 根据合同条款判断付款条件是否满足, input: 合同编号HT-2024-001项目已验收……, output: 根据合同第5.2条验收合格后30日内付款……}指令、输入、输出三段式是SFT最通用的格式instruction写任务描述input写业务输入output写期望输出。数据量上一类任务起步500到1000条低于这个量级先别微调优先优化RAG。然后启动LoRA微调llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --peft lora \ --dataset contract_review \ --template qwen \ --output_dir ./checkpoints/qwen7b-contract-lora \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 1e-4 \ --num_train_epochs 3 \ --lora_rank 16这里的关键设计是冻结原模型权重只训练低秩适配器7B模型在一张24G显存的卡上也能跑。per_device_train_batch_size是单卡批大小gradient_accumulation_steps做梯度累积两者相乘才是有效批大小。learning_rate常用区间是1e-4到2e-4超出容易灾难遗忘。几个常见超参的经验值如下参数常用区间说明lora_rank8–32任务复杂取大简单取小learning_rate1e-4–2e-4超过2e-4容易灾难遗忘num_train_epochs2–5数据量小先跑2轮看loss走势max_seq_length2048–4096要和推理侧max-model-len匹配训练完不是直接部署要先把LoRA适配器合并回基座模型再注册到模型仓库llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path ./checkpoints/qwen7b-contract-lora \ --template qwen \ --export_dir ./merged/qwen7b-contract提示导出时基座模型必须和训练时完全一致版本不一致会出现tokenizer错位症状是回答开头乱码、中间莫名截断这类问题最难排查。合并后的权重上传模型仓库在网关路由表注册新版本按老版本100%、新版本5%起步、再逐步放量的节奏灰度。5.3 Agent编排让模型按业务规则调用工具而不是全自治微调解决单段式任务企业真实流程往往是多步的查合同、比对条款、再给出结论。Agent编排就是在这套流程上加一层可控的工具调用。底座里落地Agent建议从function calling开始先固定流程模板再谈自治from openai import OpenAI client OpenAI(base_urlhttp://gateway:8000/v1, api_keysk-xxx) tools [{ type: function, function: { name: query_contract, description: 按合同编号查询合同文本中的指定条款, parameters: { type: object, properties: { doc_id: {type: string, description: 合同编号}, item: {type: string, description: 条款关键词} }, required: [doc_id] } } }] resp client.chat.completions.create( modelqwen72b-chat, messages[{role: user, content: 查一下HT-2024-001的付款条件}], toolstools, tool_choiceauto )这段代码里模型不直接执行查询而是返回tool_calls由底座编排层去调用授权的业务接口把结果回填给模型生成最终回答。编排层的设计重点有三个工具定义要有JSON Schema校验和权限绑定工具执行要设超时和重试执行结果要截断长度再回填。企业Agent别一上来就追求完全自治先固定任务模板、限定工具范围、保留人工确认节点跑稳三个月再逐步放开。这一步的工程可靠性决定底座从能问答走到能干活。6. 数字底座上线后三个验证手段和一个成本压法6.1 评测集先行模型升级必须过门槛底座上线后的第一件正事是建一份golden评测集。从真实业务流量里攒50到200条标注数据每条含输入、期望输出和评分维度答案准确率、格式规范率、拒答正确率。每次模型升级、prompt调整、RAG参数变更都跑同一份评测集并记录结果。自动评测可以用LLM as judge打分但每周抽样人工复核一次防止评分模型被自己的话术带偏也防止评测集被过拟合。6.2 压测看三个数字TTFT、TPOT、吞吐第二件正事是压测。vLLM自带serving benchmark脚本可以直接对网关做端到端压测python benchmarks/benchmark_serving.py \ --model qwen72b-chat \ --base-url http://gateway:8000/v1 \ --num-prompts 500 \ --request-rate 20 \ --max-concurrency 64压测报告里固定看三个数字TTFT首token时延TPOT每token生成时延整体吞吐。内部办公场景经验值是TTFT低于2秒客服场景低于1.5秒超过就要排查是上游排队、显存瓶颈还是网卡带宽。压测的prompt必须来自业务真实分布同时包含长短文本、中英文混合、长上下文检索否则测出的数据不能用于容量规划。6.3 成本压不下来优先动这三个开关到最后底座通常会发现模型能力不是瓶颈成本才是。三个开关按实施顺序排列手段收益踩坑点AWQ/GPTQ量化显存占用接近减半复杂数学推理质量下降冷热模型分流高频场景成本明显下降分流规则要可观测、可回滚语义缓存重复问题零推理成本只用于静态知识问答开放生成禁用这三个手段常被误解为用质量换成本实际上对绝大多数业务场景量化后的质量损耗很小冷热分流靠网关规则实现规则要能统计命中率和回滚语义缓存只适用于RAG知识问答这类确定性场景开放生成不能用。把评测集通过率、压测TTFT、每万token成本三个数字固定进每日巡检后续任何模型替换、参数调整都有基线可对齐。这三个数字不达标之前不要谈新场景扩容。本文还有配套的精品资源点击获取