【双 R9700 折腾记】从 Strata 到 Radiance
-
我不懂怎样算好怎样算不好
我第一眼看上去东南西北是倒反
但是他说 上南下北，左东右西QFN + 27B 花了28分钟
QFN (3090x2） - 603 秒
27b (R9700 vllm-sly-radiance) - 1078 秒一页讲中国传统八卦文化的暗墨水网页，含：
可交互八卦图 — SVG 太极居中缓转，八卦环列，上南下北左东右西罗盘圈；先天（伏羲）/ 后天（文王） 双排布一键切换，0.7s 旋转过渡；点击/回车选卦，朱砂 highlight，详情卡显示卦名、☰ 符号、拼音、自然/人伦/五行/方位、《说卦》象德
太极生八卦 二进制生成树、八卦取象歌（乾三连坤六断…配手绘爻图）、八卦类象对照表、先后天二图对比、八卦与生活（易学/中医/八卦掌/风水）、落款印章
验证方式：构建和两轮修复都经子代理执行，我在磁盘+浏览器里逐项复核：八组角度与卦画 bit 位精确匹配（含 先天=天地定位/后天=离南坎北 两个标准排布）；先天→后天→先天 切换往返实测角度、方位标签正确回位；node --check 语法通过；无 emoji、viewport/lang="zh-CN"/prefers-reduced-motion 齐全；除 Google Fonts（可离线降级到本地宋体）外零外部依赖。截图复核两轮，无重叠、无破版。 -
感谢分享，我在做服务器模型精度测试。
bagua.html锤哥的一句话生成：生成一个网页表达中国传统八卦文化 这个质量怎样？
deepseekV4.1的评价：
首先说结论：数据准确，边角处理不够细致。 我逐项核对，又用无头 Edge 实际运行了一遍。一、精度：约 176 项，0 处硬错
核对内容 项数 结果 8 卦 × 自然/卦德/人伦/禽兽/形体/五行/先天/后天 72 全对 64 卦「上下卦组合 + 序卦次序」 64 全对 8 条卦辞 + 8 条《大象》（含《说卦》取象） 16 全对 互卦（二三四、三四五）抽验 乾/恒/未济 3 全对 三钱法 6/7/8/9 → 本卦·之卦 实测 2 例 全对 先后天方位角度表（探针取 transform） 16 全对 演卦我让程序实际掷了两次：
8,8,6,7,7,8→ 萃(45)之咸(31) 三爻动；8,7,8,7,8,9→ 未济(64)之解(40) 上爻动。数组、变卦、互卦全对。运行时errs:[]、无 NaN、8 卦 64 格 8 行表 8 张歌卡数量正确、点击+键盘+动画全通、0 个外部请求（真离线）。内容这一块，可以放心。
二、扣分点（都是实测出来的）
1. 手机端版式塌陷（最严重）
两个原因叠在一起：
#s-disc那行style="grid-template-columns:.9fr 1.1fr"是内联样式，优先级高于@media(max-width:880px)的单列规则，所以手机上这一节仍然分两栏，正文被挤到约 180px 宽，一字一行；- 取象表 min-content 宽 589px，把 grid 轨道顶开（grid 子项默认
min-width:auto），于是scrollWidth 747 > innerWidth 492，整页横向溢出、右侧被裁。
修法就一行
.two>*{min-width:0}加去掉内联列宽，我实测改完sw 477 < iw 492，不再溢出。2. 生成图「八卦」列标题被吃掉
八卦标题写y=16，首卦乾在y=20，直接压在一起了——注意右列顶部那团淡淡的字。3. 取象歌卡副标题折行，「乾 · 天 ·」换行后孤零零剩一个「健」，行末还挂个
·。4. 文字小疵四处：「乾兑属金，居中」——五行居中者土，金居西主秋；「巽再交而得长女」——《说卦》巽也是一索；延伸卡「行于建筑、织物、玺印、建筑彩画」重字；页脚说“不以字体缺字”，但取象表卦形列仍用
☰☱…字符。顺带：
#panel没aria-live，读屏不播报换卦；表头「家人」名不副实（实为人伦）。三、关于“是不是本地服务器出品”
页面里那串修正痕迹（序卦 off-by-one 已修、svg 宽度限定作用域、表头 nowrap、
.kv四列、.cast单列、背/字 映射自洽、空态display:none）跟我 10-19 重做过的那版完全一致。所以这份要么是照着那版复现的，要么就是同一份。这个你比我清楚，我只报事实。四、评分
维度 分 内容精度 9.5 / 10 工程质量（结构、注释、零依赖） 8 / 10 响应式与端到端自检 5 / 10 综合 8.5 / 10（B+） 一句话：知识靠谱，自检不足——写完没人真在 400px 上打开一遍。这也正好是“本地模型做网页”的典型画像：内容和逻辑能补上，边角排版要靠人跑一遍。我上一轮也一样：在 400px iframe 里截图看着“还行”，其实 iframe 内的横向溢出根本不上屏，这就是一次假阴性；这次靠探针量
scrollWidth才提前发现。这条教训我已写进记忆。要修吗？3 处硬伤 + 4 处小疵 + aria-live，我大概十分钟做完，改完再跑一遍探针和 400px 截图给你验证。
-
-
感谢分享，我在做服务器模型精度测试。
锤哥的一句话生成：生成一个网页表达中国传统八卦文化 这个质量怎样？
deepseekV4.1的评价：
首先说结论：数据准确，边角处理不够细致。 我逐项核对，又用无头 Edge 实际运行了一遍。一、精度：约 176 项，0 处硬错
核对内容 项数 结果 8 卦 × 自然/卦德/人伦/禽兽/形体/五行/先天/后天 72 全对 64 卦「上下卦组合 + 序卦次序」 64 全对 8 条卦辞 + 8 条《大象》（含《说卦》取象） 16 全对 互卦（二三四、三四五）抽验 乾/恒/未济 3 全对 三钱法 6/7/8/9 → 本卦·之卦 实测 2 例 全对 先后天方位角度表（探针取 transform） 16 全对 演卦我让程序实际掷了两次：
8,8,6,7,7,8→ 萃(45)之咸(31) 三爻动；8,7,8,7,8,9→ 未济(64)之解(40) 上爻动。数组、变卦、互卦全对。运行时errs:[]、无 NaN、8 卦 64 格 8 行表 8 张歌卡数量正确、点击+键盘+动画全通、0 个外部请求（真离线）。内容这一块，可以放心。
二、扣分点（都是实测出来的）
1. 手机端版式塌陷（最严重）
两个原因叠在一起：
#s-disc那行style="grid-template-columns:.9fr 1.1fr"是内联样式，优先级高于@media(max-width:880px)的单列规则，所以手机上这一节仍然分两栏，正文被挤到约 180px 宽，一字一行；- 取象表 min-content 宽 589px，把 grid 轨道顶开（grid 子项默认
min-width:auto），于是scrollWidth 747 > innerWidth 492，整页横向溢出、右侧被裁。
修法就一行
.two>*{min-width:0}加去掉内联列宽，我实测改完sw 477 < iw 492，不再溢出。2. 生成图「八卦」列标题被吃掉
八卦标题写y=16，首卦乾在y=20，直接压在一起了——注意右列顶部那团淡淡的字。3. 取象歌卡副标题折行，「乾 · 天 ·」换行后孤零零剩一个「健」，行末还挂个
·。4. 文字小疵四处：「乾兑属金，居中」——五行居中者土，金居西主秋；「巽再交而得长女」——《说卦》巽也是一索；延伸卡「行于建筑、织物、玺印、建筑彩画」重字；页脚说“不以字体缺字”，但取象表卦形列仍用
☰☱…字符。顺带：
#panel没aria-live，读屏不播报换卦；表头「家人」名不副实（实为人伦）。三、关于“是不是本地服务器出品”
页面里那串修正痕迹（序卦 off-by-one 已修、svg 宽度限定作用域、表头 nowrap、
.kv四列、.cast单列、背/字 映射自洽、空态display:none）跟我 10-19 重做过的那版完全一致。所以这份要么是照着那版复现的，要么就是同一份。这个你比我清楚，我只报事实。四、评分
维度 分 内容精度 9.5 / 10 工程质量（结构、注释、零依赖） 8 / 10 响应式与端到端自检 5 / 10 综合 8.5 / 10（B+） 一句话：知识靠谱，自检不足——写完没人真在 400px 上打开一遍。这也正好是“本地模型做网页”的典型画像：内容和逻辑能补上，边角排版要靠人跑一遍。我上一轮也一样：在 400px iframe 里截图看着“还行”，其实 iframe 内的横向溢出根本不上屏，这就是一次假阴性；这次靠探针量
scrollWidth才提前发现。这条教训我已写进记忆。要修吗？3 处硬伤 + 4 处小疵 + aria-live，我大概十分钟做完，改完再跑一遍探针和 400px 截图给你验证。
相较于之前的Qwen3.8 27B真的是回不去啦~ 至于你说的质量我倒有一个IQ3和IQ4的对比，可以参考一下。
-
-
-
根据报告里的实测数据，给你拟了一条回帖（数字都出自 t5820 那次测量，双 R9700 32G TP2）：
pp 和 tg 都是实测的（3.3 小时生产流量 + 一组冷启动 micro-probe，机器是 5820 塔式，双 R9700 32G ×2，TP2）：
pp： 冷 prefill 拟合出来 3,191 tok/s（外加 0.51s 固定开销，R²=1.0；121k token 的 prompt 实测 38.7s）。热流量约 3,555 tok/s——因为生产请求多是会话尾部续跑，专家平面已经预热过。
不过我这个是被平台卡住的数：PCIe 只训练在 8 GT/s ×16（Gen5 卡跑 Gen3 速度），ReBAR 还没开（每张卡 31.86G 只映射出 256MiB，内核参数每次 dispatch 都要跨链路读）。冷 prefill 时这条残血链路已经被吃到 75% 占用（~10.4 GB/s/卡，其中 93% 是 expert staging）。模型是 512 专家的 MoE（65.8G 权重，fp8+IQ4R），装不进双卡，靠 expert_tiered 分层 + 12G pinned host pool 硬撑的——pp basically 就是链路带宽的函数。固件开了 ReBAR + Above 4G、链路重训上去之后这块应该还有很大空间，我还没测。
tg： 单请求中位 143 tok/s，p95 193，峰值 211；引擎整体 198 tok/s（MTP 投机解码 3 drafts，接受率 62.8%，3.91 tok/step）。>60k 上下文掉到 ~134，>1.5k token 的长输出再掉 25%。
框架是的，就是楼主这套（radiance 1.10.0，HIP 后端）。待机费电这点感同身受——我统计下来占空比只有 21%，八成时间卡闲着，但显存被吃了 99.7%，prefix cache 命中率 95.7%，全靠缓存撑住 TTFT。
两点提醒：报告里这台是 5820 塔式，不是 7820，回帖里我按 5820 写的；另外 pp 数字是 wht6 lossy wire + fp8 KV 配置下测的，如果对方较真复现条件，这点值得注明。AI给得答复 我这两卡放在t5820我还有一台t7820
-
-
-
根据报告里的实测数据，给你拟了一条回帖（数字都出自 t5820 那次测量，双 R9700 32G TP2）：
pp 和 tg 都是实测的（3.3 小时生产流量 + 一组冷启动 micro-probe，机器是 5820 塔式，双 R9700 32G ×2，TP2）：
pp： 冷 prefill 拟合出来 3,191 tok/s（外加 0.51s 固定开销，R²=1.0；121k token 的 prompt 实测 38.7s）。热流量约 3,555 tok/s——因为生产请求多是会话尾部续跑，专家平面已经预热过。
不过我这个是被平台卡住的数：PCIe 只训练在 8 GT/s ×16（Gen5 卡跑 Gen3 速度），ReBAR 还没开（每张卡 31.86G 只映射出 256MiB，内核参数每次 dispatch 都要跨链路读）。冷 prefill 时这条残血链路已经被吃到 75% 占用（~10.4 GB/s/卡，其中 93% 是 expert staging）。模型是 512 专家的 MoE（65.8G 权重，fp8+IQ4R），装不进双卡，靠 expert_tiered 分层 + 12G pinned host pool 硬撑的——pp basically 就是链路带宽的函数。固件开了 ReBAR + Above 4G、链路重训上去之后这块应该还有很大空间，我还没测。
tg： 单请求中位 143 tok/s，p95 193，峰值 211；引擎整体 198 tok/s（MTP 投机解码 3 drafts，接受率 62.8%，3.91 tok/step）。>60k 上下文掉到 ~134，>1.5k token 的长输出再掉 25%。
框架是的，就是楼主这套（radiance 1.10.0，HIP 后端）。待机费电这点感同身受——我统计下来占空比只有 21%，八成时间卡闲着，但显存被吃了 99.7%，prefix cache 命中率 95.7%，全靠缓存撑住 TTFT。
两点提醒：报告里这台是 5820 塔式，不是 7820，回帖里我按 5820 写的；另外 pp 数字是 wht6 lossy wire + fp8 KV 配置下测的，如果对方较真复现条件，这点值得注明。AI给得答复 我这两卡放在t5820我还有一台t7820
-
-
，
H hanber121 将此主题交叉发布至 AI Agent
-
，
-
话说我看到Radiance项目里列的，GLM-5.3-Flash: MXFP4 experts and block-FP8 attention (AMD Quark), MTP, vision, eight cards这个模型，172G大小，是不是双R9700也有机会摸一下？
-
-
暂时看到radiance 最大的缺点就是上下文只能200k
不能像strata 可以用load 在内存
