- 硬件与软件环境
| 项目 | 测试环境 |
|---|---|
| CPU | AMD Ryzen 7 9800X3D，8 核 16 线程，AVX-512 / VNNI 可用 |
| GPU | AMD Radeon RX 7900 XTX，标称 24GB 显存，gfx1100 |
| GPU 连接 | PCIe 4.0 x16，链路 16 GT/s、x16 |
| 系统内存 | 标称 48GB，系统可见约 45.2 GiB |
| 模型存储 | Kingston NV3 1TB NVMe；GGUF、专家 pack、PLE 放在 NVMe 上 |
| 操作系统 | Ubuntu 26.04 LTS |
| 内核 | 7.0.0-34-generic |
| 服务 Python | 独立 Python 3.12 虚拟环境 |
| HIP / ROCm | AMD TheRock 7.10.0a20251120，沿用原安装环境 |
| hipBLASLt | 100200，使用与 gfx1100 和该版本匹配的调优表 |
| Strata | v0.1.34，Linux HIP 后端，本机源码编译 |
| 图片编码器 | CPU 编译版本，8 线程，未使用 GPU 编码 |
| 测试方式 | 单服务独占运行；请求顺序执行，服务并发为 1 |
RAM 和显存的监测统一使用 GiB，即 bytes / 2³⁰；不要将软件显示的 GB 与 GiB 混用。内存频率、时序和主板型号未在本轮采集，不作推测。本报告未测试 AI PRO R9700、其他显卡、双卡，也未测试 Windows 原生运行。
新版提交固定为：
1678de333d0e0711bc414ad992b640e1a37dd814
v0.1.34 的发布说明区分了 Windows 和 Linux AMD：本次走的是 Linux HIP＋CPU 看图 路线，没有套用 Windows HIP 压缩包。官方发布说明
2. 模型与权重
| 项目 | 实际使用 |
|---|---|
| 文本模型 | Qwen3.8-Flash-Next-GSQ-RCO，IQ3_XXS |
| 权重来源 | ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF |
| 权重 revision | ed59f92082b1e93c0e96d60a8b11aab089b52f09 |
| GGUF | 两片，合计约 75.8 GB；下载时两片均核对 SHA256 |
| 专家 pack | 约 39.97 GiB |
| 原生小权重 arena | 约 1.43 GiB |
| 图片 projector | mmproj-Qwen3.8-Flash-Next-BF16.gguf |
| projector 大小 | 907,543,008 bytes，约 0.908 GB / 0.845 GiB |
| MTP | 启用匹配的 MTP runtime，CJK draft vocabulary |
视觉 projector 取自与文本 GGUF 相同的 revision，完整 SHA256 校验通过：
b1a82259702816a5330d7bd7607cd9676b11780e79ff7348c21103ff3ce49bd0
模型来源：固定 revision 的 ISTA GGUF 仓库。本轮只测试这组权重，没有做其他量化或其他微调模型的 A/B。
3. 关键运行配置
| 配置 | 值 |
|---|---|
| 上下文 | 131072 tokens，即 128K |
| KV | int8 |
| Prefill chunk | 4096 |
| CPU expert pool workers | 7，另有 host thread |
| Speculation | spec=4，spec-min-p=0.5 |
| Expert cache | auto，固定 expert profile |
| CPU 专家 | 强制常驻 RAM，pageable，非 pinned |
| MMAP | --mmap-experts |
| VRAM reserve 参数 | 1536 MiB |
| Adaptive swaps | adapt-every=0 |
| PCIe fraction | pcie-frac=0 |
| 多对话缓存 | conversation-cache-mib=0 |
| 自动 idle unload | 关闭 |
| HIP MMQ | STRATA_PREFILL_MMQ=1 |
| 图片嵌入路径 | 文本引擎必须带 --vision |
| CPU 图片编码 | gpu=false，threads=8，max_tokens=300 |
核心参数记录如下，模型和 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：真实图片与图文结果
| 测试 | 输入 tokens | 输出 tokens | TTFT | 总耗时 | PP token/s | TG token/s |
|---|---|---|---|---|---|---|
| 图片 A，数字 7462 | 234 | 90 | 3.00 s | 4.31 s | 149.0 | 67.2 |
| 图片 B，数字 9137 | 234 | 90 | 2.82 s | 4.16 s | 162.1 | 66.5 |
| 近满 128K＋图片 | 129,745 | 35 | 134.82 s | 135.29 s | 963.5 | 70.8 |
| 长图文后的 HEALTHY 检查 | 17 | 4 | 0.24 s | 0.35 s | 78.2 | 31.3 |
四个请求均正常结束，finish_reason=stop。