大模型的兴起给基础设施团队带来了一系列全新的挑战。传统的 Web 服务是 CPU 密集型的，资源调度的粒度是”核数”和”内存”。但模型推理服务是 GPU 密集型的，资源调度的粒度变成了”显存”和”算力卡”，调度策略、弹性伸缩、故障恢复的逻辑都需要重新设计。
更深层的变化是流量模式。传统服务的请求是毫秒级响应，模型推理的请求可能是秒级甚至分钟级。这意味着负载均衡、超时控制、熔断策略都不能照搬原来的经验。长连接、流式响应、推测解码——这些新模式对基础设施的每一层都提出了适配需求。
把一个训练好的模型变成一个可靠的在线服务，中间的工程链路远比想象中复杂。模型版本管理、权重文件的分发和缓存、多模型的资源隔离、推理引擎的选型和优化——每一个环节都需要基础设施团队的深度参与。
我们在实践中发现，模型服务化最大的难点不是”让模型跑起来”，而是”让模型稳定地跑在生产环境里”。显存泄漏、推理延迟毛刺、CUDA 版本兼容性、多卡推理的负载不均——这些问题在实验室环境中往往不会暴露，只有在生产流量下才会浮现。
平台工程师的下一个十年，核心能力将从”提供工具和平台”转向”提供智能体运行的基座”。这意味着我们需要理解大模型的运行原理、推理框架的架构、GPU 集群的调度策略，同时保持对传统基础设施的深度掌控。
这不是一次简单的技能拓展，而是思维模式的转变。以前我们服务的”用户”是人类工程师，设计的抽象围绕着人的认知习惯。未来我们同时服务人类和 AI Agent，API 的设计需要兼顾两种消费者的需求。平台工程师的核心竞争力将在于：能否搭建一个让人类和 AI 都能高效协作的基础设施。