GPU虚拟化技术系列一:设备虚拟化基础
虚拟化基础虚拟化技术是云计算与 AIInfra 的基石,其本质是通过虚拟机监控器(VMM/Hypervisor) 这一软件抽象层,将物理硬件资源(CPU、内存、设备)抽象为多个隔离的虚拟环境,实现资源的高效复用与安全隔离。 要构建稳定、高效的虚拟化系统,需突破三大核心技术瓶颈:CPU 特权级隔离、内存地址转换嵌套、设备 I/O 性能损耗。本章将从这三大维度切入,系统解析虚拟化基础原理,为后续 GPU 虚拟化技术的深入分析铺垫底层逻辑。 CPU 虚拟化:解决特权指令的 “权限冲突”CPU 是虚拟化的核心内容,x86 架构的设计历史导致其天然存在 “特权指令未完全隔离” 的问题,这也是 CPU 虚拟化需要突破的首个关键卡点。 CPU虚拟化需要解决的问题:特权指令设计无法满足虚拟化权限隔离需求虚拟化要求实现 “双重权限隔离”: Hypervisor 必须运行在最高特权级(Ring 0),完全控制物理硬件 虚拟机中的客户操作系统(Guest OS)需运行在非特权级(Ring 1-3),其操作需经过 Hypervisor 的监管 然而,x86 架构在设计时未考虑虚拟化场景,早期的CPU存在 ...
eBPF入门与实践:深入解析Linux系统的可观测引擎
在Linux系统中,内核是“操作系统的核心”,负责管理硬件资源、进程调度、网络交互等核心功能。但长期以来,内核的可编程性一直是个难题——如果想自定义内核行为(比如监控进程、过滤网络包),传统方式要么依赖内核模块(风险高、兼容性差,内核模块加载后拥有与内核相同的权限,错误的代码可能导致系统崩溃或安全漏洞。),要么只能修改内核源码重新编译(成本极高)。 eBPF(extended Berkeley Packet Filter)的出现彻底改变了这一局面。它是一种运行在Linux内核中的动态追踪与可编程技术,允许用户在不修改内核源码、不重启系统的情况下,安全地向内核注入自定义逻辑,实现对系统行为的细粒度观测、控制与优化。 如今,eBPF已成为云原生、性能分析、网络安全等领域的“基础设施”,被Google、Facebook、Netflix等企业广泛用于生产环境,是理解和优化Linux系统的“瑞士军刀”。 eBPF是什么?eBPF起源于Linux网络子系统(最初用于数据包过滤),经过多年发展,已成为一套通用的内核可编程框架。简单来说,eBPF是一种“运行在内核中的安全沙箱”,允许用户编写小型程序并 ...
AI会取代程序员吗?
从去年用上WCA(Watsonx Code Assistant)起,到Copilot、Deepseek及智能终端工具Warp,使用AI编程助手快一年左右的时间了。亲眼见证了AI一步一步变强大的过程。作为一个从业十多年的老家伙,今天跟大家分享一下我对AI工具的一些看法。 AI会不会取代程序员?个人观点:不会。我觉得AI作为编程助手是AI和人类程序员合作的最好模式。为什么这么说呢?这是软件的本质和LLM(Large Language Model)的本质决定的。软件的本质是逻辑的产物。众所周知,计算机程序是由算术逻辑运算和流程控制语句等组成的。它具有幂等性,给定特定的输入就会100%得到确定的输出。所以程序员编写程序实际是在利用自己的逻辑思维加上计算机语言来解决问题。然而,LLM则是基于对海量数据的统计来根据上下文来猜测下一个词的概率。尽管它的能力越来越强,编写出正确的程序的概率也越来越大,但它永远具有不确定性,很有可能会一本正经的胡说八道(幻觉)。 其次,AI的创造能力远远不如人类,它是一个很好的、升级版的搜索引擎,它通过学习海量的代码掌握的编程范式远远超越了普通程序员,然而它却无法创造新 ...
Bug fix为什么不能先进Release分支再进主分支?
今天和同事争论为什么Bug fix不能先进release分支再进主分支,我只能干巴巴的回答这样做不优雅,不能先CD再CI。问了问大模型,发现AI确实比较擅长做以理服人的事,哪怕它是幻觉,都让你觉得好有道理的样子。 看看AI是怎么回答的: 这是个非常棒的问题!这触及了 Linux 内核开发流程的核心设计哲学:稳定分支的纯洁性和主线的权威性。 简单来说,稳定分支只接受经过主线验证的、最小化的、必需的修复。让修复先进稳定分支再进主线,违背了这个核心原则,并会带来一系列严重问题: 破坏“稳定分支”的“稳定”定义: 代码冻结: 当一个版本被标记为稳定分支(如 6.1.y)时,就意味着它的代码基础(除了必要的修复)是冻结的。不允许添加新功能或进行大的重构。 最小化变更: 进入稳定分支的唯一东西应该是针对已知问题的、经过主线充分验证的、尽可能小的修复。目标是最大程度地减少引入新问题的风险。 如果修复先进入稳定分支: 这个修复本身就是一个新的、未经主线充分验证的变更。它可能会引入新的、更严重的 Bug,或者与主线正在进行的其他开发产生冲突,从而直接破坏了稳定分支的稳定性。 绕过主线 ...
使用semantic-release和gitlab CI自动管理软件版本
在敏捷开发和DevOps实践中,持续集成与自动化发布已成为提升团队效率的关键。然而,传统手动管理软件版本的方式常面临诸多挑战:分支繁多导致版本追溯困难,人工更新版本号易出错,且变更日志的编写耗时耗力。尤其在多成员协作的项目中,版本兼容性管理不当可能引发“依赖地狱”,影响交付效率。 为解决这些问题,semantic-release应运而生。该工具通过分析符合规范的Git提交信息(如Angular Commit规范),自动遵循语义化版本(SemVer)规则升级版本号,并生成变更日志与Git标签,实现从代码提交到版本发布的端到端自动化。结合GitLab CI/CD,这一流程进一步无缝集成至持续交付管道:开发者只需推送代码至特定分支(如main),即可触发自动化版本发布、生成文档并推送至仓库,甚至通过插件扩展至npm包发布等场景。这种组合不仅减少了人为操作风险,还确保版本迭代透明可追溯,尤其适用于追求高效、规范化的敏捷团队。 语义化版本(Semantic Versioning)语义化版本控制规范(SemVer)是为软件版本号赋予明确含义的标准格式。其版本号采用X.Y.Z(主版本号.次版本号.修 ...
企业级Kubernetes离线部署指南
问题场景与需求分析1.1 核心挑战在隔离网络环境下构建企业级Kubernetes集群时面临三大挑战: 资源隔离:无法直接访问DockerHub、GitHub等公共资源库 安全合规:需通过私有镜像仓库(Harbor)实现镜像生命周期管理 生产级要求:需满足高可用架构、持久化存储、网络策略等企业特性 1.2 解决方案要点 跳板机设计:通过双网卡笔记本实现: 外网侧:下载RKE2二进制文件、Harbor安装包、依赖镜像 内网侧:搭建HTTP文件服务器同步资源 离线资源池: RKE2 v1.26.5+ 离线包 Harbor v2.7.0+ 离线安装包 预下载Kubernetes组件镜像(约300个) 网络规划: 架构设计与组件分布2.1 逻辑架构图 2.2 节点规格建议 角色类型 CPU 内存 磁盘 数量 网络要求 Server 4+ 8G+ 100GB+ x3 3 1Gbps 内网 Agent 8+ 16G+ 200GB+ N 10Gbps 内网 Harbor 4 8G 1TB 1 独立存储网络 关键配置与问题排查3.1 RKE2数据目录迁移修 ...
快速排序
今天面试快排竟然没有写出来,囧… 再练一遍。 123456789101112131415161718192021222324252627282930import randomdef quickSort(arr, left, right): if left >= right: return pivot = random.randint(left, right) arr[pivot], arr[right] = arr[right], arr[pivot] q = left p = left - 1 while q < right: if arr[q] < arr[right]: p += 1 arr[p], arr[q] = arr[q], arr[p] q += 1 p += 1 arr[p], arr[right] = arr[right], arr[p] quickSort(arr, left, p - 1) quick ...
Argo workflow v.s. Tekton
在云原生的世界里,持续集成/持续交付(CI/CD)工具起着至关重要的作用,Argo和Tekton作为两款备受瞩目的工具,各自具有独特的特点和优势。本文将从多个方面对它们进行详细对比,帮助大家更好地理解和选择适合自己项目的 CI/CD 解决方案。 Argo核心概念 Workflow: Workflow是Argo管理和调度的对象,用户可以通过UI和CLI提交一个Workflow让Argo去运行。一个Workflow作为Kubernetes CRD来实现。 Template:一个Workflow可以定义一个或者多个Template,通常会以Pod的形式来运行。入口template可以通过entrypoint来指定。 Template tags: 也称为Template variables。它由{{}}来分割并在运行时被替换为具体的值。 Template有两种类型,一种是Work,另外一种是Orchestrate。 Work类型的template有以下几种, 它们都会以Pod的形式来运行: container set允许Pod中运行多个容器. da ...
如何给云计算用户提供安全可靠的操作系统镜像
在云计算环境中,操作系统镜像作为用户创建云实例的基础模板,其安全性和可靠性直接影响着用户应用和数据的安全。一旦操作系统镜像存在安全漏洞,可能导致大规模的安全事件,如数据泄露、恶意软件传播等。因此,研究如何给云计算用户提供安全可靠的操作系统镜像具有极为重要的现实意义。 操作系统镜像的分类 云平台镜像(stock image):云平台镜像是指云计算平台官方提供的,经过平台定制化、验证过的操作系统镜像。由云平台负责镜像的生命周期管理。 用户自定义镜像(custom image):用户自定义的镜像通常保存了用户特定的配置,安装了特定的软件。由用户自己管理镜像的生命周期。 第三方镜像(catalog image):第三方镜像是指第三方的供应商提供的操作系统镜像,由第三方供应商负责管理镜像的生命周期,由云平台负责审核与验证。 操作系统镜像的生命周期 可用/已验证(Available):表示镜像可以正常用于创建虚拟机、裸金属实例。 已弃用(Deprecated):表示镜像的操作系统版本已经不是最新的稳定版本。 已淘汰(Obsolete):表示镜像的操作系统版本已经结束支持。 如何保证操作系统镜像 ...
2024云-AI-计算国际合作论坛要点小结
坚持开放、兼容与自主创新来应对技术封锁 推进算力国产化,2030年国产化算力占比要达到90%以上 互联网+ 正在转变为AI+ 人工智能从单模态向多模态发展 系统软件是制约我国AI发展的关键因素,智算的10种核心基础软件 并行系统:DeepSpeed, Megatron-LM, FairScale 编程框架:PyTorch 通信库:NCCL AI编译器:tvm 算子库:cuBLAS, cuDNN 编程语言:CUDA, oneAPI 调度器 内存管理 容错系统 存储系统 构建国产万卡集群很重要也很难 异构卡、异地卡训练效果不好 与通算中心相比,智算中心功率密度更大,负载波动更大,交付时间更短 智算云计算架构包括智算基础设施、智算平台层和智算服务层,贯穿安全与稳定性保障 大模型训练中,电力费用占比65%,缺算到缺电 云计算从通用计算到混合计算再到异构计算,从CPU池化到GPU、NPU、TPU、DPU池化 大模型浪潮下,企业更需要私有化部署保护数据主权 企业落地AI的三大困境 资源困境:算力烧钱、投资风险 模型困境:模型难选、难用 应用困境:数据缺失、应用效果差 ...







