SGLang、vLLM、xAI……这几个词放在一起不像技术选型更像一场权力的游戏。上周和一位做 AI Infra 的朋友碰了一下午化名盛颖。她从模型推理优化聊到算力集群又绕回开源社区的版本分裂和路线之争。我们最后比较一致的判断是AI Infra 的浪漫不是把集群铺得有多大而是让复杂系统能被普通人轻易用起来开源让这种能力变得普惠但普惠不等于没有门槛也不等于社区里不存在“甄嬛传”。这篇文章不想写成 SGLang 的安装手册也不准备站队说谁一定比谁强。我更想把 AI Infra 这件事拆开讲清楚为什么它值得被称作浪漫为什么开源让推理能力平权以及为什么当你真正开始用这些开源框架时会遇到比技术更复杂的治理问题。1. AI Infra 的浪漫不是“堆算力”而是“调度复杂性”1.1 为什么 SGLang 会被反复讨论SGLang 常被看作大模型推理框架里的后起之秀。它和 vLLM 并列出现但设计思路不完全一样。SGLang 的核心是 RadixAttention一种基于树状结构来管理 KV Cache 的方式。它把请求中频繁重复的前缀缓存下来让多个请求复用已经计算过的结果。聊天记录、系统提示词、代码补全的上下文、Agent 任务里反复出现的工具描述都属于典型的高复用前缀。当这些前缀被复用时预填充开销会明显下降首字延迟和整体吞吐都会受益。这也是为什么很多长上下文场景里SGLang 的表现值得关注。除此之外SGLang 在结构化输出上也做了闭环优化。常见做法是把 JSON Schema 编译成状态机让模型在解码过程中直接受到约束而不是生成完再做一次“碰运气”式的解析。对接口稳定性要求高的业务来说这个细节常常比跑分更重要。它还支持多模态输入和多种后端整体更偏“一个框架覆盖多种推理需求”。但这些能力不是没有代价。SGLang 的版本迭代很快新特性多配置项也多如果只看官方 README新手很容易在参数选择上迷失。这也是很多团队把它和 vLLM 反复对比的原因不是谁更能“跑分”而是谁更适合自己的业务形态。1.2 从 vLLM 到 SGLang同一个问题不同的解法vLLM 最广为人知的设计是 PagedAttention把 KV Cache 切成固定大小的块按需分配减少显存碎片同时提升批处理时的吞吐。这个思路借鉴了操作系统虚拟内存的管理方式解决的是“显存不够、并发上不去”的经典痛点。SGLang 的切入点更偏向请求生命周期从 tokenization、prefill、decode、structured output到 KV Cache 的前缀复用它希望把一条请求的完整路径都优化到。两者解决的问题有重叠但侧重点不同。更准确地说vLLM 适合那些需要稳定高吞吐、团队对改动迁移成本敏感的场景SGLang 适合那些有大量共享上下文、对结构化输出有强需求、且愿意跟着迭代节奏走的场景。需要提醒的是网上很多“SGLang 比 vLLM 快多少”的说法往往只针对特定模型和特定提示词分布。换一个 workload结果可能反转。框架选型最忌只看一两个 benchmark。实际落地时瓶颈经常不在框架本身而在数据、模型、超参数和调用方的行为。1.3 浪漫的落点把模型变成一件“可交付的产品”聊到 xAI 的时候我们其实没有把 xAI 当成某个具体产品的代名词而是把它当作一个信号当集群规模大到一定程度推理基础设施的优化空间会变得非常可观。SGLang 经常出现在这类讨论里不是因为它属于某家公司而是因为它的设计恰好踩中了大规模推理服务最吃力的地方——共享前缀、复杂调度、高并发、结构化输出。这也回到了“浪漫”这个词上。Infra 工程师写下的每一行调度逻辑最终结果不是让某个模型变得更快而是让其他人调用模型时不用关心显存怎么分配、前缀缓存怎么设计、状态机怎么约束输出。把复杂度留在系统内部把简单留给使用者这才是 AI Infra 最像浪漫的地方。它不像应用层那样一眼能看到界面效果但它决定了上层应用能不能稳定跑在千万用户面前。2. 别急着站队SGLang 和 vLLM 最适合去看“匹配度”2.1 一个最小可运行的 SGLang 部署示例不管项目口碑多好第一次上手都应该从最小可运行流程开始。假设你已经有一台带 NVIDIA GPU 的机器显存至少能容纳目标模型的量化版本先确认 Docker 和 GPU driver 已经就绪。然后拉取官方镜像启动服务。下面是一个示例结构具体镜像名和 tag 以你使用的仓库 README 为准docker run --gpus all \ -p 30000:30000 \ -v /models:/models \ sglang-image:tag \ python3 -m sglang.launch_server \ --model-path /models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 30000 \ --tp-size 1 \ --mem-fraction-static 0.8这里面sglang-image:tag是占位符实际部署时要替换成官方仓库里的镜像名和固定版本。不要直接复制命令就跑尤其要确认模型路径是不是挂载进了容器。模型路径不对启动日志通常都会报错但有时候会卡很久才失败所以先确认路径和权限是最高效的一步。服务起来之后可以用 OpenAI 兼容接口测试from openai import OpenAI client OpenAI( base_urlhttp://localhost:30000/v1, api_keyEMPTY, ) resp client.chat.completions.create( modeldefault, messages[ {role: user, content: 请用一句话解释 KV Cache 是什么} ], temperature0.7, ) print(resp.choices[0].message.content)如果能看到正常回答说明最小链路已经打通。接下来才考虑量化、并发、prefix caching 等优化。这也是我每次做推理框架验证时都会坚持的顺序先跑通再调优。2.2 参数不是越多越好几个关键参数的真实含义SGLang 启动参数很多但新手不需要全部理解。先掌握几个关键项就够了--model-path指向模型权重所在目录。如果模型是从 Hugging Face 下载的通常是包含config.json、tokenizer.json的那一层目录如果用本地路径要确认目录权限和 Docker 挂载是否正确。--tp-size张量并行度。单卡设 1多卡按 GPU 数设置。但tp-size不是越大越好卡间通信会带来额外开销。--mem-fraction-static给 KV Cache 预留的静态显存比例。设得太高模型加载后剩余显存不足设得太低并发上来时容易被拒绝。--max-running-requests同时运行的请求数影响吞吐和排队延迟。--enable-prefix-caching开启前缀缓存。对聊天、Agent 等有大量重复上下文的场景很关键。--max-new-tokens限制单次生成的最大 token 数避免异常请求把显存拖垮。避坑提醒不要一上来就把并发数和显存比例拉满。先用一条样例确认输入、输出和日志都正常再逐步加压。很多服务一启动就 OOM不是模型太大而是显存预留比例和并发配置太激进。2.3 一张表帮你做选型判断网上关于 SGLang 和 vLLM 的争论很多但选型本质是匹配度问题。可以用下面这张表作为初始判断判断维度更倾向 SGLang更倾向 vLLM备注请求是否高度复用前缀是聊天历史、系统提示词、工具描述多一般前缀缓存收益在共享上下文场景里更明显对结构化输出的强约束更合适能把 JSON Schema 编译进状态机相对弱一些如果接口依赖强约束建议实际测一遍团队是否需要稳定长期维护看版本节奏和发布公告通常更稳文档和样本更多结合团队维护能力判断是否需要大量自定义改代码学习曲线更陡社区讨论更多踩坑经验好找用真实 workload 验证部署环境是否敏感都支持 Docker都支持 Docker关键是固定镜像 tag 和记录参数这张表不是绝对结论。真正的答案是在一个和你业务相近的测试集上跑一遍看延迟、吞吐、显存占用和稳定性。如果两个框架差别不大优先选团队维护成本更低、社区更活跃的那个。3. 开源平权能力被稀释但门槛没有消失3.1 为什么开源是 AI Infra 的“平权”力量在 SGLang、vLLM 这类项目出现之前一个普通团队想自己做推理优化通常要从零处理显存分配、调度策略、批处理逻辑。这些能力被少数公司和研究者掌握普通使用者只能调用外部 API很难深入理解系统也很难根据自己的场景调整。开源改变的是这一点最核心的推理引擎代码公开在代码托管平台上任何人可以下载、运行、修改、学习。这是一种“平权”但不是简单的“免费”。使用开源项目仍然需要投入时间。搭环境、跑通样例、理解参数、排查问题、跟踪上游版本每一件事都有成本。开源把门槛从“造不出轮子”变成了“会不会用车”。后者依然需要学习只是学习曲线远比前者短。这也解释了为什么很多团队虽然不自己做推理框架但会花精力去读 SGLang 或 vLLM 的核心源码不是为了炫耀而是为了在出问题时能判断是参数问题、代码问题还是我们自己理解错了。3.2 开源项目的“甄嬛传”治理、路线和话语权聊到这里盛颖换了语气开源社区从来不只有代码还有人。一个项目一旦被大量使用就必然面对治理问题。谁来合并代码谁来决定 Roadmap是个人维护者主导还是基金会、公司参与治理商业化版本和开源版本如何区分这些问题处理不好就会演化成“甄嬛传”。常见的情况包括为了抢功能发布时间主干分支不断变化外部贡献者的 PR 长时间悬空团队内部对“激进重构”和“稳定兼容”产生分歧于是项目分叉公司接手后许可证、品牌、社区归属产生摇摆让下游使用者不安核心维护者离开项目迭代速度明显下降Issue 堆成山。这些现象不是某个项目独有而是开源项目进入成熟期必然会遇到的组织张力。对使用者来说“甄嬛传”不是茶余饭后的话题而是风险因素。你选择依赖的框架可能今天很火明天因为治理变化导致方向调整。因此在把某个开源项目写进生产架构前不要只看 star 数和 benchmark还要看它的治理模式、发布节奏、贡献者来源、Issue 响应速度和许可证变化历史。3.3 使用开源项目时先看许可证和社区健康度许可证是一个经常被忽略但非常关键的点。宽松许可证像 Apache-2.0、MIT通常允许你自由使用、修改、再分发甚至用于闭源商业产品或服务而 Copyleft 类许可证要求衍生作品以相同方式开源对某些商业场景会带来额外的合规义务。SGLang 和 vLLM 的具体许可证是什么请以仓库 LICENSE 文件为准不要凭印象。开源项目改许可证在业界也不是新鲜事。下游团队最怕的不是许可证收紧而是“突然变化”导致自己没有任何缓冲时间。提醒在看代码之前先看 LICENSE、CONTRIBUTING 和最近的 release notes。这三个文件能帮你判断“这个项目能不能用、怎么参与、会不会频繁破坏兼容性”。社区健康度可以用一个简单清单判断最近一个月有没有合并 PRReview 速度是否正常Issue 是否有人回复还是长期无人问津Release 是否按节奏发布版本描述是否清晰维护者来自个人、公司还是基金会文档是否完整是否有足够测试覆盖README 里的示例是否真的能跑通。不用非常复杂花半小时翻一下代码仓库的 Pulse 页面和 Issue 列表就能对项目状态有个初步体感。4. 从单次跑通到生产级部署一个可复用的“四步排查法”4.1 第一步确认输入输出边界部署推理服务失败时先不要急着调参数。首先要确认输入输出边界模型路径是否存在文件权限是否足够模型目录是否真的包含了config.json和 tokenizer 文件启动命令中的模型名是否和内部结构匹配调用接口时prompt 格式、role 字段、context 长度是否超限。很多“服务起不来”的问题其实只是路径写错或模型格式不匹配。先把这些基础项确认完再去看日志。4.2 第二步检查环境与依赖输入没问题再看环境。GPU 驱动是否被容器识别NVIDIA Container Toolkit 是否安装CUDA 版本和镜像是否兼容端口有没有被占用磁盘空间是否足够放模型和临时缓存。如果你把模型放在外部磁盘或网络挂载目录还要额外确认 I/O 延迟否则首次加载模型可能会非常慢甚至读取超时。容器里用nvidia-smi看 GPU 状态用df -h看磁盘用ss -lntp看端口占用都是一些常规但很有效的检查方式。4.3 第三步控制并发与显存参数环境正常但服务跑得慢、频繁 OOM问题大多出在参数。--mem-fraction-static调低一些给模型权重和激活值更多余量--max-running-requests调低先观察单请求延迟--max-new-tokens根据业务实际生成长度设置一个上限。并发参数应该从保守值开始逐步加压而不是一开始就设成理论最大值。压测时监控显存利用率和服务日志能更清楚瓶颈在显存、CPU 还是网络。这里有一个很容易犯的错误拿一条很短的 prompt 压测然后把并发拉满看似吞吐很高一换成真实的长上下文请求服务立刻进入排队状态。4.4 第四步识别工具边界与版本差异如果参数和环境都正常仍然出现诡异行为就要考虑工具边界。SGLang 和 vLLM 的 API 虽然都兼容 OpenAI Chat Completions但具体字段、流式返回、tool call 的细节可能存在差异。上游版本更新后行为也可能变化比如某个参数被废弃、默认值改变。遇到这种情况先翻阅当前版本的 release notes 和 GitHub Issues看看是不是已知缺陷。不要为了绕过问题写一堆 hack先确认是不是版本问题。很多时候升级或降级一个小版本问题就消失了。4.5 长期运行的工程化清单单次跑通和生产级稳定运行是两件事。生产环境需要固定镜像 tag不能一直用latest配置健康检查定期探测/health或类似端点收集日志、请求数、错误率、显存占用、首字延迟等指标设置容器崩溃后的自动重启和资源限制准备一个简单的灰度流程新镜像先在少量流量上验证再逐步放量。这个清单比调某个参数更重要因为框架可以换但稳定的交付流程会一直复用。5. 真正值得长期积累的不是参数而是判断力5.1 先跑通、再压测、再工程化如果只让我保留一条经验就是先跑通再压测再工程化。这一顺序几乎适用于所有推理框架、模型服务和开源中间件。先跑通是为了确认路径正确压测是为了找出性能边界工程化是为了让服务能长期运行。很多人一上来就看 benchmark、抄参数结果部署在自己环境里完全不是一回事。浪费时间的不是调参而是对着一个还没跑通的环境反复试错。5.2 选择模型和框架之前先问自己的 workloadSGLang 和 vLLM 之争最终会回到你的实际 workload请求是不是共享上下文用户能不能接受首字延迟高一点但吞吐更高团队有没有精力跟踪快速迭代的版本这个框架的核心作者和社区治理是否稳定如果上游突然换许可证你能不能承受迁移成本这些问题的答案决定你该选哪个框架、该用什么配置也决定你要不要自己维护一套分支。我们比较一致的看法是开源平权让少数人掌握的能力变得可复制但真正的壁垒会慢慢回到你对系统的理解。这也是整场聊天最想表达的部分。AI Infra 的浪漫不在于某个框架的跑分而在于让复杂系统变成一个稳定、可控、可复用的服务开源让这条路径变得开放但开放世界的规则更复杂。先建立自己的判断流程再选择工具比永远追着最新特性跑更重要。