[实测] RTX 5080 16GB + 64GB RAM：Strata / SC117 Qwen3.8 Uncensored IQ3_XXS，44分钟3D鹈鹕骑行

Marck Wong

Strata打开了新世界，这几天一直在这趟。看到论坛里的 3D 鹈鹕骑行 prompt，我也用自己的单卡 PC 跑了一次。本地模型是 SC117 的 Qwen3.8-Flash-Next GSQ-RCO abliterated / Uncensored，IQ3_XXS，放在 Codex 里执行，完整 task 显示 Worked for 44m。

先说实际感受：能做出可运行的 3D 骑行 demo，海水、天空和日光有一定效果，鹈鹕与自行车也能辨认；但植被和人物比较简化，清晨逆光下主体偏暗，距离 prompt 中的“细节拉满、比例正确”仍有差距。这个结果说明它能完成这一项 coding task，不能凭一轮测试推导出普遍能力排名。

分工说明：文件生成及其过程中检查、修复由本地模型执行；生成完成后，我切换到 GPT-6.1 Sol High，进行了源码、截图和录屏检查，核对环境与参数，整理这份报告，并由它代为发布。后续检查与发帖时间不计入本地模型的 44 分钟。本文是我的实测资料与现场反馈，经 AI 协助整理。

1. 测试平台

测试日期：2026-10-09。下面的 hardware 和已安装 runtime 由生成完成后的 read-only 检查核对；当时的运行状态另用截图说明。

项目	配置
CPU	AMD Ryzen 7 9700X，8 cores / 16 threads
RAM	64GB，2 × 32GB Kingston KF560C30-32，DDR5，configured speed 6000 MT/s
GPU	NVIDIA GeForce RTX 5080，16GB；nvidia-smi 报告 16303 MiB
PCIe	monitor 显示 Gen5 ×16；这是界面读数，没有另测 DMA bandwidth
OS	Windows 11 Pro for Workstations，64-bit，build 26300
NVIDIA driver	617.42
Storage	KIOXIA EXCERIA PLUS G4， 2TB NVMe SSD
Inference engine	官方 Strata 0.1.41，revision `fb58e0dbc8399662c0e47c76578c6e878b14f6cf`，已安装 manifest 无 upstream patches
Coding harness	Codex desktop，通过 OpenCodex 接入本地 Strata；选择 High effort、256K context

以下是执行中的 Codex 界面，能看到左侧 task、底部本地模型选择和右侧 monitor。

Codex执行过程与Strata monitor，保留原有mosaic

2. 模型出处和规格

这里测试的是 SC117 的 Uncensored 版本，不是未经修改的官方原版。 Codex 中的 display name 是 Qwen 3.8 Flash-Next Uncensored，本地 model ID 为 sc117-qwen3.8-flash-next-iq3_xxs。

Model repository：SC117/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF
本地 provenance 记录的 revision：eec4e10a2c29b440a2ae85591fa11569ce752963
SC117 model card 标注的 quantized base：ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF
SC117 model card 标注的 abliteration tensor 来源：orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF

按 Qwen 官方 model card 的规格口径，主干 125B、activated 6B，另有 51B n-gram embedding 和 4B MTP；48 layers，512 experts，每 token 选择 10 routed experts 加 1 shared expert。不要把文件大小 76GB 误写成 76B，也不要把整套约 180B 写成每 token 全部参与计算。

本机实际使用下面两片 GGUF，文件大小已检查：

文件	Bytes	十进制 GB
`Qwen3.8-Flash-Next-GSQ-RCO-abliterated-IQ3_XXS-00001-of-00002.gguf`	47,342,144,896	47.34
`Qwen3.8-Flash-Next-GSQ-RCO-abliterated-IQ3_XXS-00002-of-00002.gguf`	28,800,138,432	28.80
两片合计	76,142,283,328	76.14

这个合计不含单独的 MTP runtime、vision projector 和 pack。IQ3_XXS 是本次使用的 tier 名称，不表示所有 tensors 都是同一精度；SC117 的 model card 说明第二片为 n-gram table，采用 IQ4_NL。

3. 接入方式与参数

Inference 在 PC 本地执行。Codex 经 OpenCodex 的 Responses adapter 接入：

Codex desktop
  → OpenCodex Responses proxy (127.0.0.1:10100/v1)
  → Strata carrier (127.0.0.1:8080/v1)
  → official Strata server (127.0.0.1:8081)

monitor / frontend 可以通过另一台机器的 portal 查看，这不等于把 inference 放到了云端。工具调用、浏览器、下载等操作也会消耗时间，所以完整 task 不是一次连续 decode。

配置方式是下载 SC117 对应的两片 GGUF，为它单独生成 native pack，再让 --pack、--native 和 --ple-gguf 指向这套文件。SC117 的 model card 特别说明，不能只换 GGUF 路径而沿用另一套模型的旧 pack。以下是事后从本机 generated runtime config 核对出的参数，路径用占位符表示，避免大家照抄我的目录：

--pack <SC117专用pack-iq3_xxs>
--native <IQ3_XXS第一片GGUF>
--ple-gguf <IQ3_XXS第二片GGUF>
--expert-profile <SC117的expert-profile-neutral.bin>
--expert-cache auto
--prefill auto
--spec 4
--spec-min-p 0.5
--mtp <MTP runtime目录>
--resident-budget-gib 55
--stats
--vision
--max-context 262144
--kv int8
--kv-resident 32768
--rope-scaling none
--rope-scale 1
--yarn-orig-ctx 262144
--conversation-cache-mib 2048
--conversation-cache-slots 2
--conversation-cache-min-free-mib 4096

这份 config 的 tokenizer 也指向 SC117 pack 的 tokenizer。Vision config 为 CPU、8 threads、max_tokens 1024；“配置里启用了 vision”不等于本次 task 测了模型的 vision 能力。安装记录中的默认 VRAM reserve 为 700 MiB，RAM headroom 为 8 GiB，没有把专家缓存手动设成固定数量。截图当时 monitor 显示缓存 4,890 experts、约 7.9GB。

Codex 界面明确选择 High effort；context 为 262,144 tokens，catalog 的 auto compact threshold 为 209,715 tokens（80%）。这只是配置容量，本次截图约占用 75K，并不是做了 256K 满载 benchmark。

Sampling 的实际 request payload 本次没有保存核验，因此 temperature、top_p、top_k、sampling min_p 均不当作已测值。 GGUF metadata 中有 temp=1.0、top_p≈0.95、top_k=20，但 metadata 不是请求证据；High effort 也不等于 temperature。上面的 --spec-min-p 0.5 是 speculative 参数，不能写成 sampling min_p。

4. 原始 prompt 与计时

Prompt 来自论坛 3D 鹈鹕骑行讨论。我执行的是：

画一个3D的鹈鹕在海边公路骑自行车动画，用HTML5及必要的技术来展示，要求细节拉满，有美感，比例正确60帧不卡顿，默认从左后方向45度视角，有日夜切换按钮，太阳和月亮会随时间变化运动（大概是20倍于现实中的时间流逝）,鹈鹕左侧的路面增加一些花花草草，海里增加一些小鱼时不时的跃出水面，沙滩上有螃蟹及海螺，岸边有人散步，海里有些人游泳，远处有一些渔船，海上有一些海鸥随机飞翔。夜晚天上加一些星星，保存为pelican.html（本机默认下载好three.js，如果没有也可以自动从中国CDN快速加载）。游戏要有server.py，启动后随机寻找一个本机的空闲端口作为服务器，并自动从默认浏览器打开让用户试玩.

结果为 pelican.html、server.py，另有本地 three.min.js r128。事后检查文件大小分别约 52KB、2.4KB、603KB。HTML 是程序化 3D 场景，不依赖外部贴图。

44 分钟是完整 agent task 的耗时，包括思考、读取文件、查找或下载依赖、写文件、检查及修复，不是单次 inference 用时，也不是“一次输出 44 分钟、零修复完成”。完成页的截图如下：

Worked for 44m与本地模型的交付记录

5. Monitor 读数：速度与资源

这次没有导出只包含本 task 的完整 request log，下面只记录截图可见的数据，不做整场平均：

来源	截图读数	口径
执行中瞬间	Decode 101.9 tok/s；Prefill 79 tok/s	monitor 的当前/该请求读数，不是稳定峰值或冷启动 benchmark
执行中 recent request	Prompt 49,709；Reused 49,620；Output 12,216；Decode 69.4 tok/s；Duration 176.8s	一个请求，prefix reuse 很高
同一执行截图	GPU load 91%；VRAM 15.6/16GB；GPU 63℃、167W	一个时刻，不是全程平均或最大值
同一执行截图	RAM 57.3/61GB；CPU load 55%	monitor 的总系统读数
后续 recent request	Prompt 45,597；Reused 45,533；Output 894；Decode 72.6 tok/s；Duration 13.0s	一个请求，非整轮任务统计

后续截图里若干请求的 Decode 为 71.4、75.0、78.8、75.4 tok/s。这些样本能说明当时的实际使用速度，不能据此宣布整场均速。下面这张截图拍摄时已经 Idle，显存显示 1.7GB，不应拿它当作运行模型时只需要 1.7GB 的证据；其 recent requests 才是历史请求记录。

Idle时的monitor与recent requests

6. 一个实际踩坑：打开 3D HTML 后跌到约 15 tok/s

本地模型运行期间，Codex 调用 in-app browser 查看 3D HTML 后，出现明显卡顿，Decode 一度跌到约 15 tok/s。移除那个 HTML tab 后，速度恢复。 这是我的现场观察，15 tok/s 的瞬间没有在本文附件里保留对应截图，不把它包装成完整 profiling 数据。

当时截图中的 VRAM 已到 15.6/16GB、RAM 为 57.3/61GB，资源余量很小。3D WebGL 页面和模型同时运行时争用 GPU/VRAM，是一种合理解释；但没有前后 GPU profiling、进程分项和同条件重复实验，不能确定唯一原因，也不能认定所有 browser 都会触发。

我的使用建议：16GB 卡跑这套模型时，生成阶段尽量关闭不必要的 3D HTML tabs，先做源码和 syntax 检查；生成完成、停止本地 inference 后，再集中检查画面。这次的 44 分钟包含了那段卡顿，没有剔除或重新计时。

7. 实际完成度与不足

下面的 GIF 来自我提供的 15.6 秒录屏，展示视角变化；为适应 upload 大小，转成 320px 宽、4fps、32 colors 的 GIF。GIF 帧数与原页面 render FPS 无关，颜色和清晰度也经过压缩。

鹈鹕骑行录屏GIF，低帧数仅用于展示视角

Prompt 项目	本次可确认的程度
鹈鹕骑自行车、海边道路	用户截图及录屏能看到，主体和自行车可辨认；源码有车轮、曲柄和双腿动画
默认左后方45°、可调整视角	源码 azimuth=225°；录屏展示了不同视角。此时默认 elevation=16°
花草、海水、人物、远处船与海鸥	截图/录屏可见；植被与人物比较简化，主体偏小的远景会降低细节辨识度
蟹、海螺、游泳者、跃水小鱼	源码有对应实体或 animation/update 路径；现有录屏不足以逐一确认最终视觉效果
日夜 button、太阳/月亮随时间移动、星星	源码有对应实现及 N 快捷键；此次没有完成夜景交互复测
20×时间	源码 TIME_SCALE=20；完整昼夜正常流逝约需72分钟，button 可快速切换。没有做72分钟连续观察
60帧不卡顿	HUD 在截图/录屏中显示120；严格 FPS 和 frame-time benchmark 未完成，不能据此宣布稳定120FPS
本地three.js及CDN fallback	loader 顺序为本地文件 → bootcdn → staticfile → jsdelivr → unpkg；没有重新验证每个CDN当前都可达
server.py自动开browser	源码有随机空闲端口选择、loopback server和自动开默认browser逻辑；本轮做了syntax检查，没有再次启动作完整验证

视觉上，海面的波纹和日光反射较有氛围，鹈鹕的长嘴、喉囊、折叠翅膀和 bike 都能辨认。但草像较硬的细杆，岸边人物很简化，画面主要是平坦地形；清晨逆光下 road 和主体偏暗。“能跑出demo”基本做到，“细节拉满”和“比例正确”不能直接判定全达标。

8. GPT-6.1 Sol High 的事后检查范围

这部分在本地模型交付之后进行：

两段 inline JavaScript 用 node --check 检查，syntax通过；server.py 用Python compile检查，syntax通过。
查看用户的截图，并从录屏抽取代表性画面，核对模型选择、完成页、资源读数和视觉效果。
Read-only 核对 hardware、runtime config、model文件及来源，区分截图历史读数和事后配置。
发现 FPS HUD 使用 dt = Math.min(clock.getDelta(), 0.05) 后的dt计时；当一帧超过50ms时，这种写法会高估FPS。因此 120是HUD读数，不是独立frame-time measurement。

Browser automation 对已经打开的 file:// 页面拒绝访问；没有绕过这一限制，所以此次没有由 GPT-6.1 Sol High 直接点击测试日夜 button。它查看的是截图、录屏和源码，没有修改生成产物来美化本次成绩。前面本地模型自己的“全部完成”和“120FPS”总结，是原始交付记录，不替代这些检查结论。

我的结论是：RTX 5080 16GB + 64GB RAM 配合 Strata 和 SC117 IQ3_XXS，已经能在 Codex 中执行这一项实际 coding task；代价是完整agent耗时、有限资源下的browser竞争，以及仍需人工检查的画面质量。想复测的朋友可以使用同一prompt；这次只有一轮结果、没有同条件其他模型对照，欢迎交流实际完成度和资源分配经验。

参考阅读：Strata参数篇加精主题、RTX3060的IQ2_XS/IQ3_XXS加精实测、本次prompt所在讨论。参考的是呈现环境、参数、实测与限制的方式，没有把其他机器的成绩算成本机数据。

terry

可以，图文并貌，插入一点硬件实拍更有说服力。5080是strata最大受益者之一。

Marck Wong

@terry 大佬，我在纠结要不要换成DDR5 128G 5400的内存， 6000的好像没货，但是9700x 应该不能4条 32g吧？

terry

@Marck-Wong R9700和你用什么内存之间有关系？？没太理解。内存频率差这点影响不大。

Marck Wong

@terry 是不是说插满4条32g ddr5 6000是不是会降频或者无法开机？我是MAG B850的M-ATX主板

Henry Chiu 0

不好意思沒看懂~如果有96GB ram, 會提升到那些方面呢?

Marck Wong

@Henry-Chiu-0 expert cached 是不是可以更多进入RAM 而不是硬盘呢？我是这么估计的。

Henry Chiu 0

@Marck-Wong 我是小白, 技術性太高的內容看不太懂, 只是也在糾結要64GB還是96GB內存, 想知道跑起來體感差別布多大, 特別是多工, 是否一邊跑一邊也能幹其他事情.

terry

没听说过这些事啊，玄学？？？是不是主板BUG？

抡锤者