最近关于 AI 的讨论里有一个题目越来越值得注意当新建数据中心、算力园区甚至相关配套园区需要选址时为什么总是城市边缘的绿地、老厂区、历史街区甚至墓地在“让位”英文里那句 “Are We Sacrificing Cemeteries for AI?” 说的不是字面上的“要不要给 AI 迁坟”而是一个很现实的问题——AI 基础设施的大规模扩张正在以什么样的速度挤占城市空间、能源资源和公共记忆场所我们又该如何在技术与城市之间做可持续的选择。这篇文章不打算站在纯人文角度喊口号而是从工程视角拆解这件事AI 算力扩张的真实成本是什么数据中心选址和部署要考虑哪些前置条件已经在运行的系统如何通过调度、量化和接口设计降低资源占用以及负责任地部署 AI 到底该有什么底线。无论你是做算法、做平台还是负责基础设施规划这些问题都比“下一个模型涨了多少分”更值得先想清楚。全文会围绕“代价可量化、部署可优化、边界可执行”来展开最后给出一套通用排查清单和最佳实践。适合以下读者正在做 AI 基础设施规划的技术负责人被要求评估算力扩容或新建机房成本的工程师以及关注 AI 社会影响的开发者。1. AI 基础设施扩张的代价拆解先建立一个基本共识AI 不是无成本的“云上魔法”。从材料看当前 AI 基础设施扩张主要集中在大规模数据中心、智算中心、配套变电站和冷却设施建设。这些设施的代价可以分成四类代价类型具体表现工程影响土地空间代价数据中心选址占用城市边缘地块、绿地、旧工业区甚至历史区域周边用地需要做土地规划、环评、文保评估选址周期拉长能源代价训练和推理集群长期高功耗运行对电网和绿电比例提出要求影响 PUE、碳排核算和电力成本水资源与热排放代价风冷、液冷和水冷系统消耗水资源机房周边存在热岛效应影响冷却方案选型和散热设计城市功能与公共记忆代价算力园区建设可能改变区域功能甚至需要迁移既有公共设施涉及社会沟通、补偿和遗产保护不只是技术问题从材料看这类冲突不是个案。许多城市规划中已经出现“算力优先”的倾向绿地、老市场、沿河地块甚至历史墓园周边都被纳入选址候选。问题的本质不是“AI 不好”而是“算力需求无限膨胀时城市和社区是否有足够的议价能力”。工程侧的应对思路是把代价提前量化。在立项阶段就计算单位算力的综合资源成本而不是等到建设完成后再补救。具体来说新建 AI 基础设施前至少要评估以下指标单位建筑面积对应的算力密度kW/平方米。预计 PUE电能利用效率目标。峰值用水量和冷却方式。土地性质、文保距离和居民影响范围。电力接入容量和可再生电力比例。生命周期结束后的设备回收与场地修复成本。这个清单不复杂但在实际项目里经常被跳过。很多项目先把机房建起来再回头补环评和节能审查结果要么是选址冲突要么是后期被限电、限水导致业务被迫降载。更稳妥的做法是先做“代价评估”再做“算力规划”最后才进入“设备选型”。2. 适用场景与使用边界AI 基础设施的集中化建设并不适用于所有场景。从工程实践看不同场景对算力形态的选择差异很大场景推荐部署形态理由大规模模型预训练集中式智算中心需要高带宽内部互联和大规模 GPU 集群集中部署成本最低业务推理服务边缘节点 区域中心混合部署降低时延和骨干网压力避免所有流量涌向单一机房数据敏感业务本地私有化部署满足数据合规要求避免跨境或跨域传输实验和原型验证单机多卡或云上按需资源灵活启动、用完即释放避免长期占用物理空间高实时交互场景端侧或边缘侧轻量模型减少网络依赖和中心机房扩容压力换句话说把一切都塞进大型数据中心是不合理的。一个成熟的 AI 基础设施策略应该是“中心 边缘 端侧”的混合结构。使用边界同样重要。以下场景不适合直接建设集中式算力设施历史保护区核心区、饮用水源保护区、基本农田、生态红线范围内。周边基础设施供电、供水、网络、交通无法支撑长期运行的区域。需要大量迁移居民或公共设施但未完成法定程序的项目。没有明确算力需求和业务规划的“形象工程”。同时必须强调合规边界。涉及土地、文化遗产、环境评价时必须以当地法律法规为准不能以“技术先进”为由绕开监管。对于图像、视频、声音等 AI 能力涉及人脸、肖像、声音、版权素材时必须确认授权涉及个人隐私数据必须遵守数据安全和个人信息保护要求。技术部署永远不能成为突破底线的理由。3. 数据中心选址与环境前置条件如果你负责一个真实的算力项目选址阶段需要比“能不能放得下机器”考虑更多。以下是一份通用的前置条件检查清单适用于城市级或园区级 AI 基础设施规划检查项说明常见问题地质条件避开地震带、沉降区、洪水淹没风险区机房建成后地基沉降导致设备故障气候条件年均温度、湿度、极端天气频率高温地区冷却成本高PUE 难达标能源条件电力接入容量、电网稳定性、绿电可获得性高峰期限电训练任务中断水资源条件冷却水供水能力、排水许可液冷系统对水质和水量有要求网络条件骨干网接入点、延迟、带宽冗余单线路故障导致服务中断土地规划用地性质、规划红线、控规条件未批先建或改变土地用途导致处罚文保距离周边历史文化保护区、文物保护单位距离施工可能破坏地下遗存或景观视线社区影响噪音、交通、人口密度、搬迁需求居民诉求导致项目停工实操层面可以用一个简单的评分表给候选地块打分而不是凭感觉决策。例如指标权重地块 A 得分地块 B 得分能源接入30%9070气候冷却条件20%7085文保与社区风险25%5090网络条件15%8075土地合规性10%6095这块地能不能用核心不是“关系”或“速度”而是综合风险最低。一个在技术指标上完美、但需要迁移公共墓园或历史街区的地块往往意味着极高的社会成本和合规风险后期停摆的概率远大于收益。还有一点值得注意很多项目为了赶进度会选择“先建设、后评估”的路子。这在严格的工程管理里是危险的。选址评估应该在概念设计阶段就完成而不是在设备采购之后。评估结果应当保留为项目文档的一部分作为后续环评、能评和土地审批的依据。4. 算力资源部署与调度架构选址问题解决后进入实际部署阶段。AI 算力部署有两种常见架构集中式集群和混合式调度。集中式集群适合模型训练通常采用 Slurm 或 Kubernetes 作为调度系统GPU 节点通过高速网络互联。混合式调度适合训练 推理并存训练任务跑在中心集群推理服务则按业务需求分发到边缘节点或本地集群。下面是一个使用 Kubernetes 声明计算资源的通用示例。实际项目中需要根据集群的 GPU 类型、驱动版本和调度插件调整参数。apiVersion: v1 kind: Pod metadata: name: ai-inference-gpu spec: containers: - name: inference image: your-registry/ai-inference:latest resources: requests: nvidia.com/gpu: 1 cpu: 8 memory: 32Gi limits: nvidia.com/gpu: 1 cpu: 8 memory: 32Gi env: - name: CUDA_VISIBLE_DEVICES value: 0 - name: MODEL_CACHE_DIR value: /models volumeMounts: - name: model-cache mountPath: /models volumes: - name: model-cache persistentVolumeClaim: claimName: model-cache-pvc这个配置的核心是明确告诉调度器这个推理服务需要 1 张 GPU、8 核 CPU、32GB 内存。调度器会据此决定放置位置避免多个任务争抢同一张卡。更大的集群还可以使用节点亲和性和拓扑分布约束把训练任务和推理任务隔离开。对于训练集群一种更接近生产的做法是使用 Slurm 作业脚本提交任务#!/bin/bash #SBATCH --job-namefinetune #SBATCH --nodes4 #SBATCH --ntasks-per-node8 #SBATCH --gresgpu:8 #SBATCH --time24:00:00 #SBATCH --partitiongpu export MASTER_ADDR$(hostname) export MASTER_PORT29500 export NCCL_DEBUGINFO srun python train.py \ --model_name your_model \ --batch_size 32 \ --learning_rate 1e-5 \ --output_dir ./checkpoints这里的关键是不要把所有任务塞进同一个队列。如果训练和推理混跑推理任务会因为等待大规模训练任务而出现高延迟。更合理的做法是划分资源池例如训练池、在线推理池、离线批量推理池每个池子设置不同的资源配额和优先级。5. 推理服务批量任务与接口设计对于大多数团队来说真正的资源消耗大头不是训练而是长时间运行的推理服务。一个问题模型部署上线后每来一个请求都在消耗 GPU 算力。如果接口设计不合理资源浪费非常明显。推理服务接口的基本设计目标是支持批量请求、支持超时控制、支持失败重试、支持并发限制。下面给出一个通用的 Python 调用示例实际使用时要根据模型服务框架的接口路径调整。import requests import time url http://127.0.0.1:8000/v1/generate headers {Content-Type: application/json} payload { prompt: 请用三句话说明数据中心选址的注意事项, max_tokens: 200, temperature: 0.7, stream: False } start time.time() response requests.post(url, jsonpayload, headersheaders, timeout60) elapsed time.time() - start if response.status_code 200: result response.json() print(生成内容:, result.get(text, )) print(耗时: {:.2f}s.format(elapsed)) else: print(请求失败:, response.status_code, response.text)对批量任务不要用 for 循环逐个请求。更高效的方式是合并为批量推理把多个输入一次性发送到服务端。以文本生成类模型为例可以设计如下批量请求结构{ inputs: [ {id: 1, prompt: 第一段文本}, {id: 2, prompt: 第二段文本}, {id: 3, prompt: 第三段文本} ], params: { max_tokens: 128, temperature: 0.6 } }批量任务还应包含一个简单的队列控制和重试机制。以下是一个最小化的失败重试逻辑import time import requests def call_with_retry(payload, max_retries3, timeout60): for attempt in range(max_retries): try: resp requests.post( http://127.0.0.1:8000/v1/generate, jsonpayload, timeouttimeout ) if resp.status_code 200: return resp.json() except requests.exceptions.Timeout: pass time.sleep(2 * (attempt 1)) raise RuntimeError(接口调用失败超过最大重试次数)批量任务队列建议独立于在线推理服务。在线服务强调低延迟批量任务强调吞吐量。如果两者共用同一份 GPU 资源在线服务会被长文本生成任务拖慢。更稳妥的做法是批量任务使用低优先级队列在业务低峰期运行或单独挂到推理负载较低的工作节点上。6. 资源占用与性能观察前面提到很多次“资源占用”这里专门讲清楚观察方法。在 AI 基础设施运营中最怕的不是某个模型效果差而是资源被白白消耗却没人发现。建议至少监控以下指标集群整体 GPU 利用率长时间低于 30% 说明资源分配不合理或任务排队策略有问题。单卡显存占用显存打满而算力利用率低常见于模型过大、batch size 过小或推理框架未开启动态批处理。功耗与 PUE机房功耗由 IT 功耗、冷却功耗和供配电损耗组成PUE 过高说明冷却和供配电需要优化。任务排队时间如果任务提交后长时间处于排队状态可能是资源配额设置过紧或集群碎片化严重。请求延迟分位数P95/P99 延迟能反映在线服务的稳定性只看平均延迟会掩盖尾延迟问题。观察显存占用最直接的方法是使用nvidia-smiwatch -n 1 nvidia-smi也可以使用nvidia-smi --query-gpuindex,utilization.gpu,memory.used,power.draw --formatcsv -l 1间隔统计。如果服务运行在容器中则优先通过 Prometheus Grafana 收集指标而不是频繁执行nvidia-smi因为高频调用会引入额外开销。降低资源占用的通用手段包括手段适用阶段说明模型量化推理部署把 fp16 权重转为 int8/int4减少显存占用但需测试精度损失动态批处理在线推理把并发请求合并为一个 batch提升 GPU 利用率早停和流式输出文本生成达到结束条件时提前停止避免多余计算请求缓存重复业务相同或相似请求直接走缓存不重复推理模型蒸馏推理服务用大模型生成训练数据蒸馏出小模型降低单次推理成本潮汐调度混合负载夜间低峰期运行离线批量任务白天释放资源给在线服务这些手段不是每个项目都要全上而是要根据业务特征选择。对于需要长期运行的 AI 服务“能跑起来”只是第一步“跑得稳定且不浪费”才是工程能力的体现。7. 常见问题与排查方法问题现象可能原因排查方式解决方案服务启动后 GPU 显存不足模型权重过大或 batch size 设置过高查看启动日志和 nvidia-smi 输出降低 batch size、开启量化或换更大显存设备在线推理延迟高批量任务和在线任务混跑观察集群节点 GPU 利用率与队列分布划分训练/在线/批量资源池分离负载任务长时间排队资源配额过小或集群碎片化查看调度器队列和节点资源余量调整配额、增加节点或使用碎片整理策略PUE 偏高冷却系统效率低或机房密封性差查看冷却系统功耗和机房温度分布优化风道、调整空调设定、评估液冷方案API 调用超时模型推理耗时过长或并发过高查看请求日志和服务端进程状态开启动态批处理、增加超时重试、扩容推理副本批量任务中断节点故障或显存泄漏查看任务日志和节点事件加入失败重试机制定期重启推理进程训练偶发中断网络通信问题或驱动异常查看 NCCL 日志和事件日志检查网卡速率、驱动版本和交换机配置数据合规风险输入数据包含未授权人脸/声音/版权内容审计数据来源和授权记录上线前完成数据合规校验建立数据来源清单排查的核心思路是“先看监控再看日志最后才动配置”。不要一出现问题就开始重启那只是掩盖问题。比较稳妥的流程是确认问题影响范围单节点、单任务还是全集群。查看对应时间点的利用率、延迟、错误日志。尝试最小化复现用一条请求或一个小 batch 复现问题。修改一个变量验证效果。记录变更防止问题回归。8. 最佳实践与可持续部署建议回到开头的那个问题我们是不是在为 AI 牺牲城市空间和公共记忆技术侧的回应不应该是否认代价而是用更精细的工程手段减少不必要的扩张并在必须扩张时守住合规底线。以下几条建议适用于大多数 AI 基础设施项目第一先评估再建设。立项前完成能源、土地、文保、社会影响评估项目文档化。第二优先复用现有资源。旧机房改造、闲置园区再利用往往比新建更划算也更少社会阻力。第三能用边缘算力解决的问题不要全堆到中心机房。把模型做小、做快比无限扩大机房更可持续。第四批量任务要有队列、限流和失败重试机制。任务跑挂和任务跑散是两种常见事故都要提前设计。第五接口服务要限制访问范围。内部接口不要直接暴露到公网至少加上鉴权和限流。第六涉及人脸、声音、版权素材、历史遗址和公共空间时必须有授权和合规评估记录。第七发布或商用前做效果复核。不只是看模型指标还要看真实业务场景中的表现。第八做好设备回收和场地修复预案。基础设施有生命周期离开时也要负责任。有些人可能会觉得这些建议“太保守”不够“AI 速度”。但换个角度想如果每一轮算力扩张都要用永久性空间牺牲来换那这种扩张本身是不可持续的。真正可持续的 AI 部署应该是在满足业务需求的同时尽可能降低对土地、能源和社区的影响。9. 总结与下一步这次围绕 “Are We Sacrificing Cemeteries for AI?” 展开的讨论本质是在给 AI 基础设施算一笔综合账。推荐你最先做一件事把当前在跑或计划中的 AI 项目按资源占用、能源消耗、空间占用、合规风险四个维度盘一遍。你可能会发现很多资源浪费不是模型能力不够而是部署和调度过于粗放。最容易踩的坑有两个一是选址评估不到位项目建完后才发现能耗或文保问题二是训练和推理混跑导致在线服务延迟失控。下一步可以做三件事如果你在规划新算力设施先建立选址评估和代价量化清单。如果你已经在运行 AI 服务先检查 GPU 利用率、PUE 和任务排队情况找出利用率最低的那批任务。如果你正在设计接口和批量任务先加上超时、重试、限流和队列隔离防止资源被一个任务拖垮。技术本身不是问题问题在于我们有没有把代价算清楚。想明白这一点“要不要新建机房”就不再是一道单纯的技术选择题而是一道需要工程、管理和社会责任共同回答的题。