企业官网建设流程全解析

1. 为什么 AI 基础设施开源论坛值得单独被提出来

1.1 模型竞争的下半场，比的其实是底座

这一年里，你随便问一个做 AI 应用的朋友，他大概率会跟你抱怨两件事：一是模型迭代太快跟不上，二是底层资源不够稳。前者还能靠多盯几个版本缓解，后者才是真正让人头疼的地方。

早期做大模型，大家拼的是谁的算法更新、谁的评测分数刷得高；到了现在，模型本身反而是最"公开"的——开源权重可以直接下载，商业模型可以通过 API 调用，真正能拉开团队间差距的，反而是那些不直接产生模型参数、但决定模型能不能稳定跑起来的底层能力。算力调度、训练框架、推理服务、数据管道、监控可观测性、模型生命周期管理，差不多是这几块。它们有一个共同点：平时不出问题你感觉不到它们的存在，一出问题就是连锁反应。

我见过好几个团队，模型辛辛苦苦调了一个月，上线当天推理服务扛不住峰值流量，接口大面积超时，最后只能紧急改成限流排队，用户体验一落千丈。你说这是模型的错吗？不是，是基础设施没到位。还有的团队训练任务跑了两天，一个节点故障，整个作业断了，checkpoint 还是三个小时之前存的，白白浪费几十卡时。这些事情写出来不 fancy，但每天都在 AI 公司里反复上演。

1.2 开源在 AI 基建里的位置，为什么天然合适

基础设施有一个天然属性：它需要很多人长期投入去打磨，最佳实践不能只靠一两个团队闭门造车。拿 GPU 调度来说，不同公司的场景可能千差万别，但基础的队列、优先级、抢占、配额这些逻辑是通用的。与其每个公司从零实现一套，不如把公共部分放到开源社区，让一批团队在真实生产环境里把坑踩平，剩下的人直接站在上面做事。

开源还有一个特别实际的好处，就是避免绑定。你选了一套私有化的底层平台，短期看是省事，但后面每一次升级、每一个新硬件的适配、每一个新的 AI 框架的支持，可能都要看厂商的节奏。开源项目虽然也要跟着社区节奏走，但代码、接口、扩展点都在你手里，真遇到问题可以自己动手解决。这个自由度在 AI 这种天天变的环境里太重要了。

所以看到 COSCon'25 把"AI 基础设施开源论坛"单独成场，我没有觉得意外，反而觉得这个时间点刚刚好。开源 AI 基础设施这两年积累了大量真实场景、工程经验甚至惨痛教训，确实值得拿出来认真聊一聊。作为长期泡在开源和 AI 工程里的人，这个议程我从发布那天开始就在关注，后面几节就按我看到的内容，聊聊这个领域最值得关注的技术主线。

2. 论坛议程公布之后，我看到的几条关键主线

2.1 从算力到应用，一条完整的纵向链路

先说明一下，我下面的叙述基于当前公开的议程框架，最终内容以现场活动为准。不过光看这个大框架，它的野心已经很明显了，基本是把 AI 基础设施这一整条链路都盖上了。

我梳理了一下，整个论坛的内容大致可以归纳成三个板块：

• 集群与算力层：大规模 GPU 集群的调度与资源管理，包括 Kubernetes 生态、调度器扩展、资源配额、多租户隔离，解决的是"算力怎么分、怎么排队、怎么不浪费"。
• 训练与推理层：分布式训练、微调管线、推理加速、模型服务化，解决的是"模型怎么快速上线、上线后怎么稳住"。
• 数据与治理层：数据集构建与管理、向量检索、模型可观测性、开源协议与社区治理，解决的是"底层数据怎么管、系统怎么监控、项目怎么长期演进"。

这个结构合理的地方在于，它没有把"基础设施"狭隘地理解成"机房里的服务器和网络"，而是往上涵盖了从训练到服务、再到数据治理的全过程。现在的 AI 系统本质上就是一个软件系统，软件生命周期里的版本管理、监控告警、弹性伸缩、故障恢复，它一样都躲不掉，这些都是基础设施的范畴。

2.2 更重工程验证，而不是概念重复

这几年各种 AI 技术大会其实不少，但有些主题演讲容易落入套路：前半场都是趋势、概念、蓝图，后面匆匆忙忙放两个 demo 就结束了。这次仅从论坛选题来看，明显更偏向工程落地。

它关心的是这些具体问题：你的集群里配额是怎么分配的，用哪类调度策略；分布式训练在节点故障时，整体恢复时间预期是多少；推理引擎在并发 1000 时，延迟和吞吐的平衡怎么打；训练数据集的版本管理是放在对象存储里还是单独搭一套服务。这些问题听起来不酷，但只要真正上线过，就知道每一个都是一场恶战。

它还专门留了空间讨论开源项目怎么活下去这个"不性感但要命"的话题。开源代码放出来只是第一步，社区怎么治理、许可证怎么选、商业模式怎么闭环，这些决定了项目能不能长期发展。对正在做技术选型的团队来说，这种信息比任何 benchmark 都值钱。

2.3 不同角色的读者，分别能挖到什么

你可能会问，我又不开发底层框架，去看这种论坛有意思吗？我觉得分两类人，收获是完全不同的。

对普通应用开发者来说，值得关注的不是"怎么写"，而是"怎么用"。现在做 AI 应用，十有八九绕不开 RAG、向量数据库、模型网关这些组件，业务侧程序员也得懂选型逻辑。论坛现场讲到的工具、踩坑经验和边界条件，比你看一个月文档都管用。

对平台工程师来说，这个论坛基本就是同行交流会。大家的痛点高度一致：GPU 贵、算力碎、任务多、资源利用率低。平时一个人卡住的问题，在现场大概率能找到踩过更深的坑的人。这种密集的信息交换，是线上社区做不到的。

3. 算力调度：论坛里的头号话题

3.1 GPU 调度的难处到底在哪

GPU 和 CPU 最大的区别在于，它不是那么好"切"。CPU 核可以按线程比较均匀地划分，GPU 你会遇到显存、计算单元、NVLink 带宽、PCIe 拓扑一堆约束叠在一起的问题。一个任务不光是占多少张卡的问题，还涉及卡之间能不能走高速互联、显存够不够放模型、I/O 会不会抢带宽。

同时，集群里的工作负载形态又高度混杂：训练任务一跑就是几小时到几天，推理任务跟着线上流量波动，数据预处理任务瞬时占用大量 CPU 和内存，还有一堆定期跑的实验和评测任务。不同任务对资源的需求和容忍度完全不一样，一个调度器得同时处理好这些差异，难度一下子就上来了。

多团队共享也是一道坎。部门 A 的任务不能因为部门 B 上了个大作业就饿死，管理员得能设置配额、优先级，还要有合理的抢占和排队策略。真到了几十人共用几百张卡的规模，没有一个像样的调度层，纯靠人肉分配，谁也撑不住。

3.2 开源调度引擎的选型对比

目前开源生态里已经有好几套成熟的方案，我列一个简表，方便直接对照。

我的个人经验是，如果你们的集群已经重度使用 Kubernetes，而且跑的多数是 PyTorch/Spark 这类框架级任务，Volcano 是稳的选择；如果你离不开 Ray 的那套分布式计算接口，KubeRay 更顺手；如果资源分布在多个云厂商，又希望自动挑便宜的机器，SkyPilot 值得专门研究。选型最忌讳一上来全家桶，先确定你最大的 workload 是什么，再决定那把椅子最合适。

注意：调度器不是装完就完事的组件。它是一套规则系统，上线之后需要根据真实流量持续调参，比如队列的公平性权重、抢占触发条件、最大排队时间这些，都必须结合实际任务画像来配。

3.3 调度集群落地时容易被忽略的细节

很多团队在调度器上踩坑，不是选型选错，而是细节做少了。我挑几个最常见的。

第一是配额设计。生产环境里我推荐用"预留 + 弹性"的组合：每个团队或者项目有一个最低保障配额，保证日常任务不会被饿死；同时设置弹性上限，允许他们在集群空闲的时候临时用更多资源。这种做法看起来多了一层复杂度，但能避免大量排练焦虑。

第二是 GPU 共享与显存隔离。同一个物理 GPU 上跑多个小模型推理任务，可以大幅提高利用率。可一旦共享，显存和算力的隔离措施没做好，一个任务的显存溢出就能把整张卡一起搞挂。现在开源里比较常见的做法是通过 MIG 或者 vGPU 能力做隔离，配置的时候需要确认清楚是整卡调度还是细粒度切分。

第三是拓扑感知。很多分布式训练任务对跨节点通信带宽敏感，调度时需要考虑 GPU 之间是不是同一 NUMA 节点、是不是同一个 PCIe switch。调度器如果完全无视拓扑，任务性能可能衰减一半以上。这在网络侧看不太明显，要落到实际运行数字上才看得出来。

第四是排队可视化。别小看这个，我调研过很多集群，管理员最头疼的问题之一就是"用户来问我为什么我的任务还没跑"——没有一个排队面板，这些问题要解释几百遍。任务排队状态、预估剩余时间、优先级原因，这些信息透明化之后，团队摩擦直线下降。

4. 训练与推理：从"跑起来"到"跑得好"

4.1 分布式训练的工程化，不只是改几行代码

很多人以为分布式训练就是把代码从单机改成多机，PyTorch 里加几行 DDP 就行。实际上，真正的工程难点在数据、通信和容错这三块。

数据侧最常见的问题是数据加载跟不上 GPU 算力。你用 A100 训练，GPU 算得飞快，但 dataloader 还在从普通磁盘慢慢读，训练曲线就会出现周期性尖刺。解决办法不外乎几类：把数据集做成流式格式，压缩后放在高性能存储上，或者加大预取和缓存。别忽略数据预处理，很多时候训练跑到第 17 个小时才开始报错，源头是数据管道的 bug。

通信侧，大规模集群里跨节点通信占的比重非常夸张。模型并行、流水线并行、张量并行、序列并行，这些并行策略怎么组合、切分点在哪，直接决定通信量。工程上还会用到 bfloat16 混合精度、FlashAttention 这类省显存的手段，让同样一批卡能装下更大的模型和 batch，这些都是实打实降低训练成本的办法。

容错侧，断点续训是老生常谈，但真正做得好的团队并不多。大模型训练动辄几十天，节点故障几乎是必然事件。checkpoint 存得勤则 I/O 压力大，存得少则故障恢复丢太多进度。现在聚类上的趋势是分片异步 checkpoint，把保存和训练重叠起来，把恢复时间控制在分钟级。这个点论坛上有专门展开，我自己的看法是，恢复时间目标（RTO）和丢失窗口目标（RPO）必须在项目启动时就定清楚，不然上线后必后悔。

4.2 推理引擎的演进，值得单独讲透

推理是模型效果落地的最后一公里，也是成本最容易被低估的一公里。早期的推理服务方式是把几个请求拼在一起做 batch，简单粗暴，但一旦请求长短差异悬殊，GPU 利用率就会显著下降。后来社区意识到，与其等着攒满一个 batch 再跑，不如"来一个处理一个"，动态地把新请求插入运行中的 batch，这就是 continuous batching，现在已经是推理引擎的标配。

vLLM 提出的 PagedAttention 是另外一个里程碑。它把 KV Cache（模型推理时保存的中间计算结果）按页管理，像操作系统的虚拟内存一样，避免显存碎片和预分配浪费。配合连续批处理之后，同样一张卡上能够同时跑的请求数多了好几倍，这对吞吐量提升非常明显。再往后，SGLang 在结构化生成和前缀缓存上做了更多优化，TensorRT-LLM 则走的是 NVIDIA 深度优化路线，各家各有取舍。

理性来看，选推理引擎不能只看谁跑分高，要看你的场景是长文本为主还是高并发短交互为主，还要看社区的活跃度和遇到问题能不能找到人问。vLLM 综合表现确实强，但如果你在 NVIDIA 卡上做极致优化，TensorRT-LLM 的很多特性也是 vLLM 短期内追不上的。

4.3 模型网关与服务化：多模型时代的必备件

过去部署一个模型服务很简单，跑一个 API 就行；现在模型可能同时有十几个版本在线上，需要做灰度、切流、降级。模型网关在这时候就特别关键，它的职责不只是转发请求，还包括多模型路由、请求级限流熔断、语义缓存、成本统计和访问审计。

开源社区里 LiteLLM、BentoML、KServe 这些项目都在做类似的事。你把它理解成模型层的 API 网关就行：请求进来，网关根据路由规则决定打到哪个模型；如果某个模型超时或者挂了，自动 fallback 到另一个模型；相同语义的请求如果缓存命中，直接返回结果，不用再烧一遍 GPU 算力。

弹性伸缩这方面，我的经验是看两个指标，一是队列深度，二是 GPU 利用率。如果请求排队变长，说明服务能力不足，需要扩容；如果 GPU 利用率长期低于 30%，说明服务太闲，该缩容或者合并。现在很多团队开始用 scale-to-zero 策略，没有请求时把 Pod 缩到零，能省出不少成本，代价是要接受一定的冷启动延迟。这个延迟可不可以忍，纯看业务场景。

注意：模型网关上配置缓存要格外小心。LLM 的输出不确定性意味着语义缓存需要做嵌入相似度匹配，而不是简单的文本精确匹配。缓存命中率没做好的话，可能白白增加延迟，还不如不缓存。

5. 数据、可观测性与开源治理，一个都不能少

5.1 数据基础设施：最容易被低估的短板

数据是 AI 的半条命，但这半条命往往是被管得最随便的。很多团队的数据集还是散落在共享目录里，靠文件名区分版本。跑完一轮实验想复现结果，发现数据集已经被覆盖过三次，这种经历我想不少人都体会过。

数据基础设施至少要做三件事：版本化、质量校验、权限管理。版本化用来解决"这个模型到底是在哪份数据上训出来的"问题，DVC、lakeFS、Hugging Face Datasets 这些工具都在往这个方向做。质量校验用来保证喂养给模型的数据没有脏样本、重复样本和格式错误，这块需要把校验步骤嵌入数据导入管线里。权限管理则要确保敏感数据不会因为某个成员的失误流到训练任务里。

RAG 场景下还有一个容易被忽略的点，就是向量数据库的索引维护。文档更新之后，旧的向量要清理，新的向量要写入，索引要重训练，这些和数据管线的衔接不能靠人肉定时任务。现在开源向量数据库生态很活跃，Milvus、Qdrant、Chroma 各有侧重，关键不是选最火的，而是选能融进你现有技术栈的。

5.2 AI 系统的可观测性，不能靠出事以后再查

普通后端的可观测性大家已经很熟了，但 AI 系统的可观测性是多个层面叠在一起的：底层基础设施（GPU、网络、存储）、资源调度系统（队列、配额、等待时间）、推理服务（延迟、吞吐、显存）、模型本身（输出质量、漂移、成本），每一层都可能出问题。

我倾向于用 Prometheus + Grafana 搭基础监控，把 GPU 利用率、显存使用率、网络吞吐、服务延迟这些硬指标先拉起来。然后再加上一层 LLM 应用层的追踪，OpenTelemetry 生态现在也能支持生成式 AI 相关属性，配合 Langfuse 这类项目做 trace，能看到一次请求在哪个环节最耗时、token 花费是多少。这一步最大的意义是让成本透明化，我见过不少团队上了这套监控之后才发现，某些慢请求其实不是模型慢，而是网络代理在中间多跳了几层。

模型漂移的监控也应该纳入基建范围。同一个提示词，模型回答越来越不稳定，甚至出现明显质量下降，这不一定是你改了什么代码，可能是上游基础模型升级了，也可能是 embedding 更新了。这类变化不靠监控很难发现。

5.3 开源协议选择与社区健康度判断

聊开源 AI 基础设施，绕不开许可证。代码和模型权重是两回事，同一个项目里可能有 Apache-2.0 代码，同时模型的权重文件又带了额外的使用限制。很多团队只盯着"能不能免费下载"，忽略了商业场景下的合规风险，等产品上线了才发现某个组件的协议不兼容，这种返工成本是很高的。

选择使用某个开源项目时，建议至少看一眼三样东西：license 的商业友好性、项目最近半年的活跃度（commit 频率和 issue 响应速度）、社区治理结构（有没有明确的方向和维护者梯队）。这几个维度做完，风险就小了一半。

6. 参与开源 AI 基建项目的思路

6.1 哪些项目值得投入精力去拥抱

一个特别容易犯的错误是"看什么火就上什么"。AI 基础设施项目迭代极快，今天还挂在热榜上的 tomorrow 可能就没人维护了。我判断一个项目值不值得追，会先看三个点：

第一，架构有没有清晰的抽象边界。调度器不一定要和训练框架绑死，推理引擎不一定要和模型仓库耦合，设计上解耦的项目通常能活得久。

第二，是不是有真实的生产用户。GitHub Star 数量参考价值有限，真正该看的是仓库里有没有来自不同团队的 issue 和解决方案，有没有公司在生产环境里使用并回馈社区。

第三，云中立性和可移植性。一个只能在某个特定云环境里跑的项目，就算再快，我也不太敢把它作为核心依赖。反过来说，抽象层次够好、可以跑在任意 Kubernetes 集群上的项目，长期价值更大。

6.2 落地和贡献过程中，我比较受用的经验

如果你想在团队里落地开源 AI 基础设施，我的建议是"先用起来，再决定要不要改"。很多新人上来就想给核心调度器加特性，这是最难走的路。正确的姿势是先小范围试用，跑通一个完整的训练到推理链路，把使用体验记录下来，再对照文档去理解它的设计意图。等真正理解了边界，再通过修 bug、补文档、加测试这些低门槛的方式切入贡献，反而容易得到维护者的认真回应。

落地层面还有一个经验是"别追求完美架构"。我个人见过不少团队一开始就想着搞一个大而全的 AI 平台，结果做了一年，训练、推理、数据、监控全是半成品。反过来，如果先挑一个痛点最明显的环节，比如推理服务性能，用开源组件打通一个端到端最小闭环，再去逐步扩展，效果往往好得多。每个组织都一样：先解决一个具体的问题，再谈平台。

开源项目的长期维护，说到底是靠持续参与而非一次性贡献。国内团队这几年在核心项目里的身影越来越多，这个论坛本身就是个缩影。去现场听听维护者们的分享，哪怕是聊聊天，也能获得不少教科书里没有的信息。

7. 最后的闲话：准备好迎接"AI 基础设施即服务"的时代

我个人这几年一个很强的感受是，未来两年，做 AI 的人不会再纠结于"训模型还是调 API"这种二元选择，而是会把训练、微调、推理、RAG、监控当成一组标准化的服务能力来使用。开源基础设施在这中间扮演的角色，就像电力和自来水之于现代城市一样，越基础反而越重要。

回过头来再说说这次论坛：今天聊的算力调度、推理引擎、数据链路和可观测性，其实有一个共同的逻辑——开源社区正在把过去几年踩出来的工程经验，沉淀成一套可复用、可扩展的底座。对参与者和使用方来说，这个底座意味着你不用从零开始，也不必重复踩坑；对开源项目来说，更多人在生产环境里使用，意味着更多反馈、更多修复、更稳定的演进。这种双向赋能的循环，恰恰是开源最有价值的地方。

如果你也在做 AI 基础设施相关的选型或者自研，我的建议很朴素：多看看社区在发生什么，找一个你能上手的真实场景，把开源方案跑起来，感受一下它的边界。只有这样，当下一代技术浪潮来的时候，你才不是站在岸边的人。