ggml是什么 ggml是用于transformer架构推理的机器学习库，类似于pytorch、TensorFlow等机器学习库。ggml不需要第三方库的依赖，目前兼容X86、ARM、Apple Silicon、CUDA等。 小demo开始 int main(void) { #define rows_A 4 #define cols_A 2 float matrix_A[rows_A * cols_A] = { 2, 8, 5, 1, 4, 2, 8, 6 }; #define rows_B 3 #define cols_B 2 float matrix_B[rows_B * cols_B] = { 10, 5, 9, 9, 5, 4 }; size_t ctx_size = 0; ctx_size += rows_A * cols_A * ggml_type_size(GGML_TYPE_F32); ctx_size += rows_B * cols_B * ggml_type_size(GGML_TYPE_F32); ctx_size += 2 * ggml_tensor_overhead(); ctx_size += ggml_graph_overhead(); ctx_size += 1024; struct ggml_init_params params = { .mem_size = ctx_size, .mem_buffer = NULL, .no_alloc = false, }; struct ggml_context * ctx = ggml_init(params); struct ggml_tensor * tensor_a = ggml_new_tensor_2d(ctx, GGML_TYPE_F32, cols_A, rows_A); struct ggml_tensor * tensor_b = ggml_new_tensor_2d(ctx, GGML_TYPE_F32, cols_B, rows_B); memcpy(tensor_a->data, matrix_A, ggml_nbytes(tensor_a)); memcpy(tensor_b->data, matrix_B, ggml_nbytes(tensor_b)); struct ggml_cgraph * gf = ggml_new_graph(ctx); struct ggml_tensor *result = ggml_mul_mat(ctx, tensor_a, tensor_b); ggml_build_forward_expand(gf, result); int n_threads = 1; ggml_graph_compute_with_ctx(ctx, gf, n_threads); float *result_data = (float *)result->data; printf("mul mat (%d x %d) (transposed result):\n[", (int) result->ne[0], (int) result->ne[1]); for (int j = 0; j < result->ne[1]; j++) { if (j > 0) { printf("\n"); } for (int i = 0; i < result->ne[0]; i++) { printf(" %.2f", result_data[j * result->ne[0] + i]); } } printf(" ]\n"); ggml_free(ctx); return 0; } 下面以一个最小demo开始串起全流程，顺序是： 估算内存池需要的大小ctx_size。 ggml_init创建context内存池。 ggml_new_tensor_2d创建tensor，并把原始数组memcpy到tensor->data。 ggml_new_graph创建graph。 ggml_mul_mat创建一个“矩阵乘”节点（这里只是描述，还没算） ggml_build_forward_expand从result往回收集依赖，填充graph。 ggml_graph_compute_with_ctx执行graph，结果写到result->data。 关键数据结构 本章节中涉及到一些关键的数据结构，理解这些数据结构对于整个架构至关重要。主要的ggml_context、ggml_tensor、ggml_cgraph。 ggml_context：内存池管理器，用于存储张量、计算图等信息。 ggml_tensor：计算的元数据，但不仅仅是存储tensor，还存储的tensor操作。 ggml_cgraph：计算图的表示，用于传给后端的“计算执行顺序”。 内存池ggml_context struct ggml_context { size_t mem_size; void * mem_buffer; bool mem_buffer_owned; bool no_alloc; int n_objects; struct ggml_object * objects_begin; struct ggml_object * objects_end; }; ggml_context从命名看是上下文，从编码上来看是用于存储的全局信息，一个装载各类对象 (如张量、计算图、其他数据) 的“容器”。 内存池布局 ggml_context就是ggml的内存池管理器，它管理一块连续的大内存mem_buffer，并在其中按顺序分配"对象"（tensor、graph、work_buffer），最后用ggml_free(ctx)一次性释放。 mem_size：内存池的总大小。 mem_buffer:内存池的基址地址，一整块连续内存的起点。 mem_buffer_owned:这块mem_buffer由ggml拥有（负责释放）。 no_alloc:是否禁止ggml自动为tensor分配tensor->data。 n_objects:已经在ctx内存池里分配了多少个对象块（tensor/graph/work_buffer等）。 objects_begin/end:ctx内存池里对象链表的头/尾。 内存池中可以存储不同的对象，对象的类型主要分为3种。 GGML_OBJECT_TYPE_TENSOR：存储张量+计算的节点。 GGML_OBJECT_TYPE_GRAPH：一次执行要跑那些节点 GGML_OBJECT_TYPE_WORK_BUFFER：执行过程中临时scratch内存。 每一类的存储类型内存布局都是先以struct ggml_object开头，然后是对应的类型数据。而具体的类型数据前面又存储个其内存数据的描述结构。（这种类型结构很经典，跟蓝牙的广播AD type一样，也跟之前设计的眼镜方案消息传输方案一样）。 struct ggml_object { size_t offs; size_t size; struct ggml_object * next; enum ggml_object_type type; char padding[4]; }; ggml_object可以理解为header，其描述了存储数据的类型type，实际数据起始偏移（相对ctx->mem_buffer），实际的数据长度size，以及指向下一个类型的指针next。而padding是用于填充，保持对齐要求。 在ggml_object后面就是实际类型的数据，以tensor类型为例，同样开始存储的是struct ggml_tensor结构体，后面是实际的tensor数据以及padding，这里需要注意的是tensor的数据并不一定会存储在内存池中，主要根据struct ggml_context中的no_alloc来判断是否要为tensor分配空间，如果不需要那么这里只会存储的是描述tensor的数据结构即struct ggml_tensor+padding，在ggml_tensor中data指向的实际的tensor存储位置起始地址。 ctx->mem_buffer + (某个位置) ┌───────────────┬───────────────────┬──────────────────────┬──────┐ │ ggml_object头 │ ggml_tensor结构体 │ tensor data (bytes) │ PAD │ └───────────────┴───────────────────┴──────────────────────┴──────┘ ↑ tensor 指针(result) ↑ tensor->data 指针 内存池是先预分配，后续实际需要多少就从内存池中获取多少。这就LwIP网络协议栈中的实现原理是一样的，类似先分配一块内存池MEM_POOL，这样的话就不用反复的申请提高计算效率。 关键API 这里总结一下跟ggml_context相关的关键API。 创建： ggml_init(params)，创建一份ggml_context。 释放：ggml_free。 查询： ggml_used_mem(ctx)：当前已用到的内存池在哪里。 ggml_get_mem_size(ctx)/ggml_get_mem_buffer(ctx) ggml_get_no_alloc(ctx) / ggml_set_no_alloc(ctx) 下面我们重点分析一下ggml_init的实现。 分配内存池 ggml_init的实现其实非常简单，就是先使用malloc分配struct ggml_context数据结构，其次就是分配一块虚拟地址连续的mem_buffer。这里需要注意的是ggml_context和mem_buffer不要搞混了，ggml_context可不再内存池中，ggml_contexth是单独的一块数据结构用来管理内存池的，内存池的虚拟地址的连续的。 struct ggml_context * ggml_init(struct ggml_init_params params) { static bool is_first_call = true; ggml_critical_section_start(); if (is_first_call) { // initialize time system (required on Windows) ggml_time_init(); is_first_call = false; } ggml_critical_section_end(); struct ggml_context * ctx = GGML_MALLOC(sizeof(struct ggml_context)); // allow to call ggml_init with 0 size if (params.mem_size == 0) { params.mem_size = GGML_MEM_ALIGN; } const size_t mem_size = params.mem_buffer ? params.mem_size : GGML_PAD(params.mem_size, GGML_MEM_ALIGN); *ctx = (struct ggml_context) { /*.mem_size =*/ mem_size, /*.mem_buffer =*/ params.mem_buffer ? params.mem_buffer : ggml_aligned_malloc(mem_size), /*.mem_buffer_owned =*/ params.mem_buffer ? false : true, /*.no_alloc =*/ params.no_alloc, /*.n_objects =*/ 0, /*.objects_begin =*/ NULL, /*.objects_end =*/ NULL, }; GGML_ASSERT(ctx->mem_buffer != NULL); GGML_ASSERT_ALIGNED(ctx->mem_buffer); GGML_PRINT_DEBUG("%s: context initialized\n", __func__); return ctx; } 从上面的代码可以看出主要是调用GGML_MALLOC分配struct ggml_context本体，接着判断用户是否传入mem_buffer，如果没有传递同时mem_size有设置就会在内部分配一块。 张量ggml_tensor 数据结构 struct ggml_tensor { enum ggml_type type; struct ggml_backend_buffer * buffer; int64_t ne[GGML_MAX_DIMS]; // number of elements size_t nb[GGML_MAX_DIMS]; // stride in bytes: // nb[0] = ggml_type_size(type) // nb[1] = nb[0] * (ne[0] / ggml_blck_size(type)) + padding // nb[i] = nb[i-1] * ne[i-1] // compute data enum ggml_op op; // op params - allocated as int32_t for alignment int32_t op_params[GGML_MAX_OP_PARAMS / sizeof(int32_t)]; int32_t flags; struct ggml_tensor * src[GGML_MAX_SRC]; // source tensor and offset for views struct ggml_tensor * view_src; size_t view_offs; void * data; char name[GGML_MAX_NAME]; void * extra; // extra things e.g. for ggml-cuda.cu char padding[8]; }; 上面是ggml_tensor的结构体，ggml_tensor是ggml的核心对象，既是一个多维数组的描述符（type/shape/stride/data），也是计算图里的一个节点（op/src/params/flags）。 ggml_tensor代表了两种类型，理解这两类类型十分关键： 数据张量：张量持有实际的数据，包含一个多维数组的数组。 运算张量：这个张量表示的是有多个输入张量的运算结果，只有实际运算时才会有数据。 主要是通过数据结构中的op来判断，如果op为GGML_OP_NONE则表示的是张量数据，如果op为操作符如GGML_OP_MUL_MAT则表示张量不含数据，而是表示两个张量矩阵乘法的结果。 （1）作为数组的字段 type：元素的类型（F32/F16/量化类型），决定元素/块大小，行大小。 ne[]：每维有多少个元素，ggml默认最多4维。 nb[]：描述每个维度步长。 （2）作为计算节点的字段 op： 这个tensor通过那个算子得到。如果维GGML_OP_NONE表示不是算子输出而是输入张量。 src[]: 算子节点输入张量的指针数组，如对于mul_mat来说src[0]=a,src[1]=b。这决定后续计算graph的根本。 op_prarams:算子的额外参数。 （3）View/切片/共享数据 view_src+view_offs表示这个tensor是另一个tensor的视图（共享data，不重新分配），data通常等于view_src->data+view_offs。 （4）与后端/设备相关字段 buffer：指向ggml_backend_buffer（后端的内存抽象），CPU简单路径下很多时候是NULL或默认。 extra：给特定后端/实现放额外信息的扩展指针。 总结一下ggml_tensor承担的两件事情，一是存储张量/数组的描述，而是用于计算计算节点。 分配张量 分配张量就是调用ggml_new_tensor_xx，如下： struct ggml_tensor * ggml_new_tensor_1d：分配1维的张量。 struct ggml_tensor * ggml_new_tensor_2d： 分配2维的张量。 struct ggml_tensor * ggml_new_tensor_3d：分配3维的张量。 struct ggml_tensor * ggml_new_tensor_4d：分配4维的张量。 最终张量的分配都会调用ggml_new_tensor来实现。下面以ggml_new_tensor_2d为例。 ggml_new_tensor_2d最终会调用内部的ggml_new_tensor_impl来实现，主要的流程就是先试用ggml_new_object从内存池中分配一个头节点，然后在分配payload也就是再从内存池分配ensor的结构体，接着根据no_alloc来判断是否要为tensor的data从内存池分配空间，最后就是填充好ggml_object和ggml_tensor。 创建的tensor主要有两部分组成 tensor结构体本身：shape、stride、op、src等信息。 可选的数据区：紧跟在结构体后面（(result + 1)），只有在 view_src NULL && ctx->no_alloc false 时才会在 ctx 内存池里实际分配。 这是ggml核心设计之一，ctx是一个arean/内存池，所有对象顺序追加，没有逐个free；ggml_free一次性释放整个池。 计算图ggml_cgraph 关键数据结构 struct ggml_cgraph { int size; // maximum number of nodes/leafs/grads/grad_accs int n_nodes; // number of nodes currently in use int n_leafs; // number of leafs currently in use struct ggml_tensor ** nodes; // tensors with data that can change if the graph is evaluated struct ggml_tensor ** grads; // the outputs of these tensors are the gradients of the nodes struct ggml_tensor ** grad_accs; // accumulators for node gradients struct ggml_tensor ** leafs; // tensors with constant data int32_t * use_counts;// number of uses of each tensor, indexed by hash table slot struct ggml_hash_set visited_hash_set; enum ggml_cgraph_eval_order order; }; nodes[]：真正要执行的算子节点（有op，或是参数param）。 leafs[]：常量/叶子（op=NONE且不是param），例如常量张量。 在ggml中理解叶子（leaf）和节点（node)十分关键。 这两个都是用struct ggml_tensor来表示的，leaf是没有算子的（op=NONE），leaf可以理解为是输入/常量，他不需要通过执行算子来产生数据，数据已经在tensor->data中了，通过前面的memcpy进来或者后端的buffer提供，也不会前向执行中被计算出来；而node是需要再图执行是被处理的，包括两类 真正的算子输出：它的值来之执行的op，由tensor->src[]通过tensor->op计算而来。 参数：这个 tensor 是训练里要被当作变量去优化更新的参数（比如权重参数），既是op=NONE，但是也会放进node。 针对我们的demo，tensor_a、tensor_b是由ggml_new_tensor_2d创建的默认op=NONE，也不是PARAM这个就是leaf。而result=ggml_mul_mat(ctx, tensor_a, tensor_b)会设置result->op=GGML_OP_MUL_MAT且src[0]=tensor_a，src[1]=tensor_b，这个就是node。 再总结一下leafs就是图的“外部给定值”（常量/输入），不由 op 产生；nodes是图的“计算产生值”（算子输出）+ “训练参数（PARAM）”。 分配计算图 分配计算图是在ctx的内存池里一次性分配并初始化一张计算图ggml_cgraph，同时把图需要的数组nodes/leafs/use_counts/hash_keys/(可选)grads/grad_accs/hash_used）都放在同一个对象内存块里，并把这些指针指向那块内存。 struct ggml_cgraph * ggml_new_graph_custom(struct ggml_context * ctx, size_t size, bool grads) { const size_t obj_size = ggml_graph_nbytes(size, grads); struct ggml_object * obj = ggml_new_object(ctx, GGML_OBJECT_TYPE_GRAPH, obj_size); struct ggml_cgraph * cgraph = (struct ggml_cgraph *) ((char *) ctx->mem_buffer + obj->offs); // the size of the hash table is doubled since it needs to hold both nodes and leafs size_t hash_size = ggml_hash_size(size * 2); void * p = cgraph + 1; struct ggml_tensor ** nodes_ptr = incr_ptr_aligned(&p, size * sizeof(struct ggml_tensor *), sizeof(struct ggml_tensor *)); struct ggml_tensor ** leafs_ptr = incr_ptr_aligned(&p, size * sizeof(struct ggml_tensor *), sizeof(struct ggml_tensor *)); int32_t * use_counts_ptr = incr_ptr_aligned(&p, hash_size * sizeof(int32_t), sizeof(int32_t)); struct ggml_tensor ** hash_keys_ptr = incr_ptr_aligned(&p, hash_size * sizeof(struct ggml_tensor *), sizeof(struct ggml_tensor *)); struct ggml_tensor ** grads_ptr = grads ? incr_ptr_aligned(&p, hash_size * sizeof(struct ggml_tensor *), sizeof(struct ggml_tensor *)) : NULL; struct ggml_tensor ** grad_accs_ptr = grads ? incr_ptr_aligned(&p, hash_size * sizeof(struct ggml_tensor *), sizeof(struct ggml_tensor *)) : NULL; ggml_bitset_t * hash_used = incr_ptr_aligned(&p, ggml_bitset_size(hash_size) * sizeof(ggml_bitset_t), sizeof(ggml_bitset_t)); // check that we allocated the correct amount of memory assert(obj_size == (size_t)((char *)p - (char *)cgraph)); *cgraph = (struct ggml_cgraph) { /*.size =*/ size, /*.n_nodes =*/ 0, /*.n_leafs =*/ 0, /*.nodes =*/ nodes_ptr, /*.grads =*/ grads_ptr, /*.grad_accs =*/ grad_accs_ptr, /*.leafs =*/ leafs_ptr, /*.use_counts =*/ use_counts_ptr, /*.hash_table =*/ { hash_size, hash_used, hash_keys_ptr }, /*.order =*/ GGML_CGRAPH_EVAL_ORDER_LEFT_TO_RIGHT, }; ggml_hash_set_reset(&cgraph->visited_hash_set); if (grads) { memset(cgraph->grads, 0, hash_size*sizeof(struct ggml_tensor *)); memset(cgraph->grad_accs, 0, hash_size*sizeof(struct ggml_tensor *)); } return cgraph; } 如果grads=false，表示是这是推理/前向图，内存布局如下： graph payload (obj->offs 指向起点) +------------------------------+ | struct ggml_cgraph | <- cgraph 指向这里 | - nodes -> nodes_ptr | | - leafs -> leafs_ptr | | - visited_hash_set.size | | - visited_hash_set.used -> hash_used | - visited_hash_set.keys -> hash_keys_ptr | - use_counts -> use_counts_ptr | - grads/grad_accs == NULL | +------------------------------+ | (对齐到 sizeof(ptr)) | +------------------------------+ | nodes_ptr[size] | array of struct ggml_tensor* +------------------------------+ | leafs_ptr[size] | array of struct ggml_tensor* +------------------------------+ | use_counts_ptr[hash_size] | array of int32_t (按 hash slot) +------------------------------+ | hash_keys_ptr[hash_size] | array of struct ggml_tensor* (hash keys) +------------------------------+ | hash_used bitset | ggml_bitset_t[bitset_size(hash_size)] +------------------------------+ | (尾部 padding 到 GGML_MEM_ALIGN) | +------------------------------+ 如果grads=true，对应的就是训练图/反向图，在hash_keys_ptr后面多两段。 ... hash_keys_ptr[hash_size] +------------------------------+ | grads_ptr[hash_size] | struct ggml_tensor* (每个被访问 tensor 的 grad 输出) +------------------------------+ | grad_accs_ptr[hash_size] | struct ggml_tensor* (grad accumulator) +------------------------------+ | hash_used bitset ... 我们重点看推理这部分，在graph payload中，前面部门存储的是ggml_cgraph结构体，后面紧跟的就是ggml_cgraph结构的内容。其中就最关键的是nodes[]和leafs[]，前者存储是指向node类型tensor的指针，后者存储的指向leafs类型tensor的指针。 计算图构建 计算节点 在ggml中创建一个算子节点，就是调用类似ggml_mul_mat的函数。 struct ggml_tensor * ggml_mul_mat( struct ggml_context * ctx, struct ggml_tensor * a, struct ggml_tensor * b) { GGML_ASSERT(ggml_can_mul_mat(a, b)); GGML_ASSERT(!ggml_is_transposed(a)); const int64_t ne[4] = { a->ne[1], b->ne[1], b->ne[2], b->ne[3] }; struct ggml_tensor * result = ggml_new_tensor(ctx, GGML_TYPE_F32, 4, ne); result->op = GGML_OP_MUL_MAT; result->src[0] = a; result->src[1] = b; return result; } 上面的代码其实很简单，就是创建一个ggml_tensor，然后赋值op和要操作的src[0]和src[1],最后返回的也是ggml_tensor。 所以了ggml_mul_mat并不会立刻进行做矩阵乘法运算，它只是创建了一个"算子节点"，把算子类型和输入依赖挂上去，等后面ggml_build_forward_expand+ggml_graph_compute_with_ctx才正在执行。 计算图 ggml_build_forward_expand是GGML计算图构建最关键的一部，核心任务是执行拓扑排序，从一个目标节点开始（通常是Loss或输出张量），递归的遍历所有依赖项（源张量src[0]，src[1]），并将它们按照"先输入后输出"的顺序填入计算图的执行队列中nodes数组。 static size_t ggml_visit_parents(struct ggml_cgraph * cgraph, struct ggml_tensor * node) { // 1) 用 visited_hash_set 去重：同一个 tensor 只处理一次 size_t node_hash_pos = ggml_hash_find(&cgraph->visited_hash_set, node); if (!ggml_bitset_get(cgraph->visited_hash_set.used, node_hash_pos)) { cgraph->visited_hash_set.keys[node_hash_pos] = node; ggml_bitset_set(cgraph->visited_hash_set.used, node_hash_pos); cgraph->use_counts[node_hash_pos] = 0; } else { return node_hash_pos; } // 2) 递归访问 node->src[k]，同时对每个 src 做 use_counts++ for (int i = 0; i < GGML_MAX_SRC; ++i) { struct ggml_tensor * src = node->src[k]; if (src) { size_t src_hash_pos = ggml_visit_parents(cgraph, src); cgraph->use_counts[src_hash_pos]++; } } // 3) 分类：leaf vs node（leaf 是 op==NONE 且不是 PARAM） if (node->op == GGML_OP_NONE && !(node->flags & GGML_TENSOR_FLAG_PARAM)) { cgraph->leafs[cgraph->n_leafs++] = node; } else { cgraph->nodes[cgraph->n_nodes++] = node; } return node_hash_pos; } 核心在这个ggml_visit_parents函数中，核心原理是从results开始往上遍历，把tensor为leafs类型的添加到leafs[]中，把tensor为node类型的添加到nodes[]中。 （1）去重 在ggml_visit_parents中会去重，同一个tensor可能会被多个算子引用，但是只希望他在图中出现一次，通过使用 visited_hash_set（key 是 tensor 指针地址）记录“见没见过”。见过就直接返回，不再 DFS，不再追加 nodes/leafs。 （2）递归遍历DFS 先递归访问 node->src[]，再把 node 自己追加到 nodes/leafs。这天然形成一种顺序：后序遍历（post-order），直觉上就是：先把依赖（输入、上游算子）放进图，再放当前算子输出，这就是为什么 build 结束后，nodes[] 基本满足“依赖在前，使用在后”，便于执行。 （3）use_count使用次数统计 cgraph->use_counts[src_hash_pos]++ 表示：这个 src tensor 被作为某个 node 的输入用了一次。 它按 “hash slot” 存（不是按 nodes[] 下标），原因是：去重后每个 tensor 都能在 hash 表里找到一个稳定位置，方便后续用同一套索引关联其它数组（例如 grads/grad_accs 在训练图里也是按 hash slot 对齐）。 if (node->op == GGML_OP_NONE && !(node->flags & GGML_TENSOR_FLAG_PARAM)) { cgraph->leafs[cgraph->n_leafs] = node; cgraph->n_leafs++; } else { cgraph->nodes[cgraph->n_nodes] = node; cgraph->n_nodes++; } 从这个代码中也可以看到对于ggml_tensor，是怎么区分leaf和node的。 leaf：op为NONE 且不是 PARAM ->通常代表“常量/输入常量”（不需要通过执行算子得到） node：其它情况 ->需要在图执行时被处理的东西（算子输出 or 训练参数） 下面以简单的图来说明一下，我们的示例小demo的表达式如下： result (MUL_MAT) / \ tensor_a tensor_b (op NONE) (op NONE) 调用 ggml_build_forward_expand(gf, result) 的 DFS（后序）大致是： visit(result) visit(tensor_a) -> leafs += tensor_a visit(tensor_b) -> leafs += tensor_b nodes += result 得到的结构就是 cgraph->leafs: [ tensor_a, tensor_b ] 如果图更复杂，有共享子图（DAG），去重就很关键： z = add(x, x) // x 被用两次 / \ x x visit(z): visit(x): 第一次见到 -> leafs += x visit(x): 第二次见到 -> 直接 return（不重复加入） use_counts[x] 会被 ++ 两次 nodes += z 计算结果就是 leafs: [x] nodes: [z] use_counts[x] == 2 执行计算 ggml_graph_cmpute会先调用ggml_graph_plan算出需要多大的临时buffer，然后把这个work buffer直接从ctx的内存池分配出来，最后在启动图的计算。 图规划 ggml_graph_plan(cgraph, n_threads, NULL)的目标是决定实际用多少线程+估算整张图执行所需的最大临时内存work_size。plan会编译cgraph->nodes[]，对每个node 计算 n_tasks = ggml_get_n_tasks(node, n_threads)（这个 op 适合拆多少任务） 估算该 op 需要的额外临时空间 cur 全图取 work_size = max(work_size, cur)（注意是 max，不是 sum，因为 work buffer 复用） for (int i = 0; i < cgraph->n_nodes; i++) { struct ggml_tensor * node = cgraph->nodes[i]; const int n_tasks = ggml_get_n_tasks(node, n_threads); max_tasks = MAX(max_tasks, n_tasks); size_t cur = 0; // ... switch(node->op) 估算 cur ... work_size = MAX(work_size, cur); } if (work_size > 0) { work_size += CACHE_LINE_SIZE*(n_threads); } cplan.threadpool = threadpool; cplan.n_threads = MIN(max_tasks, n_threads); cplan.work_size = work_size; cplan.work_data = NULL; return cplan; 很多 op 需要一块临时空间（例如把 src1 转换/pack 成适合 vec-dot 的布局），但这些临时空间可以在不同节点之间复用，所以用 “最大需求” 的单一 work buffer 就够。struct ggml_cplan 如下 struct ggml_cplan { size_t work_size; uint8_t * work_data; int n_threads; struct ggml_threadpool * threadpool; ggml_abort_callback abort_callback; void * abort_callback_data; }; 分配work buffer 主要的目的就是在ctx的内存池里分配一块连续的内存作为work buffer，并把指针协会cplan.work_data。 cplan.work_data = (uint8_t *)ggml_new_buffer(ctx, cplan.work_size); return ggml_graph_compute(cgraph, &cplan); 为什么放 ctx 里，主要是避免每次 compute 时 malloc/free，并且生命周期跟 ctx 同步；缺点是 ctx 必须预留足够大（demo 里看到加了 ggml_graph_overhead() 和额外 1024，就是类似目的）。 执行 ggml_graph_compute就是执行了 （1）首先是先启动线程池 初始化计算后端如 cpu backend。 根据 cplan->threadpool 是否为空，创建一个临时 threadpool 或复用传入的 threadpool。 并行运行 ggml_graph_compute_thread enum ggml_status ggml_graph_compute(struct ggml_cgraph * cgraph, struct ggml_cplan * cplan) { ggml_cpu_init(); GGML_ASSERT(cplan); GGML_ASSERT(cplan->n_threads > 0); GGML_ASSERT(cplan->work_size == 0 || cplan->work_data != NULL); int n_threads = cplan->n_threads; struct ggml_threadpool * threadpool = cplan->threadpool; if (threadpool == NULL) { disposable_threadpool = true; // 创建 threadpool threadpool = ggml_threadpool_new_impl(&ttp, cgraph, cplan); } else { // 复用 threadpool：设置当前要跑的 cgraph/cplan 等 threadpool->cgraph = cgraph; threadpool->cplan = cplan; // ... } // 然后让各线程进入 ggml_graph_compute_thread(...) } 启动线程池后每个线程跑 ggml_graph_compute_thread，按 node 顺序执行 op，每个线程会构造一个ggml_compute_params，里面包含线程编号和线程数，全局work buffer，同步/屏障等信息。 struct ggml_compute_params { int ith, nth; size_t wsize; void * wdata; struct ggml_threadpool * threadpool; }; （2）线程执行的主流程 static thread_ret_t ggml_graph_compute_thread(void * data) { const struct ggml_cgraph * cgraph = tp->cgraph; const struct ggml_cplan * cplan = tp->cplan; struct ggml_compute_params params = { .ith = state->ith, .nth = ..., .wsize = cplan->work_size, .wdata = cplan->work_data, .threadpool= tp, }; for (int node_n = 0; node_n < cgraph->n_nodes && ...; node_n++) { struct ggml_tensor * node = cgraph->nodes[node_n]; if (ggml_op_is_empty(node->op)) { continue; } ggml_compute_forward(¶ms, node); if (node_n + 1 < cgraph->n_nodes) { ggml_barrier(state->threadpool); // 每个 node 结束后做一次全线程同步 } } ggml_barrier(state->threadpool); return 0; } 从上面可以看到图执行是“按 nodes[] 线性顺序”，每个 node 结束用 barrier 保证所有线程都完成该 node，再进入下一个 node（避免数据依赖被破坏）。ggml_compute_forward 里会根据 node->op 分发到具体 kernel。比如 MUL_MAT： case GGML_OP_MUL_MAT: { ggml_compute_forward_mul_mat(params, tensor); } break; （3）以一个例子来理解哪里串行，哪里并行 W (leaf) x (leaf) \ / \ / y = MUL_MAT b (leaf) | | +-----> y2 = ADD | v o = RELU 经过DFS后续遍历后，结果是： cgraph->nodes[0] = y (MUL_MAT) cgraph->nodes[1] = y2 (ADD) cgraph->nodes[2] = o (RELU) 因为各个node的计算是有前后依赖的，因此不行并行，也就是说node0 -> node1 -> node2 是串行推进，不能乱序并发（因为 node1 依赖 node0 输出，node2 依赖 node1 输出）。 for node_n in [0..n_nodes): 所有线程一起执行 nodes[node_n] barrier 等齐 而并行多线程计算你的是单个node的内部，每个node内部数据量很大，通常会拆快让多个线程并行计算。 时间 → thread0: [ node0: MUL_MAT 计算一部分tile ] |B| [ node1: ADD 处理一部分元素 ] |B| [ node2: RELU 处理一部分元素 ] |B| thread1: [ node0: MUL_MAT 计算一部分tile ] |B| [ node1: ADD 处理一部分元素 ] |B| [ node2: RELU 处理一部分元素 ] |B| thread2: [ node0: MUL_MAT 计算一部分tile ] |B| [ node1: ADD 处理一部分元素 ] |B| [ node2: RELU 处理一部分元素 ] |B| thread3: [ node0: MUL_MAT 计算一部分tile ] |B| [ node1: ADD 处理一部分元素 ] |B| [ node2: RELU 处理一部分元素 ] |B| 其中竖线|B|就是ggml_barrier，所有线程必须等到这一个node全部完成，才能进入到下一个node，而有4个线程同时干一个算子的事情。在一个node算子内，数据量通常是一个多维的矩阵，那么对数据可以做拆分tile分发到多个线程并发执行，这样就可以提高速度。