Step Edge 想在本地跑端侧模型，先看清设备内存和量化档位

想在这台设备上加载 Step Edge 的端侧模型，判断顺序应该是：先用系统命令读出真正可用的内存和剩余存储，再用模型文件大小除以参数量确认它属于哪个量化档位，最后跑一次最小前向并采样一次内存。标称内存不等于可用内存，模型装得下也不等于首字延迟能被用户接受。这三步都不需要联网，也不需要改模型，先做完再决定要不要把 Step Edge 留在本地。

端侧能不能跑，先看两件事：可用内存和文件体积。用 adb shell cat /proc/meminfo 或活动监视器读“可用内存”，用文件大小除以参数量核对量化档位（fp16 约 2 字节、int8 约 1 字节、int4 约 0.5 字节每参数）。跑一次最小前向，记录峰值内存和首字延迟：余量不足就降档或换小模型，延迟超出交互预期就把实时请求退回云端，本地只留低延迟要求不高的任务。

用系统命令读出设备可用内存与剩余存储

先把硬件上限拿到手，而且只记“可用”那一项。MemTotal 是标称总数，系统和其它常驻应用已经占掉一部分，只有 MemAvailable 才接近你能拿到的量。

Android 设备，用 adb 连上后执行：

adb shell cat /proc/meminfo | grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree'
adb shell dumpsys meminfo your.package.name
adb shell df -h /data

iOS 没有直接读 /proc/meminfo 的口子。用 Xcode 的 Devices and Simulators 窗口能看到设备型号和容量，运行期的可用内存要在 Xcode 的 Debug navigator 或 Instruments 的 Allocations、VM Tracker 里观察；代码里可以用 os_proc_available_memory() 取当前进程还能用的字节数。设置—通用—关于本机只给标称容量，不够用作判断依据。

桌面系统直接用图形工具更快：macOS 活动监视器看“内存压力”和“可用”，Windows 任务管理器性能页看“可用”和“已提交”，Linux 用 free -m 看 available 列、df -h 看剩余磁盘。

记录时注意三点：swap 只能避免进程被立刻杀掉，不代表设备能承载推理，别把它算进可用内存；剩余存储要留出模型文件之外的余量，加载和转换过程可能产生临时文件；同一台设备多测几次，后台应用波动会明显影响 MemAvailable。

把模型权重按量化档位换算成文件体积

每参数字节数是个固定换算：fp16 约 2 字节，int8 约 1 字节，int4 约 0.5 字节。用文件字节数除以参数量，看结果落在哪一档，就能核对手上这份权重到底是什么精度。

# 纯权重算术示例，换成你自己的文件大小和参数量
# 7e9 参数，int4: 7e9 * 0.5 = 3.5e9 B  (约 3.3 GiB)
# 7e9 参数，fp16: 7e9 * 2   = 14e9  B  (约 13 GiB)

这里的数字只是换算演示，不是任何具体模型的规格；用 ls -l 或文件管理器拿到真实字节数再算。文件名里写着 int4 或 fp16 只能当线索，不能当结论，尤其经过二次转换或重新打包的文件，名字经常和实际精度不一致。

另外，文件里通常还包含词表、配置和未量化的嵌入层，所以实测字节数会略大于纯权重估算值。偏差不大说明档位判断没错；差到几倍，说明参数量估错了，或者文件里混了别的权重，这时不要急着加载，先确认文件构成。

写一段最小加载脚本做单次前向

这一步必须把两类失败分开：内存不足，和格式或接口不对。写一段只做加载加一次前向的脚本，中间打日志，不掺任何业务逻辑。

# 框架相关接口都是占位名，替换成本地实际可用的方法
model = load_model_placeholder(model_dir)        # 或 runtime.load(...)
tokenizer = load_tokenizer_placeholder(model_dir)

prompt = 'hello'
ids = tokenizer.encode(prompt)
out = model.generate_placeholder(ids, max_new_tokens=8)
print(out)                                       # 或 tokenizer.decode(out)

放在哪执行：能在目标设备上跑就在设备上跑，不要在开发机上验证完就下结论，内存行为差别很大。加载阶段就报 OOM，是内存不够；加载时抛键名不匹配、文件头错误、算子不支持，是档位或文件不对；加载成功但前向崩，通常是上下文长度或 KV cache 撑不住。三类原因对应的动作完全不同，日志里要写清楚是哪一类。

记录首次推理的峰值内存与首字延迟

拿一次推理的实际数据，才能判断能不能满足交互。固定间隔采样进程内存，别只看一个瞬时值。

# Android，每秒采一次进程驻留内存
adb shell "while true; do cat /proc/$(pidof your.package.name)/status | grep VmRSS; sleep 1; done"

# 桌面 Linux
while true; do ps -o rss= -p $PID; sleep 1; done

记录表建议用这几列：时间戳、进程内存（VmRSS 或 RSS）、设备可用内存、事件标记（加载开始、加载完成、首字输出、结束）、首字耗时（从提交输入到第一个 token 返回的毫秒数）。峰值内存取加载完成到推理结束这段区间里的最大值，别取整个采样过程的最高点，否则会把系统别的开销算进来。

判定加载成功的验证信号，需要同时满足：进程在推理结束后仍然存活，没有被系统回收；前向返回了非空、长度和形状符合预期的结果；日志里没有 OOM、换页告警或算子不支持的报错。三条缺一条，就说明这次档位在当前设备上还不算可用。

按实测结果决定留在本地还是退回云端

内存余量不足时：如果采样里看到加载完成后可用内存已经很小，或者推理过程中出现明显换页、进程被系统回收，就降一档再试（int8 换 int4，或换更小参数量版本），然后重跑最小前向和内存采样，重新判断。不要靠加大 swap 硬撑，这只推迟失败的时间点。

首字延迟超出交互预期时：如果场景是用户边输入边等结果，而首字耗时明显超过你能接受的范围，可以先减上下文长度、改流式输出、避免并发多个推理请求；这些仍不达标，就把实时对话类请求交给云端，本地只保留离线批处理、后台摘要这类对首字延迟不敏感的任务。

取舍边界：设备内存和散热是硬约束，别指望靠调参把明显不匹配的档位跑顺。降档能换来更稳的加载，代价是输出质量下降，这个交换是否值得，要按你自己的场景定。留一个原则：先在本地跑通一个你确认能稳定承载的档位，再考虑往上加，而不是从最大档位开始试。