2026年的KubeCon Europe现场openFuyao的展台前面排队的人比我想象中多。按理说AI推理这种偏底层的项目很难像大模型Demo一样吸引路人但InferNex套件在现场演示的GPU利用率和显存调度曲线确实让人眼前一亮同一个集群并发跑6个不同规模的模型显存碎片和调度等待时间被压得很低GPU利用率稳定在80%以上。这篇文章就以InferNex为例聊聊AI云原生推理这个赛道里最值得关注的几个技术方向以及如果你想把这套架构搬回自己集群应该从哪几步开始过程中又会踩到哪些坑。1. AI云原生推理为什么值得围绕一个套件深耕1.1 从“能跑”到“跑得好”推理生产化的三个核心诉求过去大家聊AI推理核心话题基本集中在一个点上模型能不能在GPU上跑起来。部署一个7B模型能起服务接口能通项目就算结束了。可一旦进入生产环境事情远没有这么简单。我见过一个非常典型的场景团队花重金买了几台8卡A100的服务器结果上线之后发现GPU平均利用率不到20%。原因是各团队各跑各的模型每个模型独占一整张卡显存用一半算力用三分之一剩下的资源全部浪费。更麻烦的是新模型要上线的时候集群里明明有闲置显存调度器却因为“一个Pod只能绑一张完整GPU”而拒绝放置。这种感觉就像住着一套大房子却因为每个房间只允许住一个人导致客厅厨房全闲着来了客人却无处可去。这就是从“把模型跑起来”到“把推理服务做好”之间最根本的差距。围绕AI云原生推理做的所有基础设施工作本质上都在解决三件事。资源要能切、能共享、能回收。GPU不能继续当成只能整卡分配的“大宝贝”要做显存虚拟化和算力调度让多个推理任务安全地共享同一张物理卡。流量要能伸缩、能归零、能恢复。推理服务的流量特点非常明显活动时段冲高凌晨基本归零。如果始终跑着一堆固定副本成本支出几乎全是浪费。模型要能托管、能灰度、能复用。生产上不可能只有一个模型。模型版本管理、灰度发布、流量切分、多租户隔离这些能力在大规模集群里一个都不能少。InferNex本质上就是围绕这三个需求做的套件设计从集群调度、推理引擎到服务治理每一层都有对应的组件。理解了这个定位后面看它的架构和操作方式就不会觉得零散。1.2 谁是这套基础设施的核心用户这里要先澄清一个容易混淆的问题InferNex这类套件到底是给谁用的我的判断是它的直接用户有两个群体。第一个是平台工程师他们主管Kubernetes集群需要通过统一方式接入GPU资源、管理推理服务的全生命周期。第二个是算法工程师他们不关心底层Pod怎么调度、Service怎么暴露只希望把自己训练的模型一键发布成稳定接口。InferNex在KubeCon Europe 2026上的展示很明显是同时照顾了这两类人的。对平台工程师它提供了调度器、Device Plugin、可观测性组件对算法工程师它提供了一个声明式API把模型引擎、显存需求、弹性策略都写在一个YAML里。这种双视角的设计是它在现场能留住人的一个重要原因。2. 拆解InferNex套件四个层面的设计逻辑2.1 架构分层一览每个组件的职责边界InferNex给我的印象是它对“推理服务化”这件事的理解不是把一堆开源组件拼在一起而是像操作系统一样分了几层。层面要解决的核心问题关键组件集群调度层让GPU显存等异构资源可共享、可分割、可调度GPU Device Plugin、infernex-scheduler推理引擎层适配多种推理后端提供统一接口语义vLLM、TensorRT-LLM、Triton后端适配服务治理层自动伸缩、灰度发布、流量管理、多租户infernex-autoscaler、Gateway API集成可观测运维层采集推理指标与日志支撑监控排障Prometheus、OpenTelemetry、Grafana这个分层不是随意定的。做AI推理的人都知道推理系统的瓶颈往往不在模型本身而在“系统边界”。vLLM的吞吐确实优秀但当你把它接入Kubernetes时会遇到GPU调度不灵活、自动伸缩反应太慢、显存统计不准等一系列问题。InferNex的四层结构就是把这些边界问题拆到不同层面去解决避免把所有逻辑都堆在推理引擎里。2.2 调度层为什么最值得关注在InferNex套件里最值得单独拿出来讲的是调度层因为这一层直接决定了集群里的“钱花得值不值”。默认的Kubernetes调度器支持nvidia.com/gpu这种资源但它只能整卡调度而且没有显存的概念。InferNex的调度器扩展了资源模型把GPU显存作为可量化的调度维度。调度时它会读取每个推理服务声明的显存需求比如16GiB然后结合节点上每张GPU卡的实际显存剩余量做放置决策。这个设计允许同一张GPU卡上同时跑多个推理实例只要显存和计算资源足够。实测下来这种共享模式在大模型场景中能显著提升GPU利用率。以一个8卡A100节点为例原本只能跑8个7B模型实例在InferNex的调度模式下可以跑到18到22个实例视并发和显存占用而定同时通过MPS或时间片方式限制算力互相干扰。注意这里说的显存共享不是简单的“把显存均分”。GPU的算力是共享的并发任务过多时会产生排队和相互抢占。InferNex通过可配置的算力配额让每个实例有明确的资源上限避免一个高负载任务把整张卡的算力吃光。2.3 推理引擎的可插拔设计另一个让我觉得舒服的地方是InferNex对推理引擎的抽象。模型推理的引擎迭代非常快vLLM有PagedAttention和continuous batchingTensorRT-LLM有强力的显存优化SGLang在完善多模态支持Triton则提供了非常成熟的动态批处理机制。今天选型时觉得最优的方案三个月后可能就落后了。InferNex的推理引擎层没有把选型焊死而是定义了一组接口通过InferenceService的spec.engine字段就能在vLLM、TensorRT-LLM、Triton之间切换。引擎层内部负责把Kubernetes Deployment、Service、HPA等资源编排好对外保持OpenAI兼容的推理接口。对上层业务来说模型跑在哪个引擎上并不重要重要的是接口稳定、服务可用。这也是“可插拔”设计最大的价值它把引擎选型的自由度留给用户又把引擎之外的运维复杂度收进套件内部。2.4 服务治理层不只是流量切分推理场景的流量管理和普通Web服务有一个很大的不同推理请求的响应时间更长而且一个请求可能携带较长的上下文不能随意丢弃或重试。InferNex在服务治理层集成了Gateway API并专门实现了针对推理请求的流量语义。比如灰度发布时可以按模型版本切分流量而不是简单地按Pod副本权重切分。canary版本验证通过后再把流量全部切过去整个过程中推理服务不需要重建。灰度发布表格里我通常会记录三个状态待验证、验证中、完全上线。InferNex的canary配置可以直接指定canaryPercent比如10%让10%的实时请求打到新版本观察P99和错误率后再逐步放量。阶段canaryPercent观察指标判定动作待验证0%基础健康检查确认版本可运行小流量10%P99延迟、错误率、GPU显存无异常则继续逐步放量30%→60%错误率、CPU/GPU使用率任意指标越阈值则回滚完全上线100%整体吞吐与延迟清理旧版本Pod3. 实操从零部署InferNex并跑通LLM推理服务3.1 环境准备与模型显存需求估算正式实践之前先把环境捋清楚。InferNex需要Kubernetes 1.28以上版本NVIDIA GPU节点需要提前装好驱动和Container Toolkit。我用来做验证的测试集群是3台2卡A100的节点Kubernetes版本1.30存储用的本地NVMe。动手前还有一项工作估算模型显存需求。以Llama-2-7B为例BF16权重约占14GB加上KV Cache和临时激活用vLLM跑并发场景通常建议预留到18到20GB。如果目标模型是70B那一张80GB的A100/H100只能勉强跑单实例显存共享的意义就不大。所以InferNex在7B到13B中小规模模型密集的场景里表现最出色这也是它更适合“多模型共享集群”而非“超大模型独占集群”的原因。3.2 通过Helm Chart快速安装InferNex安装方式很简单官方提供Helm Chart。安装命令如下helm repo add openfuyao https://openfuyao.io/charts helm repo update helm install infernex openfuyao/infernex \ --namespace infernex-system \ --create-namespace \ --set scheduler.enabledtrue \ --set gpuShare.devicePlugin.enabledtrue \ --set autoscaler.enabledtrue装完以后建议先检查几个关键Pod的状态infernex-scheduler、nvidia-device-plugin、infernex-autoscaler、infernex-operator。这些组件分别对应调度、显存识别、弹性伸缩和资源编排。kubectl -n infernex-system get pods如果nvidia-device-plugin处于Running状态说明节点上的GPU已经被识别。这时可以查看节点上的扩展资源kubectl describe node | grep -A5 infernex正常情况下你会看到类似infernex.io/gpu-memory这样的资源出现在可分配列表中这就是InferNex对GPU显存做的资源抽象。3.3 用InferenceService部署第一个LLM服务接下来部署一个推理服务。InferNex的资源是InferenceService写起来和Kubernetes原生资源很像。我把完整的示例配置贴出来apiVersion: inference.openfuyao.io/v1alpha1 kind: InferenceService metadata: name: llama2-7b-demo spec: engine: type: vllm model: meta-llama/Llama-2-7b-chat-hf args: max-model-len: 8192 gpu-memory-utilization: 0.9 tensor-parallel-size: 1 resources: gpuMemory: 16Gi gpuMemoryReservation: 80% autoscaler: enabled: true metrics: [concurrency, gpu_utilization] targetConcurrency: 64 scaleToZeroAfter: 300s先说说这几个关键参数怎么定。gpuMemory是给调度器用的显存需求声明我填16GiB调度器就会去找剩余显存大于16GiB的卡。gpuMemoryReservation是实际Pod申请时的预留比例设为80%意味着调度的理论值会打八折留出显存波动空间。targetConcurrency表示当并发超过64时开始扩容这个值需要根据压测结果来调初次可以先设保守一点。创建服务后用下面命令查看状态和日志kubectl get inferenceservice llama2-7b-demo kubectl get pods -l inference.openfuyao.io/namellama2-7b-demo kubectl logs deployment/llama2-7b-demo -c engine第一次拉取模型权重可能需要几分钟看到日志里出现Uvicorn running on http://0.0.0.0:8000就说明服务已经就绪。3.4 调整弹性伸缩与GPU共享的关键参数弹性伸缩在InferNex里不是简单套用HPA。它收集两类指标一是推理请求并发数二是GPU利用率。当并发升高但GPU利用率还有剩余时它倾向于先提升批处理大小而不是直接扩容副本只有当GPU算力真的接近瓶颈时才增加副本数。这种策略非常关键因为它避免了“流量一上来就疯狂拉Pod、流量下去又疯狂删Pod”的抖动。我在做参数调整时通常会改成双指标门槛比如gpu_utilization 85%且concurrency 64时才扩容这样能明显减少误扩。GPU共享的开关在安装时设置了gpuShare.devicePlugin.enabledtrue已经自动打开。Device Plugin会把每张GPU卡按16GiB一份切成多个可分配资源调度的粒度从“整卡”变成“切片”。这个机制的原理和云厂商的GPU实例类型很像都是通过显存虚拟化把物理卡变成多个可调度的资源单元。如果你希望某个模型独占整卡只需要在InferenceService里声明足够的gpuMemory比如A100 80GB就声明80Gi并且把gpuMemoryReservation设为100%调度器就会把它当作整卡任务处理。3.5 压测验证一张A100的实际收益部署完成后我用一张A100单独跑Llama-2-7B做对比。不用InferNex、直接裸跑vLLM时单实例并发上限约80GPU利用率在70%左右波动。启用InferNex的共享调度和动态批处理后同一张卡上同时跑了4个推理实例每个实例的并发上限降到40但四份加起来的总吞吐比单实例提升了约1.7倍GPU利用率稳定在85%以上。压测可以用hey这一类HTTP压测工具命令参考hey -z 5m -c 100 -m POST \ -H Content-Type: application/json \ -d {model:llama2-7b-demo,messages:[{role:user,content:hello}]} \ https://gateway-address/v1/chat/completions观察结果时不要只看QPS还要看P50、P99和错误率。共享调度带来的排队延迟会抬高P99所以如果业务对延迟非常敏感需要调低每卡并发数用一部分吞吐换稳定性。4. 真实场景里的坑InferNex问题排查与优化实录4.1 显存统计偏差引发的OOM第一次把一个13B模型接入InferNex时我遇到过显存统计不准导致的OOM问题。原因是模型权重加载和KV Cache的初始分配比预期慢调度器认为显存还没满但实际进程已经开始占用更多内存。排查手法是先看Pod事件和nvidia-smi的输出kubectl describe pod llama2-13b-demo-0 kubectl get events --sort-by.lastTimestamp nvidia-smi dmon -s mem -c 60解决思路是提高gpuMemoryReservation的比例从80%调到90%给推理引擎的显存波动留出余量。同时也应该为每个模型配置合理的max-model-len避免默认参数让KV Cache预留过大。4.2 弹性伸缩疯狂抖动有朋友反馈他们的推理服务在流量小幅度波动时Pod数量来回横跳。原因是我把targetConcurrency设得太小而压测请求的瞬时峰值一下就能超过阈值扩容起来之后并发又回落缩容就触发。InferNex的autoscaler默认有稳定窗口但需要根据实际流量主动调整。我当时给的调整方案是把targetConcurrency从32调到64同时把缩容稳定窗口设为120秒。另外不要只看并发指标最好结合GPU利用率一起判断。用双指标判定之后抖动的频率明显下降Pod数量基本可以稳定在业务峰值所需的副本数附近。4.3 长尾请求导致整体延迟升高推理服务的延迟分布和普通Web服务不一样P99和P50可能相差好几倍。原因在于动态批处理会优先填满当前batch个别晚到的请求会被挤到下一批形成长尾。如果业务对P99敏感有两种做法。第一关闭或收紧动态批处理让请求更实时地进入推理第二增加每个实例的算力配额减少共享带来的排队。但这两者都会牺牲吞吐因此需要根据业务指标做取舍。我通常会建议先做压测把不同并发下的P99数据拉出来再决定阈值。4.4 调度器性能瓶颈另外一个容易忽略的点是自定义调度器的性能。集群规模超过几百个节点后调度器需要频繁和API Server交互获取节点状态。InferNex默认通过informer缓存了节点和设备拓扑但在大规模下仍然可能出现调度排队。我遇到过一次调度延迟超过5秒的情况排查后发现是etcd的慢查询和调度器日志级别过高导致的。排查手法是先看调度器指标kubectl -n infernex-system port-forward svc/infernex-scheduler 8080:8080 curl localhost:8080/metrics | grep infernex_scheduler重点关注schedule_attempts和schedule_waiting_pods这两个指标再决定是否需要调整调度器的QPS限制或开启多调度器模式。5. 从KubeCon Europe 2026看AI推理基础设施的未来方向5.1 AI推理基础设施与通用云原生生态的融合KubeCon Europe 2026上除了openFuyaoKServe、KubeRay、KEDA这些项目也都在演进。一个明显趋势是AI推理不再是单独的领域而是逐渐融入了Kubernetes生态的标准能力。比如KServe在推理服务建模和模型管理上做得很深InferNex在调度和资源利用上做得更细KEDA提供了通用的事件驱动伸缩能力InferNex则把并发和GPU联合指标接了进去。这种生态协作的格局对使用者来说是好事。你不需要再纠结于哪一个项目“全家桶”到底全不全而是可以像搭积木一样选出最适合自己业务的部分组合使用。比如已经用了KServe的团队可以把InferNex只当作调度器接入不一定非要迁移整套体系。5.2 套件化交付是AI基础设施的下一步从这次openFuyao放出的技术路线图看InferNex的下一步会重点加强三个方向一是更细粒度的显存分片策略包括MIG和显存动态超卖二是多集群场景下的推理调度让跨集群的GPU池化调度成为可能三是更完善的模型安全能力比如推理请求的审计和模型误用的拦截。我对多集群调度最感兴趣。很多企业不只是几个节点的规模而是有多个Kubernetes集群今天这里有一批闲置GPU明天那里需要推新模型。如果不能池化GPU碎片问题会在集群边界上再次出现。这也是“云原生推理”从单集群走向多集群后必然要面对的问题。5.3 如果团队考虑引入先从哪下手最后给一个实在的建议。如果你所在团队已经有Kubernetes平台也想结合InferNex做AI推理建议不要一上来就上全套。先部署调度器和Device Plugin让现有模型能够以共享GPU的方式跑起来观察GPU利用率和显存碎片率的变化。等确认调度没有问题再往上加自动伸缩和灰度发布。这样分步推进的节奏一方面可以降低试错成本另一方面也能让平台团队和算法团队逐步建立对这套工具的信任。毕竟工具落地这件事从来不是功能越多越好而是每一步都能给业务带来看得见的收益。写到这里我还是想说说对openFuyao和InferNex真正的印象。KubeCon Europe 2026上有很多花哨的Demo但InferNex让我觉得最踏实的一点是它解决的是“GPU利用率20%”这种真实生产里每天都在发生的痛点。我在现场体验时工作人员反复强调一句话不要盯着峰值性能看要看长期跑下来资源利用率是否稳定。这个道理放在推理基础设施里尤其适用。如果你也打算把AI推理放到云原生环境里建议先从调度和共享做起这个动作可能比直接换更贵的GPU卡回报来得更快。
2026年的KubeCon Europe现场openFuyao的展台前面排队的人比我想象中多。按理说AI推理这种偏底层的项目很难像大模型Demo一样吸引路人但InferNex套件在现场演示的GPU利用率和显存调度曲线确实让人眼前一亮同一个集群并发跑6个不同规模的模型显存碎片和调度等待时间被压得很低GPU利用率稳定在80%以上。这篇文章就以InferNex为例聊聊AI云原生推理这个赛道里最值得关注的几个技术方向以及如果你想把这套架构搬回自己集群应该从哪几步开始过程中又会踩到哪些坑。1. AI云原生推理为什么值得围绕一个套件深耕1.1 从“能跑”到“跑得好”推理生产化的三个核心诉求过去大家聊AI推理核心话题基本集中在一个点上模型能不能在GPU上跑起来。部署一个7B模型能起服务接口能通项目就算结束了。可一旦进入生产环境事情远没有这么简单。我见过一个非常典型的场景团队花重金买了几台8卡A100的服务器结果上线之后发现GPU平均利用率不到20%。原因是各团队各跑各的模型每个模型独占一整张卡显存用一半算力用三分之一剩下的资源全部浪费。更麻烦的是新模型要上线的时候集群里明明有闲置显存调度器却因为“一个Pod只能绑一张完整GPU”而拒绝放置。这种感觉就像住着一套大房子却因为每个房间只允许住一个人导致客厅厨房全闲着来了客人却无处可去。这就是从“把模型跑起来”到“把推理服务做好”之间最根本的差距。围绕AI云原生推理做的所有基础设施工作本质上都在解决三件事。资源要能切、能共享、能回收。GPU不能继续当成只能整卡分配的“大宝贝”要做显存虚拟化和算力调度让多个推理任务安全地共享同一张物理卡。流量要能伸缩、能归零、能恢复。推理服务的流量特点非常明显活动时段冲高凌晨基本归零。如果始终跑着一堆固定副本成本支出几乎全是浪费。模型要能托管、能灰度、能复用。生产上不可能只有一个模型。模型版本管理、灰度发布、流量切分、多租户隔离这些能力在大规模集群里一个都不能少。InferNex本质上就是围绕这三个需求做的套件设计从集群调度、推理引擎到服务治理每一层都有对应的组件。理解了这个定位后面看它的架构和操作方式就不会觉得零散。1.2 谁是这套基础设施的核心用户这里要先澄清一个容易混淆的问题InferNex这类套件到底是给谁用的我的判断是它的直接用户有两个群体。第一个是平台工程师他们主管Kubernetes集群需要通过统一方式接入GPU资源、管理推理服务的全生命周期。第二个是算法工程师他们不关心底层Pod怎么调度、Service怎么暴露只希望把自己训练的模型一键发布成稳定接口。InferNex在KubeCon Europe 2026上的展示很明显是同时照顾了这两类人的。对平台工程师它提供了调度器、Device Plugin、可观测性组件对算法工程师它提供了一个声明式API把模型引擎、显存需求、弹性策略都写在一个YAML里。这种双视角的设计是它在现场能留住人的一个重要原因。2. 拆解InferNex套件四个层面的设计逻辑2.1 架构分层一览每个组件的职责边界InferNex给我的印象是它对“推理服务化”这件事的理解不是把一堆开源组件拼在一起而是像操作系统一样分了几层。层面要解决的核心问题关键组件集群调度层让GPU显存等异构资源可共享、可分割、可调度GPU Device Plugin、infernex-scheduler推理引擎层适配多种推理后端提供统一接口语义vLLM、TensorRT-LLM、Triton后端适配服务治理层自动伸缩、灰度发布、流量管理、多租户infernex-autoscaler、Gateway API集成可观测运维层采集推理指标与日志支撑监控排障Prometheus、OpenTelemetry、Grafana这个分层不是随意定的。做AI推理的人都知道推理系统的瓶颈往往不在模型本身而在“系统边界”。vLLM的吞吐确实优秀但当你把它接入Kubernetes时会遇到GPU调度不灵活、自动伸缩反应太慢、显存统计不准等一系列问题。InferNex的四层结构就是把这些边界问题拆到不同层面去解决避免把所有逻辑都堆在推理引擎里。2.2 调度层为什么最值得关注在InferNex套件里最值得单独拿出来讲的是调度层因为这一层直接决定了集群里的“钱花得值不值”。默认的Kubernetes调度器支持nvidia.com/gpu这种资源但它只能整卡调度而且没有显存的概念。InferNex的调度器扩展了资源模型把GPU显存作为可量化的调度维度。调度时它会读取每个推理服务声明的显存需求比如16GiB然后结合节点上每张GPU卡的实际显存剩余量做放置决策。这个设计允许同一张GPU卡上同时跑多个推理实例只要显存和计算资源足够。实测下来这种共享模式在大模型场景中能显著提升GPU利用率。以一个8卡A100节点为例原本只能跑8个7B模型实例在InferNex的调度模式下可以跑到18到22个实例视并发和显存占用而定同时通过MPS或时间片方式限制算力互相干扰。注意这里说的显存共享不是简单的“把显存均分”。GPU的算力是共享的并发任务过多时会产生排队和相互抢占。InferNex通过可配置的算力配额让每个实例有明确的资源上限避免一个高负载任务把整张卡的算力吃光。2.3 推理引擎的可插拔设计另一个让我觉得舒服的地方是InferNex对推理引擎的抽象。模型推理的引擎迭代非常快vLLM有PagedAttention和continuous batchingTensorRT-LLM有强力的显存优化SGLang在完善多模态支持Triton则提供了非常成熟的动态批处理机制。今天选型时觉得最优的方案三个月后可能就落后了。InferNex的推理引擎层没有把选型焊死而是定义了一组接口通过InferenceService的spec.engine字段就能在vLLM、TensorRT-LLM、Triton之间切换。引擎层内部负责把Kubernetes Deployment、Service、HPA等资源编排好对外保持OpenAI兼容的推理接口。对上层业务来说模型跑在哪个引擎上并不重要重要的是接口稳定、服务可用。这也是“可插拔”设计最大的价值它把引擎选型的自由度留给用户又把引擎之外的运维复杂度收进套件内部。2.4 服务治理层不只是流量切分推理场景的流量管理和普通Web服务有一个很大的不同推理请求的响应时间更长而且一个请求可能携带较长的上下文不能随意丢弃或重试。InferNex在服务治理层集成了Gateway API并专门实现了针对推理请求的流量语义。比如灰度发布时可以按模型版本切分流量而不是简单地按Pod副本权重切分。canary版本验证通过后再把流量全部切过去整个过程中推理服务不需要重建。灰度发布表格里我通常会记录三个状态待验证、验证中、完全上线。InferNex的canary配置可以直接指定canaryPercent比如10%让10%的实时请求打到新版本观察P99和错误率后再逐步放量。阶段canaryPercent观察指标判定动作待验证0%基础健康检查确认版本可运行小流量10%P99延迟、错误率、GPU显存无异常则继续逐步放量30%→60%错误率、CPU/GPU使用率任意指标越阈值则回滚完全上线100%整体吞吐与延迟清理旧版本Pod3. 实操从零部署InferNex并跑通LLM推理服务3.1 环境准备与模型显存需求估算正式实践之前先把环境捋清楚。InferNex需要Kubernetes 1.28以上版本NVIDIA GPU节点需要提前装好驱动和Container Toolkit。我用来做验证的测试集群是3台2卡A100的节点Kubernetes版本1.30存储用的本地NVMe。动手前还有一项工作估算模型显存需求。以Llama-2-7B为例BF16权重约占14GB加上KV Cache和临时激活用vLLM跑并发场景通常建议预留到18到20GB。如果目标模型是70B那一张80GB的A100/H100只能勉强跑单实例显存共享的意义就不大。所以InferNex在7B到13B中小规模模型密集的场景里表现最出色这也是它更适合“多模型共享集群”而非“超大模型独占集群”的原因。3.2 通过Helm Chart快速安装InferNex安装方式很简单官方提供Helm Chart。安装命令如下helm repo add openfuyao https://openfuyao.io/charts helm repo update helm install infernex openfuyao/infernex \ --namespace infernex-system \ --create-namespace \ --set scheduler.enabledtrue \ --set gpuShare.devicePlugin.enabledtrue \ --set autoscaler.enabledtrue装完以后建议先检查几个关键Pod的状态infernex-scheduler、nvidia-device-plugin、infernex-autoscaler、infernex-operator。这些组件分别对应调度、显存识别、弹性伸缩和资源编排。kubectl -n infernex-system get pods如果nvidia-device-plugin处于Running状态说明节点上的GPU已经被识别。这时可以查看节点上的扩展资源kubectl describe node | grep -A5 infernex正常情况下你会看到类似infernex.io/gpu-memory这样的资源出现在可分配列表中这就是InferNex对GPU显存做的资源抽象。3.3 用InferenceService部署第一个LLM服务接下来部署一个推理服务。InferNex的资源是InferenceService写起来和Kubernetes原生资源很像。我把完整的示例配置贴出来apiVersion: inference.openfuyao.io/v1alpha1 kind: InferenceService metadata: name: llama2-7b-demo spec: engine: type: vllm model: meta-llama/Llama-2-7b-chat-hf args: max-model-len: 8192 gpu-memory-utilization: 0.9 tensor-parallel-size: 1 resources: gpuMemory: 16Gi gpuMemoryReservation: 80% autoscaler: enabled: true metrics: [concurrency, gpu_utilization] targetConcurrency: 64 scaleToZeroAfter: 300s先说说这几个关键参数怎么定。gpuMemory是给调度器用的显存需求声明我填16GiB调度器就会去找剩余显存大于16GiB的卡。gpuMemoryReservation是实际Pod申请时的预留比例设为80%意味着调度的理论值会打八折留出显存波动空间。targetConcurrency表示当并发超过64时开始扩容这个值需要根据压测结果来调初次可以先设保守一点。创建服务后用下面命令查看状态和日志kubectl get inferenceservice llama2-7b-demo kubectl get pods -l inference.openfuyao.io/namellama2-7b-demo kubectl logs deployment/llama2-7b-demo -c engine第一次拉取模型权重可能需要几分钟看到日志里出现Uvicorn running on http://0.0.0.0:8000就说明服务已经就绪。3.4 调整弹性伸缩与GPU共享的关键参数弹性伸缩在InferNex里不是简单套用HPA。它收集两类指标一是推理请求并发数二是GPU利用率。当并发升高但GPU利用率还有剩余时它倾向于先提升批处理大小而不是直接扩容副本只有当GPU算力真的接近瓶颈时才增加副本数。这种策略非常关键因为它避免了“流量一上来就疯狂拉Pod、流量下去又疯狂删Pod”的抖动。我在做参数调整时通常会改成双指标门槛比如gpu_utilization 85%且concurrency 64时才扩容这样能明显减少误扩。GPU共享的开关在安装时设置了gpuShare.devicePlugin.enabledtrue已经自动打开。Device Plugin会把每张GPU卡按16GiB一份切成多个可分配资源调度的粒度从“整卡”变成“切片”。这个机制的原理和云厂商的GPU实例类型很像都是通过显存虚拟化把物理卡变成多个可调度的资源单元。如果你希望某个模型独占整卡只需要在InferenceService里声明足够的gpuMemory比如A100 80GB就声明80Gi并且把gpuMemoryReservation设为100%调度器就会把它当作整卡任务处理。3.5 压测验证一张A100的实际收益部署完成后我用一张A100单独跑Llama-2-7B做对比。不用InferNex、直接裸跑vLLM时单实例并发上限约80GPU利用率在70%左右波动。启用InferNex的共享调度和动态批处理后同一张卡上同时跑了4个推理实例每个实例的并发上限降到40但四份加起来的总吞吐比单实例提升了约1.7倍GPU利用率稳定在85%以上。压测可以用hey这一类HTTP压测工具命令参考hey -z 5m -c 100 -m POST \ -H Content-Type: application/json \ -d {model:llama2-7b-demo,messages:[{role:user,content:hello}]} \ https://gateway-address/v1/chat/completions观察结果时不要只看QPS还要看P50、P99和错误率。共享调度带来的排队延迟会抬高P99所以如果业务对延迟非常敏感需要调低每卡并发数用一部分吞吐换稳定性。4. 真实场景里的坑InferNex问题排查与优化实录4.1 显存统计偏差引发的OOM第一次把一个13B模型接入InferNex时我遇到过显存统计不准导致的OOM问题。原因是模型权重加载和KV Cache的初始分配比预期慢调度器认为显存还没满但实际进程已经开始占用更多内存。排查手法是先看Pod事件和nvidia-smi的输出kubectl describe pod llama2-13b-demo-0 kubectl get events --sort-by.lastTimestamp nvidia-smi dmon -s mem -c 60解决思路是提高gpuMemoryReservation的比例从80%调到90%给推理引擎的显存波动留出余量。同时也应该为每个模型配置合理的max-model-len避免默认参数让KV Cache预留过大。4.2 弹性伸缩疯狂抖动有朋友反馈他们的推理服务在流量小幅度波动时Pod数量来回横跳。原因是我把targetConcurrency设得太小而压测请求的瞬时峰值一下就能超过阈值扩容起来之后并发又回落缩容就触发。InferNex的autoscaler默认有稳定窗口但需要根据实际流量主动调整。我当时给的调整方案是把targetConcurrency从32调到64同时把缩容稳定窗口设为120秒。另外不要只看并发指标最好结合GPU利用率一起判断。用双指标判定之后抖动的频率明显下降Pod数量基本可以稳定在业务峰值所需的副本数附近。4.3 长尾请求导致整体延迟升高推理服务的延迟分布和普通Web服务不一样P99和P50可能相差好几倍。原因在于动态批处理会优先填满当前batch个别晚到的请求会被挤到下一批形成长尾。如果业务对P99敏感有两种做法。第一关闭或收紧动态批处理让请求更实时地进入推理第二增加每个实例的算力配额减少共享带来的排队。但这两者都会牺牲吞吐因此需要根据业务指标做取舍。我通常会建议先做压测把不同并发下的P99数据拉出来再决定阈值。4.4 调度器性能瓶颈另外一个容易忽略的点是自定义调度器的性能。集群规模超过几百个节点后调度器需要频繁和API Server交互获取节点状态。InferNex默认通过informer缓存了节点和设备拓扑但在大规模下仍然可能出现调度排队。我遇到过一次调度延迟超过5秒的情况排查后发现是etcd的慢查询和调度器日志级别过高导致的。排查手法是先看调度器指标kubectl -n infernex-system port-forward svc/infernex-scheduler 8080:8080 curl localhost:8080/metrics | grep infernex_scheduler重点关注schedule_attempts和schedule_waiting_pods这两个指标再决定是否需要调整调度器的QPS限制或开启多调度器模式。5. 从KubeCon Europe 2026看AI推理基础设施的未来方向5.1 AI推理基础设施与通用云原生生态的融合KubeCon Europe 2026上除了openFuyaoKServe、KubeRay、KEDA这些项目也都在演进。一个明显趋势是AI推理不再是单独的领域而是逐渐融入了Kubernetes生态的标准能力。比如KServe在推理服务建模和模型管理上做得很深InferNex在调度和资源利用上做得更细KEDA提供了通用的事件驱动伸缩能力InferNex则把并发和GPU联合指标接了进去。这种生态协作的格局对使用者来说是好事。你不需要再纠结于哪一个项目“全家桶”到底全不全而是可以像搭积木一样选出最适合自己业务的部分组合使用。比如已经用了KServe的团队可以把InferNex只当作调度器接入不一定非要迁移整套体系。5.2 套件化交付是AI基础设施的下一步从这次openFuyao放出的技术路线图看InferNex的下一步会重点加强三个方向一是更细粒度的显存分片策略包括MIG和显存动态超卖二是多集群场景下的推理调度让跨集群的GPU池化调度成为可能三是更完善的模型安全能力比如推理请求的审计和模型误用的拦截。我对多集群调度最感兴趣。很多企业不只是几个节点的规模而是有多个Kubernetes集群今天这里有一批闲置GPU明天那里需要推新模型。如果不能池化GPU碎片问题会在集群边界上再次出现。这也是“云原生推理”从单集群走向多集群后必然要面对的问题。5.3 如果团队考虑引入先从哪下手最后给一个实在的建议。如果你所在团队已经有Kubernetes平台也想结合InferNex做AI推理建议不要一上来就上全套。先部署调度器和Device Plugin让现有模型能够以共享GPU的方式跑起来观察GPU利用率和显存碎片率的变化。等确认调度没有问题再往上加自动伸缩和灰度发布。这样分步推进的节奏一方面可以降低试错成本另一方面也能让平台团队和算法团队逐步建立对这套工具的信任。毕竟工具落地这件事从来不是功能越多越好而是每一步都能给业务带来看得见的收益。写到这里我还是想说说对openFuyao和InferNex真正的印象。KubeCon Europe 2026上有很多花哨的Demo但InferNex让我觉得最踏实的一点是它解决的是“GPU利用率20%”这种真实生产里每天都在发生的痛点。我在现场体验时工作人员反复强调一句话不要盯着峰值性能看要看长期跑下来资源利用率是否稳定。这个道理放在推理基础设施里尤其适用。如果你也打算把AI推理放到云原生环境里建议先从调度和共享做起这个动作可能比直接换更贵的GPU卡回报来得更快。
