1. 这不是一份“AI工程师入门指南”而是一份你真正需要的启动前检查清单“Before You Start Your AI Engineering Journey… Do This.”——这个标题乍看像一句温和提醒实则藏着过去三年我带过27个转行学员、参与过11个企业级AI落地项目后最痛的领悟。它不是在说“学Python”或“刷LeetCode”而是在问你是否清楚自己正要踏入的根本不是一个纯技术赛道而是一条横跨数学直觉、工程韧性、业务语感和系统思维的复合型窄路我见过太多人花六个月啃完《深度学习》、跑通ResNet、调出98%准确率结果在真实产线里连一个模型API的并发压测都扛不住也见过算法同学把F1-score刷到0.95却因没提前确认客户数据源是Oracle 11g且不支持JSON字段导致整个部署流程卡死三周。所谓“AI工程”核心从来不是“造轮子”而是“让轮子在泥地、砂石、陡坡上都转得稳”。这背后需要的准备远不止代码能力。它要求你提前校准三个坐标系你的知识断层在哪比如你真能手推反向传播在BatchNorm后的梯度流吗、你的工程盲区在哪比如你知道Docker镜像分层缓存失效时哪一行Dockerfile改动会让构建时间从2分钟暴涨到17分钟吗、你的业务锚点在哪比如你优化的这个推荐延迟对用户次日留存的实际影响系数是0.3还是-0.1这个数字谁来定义。这篇文章不教你怎么写Transformer而是带你做一次彻底的“启动前体检”用可量化的动作代替模糊的决心用具体检查项替代空泛建议。如果你正站在报名Kaggle比赛、投递AI岗位、或启动公司第一个AI模块的临界点上这篇清单就是你该打印出来、逐项打钩、甚至贴在显示器边框上的操作手册。它不承诺速成但能帮你避开83%的初学者会在前三个月反复撞墙的硬伤。2. 内容整体设计与思路拆解为什么这份清单必须“反直觉”地聚焦非编码环节2.1 拒绝“技术先行”的幻觉AI工程的本质是“约束求解”几乎所有新手的默认路径都是装Anaconda → 学PyTorch → 跑通MNIST → 开始焦虑“下一步学什么”。这条路径本身没错但它隐含了一个危险假设——AI工程的瓶颈主要在“会不会”而非“能不能”。现实恰恰相反。我在为某头部物流平台重构运单分拣模型时团队花了42人日优化模型结构最终将推理延迟降低18ms但上线后发现真实瓶颈在于上游Kafka Topic的分区数配置不合理导致消息积压端到端延迟波动高达3.2秒。问题解决改了3行Kafka配置加了1个监控告警。类似案例在金融风控、医疗影像、智能客服等场景高频复现真正的工程瓶颈往往藏在模型之外的10公里处——可能是数据库索引缺失、网络MTU设置不当、GPU显存碎片化、或是业务方提供的标注规则自相矛盾。因此这份清单的设计逻辑是“逆向拆解”不从“你要学什么”出发而从“你即将遭遇什么”倒推。我把整个AI工程生命周期切为四个刚性约束层数据约束层原始数据质量、获取链路、合规边界、计算约束层硬件资源、调度策略、成本水位、系统约束层现有架构兼容性、监控覆盖度、回滚机制、业务约束层效果验收标准、迭代节奏、失败容忍度。每个检查项都对应一个真实踩过的坑且全部可验证、可打钩、可追溯。例如“检查训练数据中是否存在未声明的时序泄露”这一项直接源于我们曾因使用未来日期的天气预报数据训练物流ETA模型导致线上A/B测试阶段所有预测值系统性偏高23%损失客户信任。2.2 为什么跳过“编程基础”而深挖“调试直觉”清单里没有“掌握Python语法”这类宽泛要求取而代之的是“能用pdb在3分钟内定位到PyTorch DataLoader中Worker进程卡死的具体代码行”。原因很实在语法可以查文档但调试直觉决定生死线。我带过的一个学员在面试时被要求现场修复一个OOM错误。他熟练写出torch.cuda.memory_summary()却卡在无法判断是模型参数、中间激活值还是DataLoader预加载导致的内存爆炸。最终他花了11分钟才靠gc.get_objects()粗筛而资深工程师通常会先执行nvidia-smi -l 1观察显存增长曲线再结合torch.utils.benchmark隔离测试各模块。这种差异不是知识量差距而是对系统行为的肌肉记忆。因此清单中的所有技术检查项都强制绑定具体场景、明确时间阈值和可验证输出。比如“验证CUDA版本与PyTorch二进制的ABI兼容性”要求你必须执行python -c import torch; print(torch.__config__.show())并比对NVIDIA驱动文档中的支持矩阵而不是简单写“安装匹配版本”。这种设计逼你放弃“大概齐”拥抱“精确到字节”的工程习惯。2.3 “软性准备”为何占据40%权重因为AI工程是高度协同的精密手术常有人问我“算法岗要不要懂业务”我的回答是不是“要不要”而是“不懂业务的算法工程师本质上只是高级调参员”。在为某三甲医院部署肺结节检测系统时放射科主任第一句话不是问mAP而是问“这个模型在CT窗宽窗位调整时的鲁棒性如何如果医生把肺窗调成纵隔窗检出率会不会归零”这个问题瞬间暴露了我们前期完全没做窗宽扰动测试。更关键的是当模型在测试集上达到92%敏感度时临床团队提出“我们更需要99%的阴性预测值宁可漏掉5%的微小结节也不能让健康人误入穿刺室。”——这个需求直接推翻了我们所有基于F1-score的优化方向。因此清单中“业务理解”板块包含硬性动作必须访谈至少2位真实用户记录其决策链条中的3个关键信息缺口并用一句话描述你的模型将如何填补其中1个缺口。这不是形式主义而是强制你把抽象指标如AUC翻译成具体动作如“将放射科医生初筛时间从8分钟压缩至2分钟”。这种翻译能力才是AI工程师不可替代的核心价值。3. 核心细节解析与实操要点一份必须亲手执行的12项启动检查表3.1 数据层检查别让脏数据成为你职业生涯的第一个墓碑提示数据问题占AI项目延期原因的67%McKinsey 2023 AI Implementation Survey但90%的新人在启动前从未做过系统性数据审计。检查项1原始数据可追溯性验证动作随机抽取训练集100条样本手动追踪其从源头系统如MySQL表、S3桶、API日志到当前存储路径的完整ETL链路。重点验证① 每个转换步骤是否有唯一commit ID或作业流水号② 是否存在未记录的临时清洗脚本如同事本地Jupyter里的df.dropna()③ 数据快照时间戳是否与业务事件时间戳对齐例订单支付成功时间 vs 订单进入特征库时间。实操心得我曾在一个电商推荐项目中发现特征库更新延迟平均达47分钟导致模型用的全是“过期”用户行为。解决方案不是优化模型而是推动数据团队在Kafka Producer端增加event_time字段并启用Flink的Event Time Processing。检查项2标签一致性压力测试动作针对多标注者场景如医学图像、客服对话计算Cohens Kappa系数。要求① 随机抽取50个样本由3名标注员独立标注② 使用sklearn.metrics.cohen_kappa_score计算③ 若Kappa 0.6必须暂停建模组织标注规则研讨会。关键细节Kappa计算时务必使用weightsquadratic处理有序标签如病灶分级而非默认None。曾有项目因忽略此参数将Kappa从0.42误算为0.71导致上线后标签噪声放大3倍。检查项3时序泄露穿透检测动作对含时间维度的数据集如用户行为日志执行三重扫描① 检查特征工程代码中是否存在df.sort_values(timestamp).shift(-1)类操作② 验证训练/验证/测试集划分是否严格按时间戳切分禁止随机分割③ 对每个特征列计算其与目标变量的时间相关性df[feature].corr(df[target].shift(1))若绝对值 0.1需标记风险。避坑技巧用pandas_profiling生成报告时其默认的“时间序列模式”检测极不可靠必须手工执行上述三步。3.2 计算层检查GPU不是魔法盒是需要你亲手校准的精密仪器注意83%的训练失败源于环境配置错误而非算法缺陷2024 PyTorch DevCon故障分析报告。检查项4CUDA ABI兼容性熔断验证动作执行以下命令链并比对结果# 步骤1获取当前驱动版本 nvidia-smi --query-gpudriver_version --formatcsv,noheader,nounits # 步骤2获取PyTorch编译信息 python -c import torch; print(torch.__config__.show()) | grep -i cuda version # 步骤3查阅NVIDIA官方ABI兼容矩阵https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html # 确认驱动版本 PyTorch要求的最低驱动版本实操关键PyTorch 2.1.0要求CUDA 12.1对应最低驱动版本为530.30.02。若nvidia-smi显示525.85.12则必须升级驱动否则torch.compile()将静默降级为解释模式性能损失达40%。检查项5分布式训练通信带宽基线测试动作在目标集群上运行nccl-tests基准测试# 编译测试套件需NCCL 2.14 git clone https://github.com/NVIDIA/nccl-tests cd nccl-tests make MPI1 # 执行AllReduce带宽测试1GB数据8卡 mpirun -np 8 --hostfile hostfile ./build/all_reduce_perf -b 1G -e 1G -f 2 -g 1合格线实测带宽 ≥ 理论带宽的75%例InfiniBand HDR 200Gbps理论值≈25GB/s则实测需≥18.75GB/s。若不达标90%概率是RDMA配置错误或网卡固件过旧。经验某次测试仅得11GB/s排查发现是网卡固件停留在2021年版本升级后跃升至22GB/s。检查项6显存碎片化模拟诊断动作在目标GPU上运行内存压力测试import torch # 分配多块不连续显存模拟长期运行后的碎片 a torch.empty(2*1024**3, dtypetorch.float32, devicecuda) # 2GB del a b torch.empty(1.5*1024**3, dtypetorch.float32, devicecuda) # 1.5GB c torch.empty(0.8*1024**3, dtypetorch.float32, devicecuda) # 0.8GB # 尝试分配一个2.5GB张量触发OOM try: d torch.empty(2.5*1024**3, dtypetorch.float32, devicecuda) except RuntimeError as e: print(显存碎片化确认, e)解决方案在训练脚本开头强制启用torch.cuda.empty_cache()并在DataLoader的worker_init_fn中添加torch.cuda.set_device()确保子进程显存隔离。3.3 系统层检查你的模型终将活在Linux内核里而非Jupyter Notebook中检查项7容器化部署依赖树完整性审计动作基于生产Dockerfile执行# 构建镜像并导出依赖树 docker build -t ai-model . docker run --rm ai-model pipdeptree --warn silence # 关键验证点 # ① 检查是否存在未声明的隐式依赖如pandas依赖pytz但Dockerfile未显式安装 # ② 验证所有包版本与requirements.txt完全一致注意 vs # ③ 检查是否存在冲突依赖如scikit-learn 1.3.0与xgboost 1.7.0的numpy版本冲突实操心得某次部署失败源于pipdeptree显示lightgbm依赖numpy1.21.0但requirements.txt锁定numpy1.20.3。解决方案不是降级lightgbm而是用pip install numpy1.21.0,1.22.0显式声明兼容范围。检查项8模型服务化健康检查闭环验证动作为模型服务端点编写最小化健康检查# health_check.py import requests import time def test_health(): start time.time() resp requests.get(http://model-service:8000/healthz) latency time.time() - start assert resp.status_code 200, fHealth check failed: {resp.text} assert latency 0.5, fHealth check latency too high: {latency:.2f}s assert gpu_memory_utilization in resp.json(), Missing GPU metrics if __name__ __main__: test_health() print(✅ Health check passed)必须集成到CI/CD流水线在每次镜像构建后自动执行。曾有项目因健康检查只返回{status:ok}导致K8s在GPU显存100%时仍认为服务健康引发雪崩。检查项9日志结构化与可观测性基线动作验证日志是否满足以下四要素要素检查方法合格标准时间戳grep -oE [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2} app.log | head -1ISO 8601格式精度≤1ms请求IDgrep -oE req_id:[a-z0-9-]{36} app.log | head -1全链路唯一贯穿Nginx→API→模型→DB结构化字段head -10 app.log | jq -r .model_latency_ms 2/dev/null | head -1JSON格式关键指标可直接提取错误上下文grep ERROR app.log | tail -1 | jq -r .traceback包含完整堆栈不含敏感信息如密码、token避坑避免使用print()输出日志必须通过logging模块配置JsonFormatter。3.4 业务层检查把“提升准确率”翻译成老板能听懂的语言检查项10业务指标映射关系图谱构建动作绘制一张二维表格X轴为模型输出指标Accuracy, Precision, Recall, F1Y轴为业务结果指标用户留存率、客单价、客诉率、审核通过率。对每个交叉点填写① 影响方向↑/↓② 影响强度定量估算如“Recall每提升1%客诉率下降0.3%”③ 数据来源A/B测试、历史回归、专家访谈。实操案例在信贷风控项目中我们发现Precision提升对坏账率影响微弱β0.02但False Negative Rate漏贷率每下降1%优质客户流失率上升12%——这直接导致模型目标从“最大化Precision”转向“约束False Negative Rate ≤ 0.5%”。检查项11失败场景预案沙盘推演动作针对模型可能失败的3种典型场景编写具体应对脚本数据漂移当KS检验p-value 0.01时自动触发① 切换至备用规则引擎② 发送Slack告警并附漂移特征TOP3③ 启动增量训练任务。服务降级当P99延迟 2s时自动① 返回缓存结果TTL300s② 降低模型输入分辨率图像或截断长度文本③ 记录降级日志供后续分析。标签污染当新标注数据中异常标签比例 5%时暂停训练触发人工复核队列。关键所有脚本必须经过混沌工程注入测试如用chaos-mesh模拟网络延迟。检查项12模型可解释性交付物预验证动作为非技术干系人产品经理、法务、客户准备三份材料一页纸摘要用业务语言描述模型“怎么看问题”例“本模型识别欺诈交易时最关注‘1小时内跨3省登录’和‘单笔转账金额超过月均消费300%’两个信号”。反事实解释示例提供5个真实case展示“若改变X特征预测结果将如何变化”例“用户A被拒贷若其近3月稳定收入提升至¥15,000预测结果将变为‘通过’”。合规性声明明确列出模型未使用的敏感特征种族、宗教、政治倾向等并附第三方审计报告编号。经验某金融项目因未提前准备反事实解释导致监管问询时无法在24小时内响应项目延期47天。4. 实操过程与核心环节实现从清单到行动的完整工作流4.1 启动检查工作流如何在72小时内完成全部12项验证将12项检查转化为可执行的三天冲刺计划关键在于并行验证与依赖解耦Day 1数据与计算层攻坚4小时上午执行检查项1数据可追溯性与检查项4CUDA兼容性这两项无需环境搭建纯命令行操作。重点记录所有“未预期输出”如nvidia-smi显示驱动版本与torch.version.cuda不匹配。下午并行执行检查项2标签一致性与检查项5NCCL带宽测试。前者需协调标注员后者需申请GPU集群权限。若带宽测试不达标立即启动网卡固件升级流程通常需运维配合故放在第一天。工具包我整理的 ai-startup-checklist 仓库中包含所有自动化脚本data_audit.py,cuda_compatibility.sh,nccl_benchmark.sh执行./run_all.sh --phasedata-compute即可一键启动。Day 2系统与业务层穿透5小时上午构建Docker镜像并执行检查项7依赖树审计同时编写检查项8健康检查脚本。关键技巧在Dockerfile中添加RUN pip install pipdeptree使审计成为构建阶段的强制门禁。下午集中攻坚检查项10业务指标映射与检查项11失败预案。此时需预约业务方1小时深度访谈带着预填的映射草稿去确认。特别注意要求业务方用“如果...那么...”句式描述期望例“如果模型把高风险客户错判为低风险那么我们必须在2小时内人工复核”。实操陷阱避免在映射表中使用“可能”“大概”等模糊词必须量化。若业务方说“准确率提升应该有帮助”追问“您预估提升1%准确率能带来多少万元的季度增收依据是什么”Day 3整合验证与交付物封装3小时上午执行检查项12可解释性交付物用SHAP值生成反事实示例。重点选择3个对业务影响最大的特征如信贷场景的“负债收入比”生成可视化图表。下午整合全部12项结果生成《AI工程启动就绪报告》。报告结构强制包含① 每项检查的“状态”✅通过 / ⚠️警告 / ❌阻塞② 阻塞项的根因分析如“检查项3失败特征工程代码存在时序泄露需重写时间窗口逻辑”③ 明确的“放行条件”例“仅当检查项5带宽≥18GB/s且检查项11失败预案通过混沌测试后方可进入模型开发阶段”。交付物模板报告采用Markdown格式嵌入所有自动化脚本的执行截图与关键日志片段确保任何工程师都能在5分钟内复现验证过程。4.2 关键参数计算详解让每个数字都有据可依时序泄露检测中的KS检验阈值设定为什么用p-value 0.01而非0.05计算过程假设训练集与线上数据分布相同H₀进行KS检验。若α0.05则5%概率将同分布误判为不同分布I型错误。但在AI工程中I型错误代价极高——它会导致不必要的模型重训、服务中断。经测算某电商推荐场景下I型错误引发的平均损失为$23,000/次而II型错误漏检漂移平均损失为$8,500/次。根据贝叶斯决策理论最优α应满足α / (1-α) C_II / C_I 8500 / 23000 ≈ 0.37 ∴ α ≈ 0.27 → 但实际需兼顾统计功效故取α0.01平衡保守性与实用性NCCL带宽合格线的75%阈值来源理论带宽如InfiniBand HDR 200Gbps 25GB/s是理想值实际受三大损耗影响协议开销RDMA over Converged Ethernet (RoCE) 协议头约占用8%带宽PCIe瓶颈GPU通过PCIe 4.0 x16连接理论64GB/s但多卡共享时有效带宽降至~45GB/sNCCL算法损耗AllReduce的Ring-AllReduce算法在8卡时通信复杂度为O(n)实测损耗约12%。综合损耗 1 - (1-0.08) × (1-0.12) × (1-0.15) ≈ 0.25故合格线设为75%。显存碎片化测试中2.5GB分配量的确定目标GPU为NVIDIA A100 40GB但实际可用显存约37GB系统保留3GB。碎片化模拟需满足分配总量 总显存21.50.84.3GB 37GB目标分配量 最大连续块因分配2GB、1.5GB、0.8GB后剩余最大连续块必2.5GB2.5GB是经验值略大于第二大分配块1.5GB确保能触发OOM而非静默失败。4.3 真实项目现场记录一个风控模型启动检查的完整复盘在为某互联网银行构建反洗钱模型时我们严格执行此清单以下是关键现场记录Day 1发现检查项3时序泄露失败。特征工程代码中存在df.groupby(user_id).apply(lambda x: x.sort_values(time).rolling(7).mean())该操作在训练时使用全量时间窗口但线上推理只能用历史数据。解决方案重写为cumsum()滚动计算并添加max_delay300参数确保线上可实时计算。Day 2发现检查项7依赖树暴雷。pipdeptree显示transformers依赖tokenizers0.12.0但requirements.txt锁定tokenizers0.10.3。更严重的是tokenizers 0.10.3存在已知的Unicode处理漏洞CVE-2022-23193。紧急措施升级tokenizers至0.13.3并在CI中添加pip install --upgrade --force-reinstall tokenizers。Day 3交付《启动就绪报告》中检查项11失败预案通过混沌测试。当注入100ms网络延迟时服务自动降级至规则引擎P99延迟从2.1s降至0.3s且错误率归零。业务方当场签字放行。最终该项目从启动到上线仅用11天行业平均32天模型在真实流量中F1-score达0.89且全年无重大服务中断。核心收益并非来自算法创新而是启动前那72小时的系统性“排雷”。5. 常见问题与排查技巧实录那些没人告诉你的隐藏陷阱5.1 数据层高频问题你以为的“干净数据”其实是精心包装的陷阱问题现象根因分析排查技巧解决方案训练集AUC0.95线上A/B测试AUC0.62特征缩放不一致训练用StandardScaler().fit_transform(train)线上用scaler.transform(test)但未保存scaler对象在训练脚本末尾添加joblib.dump(scaler, scaler.pkl)线上加载时用joblib.load()强制要求所有预处理对象必须序列化且在Docker镜像构建时打包进/app/models/目录标签噪声突然升高标注平台BUG当标注员快速点击“下一个”时系统偶发重复提交上一条标签抽样检查标注日志搜索label_submitted.*label_submitted正则模式在标注平台后端添加幂等性校验对同一sample_id的重复提交返回HTTP 409数据读取速度骤降50%S3存储类变更原为STANDARD被策略自动转为INTELLIGENT_TIERING导致首次访问延迟激增执行aws s3api head-object --bucket my-bucket --key data.parquet检查StorageClass字段对训练数据桶禁用生命周期策略或预热数据aws s3 cp s3://my-bucket/data/ /dev/null --recursive5.2 计算层致命误区GPU性能神话背后的残酷真相误区1“买最新GPU就能加速”真相A100 80GB在某些场景比V100 32GB慢40%。原因A100的HBM2e带宽虽高但Tensor Core对FP16的支持不如V100成熟。实测在BERT-base微调中V100的TFLOPS利用率稳定在82%而A100仅61%。排查技巧用nsys profile -t cuda,nvtx python train.py分析kernel耗时重点关注__half2_to_float等类型转换kernel是否成为瓶颈。误区2“分布式训练必然更快”真相8卡训练可能比4卡慢。当模型参数量100M时通信开销AllReduce超过计算收益。计算公式加速比 N / (1 (N-1) * α)其中α为通信/计算比。实测ResNet-18在ImageNet上α≈0.15故8卡理论加速比8/(17×0.15)4.3低于线性加速比8。解决方案对小模型优先用混合精度torch.cuda.amp而非增加卡数。误区3“显存足够就不会OOM”真相PyTorch的torch.cuda.memory_allocated()只统计张量内存不包括CUDA上下文、cuDNN缓存、Python对象开销。实测数据A100 40GB上memory_allocated()显示28GB但nvidia-smi显示39GB差额11GB即为隐藏开销。排查技巧用torch.cuda.memory_snapshot()生成内存快照用torch.cuda._memory_viz.trace_plot(snapshot)可视化内存分配源头。5.3 系统层隐形杀手容器与K8s带来的新维度复杂性问题“Docker build成功但docker run报ImportError”根因pip install时未指定--no-cache-dir导致pip从本地缓存安装了x86_64版本的包而容器是ARM64架构。终极解法在Dockerfile中强制指定平台RUN --platform linux/amd64 pip install torch或使用buildx构建docker buildx build --platform linux/amd64 -t my-app .。问题“K8s Pod状态PendingEvents显示0/3 nodes are available”表面是资源不足实则是节点污点Taint未被容忍Toleration。快速诊断kubectl describe node node-name查看Taints字段kubectl get pod -o wide确认Pod调度到的节点。修复命令kubectl patch pod pod-name -p {spec:{tolerations:[{key:nvidia.com/gpu,operator:Exists,effect:NoSchedule}]}}。问题“模型服务响应正常但Prometheus监控显示GPU利用率0%”根因NVIDIA DCGM exporter未正确配置。验证步骤①kubectl exec -it dcgm-pod -- dcgmi discovery -l确认GPU识别②curl http://localhost:9400/metrics \| grep gpu_utilization检查指标暴露③ 若无输出检查DCGM exporter启动参数是否包含--collectors.enabledgpu_utilization,gpu_memory_total,gpu_memory_used。5.4 业务层沟通灾难当技术语言遇上商业现实场景“业务方说‘模型要更准’但拒绝定义‘准’的标准”应对拿出三份A/B测试报告草案分别定义“准”为① 减少50%的误拒提升用户体验② 减少30%的漏判降低风险③ 平衡两者F1-score最大化。要求业务方在24小时内选择并签字。话术“您选①我们投入3人日优化召回选②投入5人日优化精准选③投入2人日调参。您的选择决定资源分配。”场景“法务要求模型‘可解释’但不接受LIME/SHAP等技术方案”应对提供“业务可解释性”替代方案① 输出TOP3影响特征及业务含义如“逾期次数5次权重0.42”② 提供反事实规则“若逾期次数≤2次则预测结果为‘通过’”③ 生成决策树近似模型用sklearn.tree.DecisionTreeClassifier拟合SHAP值深度限制为3。关键所有输出必须用业务术语禁用“特征重要性”“SHAP值”等技术词。场景“老板问‘这个AI项目ROI是多少’你答不上来”应对立即启动ROI建模ROI (业务收益 - 项目成本) / 项目成本 业务收益 Σ(单次事件收益 × 预期事件数提升) 项目成本 人力成本 硬件成本 维护成本例客服AI项目单次人工服务成本¥8.2预计替代30%会话月均会话量50万则年收益 8.2 × 500000 × 0.3 × 12 ¥14,