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

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

1. 测试平台

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

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

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，文件大小已检查：

这个合计不含单独的 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 分钟、零修复完成”。完成页的截图如下：

5. Monitor 读数：速度与资源

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

后续截图里若干请求的 Decode 为 71.4、75.0、78.8、75.4 tok/s。这些样本能说明当时的实际使用速度，不能据此宣布整场均速。下面这张截图拍摄时已经 Idle，显存显示 1.7GB，不应拿它当作运行模型时只需要 1.7GB 的证据；其 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 无关，颜色和清晰度也经过压缩。

视觉上，海面的波纹和日光反射较有氛围，鹈鹕的长嘴、喉囊、折叠翅膀和 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所在讨论。参考的是呈现环境、参数、实测与限制的方式，没有把其他机器的成绩算成本机数据。