近期看到一些关于传统基础设施（Traditional Infrastructure）与人工智能基础设施（AI Infrastructure，尤其大模型领域）差异的评论。其核心观点直指两者间的巨大鸿沟：许多精于网络、计算、存储等传统领域的工程师，在面对GPU集群、KV Cache管理、3D并行等全新概念时，常感过往经验难以直接套用，甚至产生踏入一个全然不同技术体系的“割裂感”。 这些看法颇具代表性，精准捕捉了工程师初探AI Infra时的普遍印象：陌生、高门槛、范式迥异。本文旨在分享我对此的一些初步思考：AI Infra究竟是颠覆传统的全新体系，抑或是既有Infra经验在智能时代的一次深度演化？ （免责声明：本文纯属个人观点，旨在抛砖引玉，欢迎指正谬误！） 我的核心论点：AI Infra并非平地起高楼，它实质上是传统Infra工程智慧在新场景下的重构与系统性延展。 表象差异：新术语与新挑战带来的“视觉冲击” 乍看之下，AI Infra与传统Infra确实分野明显： 核心任务不同： 传统Infra聚焦于处理海量Web请求（毫秒级、无状态）、保障数据持久化存储、实现分布式服务协调。而AI Infra（尤以大模型为甚）则围绕GPU驱动的模型训练/推理、KV Cache的高效管理、百亿/千亿级参数的分布式执行框架展开。 请求形态迥异： Web请求追求瞬时响应（毫秒级）、天然无状态。大模型（LLM）推理则常承载持续的会话交互（秒级乃至更长，随上下文窗口扩展而递增），需动态维护细粒度的Token级状态（KV Cache）。 技术栈迭代： 熟悉的Kubernetes + Docker堆栈旁，涌现出GPU硬件抽象、vLLM、DeepSpeed、FlashAttention、Triton、NCCL等专为AI设计、名号“高深”的组件。 由此观之，认为传统经验难以直接迁移，确有其表象依据。但这仅仅是“水面之上的冰山”，远非其底层基石。 本质共性：工程核心挑战的永恒回归 拨开“AI专属”的面纱，工程实践的核心命题依然如故：系统设计与资源调度的精妙艺术。 我们面临的，仍是那些传统Infra领域中反复锤炼的同类问题，只是约束条件和优化目标发生了变化： 资源调度： 核心资源从CPU/内存/磁盘IO，转向了更稀缺、更昂贵的GPU显存与算力。 负载处理： 承载对象从HTTP资源请求，变为密集的Prompt请求与大规模训练任务。 核心目标： 高效、稳定、低成本地协调跨节点资源的核心诉求丝毫未变。 概念的映射：经典范式的AI实践 这种延续性，清晰地体现在关键概念的对应关系上： 传统 Infra 概念 AI Infra 对应实践 核心思想应用 数据分片 (Data Sharding) 数据并行 (Data Parallelism) 数据集拆分，多副本并行处理 负载均衡 (Load Balancer) MoE Router (Mixture of Experts) 动态分配请求（Token）至专家网络，避免热点 操作系统分页 (OS Paging) vLLM KV Cache Paging 虚拟化显存空间，高效管理请求状态 以vLLM为例： 其核心创新在于将操作系统经典的内存管理机制（分页、交换），创造性地应用于管理LLM推理中关键的KV Cache状态。它如同为LLM定制了一个“显存操作系统”，管理“进程”（推理请求）和“内存页”（KV Cache Blocks），极致优化昂贵显存的利用率。这绝非凭空创造，而是经典系统原理在特定约束下的卓越应用。 ...

LaTeX 渲染测试 基础测试 行内公式：$E = mc^2$ 块级公式： $$E = mc^2$$复杂公式测试 原始问题公式1（更稳妥写法，拆成两条显示公式） $$ \mathbf{y} = f\left(\mathbf{x}\, \big[\,\mathbf{W}^{(A)}_1\; \mathbf{W}^{(A)}_2\; \cdots\; \mathbf{W}^{(A)}_n\,\big]\right) \begin{bmatrix} \mathbf{W}^{(B)}_1 \\ \mathbf{W}^{(B)}_2 \\ \vdots \\ \mathbf{W}^{(B)}_n \end{bmatrix} $$ $$ \mathbf{y} = \sum_{i=1}^n f\big(\mathbf{x}\mathbf{W}^{(A)}_i\big)\,\mathbf{W}^{(B)}_i $$ 其他常见LaTeX测试 分数和根号： $$\frac{\sqrt{x^2 + y^2}}{2}$$积分： $$\int_{-\infty}^{\infty} e^{-x^2} dx = \sqrt{\pi}$$矩阵（确保每行使用 \ 换行）： $$ \begin{pmatrix} a & b \\ c & d \end{pmatrix} \begin{bmatrix} x \\ y \end{bmatrix} = \begin{bmatrix} ax + by \\ cx + dy \end{bmatrix} $$ 求和和乘积： $$\sum_{i=1}^n i = \frac{n(n+1)}{2}$$$$\prod_{i=1}^n i = n!$$上下标组合： $x^{2^3}$, $x_{i_j}$, $x^{(a)}_{(b)}$ ...

本文旨在记录对中间件、编排组件容器化部署后，实现kubernetes扩展组件Controller的过程。 Third-Parties kubernetes-client: javascript client-go kube-rs client-go源码分析 目录结构 kubernetes: contains the clientset to access Kubernetes API. discovery: discover APIs supported by a Kubernetes API server. dynamic: contains a dynamic client that can perform generic operations on arbitrary Kubernetes API objects. transport: set up auth and start a connection. tools/cache: useful for writing controllers. informers: informer group listers: lister group 代码实例 1 2 3 4 git clone https://github.com/huweihuang/client-go.git cd client-go #保证本地HOME目录有配置kubernetes集群的配置文件 go run client-go.go client-go.go ...

注：如果对kubernetes的基本概念不太清楚，建议先过一下基本的资源类型再阅读此文 先随便给个例子: 1 2 3 4 5 6 7 8 9 10 apiVersion: v1 kind: ConfigMap metadata: name: test-config data: config.yml: |- start-message: 'Hello, World!' log-level: INFO bootstrap.yml: listen-address: '127.0.0.1:8080' 我们定义了一个ConfigMap，data中定义了两个文件config.yml以及bootstrap.yml，当我们要引用当中的配置的时候，kubernetes提供了两种方案： 使用configMapKeyRef引用configMap中某个文件的内容作为Pod中容器的环境变量。 把所有configMap中的文件写到一个临时目录，将临时目录作为volume挂载到容器中，也就是configmap类型的volume。 假设现在我们有一个Deployment，它的pod模板里引用了configMap，现在我们的目标是：当configmap更新的时候，这个Deployment的业务逻辑也能随之更新。那么有哪些方案？ 最好的情况是，当configMap发生变更时，直接进行hot update，做到不影响pod的正常运行。 如果无法hot update或者这样完成不了需求，就要出发对应的Deployment做一次滚动更新。 场景一： 针对可以进行热更新的容器，进行配置热更新 如果configMap由volume挂载，比如下述的投射卷，它的内容是可以更新的： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 apiVersion: v1 kind: Pod metadata: name: volume-test spec: containers: - name: container-test image: busybox volumeMounts: - name: all-in-one mountPath: "/projected-volume" readOnly: true volumes: - name: all-in-one projected: sources: - configMap: name: myconfigmap items: - key: config path: my-group/my-config 为了能够比较好得理解，先说明一下configMap的volume挂载机制： ...

资源模板 statefulset举例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 apiVersion: apps/v1beta1 kind: StatefulSet metadata: name: kubia spec: serviceName: kubia replicas: 2 template: metadata: labels: app: kubia spec: containers: - name: kubia image: derios/kubia ports: - name: http containerPort: 8080 volumeMounts: - name: data mountPath: /var/data volumeClaimTemplates: - metadata: name: data spec: resources: requests: storage: 1Mi accessModes: - ReadWriteOnce headless service举例 1 2 3 4 5 6 7 8 9 10 11 apiVersion: v1 kind: Service metadata: name: kubia spec: clusterIP: None selector: app: kubia ports: - name: http port: 80 storage class local PV 1 2 3 4 5 6 kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: local-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 apiVersion: apps/v1 kind: StatefulSet metadata: name: local-test spec: serviceName: "local-service" replicas: 3 selector: matchLabels: app: local-test template: metadata: labels: app: local-test spec: containers: - name: test-container image: k8s.gcr.io/busybox command: - "/bin/sh" args: - "-c" - "sleep 100000" volumeMounts: - name: local-vol mountPath: /usr/test-pod volumeClaimTemplates: - metadata: name: local-vol spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "local-storage" resources: requests: storage: 368Gi Key Point 使用Local PV的实际场景 使用本地磁盘作为缓存的系统 CI/CD中用于存储构建中的系统 一些允许丢失和不需要保证可靠的数据(session, token) Local PV与HostPath的对比 hostpath: ...