专访梁胜：让任何模型在任何GPU上高质量高性能生产Token

在 GPUStack 生态与技术创新大会期间，我终于见到了那个人：梁胜博士。

作为他的忠实粉丝，这一次难得有机会坐下来，和他进行了一场深度对话。

GPUStack 想做的事情很大：

让任何模型，都能在任何 GPU 上，高质量、高性能地生产 Token。

上一期文章，我已经拆解了 GPUStack 的产品和技术架构。

但这一次，我更想聊聊技术背后的人，以及技术背后的判断。

我们暂时放下产品参数和架构图，听梁胜博士亲自讲讲，GPUStack 是怎么来的，又准备走向哪里。

以下为访谈实录⬇️

➤小黑羊：

非常荣幸能够采访您，我本人也曾经是IT Infra的相关从业者，在CloudStack时代就非常关注您，也是您的忠实粉丝。

从CloudStack到Rancher再到GPUStack，您几乎完整经历了整个IT Infra的迭代周期。

从云时代的VM管理到云原生时代的容器管理，再到现在Token时代的GPU和推理工作负载管理，基本上每个时代的“Stack”都有您在引领的趋势，而且都做得非常成功。

所以我特别好奇，您是怎么判断一个技术从热点变成实质性可落地的商业机会？您最看重哪些信号？

➤梁胜：

这个问得很好，其实我还是单纯的从我个人作为用户的角度来看。

因为市场调研这个事情对我来讲也不是我的特长，我从来也不觉得特别靠谱。

但是如果我个人是用户的话，就比较好。

比如当年做 CloudStack 之前，我自己就在用亚马逊的云服务，用下来觉得这个东西确实有价值。

容器也是一样。Docker 刚出来的时候，我以前 cloud.com 的一个投资人说想投资 Docker。

当时我连这家公司都不知道，听他说要投，我就去研究了一下。看完之后觉得这个东西确实很奇妙，有些地方甚至比当年的虚拟机做得更好。

AI 也是类似的过程。

Llama 出来以后，很多人开始下载、自己部署，也出现了 LM Studio 等各种软件。我自己很早就开始用 vLLM、llama.cpp。

但用下来总觉得，距离真正把模型做成一个好用的服务，体验上还有一段距离，所以后来我们开始做 GPUStack。

刚开始做的时候，环境也没有今天这么复杂。当时模型主要就是 Llama，GPU也没有现在这么多选择，更没有这么多国产GPU，基本就是英伟达。

当然，这个故事很多人都会讲，我肯定不是第一个看到这些问题的人。

但我觉得我们有一点可能不太一样，就是比较专注。

我们希望真正把它做成一个开源产品，把体验做好，把那些繁琐的问题一个个解决掉，然后尽可能让更多用户使用。

从这个角度来说，我觉得很多人做得还不够专注。

而在我看来，这件事情值得长期专注地做下去。

➤小黑羊：

刚才您正好提到了开源，不管是CloudStack还是Rancher，都是非常重要且成功的开源项目，包括现在的GPUStack也是开源项目。

您为什么特别偏爱开源？又如何看待很多商业公司白嫖开源项目，您的产品被白嫖过吗？

➤梁胜：

那当然有了，但我倒不是特别在乎，因为世界上可能99%的产品都到不了担心被白嫖的那个阶段。

你知道我意思，这个（白嫖）其实是也一种很大的认可，实际上。

特别现在有AI智能体之后，做项目比以前是更简单的，最关键是你不知道你做了对的事情没有，你做出来的东西到底有没有价值。

那你怎么办呢？你可以做出来，你可以跟人去解释，看有没有人买。

这个我觉得台阶就太高了，很多人可能跨不过那个台阶。

所以，对我来说，开源是一种能够快速获得真实反馈的方式。

你可能坚信自己做出来的东西很好，但实际上十有八九，甚至 99.99% 的时候，未必真有那么好。

有些人就是不在乎，没人用也继续做。

但我其实还是比较在乎这种用户反馈的，如果我做一个东西没人用，我马上兴致就不大了，就去做下一个东西了。

所以做开源，它可以给我一些早期的反馈，从另一个角度说，被商业公司白嫖，可能也是对开源产品成功的一种认可，它会推动这个产品的普及。

当年有不少公司，把Rancher稍微改一改就拿去卖，这其实也挺好。

后来甚至有客户找到我们，说自己是 Rancher 的客户。我们一看才发现，他们用的其实是别人基于Rancher改的产品，连 Rancher 的牌子都没换。

绕了一圈，最后他们还真成了我们的客户。

我觉得这都是很好的事情，只是绝大部分公司做不到那个级别而已啦。

Rancher 当年被收购时，一年的业绩大概是 5000 万美元，折合人民币也就 3 亿多，其实并不算特别大。

所以在那个阶段，被别人“白嫖”并不是什么问题。

➤小黑羊：

国内现在的GPU非常多，不止品牌，还有型号。以前做云的时候，大家有一个感觉，做这种异构硬件纳管，是一个脏活累活。

导致很多厂商都把这种私有云做成了定制化的项目，这个问题在 GPU 时代同样会存在，GPUStack如何避免自己陷入到定制化适配泥潭中呢？

➤梁胜：

对，实际上我们看的还是这个东西到底有没有价值。

你说的很对，比如说各家模型厂商，在一种GPU上做训练，然后在推理层面，不可能对所有类型的GPU做适配和优化，跑分也是在最优的GPU上得到的结果。

但是开源权重的模型最后他发布出去了，很多客户并没有他一样的GPU，就必须有人做这件事，这一点在国内可能更明显（国外反而没有这么多类型的GPU）。

所以现在这类客户的情况呢，那他说我可以自己干，或者雇一个团队来，给我做定制化，也可以直接把GPUStack下载下来，这东西都调好了。

应该是，至少是都能run起来，中间最重要的可能都已经调优了，我觉得这个价值本身就很大。

所以我觉得，这恰恰是 GPUStack 的价值：让用户不需要自己做大量定制。

这也再次印证了，我们为什么一定要开源。因为这件事只靠闭源，很难做成。

我们每周都会收到大量反馈：某个模型在某款GPU上跑得不好，有开发者自己调通了、修好了，就把代码直接贡献回来。

尤其是一些高端或者偏门的GPU，我们不可能第一时间把所有硬件都买回来测试。

只有借助开源社区的力量，才能覆盖足够多的模型和GPU组合。

你看 Linux 为什么能支持那么多不同的硬件和外设？开源社区功不可没。

➤小黑羊：

我看今天来参会的生态伙伴里面GPU厂非常多，他们会主动对GPUStack做适配吗？

➤梁胜：

会有的，但很多时候它们都甚至可以不直接跟我们打交道，因为有个东西叫推理引擎。

很多推理引擎本身就带有很强的定制属性。比如基于 vLLM、SGLang 做一个分支，我们直接把这个分支整合进来就行。

但整合之后还会遇到新问题。比如这个版本跑 DeepSeek 很好，却跑不了 GLM。

过一段时间，可能又有开源用户做出一个新分支，专门解决某款 GPU 跑 GLM 的问题，我们再把它整合进来。

所以我们在这个领域，核心其实就做两件事：第一是适配和匹配，第二是调优。

所谓调优，大部分时候其实是参数和配置的调优。真正需要修改算法、修改底层代码的情况当然有，但占比很少。

现在国内做类似事情的公司很多，只是形态和我们不太一样。很多公司会做高度定制化的闭源软件，甚至直接把软硬件打包成一套系统来卖。

大家也经常强调自己有独特的性能调优技术。

但我们讲得比较实在：很多时候，所谓性能调优，就是把模型、GPU、推理引擎和参数真正匹配好。

别小看这件事，能把这些参数真正调好，本身就已经非常不简单了。

说实在的，你真的能够发明新的算子吗？连 DeepSeek 都没有发明。

你作为第三方要把 DeepSeek 跑在华为 GPU 上，还比 DeepSeek 自己跑得更快，我觉得不太可能。

现在国内这方面的噪音非常大，有时候客户自己也搞不清楚。

有些厂商说自己做了很多性能调优，我看了一下数字，其实也就是配置调了一下，并不是什么特别了不起的数字。

甚至有时候，他可能先把基础的 Run 跑得很慢，然后再告诉你：你看，从我这里一跑，性能就变快了。

所以有时候客户也很难判断。

我们相对比较诚实。最近一个版本的 GPUStack 里，我们专门做了一个性能测试功能。

因为很多客户部署完以后，自己也想测一测到底能跑多快。

后来我们发现，性能测试本身也很有窍门。

比如测试吞吐量，根据你给它的负载不同，或者测试时间长短不同，最后测出来的吞吐量都会不一样。

有时候甚至会画出一维、二维的曲线，让你看到不同状态下吞吐量到底是什么样的。

如果你非要用最高的那个数字，那当然也可以报最高值。

但对用户来说，把这些真实的数据展示出来其实更有用，也更透明。

而且它本身也是一个工具。比如运维人员可以拿它做容量规划：我有这么多 GPU，这个模型到底应该分配多少张？分配完以后，又能支撑多少用户？

这些问题，用户自己都可以测清楚。

所以实际上，GPUStack就是一个非常透明、非常诚实的工具。

➤小黑羊：

现在各种各样的模型更新速度特别快，以月甚至以周为单位迭代，那么对GPUStack来说，实现Day 0模型适配，难度有多大？

➤梁胜：

这个基本还是通过上游来实现。

什么叫 Day 0？一般一个模型发布时，会告诉你：这个模型可以用某一个或者几个推理引擎，同时支持某几种 GPU，有时候甚至只支持一种 GPU。

我们要做的，就是模型发布当天，马上把这些已经支持的模型、推理引擎和 GPU 组合整合进 GPUStack。

这样，外面的 GPUStack 用户第一时间就能用上，这就是我们说的 Day 0 支持。

当然，如果要把这个模型移植到它原本不支持的其他 GPU 上，那肯定还需要时间。

所以所谓 Day 0 支持，核心就是一件事：

上游已经支持的东西，我们不要站在中间再增加一层障碍，而是第一时间把它整合进来，让用户马上就能用。

这里面其实没有什么黑科技，而且实际上用户想让我们解决也就这些问题。

关于Day0支持，还有一点也很重要，你要看谁最在意Day0。

新的模型出来以后，社区用户往往会第一时间想看一看、试一试。再比如学校、研究机构的一些用户，本身也不是生产环境，他们对 Day 0 的需求也会比较强。

企业客户当然也会好奇，也想第一时间比较一下。

但说实在的，如果只是想体验、比较，直接去模型厂商的网站上试就可以了，没有必要马上自己部署一套。

真正进入企业生产环境以后，情况就不一样了，自己部署是有很多要求的，企业也会非常小心。

所以我觉得，企业真正部署模型，对 Day 0 的要求反而没有那么高。

生产环境本身就是一个需要谨慎推进的系统工程，通常都会慢慢测试、验证，再逐步发布。

➤小黑羊：

今天 Keynote 最后提到了“训推一体”。为什么 GPUStack 现阶段把重点放在模型服务和推理上，而没有做大模型训练？

➤梁胜：

首先还是需求问题，我们团队的力量也有限。

训练、Fine-tune 用的是另外一套技术栈，跟推理完全不一样。

它不是 vLLM，也不是 SGLang，而是完全不同的一套东西。

目前我们的客户当然也有训练需求，但还没有特别明显。真正有这类需求的客户，可以直接租 GPU，自己把训练环境搭起来。

所以现阶段，我们还没有做到那一步。

但我说的“训推一体”，其实还有另外一层考虑。

我个人非常关注一个方向，就是未来的推理会不会逐渐变成一种“有状态的推理”。

现在模型推理完成以后，并不会直接改变权重。很多状态和记忆，其实都维护在智能体这一侧，并没有真正放到模型里面。

但未来有没有可能发生变化？推理引擎本身开始维护越来越多的状态，甚至把推理和学习逐渐结合起来。

就像人的大脑一样，人的记忆本来就在脑子里面，并不是全部放在一个外部系统里。

我在美国也有朋友在做这方面的创业。你也可以把它理解成一种新的推理引擎：它是有状态的，自由度也更大。

当然，这件事技术难度非常高，最后能够做到什么程度，现在还不知道，但我们一直非常关注。

如果未来推理和学习真的能够结合起来，GPUStack 的市场需求可能会大很多。

因为到了那个时候，企业可能更不愿意把这些东西全部放到云上。现在只是模型推理，将来如果连模型的状态、记忆甚至学习过程都在里面，相当于把自己的“脑子”也放上去了。

企业自己部署、自己管理的意愿可能会更强，在国外也是一样。

对 GPUStack 来说，这也会带来很多新的问题。

一旦推理开始有状态，就一定会涉及：状态怎么管理？存储怎么管理？底层基础设施怎么管理？

这其实又回到了我们以前做 Longhorn 时很熟悉的基础设施问题。我自己很喜欢做这类事情，因为这里面有很多真正的问题可以解决。

甚至未来 GPU 服务器本身的形态都可能发生变化。

到了那个时候，GPUStack 这样的系统就会有更大的用武之地：把 GPU、内存、存储以及这些状态真正统一管理起来。

我觉得这会是一件很有意思的事情。

➤小黑羊：

今天上午KeyNote展示了一组数据，GPUStack 在全球已经有 11 万多的安装量，其中 50% 以上来自国内。

从目前国内的落地情况来看，大家用 GPUStack 最多是在解决什么问题？

➤梁胜：

如果从安装量来看，大部分用户的使用场景可能还是偏小。

最常见的就是：我需要一个平台放在那里，每次有新模型出来，都可以很方便地部署下来试一试。

你可能会问，那为什么不直接装个 vLLM？

这也说明，我们做的 Day 0 部署这些东西，还是有人认可的。对用户来说，确实方便一些，这应该是目前较多的一类场景。

第二类就是用户有一批机器，可能还是异构的GPU，他需要把这些机器统一管理起来，再提供给其他人使用，今天清华的用户分享的案例就比较典型。

而且，大部分客户都是这样来的↓

先通过开源使用 GPUStack，再逐渐转化成商业用户。

因为我们也没有什么销售团队，我们的模式主要还是 Inbound，也就是客户主动找过来。

对于我们这样的小公司，这也是比较合适的方式，主动出去一个个敲门找客户，效率太低了。

另外，除了国内，美国还是有很多用户在使用 GPUStack。

美国用户还有一个特点，他们使用的 GPU 相对比较统一，基本都是 NVIDIA，所以遇到的问题可能也少一些。很多时候部署下去，直接就能 Work。

而且我觉得，美国用户也没有什么理由不认可中国开发的软件。

毕竟现在他们跑的很多模型，本来就是中国开发的。

➤小黑羊：

最后一个问题，您认为GPUStack最不可替代的能力是什么？

➤梁胜：

如果从长期来看，我觉得还是用户群和社区。

我们每个星期都会开一次会，把过去一周社区反馈的问题一个个拿出来审查。

每次都是密密麻麻的一大堆：什么配置、什么 GPU、跑什么模型、运行到什么时候出了什么问题。

这些都是真实用户在真实环境里遇到的问题。

很多问题现在就算交给 AI Coding Agent，它也不知道该怎么解决。

我们需要跟用户一起复现问题，搞清楚原因，再做很多研究。

AI Agent 可以提供一些基本思路，但真正把问题解决掉，还是需要一点点去打磨。

刚才我们也讲了，我们实际上是在跟大量的定制化方案竞争。

把一件高度定制化的事情真正做成产品，其实非常不容易。

所以我觉得，长期来看，这可能会成为 GPUStack 最重要的护城河：把产品覆盖面做大，把质量真正做上去。

有点像早期的 Linux。上世纪 90 年代的时候，有人说 Linux 很重要的护城河就是它积累了大量硬件驱动。很多人给它写驱动，然后一点点沉淀在那里。

社区把这些东西长期积累下来，看起来都是苦活、累活，但其实非常有价值。后来的人如果想从头再做一遍，会非常困难。

我们也希望越来越多的人使用 GPUStack。

另外，我非常希望未来能够跟这些推理引擎团队有更深入的合作。

前段时间 vLLM、SGLang 这些推理引擎团队都融了很多钱，我也跟他们交流过。

我当时跟他们说，你们将来也会遇到产品化的问题，比如 vLLM 如果做企业级产品，是不是就会变成类似 Red Hat 的支持模式？

当然，他们也可以继续往上做，把整个东西做得更加开箱即用。

但后来我们看到，vLLM 只需要服务一些超大规模部署，业务量可能就已经足够了。所以他们选择了更上层、更大规模的市场。

这反而给 GPUStack 留出了机会，让我们可以继续服务下面更广泛的市场。

另外一个很有意思的变化是，现在硅谷还有很多人在做新的推理引擎。

大家都想尝试一些不同于 vLLM 的东西。比如强化学习、循环推理，这些新场景都会带来新的优化机会。

我以前读博士时的教授，最近也从学校 Leave 了，跑到加州开了一家小公司，带着三个学生做一个新的推理引擎。昨天我还看到伯克利又出了一个新的。

所以未来会怎么样，我也不知道。

说不定推理引擎会越来越多，甚至可能比 GPU 还多。

以前我经常讲，GPUStack 面对的是一个 M×N 的问题：上面有 M 种模型，下面有 N 种 GPU，我们负责把它们匹配起来。

但现在看，可能还要再增加一个维度：推理引擎。

未来可能是不同的模型、不同的推理引擎，再加上不同的 GPU，组合会越来越多。

如果真是这样，就更需要 GPUStack 这样的产品，把这些复杂的组合统一管理起来。

只要这里面还有真正的问题需要解决，我们就继续做，把它做成一个好产品。

聊完这些问题，我很有一些感慨⬇️

从 CloudStack，到 Rancher，再到今天的 GPUStack，看起来梁胜博士一直在追逐不同的技术浪潮：云计算、容器、GPU、AI。

但仔细想想，他好像一直在做同一件事。

当一种新技术开始爆发，底层越来越复杂、选择越来越多的时候，总需要有人站出来，把那些繁琐、脏累、没人愿意做的事情，一点点做成产品。

CloudStack 管的是虚拟机，Rancher 管的是容器。

到了 GPUStack，要面对的则是越来越多的模型、越来越多的 GPU，以及可能比 GPU 还多的推理引擎。

技术变了，问题的形态变了。

但梁胜博士选择的方法似乎一直没怎么变：

先把自己当成用户，找到真正不好用的地方；然后开源，让更多人来用；再跟着真实用户，把一个个细碎的问题解决掉。

没有那么多神秘的黑科技，也没有密而不传的独门武功。

更多时候，是某个模型在某张 GPU 上跑不起来，是一个参数没有调对，是一个社区用户提交的问题，是每周会议上那一页又一页密密麻麻的 Issue。

这些事情看起来不性感，甚至平淡且充满苦累，但 Linux 当年的无数驱动，也是这样一行一行积累起来的。

采访最后，梁胜博士说了一句话，我印象很深：

“只要这里面还有真正的问题需要解决，我们就继续做，把它做成一个好产品。”

技术浪潮一直在变，但每个时代都有每个时代的 Stack。或许，GPUStack 就是这个时代的答案。