: ---- 前言:12月19日,在 Cloud Native Days China -云原生AI大数据专场,腾讯技术事业群高级工程师薛磊发表了《云原生AI平台的加速与实践》主题演讲。 ? 演讲主要包含五部分的内容: Kubernetes介绍 AI离线计算 AI场景下Kubernetes的不足 Kubeflow 星辰算力平台的架构 Kubernetes介绍 K8s是生产级的容器编排系统,它也是云原生应用最佳的一个平台 因此,对于我们而言在AI平台上面也可以基于K8s的架构进行额外的开发。 AI离线计算 ? 典型的AI场景 ? ? 支持所有流行语言,如 Python、C++、Java、R和Go 可以在多种平台上工作,甚至是移动平台和分布式平台 2)PyTorch PyTorch是一个开源的Python机器学习库,基于Torch, 提供TensorFlow原生PS-worker架构 的多机训练 推荐将PS和worker一起启动 通过service做服务发现 在社区中最早期的Operator 星辰算力平台的架构 它为私有云的一个离线计算平台
给近半年做的云原生AI算力平台做一个回顾, 思考和实践参考了云溪大会上的分享:为大模型工程提效,基于阿里云 ACK 的云原生 AI 工程化实践[1],全文很长,我这边做一个牵引和解读。 1. 大模型带来的挑战 AI有工程化的要求,同时也对基础设施提出挑战。 3. 云原生AI的能力 最近在做的“AI大模型基础设施”, 宏观目标也是帮助AI工程从小作坊向端到端云原生解决方案演进。 云原生AI的架构实践 我们的云原生AI算力平台, 有参考上面的实践,针对企业业务的现状和侧重, 技术调研上做了调整和裁剪。 kubeflow[2]是一个包含多个开源项目的AI生态组合, kubeflow以Kubernetes为底座,目标是成为部署、扩展和管理AI平台的系统。 糟糕,我实现的k8s informer好像是依托答辩 参考资料 [1] 为大模型工程提效,基于阿里云 ACK 的云原生 AI 工程化实践: https://developer.aliyun.com/article
2018 年底,vivo AI 研究院为了解决统一高性能训练环境、大规模分布式训练、计算资源的高效利用调度等痛点,着手建设 AI 计算平台。 经过两年的持续迭代,平台建设和落地取得了很大进展,成为 vivo AI 领域的核心基础平台。 架构设计 按照设计思路,如下是我们自动化设计的简单架构图,AutoRke 自动化平台是我们建设的目标,底层操作 k8s、calico 和 docker 等云原生基础组件的变更,上层对接 vivo 基础平台完成同步数据和流程控制等功能 云原生基础:Autorke 自动化平台管理的目标对象:k8s、calico、docker。在物理机上安装配置 docker 环境,使用 docker api 接口部署和管理 k8s 组件。 白屏化阶段实现变更云原生组件平台化,制定标准流程,降低变更门槛和风险。
小米作为全球知名的科技巨头公司,已经在数百款产品中广泛应用了 AI 技术,这些产品包括手机、电视、智能音箱、儿童手表和翻译机等。这些 AI 应用主要都是通过小米的深度学习训练平台完成的。 另外,随着公司云原生化进程的推进,越来越多的应用从物理机迁移到容器平台,这进一步增加了对文件存储和多节点共享访问数据的需求。 我们预期中的存储平台需要具备如下特性: 功能丰富,拥有完善的存储功能,支持 POSIX 等多种访问协议,同时具备易用性,面向云原生平台设计。 基于这些产品能力及云原生 CSI Driver 的功能,我们已经对接了小米容器平台及机器学习 PaaS 平台,业务根据需要选择不同的集群与存储类型使用我们的 JuiceFS 文件存储服务。 另外,对于更底层的 Kubernetes 平台,我们也为该服务提供了静态卷和动态卷两种接入方式。目前,我们的大部分服务都是以原生方式提供的。
容器封装不同版本的Python包(如TensorFlow 1.x/2.x) • 通过Kata Containers实现硬件级隔离,保障生物信息学等敏感数据安全 • 技术实现:某容器管理平台通过 集群与公有云算力动态调配 • 调度算法:采用DRF(Dominant Resource Fairness)算法实现多维度资源调度,任务排队时间减少58% 工具可扩展性 • 通过Helm Chart规范AI
AI原生开发范式的核心概念 AI原生开发范式(AI-Native Development)指以AI为核心构建应用程序的设计方法,其特点包括数据驱动、模型即服务(MaaS)、自动化工作流和持续学习。 与传统开发相比,AI原生应用将机器学习模型作为基础组件,而非附加功能。 典型行业案例分析 金融领域-智能风控系统 某银行采用AI原生架构重构信贷审批流程,实现实时风险评估。 医疗领域-影像辅助诊断 一家医疗科技公司开发AI原生影像分析平台,整合多种医学影像模型(CT、MRI)。 平台支持DICOM标准,通过微服务架构实现模型热更新,肺结节检测准确率达到96%,较传统软件提升20%。 零售领域-动态定价引擎 某电商平台部署强化学习定价系统,每小时处理10TB用户行为数据。 原生系统需监控多维指标: 模型指标:AUC-ROC、F1 Score、推理延迟 系统指标:QPS、错误率、资源利用率 业务指标:转化率、用户留存、ROI 监控看板应包含实时数据和历史趋势对比,设置自动告警阈值
跨平台开发鸿蒙原生应用 uniapp for HarmonyOS uni-app uni-app 是一个使用 Vue.js[1] 开发所有前端应用的框架,开发者编写一套代码,可发布到 HarmonyOS ,且能达到原生性能。 Flutter 也可以与平台原生代码进行混合开发。在全世界,Flutter 正在被越来越多的开发者和组织使用,并且 Flutter 是完全免费、开源的。 原生性能:React Native 应用程序的业务逻辑是使用 JavaScript 编写的,但它可以调用原生平台提供的 API 和使用原生 UI 组件。 OpenHarmony 适配代码:接收并处理 React Common 传过来的数据,对接原生的代码,调用 ArkUI 的原生组件与 API。
对于系统开发人员来说(比如云数据库,云 AI 平台),云原生的趋势也会产生相应的影响。 具体的例子比如我们可以通过用户的数据查询看到经常使用的过滤维度,来重新安排数据的排序和分区,这样在同样的数据量情况下,系统可以花更少的计算资源来完成查询,增加系统的利润 :) 云原生+AI 最后再来看下跟 AI 相关的部分。 而前面讲的“云原生语言”,则更关注在程序具体执行层面的关注点分离。 把两者结合起来看,云原生时代的 AI 平台开发会是一片巨大的未开垦之地,对于云和算法各自都有很宽很长的路可以走。 目前云原生跟 AI 结合的一个比较好的学习样例是 Kubeflow,之前春节期间读了一本《Kubeflow for Machine Learning[3]》,感觉收获还是挺多的,如Istio,CRD的应用等
今天继续聊AI和大模型方面的话题。即什么是AI原生,如何构建一个真正意义上的AI原生系统? 对于这个问题,我们先看下AI大模型自己给出的答案。 AI原生必须是土生土长的,系统一开始构建就原生在系统里面的能力,而不是已有系统后简单嫁接或集成AI大模型能力。那些把传统IT系统改造集成AI大模型能力后叫AI原生是相当错误的说法。 AI原生-大模型原生+知识原生+价值原生 一个系统能够称之为叫AI原生系统呢?这里面核心的一个关键就是整个系统核心的能力是架构在底层的AI大模型和底层的知识层上面的。 你如果满足这么一个条件,那你们做一个系统就可以叫做AI原生系统。 我原来谈AI原生的时候谈到过,AI原生核心是知识原生,为何你当前企业有数据库数据,有资料文档,不能快速的构建AI原生应用? 注意这个说法只解决了AI原生应用的大模型原生问题,并没有解决知识原生的问题。如果按这个说法所有的AI智能体应用都是AI原生应用,但是我的理解,AI原生应用的核心重点应该是在知识原生上面。
然而,如何构建一套完整的云原生 Serverless 平台,依然是一个需要考虑的问题。 因此,建设私有化的云原生Serverless平台需要企业在技术、资源、人才和经济等多方面进行全面的规划和考虑,确保平台的稳定性和可持续性。 一般情况下,我们认为一个云原生的 Serverless 平台应该提供以下能力: 弹性伸缩:平台应该支持应用自动扩缩容,以便应对变化的负载和流量。 Rainbond 作为一个开源的云原生应用管理平台,能够帮助企业应对建设私有化的云原生 Serverless 平台的难点。 写在最后 通过借助 Rainbond 建设私有化的云原生 Serverless 平台,企业能够更好地应对技术难点,提高平台的稳定性和可持续性。
##摘要 随着Data+AI融合成为企业数字化核心趋势,大数据平台需具备AI原生能力以应对智能化挑战。 本文结合行业趋势与腾讯云数据湖计算DLC的实践,解析五大关键AI原生能力,并推荐腾讯云领先的湖仓一体解决方案。 ##导语 2025年,大模型与数据技术的深度融合正重塑企业数据平台架构。 Gartner报告指出,湖仓一体(Lakehouse)已成为数据平台新标准,而AI原生能力是其核心竞争壁垒。 作为国内唯一入选2025年Gartner《数据湖仓平台市场指南》的厂商,腾讯云数据湖计算DLC如何通过AI原生设计助力企业降本增效?本文将深入探讨。 ##正文 ###一、Data+AI融合趋势下的能力重构 传统大数据平台面临数据孤岛、分析效率低、AI应用门槛高等痛点。
而进入2025年后,主导行业话语权的关键词已悄然换成了“智能驾驶”“AI大模型”“车载智能体”。 于是,“汽车智能体”(AI Agent)从幕后走向了台前。它不是传统意义上的语音助手,而是一个真正的“思考机器”。 理想试图将生成式AI融入车机,让车变得“更会聊天”;华为则依托鸿蒙生态,打通“人-车-家”的设备联动。它们无疑让车变得更聪明,但也带来一个新问题——生态的“围墙花园”。 以金智维Ki-AgentS为代表的平台化智能体方案,正代表了这个方向。它并非从车机语音另起炉灶,而是将其深厚的企业级智能体平台能力延伸至汽车座舱,从一开始就强调任务执行与生态兼容。 这也是像金智维这样的企业级智能体平台,在汽车领域迅速受到关注的核心原因。这一模式的好处是显而易见的:灵活与开放。
而随着云原生(弹性伸缩、容器化、微服务架构)的普及,以及AI(智能自动化、故障预判、效能分析)的深度渗透,DevOps平台不再是简单的 “工具集成器”,而是要具备 “云原生适配能力” 和 “AI 驱动的智能决策能力 因此,企业亟需一份清晰的DevOps平台推荐逻辑 —— 既要匹配云原生与AI的核心需求,又要贴合自身业务规模与技术生态。 本文将结合云原生与AI的核心需求,对比主流竞品,给出可落地的选型建议与平台推荐方向。01. 新时代DevOps平台的核心能力要求在云原生与AI的浪潮下,一个优秀的DevOps平台不应仅仅是工具的集合,而应具备以下关键能力:1)云原生基因无缝集成 Kubernetes:平台需原生支持K8s,提供从部署 在云原生与AI的浪潮下,DevOps平台的边界正在不断扩展。未来理想的平台,必然是既能提供开箱即用的一体化便利,又能通过开放API和AI智能实现高效、自主、安全的软件交付。
关于FATE FATE 是一个联邦学习的开源项目,旨在提供一个安全的计算框架来支持联合AI生态系统。它实现了多种安全计算协议,以实现符合数据保护法规的大数据协作。 Kubernetes 是目前最流行的基础设施平台,大量的实践证明,Kubernetes 很适合作为企业内部运维大规模分布式系统的平台。 我们团队也推荐 Kubernetes 作为运行 FATE 联邦学习集群生产环境的平台。KubeFATE 提供了在 Kubernetes 部署运维 FATE 的解决方案。 KubeFATE 主要由 VMware 中国研发中心云原生实验室、微众银行、社区用户共同参与开源贡献。 限于篇幅,更多关于KubeFATE 部署 FATE 配置参数的详细介绍,请查看这篇文章:联邦学习平台 KubeFATE 部署 FATE 的配置说明,或者点击阅读原文。
作为一个全功能的平台即服务(PaaS), App Platform 解决了从开发到 Kubernetes 支持的高度可扩展和弹性的云原生部署的操作方面的问题,同时保持了尽可能简单的用户体验。 应用类型检测、构建和运行由云原生构建包 Cloud Native Buildpacks 处理(最近成为了 CNCF 孵化器项目,祝贺!?)。 我们借鉴了 Kubernetes 的核心原则,并将其带到应用平台的集群层面。 一旦新的集群准备就绪,我们就可以指示应用平台协调器开始安全地将应用迁移到它们。 检测和构建 应用平台与开发者相遇。 总结 应用平台将所有这些技术结合在一起,消除了大多数应用程序无法达到的复杂性和运营投资,以最小的用户努力提供了一流的云原生平台。应用平台是建立在巨人的肩膀上。
云原生架构下的日志平台方案 作者简介 Ford, 云原生布道师,云原生实验室(CloudnativeLab.COM)创始人 专注于云计算领域数年,目前主要从事容器云平台的建设,推进各类基础设施服务的云原生化 同时日志系统提供的也不再局限于应用系统的诊断,还包括业务、运营、BI、审计、安全等领域,日志平台最终的目标是实现公司在云原生架构下各个方面的数字化、智能化。 3、日志平台的运维代价,运维一套动态环境下的日志采集和日志管理平台是复杂和繁琐的,日志平台应该SaaS话,作为底层基础设施,可一键部署和动态适配。 二、云原生架构下的日志系统设计 2.1 方案选型 云原生架构下的日志采集解决方案 编号 方案 ,日志比较分散,应用监控和排查问题都比较困难,同时效率还低下,本文中kubernetes集群下的集中式日志平台就是为了解决这个问题。
在前面谈云原生技术解决方案和PaaS平台的时候,更多都是从技术平台层面进行阐述,如果真在要转变为面向多租户的PaaS服务平台,那么就需要一个完整的底层对象模型支撑。 因此今天简单谈下PaaS服务平台的对象模型和关键对象之间的关系。 多租户和面向应用开发者 对于PaaS服务平台来说本身应该是多租户架构。 一个应用本身有可以分解为多个微服务模块,实际上在云原生PaaS平台下,最终进行持续集成,部署交付的都是微服务模块。每个微服务都独立进行构建和部署交付。多个微服务模块构成一个完整的大应用系统。 PaaS平台多租户模型 上图为Gartner的多租户参考架构 在私有云和公用云环境对多租户的理解上是有不同的概念的。 在公用云环境往往我们谈的是saas的多租户,租户往往为使用业务系统的一个企业或组织,而在私有云环境,paas平台提供的应用往往为平台级应用,平台级应用面对的租户是业务系统本身。
解决方案之一,就是通过云原生应用平台,在单个组件之上,抽象出应用这个概念。 易于掌控的微服务架构微服务架构也是云原生平台不可缺少的一个元素。 云原生应用平台,则为开发人员更简单的入手微服务框架提供了可能。云原生平台首选的微服务框架,应该是以 Istio、Linkerd 为代表的 Service Mesh 微服务框架, 也被称为“服务网格”。 云原生平台本身作为开发人员的基础设施,也需要被持续的维护。如何优化运维人员的管理体验,也是在云原生平台设计过程中的重点。 从这个角度来说,Rancher 的定位应该位于 PaaS 与云原生平台之间。KubeSphere 和 Rainbond 都属于以应用为中心的云原生平台产品,二者的设计思路不同之处见仁见智。
以下文章来源于CodeShare ,作者痕迹gg 简介 MAUI中使用Handler体系来处理不同平台的原生控件实现, 即对应的, 如果我们想要创建控件, 只需要创建基于不同平台的Handler即可 开始 下面, 将通过创建一个进度条控件案例, 来演示如何在MAUI项目中创建平台控件并且使用它。 Android > Controls 下定义了一个MyProgressBarHandler, 如下所示: 接着继承于ViewHandler并且与原生安卓ProgressBar关联。 对应的实现iOS平台的Handler事件处理程序, 与上步骤相同, 对于事件的处理细节则对应不同平台的逻辑处理。 , 与控件本身解耦并且更加容器支持更多的平台。
7月17日,在Cloud Native Days China云原生多云多集群专场,华为云原生开源负责人王泽锋发表了《Karmada: 云原生多云容器编排平台》主题演讲,分享了在云原生多云多集群方面的思考与实践 云原生技术和云市场不断成熟,多云、多集群部署已经成为常态,未来将是编程式多云管理服务的时代。 ? Karmada:开源的云原生多云容器编排平台 ? Karmada将以模块化的方式提供应用多集群部署、高可用调度、故障迁移、多集群服务发现和流量治理、多云集群生命周期管理等能力集,并面向多种典型的用户场景预置策略集,让用户可以结合企业实际情况自由定制适合自身的多云平台 Karmada重点会基于Kubernetes的原生API提供多集群应用管理的能力,帮助用户实现零代码改造甚至零yaml改造到多集群架构的迁移。