GaGa's Blog

大模型需要多大GPU内存才能跑起来的计算公式

Posted on 2026-08-31

一个大模型需要多大 GPU 内存才能跑起来的计算公式：
M = ((P * 4B) / (32 / Q) ) * 1.2

M: 所需的 GPU 显存，单位是 GB。
P: 模型的参数数量。例如，7B 模型有 70 亿个参数。
4B: 每个参数占用的字节数，这里假设每个参数占用 4 个字节（通常指 FP32 或 Float32 格式）。
32: 4 个字节等于 32 位。
Q: 加载模型时使用的位数。例如，16 位 (FP16/BF16)，8 位 (INT8) 或 4 位 (INT4)。这通常称为量化。
1.2: 表示额外开销的系数，通常为 20%。这考虑了除了模型权重之外还需要加载到 GPU 显存中的其他数据，例如优化器状态、梯度等。

如使用 FP16 量化加载 Llama 70B 模型，计算过程就是
M = ( (70,000,000,000 * 4) / (32 / 16) )* 1.2 = 168 GB

文档：Redoc架构及应用场景

Posted on 2026-08-31

1.Redoc 简介

Redoc是一个开源的OpenAPI/Swagger 文档生成器，专注于美观的 API 文档渲染。

2.核心架构

┌─────────────────────────────────────────────────────
│                  OpenAPI/Swagger Spec               
│              (YAML / JSON 格式)                     
└──────────────────────┬──────────────────────────────
                       │
                       ▼
┌─────────────────────────────────────────────────────
│                   Redoc CLI / Build                  
│   • redoc-cli build spec.yaml --output index.html  
│   • npm/yarn 打包为静态资源                          
└──────────────────────┬──────────────────────────────
                       │
                       ▼
┌─────────────────────────────────────────────────────
│                单页 HTML 输出                         
│  • 自包含 HTML + CSS + JS                            
│  • 无需后端服务，可直接部署到 CDN/Nginx               
└──────────────────────┬──────────────────────────────
                       │
                       ▼
┌─────────────────────────────────────────────────────
│              浏览器端渲染引擎                         
│  • React + Web Components                            
│  • 左侧导航 + 右侧内容区                              
│  • 主题定制（CSS 变量）                               
│  • 搜索/筛选功能                                      
└─────────────────────────────────────────────────────

LoongCollector支持同时采集容器标准输出（Console）日志和容器内文本文件

Posted on 2026-08-31

1. 支持的采集类型

LoongCollector 支持以下两类容器日志采集方式：

容器标准输出（stdout/stderr）采集
自动读取容器运行时（Docker 或 Containerd）生成的标准输出流日志，无需访问容器内部文件系统。
容器内文本文件日志采集
通过挂载宿主机根目录（默认挂载至 LoongCollector 容器内的 /logtail_host），间接访问业务容器在宿主机上的日志文件路径，从而采集容器内指定路径的日志文件。

SLS的LogStore智能存储分层

Posted on 2026-08-31

阿里云日志服务（SLS）的 LogStore 智能存储分层 是一项基于数据生命周期自动管理存储成本的核心功能，通过将日志数据在 热存储、低频存储、归档存储 三层之间自动迁移，在保障关键能力的同时显著降低长期存储费用。

1.三种存储类型详解

存储类型	适用场景	费用（元/GB/天）	查询性能	并发能力	核心优势
热存储	高频查询、实时监控、告警分析等业务	0.0115	十至百毫秒	查询并发：100 分析并发：2	高性能、高并发、实时访问
低频存储（原冷存储）	问题回溯、偶发性排查、低频审计	0.005	百毫秒至秒级	查询并发：10 分析并发：2	成本约为热存储的43%，功能完整
归档存储	合规审计、长期保存（如等保6个月以上）	0.0017	分钟级响应	查询并发：1 分析并发：1	成本仅为热存储的约15%，支持可查询归档

SLS非阿里云日志上传收费情况

Posted on 2026-08-31

1.是否收费？

是的，通过公网上传日志会产生费用，但费用并非直接针对“公网上传”本身单独计费，而是根据所选的 LogStore计费模式 对应的相关计费项进行收取。

若LogStore =采用按使用功能计费模式：

写入流量（即上传流量）属于“读写流量”计费项，会按照实际压缩后的数据量计费。
同时可能涉及以下计费项：
- 活跃Shard租用
- 存储空间（日志热存储）
- 索引流量（如开启索引）
- 读写次数

Spark技术架构及应用场景

Posted on 2026-08-31

1.Spark 核心架构

1.1 整体架构

┌─────────────────────────────────────────────────────────
│                   Client（客户端）                        
│            spark-submit / pyspark / spark-shell          
└─────────────────────────────────────────────────────────
                          │
                          ▼
┌─────────────────────────────────────────────────────────
│                   Driver（驱动器）                        
│  ┌─────────────┐  ┌──────────────┐  ┌───────────────┐  
│  │  DAGScheduler │  │  Scheduler   │  │  SparkContext  
│  │  (任务调度)   │  │  (资源调度)   │  │  (上下文管理)  │  
│  └─────────────┘  └──────────────┘  └───────────────┘  
└─────────────────────────────────────────────────────────
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
    ┌───────────┐  ┌───────────┐  ┌───────────┐
    │  Executor │  │  Executor │  │  Executor │   ← Worker节点
    │   (工作节点) │  │   (工作节点) │  │   (工作节点) │
    └───────────┘  └───────────┘  └───────────┘
          │               │               │
          └───────────────┴───────────────┘
                          │
              ┌───────────┴───────────┐
              ▼                       ▼
        ┌─────────┐            ┌─────────┐
        │  HDFS   │            │  Kafka  │  ← 数据源
        └─────────┘            └─────────┘

1.2核心组件详解

逻辑回归（Logistic Regression）

Posted on 2026-08-31

逻辑回归是一种分类算法，尽管名字中有”回归”，但它主要用于解决二分类问题（也可以扩展到多分类）。

核心思想

将线性回归的输出值，通过一个Sigmoid函数映射到 (0, 1) 区间
输出值表示样本属于某一类别的概率
当概率 ≥ 0.5 时预测为正类，否则为负类

数学公式

JuiceFS (JFS) 在k8s中应用

Posted on 2026-08-30

Kubernetes容器存储

K8s CSI 驱动架构：

┌─────────────────────────────────────────────────────────────┐
│                    Kubernetes 集群                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Pod 1              Pod 2           Pod 3           │   │
│  │  ┌─────────────┐    ┌─────────────┐ ┌─────────────┐ │   │
│  │  │  Container  │    │  Container  │ │  Container  │ │   │
│  │  │   /data     │    │   /data     │ │   /data     │ │   │
│  │  └──────┬──────┘    └──────┬──────┘ └──────┬──────┘ │   │
│  │         └──────────────────┼─────────────────┘       │   │
│  │                            ▼                         │   │
│  │                 ┌─────────────────────┐              │   │
│  │                 │   JuiceFS CSI       │              │   │
│  │                 │   Controller        │              │   │
│  │                 └──────────┬──────────┘              │   │
│  │                            │                         │   │
│  │                 ┌──────────┴──────────┐              │   │
│  │                 │   JuiceFS Node      │              │   │
│  │                 │   (每个节点)         │              │   │
│  │                 └──────────┬──────────┘              │   │
│  └────────────────────────────┼─────────────────────────┘   │
│                               │                             │
│                               ▼                             │
│              ┌─────────────────────────────────┐            │
│              │         JuiceFS Mount           │            │
│              │      (POSIX 文件系统)            │            │
│              └─────────────────────────────────┘            │
│                               │                             │
│                               ▼                             │
│              ┌─────────────────────────────────┐            │
│              │         对象存储                │            │
│              │     (S3/OSS/COS/MinIO)         │            │
│              └─────────────────────────────────┘            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

PVC示例

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: juicefs-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: juicefs-sc
  resources:
    requests:
      storage: 100Gi
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: juicefs-sc
provisioner: csi.juicefs.com
parameters:
  CSI PROVISIONER SECRET: juicefs-provisioner-secret
  CSI NODE STAGE SECRET: juicefs-node-secret
  CONTEXT: '{"subpath":"/"}'

JuiceFS (JFS) 分布式存储架构及应用场景

Posted on 2026-08-30

1.JuiceFS 核心架构

┌─────────────────────────────────────────────────────────────┐
│                     JuiceFS三层架构                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Client 层                                          │   │
│  │  • POSIX Mount  (类 Unix 文件系统)                   │   │
│  │  • HDFS Gateway   (Hadoop 兼容)                    │   │
│  │  • S3 API Gateway (对象存储接口)                    │   │
│  └─────────────────────────────────────────────────────┘   │
│                              │                              │
│                              ▼                              │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Engine 层                                          │   │
│  │                                                     │   │
│  │  ┌──────────────────┐      ┌──────────────────┐   │   │
│  │  │   元数据引擎      │      │    数据引擎      │   │   │
│  │  │  (Metadata)      │      │   (Storage)      │   │   │
│  │  ├──────────────────┤      ├──────────────────┤   │   │
│  │  │ • Redis          │      │ • AWS S3        │   │   │
│  │  │ • TiKV           │      │ • MinIO         │   │   │
│  │  │ • MySQL          │      │ • 阿里云 OSS     │   │   │
│  │  │ • SQLite         │      │ • 腾讯云 COS     │   │   │
│  │  │ • JVE (自研)     │      │ • Azure Blob    │   │   │
│  │  └──────────────────┘      └──────────────────┘   │   │
│  └─────────────────────────────────────────────────────┘   │
│                              │                              │
│                              ▼                              │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Cache 层                                           │   │
│  │  • L1: 本地 SSD/内存 (热数据)                       │   │
│  │  • L2: 分布式缓存 (温数据)                          │   │
│  │  • L3: 对象存储 (冷数据)                            │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

2.核心特性

DevOps文档重要性

Posted on 2026-08-30

1.核心观点

代码是写给人看的，顺便让机器执行
    ↓
DevOps 文档是写给人读的，确保协作顺畅
    ↓
优秀的文档 = 减少沟通成本 + 加速团队成长 + 降低故障风险

2.为什么DevOps文档如此重要？

webassembly技术应用场景

Posted on 2026-08-30

1.核心优势：为什么需要 WebAssembly？

特性	JavaScript	WebAssembly
执行速度	解释执行，受GC影响	接近原生性能（~0.75x原生）
类型系统	动态弱类型	静态强类型
内存管理	自动GC，不可控	手动/精确控制内存布局
来源语言	JS/TS	C/C++/Rust/Go等编译
启动速度	较快	需预编译，启动稍慢

适用场景：计算密集型、对性能有严格要求的Web应用

文档平台：readme.io介绍

Posted on 2026-08-30

1.平台概述

项目	内容
成立时间	2014年（约一年前成立，据2015年资料）
创始人	Gregory Koberger（CEO兼创始人）
定位	API文档托管与开发者中心平台
愿景	将文档、仪表板、API三者整合到统一平台

2.核心问题：为什么需要 ReadMe？

1.Redoc 简介

2.核心架构

1. 支持的采集类型

1.三种存储类型详解

1.是否收费？

若LogStore =采用 按使用功能计费模式：

1.Spark 核心架构

1.1 整体架构

1.2核心组件详解

核心思想

数学公式

Kubernetes容器存储

PVC示例

1.JuiceFS 核心架构

2.核心特性

1.核心观点

2.为什么DevOps文档如此重要？

1.核心优势：为什么需要 WebAssembly？

1.平台概述

2.核心问题：为什么需要 ReadMe？

若LogStore =采用按使用功能计费模式：