如何在Kubernetes环境中诊断并解决AI推理过程中的延迟问题

现在是星期四，大约两点二十分。两周前，你们的团队推出了一款内部辅助工具。测试效果还不错，以至于财务部门的某个人询问这种工具是否能够阅读合同文件。消息很快传开了，今天，所有人第一次同时使用这款工具。

支持渠道收到了同样的投诉，但这些投诉是以六种不同的方式表达的。是系统出现故障了吗？我的设备只是一直在循环加载中……今天早上它还能正常工作啊。有人发了一张显示加载指示器的截图，但没有附上任何说明文字，看来他们觉得这样挺有意思的。

于是你打开了控制面板。

所有节点都已准备就绪，容器也在运行中，CPU使用率仅为20%。没有发生重启现象，也没有进入崩溃循环状态，也没有任何警报被触发。根据Kubernetes提供的所有信息来看，系统应该是正常的。

但实际上系统并不正常。有人已经等待了十一秒钟，却仍然没有得到任何回复；他们正准备重新回到原来的工作方式去，而且可能再也不会改回来用了。

这就是这篇文章所要讨论的问题——这种隐性的故障，也就是那些技术上看起来一切正常，但产品实际上仍然无法使用的状况。

你的第一直觉是错误的
你并不是唯一一个遇到这种问题的人
在部署系统时，没有人告诉你的那些事情
那十一秒钟去哪儿了
与此同时，平台本身也在不断发展变化中
这一切究竟是怎么发生的
等“火”终于熄灭后，该怎么做
你的监控系统仍然没有告诉你的一些事情
那些仍未得到解决的问题
星期一早晨
回到星期四的话题

你的第一直觉往往是错误的

在那种情况下，人们的第一反应往往会怀疑是模型本身出了问题——可能是版本有误、量化处理不当、上下文信息过长，又或者是有人修改了系统的提示语句。但实际上，几乎从来都不是模型的问题。

如果你仔细观察整个请求的处理流程，会发现它实际上分为四个阶段：首先，请求会被路由到一个副本系统；然后进入队列等待处理；接着模型会读取提示语句并生成答案；最后才会将答案发送出去。其中只有后两个阶段真正涉及到模型在执行你为之付费的功能，而前两个阶段主要是负责请求的排队和路由工作，这些都属于基础设施层面的操作。

当人们说他们的模型运行速度慢时，其实模型本身往往并没有问题，问题通常出在其他地方。

你并不是唯一有这种困扰的人

在开始解决问题之前，你需要知道：这是这个领域中最常见的抱怨，而不是你的配置出了什么问题。

一项针对200位在实际环境中使用AI技术的人员进行的调查发现，近一半的人（49.5%）认为，在高峰负载情况下，延迟问题是他们面临的最大挑战。这个问题与模型的准确性、产生的错误结果或成本无关，而是发生在人们真正试图使用这些系统的时候。

同一项研究还提供了另外两个值得注意的数据：59.5%的受访者表示，将推理过程部署在更接近用户或决策点的位置非常重要；而45.5%的人仍然选择从同一个云区域提供服务。这说明人们确实意识到了距离的重要性，但却没有采取相应的措施来改善这一情况，这也从侧面反映了搭建多地区GPU基础设施所需的成本有多高。

这项研究还提到，一些组织要求系统的响应时间必须低于250毫秒，并且系统的可用性必须达到99.9%。不过仔细想想，这个要求实际上是不可能实现的。没有任何一款大型语言模型能够在四分之一秒内完成响应；这里所说的“响应时间”应该是指从接收到请求到系统开始生成答案的第一个词所需的时间，而这个标准本身也是合理的。一旦系统的响应速度达到了可以让人接受的水平，人们就不会再去关注响应时间了——因为在那之前出现的漫长的等待时间才是真正令人困扰的地方。

在部署系统时，没人会告诉你这些事情

接下来要讲的内容，能够解释前面提到的所有问题。

普通的Web请求通常处理时间较短，消耗的资源也较少，其成本大致与之前的请求相当。Kubernetes的调度系统、服务负载均衡机制、水平Pod自动扩展器，以及你的入口控制器默认设置的超时时间，都是基于这个假设来设计的。因为在过去的十五年里，这一假设一直都是正确的。

然而，大型语言模型的请求处理过程在三个环节打破了这一常规。

首先，模型会分两个阶段进行处理：在第一阶段，模型会一次性读取全部的提示语句，这个阶段对计算资源的消耗较大，且处理过程具有突发性，这就是为什么用户会感到等待时间较长的原因；在第二阶段，模型会逐个生成答案中的单词，而每个单词的生成都需要依赖于之前所有单词的处理结果。这些处理结果实际上存储在KV缓存中，而这些缓存数据则保存在GPU内存中，随着答案内容的增加，缓存的大小也会随之增长。

因此，这些请求的处理时间可能会长达一分钟。它们的成本也各不相同：那些需要加载大量数据的请求，其成本可能是一般请求的五十倍。而真正稀缺的资源是GPU内存，在你继承的任何监控面板中，都看不到与GPU内存相关的信息。

这就是为什么你的监控系统显示一切正常的原因——它实际上是在测量错误的机器。

那十秒钟去哪了

如果追踪这些请求在四个不同阶段中的处理过程，就能依次找出导致故障的原因。这六种故障类型是从业者们最常提到的，它们与整个请求处理流程密切相关。

第一阶段：路由选择：你的负载均衡器其实是在随机分配请求

一旦请求的处理成本开始出现差异，轮询调度方式就不再公平了。三个耗时较多的请求会被分配到同一个节点上，而另一个节点则只负责处理简单的请求。这样一来，那个负担过重的节点的队列会越来越长，其响应延迟也会增加，但整体系统的平均性能看起来仍然正常，因此之前没有人注意到这个问题。

长期存在的连接情况会使问题更加严重。使用HTTP/2或保持连接机制时，客户端会建立一条连接来发送所有数据，而Kubernetes服务则是按照每条连接而不是每个请求来分配处理资源的。这样一来，所有的流量都会集中在同一个后端服务器上，导致其负担过重。

还有另一个大多数团队从未考虑过的成本因素：如果某个副本节点的KV缓存中已经存储了该请求所需的数据前缀，那么直接将请求路由到这个节点就可以省去预处理的工作。由于大多数生产环境中的请求都需要加载大量的系统数据，这种情况其实非常普遍，因此轮询调度方式会白白浪费这些优化机会。

第二阶段：队列等待：没有任何措施能够缓解这个问题

你的自动扩展机制确实可以增加处理能力，但这样做会延迟响应时间，而且原因并不复杂：新的副本节点需要下载数吉字节的镜像文件，从网络中获取20GB到70GB的数据，并将其加载到GPU内存中。这个过程至少需要几分钟的时间，而不是几秒钟。当然，这还是假设系统中已经有可用的节点可用的话。如果没有这样的节点，那么还需要额外的时间来进行资源分配，同时还要考虑你的服务提供商在该地区是否还有库存。

还有一个更严重的问题：当前的监控指标往往无法准确反映实际情况。CPU利用率在这里毫无参考价值，因为当GPU正在工作时，CPU其实是处于空闲状态的；GPU利用率的数值也不太可靠，因为它只能显示在采样期间是否有内核程序在运行，而无论处理一个请求还是六十个请求，GPU的利用率都可能显示为100%。因此，这些指标无法帮助我们判断是否有请求正在等待处理。

不过，队列长度这个指标可以提供有用的信息。vLLM已经将正在处理和处于等待状态的请求数量作为Prometheus监控指标提供了出来，你可以根据这些指标来进行调整：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: llm-server
spec:
  scaleTargetRef:
    name: llm-server
  minReplicaCount: 2
  maxReplicaCount: 8
  cooldownPeriod: 600
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring:9090
        query: sum(vllm:num_requests_waiting{app="llm-server"})
        threshold: "5"

请检查这些指标名称是否与您所使用的vLLM版本相匹配。在不同的版本更新中，有些指标的名称已经发生了变化，而这种变化并不会引发任何错误提示。

其中有两个设置是经过慎重考虑后确定的。最低需求设置为2个资源单元，是因为如果从零开始启动系统，那么根本无法正常提供服务；而10分钟的冷却时间也是为了防止过于急切地缩减资源规模，否则很快又会面临再次从零开始的困境。

这些设定让我们不得不得出一个关于自动扩展功能的结论：无论冷启动所需的时间有多长，反应式的扩展机制总会导致延迟，而且没有任何触发条件能够解决这个问题。因此，正确的解决办法就是保留比实际需要更多的备用资源——始终运行额外的副本节点，在认为还不需要扩展时就提前进行扩展，而在需要缩减规模时也要更加谨慎。

第三阶段：GPU资源已准备就绪，但实际却无法被有效利用

Kubernetes分配CPU资源时是以毫核为单位，而GPU则是以整块设备的形式提供的。当一个Pod申请使用一块GPU时，它实际上会获得整块GPU，无论它真正需要使用其中10%还是全部资源。

这种资源浪费显然是一个严重的问题，但更糟糕的是资源分配的不均匀性——例如，对于一个需要16位运算的70B模型来说，大约需要140GB的模型参数存储空间，因此一个副本节点就需要配备多块GPU。即使你有四块闲置的GPU，分别分布在四个节点上，那个副本节点也可能永远处于“待分配”状态。从纸面上看，这些资源看似可用，但实际上根本无法被利用，也不会有任何警报提示，因为系统并没有出现任何故障。

当多个Pod共享一块GPU时，有三种使用方式，但每种方式都存在一定的局限性，在选择之前必须了解这些限制。时间切片这种方式虽然易于实现，但却不能提供内存隔离功能，因此一个占用了大量资源的Pod很可能会影响其他节点的正常运行。MIG技术虽然能够实现真正的硬件隔离，但是切片尺寸是固定的，这意味着你必须在实际确定工作负载构成之前就提前规划资源分配方案。而动态资源分配机制才是从根本上解决问题的方法，它能够将加速器的资源请求纳入Kubernetes的核心API体系中进行处理。

这些功能在默认情况下都是处于关闭状态的。每一种功能的启用都需要由那些真正了解具体工作负载需求的人来决定，而这些人在集群建设阶段通常并不在场。

第四阶段：你的Ingress配置正在导致服务中断

许多Ingress控制器在默认情况下都会设置60秒的读取超时时间，并且会启用响应缓冲功能。

这种超时设置会导致一些长耗时的操作在还没有完成时就被终止。用户会误以为这是系统崩溃了，但实际上你无法重现这种问题，因为你的测试用例通常比较简短。而响应缓冲机制则会将大量的请求数据暂时存储起来，然后一次性发送出去，这种处理方式破坏了流式处理的体验，尽管模型的运行本身并没有出现问题。

这些配置设置其实是为那些已经不存在的工作负载场景设计的。

归根结底：问题根源在于突发性的高流量，但却没有人真正去追究这个问题背后的原因

内部使用的AI工具并不会持续获得稳定的流量。它们的使用量会突然出现激增：比如当所有人都在早上9点开始工作时，或者在公司召开全员会议后的一个小时里，又或者当有人在繁忙的Slack频道中分享某个链接，并评价说这个链接确实非常有用时，使用量就会骤然增加。而那些被设置为固定值的复制数量设置，实际上只能应对其中的一种情况而已。大多数团队会在一个工作较为平静的周内设置一次这些数值，之后就再也不会去调整它们了，因此结果就是既会造成资源浪费，也会在某一天导致系统崩溃。

第六种故障模式完全与技术无关，但正是这种原因导致其他五种故障模式能够在几个季度内持续存在。

平台工程团队负责管理这些集群。从他们的角度来看，各项工作都进行得很顺利。但是应用程序开发人员会发现延迟现象很严重，却无法理解其中的原因，因为所有导致延迟的因素都与调度、扩展和路由机制有关，而这些机制既不在他们的控制范围内，也无法被他们观察到。而机器学习运维团队虽然负责管理模型相关资源，但却几乎无法影响模型在周四下午两点半时的运行表现。

有三个团队都在说实话，但问题就出在他们各自的值班安排之间——没有设置任何警报机制，也没有任何监控指标来反映问题的存在。

与此同时，平台本身也在不断发展之中

值得欣慰的是，上述这些问题已经被人们意识到了，相应的解决方案也已经在逐步被应用当中。

动态资源分配功能将加速器硬件的相关请求纳入Kubernetes的核心API中，这样调度系统就能根据这些设备的实际状况来做出决策，而不再只是简单地计算一些晦涩难懂的数值。Kueue功能则增加了作业队列管理以及多租户共享GPU配额的功能，同时还会考虑CPU和内存的使用情况，这样就可以避免某些研究任务占用过多资源，从而影响用户正常使用系统。Gateway API Inference Extension与llm-d技术则为路由机制添加了模型感知功能：根据请求的紧急程度进行动态调度，利用实时模型数据来平衡负载，并且还能了解缓存的状态。最后这一项技术正是对第一阶段中那种基于猜测来进行负载均衡的方法的一种直接改进。

已发布的测试结果展示了这些技术的实际效果：Kueue功能可以将多阶段作业的完成时间缩短15%，动态加速器分配机制可以将平均作业完成时间减少36%，而在高负载环境下，Gateway API与llm-d技术的组合可以将“从请求发出到得到响应的最长时间”缩短90%。

将这些数据看作是系统改进的空间而非未来的预测结果吧。之所以能取得90%的改善效果，是因为测试所使用的配置正是为了突出这种改进效果而特意选择的；而你实际能够获得的收益，完全取决于你的基准情况有多差。如果你已经采用了“优先处理未完成请求”的调度策略，并且使用了缓存机制，那么实际提升幅度可能会小很多。但如果你仍然使用默认的轮询调度方式，那么提升幅度可能会非常显著，因为那时的基准情况确实很糟糕。

方向才是最重要的。目前已公布的各项改进成果中，“从请求发出到得到响应的最长时间”这一指标的改善最为明显，而恰恰也有半数受访的专业人士将这个问题视为他们面临的最大难题。有人针对人们所抱怨的问题，真正开发出了有效的解决方案。

这一切最初是如何发展起来的

这个过程值得简要了解一下，因为它能解释为什么相关工具会延迟推出。

当生成式人工智能开始被纳入企业规划方案中时，人们普遍认为Kubernetes无法满足这种需求。因为容器编排技术本来就是为处理那些规模小、可替换性强的CPU和内存资源而设计的，它支持快速重启和复制操作。然而人工智能需要专门的硬件来运行，这些硬件需要存储大量的数据，而且部署起来也需要花费很长时间。因此，人们原本认为需要专门为人工智能开发一个全新的平台。

但实际上，这个新的平台从未真正出现。人工智能技术被直接整合到了微服务架构中，而Kubernetes也成功吸收了这些技术。

调查数据解释了其中的原因。超过一半的企业根本不会训练模型，而只有7%的企业会在任何一天实际部署模型。与此同时，82%的容器用户在生产环境中使用Kubernetes，66%提供生成式AI服务的组织也在生产环境中运行这些技术。整个行业花费了大量时间来设计那些几乎没有人真正需要的工作负载处理方案，而其他企业则只是简单地下载模型权重文件，然后将它们部署到后端服务器中而已。

实际上，真正发生变化的是运行AI模型的方式，而不是运行AI模型的具体环境。现在人们已经找到了一种标准的运行方式，而具体的运行地点则可以灵活选择。正因为如此，如今人们面临的问题主要是关于模型部署的位置、数据传输路径以及系统容量，而非与模型本身相关的问题。

火势扑灭后该怎么做

要从不可靠的状态转变为可靠的状态，关键在于五个方面：系统容量、性能、部署位置、弹性以及责任归属。

系统容量

如果某个请求需要50个令牌，而另一个请求只需要8,000个令牌，那么“每秒请求数量”这个指标就没有任何实际意义了。应该按照“每秒所需令牌数量”来制定计划，并分别跟踪请求的发起时间和响应完成时间，因为这两者会对系统的不同部分造成不同的压力。请求发起时所需的令牌数量代表着预处理阶段的计算负荷，而响应完成时所需的令牌数量则代表着解码阶段对GPU内存的持续占用时间。

应该使用最糟糕的情况下可能出现的最大并发数和最复杂的请求内容来进行负载测试，并根据这些数据来制定计划。如果基于简单的请求内容进行基准测试，得到的结果可能会在短短一周内就变得不再准确了。

在资源供应方面，应该将GPU视为需要提前预留的资源，而不是在需要时才去申请。要确定一个固定的基础使用量，然后在必要时再额外增加用量。在需要的前一天晚上，就要了解你的供应商的配额以及该地区GPU的库存情况，并使用Kueue机制来确保没有某个团队会单独占用所有资源。

性能

有两个指标最为重要：第一个令牌到达的时间（TTFT）决定了用户从发送请求到看到答案的第一句话需要等待多长时间，这个时间直接影响用户对产品的信任度；而令牌之间的响应延迟则决定了答案是否读起来流畅。

应该分别关注95%和99%的请求情况下的这两个指标，而不是平均值。这些百分比代表的是数据分布的情况：95%的请求会在这个时间范围内完成处理，因此这个指标反映了速度最慢的20%用户的体验；99%的指标则反映了速度最慢的100%用户的体验。平均值可能看起来很正常，但实际上那些速度较慢的用户可能需要等待很长时间，而他们往往就会放弃使用该产品。

接下来，需要调整服务层的相关设置。服务层是指负责加载模型和处理请求的软件，比如vLLM这样的工具。通过优化服务层，你可以以最少的投入获得最大的性能提升。连续批处理技术可以让GPU保持忙碌状态，避免过早提交的请求因为等待批次处理完成而被阻塞。在质量可以接受的情况下，对模型进行量化处理可以将内存占用量减少大约一半，这样就可以为更多的并发请求腾出资源。同时，应该根据产品的实际需求来设置最大上下文长度，而不是仅仅依据模型所能支持的最大长度来设定。如果模型能够处理128K长度的输入信息，而你最长的真实请求内容只有6K长度，那么为这种根本不会发生的场景预留大量缓存资源就是浪费资源。只需修改一条配置参数，就可以显著提高系统的并发处理能力。

部署策略

需要对某些GPU节点进行特殊处理，以确保普通工作负载无法在这些节点上运行，只有那些容忍度设置相匹配的推理任务才会被调度到这些节点上。日志记录系统绝不应该成为导致模型副本无法成功部署的原因。

尽量保持各个模型的权重值接近。通过使用节点本地的NVMe存储或区域级缓存，可以将原本需要通过40GB网络传输的数据快速读取到本地，从而有效解决模型启动速度慢、自动扩展功能延迟以及高峰时段性能下降的问题。这是这份清单中效果最为显著但可能不太引人注目的解决方案。

必须遵循正确的拓扑结构进行部署。通过NVLink连接的GPU与那些仅通过PCIe总线相连的GPU在性能上存在显著差异，而对于那些采用分片架构的模型来说，这些连接方式会直接影响每个数据包的处理流程。

此外，还要充分考虑地理位置因素。如果你的用户位于伦敦，而你的GPU却安装在弗吉尼亚州，那么所有数据包在传输过程中都需要跨越大洋，因此即使模型本身设计得很好，但如果网络传输路径过长，其性能仍然会受到影响。

弹性与容错性

只有当模型真正加载完成并且能够正常提供服务时，才能认为系统处于可用状态。在使用启动检测工具时，应该设置一个较高的故障容忍阈值；否则，在模型权重数据正在加载的过程中如果系统检测到异常，就会导致重启循环，这种问题既难以诊断，也会浪费大量时间。

需要为节点升级设置相应的限制机制，以确保常规的升级操作不会一次性导致一半的模型副本无法正常运行。

应将节点的终止缓冲时间设置为超过默认的30秒，并添加预终止处理逻辑。因为一个模型的训练过程通常会持续更长时间，所以如果不采取这些措施，每次升级都会中断正在运行的任务流程，从而导致用户遇到系统故障的问题。

要有意识地调整负载分配。当队列长度超过预设阈值时，应该立即返回错误信息并提示用户重新尝试，而不是让请求在系统中挂起两分钟才得到处理。对于工程师来说，这种做法可能显得有些繁琐，但对于用户而言却能显著提升体验——人们更容易接受快速而诚实的重试机制，而无法忍受系统长时间无响应的情况。

必须准备好备用方案：比如使用另一个区域的数据中心、开发一个适用于常见情况的简化模型，或者在遇到严重故障时启用外部API。由于有45.5%的从业者仅使用单个区域进行部署，因此这个措施往往是大家最容易忽略的，但恰恰也是最有可能导致问题发生的环节。

责任划分与沟通

必须就各项关键指标达成一致，并将它们明确记录下来：从模型开始加载到第一个数据包生成所需的时间、数据包之间的传输延迟、错误率以及请求在队列中的等待时间。将这些数据展示在同一张仪表板上，让两个团队都能看到相同的信息，从而避免出现对实际情况理解不同的情况。

要明确划分双方的责任范围：平台负责确保系统具备达到目标所需的各项能力，包括容量管理、调度安排、路由选择、扩展机制以及部署策略等；而应用程序则负责配置模型的具体参数并控制其运行流程，比如上下文长度、批量处理参数、提示信息的大小以及重试策略等。当实际数据与预期值出现偏差时，双方都可以根据这些明确的指标来进行分析和讨论，而不是基于不同的数据来源产生分歧。

你的监控系统仍然无法告诉你的四件事

延迟、流量、错误率以及系统饱和度这些指标虽然仍然重要，但已经不再足以全面反映系统的性能状况。还需要另外加入四项指标来进行评估。

令牌消耗速率、提示语的分割方式以及任务完成情况，因为这些才是真正能够体现系统处理能力的指标；按租户和查询类型划分的每请求成本也很重要，因为我们使用了八块GPU，但这并不能说明某个功能对每个用户来说到底需要多少成本；输出质量、幻觉现象的出现频率以及系统的稳定性也是必须考虑的因素，因为那些会降低质量的延迟问题显然不是我们想要的结果；此外，还需要记录是哪个检查点以及哪个版本的提示语产生了相应的响应结果，因为当质量发生变化时，我们需要知道到底是哪些因素导致了这种变化。

最后这一点与一个值得注意的趋势有关：模型注册系统已经与容器注册系统处于同等重要的地位了，而提示语和代理配置也越来越像其他代码一样，被纳入GitOps流程中进行版本控制和管理。

如今，提示语本身就已经成为了代码。它们会改变系统的实际运行行为，甚至可能导致系统出现故障，因此应该像其他代码一样经过审查、版本控制以及回滚操作。很多团队至今仍在通过Web控制台来编辑提示语，却不知道为什么某个周二系统的质量会突然下降。

尚未解决的问题

基础技术层面已经趋于统一，这一事实本身就是最好的证明。2025年底，Kubernetes推出了一个AI合规性检测项目，最初只有18个平台参与其中；大约四个月后，这个项目的参与平台数量增加到了31个，并且应用范围也扩展到了代理相关工作负载上，涵盖了主要的超大规模云服务提供商、企业级云平台、私有云解决方案以及边缘计算网络。那些在其他很多方面都无法达成共识的公司，在这一点上却达成了统一。

然而，在上层技术层面，各种技术和标准却远未实现统一。AI网关、评估平台、代理控制机制以及代理的可观测性功能，在商业产品中的发展速度远远快于任何标准化组织制定的标准，而且这些技术正好处于那些能够带来实际业务价值的关键领域。

这个风险值得我们明确指出来：在Kubernetes这一层面上，你的系统可能是完全可移植的；但在实际开发运行的层面，你可能会遇到各种限制。你的Pod可以在不同的云平台上顺利迁移，但你的代理定义、评估脚本以及网关配置却会固定在一个地方，因为根本没有任何标准化的机制可以让它们被转移到其他地方去。

但这并不是拒绝使用这些工具的理由。今天，这些工具确实能够解决一些实际问题。相反，我们应该明确知道自己的哪些组件是可以进行标准化管理的，哪些则不能，并且应该提前做出这样的决策，而不是在续签合同的时候才去发现这些问题。

周一早晨

首先从一项测量开始吧：记录一次从创建Pod到首次提供令牌这一整个过程所需的时间，并把这个数字记下来。这个数值就是你的自动扩展下限，而最低副本数量也可以根据这个数值来计算得出。

在主仪表板上，将“首次提供令牌所需时间”和“队列深度”这两个指标放在p99分位点进行展示。用基于队列深度的触发机制来替代基于CPU的自动扩展机制，并设置符合实际运行情况的最小值；同时检查系统的入站请求读取超时时间和缓冲机制，确保它们能够在面对较长延迟的流式响应时正常工作，而不仅仅是针对测试提示语进行的测试；最后调整系统的终止宽限期，确保部署过程不会给用户带来不便。

在接下来的几周里，你需要做以下几件事：污染你的GPU节点，将权重数据转移到节点本地的存储空间中，将最大上下文长度设置为你实际使用的数值，并确认你是否仍然处于轮询调度模式下。很可能你仍然是这样的。

在季度结束之前，要明确谁应该对端到端的延迟指标负责，并且要在有其他团队成员在场的情况下当众说明这一点。

回到周四的话题

那个仪表盘从来都没有撒谎，但它回答的其实是另一个问题。

它只是告诉你那些容器是否处于运行状态——而它们确实是在运行的。但它无法告诉你：有些请求因为路由错误而被滞留在队列中；有四分钟的时间没有新的副本被生成；有六块GPU虽然空闲但无法被使用；或者入口端正在缓冲本应被立即传输的数据。标准工具包中没有任何功能能够用来检测这些情况。

在Kubernetes平台上让一个模型开始运行只需要一个下午的时间，但要确保所有人同时登录时该模型都能正常工作，这就需要另外一套复杂的解决方案了。这其实更像是一项普通的基础设施工程任务，而不是我们目前讨论的内容所暗示的那样。调度、路由、容量分配以及责任归属这些问题，我们在人工智能概念出现之前就已经在着手解决了。这些技能本来就存在于我们的能力范围内，只是需要将它们应用于正确的场景中而已。

一个处于正常运行状态的集群才是我们开始工作的基础。真正重要的是那些输入指令的人所看到的结果。

希望你喜欢这篇文章，并从中学到了一些新的知识。我随时欢迎你在LinkedIn上提出建议或进行讨论，也可以直接给我发私信。

如果你喜欢我的写作内容，并且希望激励我继续创作下去，欢迎在GitHub上给我打星评价，也可以在LinkedIn上为我推荐相关的技能。

下次再见，祝大家探索愉快！