RAM 和显存的监测统一使用 GiB，即 bytes / 2³⁰；不要将软件显示的 GB 与 GiB 混用。内存频率、时序和主板型号未在本轮采集，不作推测。本报告未测试 AI PRO R9700、其他显卡、双卡，也未测试 Windows 原生运行。

新版提交固定为：

1678de333d0e0711bc414ad992b640e1a37dd814

v0.1.34 的发布说明区分了 Windows 和 Linux AMD：本次走的是 Linux HIP＋CPU 看图 路线，没有套用 Windows HIP 压缩包。官方发布说明

2. 模型与权重

视觉 projector 取自与文本 GGUF 相同的 revision，完整 SHA256 校验通过：

b1a82259702816a5330d7bd7607cd9676b11780e79ff7348c21103ff3ce49bd0

模型来源：固定 revision 的 ISTA GGUF 仓库。本轮只测试这组权重，没有做其他量化或其他微调模型的 A/B。

3. 关键运行配置

核心参数记录如下，模型和 pack 路径另行配置：

--max-context 131072 --kv int8 --prefill 4096
--pool-workers 7 --spec 4 --spec-min-p 0.5
--expert-cache auto --adapt-every 0 --pcie-frac 0
--vram-reserve-mib 1536 --conversation-cache-mib 0
--mmap-experts --resident-cpu-experts --vision

pageable 常驻配合 STRATA_RESIDENT_PIN=0。这组配置会在常驻资源预算不足时拒绝启动；本轮没有用持续 swap 或临时并行启动另一服务来维持运行。

运行日志确认新版 CPU 常驻专家约 26.46 GiB，GPU 缓存 9,583 个专家，约 15.53 GiB。这些是专家部分的分配，不是整个服务的总内存/显存；KV、dense、MTP、图片编码器和临时缓冲还会占用资源。

CPU 图片配置的 max_tokens=300 是图像 token 预算，用来控制图像缩放和编码负载，不是回答只能生成 300 tokens。小字号文档、复杂截图和精细定位没有在本轮验证，不能根据这两张简单测试图推断其 OCR 精度。

4. 测试方法与指标

升级时保留文本权重、128K 及主要推理参数，新增视觉组件；未同时更换系统 ROCm 或文本模型。首先编译新 HIP 引擎和 CPU 编码器、校验 projector，再确认服务空闲，停止旧服务的整个 cgroup。连续检查资源释放后启动新版，最后验证真实 API 请求。

本轮新版真实模型测试共 4 个请求：两张独立图片、一个近满 128K 图文请求、一个长请求后的短文本健康检查。请求参数为 temperature=0、top_k=1、top_p=1、min_p=0、seed=42、reasoning_effort=none；使用流式 Chat Completions。

指标含义：

• PP / prefill token/s：引擎处理输入的速度，不是回答生成速度。
• TG / decode token/s：引擎报告的输出 tokens ÷ 解码耗时，不包含读入长提示词的时间。
• TTFT：客户端从发出请求到收到首个非空正文的时间，包含该请求的图片处理、预填充及首次输出等待。
• 总耗时：完整请求的客户端墙钟时间。
• cache_n / cached_tokens：检查输入 KV 是否复用。本轮 4 个请求均为 0；这不等于系统文件缓存是冷的。

两张图片都是程序生成的 512×336 PNG，白底、大号数字及三个彩色几何图形。提示词只要求读文字和描述形状，没有把正确数字、颜色或形状列表告知模型。第二张更换数字，并交换图形颜色，避免把第一张回答复用为识别结果。

128K 测试以模型自己的 tokenizer 和 chat template 构造输入，再以 API usage.prompt_tokens 核实实际输入量，图像 tokens 计入同一个窗口。长文本是合成 JavaScript 档案，中间插入唯一标记，同时附上第一张图片。该图片已在前一个请求中编码，可能复用图片编码缓存，但没有复用输入 KV；因此这是长上下文图文验证，不是“首次冷图编码＋128K”的时延基准。

5. v0.1.34：真实图片与图文结果

四个请求均正常结束，finish_reason=stop。