在本地跑大模型时很多人会先看算力CPU是几核GPU有多少 TOPS。结果真正跑起来却发现设备明明算力不差生成速度却始终提不上去。这个现象背后的关键瓶颈往往不是计算单元而是内存带宽。最近讨论度很高的 Xiaomi AI Cube 就是一款把“近内存带宽”做到 1.22 TB/s 的本地 LLM 硬件方案。本文不打算只堆参数而是从内存带宽与 LLM 推理的关系出发拆解这个指标意味着什么并给出在高带宽设备上部署、测试本地大模型的一套可复用思路。1. 背景与核心概念1.1 LLM 推理的访存瓶颈大语言模型Large Language ModelLLM的推理过程本质上由两大部分组成Prefill 和 Decode。Prefill 阶段负责处理用户输入的 Prompt一次性生成第一轮计算的 KV CacheDecode 阶段则逐个生成 Token是用户在对话界面中等待得最久的部分。很多开发者在刚接触 LLM 推理优化时会把注意力放在“每秒多少 FLOPs”上。但在实际部署中LLM 推理尤其是单用户交互场景里的 Decode 过程往往是一个访存密集型任务。每一次生成一个新的 Token都需要把模型权重从头到尾读一遍。也就是说模型越大生成单个 Token 需要搬移的数据量就越大。这里可以用一个简单的估算来帮助理解一个 7B 参数的模型以 FP16 精度存储权重大小约为 14GB。每生成 1 个 Token理想情况下至少需要从内存中读取全部权重。如果内存带宽只有 100GB/s那么生成 1 个 Token 的最短耗时也在 140ms 左右换算下来只有 7 tokens/s。如果把内存带宽提升到 1TB/s 级别生成 1 个 Token 的访存耗时可以降到 14ms 左右对应约 70 tokens/s。这个对比清楚说明了一个结论在本地 LLM 场景中带宽往往比纯算力更早成为天花板。很多 CPU 平台的算力并非不够而是权重数据“喂”不过去导致计算单元一直在等待。1.2 什么是近内存带宽近内存带宽Near-Memory Bandwidth并不是一个全新的概念它脱胎于近内存计算Near-Memory Computing思想。传统计算机的内存带宽指的是内存控制器与内存颗粒之间、或者内存条与 CPU/GPU 之间的数据传输速率。数据需要在 DRAM、缓存、计算单元之间来回搬运物理链路越长延迟越高带宽越容易受限。近内存计算把计算单元物理上做得更靠近内存甚至把部分计算逻辑放进存储控制器的附近从而大幅缩短数据搬运路径。这样做的好处有三个降低访存延迟。提升单位功耗下的数据吞吐能力。避免传统外部总线接口成为性能瓶颈。Xiaomi AI Cube 提到的 1.22 TB/s 近内存带宽翻译成更直观的说法就是计算单元和存储之间最核心的数据通道峰值可以达到每秒 1.22 太字节级别。这个量级通常已经远超普通 PC 的 DDR4/DDR5 内存带宽也比很多入门级独立显卡的显存带宽更高。需要注意的是近内存带宽与常见的“显存带宽”“系统内存带宽”并不完全等同。它们之间的区别可以简单理解成不同位置的数据通路带宽类型常见位置典型量级主要用途系统内存带宽CPU 与 DDR 内存之间几十 GB/s 到上百 GB/s常规程序运行、文件缓存显存带宽GPU 与显存之间数百 GB/s 到 TB/s 级别图形渲染、AI 训练、模型推理近内存带宽计算单元与近邻存储之间数百 GB/s 到 TB/s 级别边缘 AI 推理、端侧 LLM、存算优化从这张表可以看到1.22 TB/s 本身是很有竞争力的数字但它是不是能在真实业务中完全发挥出来还要看软件栈、访存模式和数据容量是否匹配。1.3 Xiaomi AI Cube 是什么根据现有公开信息Xiaomi AI Cube 是一款面向本地 LLM 推理场景的 AI 计算设备。它的核心定位不是“跑分最高”而是把大模型部署到普通用户可以接触到的本地环境中让数据不必上传到云端也能完成高质量对话、代码生成和知识问答。从产品命名和宣传点来看AI Cube 强调“Local LLMs”和“Near-Memory Bandwidth”说明它重点解决的是端侧部署大模型时的两个现实问题内存容量能不能把模型放进去。内存带宽能不能把模型权重及时“喂”给计算单元。目前官方并没有把完整的芯片架构、内存颗粒型号和软件 SDK 全部公开因此本文不会去猜测具体的硬件设计。但我们可以把 1.22 TB/s 当成一个近期值得关注的硬件指标围绕它展开原理分析和部署实践。2. 硬件指标解读1.22 TB/s 意味着什么2.1 数字换算与实际体验先来做单位换算。计算机行业经常出现 TB 和 TiB 混用的问题1 TB/s 1000 GB/s这是十进制换算。1 TiB/s 1024 GiB/s这是二进制换算。如果厂商按十进制标注1.22 TB/s 等于 1220 GB/s如果是二进制标准则约等于 1249 GB/s。大多数消费级产品的标称带宽习惯使用十进制所以我们在估算时可以按 1220GB/s 处理。把这个带宽代入前面的 7B FP16 模型例子中权重 14GB。读取耗时理想值14GB ÷ 1220GB/s ≈ 11.5ms。每秒最多可以完成约 87 次全量权重读取也就是理论极限约 87 tokens/s。在实际运行中Decode 阶段还需要读取 KV Cache同时计算单元也不可能把全部时间都花在内存读取上所以实际流畅速度通常要打折扣。但即便只有理论值的 60% 到 70%也能做到每秒 50 到 60 个 Token。对于本地对话、文档摘要、代码补全这类场景这个速度已经足够日常使用。下面这个 Python 脚本可以帮你快速做带宽到 token 速度的换算# 文件路径scripts/estimate_bandwidth.py def estimate_tokens_per_second( model_size_b: float, bits_per_weight: int 16, bandwidth_gbps: float 1220.0, ): 根据模型大小、量化精度和带宽估算理论解码速度。 参数说明 model_size_b : 模型参数数量单位是 B10 亿。 bits_per_weight : 每个权重占用的 bit 数。FP16 为 16INT8 为 8INT4 为 4。 bandwidth_gbps : 内存带宽单位是 GB/s。 weight_bytes model_size_b * 1e9 * (bits_per_weight / 8) time_per_token_ms weight_bytes / bandwidth_gbps * 1000 tokens_per_second 1000 / time_per_token_ms return weight_bytes, time_per_token_ms, tokens_per_second if __name__ __main__: for bits in (16, 8, 4): total_bytes, time_ms, tps estimate_tokens_per_second(7, bits, 1220) print(fbits{bits:2} 权重{total_bytes / 1e9:.2f}GB 理论耗时{time_ms:.2f}ms token/s{tps:.1f})运行结果会显示量化确实能把权重体积和访存时间压到很低的水平。这也是为什么本地 LLM 方案普遍推荐使用 4bit 量化模型。2.2 与常见平台的带宽对比为了更直观地感受 1.22 TB/s 的定位可以把它和开发者在 PC 上经常使用的平台做对比平台类型典型内存带宽对 7B FP16 模型的单 Token 理论读取耗时普通 DDR4 PC约 30-50GB/s280-470msDDR5 PC约 60-80GB/s175-233ms高端游戏显卡约 600-1000GB/s14-23msAI Cube 近内存带宽约 1220GB/s约 11.5ms需要说明的是上面的游戏显卡数据是显存带宽不是 CPU 内存带宽。如果你的模型权重保存在系统内存中那么即使显卡本身带宽很高也会受到 PCIe 或统一内存接口的限制。小米 AI Cube 的 1.22 TB/s 如果能在实际软件栈中稳定发挥它的单 Token 权重读取速度会非常接近中高端独立显卡的显存读取速度。对于不能使用显卡、或者希望控制功耗和体积的边缘设备来说这是一个很有参考意义的路线。2.3 带宽与可运行模型规模的关系带宽决定的是模型运行速度容量决定的是能不能运行模型。因此带宽再高也需要匹配足够的内存空间。以常见量化精度为参考不同参数规模的模型体积大致如下模型规模FP16INT8INT47B约 14GB约 7GB约 4GB13B约 26GB约 13GB约 7GB33B约 66GB约 33GB约 18GB70B约 140GB约 70GB约 40GB如果一台设备只有 16GB 可用内存那么跑 FP16 的 7B 模型已经比较吃力跑 INT4 的 13B 模型则相对合适。若设备内存能够达到 32GB 以上INT4 的 33B 模型也可以放到本地推理。这里还要提醒一点模型权重之外上下文窗口和 KV Cache 也会占用额外内存。上下文越长KV Cache 占用越大。所以“内存容量刚好能装下权重”并不等于能正常跑长文本。3. 本地 LLM 部署的核心原理3.1 Prefill 与 Decode 的差异部署过模型的人都知道第一次提问时等待时间往往很长但后续回复却是逐字出现。这个现象背后的原因就是 Prefill 和 Decode 的计算特征不同。Prefill 阶段要处理整个 Prompt属于计算密集任务。它需要把输入文本的所有 Token 并行带入模型计算因此算力越强首 Token 延迟越低。Decode 阶段是逐 Token 生成每一步只能计算一个 Token这个过程很难完全并行化而且每一步都要重新读取全量权重。即使算力再强如果内存带宽不够每一步都会被卡在访存上。在交互式对话场景中用户对首 Token 延迟和后续 Token 速度都很敏感。一个典型的本地 LLM 硬件方案如果想要体验流畅至少要在 Decode 阶段提供足够的带宽。这也是为什么 1.22 TB/s 近内存带宽会比单纯宣传 TOPS 更有说服力。3.2 量化如何影响带宽需求权重精度越低单个权重占用的字节数越少读取同样参数所需的总数据量就越小。假设一个 7B 模型FP16每个权重 2 字节总权重约 14GB。INT8每个权重 1 字节总权重约 7GB。INT4每个权重 0.5 字节总权重约 3.5GB 到 4GB。这意味着在相同带宽下使用 INT4 模型可以把读取权重的时间缩短到 FP16 的四分之一。用 1220GB/s 带宽计算FP16 7B 模型理论约为 87 tokens/sINT4 7B 模型理论上可以冲到 300 tokens/s 以上虽然实际还会受其他因素限制但量化带来的收益非常明显。不过量化也不是越低越好。INT4 可能导致模型精度下降在复杂推理、数学计算、非中文场景下更容易出现错误。工程上需要根据业务场景在速度和效果之间取平衡。通常在通用对话场景中Q4_K_M、Q5_K_M 这类量化格式是比较稳妥的选择。3.3 KV Cache 的隐藏成本KV Cache 是 LLM 推理中另一个容易被忽视的访存项。它用来保存已处理 Token 的 Key 和 Value 向量避免每一步重新计算历史信息。KV Cache 的大小取决于模型层数、注意力头数、隐藏层维度和上下文长度。以 7B 级别模型为例在 4096 上下文长度下KV Cache 可能占用几百 MB 到 1GB 以上。如果上下文长度扩展到 32K 甚至 128KKV Cache 会成倍增长。KV Cache 对带宽的影响是Token 生成越多历史信息越长每一步需要读取和写入的 KV Cache 就越大。再加上全量模型权重复读取高带宽设备的优势会被长期对话场景进一步放大。反过来如果内存带宽不足长上下文对话的生成速度会随着对话变长而明显下降。4. 实战面向高带宽设备的本地 LLM 部署思路4.1 创建项目结构虽然 Xiaomi AI Cube 的完整 SDK 还没有大规模开放但高带宽本地推理设备在软件层面通常可以沿用当前主流的大模型推理栈。下面我们使用 llama.cpp 生态作为示例演示一套通用的部署和基准测试流程。先创建一个干净的项目目录mkdir -p local-llm/models mkdir -p local-llm/scripts cd local-llm项目结构建议如下local-llm/ ├── models/ │ └── qwen2-7b-instruct-q4_k_m.gguf ├── scripts/ │ ├── estimate_bandwidth.py │ ├── run_llama_cpp.py │ └── benchmark_decode.py └── README.mdmodels目录存放 GGUF 格式的量化模型文件scripts目录存放加载和测试脚本。这里的模型示例选用常见的 Qwen2 7B Instruct实际部署时可以根据设备内存容量换成其他模型。4.2 安装依赖与编译推理引擎llama.cpp 是一个支持 GGUF 模型格式的轻量推理项目也是本地 LLM 部署中非常常见的方案。它既可以用官方预编译二进制也可以从源码编译。最简单的安装方式是通过 Python 的llama-cpp-python包pip install llama-cpp-python如果设备是 ARM 架构或需要针对特定指令集优化推荐先从源码编译git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp make -j4编译完成后可以先用内置的帮助命令确认版本./llama-cli --help | head -n 20在这类设备上运行时需要关注编译参数是否启用了当前平台支持的向量扩展。如果软件栈还未适配某款新芯片可以先关闭硬件加速运行让推理引擎以内存带宽友好的方式执行再逐步开启优化开关。4.3 加载模型并预热使用llama-cpp-python加载模型时最关键的两个参数是model_path和n_gpu_layers。在普通 CPU 设备上n_gpu_layers可以设置为 0如果设备提供 GPU 或 NPU 后端则可以根据支持情况传入-1表示尽量将层加载到加速器。下面是一段加载模型并进行简单对话的代码# 文件路径scripts/run_llama_cpp.py from llama_cpp import Llama llm Llama( model_pathmodels/qwen2-7b-instruct-q4_k_m.gguf, n_ctx2048, n_gpu_layers-1, ) output llm( 请用一句话介绍内存带宽对自然语言处理的影响。, max_tokens128, temperature0.7, echoFalse, ) print(output[choices][0][text])这段代码的作用是把模型权重载入内存并在推理时生成一段简短回复。n_ctx2048表示上下文窗口为 2048 Token如果你需要使用长文档摘要可以适当调大但要留意 KV Cache 对内存容量的占用。模型加载完成后第一次推理通常会有预热成本比如 KV Cache 初始化、内存页分配、线程池启动等。所以正式跑性能测试之前最好先执行一次短输出排除初始化阶段的影响。4.4 编写解码性能测试脚本性能测试的重点放在 Decode 阶段。最简单的方式是固定输入 Prompt让模型连续生成 256 个 Token然后统计总耗时。# 文件路径scripts/benchmark_decode.py import time from llama_cpp import Llama llm Llama( model_pathmodels/qwen2-7b-instruct-q4_k_m.gguf, n_ctx2048, n_gpu_layers-1, ) prompt 请列举内存带宽在大模型推理中的重要性 # 预热 llm(prompt, max_tokens16) start time.perf_counter() output llm(prompt, max_tokens256) elapsed time.perf_counter() - start generated_text output[choices][0][text] token_count len(output[choices][0][text]) print(f生成耗时: {elapsed:.2f} 秒) print(f输出文本长度: {token_count} 字符) print(f平均速度(字符/秒): {token_count / elapsed:.2f})这里的“字符数/秒”并不是严格意义上的 tokens/s因为中文字符和 Token 并不完全等同。更精确的测试可以直接读取 llama.cpp 返回的 usage 字段其中会包含completion_tokens和total_tokens。如果需要命令行级别的权威测试可以运行 llama.cpp 自带的 benchmark。在源码目录下执行./llama-bench -m ../local-llm/models/qwen2-7b-instruct-q4_k_m.gguf -p 64 -n 256其中-p 64表示使用 64 Token 的输入-n 256表示生成 256 Token。llama-bench 会分别输出 Prompt 处理和生成阶段的数据是排查性能瓶颈的实用工具。4.5 结果解读与瓶颈定位拿到测试结果后不要只看一个综合速度要分别看Prefill 阶段 Token/s反映算力上限。Decode 阶段 Token/s反映内存带宽和访存优化水平。平均内存占用判断是否接近容量上限。如果在高带宽设备上 Decode 速度依然很低优先检查是否启用了正确的加速后端以及模型是否存放在高带宽内存区域。很多设备会同时存在普通内存和近内存如果模型被加载到慢速内存即使硬件标称带宽再高也无法体现。还可以用perf或/proc/meminfo观察内存带宽压力perf stat -e cache-misses,instructions ./llama-cli -m models/qwen2-7b-instruct-q4_k_m.gguf -p 测试 -n 64需要注意的是perf在不同平台上支持的事件名可能不同嵌入式设备上可能需要换成 vendor 私有的 profiling 工具。性能测试最重要的原则是先确认数据确实在目标存储区域再讨论带宽利用率。5. 常见误区与排查思路5.1 常见误区误区实际情况1.22 TB/s 等于外接接口带宽这是近内存带宽不一定是 PCIe/USB 等外部接口带宽内存带宽高就能运行任意大模型还要看内存容量、量化格式、上下文长度带宽越高Prefill 一定越快Prefill 更依赖算力带宽主要影响 Decode量化会让模型完全不能商用4bit 量化在多数通用任务中效果好但需要针对场景验证峰值带宽等于实际带宽实际访存可能无法打满峰值特别是小模型逐 Token 推理时5.2 带宽够高但生成慢的排查清单如果遇到“设备带宽很高但跑模型速度不理想”的情况可以按下面顺序排查第一步检查模型是否真的被加载到高带宽内存区域。对于近内存计算设备来说数据摆放位置可能决定了性能数量级。第二步检查是否开启了硬件加速。部分推理框架默认只使用 CPU或者没有识别到新增的 AI 算子。第三步检查上下文长度。如果n_ctx设置得非常大KV Cache 可能占用了大量带宽和内存导致有效带宽下降。第四步检查推理框架版本。新芯片通常需要配合新版本的编译器和内核模块旧版本可能无法利用指令集或内存控制器特性。第五步检查是否统计了完整的端到端耗时。用户点击按钮到看到第一个字的时间包含模型加载、Prompt 处理、网络传输等多个环节不能全部归罪于 Decode 速度。5.3 实际部署中的常见问题问题现象常见原因解决思路设备内存足够但 OOM上下文过长导致 KV Cache 膨胀调低 n_ctx或使用更强量化模型总是输出乱码量化格式不兼容或采样参数异常检查 GGUF 元数据重置 sampler 参数生成速度越来越慢对话历史太长KV Cache 持续增长使用摘要裁剪历史或限制最大长对话轮数设备发热严重未做频率控制持续满载推理开启功耗限制选择更小模型多个用户同时访问卡顿推理进程串行排队引入动态批处理或服务化框架6. 最佳实践与工程建议6.1 模型大小和量化格式的选择在高带宽但容量有限的设备上最优策略是“用 4bit 量化保持模型规模用上下文管理控制 KV Cache”。日常对话场景中7B 到 14B 级别的量化模型是性价比最高的区间。需要处理复杂代码或者更强数学能力时可以直接测试 32B 以上模型但要为内存容量留出余量。量化格式的选择可以参考一个简单原则先跑通 Q4_K_M再根据效果逐步升级到 Q5_K_M 或 Q8_0。不要在刚开始部署时追求极端低比特因为这会给后续排错增加复杂度。6.2 日志和可观测性生产环境使用本地 LLM 时一定要记录模型版本、推理框架版本、Prompt 长度、Token 耗时和错误信息。建议每次更新模型后跑一遍标准测试集生成一份基线报告。日志同时要注意隐私边界。本地 LLM 虽然把数据留在了设备上但日志中如果包含用户输入原文依然可能造成敏感信息泄露。在多人使用或企业内网部署时建议对日志中的 Prompt 做脱敏处理。6.3 权限控制和最小化原则如果 AI Cube 被部署成局域网内可访问的服务需要设置身份认证和访问控制避免任意进程加载模型或修改配置。不要直接使用默认端口和管理密码也不要给推理服务分配不必要的系统权限。涉及模型文件替换、系统固件升级等操作时先备份原有权重和配置在测试环境验证后再更新。模型文件往往有几个 GB 到几十 GB备份策略要考虑磁盘占用建议保留最近两个可用版本方便快速回滚。6.4 性能优化参考方向部署完第一版后可以从三个方向继续优化动态批处理把多个并发请求拼成一个 Batch提高整体吞吐适合服务化场景。投机采样用小模型先生成候选 Token再用大模型验证降低延迟。上下文压缩对长文档做分段检索或摘要减少 KV Cache 压力。这些优化方向并不是互相排斥的但它们对软件栈的要求更高需要等设备 SDK 和推理框架适配完成后逐步引入。7. 总结与后续关注Xiaomi AI Cube 的 1.22 TB/s 近内存带宽让本地 LLM 推理又多了一种值得参考的硬件路线。通过本文的拆解可以明确一个关键认知大模型生成 Token 的瓶颈是内存带宽而不是单纯的算力数字。高带宽设备如果配合量化模型和合理的上下文管理完全可以在本地实现流畅的对话体验。拿到真实设备或 SDK 之后建议按下面的顺序做验证先跑llama-bench确认 Decode 阶段的基础带宽表现。再跑一个标准测试集评估不同量化模型的效果和速度。最后做长上下文测试观察 KV Cache 增长对生成速度的影响。如果只是停留在纸面参数上1.22 TB/s 只是一个好看的数字只有把它放进真实推理链路里测试才能确定它到底适合哪些模型、哪些场景。这也是本地 LLM 硬件选型中最值得投入时间的地方。