Are We Sacrificing Cemeteries for AI这句话如果只看字面很像文化评论为了给 AI 让路我们是不是连存放记忆的地方都要牺牲掉但放到 AI 应用开发、AI 模型部署和 AI 工程实践里它其实是一道非常具体的成本题。跑一个 AI 任务真正花掉的不只是显卡价格或 API 账单还有显存、内存、存储、带宽、功耗、散热、硬件折旧以及为了赶进度被埋掉的老流程、旧代码和原本够用的基础设施。既然项目正文和摘要都是空的我就按一个 AI 工程师在真实项目里会关心的角度来拆AI 到底消耗了什么、这些消耗怎么量化、部署一个 AI 应用前要做哪些评估、为什么 AI Agent 会让资源账单翻倍以及怎样在“能跑起来”和“能长期维护”之间做取舍。这不是唱反调而是把「AI 很厉害」这句话落地成「AI 需要多少资源」之后每个人都会遇到的现实问题。1. AI 的真正成本比“显卡价格”更值得关注1.1 从“墓地”这个比喻聊起AI 建设往往意味着让旧事物先让路“墓地”这个词放在 AI 语境里可以有两种解释。一种解释是物理层面的。AI 模型训练和推理需要大规模数据中心而数据中心选址会占用土地、消耗大量电力和水资源。在一些地方新机房要建在郊区、旧厂区甚至原本规划给公园和公共设施的土地上。这不是 AI 独有现象过去云计算扩张时也发生过只是 AI 的功耗密度更高矛盾更集中。另一种解释是技术层面的。AI 迭代速度快很多旧模型、旧接口、旧框架会被快速替换。今天还在用的流程明天可能因为换了模型版本而失效。旧代码像一片被遗忘的“墓地”无人维护但又不敢轻易删除。真正做 AI 工程实践的人几乎都见过这种“模型坟场”。我认为这里值得警惕的不是 AI 本身而是“为了上新模型不愿意保留迁移成本”的思维方式。任何技术进入生产环境都应该先回答一个问题它替代了什么替代之后省下的资源和多花掉的资源分别是多少。1.2 三本账资金账、资源账、时间账聊 AI 成本不要只看一个指标。我会把它拆成三本账。资金账最好理解。买显卡要花钱租云主机要花钱调用外部模型 API 要按 Token、按图片张数、按视频生成秒数计费。部分服务提供商还会把计费用单位叫 credits不同平台叫法不一样但本质都是“单次请求的计量单位”。很多人只看模型价格就觉得项目可行忽略了 credits 会随输入长度、输出长度、图片分辨率、视频时长成倍增长。资源账是更隐形成本。包括显存占用量、内存占用量、CPU 利用率、磁盘 IO、网络带宽和功耗。同样的模型输入长度翻一倍KV Cache 会变大显存占用跟着上涨并发数提高之后GPU 显存不够就会被挤到 CPU 和内存速度立刻下降。资源账不只在购买硬件时算一次而是每次调整参数后都要重新看。时间账最容易被忽略。训练一个模型要时间微调要时间跑一次推理也要时间。AI Agent 更夸张一个用户请求进来可能要串行调用多次模型每次调用都有网络延迟和模型生成时间。时间账会直接影响用户体验也会影响服务器资源释放效率。如果你正在做 AI 应用开发或 AI 产品规划建议把这本账放进需求文档里。不要只写“我们要接入大模型”要写清楚预计单日调用量、高峰期并发量、平均输入长度、平均输出长度和可容忍的最长等待时间。2. 跑一个 AI 任务资源账单应该怎么算2.1 从一个模型实例反推硬件需求做 AI 模型部署时第一件事不是直接上代码而是估算一个模型实例要占用多少显存。对于常见的 Transformer 大模型一个粗略估算思路是模型权重显存约等于参数量乘以每个参数占用的字节数。全精度 fp32 是 4 字节半精度 fp16 是 2 字节量化到 int8 是 1 字节。比如一个 70 亿参数模型如果加载成 fp16权重部分大约需要 14GB 显存。这只是权重还没算中间激活值、KV Cache、框架缓存和输入输出缓存。所以实际部署时单卡 24GB 显存跑 70 亿参数模型会非常紧张往往要降低上下文长度、减小批量数或者用量化版本。这几个数字之间是互相拉扯的关系。上下文越长KV Cache 越大批量数越大激活值占用越多量化程度越高显存占用越少但推理精度可能下降。我一般会先做一次最小配置测试单条请求、短上下文、批量数为 1先确认模型能不能正常加载并输出然后再逐步加大上下文和批量数。2.2 单次推理之外批量任务还多了哪些开销很多人在本地跑通一次推理之后就以为部署到服务器上也能直接跑批。实际上批量任务比单次推理多出好几层开销。首先是排队开销。多个请求同时进来GPU 只能分批处理如果请求到达速度超过处理速度队列就会越积越长。此时看单次推理耗时已经没意义要看端到端响应时间。其次是输入输出开销。批量任务往往要读取大量文件把处理结果写回磁盘。如果输入是超长文本、多页 PDF或者输出是图片、视频磁盘 IO 会成为主要瓶颈。我遇到过不少情况模型本身只花了 10 秒但读取一个超大 JSON 文件花了 30 秒。再次是失败重试开销。批量任务中遇到网络超时、模型输出格式错误、中间某条数据处理异常很常见。如果没有失败重试机制整个队列可能在中途中断如果重试策略太激进又会给模型服务增加额外压力。建议先跑一小批样例比如 5 到 10 条确认成功率和输出完整性之后再扩大到全量。2.3 给一个“够用”配置的快速判断标准不同 AI 任务对资源的需求差异非常大。下面这张表是启动评估时可以参考的通用标准不是精确值具体要以你的模型版本和实际测试为准。任务类型典型需求入门配置参考建议先做的小样本测试文本生成 / 对话显存集中在模型权重和 KV Cache8GB 到 24GB 显存纯 CPU 也能跑小模型单轮对话短上下文确认响应速度文本分类 / 信息抽取显存需求低重在对齐格式4GB 到 8GB 显存即可先测 20 条典型样本看返回结构是否稳定AI 绘画 / 图像生成显存与分辨率、采样步数正相关8GB 到 16GB 显存适合低分辨率测试固定分辨率先跑 1 张图观察峰值显存AI 视频生成显存、内存、生成时间和磁盘占用都很高16GB 以上显存只是起点仍要控制时长和分辨率先跑 3 秒 480p不要一上来就生成 1080p 长视频AI Agent / 复杂工作流显存未必高但调用次数多、延迟叠加多轮调用时更看重网络延迟和超时设置先跑单轮工具调用再跑多轮任务链路AI 编程辅助 / 代码补全对延迟敏感需要快速返回云端服务通常比本地部署更省事先测补全速度再看代码格式是否完整这套判断标准的重点不是“够不够用”而是“先做什么”。文本任务先看显存和模型加载速度图像任务先看分辨率和批量数视频任务先看时长和分辨率Agent 任务先看调用次数和超时时间。每类任务的瓶颈完全不同别用一套参数打天下。3. 部署 AI 应用前先做一轮容量与成本评估3.1 需求拆解先确认任务形态再选模型很多 AI 项目一开始就陷在“选哪个大模型”里但其实更该先问这个任务到底是什么形态。任务形态大致分三种。第一种是判别式任务比如文本分类、内容审核、信息抽取输出是结构化字段。第二种是生成式任务比如写文章、写代码、生成图片、生成视频输出是自然语言或媒体文件。第三种是决策式任务比如 AI Agent要理解用户目标、调用工具、观察结果、再决定下一步动作。不同形态对应的模型选型完全不同。判别式任务不一定要用最强模型一个小模型加良好提示词往往就够了。生成式任务要看输出格式和稳定性比如代码生成要重点验证语法是否完整视频生成要重点验证画面连贯性和时长限制。决策式任务要额外考虑工具调用可靠性模型可以理解指令但不代表每个工具动作都执行得正确。我建议用一页纸把需求写清楚输入是什么格式、输出是什么格式、一次任务最长需要多久、单日最大多少任务、失败后能否重试。写清楚之后再进入技术选型很多纠结自然消失。3.2 三种运行方式怎么选本地、API、自建服务部署 AI 应用主要有三种方式没有绝对好坏只有适不适合。本地运行适合学习验证、隐私敏感场景和离线环境。优点是不依赖网络单次调用没有外部费用缺点是硬件投入高环境维护要自己负责。如果只是跑一个小模型做练习本地 CPU 都可以但速度会明显慢。调用外部 API适合快速验证业务闭环。你不需要关心显卡和显存只需要关注请求格式、返回结构、计费单位和并发限制。缺点在于数据要发给外部服务很多企业数据合规不允许这种模式另外长期大规模调用累计费用不一定比自己部署便宜。自建服务适合并发稳定、调用量长期较大的场景。可以把模型部署在自己的 GPU 服务器或云主机上自己掌控模型版本、并发策略和监控但也要自己处理部署、更新、告警和扩容。很多人低估了“自建”的运维成本模型服务并不像启动 Web 服务那么简单显卡驱动、依赖版本、内存泄漏、显存碎片都是坑。对比维度本地运行外部 API自建服务硬件成本前期投入高无硬件成本按资源租用或购买数据隐私数据不出环境数据需要出网数据在自有环境延迟取决于硬件取决于网络和厂商排队可控但要做容量规划运维工作量中低高适合阶段学习、验证、离线场景快速原型、中小规模稳定批量、高并发、长期运行选择时不要只看算力单价还要看维护时间。如果你只有一个人同时要写业务代码、处理数据、部署模型我不会建议你一开始就自建推理服务。先用 API 跑通业务逻辑等调用量稳定之后再把真正高频的模型切到自建服务上。3.3 容量评估的四个参数并发、超时、批量数、最大输入长度做容量评估时最核心的参数是这四个并发数、超时时间、批量数和最大输入长度。并发数决定系统能同时处理多少请求。并发数不是越高越好。并发过高模型服务可能排队严重单次请求等待时间变长最终反而拖慢整体吞吐。我一般会从低到高逐步加压比如先开 1 个并发跑 100 条任务再开 5 个、10 个观察成功率、响应时间和 GPU 利用率变化找出拐点。超时时间决定任务卡住多久会被放弃。设置太短正常的长文本生成会被误杀设置太长故障任务会一直占着资源。建议先统计正常任务耗时分布把超时设置成 P95 耗时的 2 到 3 倍。例如大多数任务在 30 秒内完成剩余长尾任务可能需要 60 秒超时可以先定 90 秒。批量数影响显存利用率和吞吐。对 GPU 推理来说批量数增加通常能提高吞吐但会迅速推高显存占用。小批量并不一定效率低尤其是生成式任务每个序列长度不同大批量可能导致计算浪费。最大输入长度是最容易被低估的参数。输入长度直接决定 KV Cache 大小输入越长显存占用越大。文本任务要限制单条文本最多多少字符图像任务要限制最大分辨率视频任务要限制最长秒数。没有限制的话来一条超长输入服务可能直接 OOM。这四个参数最好在测试环境里先压一遍。能跑通不等于能稳定跑能稳定跑不等于在高并发下能跑。容量评估的意义就是提前发现资源瓶颈而不是等线上告警才发现。4. AI Agent 让资源消耗从“一次推理”变成“一串推理”4.1 一个 Agent 动作背后往往有多次模型调用如果你只是做一个文本生成接口成本曲线相对平缓一次请求一次模型调用一次响应。但 AI Agent 不是这样。一个 Agent 任务通常要经历多轮循环。用户给出目标Agent 先要理解意图然后决定调用哪个工具工具返回结果后Agent 要重新组织上下文决定下一步动作。每一步都是一次模型调用甚至一次调用要同时完成“理解结果”和“生成下一步计划”两件事。举个例子一个“帮我整理会议纪要并发送邮件”的 Agent可能先调用一次大模型做摘要再调用一次大模型提取收件人和发送动作再调用一次大模型生成邮件正文最后还要调用一次大模型确认发送结果。这还只是理想路径。如果中间某次工具调用返回格式异常Agent 可能要进行修复或重试调用次数继续增加。这也是为什么很多 AI Agent 项目跑起来之后账单会比预期高很多。单次调用看着便宜但一个用户会话可能要触发十几次甚至几十次调用。再加上上下文不断累积后面每轮调用的输入 Token 都越来越大成本不是线性增长而是接近指数增长。4.2 优化 Agent 资源占用的工程手段优化 AI Agent不能只从模型提示词下手更要从调用链路上控制资源。第一加缓存。如果用户问题相似或者工具返回结果相似可以缓存中间结果避免每次从头调用。缓存的粒度可以细到“某段工具输出对应的摘要结果”而不只是整个 Agent 会话。第二控制上下文长度。很多 Agent 框架会把历史对话全部塞进模型导致输入越来越长。可以把多轮历史做摘要只保留最近几轮完整消息。对长文本工具结果先做检索或截断再送进模型。第三给工具调用设置最大次数。Agent 进入死循环是常见问题模型可能反复调用同一个失败工具。比如允许单次任务最多调用 5 个工具超过就主动结束并返回部分结果。这样可以避免资源被无限占用也能防止用户看到“无限转圈”的体验。第四设置单次任务的 Token 上限。很多模型服务支持 max tokens超过则截断。不要因为担心输出不完整就无限放开尤其在生产环境要同时考虑输出质量和资源保护。第五区分快速路径和慢速路径。简单请求可以走一个小模型一次调用完成复杂请求才启动大模型和多个工具的多轮链路。这样可以大幅降低平均资源消耗同时保证复杂场景的能力上限。4.3 什么时候该砍掉 Agent用固定流程有经验的产品经理和工程师会承认一个事实不是所有任务都适合 Agent。如果任务流程固定、条件分支少用传统程序加少量模型调用更稳定。比如“每天定时拉取数据、做格式化报告、发送到某个渠道”完全可以用定时任务加固定提示词实现不需要让 Agent 理解目标并自己规划步骤。固定流程的好处是失败点和成本都可控出问题容易排查。如果任务是开放式目标用户输入千变万化且需要多个工具配合Agent 才有价值。比如“帮我搜集某行业过去一周的动态并整理成简报”这种任务输入不可枚举需要 Agent 拆解子任务。可以用固定流程先覆盖 80% 的常见场景再让 Agent 处理长尾开放场景。这种“混合架构”在 AI 应用开发里越来越常见。判断标准很简单如果每次任务的步骤完全一样就不要让 AI 每一步都重新思考如果每次任务的步骤都不同才值得用 Agent。这样可以省下的资源和运维开销比你换一个更贵的模型明显得多。5. 运行稳定性和长期维护不能只看第一次跑通5.1 显卡利用率、温度、功耗和硬件的寿命关系模型能跑通不代表硬件能持续稳定地跑。GPU 在长时间高压场景下温度、功耗、利用率三者会互相影响。当 GPU 温度过高显卡会自动降频表现为推理速度变慢、响应时间变长。这时候你去看利用率可能仍然很高但实际算力已经下降。如果任务卡顿先看温度和频率不要只盯着利用率。功耗也会影响成本。同样的任务如果显存反复分配释放、数据频繁在 CPU 和 GPU 之间拷贝功耗会明显上升。合理的批处理和内存复用能降低峰值功耗同时让整体吞吐更高。硬件寿命和散热强相关。长时间在 85 度以上运行电子元器件老化速度会加快。机房环境里要关注进风口温度和积灰情况家用环境或者小办公室部署 AI 工作站更要注意通风。有些人在机箱里堆好几张卡没做散热规划训练还没结束硬件先出问题这种代价比电费贵得多。5.2 任务失败时先按这个顺序排查AI 任务报错最容易犯的错误是直接怀疑模型能力。实际上很多问题出在模型之外。我建议按这个顺序排查能省下大量时间先看输入。输入文件是否存在、路径是否正确、编码是否为 UTF-8、字段名是否匹配、输入长度是否超过限制。很多“模型输出乱码”其实是输入文本本身就有不可见字符。再看日志。模型服务通常有应用日志和系统日志先看应用日志里有没有超时、连接拒绝、显存不足的明确报错没有的话再看系统日志可能触发系统层面的 OOM 或被 kill。查资源占用。用命令查看 GPU 利用率、显存占用、内存占用和磁盘 IO。如果显存已满新请求会排队或失败如果内存持续增长可能有内存泄漏。看参数配置。批量数、并发数、超时时间、最大输入长度、模型路径、模型版本任何一个参数和预期不符都可能产生奇怪结果。最后才怀疑模型本身。如果前面四项都正常再考虑是不是模型对某个特殊格式不敏感或者提示词缺少约束。这个过程看起来简单但很多人会跳过日志直接改提示词结果改了十几版问题还是原来的路径错误。先说一句结论AI 工程里稳定不是“它大多数时候能跑”而是“任何一次失败都能被快速定位”。做到这一点靠的就是日志、资源监控和参数记录。5.3 数据、日志、输出目录这些“看不见的工程债”模型代码写完之后真正决定项目能否长期维护的往往是数据、日志和输出目录。数据版本要可追溯。AI 任务高度依赖输入数据数据换了版本模型输出就可能变化。建议给每批数据添加版本号或哈希值避免“上次跑得好这次不知道改了哪份文件”。日志要能还原链路。对 Agent 任务尤其重要每次调用要记录用户请求、模型输入、模型输出、工具调用耗时和中间结果。如果日志只记录“成功”或“失败”排查时基本无从下手。输出目录要规范。批量任务建议按“任务ID/批次号/文件名”组织输出避免覆盖。如果输出结果需要回写数据库要记录写入状态便于失败重投。很多人跑批量任务时只关注“最后生成了多少文件”不关注“哪些文件是成功生成、哪些是失败重试”这样一两天就会乱。这些工程债不会在第一次跑通时显现但会在第十次任务、第一百次任务时变成主要时间消耗。做 AI 工程实践本质上是在跟“不可控”打交道越是不可控的任务越要把输入、输出和日志这些可控部分做扎实。6. 给你的 AI 工程准备一张实用检查清单6.1 第一次跑 AI 任务前先确认这些条件我把第一次跑 AI 任务前要确认的条件整理成一个清单每一条都来自实际踩坑经历模型文件和依赖版本是否已经确认不要直接拿默认版本。输入数据路径是否存在目录权限是否可读输出目录是否可写。显存、内存、磁盘剩余空间是否充足。上下文长度、最大输出长度、批量数、并发数是否已经根据任务设置过。是否先跑了一条最小样例验证从输入到输出的完整链路。日志是否开启日志级别是否足够定位问题。外部 API 的密钥、计费单位、并发限制是否已经确认。这些条件不需要一次全部理解清楚但一定要在任务开始前逐项过一遍。哪怕少检查一项都可能让第一次运行变成两次、三次。6.2 从学习 Demo 到线上服务要补哪些东西如果只是学习本地跑一个模型 Demo默认配置通常够用。但要变成线上服务还需要补充很多层。第一层是接口层。把模型调用封装成标准 API定义输入输出结构增加鉴权和频率限制。第二层是任务层。如果任务是异步的需要任务队列、状态管理和失败重试。建议队列用成熟组件不要在内存里自己维护。第三层是可观测层。要记录请求量、延迟、错误率、资源利用率、模型输出长度以及关键环节耗时。最好能按用户、按任务类型拆分监控指标。第四层是容量层。要设置并发上限、超时上限、输入长度上限避免单个异常请求拖垮整个服务。最好提前做一次压测确认当前配置能扛住多少 QPS。第五层是回滚层。模型版本更新后要能快速回到旧版本。保存好模型快照、依赖清单和配置参数升级前先在小流量上验证。这五层不一定要全部做到极致但要在设计初期留出扩展位置。后期再补架构成本远高于一开始规划好。6.3 不要为了“秀 AI”而牺牲公共资源回到标题我不希望这是一篇劝退文章。AI 确实能解决不少实际问题但工程资源是有限的公共资源也是有限的。在规划一个 AI 项目时我更愿意先问“这个任务真的需要用大模型吗真的需要每次都调用最新最强模型吗”答案不一定是否定的。但养成分层使用模型的习惯你会慢慢发现很多场景可以用小块模型、缓存、规则引擎、传统算法完成。这样不仅省成本还会让系统更稳定。真正成熟的 AI 工程不是把每个问题都砸给大模型而是知道哪些问题该让模型上场哪些问题根本不用模型上场。“Are We Sacrificing Cemeteries for AI?” 这个问题从工程视角看答案取决于我们怎么设计资源策略。如果我们总是追求最新模型、最大规模、最高并发那确实会把很多旧有秩序和资源挤到一边。如果我们把 AI 摆在“工具”的位置先算资源账、先做容量规划、先做失败排查那 AI 和原有系统是可以共存的。技术更新的意义不应该以埋掉真正重要的东西为代价。