本地 SLM(Small Language Model, 小型语言模型)的内存设计, 直接决定一个模型是能流畅运行, 还是一启动就让整机开始交换分区。和云端大模型不同, 本地 SLM 的推理环境通常只有一块消费级显卡、16GB 到 64GB 内存, 甚至只有 CPU 可用。此时内存不是“把模型文件读进来”这么简单: 权重、KV Cache、激活值、框架分配器、外部进程开销会在同一时刻叠加, 任何一个环节超限, 都可能触发 out of memory、segmentation fault, 或者服务端请求大面积超时。这篇博客围绕 “A Memory Design for Local SLM” 这个主题, 按“内存组成 - 基线测量 - 设计策略 - 最小实现 - 运行验证 - 问题排查 - 生产清单”的顺序, 整理一套可以直接复用的内存设计方法。读完以后, 你会清楚本地模型的内存到底花在哪里、怎么先测量再设计、遇到 OOM 时应该从哪一层开始查。1. 先拆清本地 SLM 的四类内存开销很多内存问题都源于把“模型权重占多大”当成了“整个进程占多大”。实际推理过程中, 内存由四类开销构成, 必须分开估算, 否则到了长文本场景一定会被 KV Cache 打穿。1.1 模型权重: 参数数量乘以精度字节数, 最直观但最容易误判权重内存的计算公式是:权重内存 参数数量 x 每个参数占用的字节数举个例子, 一个 70 亿参数的模型, 用 FP32 加载是 28GB, 用 FP16 是 14GB, 用 INT8 约 7GB, 用 INT4 约 3.5GB。常见精度与占用如下表:精度每参数字节数7B 模型权重占用适用场景FP324 字节28GB训练或精度对照, 本地推理很少用FP16/BF162 字节14GB精度与内存均衡, 有独显时首选INT81 字节约 7GB精度损失小, 16GB 内存在边缘INT4/AWQ/GPTQ0.5 字节左右约 3.5GB内存紧张、追求长上下文时常用这里容易误解的一点是: 量化不只是省磁盘, 它最直接的作用是把权重放进内存预算。但 INT4 模型在解码时通常需要反量化计算, 会额外消耗少量 CPU/GPU 算力。所以“哪个精度合适”要同时看内存余量和算力, 不能只看能不能加载。和硬件相关的还有一个重要维度: 本地推理的瓶颈常常不是容量, 而是内存带宽。双通道、四通道内存以及 DDR 代数, 直接决定权重读取速度。设计文档里最好把“容量”和“带宽”分开记录, 否则会出现容量够、推理却慢到不可用的情况。1.2 KV Cache: 随上下文线性增长, 最容易在长对话中失控KV Cache 是每生成一个新 token 都需要存下来的 Key 和 Value 张量, 大小随层数、batch、序列长度、隐层维度线性增长:KV Cache 字节数 ≈ 2 x 层数 x batch x 当前序列长度 x 隐层维度 x 精度字节数以 32 层、隐层 4096、单请求、FP16 为例:2 x 32 x 1 x 2048 x 4096 x 2 ≈ 1.07GB也就是说, 2048 token 的上下文大约占用 1GB; 如果并发 8 个请求, 就是 8GB。很多模型在短输入时内存正常, 用户多轮对话一拉长就立刻 OOM, 根因就是 KV Cache 没有预算控制。方案层面对应两个方向: 一是选 GQA/MQA 模型, 减少 KV 头数量; 二是用 sliding window attention, 让历史 KV 被淘汰。选模型和服务设计时都要提前确认这些能力是否存在。1.3 激活值与运行时开销: 平时不起眼, 峰值时最致命激活值是前向计算中的中间张量。首 token 阶段, 也就是 prefill 阶段, 要一次性处理整段 prompt, 激活峰值通常出现在这里; 后续 token 逐个生成, 激活值反而小。对 7B 级别模型, CPU 推理时激活值可能只占几百 MB, 但 GPU 推理时如果 batch 设置过大, 或者 attention 实现不高效, 激活峰值可能达到数 GB。运行时开销还包括下面几类:CUDA context: 约 300MB 到 500MB;PyTorch、ONNX Runtime 等框架的缓存分配器: 可能保留空闲块, 不立即归还系统;如果 SLM 服务外面还套了 Spring Boot、网关或 Agent 进程, JVM 堆、Node.js 堆也要单独计入。很多“实际内存还没用到一半却报 OOM”的现场, 就是漏掉了运行时开销和容器限制。这里先记住: 权重不是全部, KV Cache 按长度增长, 激活值看峰值, 运行时要留余量。2. 先测量基线再设计, 否则策略全是拍脑袋2.1 系统级命令: 看进程真实占用设计内存之前, 必须先知道当前基线。测量命令如下:/usr/bin/time -v python run_slm.py 21 | grep -E Maximum resident|User time|System timeGPU 侧看显存:nvidia-smi --query-gpumemory.used,memory.total,utilization.gpu --formatcsv进程粒度的内存分布:pmap -x $(pgrep -f run_slm.py) | tail -n 5这里要区分 RSS 和 VSZ。RSS 是实际驻留物理内存, VSZ 是虚拟地址空间。Linux OOM killer 主要依据物理内存和页面缓存占比来判断, 因此重点看 RSS, 以及/usr/bin/time -v输出的Maximum resident set size。2.2 框架级工具: 定位内存花在哪个模块如果是 Python 侧, 用 tracemalloc 或 memory_profiler:import tracemalloc tracemalloc.start() # 运行一次预热推理 run_inference(hello) current, peak tracemalloc.get_traced_memory() print(fcurrent{current / 1024 / 1024:.1f}MB peak{peak / 1024 / 1024:.1f}MB) tracemalloc.stop()如果是 PyTorch 后端, 直接查看显存分配汇总:python -c import torch; print(torch.cuda.memory_summary())如果 SLM 被包在 Java 服务里, 出现 JVM OOM 时抓堆转储:jmap -dump:live,formatb,fileheap.hprof pid然后用 Eclipse MAT 打开 hprof, 重点看 Dominator Tree 和 Leak Suspects。MAT 打开时如果报Failed to find main class, 通常是 JDK 版本或 PATH 问题, 配置好 JAVA_HOME、确认 JDK 17 及以上再启动即可。2.3 建立一张基线表采集完数据后, 建议记录成一张基线表:阶段指标期望状态进程启动RSS 增量只加载运行时, 不应暴涨模型加载峰值 RSS不超过总内存 50%, 留出 KV 空间短请求激活峰值记录 prefill 阶段最大值长上下文KV Cache 占用能按预算拒绝或降级并发请求内存叠加峰值叠加后仍低于硬限制基线的价值在于: 后续任何策略改动, 都能用同一组命令、同一份表做前后对比, 而不是靠感觉判断“好像稳定了”。3. 六个关键内存设计策略3.1 权重层: 量化选择加内存映射懒加载量化选择已经在上文说明。加载方式上, 推荐把权重文件做成内存映射, 也就是 mmap, 而不是一次torch.load全部读进内存。mmap 的好处有三点:操作系统按需从磁盘读页, 启动快, 不一次性占用全部内存;多个进程可以共享同一份映射页面, 减少重复占用;内存紧张时, 内核可以回收干净页, 再次访问时再从磁盘拉回, 形成自然的缓存淘汰。实际项目中, llama.cpp 一类的方案使用 mmap 就是这个思路。如果使用 PyTorch, 注意避免“全量 load 后再转 dtype”的写法, 峰值内存会翻倍。更稳妥的做法是逐层加载、量化、释放原始 buffer, 再进入下一层。3.2 KV Cache 层: 给每次请求做预算闸门KV Cache 不能等到运行时才发现不够, 要把预算计算放在请求入口。做法是:用模型结构参数算出每个 token 的 KV 字节数;请求进入时, 用“当前上下文长度 预计生成长度”申请预算;预算不足时直接拒绝请求, 或降级到短上下文模板, 而不是等生成到一半崩溃。这部分会在第 4 节给出最小实现。生产环境里, 预算不足的请求应当返回明确的限流错误码, 并记录指标, 方便后续判断是并发太高还是上下文太长。3.3 显存与内存分层: 显存不足时按需 offloadGPU 显存不够时, 常见做法是层间 offload: 把一部分 transformer 层放在 CPU 内存, 前向计算时再把需要的层搬到显存。速度会下降, 但可以换取更大的上下文或并发。学习环境可以直接接受较慢速度; 生产环境要评估 P99 延迟是否可接受, 并且要监控层搬移频率, 避免频繁交换导致吞吐崩盘。3.4 用共享内存复用权重如果一台机器上跑多个 SLM 实例, 或者一个网关后面挂多个推理 worker, 每个进程都加载一份 14GB 权重就是浪费。可以使用:mmap 共享权重文件: 内核 page cache 天然共享;fork 后写时复制: 只在写页面时才复制;同一进程内多模型并发: 权重共用, KV Cache 各自独立。注意: 共享内存解决的是 CPU 内存和磁盘页面的复用, 不会减少显存中的副本。如果多个 GPU 进程各自上传权重, 显存仍会重复占用。3.5 请求级缓存: 让重复 prompt 不重复算对本地服务来讲, 如果几十个请求都是同一类模板, 例如批量给同一文档生成摘要, 每次都重新推理会同时拉高内存和耗时。可以在服务内存里维护 LRU 缓存:key 为规范化后的 prompt 模型标识 采样参数;value 为已生成的文本, 不缓存流式中间状态;缓存命中时直接返回, 内存占用保持不变。这和浏览器开发者工具里的200 OK (from memory cache)不是一回事。浏览器缓存的是静态资源, SLM 要缓存的是推理结果; 但背后的原则类似: 减少重复计算就是减少峰值内存压力。3.6 分配器与运行时参数: 几个低成本的止损点实际项目常遇到“系统内存有余量, 但进程反复 OOM”的情况, 往往不是业务代码的问题, 而是运行时配置。PyTorch GPU 侧, 开启扩大段内存减少碎片:export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:Trueglibc malloc 多线程争用, 限制 arena 数量防止内存膨胀:export MALLOC_ARENA_MAX2JVM 侧, 显式设置堆和元空间上限:java -Xmx4g -XX:MaxMetaspaceSize512m -jar slm-server.jar这些参数不是银弹, 但通常是内存分析报告里最先出现的差异点。修改后必须重跑第 2 节的基线命令确认效果。4. 一个最小内存管理模块的实现4.1 设计目标与模块划分这一节实现一个最小可运行的演示模块, 解决三个问题: 加载权重不撑爆内存、长请求不会临时翻车、重复请求不会浪费推理。模块只做设计演示, 实际项目要按自己的模型格式、推理框架和开发语言调整。模块结构:memory_budget.py: 估算四类内存;weight_loader.py: mmap 加载权重;kv_gate.py: KV Cache 预算闸门;cache_manager.py: 请求结果缓存。4.2 内存预算计算器def estimate_memory( num_params: int, weight_bytes: int, num_layers: int, hidden_size: int, max_seq_len: int, batch_size: int, kv_bytes: int 2, ) - dict: weight_size num_params * weight_bytes kv_size 2 * num_layers * batch_size * max_seq_len * hidden_size * kv_bytes runtime max(weight_size * 0.1, 512 * 1024 * 1024) total weight_size kv_size runtime return { weight_mb: round(weight_size / 1024 / 1024, 1), kv_mb: round(kv_size / 1024 / 1024, 1), runtime_mb: round(runtime / 1024 / 1024, 1), total_mb: round(total / 1024 / 1024, 1), } print(estimate_memory(7_000_000_000, 2, 32, 4096, 2048, 1))这里把运行时开销粗略按权重的 10% 计, 同时给了 512MB 下限。实际项目应该用第 2 节实测数据替换估算值, 而不是沿用这个比例。4.3 权重 mmap 加载器import mmap import struct class WeightPage: def __init__(self, path: str): self._file open(path, rb) self._map mmap.mmap(self._file.fileno(), 0, accessmmap.ACCESS_READ) def read_fp16(self, offset: int) - float: return struct.unpack(e, self._map[offset : offset 2])[0] def slice(self, offset: int, size: int) - bytes: return self._map[offset : offset size] def close(self) - None: self._map.close() self._file.close()关键点: 这里没有把整个文件读进内存, 页面由操作系统按需加载, 进程关闭后页面会被回收。实际推理框架中, 这一层由 llama.cpp 的 mmap 或各框架的 safetensors 分片加载承担。4.4 KV Cache 预算闸门class KVGate: def __init__(self, max_memory_bytes: int, bytes_per_token: int): self._max max_memory_bytes self._bpt bytes_per_token self._used 0 def try_acquire(self, num_tokens: int) - bool: need num_tokens * self._bpt if self._used need self._max: return False self._used need return True def release(self, num_tokens: int) - None: self._used max(0, self._used - num_tokens * self._bpt)在请求入口调用try_acquire; 返回 False 时返回 429 或降级到短上下文模板, 而不是把请求放进推理队列。bytes_per_token要用第 2 节实测值, 不要用理论值, 因为不同 attention 实现的 KV 布局差异较大。4.5 请求结果缓存from functools import lru_cache lru_cache(maxsize128) def cached_generate(prompt: str, max_tokens: int 128) - str: return run_local_slm(prompt, max_tokens)生产环境不要直接用lru_cache, 因为缓存 value 是字符串, 可能非常大。建议改用带 TTL 和条目大小上限的缓存组件, 例如cachetools.TTLCache, 并且把缓存命中率作为独立指标上报。5. 运行验证与结果分析5.1 预期输出解读运行内存预算计算器会得到类似输出:{weight_mb: 13421.8, kv_mb: 1092.2, runtime_mb: 1342.2, total_mb: 15856.1}这个输出说明: 模型权重占 13GB, KV Cache 占 1GB, 运行时约 1.3GB, 总共约 15GB 预算。如果机器只有 
长河君 · 2026/8/29 17:28:30 · 阅读 1.2k 本地SLM内存设计：掌控OOM与KV Cache的完整方法
本地 SLM(Small Language Model, 小型语言模型)的内存设计, 直接决定一个模型是能流畅运行, 还是一启动就让整机开始交换分区。和云端大模型不同, 本地 SLM 的推理环境通常只有一块消费级显卡、16GB 到 64GB 内存, 甚至只有 CPU 可用。此时内存不是“把模型文件读进来”这么简单: 权重、KV Cache、激活值、框架分配器、外部进程开销会在同一时刻叠加, 任何一个环节超限, 都可能触发 out of memory、segmentation fault, 或者服务端请求大面积超时。这篇博客围绕 “A Memory Design for Local SLM” 这个主题, 按“内存组成 - 基线测量 - 设计策略 - 最小实现 - 运行验证 - 问题排查 - 生产清单”的顺序, 整理一套可以直接复用的内存设计方法。读完以后, 你会清楚本地模型的内存到底花在哪里、怎么先测量再设计、遇到 OOM 时应该从哪一层开始查。1. 先拆清本地 SLM 的四类内存开销很多内存问题都源于把“模型权重占多大”当成了“整个进程占多大”。实际推理过程中, 内存由四类开销构成, 必须分开估算, 否则到了长文本场景一定会被 KV Cache 打穿。1.1 模型权重: 参数数量乘以精度字节数, 最直观但最容易误判权重内存的计算公式是:权重内存 参数数量 x 每个参数占用的字节数举个例子, 一个 70 亿参数的模型, 用 FP32 加载是 28GB, 用 FP16 是 14GB, 用 INT8 约 7GB, 用 INT4 约 3.5GB。常见精度与占用如下表:精度每参数字节数7B 模型权重占用适用场景FP324 字节28GB训练或精度对照, 本地推理很少用FP16/BF162 字节14GB精度与内存均衡, 有独显时首选INT81 字节约 7GB精度损失小, 16GB 内存在边缘INT4/AWQ/GPTQ0.5 字节左右约 3.5GB内存紧张、追求长上下文时常用这里容易误解的一点是: 量化不只是省磁盘, 它最直接的作用是把权重放进内存预算。但 INT4 模型在解码时通常需要反量化计算, 会额外消耗少量 CPU/GPU 算力。所以“哪个精度合适”要同时看内存余量和算力, 不能只看能不能加载。和硬件相关的还有一个重要维度: 本地推理的瓶颈常常不是容量, 而是内存带宽。双通道、四通道内存以及 DDR 代数, 直接决定权重读取速度。设计文档里最好把“容量”和“带宽”分开记录, 否则会出现容量够、推理却慢到不可用的情况。1.2 KV Cache: 随上下文线性增长, 最容易在长对话中失控KV Cache 是每生成一个新 token 都需要存下来的 Key 和 Value 张量, 大小随层数、batch、序列长度、隐层维度线性增长:KV Cache 字节数 ≈ 2 x 层数 x batch x 当前序列长度 x 隐层维度 x 精度字节数以 32 层、隐层 4096、单请求、FP16 为例:2 x 32 x 1 x 2048 x 4096 x 2 ≈ 1.07GB也就是说, 2048 token 的上下文大约占用 1GB; 如果并发 8 个请求, 就是 8GB。很多模型在短输入时内存正常, 用户多轮对话一拉长就立刻 OOM, 根因就是 KV Cache 没有预算控制。方案层面对应两个方向: 一是选 GQA/MQA 模型, 减少 KV 头数量; 二是用 sliding window attention, 让历史 KV 被淘汰。选模型和服务设计时都要提前确认这些能力是否存在。1.3 激活值与运行时开销: 平时不起眼, 峰值时最致命激活值是前向计算中的中间张量。首 token 阶段, 也就是 prefill 阶段, 要一次性处理整段 prompt, 激活峰值通常出现在这里; 后续 token 逐个生成, 激活值反而小。对 7B 级别模型, CPU 推理时激活值可能只占几百 MB, 但 GPU 推理时如果 batch 设置过大, 或者 attention 实现不高效, 激活峰值可能达到数 GB。运行时开销还包括下面几类:CUDA context: 约 300MB 到 500MB;PyTorch、ONNX Runtime 等框架的缓存分配器: 可能保留空闲块, 不立即归还系统;如果 SLM 服务外面还套了 Spring Boot、网关或 Agent 进程, JVM 堆、Node.js 堆也要单独计入。很多“实际内存还没用到一半却报 OOM”的现场, 就是漏掉了运行时开销和容器限制。这里先记住: 权重不是全部, KV Cache 按长度增长, 激活值看峰值, 运行时要留余量。2. 先测量基线再设计, 否则策略全是拍脑袋2.1 系统级命令: 看进程真实占用设计内存之前, 必须先知道当前基线。测量命令如下:/usr/bin/time -v python run_slm.py 21 | grep -E Maximum resident|User time|System timeGPU 侧看显存:nvidia-smi --query-gpumemory.used,memory.total,utilization.gpu --formatcsv进程粒度的内存分布:pmap -x $(pgrep -f run_slm.py) | tail -n 5这里要区分 RSS 和 VSZ。RSS 是实际驻留物理内存, VSZ 是虚拟地址空间。Linux OOM killer 主要依据物理内存和页面缓存占比来判断, 因此重点看 RSS, 以及/usr/bin/time -v输出的Maximum resident set size。2.2 框架级工具: 定位内存花在哪个模块如果是 Python 侧, 用 tracemalloc 或 memory_profiler:import tracemalloc tracemalloc.start() # 运行一次预热推理 run_inference(hello) current, peak tracemalloc.get_traced_memory() print(fcurrent{current / 1024 / 1024:.1f}MB peak{peak / 1024 / 1024:.1f}MB) tracemalloc.stop()如果是 PyTorch 后端, 直接查看显存分配汇总:python -c import torch; print(torch.cuda.memory_summary())如果 SLM 被包在 Java 服务里, 出现 JVM OOM 时抓堆转储:jmap -dump:live,formatb,fileheap.hprof pid然后用 Eclipse MAT 打开 hprof, 重点看 Dominator Tree 和 Leak Suspects。MAT 打开时如果报Failed to find main class, 通常是 JDK 版本或 PATH 问题, 配置好 JAVA_HOME、确认 JDK 17 及以上再启动即可。2.3 建立一张基线表采集完数据后, 建议记录成一张基线表:阶段指标期望状态进程启动RSS 增量只加载运行时, 不应暴涨模型加载峰值 RSS不超过总内存 50%, 留出 KV 空间短请求激活峰值记录 prefill 阶段最大值长上下文KV Cache 占用能按预算拒绝或降级并发请求内存叠加峰值叠加后仍低于硬限制基线的价值在于: 后续任何策略改动, 都能用同一组命令、同一份表做前后对比, 而不是靠感觉判断“好像稳定了”。3. 六个关键内存设计策略3.1 权重层: 量化选择加内存映射懒加载量化选择已经在上文说明。加载方式上, 推荐把权重文件做成内存映射, 也就是 mmap, 而不是一次torch.load全部读进内存。mmap 的好处有三点:操作系统按需从磁盘读页, 启动快, 不一次性占用全部内存;多个进程可以共享同一份映射页面, 减少重复占用;内存紧张时, 内核可以回收干净页, 再次访问时再从磁盘拉回, 形成自然的缓存淘汰。实际项目中, llama.cpp 一类的方案使用 mmap 就是这个思路。如果使用 PyTorch, 注意避免“全量 load 后再转 dtype”的写法, 峰值内存会翻倍。更稳妥的做法是逐层加载、量化、释放原始 buffer, 再进入下一层。3.2 KV Cache 层: 给每次请求做预算闸门KV Cache 不能等到运行时才发现不够, 要把预算计算放在请求入口。做法是:用模型结构参数算出每个 token 的 KV 字节数;请求进入时, 用“当前上下文长度 预计生成长度”申请预算;预算不足时直接拒绝请求, 或降级到短上下文模板, 而不是等生成到一半崩溃。这部分会在第 4 节给出最小实现。生产环境里, 预算不足的请求应当返回明确的限流错误码, 并记录指标, 方便后续判断是并发太高还是上下文太长。3.3 显存与内存分层: 显存不足时按需 offloadGPU 显存不够时, 常见做法是层间 offload: 把一部分 transformer 层放在 CPU 内存, 前向计算时再把需要的层搬到显存。速度会下降, 但可以换取更大的上下文或并发。学习环境可以直接接受较慢速度; 生产环境要评估 P99 延迟是否可接受, 并且要监控层搬移频率, 避免频繁交换导致吞吐崩盘。3.4 用共享内存复用权重如果一台机器上跑多个 SLM 实例, 或者一个网关后面挂多个推理 worker, 每个进程都加载一份 14GB 权重就是浪费。可以使用:mmap 共享权重文件: 内核 page cache 天然共享;fork 后写时复制: 只在写页面时才复制;同一进程内多模型并发: 权重共用, KV Cache 各自独立。注意: 共享内存解决的是 CPU 内存和磁盘页面的复用, 不会减少显存中的副本。如果多个 GPU 进程各自上传权重, 显存仍会重复占用。3.5 请求级缓存: 让重复 prompt 不重复算对本地服务来讲, 如果几十个请求都是同一类模板, 例如批量给同一文档生成摘要, 每次都重新推理会同时拉高内存和耗时。可以在服务内存里维护 LRU 缓存:key 为规范化后的 prompt 模型标识 采样参数;value 为已生成的文本, 不缓存流式中间状态;缓存命中时直接返回, 内存占用保持不变。这和浏览器开发者工具里的200 OK (from memory cache)不是一回事。浏览器缓存的是静态资源, SLM 要缓存的是推理结果; 但背后的原则类似: 减少重复计算就是减少峰值内存压力。3.6 分配器与运行时参数: 几个低成本的止损点实际项目常遇到“系统内存有余量, 但进程反复 OOM”的情况, 往往不是业务代码的问题, 而是运行时配置。PyTorch GPU 侧, 开启扩大段内存减少碎片:export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:Trueglibc malloc 多线程争用, 限制 arena 数量防止内存膨胀:export MALLOC_ARENA_MAX2JVM 侧, 显式设置堆和元空间上限:java -Xmx4g -XX:MaxMetaspaceSize512m -jar slm-server.jar这些参数不是银弹, 但通常是内存分析报告里最先出现的差异点。修改后必须重跑第 2 节的基线命令确认效果。4. 一个最小内存管理模块的实现4.1 设计目标与模块划分这一节实现一个最小可运行的演示模块, 解决三个问题: 加载权重不撑爆内存、长请求不会临时翻车、重复请求不会浪费推理。模块只做设计演示, 实际项目要按自己的模型格式、推理框架和开发语言调整。模块结构:memory_budget.py: 估算四类内存;weight_loader.py: mmap 加载权重;kv_gate.py: KV Cache 预算闸门;cache_manager.py: 请求结果缓存。4.2 内存预算计算器def estimate_memory( num_params: int, weight_bytes: int, num_layers: int, hidden_size: int, max_seq_len: int, batch_size: int, kv_bytes: int 2, ) - dict: weight_size num_params * weight_bytes kv_size 2 * num_layers * batch_size * max_seq_len * hidden_size * kv_bytes runtime max(weight_size * 0.1, 512 * 1024 * 1024) total weight_size kv_size runtime return { weight_mb: round(weight_size / 1024 / 1024, 1), kv_mb: round(kv_size / 1024 / 1024, 1), runtime_mb: round(runtime / 1024 / 1024, 1), total_mb: round(total / 1024 / 1024, 1), } print(estimate_memory(7_000_000_000, 2, 32, 4096, 2048, 1))这里把运行时开销粗略按权重的 10% 计, 同时给了 512MB 下限。实际项目应该用第 2 节实测数据替换估算值, 而不是沿用这个比例。4.3 权重 mmap 加载器import mmap import struct class WeightPage: def __init__(self, path: str): self._file open(path, rb) self._map mmap.mmap(self._file.fileno(), 0, accessmmap.ACCESS_READ) def read_fp16(self, offset: int) - float: return struct.unpack(e, self._map[offset : offset 2])[0] def slice(self, offset: int, size: int) - bytes: return self._map[offset : offset size] def close(self) - None: self._map.close() self._file.close()关键点: 这里没有把整个文件读进内存, 页面由操作系统按需加载, 进程关闭后页面会被回收。实际推理框架中, 这一层由 llama.cpp 的 mmap 或各框架的 safetensors 分片加载承担。4.4 KV Cache 预算闸门class KVGate: def __init__(self, max_memory_bytes: int, bytes_per_token: int): self._max max_memory_bytes self._bpt bytes_per_token self._used 0 def try_acquire(self, num_tokens: int) - bool: need num_tokens * self._bpt if self._used need self._max: return False self._used need return True def release(self, num_tokens: int) - None: self._used max(0, self._used - num_tokens * self._bpt)在请求入口调用try_acquire; 返回 False 时返回 429 或降级到短上下文模板, 而不是把请求放进推理队列。bytes_per_token要用第 2 节实测值, 不要用理论值, 因为不同 attention 实现的 KV 布局差异较大。4.5 请求结果缓存from functools import lru_cache lru_cache(maxsize128) def cached_generate(prompt: str, max_tokens: int 128) - str: return run_local_slm(prompt, max_tokens)生产环境不要直接用lru_cache, 因为缓存 value 是字符串, 可能非常大。建议改用带 TTL 和条目大小上限的缓存组件, 例如cachetools.TTLCache, 并且把缓存命中率作为独立指标上报。5. 运行验证与结果分析5.1 预期输出解读运行内存预算计算器会得到类似输出:{weight_mb: 13421.8, kv_mb: 1092.2, runtime_mb: 1342.2, total_mb: 15856.1}这个输出说明: 模型权重占 13GB, KV Cache 占 1GB, 运行时约 1.3GB, 总共约 15GB 预算。如果机器只有