AI工程从零构建：裸金属到可交付模型的七层实战-平芜编程栈

1. 这不是“搭积木”，而是亲手锻造AI系统的完整工程链

“AI Engineering from Scratch”——看到这个标题，很多人第一反应是：又要写个LLM调用脚本？配个Streamlit前端？跑通一个Hugging Face示例就叫“从零开始”？不。我带过6支AI产品交付团队，亲手交付过17个落地项目，其中12个要求“全栈自研、无外部API依赖、可审计、可复现、可移交”。所谓“from scratch”，在我这儿有明确定义：从裸金属或干净云实例出发，不依赖任何预封装AI服务（包括但不限于托管推理API、SaaS模型平台、一键部署镜像），所有组件——数据管道、特征工程、训练框架、模型服务、监控告警、可观测性——全部由团队自主选型、配置、集成、验证，并通过生产环境压力测试与业务指标验收。这不是学术实验，是工程交付的底线。关键词“ai-engineering”和“from-scratch”不是修饰词，是验收 checklist 上的硬性条目。它面向三类人：一是正在组建AI基建团队的技术负责人，需要知道哪些环节绝不能外包；二是准备跳槽AI Infra岗位的工程师，得清楚真实产线里“训练一个模型”背后要填多少坑；三是创业公司CTO，在融资前必须自己跑通这条链，否则技术尽调时会被问到哑口无言。接下来的内容，没有概念铺陈，没有PPT式架构图，只有我在深圳某智能硬件厂实操78天、从零部署视觉质检模型的真实日志、参数选择依据、踩坑记录和最终压测数据。所有步骤均可在AWS EC2 t3.2xlarge（或同等配置国产云实例）上复现，不依赖GPU集群，不预装任何AI平台。

2. 为什么必须放弃“开箱即用”，选择真正从零构建？

2.1 “开箱即用”的幻觉：三个被掩盖的成本黑洞

我见过太多团队在Q1高喊“AI赋能”，Q2发现账单爆炸，Q3紧急重构。根源在于对“开箱即用”工具链的误判。以主流托管服务为例，表面看是省事，实际埋了三颗雷：

第一颗雷：数据主权与合规成本隐形化。某医疗客户用某国际云厂商的AutoML服务训练病理图像模型，训练数据需上传至其境外节点。等他们拿到等保三级认证报告才发现，原始影像数据出境需单独申报，而该服务根本不提供数据本地化处理选项。我们接手后，用Kubeflow Pipeline + MinIO自建存储，把数据预处理、标注清洗、增强生成全部放在VPC内完成，虽然多花了11人日，但避免了后续可能面临的百万级合规整改费用。这里的关键不是“能不能做”，而是“有没有选择权”。

第二颗雷：模型迭代周期被平台绑架。某电商推荐团队用某SaaS平台，模型A/B测试需等平台排期，平均响应时间4.7小时。而他们大促期间需每2小时根据实时GMV调整召回策略。我们替换成MLflow + Airflow调度，将特征版本切换、模型热加载、效果回滚压缩到92秒内。这不是性能数字游戏，是直接影响GMV转化率的工程能力。平台提供的“便捷”，本质是用你的迭代自由度换来的。

第三颗雷：故障归因能力彻底丧失。去年某金融风控模型线上准确率突降0.3%，平台只返回“服务异常”错误码。我们花3天查日志，最后发现是平台底层TensorRT版本升级导致FP16精度溢出，而他们的变更日志根本没提这茬。自建方案下，我们用Prometheus抓取PyTorch Profiler的CUDA kernel耗时、用Jaeger追踪每个tensor的shape变化路径，57分钟定位到torch.nn.functional.interpolate在特定输入尺寸下的双线性插值数值偏差。工程的本质，是把黑盒变成白盒的过程。

2.2 “From Scratch”的真实价值：不是重复造轮子，而是掌握决策权

有人问：“Kubeflow、MLflow、DVC这些开源项目不是已经很成熟了吗？为什么不算‘from scratch’？” 这是个关键误解。“From Scratch”的核心，不是拒绝所有开源组件，而是拒绝“组件即解决方案”的思维。我们用Kubeflow，但会重写其Pipeline编译器，使其支持动态资源申请（GPU显存按batch size自动伸缩）；我们用MLflow，但剥离其UI模块，只保留tracking server，用Grafana+Alertmanager重构整个可观测体系；我们用DVC，但禁用其默认的云存储后端，强制所有数据版本哈希绑定到Git LFS的SHA256校验值。这种“用而不赖”的态度，才是工程化的起点。

真正的“from scratch”体现在三个不可妥协的决策点上：

数据契约（Data Contract）必须手写：不是靠平台自动生成schema，而是用Pydantic定义每个特征的物理类型、业务含义、缺失值语义、更新频率。例如，user_last_purchase_days_ago: int = Field(ge=0, le=365, description="用户距上次购买天数，0表示今日购买，NULL表示从未购买")。这个字段在特征仓库、训练代码、线上服务、BI报表中必须完全一致，差一个字符就是线上事故。
模型接口协议必须手绘：不用OpenAPI自动生成，而是用Protocol Buffers v3定义.proto文件，明确指定每个tensor的shape、dtype、memory layout（row-major还是channel-first）、量化范围（int8需标定min/max）。某次我们发现线上服务用NHWC格式喂给模型，而训练时用NCHW，导致所有预测结果错位，根源就是接口协议没约定内存布局。
资源隔离策略必须手配：不用K8s默认的namespace隔离，而是为每个pipeline stage（data ingestion, feature gen, train, eval, serve）分配独立的cgroup v2 controller，限制CPU bandwidth、memory high watermark、IO weight。某次特征生成任务突发OOM，因未设memory.high，直接OOM Killer干掉了同节点的模型服务进程。自建方案下，我们用systemd-run --scope -p MemoryHigh=4G启动每个stage，故障影响半径控制在单stage内。

这些决策，没有一个能在“一键部署”按钮里找到开关。它们是工程能力的刻度尺。

3. 核心细节解析：从裸机到可交付模型的七层炼金术

3.1 第一层：基础设施即代码（IaC）——用Terraform固化“零状态”

很多团队卡在第一步：环境不一致。开发说“我本地跑得好好的”，运维说“生产环境没这库”。我们的解法是：所有基础设施必须通过Terraform代码声明，且禁止任何手动干预。在AWS上，我们用aws_instance资源创建EC2，但关键在provider配置：

provider "aws" { region = "cn-northwest-1" # 强制使用v2签名，避免某些国产GPU驱动兼容问题 skip_metadata_api_check = true # 禁用自动region探测，防止跨region调用 allowed_account_ids = ["123456789012"] }

更关键的是实例初始化脚本。我们不用cloud-init的复杂yaml，而是用bash函数封装：

# install_nvidia_driver.sh install_nvidia_driver() { local driver_version="535.104.05" # 检查内核版本是否匹配，不匹配则报错退出，不自动降级 if ! uname -r | grep -q "5.10.0-25-amd64"; then echo "ERROR: Kernel mismatch. Expected 5.10.0-25-amd64, got $(uname -r)" exit 1 fi # 下载驱动前先停用nouveau，且写入blacklist.conf永久生效 echo "blacklist nouveau" >> /etc/modprobe.d/blacklist-nouveau.conf dracut --force # 驱动安装后验证CUDA_VISIBLE_DEVICES可见性 nvidia-smi -L | wc -l }

这个脚本的价值不在代码本身，而在其背后的工程纪律：每次terraform apply，都是一次完整的、可验证的、幂等的环境重建。我们甚至把terraform state文件加密后存入HashiCorp Vault，每次apply前先解密比对，确保state不被篡改。这层看似枯燥的IaC，是后续所有AI工程的基石。没有它，“from scratch”就是沙滩上的城堡。

3.2 第二层：数据管道——用Airflow DAG定义“数据血缘”的宪法

数据是AI的粮食，但粮食腐烂往往发生在运输途中。我们不用Apache NiFi或Flink做流处理，因为视觉质检场景是典型的批处理（每天凌晨处理昨日产线视频）。核心是Airflow DAG的编写哲学：

# dag_data_ingestion.py with DAG( "data_ingestion", default_args={ "retries": 3, "retry_delay": timedelta(minutes=5), # 关键：设置max_active_runs=1，强制串行化，避免同一份原始数据被多个task并发读取导致状态混乱 "max_active_runs": 1, }, schedule_interval="0 2 * * *", # 每日凌晨2点 catchup=False, ) as dag: # Task 1: 校验原始数据完整性 validate_raw_data = PythonOperator( task_id="validate_raw_data", python_callable=lambda: validate_md5_checksum("/mnt/nas/raw_videos/"), # 执行前检查NAS挂载点是否可用，不可用则直接fail，不重试 on_failure_callback=lambda context: send_alert("NAS_UNMOUNTED"), ) # Task 2: 数据脱敏（非简单打码，而是基于OCR识别的PII字段替换） anonymize_data = DockerOperator( task_id="anonymize_data", image="our/anonymizer:v1.2", # 关键：强制挂载/tmp为tmpfs，避免敏感数据落盘 volumes=["/dev/shm:/tmp"], command=["--input", "/data/raw", "--output", "/data/anonymized"], )

这里有两个反常识设计：

max_active_runs=1：牺牲吞吐量换取数据一致性。某次我们放开并发，导致两个task同时处理同一段视频，一个task把帧提取到/tmp/frame_001.jpg，另一个task覆盖写入，最终训练数据集出现大量重复帧。血缘关系彻底断裂。
/dev/shm:/tmp挂载：利用Linux tmpfs内存文件系统，确保所有中间文件（如OCR识别的文本、坐标框）不写入磁盘。某次安全审计发现，某供应商提供的脱敏镜像会把原始文本缓存到/tmp/log.txt，而我们通过tmpfs挂载，即使镜像有bug，数据也在内存中蒸发。

数据管道不是ETL流水线，是数据主权的法律文书。

3.3 第三层：特征工程——用Feature Store实现“特征即API”

特征不是代码，是业务知识的结晶。我们不用Feast或Hopsworks，而是用MinIO+SQLite构建极简Feature Store：

# feature_store.py class FeatureStore: def __init__(self, bucket_name: str): self.s3 = boto3.client("s3") self.bucket = bucket_name # 每个feature group对应一个SQLite DB，表结构固定：feature_name, entity_id, value, timestamp, version self.db_path = f"/tmp/{bucket_name}.db" def get_features(self, entity_ids: List[str], feature_names: List[str]) -> pd.DataFrame: # 关键：查询时强制加WHERE timestamp <= '2024-06-15'，避免获取未来数据（data leakage） query = f""" SELECT entity_id, feature_name, value FROM features WHERE entity_id IN ({','.join(['?']*len(entity_ids))}) AND feature_name IN ({','.join(['?']*len(feature_names))}) AND timestamp <= ? """ # 参数化查询，杜绝SQL注入 return pd.read_sql_query(query, self.conn, params=entity_ids+feature_names+["2024-06-15"])

这个设计的精妙在于时间旅行（Time Travel）控制。线上服务请求特征时，必须传入as_of_timestamp参数，Feature Store严格按此时间戳返回历史快照。某次模型效果骤降，我们回溯发现，线上服务未传as_of_timestamp，导致获取了训练时不存在的未来特征（如“用户未来7天预测购买力”），造成严重data leakage。自建方案下，我们把as_of_timestamp设为必填参数，并在DB层加CHECK约束timestamp <= CURRENT_TIMESTAMP，从源头堵死漏洞。

特征工程的终点，不是产出CSV，而是定义出不可篡改的契约。

3.4 第四层：模型训练——用PyTorch Lightning封装“可复现性”

训练不是调参，是精密实验。我们弃用原生PyTorch，但也不用Hugging Face Trainer，而是深度定制PyTorch Lightning：

# trainer.py class CustomTrainer(pl.Trainer): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) # 关键：强制设置随机种子，且在每个dataloader worker中单独设置 pl.seed_everything(42, workers=True) def fit(self, model, datamodule): # 训练前，自动dump当前git commit hash和conda env export self._log_git_info() self._log_env_info() super().fit(model, datamodule) def _log_git_info(self): # 获取当前repo的commit hash、branch、dirty flag repo = git.Repo(search_parent_directories=True) self.logger.log_metrics({ "git_commit": repo.head.object.hexsha, "git_branch": repo.active_branch.name, "git_dirty": repo.is_dirty(), })

这个CustomTrainer解决了三个致命问题：

随机性可控：workers=True确保每个dataloader worker有自己的seed，避免多进程下随机数序列重复。某次我们发现，不加此参数，不同worker加载的图像增强顺序完全一样，导致batch内多样性丧失。
环境可追溯：conda env export > environment.yml在训练开始时执行，确保任何人在任何机器上都能conda env create -f environment.yml复现环境。某次模型在A机器上准确率92.3%，B机器上91.8%，差异源于libjpeg-turbo版本不同，而environment.yml精准定位了这个包。
代码可审计：git commit hash写入训练日志，意味着线上模型能精确回溯到某次PR的某行代码。某次线上bug，我们直接checkout那个commit，运行pytest tests/test_model.py::test_forward，5分钟确认是某次优化导致的数值不稳定。

训练的最高目标，不是“跑通”，而是“可证伪”。

3.5 第五层：模型服务——用Triton Inference Server实现“零拷贝推理”

模型训完不是终点，上线才是生死线。我们不用Flask/FastAPI封装ONNX，而是用NVIDIA Triton：

# config.pbtxt name: "defect_detector" platform: "pytorch" max_batch_size: 8 input [ { name: "INPUT__0" data_type: TYPE_FP32 dims: [3, 256, 256] } ] output [ { name: "OUTPUT__0" data_type: TYPE_FP32 dims: [2] # 二分类 } ] # 关键：启用shared memory，让client和server共享GPU显存，避免PCIe拷贝 dynamic_batching [{}]

Triton的价值远超性能。它的config.pbtxt是模型的宪法：

max_batch_size: 8：不是随便写的，是通过tritonperf工具在目标GPU上压测得出的最优值。我们测过1、2、4、8、16，发现batch=8时GPU utilization稳定在82%，而batch=16时显存带宽成为瓶颈，latency反而上升17%。
dynamic_batching：开启后，Triton自动合并多个小请求成一个batch。某次产线相机每秒发3帧，但模型推理只需20ms，若不开启dynamic batching，GPU大部分时间闲置；开启后，平均batch size达5.3，吞吐量提升4.2倍。
shared memory：客户端用shm方式传递tensor，数据不经过CPU内存，直接在GPU显存间流转。我们实测，相比传统HTTP JSON传输，端到端延迟从128ms降至39ms，且CPU占用率从72%降至11%。

服务不是“把模型跑起来”，是把模型的物理特性（显存、带宽、计算单元）翻译成软件契约。

3.6 第六层：可观测性——用Prometheus+Grafana构建“模型健康仪表盘”

模型上线后，没人看日志。我们用Prometheus暴露关键指标：

# metrics.py from prometheus_client import Counter, Histogram, Gauge # 模型级指标 PREDICTION_COUNT = Counter( "model_prediction_count", "Total number of predictions", ["model_name", "status"] # status: success, error, timeout ) # 推理级指标 INFERENCE_LATENCY = Histogram( "model_inference_latency_seconds", "Inference latency in seconds", ["model_name"], buckets=[0.01, 0.02, 0.05, 0.1, 0.2, 0.5, 1.0, 2.0], ) # 系统级指标 GPU_MEMORY_USAGE = Gauge( "gpu_memory_usage_bytes", "GPU memory usage in bytes", ["gpu_id"] )

但指标不是目的，是诊断的起点。我们的Grafana面板有三个黄金视图：

实时分布图：用Histogram的histogram_quantile(0.95, rate(...))计算P95延迟，当曲线突然上翘，立即触发告警。
数据漂移热力图：用Evidently计算每个特征的KS检验p值，p<0.05的特征标红，提示数据分布异常。
GPU利用率矩阵：显示每块GPU的utilization.gpu、memory.used、power.draw三维度，某次我们发现一块GPUpower.draw异常高但utilization.gpu很低，定位到是风扇故障导致降频，而非模型问题。

可观测性不是“看板”，是模型的听诊器。

3.7 第七层：持续交付——用Argo CD实现“模型即代码”的GitOps

最后一步，把模型部署变成git push。我们用Argo CD管理K8s manifest：

# k8s/model-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: defect-detector-v2.1.0 labels: app: defect-detector # 关键：version标签必须与模型artifact版本严格一致 version: v2.1.0 spec: template: spec: containers: - name: triton-server image: our/triton-server:v2.1.0 # 镜像tag与模型版本绑定 env: - name: MODEL_VERSION value: "v2.1.0" # 环境变量也同步

Argo CD的Sync Policy设为Automatic，但关键在Sync Wave：

# argocd-app.yaml syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true - ApplyOutOfSyncOnly=true # 关键：设置sync wave，确保feature store先sync，再sync model deployment syncWaves: - name: "feature-store" weight: 1 - name: "model-deployment" weight: 2

这意味着，当git push新模型时，Argo CD先确保Feature Store已更新到对应版本，再部署模型。某次我们忘了更新Feature Store schema，模型部署失败，Argo CD自动rollback，且日志清晰显示dependency 'feature-store' not ready。GitOps不是自动化，是自动化之上的秩序。

4. 实操过程：在深圳产线78天，从零部署视觉质检模型的完整日志

4.1 Day 1-3：环境奠基——Terraform跑通第一台EC2

目标：在阿里云华南1区创建一台ecs.g7ne.2xlarge（8vCPU/32GiB/1*NVIDIA A10），预装CUDA 12.1、PyTorch 2.1、Triton 23.05。

实操难点：阿里云官方AMI不预装NVIDIA驱动，需手动编译。我们试过三种方案：

方案A：用nvidia-driver-installer.run脚本。失败，因内核版本5.10.0-107-generic与驱动要求的5.10.0-105不匹配。
方案B：用apt-get install nvidia-driver-535。失败，因Ubuntu 22.04源里的驱动不支持A10。
方案C：从NVIDIA官网下载NVIDIA-Linux-x86_64-535.104.05.run，加--no-opengl-files参数绕过OpenGL冲突，成功。

关键命令：

sudo ./NVIDIA-Linux-x86_64-535.104.05.run --no-opengl-files --silent sudo nvidia-smi -L # 验证输出：GPU 0: NVIDIA A10 (UUID: GPU-xxxxxx)

经验心得：永远不要相信“一键安装”。驱动安装必须验证nvidia-smi输出的GPU型号与实物一致，且nvidia-smi -q -d MEMORY显示显存大小正确。我们曾因驱动安装后nvidia-smi显示Tesla V100（实际是A10），导致后续CUDA程序加载失败，排查耗时14小时。

4.2 Day 4-12：数据管道攻坚——Airflow DAG跑通首条视频流

目标：从产线NAS挂载点/mnt/nas/production/2024/06/15/读取MP4，抽帧、OCR脱敏、存入MinIO。

挑战：NAS是SMB协议，Airflow worker无法直接挂载。解法：用docker run -v /mnt/nas:/nas alpine ls /nas验证挂载，再在DockerOperator中挂载。

关键DAG逻辑：

Taskscan_nas: 用find /mnt/nas -name "*.mp4" -mtime -1找昨日文件。
Taskextract_frames: 用ffmpeg -i input.mp4 -vf fps=1 output_%05d.jpg每秒抽1帧。
Taskocr_anonymize: 调用PaddleOCR，识别画面中的工号牌、姓名牌，用黑色矩形覆盖。

实测数据：处理1小时视频（3600帧），耗时23分17秒，CPU占用率68%，GPU未启用（OCR纯CPU）。

避坑指南：ffmpeg抽帧必须加-vsync 0参数，否则默认-vsync 1会做帧率同步，导致抽帧数量不准。某次我们漏加，1小时视频只抽了3598帧，少了2帧，导致后续训练数据集长度不一致，DataLoader报错。

4.3 Day 13-28：特征工程落地——Feature Store支持12个质检特征

目标：构建Feature Store，支持defect_area_ratio,edge_blur_score,color_uniformity等12个视觉特征。

技术选型：MinIO作对象存储，SQLite作元数据索引（因特征量不大，<100万条/天）。

Schema设计：

CREATE TABLE features ( id INTEGER PRIMARY KEY AUTOINCREMENT, feature_name TEXT NOT NULL, entity_id TEXT NOT NULL, -- 如 video_20240615_001 value REAL NOT NULL, timestamp DATETIME NOT NULL, version TEXT NOT NULL, -- 如 v1.0.0 created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE INDEX idx_entity_feature ON features(entity_id, feature_name, timestamp);

关键实现：get_features方法中，entity_id用LIKE 'video_20240615%'模糊查询，支持按日期批量获取。

压测结果：单次查询1000个entity_id的12个特征，平均耗时83ms，P95 127ms。

经验教训：SQLite的PRAGMA journal_mode=WAL必须开启，否则高并发写入时锁表。我们初期没开，当10个worker并发写入时，INSERT操作平均等待3.2秒，后加PRAGMA journal_mode=WAL，等待降至17ms。

4.4 Day 29-52：模型训练与验证——ResNet18达到94.2% F1

目标：用PyTorch Lightning训练二分类模型，区分“合格”与“缺陷”产品。

数据集：21,567张图片（合格12,843张，缺陷8,724张），按8:1:1划分train/val/test。

关键超参：

Batch size: 64（GPU显存限制）
Learning rate: 1e-3（用OneCycleLR scheduler）
Weight decay: 1e-4（防过拟合）

训练耗时：单卡A10，127个epoch，总耗时18小时23分钟。

验证结果：

Val F1: 94.2%（epoch 112）
Test F1: 93.8%（独立测试集）
Confusion Matrix: 缺陷漏检率（False Negative Rate）2.1%，合格误判率（False Positive Rate）1.9%

独门技巧：在LightningModule的validation_step中，用torchvision.utils.save_image保存错判样本，自动生成val_errors.html报告。每次val结束，自动打开浏览器展示最差的10张错判图，工程师能直观看到模型弱点（如对反光缺陷识别差）。

4.5 Day 53-65：Triton服务上线——P95延迟压至42ms

目标：将PyTorch模型转ONNX，用Triton部署，P95延迟≤50ms。

转换脚本关键点：

# export_onnx.py dummy_input = torch.randn(1, 3, 256, 256) torch.onnx.export( model, dummy_input, "defect_detector.onnx", opset_version=14, input_names=["input"], output_names=["output"], dynamic_axes={"input": {0: "batch_size"}, "output": {0: "batch_size"}}, # 关键：enable_onnx_checker=True，确保ONNX格式合法 enable_onnx_checker=True, )

Triton配置：

max_batch_size: 8
instance_group [{count: 2, kind: KIND_CPU}]（因模型小，CPU instance足够）
dynamic_batching {preferred_batch_size: [4, 8]}

压测工具：tritonperf --model-name defect_detector --concurrency 32 --request-rate 100

实测结果：

P50: 28ms
P95: 42ms
P99: 67ms
吞吐量：1,842 req/s

血泪教训：ONNX导出时opset_version必须与Triton支持的版本匹配。Triton 23.05支持opset 14，我们最初用opset 17，Triton加载时报Unsupported opset，查文档耗时3小时。

4.6 Day 66-75：可观测性闭环——Grafana看板上线预警

目标：搭建Prometheus+Grafana，实现模型延迟、错误率、GPU利用率实时监控。

采集器：用triton-inference-server内置的Prometheus exporter（端口8002/metrics）。

关键Grafana面板：

模型健康概览：P95延迟（红线阈值50ms）、错误率（绿线阈值0.5%）、QPS（蓝线）。
GPU资源热力图：nvidia_smi_duty_cycle、nvidia_smi_memory_used_percent、nvidia_smi_power_draw_watts三指标同屏。
数据漂移预警：用Evidently计算defect_area_ratio的KS检验p值，p<0.05标红。

首次预警：Day 68下午3点，defect_area_ratiop值跌至0.003，我们检查产线，发现新批次镜头清洁液配方变更，导致图像对比度下降，模型误判率上升。提前2小时发现，避免批量误判。

4.7 Day 76-78：Argo CD交付——GitOps流水线跑通

目标：用Argo CD实现git push自动部署新模型。

流程：

开发提交models/defect_detector_v2.1.0/目录，含model.onnx,config.pbtxt,requirements.txt。
CI流水线构建Docker镜像our/triton-server:v2.1.0，推送到私有Registry。
Argo CD检测到k8s/app.yaml中image: our/triton-server:v2.1.0变更，自动sync。
Sync完成后，curl http://triton-service:8000/v2/health/ready返回200。

交付物：一份DEPLOYMENT_CHECKLIST.md，包含：

[ ] Terraform state已备份
[ ] Airflow DAG已启用
[ ] Feature Store schema已更新
[ ] Triton model repository已reload
[ ] Grafana告警规则已激活
[ ] Argo CD Application状态为Synced

最后一刻，我们执行kubectl get pods -n ai-infra，看到defect-detector-v2.1.0-7c8b9d4f5-xyzab 1/1 Running，所有人击掌。这不是Demo，是产线正式接管。

5. 常见问题与排查技巧实录：78天踩过的23个坑

5.1 环境层：Terraform与驱动的战争

问题现象	根本原因	排查步骤	解决方案	经验总结
`nvidia-smi`命令不存在	NVIDIA驱动未安装或安装失败	1.`lsmod \| grep nvidia`检查内核模块 2.`dmesg \| grep -i nvidia`看内核日志 3.`cat /proc/driver/nvidia/version`验证	用NVIDIA官网驱动run包，加`--no-opengl-files --silent`参数	永远用`nvidia-smi -L`验证GPU型号，别信文档
Terraform apply卡在`aws_instance`创建	AWS IAM角色缺少`ec2:RunInstances`权限	1. 查看CloudTrail日志 2.`aws iam simulate-principal-policy`模拟权限	在IAM policy中显式添加`"ec2:RunInstances"`	最小权限原则：只给必需权限，宁可多配一个policy，不给多余权限

5.2 数据层：Airflow与NAS的博弈

问题现象	根本原因	排查步骤	解决方案	经验总结
Airflow worker无法访问NAS挂载点	SMB挂载未在worker节点执行	1.`kubectl exec -it airflow-worker-pod -- ls /mnt/nas` 2.`kubectl logs airflow-worker-pod`看挂载日志	在worker节点的`/etc/fstab`中添加`smb://nas-ip/share /mnt/nas cifs credentials=/etc/samba/cred,uid=1001,gid=1001 0 0`	挂载点必须在所有worker节点统一，用ConfigMap分发fstab
OCR识别率骤降	NAS挂载时`iocharset=utf8`缺失，中文乱码	1.`mount \| grep nas`看挂载参数 2.`file -i /mnt/nas/test.txt`看文件编码	在`/etc/fstab`中添加`iocharset=utf8,vers=3.0`	SMB挂载必须指定`vers=3.0`，旧版协议不支持长文件名

5.3 特征层：Feature Store的隐秘陷阱

问题现象	根本原因	排查步骤	解决方案	经验总结
`get_features`返回空结果	SQLite查询未加`ORDER BY timestamp DESC LIMIT 1`，返回最早版本	1.`sqlite3 feature.db "SELECT * FROM features WHERE entity_id='xxx' ORDER BY timestamp DESC LIMIT 1;"` 2. 对比训练时用的timestamp	在`get_features`中加`ORDER BY timestamp DESC LIMIT 1`	Feature Store必须保证“最新有效版本”语义，不能只靠timestamp过滤
SQLite写入缓慢	未开启WAL模式，写操作锁表	1.`sqlite3 feature.db "PRAGMA journal_mode;"` 2.`EXPLAIN QUERY PLAN SELECT ...`看执行计划	`PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL;`	SQLite在高并发写入场景，WAL模式是刚需，不是可选项