新版Strata v0.1.34（看图功能已可用）---48G内存搭配7900XTX显卡----Qwen3.8-Flash-Next本地测试数据。
-
- 硬件与软件环境
项目 测试环境 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 原生运行。
新版提交固定为：
1678de333d0e0711bc414ad992b640e1a37dd814v0.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 --visionpageable 常驻配合
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。 -
-
-
