“I built AI at Amazon, then got laid off”这行字在近期技术社区里被很多人转发。它不像一个工具测评标题更像是一个AI工程师的职业断章。但真正值得看的不是裁员这件事而是前半句“在Amazon里做过AI”。做过什么、怎么做的、做完之后什么能带走、什么带不走这才是对普通开发者更有价值的部分。这篇不是推荐某个开源项目而是一次AI工程实践的复盘拆解。我会围绕大厂AI系统建设中真正高频的几件事展开模型怎么从实验变成服务、推理接口怎么设计、批处理任务怎么落地、成本怎么观察、上线后怎么排查问题。同时会给出可以照搬的代码示例和排查清单帮你把“能跑通的模型”升级成“能上线的系统”。如果你在做AI应用开发、AI模型部署或者正准备换到一个偏工程化的AI岗位这篇文章可以直接收藏。后面每一节都能对应到你本地方案或云上方案的落地过程里。1. 核心能力速览大厂AI工程师的日常先不要纠结“Amazon”这三个字。标题里真正可分析的是一个AI工程师在大型云厂商里到底负责什么。把它拆开看大约包含六个环节。环节工作内容常见工具链可迁移能力业务定义把业务问题转成模型问题文档、指标定义需求拆解、评估标准数据处理ETL、清洗、特征工程、数据版本管理S3、Spark、Pandas、Airflow数据流设计、数据质量监控模型训练实验管理、超参搜索、分布式训练SageMaker、PyTorch、TensorFlow、MLflow训练脚本工程化、实验对比模型评估离线指标、Bad Case分析、A/B测试评估脚本、SageMaker Experiments效果判断、回归测试模型上线推理服务、容器化、灰度发布、监控Docker、FastAPI、SageMaker Endpoint、CloudWatch服务化能力、性能调优成本与运维资源管控、实例选择、日志排查Lambda、Step Functions、CloudWatch、Cost Explorer成本意识、稳定性意识从这张表能看出来大厂AI工程师不同于算法研究员。模型能力是基础但真正拉开差距的是“能不能稳定地跑起来”“能不能被其他系统调用”“出了问题能不能快速定位”。标题里的“I built AI”不是只写Python脚本而是指一段完整的AI工程闭环。被裁之后真正能带走的就是这套闭环的工作方法和判断力。2. 适用场景与使用边界哪些经验可以被复现这篇文章拆出的内容适合以下几种场景你在做AI应用开发想把手里的模型封装成Web服务。你在做AI Agent或AI工具链集成需要了解模型接口如何对接外部系统。你有本地部署需求想知道推理服务的资源占用怎么观察。你在准备AI岗位面试需要一套完整的“模型上线”表述。不适合的场景也要说清楚如果你只想跑通一个Demo不需要复杂的推理网关和批处理队列。直接本地起一个FastAPI服务就够。过度设计是大厂系统最常见的坑迁移到个人项目时要主动砍掉。还有一条非常重要的边界如果你在或曾在公司内部做过AI项目离职后不能把内部代码、数据集、模型权重、内部文档带出来。更不要把非公开的系统架构细节写到博客、GitHub或面试题解里。本文所有示例都基于AWS对外公开的SageMaker、Lambda、S3等产品能力以及通用的AI工程实践。你在复现时要用自己的代码、公开数据集和合法授权的模型。涉及人脸、声音、版权素材时必须确认授权。生产环境的模型输出也需要人工复核不能盲目自动化。3. 从“建模型”到“建系统”AI工程实践的第一步很多工程师接触AI是从“训练模型”开始的。比如在Notebook里加载一个预训练模型跑几步推理看到输出就认为完成了。但在大厂AI项目里训练只是中间环节前面有数据后面有服务。一个标准AI系统可以拆成五段数据接入从S3、数据库、日志流里拿到原始数据做格式统一。特征与预处理做清洗、去重、截断、归一化。特征版本和模型版本要能对上。模型训练跑实验记录参数、指标和数据集版本。推理服务把训练好的模型文件加载到容器里提供HTTP接口。监控与反馈记录推理日志、延迟、错误率定期用新数据做回归评估。这五段里最容易出问题的是第一段和最后一段。数据格式变了模型不知道线上推理分布和训练分布不一致准确率再高也没用。建议第一步先把数据版本管理起来。最简单的做法是数据文件存到固定目录文件名带上日期或hash训练脚本记录数据路径、模型路径、超参。这样后续每跑一次实验都能还原当时用的什么数据、什么代码、什么参数。3.1 用一个最小工程结构管理AI项目推荐给个人项目和中小团队一套目录结构ai_project/ ├── data/ │ ├── raw/ # 原始数据 │ └── processed/ # 清洗后数据 ├── models/ # 模型文件 ├── src/ │ ├── train.py # 训练脚本 │ ├── preprocess.py # 预处理 │ └── infer.py # 推理服务 ├── configs/ │ └── config.yaml # 配置 ├── output/ │ └── logs/ # 日志 └── requirements.txt这个结构本身没有魔法但它强制你把代码、配置、数据、输出分开放。上线后排查问题第一步就是区分是数据问题、模型问题、代码问题还是环境问题。4. 模型训练与实验管理用代码固定流程在大厂做AI第一步不是写模型而是把训练流程固定下来。比如训练一个文本分类模型可以把整个流程写成一个脚本输入是数据路径和超参输出是模型文件和评估报告。以SageMaker为例训练任务一般通过Boto3创建。下面是一个可复用的训练任务提交示例你本地方案可以改成PyTorch或TensorFlow训练脚本。import boto3 sm boto3.client(sagemaker, region_nameus-east-1) response sm.create_training_job( TrainingJobNametext-classifier-v1, AlgorithmSpecification{ TrainingImage: 763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-training:2.1.0-gpu-py310, TrainingInputMode: File, }, RoleArnarn:aws:iam::123456789012:role/sagemaker-execution-role, InputDataConfig[ { ChannelName: train, DataSource: { S3DataSource: { S3DataType: S3Prefix, S3Uri: s3://your-bucket/data/processed/train/, } }, } ], OutputDataConfig{ S3OutputPath: s3://your-bucket/models/text-classifier-v1/ }, ResourceConfig{ InstanceType: ml.g4dn.xlarge, InstanceCount: 1, VolumeSizeInGB: 30, }, StoppingCondition{ MaxRuntimeInSeconds: 3600, }, HyperParameters{ epochs: 5, batch-size: 32, learning-rate: 2e-5, }, ) print(response[TrainingJobArn])注意几个细节训练镜像、角色ARN、S3路径都要替换成你自己的。HyperParameters全部是字符串SageMaker默认会传成环境变量格式。训练数据和模型输出都放S3便于版本管理和回滚。实例类型选择由你的数据量和显存决定不要随意开大机器。训练结束后一般要保存评估指标。可以用CloudWatch输出指标也可以用MLflow记录。核心目的是下次换数据或换模型时能快速对比哪个版本更好。5. 模型部署与推理服务把模型封装成API训练完的模型只是产物用户能用到的是推理服务。这里最通用的方案就是把模型文件、依赖库、推理代码打进Docker容器然后提供HTTP接口。下面用一个FastAPI示例说明。这个示例在本地跑通后可以直接封装成任意模型的推理服务。# Dockerfile FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY model/ /app/model/ COPY app.py . EXPOSE 8080 CMD [uvicorn, app:app, --host, 0.0.0.0, --port, 8080]# app.py from fastapi import FastAPI from pydantic import BaseModel import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification app FastAPI() model_path /app/model tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForSequenceClassification.from_pretrained(model_path) model.eval() class PredictRequest(BaseModel): text: str class PredictResponse(BaseModel): label: int score: float app.post(/predict, response_modelPredictResponse) def predict(req: PredictRequest): inputs tokenizer(req.text, return_tensorspt, truncationTrue, max_length512) with torch.no_grad(): outputs model(**inputs) probs torch.softmax(outputs.logits, dim-1) label int(probs.argmax(dim-1)[0]) score float(probs.max(dim-1)[0]) return PredictResponse(labellabel, scorescore) app.get(/health) def health(): return {status: ok}启动后本地测试接口curl -X POST http://127.0.0.1:8080/predict \ -H Content-Type: application/json \ -d {text: 这篇文章讲的是AI部署} \ -w \n时间: %{time_total}s\n判断成功的标准返回JSON里包含label和score。/health返回{status:ok}。连续请求多次没有内存持续暴涨。把这个容器部署到SageMaker Endpoint或AWS Lambda就能对外提供服务。关键不是容器本身而是“模型文件被加载一次接口常驻”这种在线推理设计。6. 接口API与批量任务从在线推理到离线批处理上线后你会遇到两类使用方在线场景用户点了一下按钮需要毫秒级响应例如搜索排序、智能客服。离线场景后台一次性处理几十万条数据例如历史工单分类、批量内容审核。这两类场景对接口要求不一样。在线看延迟离线看吞吐。如果只用同一个在线接口跑离线任务服务器很容易被打爆。比较稳妥的做法是把离线任务拆成队列和批处理。6.1 使用Python调用在线推理接口假设接口已经部署到http://your-endpoint/predict可以用以下代码做批量调用。import requests import pandas as pd from tqdm import tqdm df pd.read_csv(input_data.csv) url http://your-endpoint/predict results [] for text in tqdm(df[text].tolist()): try: resp requests.post(url, json{text: text}, timeout10) resp.raise_for_status() result resp.json() results.append({text: text, label: result[label], score: result[score]}) except Exception as e: results.append({text: text, label: None, score: None, error: str(e)}) output_df pd.DataFrame(results) output_df.to_csv(output_data.csv, indexFalse)这个示例里最关键的是异常处理。批量任务只要有一条网络抖动就会中断整个脚本。所以每条请求必须单独捕获异常并把失败数据写进输出方便重试。6.2 设计一个可重试的批处理队列更健壮的方案是用消息队列。以AWS Step Functions或SQS为例流程是把输入数据拆成多个批次逐条或分组发送到队列。消费者从队列取任务调用推理接口。成功的结果写回S3或数据库。失败的任务进入死信队列用于人工排查或延迟重试。代码层面可以用一个简单的重试装饰器来统一控制import time import requests from functools import wraps def retry(max_retries3, delay1.0): def decorator(func): wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: if attempt max_retries - 1: raise time.sleep(delay * (2 ** attempt)) return wrapper return decorator retry(max_retries3, delay1.0) def call_inference(text): resp requests.post(http://your-endpoint/predict, json{text: text}, timeout10) resp.raise_for_status() return resp.json()这里用的是指数退避重试。延迟低、效果明显适合批量调用场景。但要设置最大重试次数防止死循环。7. 资源占用与性能观察AI系统的成本意识大厂AI工程师和学术研究者的一个明显区别是必须考虑资源成本和性能。训练的时候可以看训练时间部署后要看推理延迟、QPS每秒查询数、显存占用、CPU利用率。如果你用NVIDIA GPU可以通过nvidia-smi查看实时显存占用nvidia-smi --query-gpuutilization.gpu,memory.used,temperature.gpu --formatcsv如果要持续观察可以写一个循环把数据保存到CSVwhile true; do echo $(date %Y-%m-%d %H:%M:%S), $(nvidia-smi --query-gpuutilization.gpu,memory.used,temperature.gpu --formatcsv,noheader,nounits) gpu_monitor.csv sleep 2 done在云上可以用CloudWatch记录自定义指标。下面这个Python示例会在每次推理后记录延迟和请求数方便后续做成本分析。import boto3 import time cloudwatch boto3.client(cloudwatch, region_nameus-east-1) def log_metric(metric_name, value, unitMilliseconds): cloudwatch.put_metric_data( NamespaceAI/Inference, MetricData[ { MetricName: metric_name, Value: value, Unit: unit, Timestamp: time.time(), } ], )影响性能的因素通常是输入文本长度越长Transformer的attention计算量越大。batch size一次性推理多条文本能提高吞吐但会显著增加显存占用。模型量化从FP32换成FP16或INT8可以节省显存但可能带来精度损失。并发数并发过高会导致GPU排队单请求延迟会变大。下面是一组观察思路不写死数字因为不同模型差异很大观察项现象建议显存占用持续接近上限降低batch size或换更大显存实例CPU高但GPU低预处理/后处理成了瓶颈优化tokenizer或增加CPU资源延迟抖动个别请求明显变慢检查冷启动、容器资源限制、并发排队成本超预期空闲实例太多用弹性伸缩缩容不用的端点千万不要只盯着“模型准确率”这一个指标。线上系统的成败往往由延迟、错误率、资源成本共同决定。8. 常见问题与排查方法AI服务上线后的排查工作比训练模型更占用时间。下面整理一份高频问题清单。问题现象可能原因排查方式解决方案部署后接口返回500模型文件路径错误或依赖缺失看容器启动日志检查Dockerfile路径和requirements.txt首次调用非常慢冷启动模型权重加载到内存耗时看调用耗时分布增加预热请求或使用常驻实例批量任务跑到一半卡住某条输入触发异常或超时看任务日志和请求失败记录单条请求加超时并记录异常显存溢出batch size过大或输入过长观察nvidia-smi降低batch size限制输入长度线上效果和离线评估差距大数据分布不一致对比线上和训练数据分布增加线上监控和定期回归评估端口冲突两个服务争用同一端口检查进程列表修改端口或杀掉残留进程API鉴权失败密钥或IAM策略配置错误检查调用方身份和权限更换正确密钥调整策略排查顺序建议是先看日志再看指标最后看代码。日志能直接暴露异常栈和数据内容指标能反映是资源问题还是流量问题代码是最后怀疑对象。9. 最佳实践与使用建议把一套AI系统做到稳定不只是训练时调参更需要工程端的约束。先小参数测试再上大模型。不要一上来就用几十亿参数模型。先用小规模模型验证流程流程跑通后再考虑升级。保留一套最小可运行配置。把训练、推理、调用三条命令写进README确保任何人按文档都能跑起来。数据、代码、模型、配置分开管理。目录结构和版本号都要清晰避免“这个效果我复现不出来”的场景。批量任务一定要加日志和失败重试。崩溃不可怕可怕的是不知道哪些数据没处理。接口服务要限制访问范围。公网接口必须有鉴权避免被刷流量。涉及人脸、声音、版权素材时必须确认授权。即使用于测试也不要使用未经授权的个人数据。发布或商用前要做效果复核。AI输出不一定正确尤其对内容生成、审核、推荐类场景要保留人工确认机制。离线评估要保留历史eval集。每次更新模型都跑同一套评估数据能快速发现回归。10. 总结被裁后能带走什么回到标题“I built AI at Amazon, then got laid off”。如果把这里的“AI”拆开它不只是模型而是一套工程能力。这些能力包括把业务问题定义成模型问题、把训练过程固定成脚本、把模型封装成服务、把服务接入业务、用成本和性能指标持续反馈迭代。被裁之后公司在职期间积累的工具链和内部数据都带不走但下面这些可以带走你训练模型时积累的代码能力。你排查线上问题的方法论。你对资源成本和性能的敏感度。你把一个Demo做成稳定服务的能力。你做文档和交接时的表达习惯。这些能力不绑定任何一家公司。放到个人项目里就是把训练脚本、推理接口、批量任务、监控指标重新做一遍放到下一份工作里就是上手新业务的速度。建议你从一个小项目开始验证自己拿一个公开数据集训练一个轻量模型用Docker封装成FastAPI服务再写一个批量调用脚本最后加上日志和重试。整个过程跑完你就知道自己是否具备独立交付AI系统的能力。这套流程适用于所有AI应用开发者。建议收藏备用后面做AI Agent、AI工具链、模型微调时都可以按同样的工程框架推进。
“I built AI at Amazon, then got laid off”这行字在近期技术社区里被很多人转发。它不像一个工具测评标题更像是一个AI工程师的职业断章。但真正值得看的不是裁员这件事而是前半句“在Amazon里做过AI”。做过什么、怎么做的、做完之后什么能带走、什么带不走这才是对普通开发者更有价值的部分。这篇不是推荐某个开源项目而是一次AI工程实践的复盘拆解。我会围绕大厂AI系统建设中真正高频的几件事展开模型怎么从实验变成服务、推理接口怎么设计、批处理任务怎么落地、成本怎么观察、上线后怎么排查问题。同时会给出可以照搬的代码示例和排查清单帮你把“能跑通的模型”升级成“能上线的系统”。如果你在做AI应用开发、AI模型部署或者正准备换到一个偏工程化的AI岗位这篇文章可以直接收藏。后面每一节都能对应到你本地方案或云上方案的落地过程里。1. 核心能力速览大厂AI工程师的日常先不要纠结“Amazon”这三个字。标题里真正可分析的是一个AI工程师在大型云厂商里到底负责什么。把它拆开看大约包含六个环节。环节工作内容常见工具链可迁移能力业务定义把业务问题转成模型问题文档、指标定义需求拆解、评估标准数据处理ETL、清洗、特征工程、数据版本管理S3、Spark、Pandas、Airflow数据流设计、数据质量监控模型训练实验管理、超参搜索、分布式训练SageMaker、PyTorch、TensorFlow、MLflow训练脚本工程化、实验对比模型评估离线指标、Bad Case分析、A/B测试评估脚本、SageMaker Experiments效果判断、回归测试模型上线推理服务、容器化、灰度发布、监控Docker、FastAPI、SageMaker Endpoint、CloudWatch服务化能力、性能调优成本与运维资源管控、实例选择、日志排查Lambda、Step Functions、CloudWatch、Cost Explorer成本意识、稳定性意识从这张表能看出来大厂AI工程师不同于算法研究员。模型能力是基础但真正拉开差距的是“能不能稳定地跑起来”“能不能被其他系统调用”“出了问题能不能快速定位”。标题里的“I built AI”不是只写Python脚本而是指一段完整的AI工程闭环。被裁之后真正能带走的就是这套闭环的工作方法和判断力。2. 适用场景与使用边界哪些经验可以被复现这篇文章拆出的内容适合以下几种场景你在做AI应用开发想把手里的模型封装成Web服务。你在做AI Agent或AI工具链集成需要了解模型接口如何对接外部系统。你有本地部署需求想知道推理服务的资源占用怎么观察。你在准备AI岗位面试需要一套完整的“模型上线”表述。不适合的场景也要说清楚如果你只想跑通一个Demo不需要复杂的推理网关和批处理队列。直接本地起一个FastAPI服务就够。过度设计是大厂系统最常见的坑迁移到个人项目时要主动砍掉。还有一条非常重要的边界如果你在或曾在公司内部做过AI项目离职后不能把内部代码、数据集、模型权重、内部文档带出来。更不要把非公开的系统架构细节写到博客、GitHub或面试题解里。本文所有示例都基于AWS对外公开的SageMaker、Lambda、S3等产品能力以及通用的AI工程实践。你在复现时要用自己的代码、公开数据集和合法授权的模型。涉及人脸、声音、版权素材时必须确认授权。生产环境的模型输出也需要人工复核不能盲目自动化。3. 从“建模型”到“建系统”AI工程实践的第一步很多工程师接触AI是从“训练模型”开始的。比如在Notebook里加载一个预训练模型跑几步推理看到输出就认为完成了。但在大厂AI项目里训练只是中间环节前面有数据后面有服务。一个标准AI系统可以拆成五段数据接入从S3、数据库、日志流里拿到原始数据做格式统一。特征与预处理做清洗、去重、截断、归一化。特征版本和模型版本要能对上。模型训练跑实验记录参数、指标和数据集版本。推理服务把训练好的模型文件加载到容器里提供HTTP接口。监控与反馈记录推理日志、延迟、错误率定期用新数据做回归评估。这五段里最容易出问题的是第一段和最后一段。数据格式变了模型不知道线上推理分布和训练分布不一致准确率再高也没用。建议第一步先把数据版本管理起来。最简单的做法是数据文件存到固定目录文件名带上日期或hash训练脚本记录数据路径、模型路径、超参。这样后续每跑一次实验都能还原当时用的什么数据、什么代码、什么参数。3.1 用一个最小工程结构管理AI项目推荐给个人项目和中小团队一套目录结构ai_project/ ├── data/ │ ├── raw/ # 原始数据 │ └── processed/ # 清洗后数据 ├── models/ # 模型文件 ├── src/ │ ├── train.py # 训练脚本 │ ├── preprocess.py # 预处理 │ └── infer.py # 推理服务 ├── configs/ │ └── config.yaml # 配置 ├── output/ │ └── logs/ # 日志 └── requirements.txt这个结构本身没有魔法但它强制你把代码、配置、数据、输出分开放。上线后排查问题第一步就是区分是数据问题、模型问题、代码问题还是环境问题。4. 模型训练与实验管理用代码固定流程在大厂做AI第一步不是写模型而是把训练流程固定下来。比如训练一个文本分类模型可以把整个流程写成一个脚本输入是数据路径和超参输出是模型文件和评估报告。以SageMaker为例训练任务一般通过Boto3创建。下面是一个可复用的训练任务提交示例你本地方案可以改成PyTorch或TensorFlow训练脚本。import boto3 sm boto3.client(sagemaker, region_nameus-east-1) response sm.create_training_job( TrainingJobNametext-classifier-v1, AlgorithmSpecification{ TrainingImage: 763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-training:2.1.0-gpu-py310, TrainingInputMode: File, }, RoleArnarn:aws:iam::123456789012:role/sagemaker-execution-role, InputDataConfig[ { ChannelName: train, DataSource: { S3DataSource: { S3DataType: S3Prefix, S3Uri: s3://your-bucket/data/processed/train/, } }, } ], OutputDataConfig{ S3OutputPath: s3://your-bucket/models/text-classifier-v1/ }, ResourceConfig{ InstanceType: ml.g4dn.xlarge, InstanceCount: 1, VolumeSizeInGB: 30, }, StoppingCondition{ MaxRuntimeInSeconds: 3600, }, HyperParameters{ epochs: 5, batch-size: 32, learning-rate: 2e-5, }, ) print(response[TrainingJobArn])注意几个细节训练镜像、角色ARN、S3路径都要替换成你自己的。HyperParameters全部是字符串SageMaker默认会传成环境变量格式。训练数据和模型输出都放S3便于版本管理和回滚。实例类型选择由你的数据量和显存决定不要随意开大机器。训练结束后一般要保存评估指标。可以用CloudWatch输出指标也可以用MLflow记录。核心目的是下次换数据或换模型时能快速对比哪个版本更好。5. 模型部署与推理服务把模型封装成API训练完的模型只是产物用户能用到的是推理服务。这里最通用的方案就是把模型文件、依赖库、推理代码打进Docker容器然后提供HTTP接口。下面用一个FastAPI示例说明。这个示例在本地跑通后可以直接封装成任意模型的推理服务。# Dockerfile FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY model/ /app/model/ COPY app.py . EXPOSE 8080 CMD [uvicorn, app:app, --host, 0.0.0.0, --port, 8080]# app.py from fastapi import FastAPI from pydantic import BaseModel import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification app FastAPI() model_path /app/model tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForSequenceClassification.from_pretrained(model_path) model.eval() class PredictRequest(BaseModel): text: str class PredictResponse(BaseModel): label: int score: float app.post(/predict, response_modelPredictResponse) def predict(req: PredictRequest): inputs tokenizer(req.text, return_tensorspt, truncationTrue, max_length512) with torch.no_grad(): outputs model(**inputs) probs torch.softmax(outputs.logits, dim-1) label int(probs.argmax(dim-1)[0]) score float(probs.max(dim-1)[0]) return PredictResponse(labellabel, scorescore) app.get(/health) def health(): return {status: ok}启动后本地测试接口curl -X POST http://127.0.0.1:8080/predict \ -H Content-Type: application/json \ -d {text: 这篇文章讲的是AI部署} \ -w \n时间: %{time_total}s\n判断成功的标准返回JSON里包含label和score。/health返回{status:ok}。连续请求多次没有内存持续暴涨。把这个容器部署到SageMaker Endpoint或AWS Lambda就能对外提供服务。关键不是容器本身而是“模型文件被加载一次接口常驻”这种在线推理设计。6. 接口API与批量任务从在线推理到离线批处理上线后你会遇到两类使用方在线场景用户点了一下按钮需要毫秒级响应例如搜索排序、智能客服。离线场景后台一次性处理几十万条数据例如历史工单分类、批量内容审核。这两类场景对接口要求不一样。在线看延迟离线看吞吐。如果只用同一个在线接口跑离线任务服务器很容易被打爆。比较稳妥的做法是把离线任务拆成队列和批处理。6.1 使用Python调用在线推理接口假设接口已经部署到http://your-endpoint/predict可以用以下代码做批量调用。import requests import pandas as pd from tqdm import tqdm df pd.read_csv(input_data.csv) url http://your-endpoint/predict results [] for text in tqdm(df[text].tolist()): try: resp requests.post(url, json{text: text}, timeout10) resp.raise_for_status() result resp.json() results.append({text: text, label: result[label], score: result[score]}) except Exception as e: results.append({text: text, label: None, score: None, error: str(e)}) output_df pd.DataFrame(results) output_df.to_csv(output_data.csv, indexFalse)这个示例里最关键的是异常处理。批量任务只要有一条网络抖动就会中断整个脚本。所以每条请求必须单独捕获异常并把失败数据写进输出方便重试。6.2 设计一个可重试的批处理队列更健壮的方案是用消息队列。以AWS Step Functions或SQS为例流程是把输入数据拆成多个批次逐条或分组发送到队列。消费者从队列取任务调用推理接口。成功的结果写回S3或数据库。失败的任务进入死信队列用于人工排查或延迟重试。代码层面可以用一个简单的重试装饰器来统一控制import time import requests from functools import wraps def retry(max_retries3, delay1.0): def decorator(func): wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: if attempt max_retries - 1: raise time.sleep(delay * (2 ** attempt)) return wrapper return decorator retry(max_retries3, delay1.0) def call_inference(text): resp requests.post(http://your-endpoint/predict, json{text: text}, timeout10) resp.raise_for_status() return resp.json()这里用的是指数退避重试。延迟低、效果明显适合批量调用场景。但要设置最大重试次数防止死循环。7. 资源占用与性能观察AI系统的成本意识大厂AI工程师和学术研究者的一个明显区别是必须考虑资源成本和性能。训练的时候可以看训练时间部署后要看推理延迟、QPS每秒查询数、显存占用、CPU利用率。如果你用NVIDIA GPU可以通过nvidia-smi查看实时显存占用nvidia-smi --query-gpuutilization.gpu,memory.used,temperature.gpu --formatcsv如果要持续观察可以写一个循环把数据保存到CSVwhile true; do echo $(date %Y-%m-%d %H:%M:%S), $(nvidia-smi --query-gpuutilization.gpu,memory.used,temperature.gpu --formatcsv,noheader,nounits) gpu_monitor.csv sleep 2 done在云上可以用CloudWatch记录自定义指标。下面这个Python示例会在每次推理后记录延迟和请求数方便后续做成本分析。import boto3 import time cloudwatch boto3.client(cloudwatch, region_nameus-east-1) def log_metric(metric_name, value, unitMilliseconds): cloudwatch.put_metric_data( NamespaceAI/Inference, MetricData[ { MetricName: metric_name, Value: value, Unit: unit, Timestamp: time.time(), } ], )影响性能的因素通常是输入文本长度越长Transformer的attention计算量越大。batch size一次性推理多条文本能提高吞吐但会显著增加显存占用。模型量化从FP32换成FP16或INT8可以节省显存但可能带来精度损失。并发数并发过高会导致GPU排队单请求延迟会变大。下面是一组观察思路不写死数字因为不同模型差异很大观察项现象建议显存占用持续接近上限降低batch size或换更大显存实例CPU高但GPU低预处理/后处理成了瓶颈优化tokenizer或增加CPU资源延迟抖动个别请求明显变慢检查冷启动、容器资源限制、并发排队成本超预期空闲实例太多用弹性伸缩缩容不用的端点千万不要只盯着“模型准确率”这一个指标。线上系统的成败往往由延迟、错误率、资源成本共同决定。8. 常见问题与排查方法AI服务上线后的排查工作比训练模型更占用时间。下面整理一份高频问题清单。问题现象可能原因排查方式解决方案部署后接口返回500模型文件路径错误或依赖缺失看容器启动日志检查Dockerfile路径和requirements.txt首次调用非常慢冷启动模型权重加载到内存耗时看调用耗时分布增加预热请求或使用常驻实例批量任务跑到一半卡住某条输入触发异常或超时看任务日志和请求失败记录单条请求加超时并记录异常显存溢出batch size过大或输入过长观察nvidia-smi降低batch size限制输入长度线上效果和离线评估差距大数据分布不一致对比线上和训练数据分布增加线上监控和定期回归评估端口冲突两个服务争用同一端口检查进程列表修改端口或杀掉残留进程API鉴权失败密钥或IAM策略配置错误检查调用方身份和权限更换正确密钥调整策略排查顺序建议是先看日志再看指标最后看代码。日志能直接暴露异常栈和数据内容指标能反映是资源问题还是流量问题代码是最后怀疑对象。9. 最佳实践与使用建议把一套AI系统做到稳定不只是训练时调参更需要工程端的约束。先小参数测试再上大模型。不要一上来就用几十亿参数模型。先用小规模模型验证流程流程跑通后再考虑升级。保留一套最小可运行配置。把训练、推理、调用三条命令写进README确保任何人按文档都能跑起来。数据、代码、模型、配置分开管理。目录结构和版本号都要清晰避免“这个效果我复现不出来”的场景。批量任务一定要加日志和失败重试。崩溃不可怕可怕的是不知道哪些数据没处理。接口服务要限制访问范围。公网接口必须有鉴权避免被刷流量。涉及人脸、声音、版权素材时必须确认授权。即使用于测试也不要使用未经授权的个人数据。发布或商用前要做效果复核。AI输出不一定正确尤其对内容生成、审核、推荐类场景要保留人工确认机制。离线评估要保留历史eval集。每次更新模型都跑同一套评估数据能快速发现回归。10. 总结被裁后能带走什么回到标题“I built AI at Amazon, then got laid off”。如果把这里的“AI”拆开它不只是模型而是一套工程能力。这些能力包括把业务问题定义成模型问题、把训练过程固定成脚本、把模型封装成服务、把服务接入业务、用成本和性能指标持续反馈迭代。被裁之后公司在职期间积累的工具链和内部数据都带不走但下面这些可以带走你训练模型时积累的代码能力。你排查线上问题的方法论。你对资源成本和性能的敏感度。你把一个Demo做成稳定服务的能力。你做文档和交接时的表达习惯。这些能力不绑定任何一家公司。放到个人项目里就是把训练脚本、推理接口、批量任务、监控指标重新做一遍放到下一份工作里就是上手新业务的速度。建议你从一个小项目开始验证自己拿一个公开数据集训练一个轻量模型用Docker封装成FastAPI服务再写一个批量调用脚本最后加上日志和重试。整个过程跑完你就知道自己是否具备独立交付AI系统的能力。这套流程适用于所有AI应用开发者。建议收藏备用后面做AI Agent、AI工具链、模型微调时都可以按同样的工程框架推进。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
