首页 / 资讯中心 / 文章详情

COSCon‘25 AI基础设施开源论坛:大模型落地的底座与工程实践

COSCon‘25 AI基础设施开源论坛:大模型落地的底座与工程实践 ★ FEATURED ARTICLE
COSCon‘25的AI基础设施开源论坛议程放出来了。看到“筑牢AI基建底座”这个主题我第一反应是松了一口气——终于有个大会愿意把注意力从“某家大模型又刷榜了”挪开认认真真聊一聊那些让模型真正能跑起来、跑得起的“水电煤”了。做AI落地这一年多我越来越觉得模型能力是天花板但基础设施才是地板地板漏水的话天花板再高也没用。这篇文章不打算替组委会做官方转述而是从一个长期混迹开源社区、也实际在公司搭过AI基础设施的从业者视角把这份议程背后的技术逻辑、行业信号和可落地的选型思路拆开聊一聊。不管你是正在琢磨公司AI平台怎么搭的架构师还是想找方向切入开源社区的开发者这篇文章都能给你一些参考。1. AI基建开源为什么成了今年最不该错过的论坛板块1.1 模型的红利期正在被“底座”拖后腿过去一年大模型的能力迭代速度肉眼可见地放缓了但企业的落地需求反而更迫切了。问题出在哪我自己的体感是再强的模型扔进现有的技术架构里也跑不动。你想把模型接进业务首先得解决GPU从哪来、数据怎么清洗、推理服务怎么扛住高峰流量、Agent跑起来之后怎么管理和追踪这些事。这就像买了一辆跑车结果发现家门口的路全是坑。车本身好但路不行你还是只能按自行车的速度开。现在的AI落地就是这个状态——模型负责“上限”基础设施决定“下限”而大多数公司的“下限”低到让人想骂人。这也是为什么我看到“AI基础设施开源论坛”这个主题会特别有共鸣。它讨论的不再是“哪个模型更强”而是“模型之外的整个系统怎么搭”。从算力调度、数据管道、模型服务到Agent中间件本质上都是在修路。1.2 开源在这个环节里有不可替代的位置基础设施这个东西天然适合开源。原因不复杂我给你捋几条第一可审计。企业内部用AI处理业务数据你得知道每一层逻辑在干什么。闭源的基础设施是个黑盒出了问题你连排查的入口都找不到。开源的代码就放在那哪里不对看哪里这在合规和排障场景下几乎是刚需。第二可定制。每家公司的硬件环境、数据规模、业务场景都不一样通用商业方案很难完全贴合。开源项目允许你自己改调度策略、自己加数据源插件、自己写推理钩子这才是“底座”该有的弹性。第三生态效应。开源项目的生命力来自社区。你在用的时候踩了坑提了issue可能过两周修复就合并进主干了。这种“一群人给一个项目打工”的模式迭代速度是闭源产品很难追上的。所以我一直觉得AI基础设施这个赛道里开源不是情怀是最优解。论坛愿意把这么多开源项目和社区的人聚到一起本身就是行业走向成熟的信号。2. 议程主线拆解从算力到Agent五大板块在解决什么顺着论坛的核心议题走一遍其实能看到当前AI基础设施的几个主战场。我把它拆成五个方向对应着一条完整的AI系统链路。2.1 算力与调度把GPU当“水电”用第一个绕不开的方向是算力。现在稍微有点规模的公司手里多少都有几台GPU服务器。但真实的利用率一般惨不忍睹——有人跑训练占着卡有人跑推理要排队还有人GPU显存碎片化到没法用。纯粹买新卡解决不了问题反而增加了成本。今年论坛把算力调度放在靠前的位置我完全理解。核心思路就是把GPU从“物理设备”抽象成“可调度的资源池”通过容器化、任务排队、动态切分、弹性伸缩这些手段让每一张卡都被榨干。Kubernetes生态里的各种设备插件、共享GPU方案、任务调度器都是这个方向上的代表作。2.2 数据基础设施大模型的“原料车间”第二个方向是数据。大模型时代的数据基础设施跟传统数仓完全是两个物种。你要处理的不仅是结构化表格还有海量的非结构化文本、图片、音视频。数据要清洗、去重、打标、分块、向量化然后才能喂给模型。这个环节的工程量和复杂度往往被严重低估。很多团队模型调得挺溜最后发现效果上不去是数据脏、数据格式混乱、数据管线断了好几天没人发现。论坛专门把数据基建列为独立议题说明行业已经开始正视这个“看不见的短板”了。2.3 模型服务与推理从“能跑”到“跑得起”第三个方向是模型部署和推理。一年前大家关心的是“这个模型能不能跑起来”现在关心的是“跑一次要多少钱、延时多少、稳不稳定”。推理成本直接决定了AI功能能不能做成生意。这里面的技术细节非常多量化压缩、KV Cache优化、动态批处理、投机采样、GPU内存复用等等。开源社区在这块的密集创新其实比很多人想象中更激进。论坛上如果聊到推理框架选型、性能调优、成本分析这些话题建议重点听。2.4 Agent基础设施2025年增量最大的新战场第四个方向也是我个人最感兴趣的——Agent基础设施。说实话Agent这个词已经被说烂了但真正把Agent当基础设施来建设的项目还很少。所谓Agent基础设施指的是让Agent能稳定执行任务的底层能力记忆管理、工具调用、规划编排、事件循环、可观测性。这就像当年从“单机软件”走向“互联网服务”时突然冒出一大堆中间件一样。Agent要做的事越复杂底层就越需要一套标准化的支撑系统。论坛把Agent基建列进议程而且分量不轻我觉得这是今年最值得关注的增量板块。2.5 开发者平台与工程化打通最后一公里最后还有一块相对泛、但同样重要的内容——开发者平台和工程化实践。纯粹的技术组件解决的是“能不能用”而平台化解决的是“好不好用”。包括统一的开发接口、模型网关、提示词管理、评测体系、安全护栏、可观测性设计等等。这一层是连接底层基础设施和上层业务应用的桥梁。没有它就算你底下的调度、存储、推理都做得很好开发者也还是用不起来。很多公司喊了半年AI原生开发最后卡死在这一层就是因为“零件有了但没人组装成机床”。3. 哪些议题背后藏着真实的行业痛点光看议题名字可能觉得抽象我更想聊聊这些主题背后到底藏着什么行业痛点——你只有理解了痛点才知道为什么这些话题会被选进议程。3.1 算力调度热本质是“利用率焦虑”我见过不止一家公司GPU采购预算一年翻了三倍但业务部门还是天天喊卡不够。后来一查训练任务和推理任务抢资源峰值时排队低谷时闲置综合利用率连30%都不到。算力调度的本质就是解决这种“有钱买卡、没钱用好卡”的尴尬。我自己的经验是上调度系统之前先花两周把现有的任务类型、资源占用曲线、峰值分布摸清楚。很多人一上来就上K8s调度器结果发现连最基础的“谁在用卡”都说不清楚调度策略根本无从谈起。3.2 数据治理被低估反而最影响模型上限数据基建这门课上很多团队交的学费是最多的。有个做企业知识库的朋友跟我吐槽他们费了老大劲搞RAG最后检索结果总是不对。排查了两周发现源头是数据分块逻辑有问题——长文档被硬切语义断了短文档又没做上下文拼接检索出来全是碎片。这就是数据基础设施的典型痛点。它不像模型推理那样有炫酷的benchmark但它实打实决定模型输出的质量。论坛里但凡涉及数据清洗、质量管理、分块策略、向量化方案的内容都属于“看着不起眼、回去就能用”的干货。3.3 推理成本决定商业模式能不能成立推理成本这件事我讲个现实例子。之前帮一个团队评估AI客服方案他们选了个很大的模型效果确实好但平均一次对话的推理成本接近两毛钱。业务量一大这笔钱比客服人力还贵商业模型直接不成立。后来换了思路用小模型做大头大模型只处理疑难case配合量化部署和动态批处理成本降了80%以上。这个数字看起来很夸张但真的能做到。所以论坛涉及推理优化、模型压缩、混合部署的session本质上都是在教你怎么把“技术可行”变成“商业可行”。3.4 Agent基建是“开荒期”现在进场的回报率最高Agent基础设施还处在很早期的阶段标准没定、生态没成型大家各自为战。但恰恰是这种混沌期参与建设的回报率最高。你现在写一个工具调用协议、一套记忆管理方案可能就是未来事实标准的一部分或者至少能让你团队成为最早吃到红利的一批人。我最近在几个开源Agent框架的仓库里看issue明显感觉社区活跃度比半年前上了一个台阶。很多人已经不是“试着玩”而是真要把Agent接进生产环境了。一旦生产场景打开基础设施的需求会指数级增长。4. 从论坛走向落地自己搭开源AI基建栈的方法论论坛讲的是行业视野最终还是要回到自己的工作台。我结合这几年的实操聊一聊从零开始搭一套开源AI基建栈的方法论以及容易踩的坑。4.1 最小可用栈别一上来就搞集群新手最容易犯的错就是一上来就按社区最佳实践搭K8s集群、上GPU虚拟化、接一堆组件。我跟你说这么干基本活不过第一周复杂度直接把你淹没。我的建议是先搭一个“最小可用栈”一切从简模型服务先用一个单机推理服务把模型跑起来支持HTTP接口调用就够。数据准备先用脚本处理数据分块和向量化都写在同一个Python流程里。应用接入直接写代码调模型接口不引入额外的网关或中间件。这个阶段的目标只有一个——把端到端的链路跑通。哪怕很糙哪怕并发就几个都没关系。你至少要亲眼看到数据从源头进去向量化之后存进向量库用户提问之后能从库里检索出内容喂给模型之后返回答案。链路通不通比链路好不好重要一万倍。4.2 从单机到多机的演变路径链路通了之后才开始往“基础设施”的方向演进。这一步我建议按三个维度逐步做第一维度是稳定性。模型服务要扛住并发就得加自动扩缩容、负载均衡、健康检查。数据管线要定时跑就得加任务编排、异常重试、失败告警。第二维度是资源效率。模型部署开始吃紧的时候再引入共享GPU、动态批处理和推理优化。按照这个顺序走每一步都有明确的目标不会为了技术而技术。第三维度才是平台化。当团队里超过五个人都要用这套东西的时候再去考虑统一的开发接口、模型网关、权限管理和可观测平台。我自己踩过的坑是跳过了第二维度直接上平台化结果底层的资源利用率问题没解决平台做得再漂亮也是空架子最后还是回来补课。4.3 选型时我自己的四步判断框架面对开源社区里五花八门的项目选型是一道送命题。我自己的判断框架很简单就四步第一步看社区活跃度。不是看star数而是看近期commit频率和issue响应速度。star是可以刷的但issue里的对话造不了假。两周没人回issue的项目再炫也不要用。第二步看核心维护者背景。项目背后是个人、小团队还是基金会维护者的稳定性直接决定了这个项目能不能走完概念期。我吃过项目突然停更的亏从此特别看重治理结构。第三步看脱离核心场景的依赖程度。项目是不是深度绑定某家云厂商是不是必须搭配某个商业产品才能用绑定越深你未来的话语权越弱。第四步看自己的团队技能树。再好的项目如果你们团队没人会运维它依赖的底层组件都得现学那成本就太高了。选一个团队能驾驭的项目比选一个“最好的”项目落地成功率高出好几倍。这四个判断框架帮我避过不少雷。你在论坛上听到什么新项目也别急着上头先用这四步过一遍再说。5. 我在实操中踩过的坑和排查手册下面是干货部分。我把过去一年多实操中反复遇到的几类问题加上排查思路整理出来当个速查手册用。5.1 GPU“显存黑洞”与资源碎片问题现象监控显示GPU利用率很高但业务吞吐量上不去任务还时常OOM。排查思路先用nvidia-smi dmon看实时显存占用确认是哪个进程在吃显存。再看是不是模型加载时把KV Cache留了过大余量导致显存预留大于实际需求。检查是否开了动态批处理continuous batching没开的话小请求也会占满整块显存。我遇到最典型的情况是为了追求低时延把最大批处理限制设得很小结果显存碎片化严重明明总量够但放不下一个大请求。后来改成动态批处理显存池化同样的卡吞吐直接翻倍。5.2 数据管线的隐性Bug现象RAG效果时好时坏有时候检索结果跟问题完全对不上。最经典的坑有三个第一数据增量更新时旧版本向量没删干净导致同一份内容检索出来两个版本第二分块没有保留父文档ID召回片段后回源拿不到全文上下文第三Embedding模型在数据入库和查询时被无意中换掉了向量空间不一致相似度全是噪音。排查方法拿着一个已知的好问题把检索链路一步步打印出来从query向量化、向量召回、重排到上下文拼接每一步都输出中间结果一眼就能看出哪一步坏了。这个排查脚本我建议每个做RAG的团队都写一份太值了。5.3 模型服务时延抖动现象P95时延忽高忽低高峰期甚至出现超时。排查思路先区分是计算瓶颈还是IO瓶颈。看GPU利用率和CPU使用率的比值如果GPU没吃满但CPU爆了多半是预处理或tokenize环节卡住了。再看是不是锁竞争。并发高的时候Python的GIL、模型推理框架的批处理队列锁都可能成为时延抖动的原因。最后看网络。模型服务和调用方不在同一个可用区时跨机房调用的网络延迟波动经常被当成服务问题排查。我个人的经验是模型服务一定要留出充足的并发缓冲更重要的是一定要做端到端的链路追踪。不然一旦时延抖动你连是哪一段慢的都不知道只能瞎猜。5.4 Agent链路的不确定性处理现象Agent跑着跑着就开始“胡言乱语”或者卡在一个工具调用里出不来甚至出现循环调用。Agent跟传统API服务最大的区别是不确定性。你不能拿测普通接口的老办法来测Agent。我自己沉淀了一套最小必要手段所有工具调用必须有超时和重试上限必须有步骤追踪日志把每次LLM输入输出、工具调用的参数和结果都记录下来必须有预算护栏比如单次任务最多调多少次LLM、多少token超了就强制终止。这三板斧看起来简陋但能拦住95%的线上事故。等这套机制跑稳了再上更复杂的评测、护栏和记忆管理。6. 现在入场普通人还能做什么最后聊点实际的。作为一个普通开发者如果现在想跟上这波AI基础设施开源浪潮从哪里切入性价比最高6.1 不建议卷的方向我不建议新入场者一上来就去卷大模型本身。模型训练已经被头部玩家牢牢把持算力门槛、数据门槛、人才门槛都是天花板级别。也不建议卷那种需要大量专家知识的底层框架源码比如去啃GPU通信库那个领域圈子已经非常封闭了。6.2 值得投入的方向与社区玩法我比较看好的切入方向是几个“新且杂”的中间层Agent框架与工具生态协议设计、插件机制、可观测性这些领域还在“百家争鸣”阶段普通人能用较低门槛做出贡献RAG与数据工具链分块策略、文档解析、评测基准这些环节跟业务贴近又极度缺乏标准推理服务的部署与调优实践哪怕只是写一些部署踩坑心得、性能对比文档对社区的价值都非常大。千万别小看文档和测试的贡献。很多开源项目的文档烂到影响使用你要是能主动补文档、写教程、做benchmark维护者会把你当宝。我当年进开源社区就是从“给一个项目补充中文文档”开始的一路做到了核心贡献者。6.3 一个务实的参与路径想长期留在开源AI基建圈子我的建议很直接选一个你实际工作中在用的开源项目长期跟进从提交issue开始然后提交小代码修复再然后认领一个模块持续积累。不用贪多一年深耕透一个项目你的成长速度远超那种每礼拜换个项目刷存在感的人。参与开源最大的回报不是简历上多一行字而是你被迫去读懂那些比你水平高的人写的代码理解他们为什么那么设计调度策略、为什么那样处理并发、为什么这样设计API。这种东西在短视频和技术速成课里永远学不到。我个人在实际操作中的体会是AI基础设施这个领域光靠看文章是没法积累真正的判断力的。论坛是给你指方向的但路还得自己走。挑一个你正在头疼的基建问题找一个对应的开源项目把它用起来、拆开看、动手改踩过几个坑之后你对整个行业的理解会完全不一样。
阅读完成 · 觉得有帮助?
咨询建站