APUS-OpenJev-v1 在端侧设备上“能跑多快”取决于内存和延迟哪一项先触顶：模型能加载不代表推理期内存够用，推理能跑完也不代表单次耗时稳定。建议把输入、参数和采样方式固定下来，分别观察峰值内存与单次推理耗时的分布，再看哪一项先接近设备上限。这样得到的判断可以被别人用同一套命令复核，而不是只凭一次体感。

在端侧设备上，内存和延迟通常不会同时成为唯一瓶颈。先固定一条输入，记录加载完成后的 VmRSS 与推理过程中的 VmHWM，再循环计时并丢弃首次预热结果；哪一项先逼近设备上限，就优先处理哪一项。若进程被杀且峰值内存贴顶，优先降内存；若内存有余但耗时分布长尾明显，优先查线程、量化和输入长度。不同设备与后端差异大，结论需在同一环境复现后使用。

固定一条输入把变量降到最少

排除输入长度干扰，先选一条你业务里常见的短输入写入 input.txt。示例内容可以是：

把下面这句话翻译成中文：The quick brown fox jumps over the lazy dog.

长度记录方式建议同时记字符数和 token 数：字符数用 wc，token 数用模型自带 tokenizer 或接入层计数。命令示例：

wc -m input.txt
wc -c input.txt
# 若接入提供 tokenizer 计数入口，替换为实际命令
python count_tokens.py `--input` input.txt

重复运行时，以下参数必须保持不变，建议写进 fixed.yaml 或启动脚本，而不是依赖默认值：max_new_tokens、temperature、top_p、top_k、repetition_penalty、线程数、批大小、上下文长度、量化格式、推理后端、设备与 CPU/GPU 亲和性。每次运行前确认没有额外的日志级别、调试开关或系统后台任务改变资源状态。

测峰值内存而不是看静态占用

静态占用只能说明模型加载后占了多少，真正的内存高点通常出现在推理过程中。启动进程后拿到 PID，先用系统监控工具或进程状态命令记录加载完成后的数值：

grep -E 'VmRSS|VmHWM|VmSize' /proc/<PID>/status
ps -o pid,rss,vsz,etime,cmd -p <PID>

然后开始一次推理，在推理过程中用循环采样记录另一个时间点，直到输出结束：

while true; do date +%s; grep -E 'VmRSS|VmHWM' /proc/<PID>/status; sleep 0.5; done > mem.log

VmRSS 是当前常驻内存，VmHWM 是进程生命周期内的峰值常驻内存。需要分别记录：加载完成后 VmRSS/VmHWM，以及推理开始到结束之间的最大 VmRSS/VmHWM。若进程中途退出，查 dmesg 或 journalctl -k 确认是否触发 OOM；若设备用 cgroup 限制内存，也查 memory.current 和 memory.max。采样间隔可能漏掉瞬时峰值，这一点要在结论里注明。

循环调用测单次推理耗时并看分布

首次推理通常包含加载、缓存建立或图编译开销，不能直接当作稳定耗时。建议进程内重复调用同一输入，先跑 20 次，时间允许再增加到 50 次，并丢弃第一次结果。计时脚本骨架如下，your_infer_cmd 替换为实际推理入口：

import time, statistics, subprocess

N = 20
times = []
for i in range(N):
    t0 = time.perf_counter()
    subprocess.run(['your_infer_cmd', '`--input`', 'input.txt', '`--config`', 'fixed.yaml'], check=True)
    t1 = time.perf_counter()
    times.append(t1 - t0)

stable = times[1:]  # 丢弃首次加载/预热结果
print('n=', len(stable))
print('min=', min(stable), 'median=', statistics.median(stable), 'max=', max(stable))

如果推理进程每次都要重启，那每次计时都会包含加载开销，这时要分开记录“冷启动单次”和“进程内重复单次”。除了最小、中位、最大，也可以看第 90 百分位，判断是否存在偶发长尾。记录时标明是否发生降频、是否接电源、屏幕与后台服务状态。

对比不同输入长度看增长趋势

判断瓶颈来自模型本身还是序列长度，至少准备短、中、长三组输入，保持参数完全相同，只替换输入文件。长度用字符数和 token 数同时记录。表格只填写实测结果，不要预填推测值：

如果峰值内存随输入长度明显上升，而单次耗时中位变化不大，内存更像是先触顶项；如果峰值内存基本不变，但耗时中位和最大值随长度拉长，延迟更像是先触顶项。两者都上升时，以先接近设备限制的那一项作为优先处理对象。这里只记录本机命令和日志能验证的数值。

把先触顶的那一项写成可复核结论

结论要能交给他人验证，建议写成固定模板：测量环境、观察到的现象、已知项、未知项。测量环境记录设备型号、系统与内核、总内存与可用内存、推理后端、模型文件与量化格式、线程数、供电和温控状态。观察到的现象只写日志、命令输出和计时结果。

可复核结论句式可以这样写：“在 [设备/系统/后端/量化] 下，用 [固定输入] 和 [固定参数] 重复 [N] 次，观察到 [峰值内存或单次耗时] 先接近 [设备限制]，因此优先处理 [内存或延迟]。该判断未覆盖 [其他进程占用、采样漏峰、温控降频、不同输入长度]。”无法确认的部分不要省略，尤其不要把 VmHWM 直接等同于整机峰值内存，也不要把一次冷启动耗时当作稳定推理耗时。