Airgorah 厂商识别揭秘：编译期生成 OUI 表，MAC 地址秒变设备品牌
2026/9/28 20:47:57
32GB 统一内存笔记本跑 15B 大模型？338H + OpenVINO INT8 的内存真相：显存划拨不动账面、页面文件才是真门槛
作者：玛小扣（Koda，与自研 agent 风火轮 17 协作完成实测）
机器：Intel Core Ultra 5 338H / 32GB LPDDR5x 统一内存 / Arc B370 iGPU / 1TB NVMe / Windows 11
模型：Marco-MT-Algharb（15B，Qwen3-14B 底座）INT8 量化版，已开源：modelscope.cn/models/fcpaul/Marco-MT-Algharb-ov-int8
标签建议：#OpenVINO #Intel Arc #大模型推理 #量化 #LLM #统一内存 #AIPC
摘要
在 32GB 统一内存的 Intel 338H 轻薄本上，我们把 15B 级翻译模型做了 INT8 量化全流程：导出 3 分 50 秒零 OOM 一次通过，推理 7.4 tokens/s。全程没有出现"32GB 机器导出高危 OOM"——因为三个实测观测揭示了 Arrow Lake-H 统一内存的真实玩法：显存划拨根本不动 Windows 的内存账面（GPU"专用显存"是驱动层重标记）、OpenVINO 可以直接问出 GPU 池大小、而页面文件才是导出型任务的真正门槛。文末附一个基于这套物理基础的推理分层脑洞（热专家驻显存池、冷专家走 SSD 页面文件），供同硬件（338H/358H/388H）的朋友拍砖。
一、TL;DR：三个观测
- 显存划拨不动 OS 账面。Intel Graphics Software 划 20GB"专用共享显存"给 iGPU 后，Windows 报告的物理内存纹丝不动（31.5GB）。所谓"专用显存"是统一内存里的驱动层访问权划分，不是容量扣减——CPU 和 GPU 从头到尾看着同一堆 LPDDR5x。
- GPU 池大小可以直接问出来。OpenVINO 运行时属性一行代码：
fromopenvinoimportCore core=Core()size=core.get_property("GPU","GPU_DEVICE_TOTAL_MEM_SIZE")# 实测 25956442112 ≈ 24.2 GiB（20GB 划拨 + 动态共享窗口）- 页面文件是导出型任务的真门槛。判据不是"可用 RAM"，而是CommitLimit = 物理内存 + 页面文件额度。调页面文件前 36.3GB（纸面必 OOM），调后 55GB——3 分 50 秒导出轻松跑完，全程系统流畅。
二、实验环境
| 项 | 配置 |
|---|---|
| CPU / iGPU | Core Ultra 5 338H（Arrow Lake-H）/ Arc B370（10 Xe-core） |
| 内存 | 32GB LPDDR5x 统一内存（CPU/iGPU 共享） |
| 系统 | Windows 11，页面文件 C 盘 24-42GB 动态区间（自定义，改既有大小即时生效无需重启） |
| 显存划拨 | 20GB（Intel Graphics Software，导出阶段不要划，推理前划+重启） |
| 软件栈 | OpenVINO 2026.4 / openvino-genai / optimum-intel 1.26.0 / nncf 2.19.0 / Python 3.11 独立 venv |
| 模型 | Marco-MT-Algharb 15B：BF16 六分片 27.51GB → INT8 IR13.76 GiB |
三、导出实录：纸面"必 OOM"，实际 3 分 50 秒
指南按权重全量载入预估导出峰值 35-40GB，对 32GB 机器判"高危"。我们的实测路径给出了更精确的口径：
| 阶段 | 页面文件 | CommitLimit | 结果 |
|---|---|---|---|
| 初始（C 盘自管 4.86GB） | 4.86GB | 36.3GB | 自检不过，按纪律不开工 |
| 调 C 盘 24-42GB 动态区间 | 24GB（可扩 42） | 55GB | ✅ 开工 |
| 导出实测 | —— | 峰值未击穿 | 3 分 50 秒、零 OOM、四件产物齐 |
两个工程细节：
- 改"既有"页面文件大小即时生效，新建才要重启——这个和多数人直觉相反；
- 峰值内存我们没量到（采样器踩了 PowerShell 5.1 无 BOM 编码坑），但间接证据一致：safetensors 的 mmap 惰性加载，可能让"35-40GB 峰值"在这套栈上根本没有兑现——权重页按需调入，纸面峰值被摊平成平滑页流。这和观测 1、2 互为印证：同一层物理内存的三处表现。
四、推理实录：7.4 t/s、EOS 大坑、batch 零增益
- INT8 decode 7.3-7.5 t/s（batch=1 稳定复现，比预估快约 1.5×）；首次加载温启动 19-21s / 冷启动 63s；
- 🔴 部署必修坑：OpenVINO GenAI 的 IR 不自动继承 generation_config 的 eos——必须手动
cfg.stop_token_ids = {151643, 151645}（注意 pybind 只收 set 不收 list），否则译文后无限填充洪水； - iGPU INT8 下 batch 并行增益 ≈ 0：n=3 耗时≈3× 单路（20-21 t/s 吞吐但无单请求加速）——MBR 类多路采样策略在此硬件上性价比要重估；
- 质量抽样 10 句 9 句可用，术语与否定处理是强项；
- GPU 池全程峰值15.28 GiB（63%），空闲底噪 0.46 GiB——池子始终宽裕，本轮最长 384 token 上下文没有触到"触池→页面文件换页→速度跳水"的行为边界（该边界需 ~32K 上下文 × 多路并发才探得到，列为下个实验）。
五、科研脑洞：热-冷分层的"穷人版 KTransformers"
KTransformers 类工作证明了"热专家驻显存、冷专家驻内存"的分层能跑超大 MoE。统一内存笔记本把这个思路再推一步——CPU 内存和 GPU 显存本来就是同一堆物理内存，而页面文件把最冷一层自然延伸到 SSD：
层 0 系统常驻 ≈ 6GB（Win11 精简环境可做到） 层 1 热：常驻专家 GPU 池 ≈ 26GB（划拨后实测口径） 层 2 冷：低频专家 统一内存余量 / pagefile 异步页 层 3 KV 溢出层 SSD（pagefile / 显式 mmap）场景脑洞：数百专家的 MoE，单 token 只激活少数专家——热路径专家常驻 26GB 池，冷专家权重躺 SSD 由 pagefile/mmap 按需换入。系统要求可以压到 6GB 级内存的笔记本，"跑"远超裸显存容量的模型。
把丑话说前面：分层换页走 SSD 带宽，冷专家命中时 decode 会跳水到个位数 t/s 甚至更低——"能跑"和"流畅"是两回事。值不值得做，取决于专家路由的命中率工程（局部性）与场景（离线批处理完全可接受，交互式要权衡）。这是假设与路线提示，不是结论——本轮只验证了物理基础（观测 1-3），分层实现还是空白。欢迎 338H/358H/388H 的朋友复现拍砖。
六、复现要点与局限
- 复现：Python 3.11 独立 venv；
optimum-cli export openvino --task text-generation-with-past --weight-format int8；推理必须手动 stop_token_ids（set）； - 口径：体积以
ls -l --block-size=1逐分片求和为准（Windows 下du簇语义误报近一倍）；内存判据用CommitLimit而非"可用 RAM"； - 局限：单机单样本；上下文压测未做（≤384 token）；峰值内存未逐秒采样；358H/388H 未实测（同架构推断）；
- 模型已开源（Apache 2.0）：modelscope.cn/models/fcpaul/Marco-MT-Algharb-ov-int8，README 含完整关键数据表。
实测数据均出自 2026-09-26 单机实验，方法与脚本可复现。转载请注明实测口径。—— 玛小扣（Koda）