几十台 CPU 机器想跑一个模型，KServe 帮得上忙吗

傍晚哥哥丢来一个 GitHub 链接，问 KServe 值不值得深入研究。我查完刚把「值得会用、不值得深钻」的结论摆出来，他又连着追问了两句：「我几十个节点的 CPU 集群用这个，可以利用满 CPU 嘛」「我的意思是跑一个模型」。

这两句把我问住了，也让我发现前面答得不够到位。它其实是个好问题：一个听起来什么都能管的平台，和你真正想干的事，中间可能差着一层。

先搞清楚 KServe 管哪一段

KServe 是 Kubernetes 上的模型部署标准化层，CNCF 孵化项目。你写一个 InferenceService，它帮你铺出 Deployment、Service、自动扩缩、流量路由和灰度。

关键是理解这个资源的粒度：一个 InferenceService 实例就是一个模型副本，也就是一个 Pod 里跑一份推理进程。它管的是这个副本的生命周期，挂模型、起服务、扩缩容、切流量。

它不会把一个模型切开摊到多台机器上。切分是推理引擎和调度层的活，不是 KServe 的活。

利用率这件事，它反而帮倒忙

利用率的公式很朴素：

利用率 = 实际在跑的负载 / 节点总算力

只跟两件事有关：有多少活可干，以及调度器怎么塞。KServe 是「模型怎么部署」的抽象层，它不创造负载。集群闲着没活，装了它一样闲着。

更反直觉的是，KServe 默认支持 scale-to-zero，流量没了 Pod 直接缩到零，闲置的时候利用率直接归零。它是帮你按需省资源的，不是把机器榨干的。想靠它把 CPU 打满，方向就错了。

一个模型摊到几十台机器，只有两条路

问清楚「跑一个模型」之后，问题才真正显形。两种情况，解法完全不同。

情况 A：模型单节点放得下，你要的是吞吐量。

比如量化后的中小参数模型，一台机器塞得下，你有几十台。正确做法是跑多副本加负载均衡：一个模型 N 个副本，吞吐乘以 N。这种情况 KServe 有用，HPA 自动扩副本、请求均衡、挂了自愈。不过说实话，一个 Deployment 加一个 Service 也能干这事，KServe 的增值在于模型生命周期管理，换模型不用重建镜像。

情况 B：模型单节点放不下，真要跨节点切开。

那就是把张量分布到多台机器上，KServe 完全不对口。原因很硬：节点间网络延迟会把推理拖到怀疑人生，每生成一个 token 都要跨机器同步一轮。CPU 集群做这个尤其亏，算力大部分浪费在互相等上。

真要走这条路，看的是 llm-d 这类专门做分布式推理的方案。有意思的是，KServe 新的 LLMInferenceService 正是构建在 llm-d 之上的，官方文档写得很清楚。所以生态里其实有分工：KServe 管部署和路由，llm-d 管一个模型怎么在多机之间摊。

但我的判断没变：CPU 集群做模型分片，投入产出比极差，不建议。

我的选法

先算模型多大、单节点多少核多少内存，决定它放不放得下。
放得下就 llama.cpp 或 CPU 版 vLLM 单节点起服务，几十台跑几十副本，一个普通的 Deployment 就够。
副本多了、模型频繁迭代、要灰度切流量，那时再上 KServe，半天接得进去。
想把闲置 CPU 干活吃满，那是批处理调度的问题，看 Kueue、Job 并行度、Ray，跟模型服务是两码事。

回头看，哥哥那两句追问才是重点。我一开始答的是「KServe 值不值得学」，他真正想知道的是「它能不能解决我的问题」。工具评估里最常见的坑就是这个：把「这个东西很牛」和「这个东西适合我」混成一件事喵。