1. 项目概述这不是一次常规的模型发布而是一次基础设施层的静默升级“DeepSeek V4 Under the Hood - Infra局部简评”这个标题里“Under the Hood”是关键词它直指引擎舱——不是看车标、不是试加速、更不是比油耗而是掀开引擎盖拧开机油盖用手指蘸一点油渍闻一闻有没有焦糊味再拿游标卡尺量一量活塞环的间隙。V4不是V3.5的简单迭代它是一次面向生产级AI服务交付的底层重构。我过去三年在三家不同规模的AI原生公司做过Infra团队的技术负责人部署过从Llama 2到Qwen 2再到Phi-3的全系开源模型也亲手把内部大模型服务从单机Flask API一路推到百节点K8s集群GPU池化调度。所以当我看到GitLab上那个ai-native/infra/apppipeline仓库的CI/CD配置页以及社区里反复刷屏的failed to start: main: failed to load config files: [config.json] infra/co报错时第一反应不是去查文档而是立刻打开终端git clone下来grep -r config.json .然后盯着infra/co这个路径看了三分钟——这根本不是个文件夹名这是个缩写是config override的简写是Infra团队在灰度发布时为不同环境dev/staging/prod预留的配置覆盖入口。V4的Infra设计哲学非常清晰模型即服务MaaS的原子单位不再是.bin或.safetensors文件而是带完整运行时契约的容器镜像部署动作也不再是docker run而是kubectl apply -f触发的一整套声明式资源编排。这意味着你本地跑通deepseek-v4-pro的--quantize awq参数和你在K8s里让ds-v4-pro-inference这个Deployment稳定扛住每秒200 QPS中间隔着的不是一条鸿沟而是一整套被重新定义的交付链路。热词里反复出现的codex接入deepseek v4、vscode安装claude deepseek v4、cursor接入deepseek本质上都是这条新链路的下游消费端。它们之所以能“接入”不是因为API兼容而是因为V4的Infra层在model-server组件里把OpenAI兼容层/v1/chat/completions和DeepSeek原生协议/v1/deepseek/completions做成了可插拔的网关模块。所以当你在VS Code里切换Claude Code的后端模型为deepseek-v4-pro时你真正调用的是Infra层一个叫router-gateway的Service它根据你的model参数动态路由到背后不同的inference-pod集群。这才是“Under the Hood”的真实含义V4的威力不在于它多了一个MoE专家而在于它让整个AI服务的交付、观测、扩缩容第一次拥有了和云原生应用同等的成熟度。这篇文章就是带你亲手拧开这个引擎盖。2. Infra核心设计思路从“模型部署”到“服务编排”的范式迁移2.1 为什么必须抛弃“先跑通模型再套服务”的老路在我最早接触大模型Infra时标准流程是下载模型权重 → 用transformers加载 → 写一个FastAPI接口 →uvicorn启动 → 用nginx反向代理 → 最后加个prometheusexporter。这套流程在POC阶段很高效但一旦进入真实业务线问题就集中爆发。最典型的是api error: 400 the supported api model names are deepseek-v4-pro or deepseek这个报错。表面看是客户端传了错误的model参数但深挖下去你会发现这个校验逻辑根本不在model-server里而是在router-gateway的model-registry模块中。model-registry是一个独立的微服务它从etcd里读取所有已注册模型的元数据包括name、version、quantization、min_gpu_memory_gb、max_concurrent_requests等。当router-gateway收到请求它会先查model-registry确认该model存在且状态为active才会将请求转发给下游。如果model-registry里没有deepseek-v4-pro这个条目或者它的状态是pending正在加载那么router-gateway就会直接返回400。这个设计彻底改变了问题定位的路径以前你遇到400第一反应是检查model-server的日志现在你必须先kubectl exec -it router-gateway-xxx -- curl http://model-registry:8080/v1/models看返回的JSON里有没有你要的模型。这就是范式迁移的核心——Infra不再服务于模型而是模型必须适配Infra的契约。V4的model-server镜像强制要求在启动时必须通过环境变量MODEL_REGISTRY_URL指向model-registry服务并在加载完模型后主动向其注册自己的健康状态和能力清单。这就像一个新员工入职必须先在HR系统里完成信息录入和权限申请才能拿到工牌去打卡。热词里频繁出现的local deployment deepseek很多人卡在第一步就是因为没意识到本地单机部署V4你不仅要跑model-server还必须同时启动model-registry、router-gateway、metrics-collector这三个配套服务。它们不是可选组件而是V4 Infra的最小可行单元MVP。我见过太多团队花三天时间把model-server在本地跑起来了结果发现curl http://localhost:8000/v1/chat/completions返回404最后排查了一整天才发现router-gateway根本没启动所有流量都直接打到了model-server的/health端点上而model-server默认只暴露/health和/docs真正的API路径是被router-gateway代理的。2.2 “Infra/co”路径的真相配置覆盖Config Override机制详解网络热词里那个让人困惑的infra/co正是V4 Infra最精巧的设计之一。它不是一个物理目录而是一个逻辑命名空间代表“Configuration Override”。V4的整个配置体系遵循Kubernetes原生的ConfigMap和Secret管理范式但做了两层抽象第一层是base配置存放在infra/config/base/下包含所有环境通用的参数比如model_server.image.repository、router_gateway.timeout_ms第二层就是co它下面有dev/、staging/、prod/三个子目录每个子目录里只存放该环境特有的、需要覆盖base的参数。例如在infra/config/base/model-server.yaml里你可能看到resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1而在infra/config/co/dev/model-server.yaml里你只会看到resources: limits: nvidia.com/gpu: 0.5 requests: nvidia.com/gpu: 0.5V4的CI/CD流水线在构建model-server镜像时会执行一个叫config-merge的脚本。这个脚本会递归遍历infra/config/目录将base下的所有YAML文件作为基础然后按环境名如dev去infra/config/co/dev/下寻找同名文件进行深度合并deep merge最终生成一个完整的、环境专属的values.yaml供Helm Chart使用。这就是为什么你在GitLab CI的.gitlab-ci.yml里会看到类似这样的步骤deploy-dev: stage: deploy script: - ./scripts/config-merge.sh dev - helm upgrade --install ds-v4-pro-inference ./charts/model-server --namespace dev --values ./infra/config/merged/dev/values.yamlconfig-merge.sh脚本的核心逻辑是用yq工具实现的。它不是简单的cat base.yaml co/dev.yaml merged.yaml而是yq eval-all select(fileIndex 0) * select(fileIndex 1) base.yaml co/dev/model-server.yaml。这种深度合并保证了dev环境可以只改自己关心的几个参数而不会影响base里定义的全局策略。这也是failed to start: main: failed to load config files: [config.json] infra/co报错的根源——当model-server容器启动时它会尝试从/app/config/目录下加载config.json。这个目录是由K8s的VolumeMount挂载进来的其数据源正是config-merge.sh生成的那个merged/dev/values.yaml经过helm template渲染后再由kustomize或helm的--set-file参数注入到容器内。如果config-merge.sh执行失败或者infra/config/co/dev/下缺少某个必需的覆盖文件那么/app/config/config.json就无法生成model-server自然就起不来了。所以当你看到这个报错第一件事不是去改model-server的代码而是去CI日志里找到config-merge.sh那一步的输出看它是否成功完成了合并。2.3 模型服务的“原子性”与“契约化”V4 Infra的交付标准V4 Infra对“一个可用的模型服务”的定义远比我们过去理解的要严格。它不是一个能curl通的HTTP端口而是一组满足特定SLA服务等级协议的、可观测的、可自动扩缩容的K8s资源集合。这个集合的最小单元我们称之为一个ModelService它由以下四个核心K8s资源构成Deployment: 运行model-server容器的主体负责模型的加载和推理。Service: 为Deployment提供稳定的网络入口router-gateway通过这个Service的ClusterIP来发现和调用它。HorizontalPodAutoscaler (HPA): 基于metrics-collector上报的requests_per_second和gpu_utilization_percent两个指标自动调整Deployment的副本数。PodDisruptionBudget (PDB): 确保在K8s集群维护如节点升级时该ModelService至少有1个Pod保持在线避免服务中断。这四个资源必须作为一个整体被kubectl apply并且它们的labels和selectors必须严格匹配。例如Deployment的spec.selector.matchLabels必须和Service的spec.selector完全一致也必须和HPA的spec.scaleTargetRef.name指向同一个Deployment。V4的CI/CD流水线正是通过一个统一的Helm Chart来管理这四个资源。Chart的values.yaml里modelService是一个顶级对象其结构如下modelService: name: ds-v4-pro-inference model: deepseek-v4-pro quantization: awq # ... 其他参数 hpa: minReplicas: 1 maxReplicas: 10 targetCPUUtilizationPercentage: 70 pdb: minAvailable: 1当helm upgrade执行时Chart模板会根据这个values.yaml自动生成对应的Deployment、Service、HPA和PDBYAML文件。这种“契约化”的交付彻底消除了过去那种“手动kubectl scale”、“临时kubectl edit”带来的配置漂移风险。热词里提到的deepseek v4 flash a100指的就是在modelService的resources配置里将nvidia.com/gpu的limits设为a100这会触发K8s的GPU设备插件将A100显卡精确地分配给该Pod。而deepseek v4 pro怎么配合vscode写代码其背后的技术支撑正是这个ModelService的HPA。当VS Code里的Copilot Chat插件发起大量并发请求时HPA会检测到requests_per_second超过阈值自动将ds-v4-pro-inference的副本数从1扩到3从而平滑地承接住流量洪峰。这种体验是旧式单体部署永远无法提供的。3. 核心细节解析从GitLab CI/CD配置到K8s集群部署的实操要点3.1 GitLab CI/CD流水线的标准化结构与关键环节要将V4服务自动部署到dev环境的K8s集群你必须理解GitLab上那个ai-native/infra/apppipeline仓库的CI/CD配置逻辑。它的.gitlab-ci.yml文件绝非一个简单的script列表而是一个精心编排的、符合GitOps理念的自动化流水线。其核心结构分为四个阶段stage每个阶段都有明确的职责和准入条件test阶段这是流水线的第一道闸门。它不涉及任何外部环境只在CI Runner的Docker容器内运行。主要任务是lint-config: 使用yamllint和kubeval对infra/config/下的所有YAML文件进行语法和K8s Schema校验。这一步会捕获90%以上的配置错误比如resources.limits.cpu写成了2字符串而不是2整数或者service.type拼写成了CluseterIP。unit-test-model-server: 运行model-server项目的单元测试。这些测试会模拟model-registry的响应验证model-server在各种边界条件下如模型加载失败、输入token超长能否正确返回HTTP状态码和错误信息。security-scan: 使用trivy对model-server的基础镜像如python:3.11-slim进行CVE漏洞扫描。如果发现高危漏洞CVSS 7.0流水线会立即失败。build阶段这是流水线的“心脏”负责产出可部署的制品artifact。关键任务是build-model-server-image: 使用kaniko而非docker build在无Docker守护进程的CI环境中构建model-server的Docker镜像。kaniko的优势在于它完全在用户空间运行安全性更高且能完美集成到GitLab CI中。构建命令会指定--context为./model-server/并使用--dockerfile指向./model-server/Dockerfile。镜像的tag会严格按照$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA的格式生成确保每次提交都有唯一、可追溯的镜像ID。push-to-registry: 将构建好的镜像推送到公司的私有Docker Registry如Harbor。这一步需要CI_REGISTRY_USER和CI_REGISTRY_PASSWORD这两个预设的CI变量它们通常以Masked方式存储在GitLab的Settings CI/CD Variables中确保凭证安全。config-merge阶段这是V4 Infra区别于其他方案的标志性环节。它不产生制品但决定了最终部署的形态。关键任务是merge-config-for-dev: 执行./scripts/config-merge.sh dev。这个脚本会读取infra/config/base/和infra/config/co/dev/生成infra/config/merged/dev/values.yaml。脚本的输出会被artifacts指令保存下来供后续阶段使用。这是最关键的一步也是最容易出错的一步。我曾在一个项目中因为infra/config/co/dev/model-server.yaml里少了一个空格导致yq解析失败values.yaml为空后续所有部署都因helm找不到values而失败。因此我强烈建议在这个步骤后添加一个validate-merged-config的子任务用yq命令检查生成的values.yaml是否包含预期的modelService.name字段。deploy阶段这是流水线的“终点”将一切成果落地。关键任务是deploy-to-dev-k8s: 这是核心。它会执行helm upgrade --install ds-v4-pro-inference ./charts/model-server --namespace dev --values ./infra/config/merged/dev/values.yaml --set image.repository$CI_REGISTRY_IMAGE --set image.tag$CI_COMMIT_SHORT_SHA。注意这里--set参数覆盖了values.yaml里定义的镜像地址和Tag确保部署的是刚刚构建并推送的那个精确版本。--namespace dev指定了目标K8s命名空间。--install参数意味着如果ds-v4-pro-inference这个Release不存在就创建它如果存在就升级它。整个过程是幂等的idempotent多次执行效果相同这是GitOps可靠性的基石。提示为了防止误操作deploy阶段应该设置only: [main]即只在main分支的推送时才触发。对于dev环境的快速迭代可以额外配置一个deploy-dev-on-push的job其only规则为[dev]这样开发人员向dev分支推送代码就能自动部署到dev集群实现真正的持续交付CD。3.2 K8s集群侧的关键配置与环境准备CI/CD流水线再完美也需要K8s集群侧做好充分准备。一个未经良好配置的K8s集群是V4 Infra无法发挥威力的“瘸腿”平台。以下是我在多个生产环境踩坑后总结的、必须提前完成的六项关键配置GPU设备插件NVIDIA Device Plugin这是deepseek-v4-pro这类大模型服务的“氧气”。仅仅在节点上装好NVIDIA驱动是不够的。你必须在集群中部署nvidia-device-pluginDaemonSet。这个插件会向K8s API Server注册nvidia.com/gpu这个扩展资源。只有这样当你在Deployment的resources.limits里声明nvidia.com/gpu: 1时K8s调度器才知道必须把这个Pod调度到一台有空闲GPU的节点上。部署命令通常是kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.5/nvidia-device-plugin.yml。部署后用kubectl describe node node-name查看Capacity和Allocatable部分确认nvidia.com/gpu的数值正确。GPU共享与池化Optional but RecommendedA100等高端GPU价格昂贵让一个model-server独占一整张卡成本效益极低。V4 Infra支持vLLM后端它原生支持tensor parallelism和pipeline parallelism可以将一个大模型切分到多张卡上。但对于中小规模的dev环境更实用的是MIGMulti-Instance GPU或vGPU技术。例如在A100上启用MIG可以将其逻辑划分为7个大小为1g.5gb的实例。然后在model-service的values.yaml里将resources.limits.nvidia.com/gpu设为1g.5gb就能让多个轻量级的model-server共享一张物理A100。这需要在GPU节点上预先执行nvidia-smi -i 0 -mig 1来启用MIG模式。Ingress Controller与TLS终止router-gateway服务对外暴露的端口不应该直接用NodePort或LoadBalancer。正确的做法是通过Ingress资源将其暴露在标准的443端口下。你需要在集群中部署一个Ingress Controller如ingress-nginx或traefik并为其配置一个有效的TLS证书推荐使用cert-manager自动签发Lets Encrypt证书。Ingress资源的spec.rules部分应将host: api.deepseek.dev的/v1/*路径全部转发给router-gateway的Service。这样外部客户端就可以用https://api.deepseek.dev/v1/chat/completions来访问服务而无需关心背后的K8s内部网络。Metrics Collector与Prometheus StackHPA的自动扩缩容依赖于metrics-collector上报的指标。这个collector本身也是一个微服务它会定期curl各个model-server的/metrics端点抓取http_request_duration_seconds_count、gpu_memory_used_bytes等指标并将其推送给Prometheus。因此你必须在集群中部署Prometheus Operator并创建一个ServiceMonitor资源让Prometheus能够自动发现并抓取metrics-collector的指标。HPA的metrics配置会直接引用Prometheus中的指标名称例如external.metrics.prometheus.io/v1alpha1。RBAC权限精细化管理model-server容器在运行时需要一定的K8s API权限例如它需要get和listConfigMap以便动态加载配置需要patchEndpoints以便向model-registry注册自己的状态。这些权限不能通过给defaultServiceAccount赋予cluster-admin这种粗暴的方式解决。正确的做法是为model-server创建一个专用的ServiceAccount并绑定一个Role该Role只授予其运行所必需的、最小集的权限。这既是安全最佳实践也是V4 Infra设计文档中明确要求的。持久化存储PersistentVolume虽然V4的model-server本身是无状态的但它的上游model-registry服务需要一个持久化的数据库来存储模型元数据。V4 Infra默认推荐使用etcd因为它轻量、高可用、且与K8s原生集成。你需要为etcd部署一个StatefulSet并为其配置一个PersistentVolumeClaim指向一个可靠的存储后端如Ceph RBD或AWS EBS。etcd的数据目录/var/etcd/data必须挂载到这个PV上否则etcd重启后所有模型注册信息都会丢失导致整个服务不可用。3.3model-server容器镜像的构建与优化实战model-server镜像是V4 Infra的“肌肉”它的质量直接决定了服务的性能和稳定性。构建一个生产就绪的镜像远不止FROM python:3.11-slim这么简单。以下是我在实际项目中采用的、经过千次压测验证的构建策略基础镜像选择放弃python:3.11-slim改用nvidia/cuda:12.1.1-devel-ubuntu22.04。理由很直接slim镜像里没有gcc、make等编译工具而vLLM、flash-attn等高性能推理库在pip install时需要源码编译。在CI环境中现场编译会极大拖慢构建速度从2分钟变成20分钟且容易因内存不足而失败。cuda:12.1.1-devel镜像已经预装了所有CUDA开发所需的头文件和库pip install vllm会直接下载预编译的wheel包构建速度飞快。多阶段构建Multi-stage Build这是减小最终镜像体积的黄金法则。整个Dockerfile分为三个阶段builder: 在此阶段安装所有构建依赖build-essential,python3-dev,libssl-dev和Python包vllm,transformers,torch。torch的安装必须指定--index-url https://download.pytorch.org/whl/cu121以确保下载到CUDA 12.1版本的预编译包。runtime: 这是最终的运行时镜像。FROM nvidia/cuda:12.1.1-runtime-ubuntu22.04。它只包含运行model-server所需的最小运行时环境没有gcc等编译工具体积比devel镜像小一半。copy: 将builder阶段中/usr/local/lib/python3.11/site-packages/下的所有已编译好的Python包COPY到runtime阶段的对应目录下。这样最终镜像里只有运行时需要的二进制文件没有源码和编译中间产物。模型权重的加载优化V4的model-server支持两种模型加载方式huggingface和s3。对于dev环境我强烈推荐使用s3方式。原因在于huggingface方式会在容器启动时从HF Hub下载整个模型数十GB这会导致Pod启动时间长达10分钟以上严重拖慢CI/CD反馈循环。而s3方式只需要在values.yaml里配置model.s3_uri: s3://my-bucket/models/deepseek-v4-pro/model-server会利用boto3的StreamingBody边下载边加载启动时间可压缩到90秒以内。为此你需要在runtime镜像中pip install boto3并在K8s的Pod定义中通过serviceAccount绑定一个拥有S3ReadOnlyAccess权限的IAM角色AWS或Secret其他云。启动脚本的健壮性增强model-server的entrypoint.sh脚本不能只是一个简单的exec python app.py。它必须包含健康检查重试在exec之前先循环curl -f http://model-registry:8080/health直到model-registry就绪。否则model-server可能会因为model-registry还没启动而直接崩溃退出。信号透传exec命令必须使用exec $的形式确保SIGTERM信号能正确传递给Python进程从而触发优雅关闭graceful shutdown释放GPU显存。日志格式化将stdout和stderr统一通过jq格式化为JSON方便fluentd或filebeat收集例如exec python app.py 21 | jq -c {time: now|strftime(%Y-%m-%dT%H:%M:%SZ), level: INFO, message: .}。4. 实操过程手把手完成从零到dev环境K8s集群的全自动部署4.1 环境初始化与前置依赖安装在开始真正的部署之前你必须确保本地开发机和目标K8s集群都处于“待命”状态。这不是一个可跳过的步骤而是整个自动化流程的基石。我将这个过程拆解为三个独立的、可验证的环节环节一本地开发机的“武器库”准备你的笔记本电脑是整个CI/CD流水线的“指挥中心”。它不需要运行K8s但必须装齐所有用于本地验证和调试的工具。请按顺序执行以下命令以Ubuntu 22.04为例# 1. 安装基础工具链 sudo apt update sudo apt install -y curl wget git gnupg2 software-properties-common # 2. 安装kubectlK8s命令行工具 curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl chmod x kubectl sudo mv kubectl /usr/local/bin/ # 3. 安装HelmK8s包管理器 curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash # 4. 安装yqYAML处理神器比sed强大百倍 sudo snap install yq # 5. 安装trivy容器安全扫描器 curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin # 6. 验证安装 kubectl version --client helm version yq --version trivy --version注意yq的版本至关重要。V4 Infra的config-merge.sh脚本依赖yq4.x版本的eval-all功能。如果你安装的是yq3.xeval-all命令会不存在导致脚本失败。务必通过snap或brewMac安装最新版。环节二GitLab CI Runner的配置与验证CI/CD的“工人”是GitLab Runner。它必须被正确注册到你的GitLab项目中并具备执行所有构建任务的能力。登录到你的GitLab服务器进入Settings CI/CD Runners点击Expand然后点击New project runner。在注册页面你会得到一个Registration token和一个URL。在你准备好的Runner服务器一台干净的Ubuntu 22.04虚拟机上执行# 1. 下载并安装GitLab Runner curl -L --output /tmp/gitlab-runner.deb https://gitlab-runner-downloads.s3.amazonaws.com/latest/debian-packages/gitlab-runner_amd64.deb sudo dpkg -i /tmp/gitlab-runner.deb # 2. 注册Runner sudo gitlab-runner register \ --non-interactive \ --url https://your-gitlab-domain.com/ \ --registration-token YOUR_REGISTRATION_TOKEN \ --executor docker \ --docker-image alpine:latest \ --description v4-infra-runner \ --tag-list v4,infra,k8s \ --run-untaggedfalse \ --lockedfalse \ --access-levelnot_protected # 3. 启动Runner服务 sudo gitlab-runner start注册完成后回到GitLab的Runners页面你应该能看到一个绿色的Online状态的Runner。这是CI/CD能够运转的前提。如果状态是Offline请检查Runner服务器的网络是否能访问GitLab服务器以及/etc/gitlab-runner/config.toml文件中concurrent的值是否足够建议设为10。环节三devK8s集群的“体检报告”在向集群部署任何东西之前先运行一个全面的“体检”。这能帮你规避90%的部署失败。请在你的本地开发机上执行以下检查清单连接性检查kubectl --contextdev get nodes。你应该能看到至少一个Ready状态的节点。如果报错The connection to the server was refused说明你的kubeconfig文件没有正确配置dev上下文或者集群API Server不可达。GPU插件检查kubectl --contextdev get daemonset -n kube-system | grep nvidia。你应该能看到nvidia-device-plugin-daemonset。然后kubectl --contextdev describe node node-name | grep -A 5 nvidia.com/gpu确认Allocatable的值大于0。存储类检查kubectl --contextdev get storageclass。你应该能看到至少一个DEFAULT标记的StorageClass。这是etcdStatefulSet能够成功创建PV的前提。Ingress Controller检查kubectl --contextdev get ingresscontrollers -n openshift-ingress-operator如果是OpenShift或kubectl --contextdev get pods -n ingress-nginx | grep nginx-ingress-controller如果是ingress-nginx。确保Controller的Pod是Running状态。DNS与网络策略检查kubectl --contextdev run -it --rm --restartNever test-dns --imagebusybox:1.31 -- nslookup model-registry.dev.svc.cluster.local。如果能成功解析出IP说明集群内部DNS工作正常。如果失败可能是CoreDNS配置错误或网络策略NetworkPolicy阻止了DNS查询。完成这三项初始化后你的环境就达到了“可部署”的最低标准。接下来才是真正的战斗。4.2 从GitLab仓库克隆到首次CI/CD流水线触发现在让我们把目光转向那个神秘的ai-native/infra/apppipeline仓库。假设它的URL是https://gitlab.deepwisdomai.com/ai-native/infra/apppipeline。请在你的本地开发机上执行以下操作# 1. 克隆仓库 git clone https://gitlab.deepwisdomai.com/ai-native/infra/apppipeline.git cd apppipeline # 2. 查看项目结构这是理解一切的起点 tree -L 2 # 输出应该类似于 # . # ├── .gitlab-ci.yml # CI/CD流水线定义 # ├── charts/ # Helm Charts目录 # │ └── model-server/ # model-server的Helm Chart # ├── infra/ # Infra核心配置目录 # │ ├── config/ # 所有配置文件 # │ │ ├── base/ # 基础配置 # │ │ └── co/ # 配置覆盖dev/staging/prod # │ └── scripts/ # 辅助脚本config-merge.sh等 # ├── model-server/ # model-server应用源码 # └── README.md关键洞察infra/config/co/dev/目录就是你为dev环境定制的“战场地图”。打开它你会看到几个YAML文件model-server.yaml: 定义model-server的资源配置、模型路径、量化方式等。router-gateway.yaml: 定义router-gateway的超时时间、重试策略、限