6.6 人工智能基础设施与运维

概述与动机

人工智能基础设施与运维，是这样一门学科：以具有成本效益、可靠且可观测的方式，配置、调度和运行人工智能工作负载所需要的专用计算、存储和服务系统。现代人工智能的运行成本高昂。训练和提供大模型服务需要稀缺的加速器（GPU 和 TPU）、高带宽网络、用于检索的大规模向量存储（把数据索引为数值向量，从而能快速找到相似的项目），以及为延迟和吞吐量而调优的服务层。把这套基础设施做对，正是能够可持续扩展的人工智能，与悄悄吞噬预算却收效甚微的人工智能之间的分水岭。

对大型团队而言，核心问题是规模、稀缺性和成本。加速器数量有限且价格昂贵，因此调度和利用率至关重要。闲置的 GPU 就是烧掉的钱，而批处理不当的推理会成倍推高每次请求的成本。检索密集型应用需要向量数据库，并且要在规模增长时仍保持快速。生成式人工智能应用需要提示词（prompt）版本管理、评估流水线和可观测性（有时被称为 LLMOps），才能安全运行并随时间改进。如果没有共享基础设施和运维纪律，每个团队都要各自打同样的仗，成本也会失控攀升。

政府和受监管组织还额外增加了围绕数据主权、安全性和可预测支出的要求。它们可能需要本地部署或主权云部署，使敏感数据和模型永远不离开受控边界。它们必须预测并论证基础设施支出的合理性，并满足安全性和可用性标准。在这些场景中，人工智能基础设施决策会带来跨越多年的后果，因此做出决策时要把采购、安全性和退出路径都纳入考量。

关键原则

把加速器计算资源当作一种稀缺、昂贵的资源来调度和利用，而不是囤积起来。
优化每一单位有效工作的成本，而不是原始容量。
把模型和硬件的规模适配到具体任务；最大的选项很少是成本效益最高的。
把批处理和缓存作为一等技术，为延迟和吞吐量设计服务层。
让人工智能系统可观测：持续跟踪成本、延迟、质量和错误。
用对待代码同等的严谨态度，为提示词和模型设置版本并进行评估。
为可移植性做规划，避免在基础设施和服务选择上被锁定。

建议

规划并控制加速器计算资源

分别预测训练和推理的需求，因为它们的形态不同。训练是突发性的、可调度的；推理是持续的、对延迟敏感的。使用调度器和配额在各团队间共享稀缺的 GPU 和 TPU，为工作负载排定优先级，并提高利用率。度量利用率，把长期闲置当作一个需要解决的问题。混合使用为基准负载预留的容量，以及为突发需求准备的按需或竞价容量，以控制成本。考虑更便宜或更小的加速器、或为轻量级模型使用 CPU 推理，是否已经够用。基于你的规模成本、数据主权需求和突发模式，在云端、本地和混合部署之间做出选择，并保留一条退出路径。

构建检索基础设施：嵌入与向量数据库

对于检索增强型应用，要搭建能生成嵌入（embedding）（把相似项目放在一起的数值向量表示）的基础设施，并将其存储在一个在你的规模下支持快速近似最近邻搜索（无需穷举比较每一个向量即可找到最相似的向量）的向量数据库中。要为三件事做规划：生成嵌入的成本和延迟、随文档变化而保持索引新鲜度，以及保持索引一致性所带来的运维负担。评估专用向量数据库、现有数据库的向量能力扩展，还是托管服务，最适合你的规模和对锁定的容忍度。监控检索延迟和召回率，因为检索质量直接决定应用质量。

优化模型服务：批处理、缓存与延迟

服务层是推理成本和用户体验被决定的地方。使用批处理将多个请求一起处理，提高加速器吞吐量，并在批量大小与延迟之间取得平衡。积极地使用缓存：缓存相同或语义相似的请求，缓存嵌入向量，并在平台支持的情况下利用提示词或前缀缓存，避免重复计算共享的上下文。设定明确的延迟目标，度量长尾延迟，而不只是平均值。把请求路由到规模适配的模型：简单情形使用小模型，只有在需要时才使用更大的模型。根据需求自动扩缩服务规模，并在上线前进行负载测试，以便你了解自己的容量和成本曲线。

践行 LLMOps：提示词版本管理、评估流水线与可观测性

把提示词当作带版本号的产物纳入源代码控制，具备评审和回滚能力。构建评估流水线，在提示词或模型发生变化时自动运行离线测试套件，从而在发布之前就发现回归问题。对生产环境进行全面埋点：记录输入、输出、延迟、令牌用量、成本和错误，并配合抽样和隐私保护措施。在线跟踪质量信号和用户反馈。这种可观测性让你能够发现退化、控制成本、调试故障，并安全地改进系统：这是生产环境中生成式人工智能的运维基石。

不懈且可观测地管理成本

把人工智能支出归属到具体团队和用例，使成本可见且有人负责。设定预算和告警，监控每次请求和每个结果的成本，并定期审查最大的成本驱动因素。运用你手头的各种杠杆：模型规模适配、缓存、批处理、提示词和上下文精简，以及在满足要求的前提下选择最便宜的部署方式。人工智能成本会随使用量以出人意料的方式扩张，因此持续的成本可观测性对避免不愉快的意外至关重要。

权衡：优点与缺点

决策	选项 A	选项 B	权衡
计算位置	云端	本地部署	弹性和较低的前期成本，相对于控制力、主权和稳态经济性
容量	预留	按需/竞价	可预测的成本，相对于灵活性和中断风险
批量大小	大批量	小批量	吞吐量和成本，相对于延迟
模型规模	大模型	小模型	质量，相对于成本和速度
向量存储	专用数据库	现有数据库的扩展	规模化性能，相对于简单性和更少的系统数量
缓存	积极缓存	最小化缓存	更低的成本和延迟，相对于新鲜度和复杂度

主要的权衡在于成本与延迟、质量之间。批处理、缓存和更小的模型能削减成本，但可能增加延迟或降低质量。正确的平衡点取决于你应用的容忍度。本地部署与云端部署的权衡，是用控制力和稳态经济性换取弹性和较低的承诺，这一决策深受数据主权需求和规模的影响。

与团队讨论的问题

我们今天每个有效结果的成本是多少，哪个杠杆最能改变它？ 原始容量和按请求平均值会掩盖真正重要的数字：交付一个真实价值单位的成本，以及这个成本如何随使用量扩展。对大型团队而言，一个经过优化的部署与一个未经优化的部署之间的支出差距，往往是数倍之多，因此这个问题能把对账单的模糊担忧，转变为一份有优先级排序的修复清单。带上按团队和用例划分的当前成本归属、按请求和按结果的趋势，以及最大的成本驱动因素。按回报大小依次讨论各种杠杆：模型规模适配、缓存（包括前缀缓存和语义缓存）、批处理，以及提示词或上下文精简。在政府场景中，还要加上预测并论证多年期支出合理性的压力。答案应当为每个最大的成本驱动因素指定一个负责人和一个杠杆，而不是耸耸肩了事。
如果我们当前的推理服务商明天把价格翻倍或宕机，我们能多快切换？ 悄无声息的锁定很容易形成，却难以摆脱，而服务技术栈正是它藏得最深的地方。对企业、尤其是政府而言，可移植性是一项采购和业务连续性要求，而不是一件锦上添花的事。带上你的架构：模型是否位于内部接口之后、提示词和评估套件是否具有可移植性，以及你依赖了多少特定服务商专属的服务行为。要关注的信号是：是否有人曾经把你的评估套件运行在第二个服务商或第二个部署目标上。如果切换需要数月并要重写核心路径，就应把这当作一个现在就需要解决的设计缺陷，因为主权部署或本地部署选项可能会在几乎没有提前通知的情况下变成强制要求。
我们现在的加速器利用率是多少，闲置的 GPU 和未批处理的推理正在烧掉多少钱？ 加速器稀缺且昂贵，因此长期闲置和逐个请求提供服务会悄悄耗尽本可用于资助更多能力的预算。对于在各团队间共享 GPU 的大型组织而言，这个问题能揭示调度、配额和优先级究竟是否真正让利用率保持在高位，还是囤积、未被充分利用的硬件才是常态。带上真实的利用率数字、你的批处理和缓存态势，以及你的长尾延迟测量数据，而不只是平均值，因为用户感受到的是那条缓慢的长尾。讨论训练需求和推理需求是否被分开预测（考虑到它们形态不同），以及一个更小的模型或 CPU 推理是否足以应付轻量场景。答案应当指出具体可回收的闲置容量，以及具体可以批处理或路由到规模适配模型的请求。
当一次提示词或模型变更上线时，是什么阻止了悄无声息的质量或成本回归到达用户？ 一套服务技术栈可能在延迟和正常运行时间上看起来很健康，与此同时它返回的答案却在悄悄变差，或者一个新提示词让每次请求的令牌用量翻了一番。对于许多团队各自独立编辑提示词、替换模型的大型团队而言，一次未被把关的变更就是一场蓄势待发的生产事故，而且影响范围会随着共享平台上每多一个团队而扩大。带上你的评估覆盖率：哪些提示词和模型有离线测试套件、这些套件是否在每次变更时自动运行、什么质量和成本阈值会把关一次发布，以及你能多快回滚。讨论提示词是否存放在带评审的源代码控制中，或者是否仍有人能手动编辑一个正在运行中的系统提示词。在企业和政府场景中，要把每一次变更与一条审计轨迹和一位具名审批人绑定，因为当监管者问”是谁改的、你们测试了什么”时，需要的是一个有记录的答案，而不是靠回忆。
我们如何在云端、本地和主权部署之间做出决策，我们核算的是真实的稳态经济性，还是仅仅是试点阶段的费用？ 计算位置的选择会在多年内决定你的成本曲线、数据主权态势和退出选项，然而它却常常是依据一次试点的云账单来做出的，而这份账单与规模化生产环境完全不是一回事。对大型组织而言，弹性的云容量起步便宜，一旦推理持续运行，就可能变成最大的单项开支，而本地部署则是用低承诺换取控制力和稳态经济性。带上预测的训练和推理量、预留或自有硬件优于按需方案的盈亏平衡点、你的数据驻留和安全约束，以及支持混合方案的突发模式。在政府和受监管场景中，要权衡可能几乎没有提前通知就变成强制要求的主权云或本地部署要求，并确认架构让模型保持在内部接口之后，这样一次被迫的迁移就不必重写核心路径。
我们是否真正拥有对人工智能支出的所有权，每个团队能否看到并对自己产生的成本负责？ 人工智能成本会以出人意料的方式随使用量扩展，如果没有归属机制，账单就会以一个不透明的数字落地，没有任何团队会觉得自己有责任去压缩它。在大型组织中，没有人拥有的成本，就是没有人会去优化的成本，因此问题在于：支出是否已经按团队和用例打上标签、配有预算、告警和按结果的趋势，还是只有在财务部门升级问题时才被发现。带上你的成本归属模型、按团队划分的最大驱动因素，以及每位负责人所掌控的杠杆：规模适配、缓存、批处理和上下文精简。对企业和政府预算而言，还要加上预测并论证多年期基础设施支出合理性的纪律，因为一个无法逐项解释其计算账单的公共机构，在审查中将很难为其辩护。

行业视角

创业公司。 能不拥有的基础设施就不要拥有。调用一个托管的推理 API，把简单请求路由到一个小而便宜的模型，把更大的模型留给困难场景，并积极缓存，让重复出现的提示词不产生任何成本。使用托管向量数据库，而不是自行运维一个；把提示词存放在 git 中，在每次变更前运行一个简短的评估脚本；并记录每次请求的成本，使账单失控在造成伤害之前就能被发现。你最稀缺的资源是工程注意力，因此要为可运维性买单，并保持切换成本低廉。

小型企业。 由于没有平台团队，要把服务、检索和可观测性当作在你已经使用的工具内购买的东西，而不是需要自己配备人手维护的系统。偏好定价透明、可预测的托管推理和托管向量搜索，并从第一天起就设定硬性支出上限和账单告警。诚实地把这个决策框定为自建与购买之争：在你的用量水平上，运维 GPU 或向量索引很少能带来回报，一个位于托管 API 之后的小模型通常能以极小的努力满足需求。

企业。 问题在于跨众多团队的共享铺装式平台：汇集的加速器配有调度器、配额和优先级以提高利用率，标准化的批处理和缓存，规模适配路由器，以及归属到每个团队和用例的成本。用自动化评估套件为提示词和模型变更把关，把接口层标准化，使服务商和部署目标始终可替换，并把每个结果的成本当作一等指标来管理，而不是让每个团队各自重新发明代价高昂、利用不足的基础设施。

政府。 数据主权、安全性和可预测支出塑造着每一项选择。偏好本地部署或主权云部署，使敏感数据和模型保留在受控边界之内，用你能在采购中论证合理性的配额在各部门间调度稀缺的 GPU，并预测容量以逐项论证多年期支出。用有记录的审计轨迹为提示词和模型设置版本并进行评估，对成本和质量保持全面的可观测性，并让模型保持在内部接口之后，这样一次被迫迁移到新服务商或主权平台的过程就不会让你陷入困境。

示例

创业公司。 一家运行人工智能写作功能的小型创业公司，在不拥有任何 GPU 的情况下让账单保持在合理范围内。它调用了一个托管的推理 API，把简单请求路由到一个更便宜的小模型，把更大的模型留给困难场景，并缓存了重复出现提示词的答案。它把提示词存放在 git 中，配有一个在每次变更前运行的简短评估脚本，为检索使用了托管向量数据库，因此不必自己运维一个，并记录了每次请求的成本，使创始人能在支出攀升变成意外之前就看到它。

企业。 一家运行高流量大语言模型功能的媒体公司，大幅削减了推理成本。它把简单请求路由到一个小模型，把更大的模型留给困难场景。它缓存了重复查询的响应，并为其共享的系统提示词启用了前缀缓存。它通过一个共享调度器运行 GPU 以保持高利用率，用 git 为所有提示词设置版本，并配有自动化评估套件为变更把关，还为每次请求的成本进行了埋点，使每个产品团队都能对自己的支出负责。

政府。 一个有着严格数据主权规则的国家级机构，把其人工智能系统部署在本地，使敏感数据和模型永远不离开其受控环境。它用配额和优先级在各部门间调度稀缺的 GPU，预测容量以论证多年期采购的合理性，并构建了一个用于检索官方文档的向量搜索平台。提示词和模型在发布前都经过版本管理和评估。全面的可观测性跟踪着成本和质量，架构也让模型保持在内部接口之后，以保留退出路径并避免锁定。

商业论证：动机、投资回报率与总拥有成本

对有纪律的人工智能基础设施进行投入的动机是直接的。规模化运行的人工智能成本高昂，一个经过优化的部署与一个未经优化的部署之间的支出差距，往往是数倍之多。投资回报来自更高的加速器利用率、通过批处理和缓存降低的每次请求成本、规模适配的模型，以及避免过度配置。可观测性和评估流水线的回报体现在防止代价高昂的事故、并支持安全的迭代改进。

总拥有成本涵盖加速器计算（对许多工作负载而言是最大的一项开支）、向量存储、服务基础设施、网络，以及运行这一切所需的平台和运维人员。要将其与不投资的成本相权衡：失控攀升的推理账单、拖累采纳的糟糕延迟，以及无法扩展的困境。对政府而言，还要加上未能满足主权或安全要求的代价。要向领导层论证这一点，就展示每个结果的成本趋势，以及一个能让众多团队高效部署人工智能的铺装式平台，而不是让每个团队各自构建代价高昂、利用不足的基础设施。

反模式与陷阱

闲置的加速器。 把稀缺的 GPU 分配给让它们利用不足的团队。
没有批处理或缓存。 逐个请求单独提供服务，重复计算共享的上下文。
默认使用最大的模型。 在一个小模型就足够的地方使用昂贵的模型。
对成本视而不见。 直到账单到来才有归属、预算或按请求成本可见性。
未设版本的提示词。 在生产环境中修改提示词，没有版本管理或评估把关。
忽视长尾延迟。 优化平均延迟，却让用户承受缓慢的长尾。
悄无声息的锁定。 深度依赖单一服务商的服务技术栈，没有可移植性。

成熟度模型

启动（Initiate）。 GPU 分配是临时的，谁声音最大就响应谁；没有批处理或缓存；直到账单到来才有成本可见性；提示词在生产环境中被现场编辑且不设版本；监控极少。
发展（Develop）。 一些团队采用了共享调度、缓存和版本受控的提示词，但整个组织的实践并不一致：一个团队做批处理和评估，另一个团队仍在逐个请求提供服务、手动修改提示词。
标准化（Standardize）。 一个有文档记录的铺装式平台在全组织范围内被强制执行：带配额和优先级的共享调度、标准化的批处理、缓存和规模适配，用于检索的向量基础设施，为每一次提示词或模型变更把关的自动化评估流水线，以及归属到团队和用例的成本。
管理（Manage）。 平台被度量并对照基线加以控制：加速器利用率、每个有效结果的成本、长尾延迟、检索召回率以及每次变更的质量回归，都配有告警和阈值加以跟踪，成本由每个团队负责，一次变更是否上线依据证据而非直觉来决定。
编排（Orchestrate）。 基础设施持续改进并自我适应：路由、批处理和扩缩容根据实时的成本和质量信号自我调优，容量随需求和约束的变化在各团队之间、以及在云端、本地和主权部署目标之间重新平衡，可移植性会被定期演练，基础设施规划与产品、安全和采购相融合。

讨论思路

你如何在不使优先级工作负载挨饿的情况下提高加速器利用率？
对你的延迟要求而言，正确的批处理与缓存平衡点在哪里？
本地部署或主权部署在什么时候能证明其成本相对于云端是合理的？
你如何在众多团队之间归属和控制人工智能支出？
什么应当在一次提示词或模型变更到达生产环境之前把关？
你如何保持服务基础设施足够可移植，以便切换服务商？

关键要点

加速器稀缺且昂贵；要有意识地调度、共享和利用它们。
批处理、缓存和模型规模适配，是控制成本和延迟的主要杠杆。
检索型应用需要运维良好的嵌入和向量搜索基础设施。
LLMOps（提示词版本管理、评估流水线和可观测性）是生成式人工智能的运维基石。
可观测地管理成本，并保持可移植性以避免锁定。

参考文献与延伸阅读

Chip Huyen, Designing Machine Learning Systems.
Google, Site Reliability Engineering（Beyer, Jones, Petoff, Murphy 编）。
Jared Kaplan et al., Scaling Laws for Neural Language Models.
Reza Yazdani Aminabadi et al., DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale.
Woosuk Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention（vLLM）。
Andriy Burkov, Machine Learning Engineering.