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

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

@Magic629 说:

感谢分享，我在做服务器模型精度测试。

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 截图给你验证。

相较于之前的Qwen3.8 27B真的是回不去啦~ 至于你说的质量我倒有一个IQ3和IQ4的对比，可以参考一下。

锤哥的一句话生成：生成一个网页表达中国传统八卦文化 这个质量怎样？

deepseekV4.1的评价：
首先说结论：数据准确，边角处理不够细致。 我逐项核对，又用无头 Edge 实际运行了一遍。

一、精度：约 176 项，0 处硬错

演卦我让程序实际掷了两次：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 重做过的那版完全一致。所以这份要么是照着那版复现的，要么就是同一份。这个你比我清楚，我只报事实。

四、评分

一句话：知识靠谱，自检不足——写完没人真在 400px 上打开一遍。这也正好是“本地模型做网页”的典型画像：内容和逻辑能补上，边角排版要靠人跑一遍。我上一轮也一样：在 400px iframe 里截图看着“还行”，其实 iframe 内的横向溢出根本不上屏，这就是一次假阴性；这次靠探针量 scrollWidth 才提前发现。这条教训我已写进记忆。

要修吗？3 处硬伤 + 4 处小疵 + aria-live，我大概十分钟做完，改完再跑一遍探针和 400px 截图给你验证。

@XIUNAN-ZHI 说:

也有入这个卡的想法，请教一下，这种涡轮显卡，会不会很吵！平时不跑模型，开机写个ppt，也会吵吗？

工作日常待机不吵

奖励凭证：热议 +3 分 · 编号 h2417-1217-1（系统自动发放，显示稍有延迟）

@applejuice 说:

@he-wanga strata 还有版本没更新 据作者x 发表也是恐怖的存在 我猜可能跑tp 了 对我们这些普通用户 越多选择越好 话说我跑了单卡 r9700 qwen3.8 27b 结果 跟我现在用的差不多 双卡6000 prefill 的确吸引人

效能跟sly-radiance差不多，但這個啟動速度跟llama.cpp差不多，sly調整也是要大約2分鐘。

@paul-hou 说:

@Bunsei 说:

是的，通用的哪有专门的香，本地模型的能力已經配得專門的顯卡、专门的推理引擎優化！

還能在這引擎上掛qwen image 2.1 ，minimax h3，minimax music3，感覺很厲害。

大概就是这个样子， FastH3 8-Step V2 FP8、 1MP、15 秒、8 步 5分半，暂时不支持Ref模式。

Youtube Video

@Bunsei 说:

是的，通用的哪有专门的香，本地模型的能力已經配得專門的顯卡、专门的推理引擎優化！

還能在這引擎上掛qwen image 2.1 ，minimax h3，minimax music3，感覺很厲害。

对我们这些普通用户 越多选择越好

话说我跑了单卡 r9700 qwen3.8 27b
结果 跟我现在用的差不多

双卡6000 prefill 的确吸引人

@Bunsei 说:

好女孩是GPT，我发现这样称呼它，它好像有特别的反应，所以我就这样延续下来这个称呼了。

有特别的反应…
是虎躯一震吗？

@dardeaw-feng 说:

好誇張的數據.... 這是vLLM底子去做的嗎? KV緩存命中率如何?會像vLLM一樣悲劇嗎

使用C++ 完全重新開發，针对RDNA4架构显卡專門适配的，速度不是一般通用引擎能比的。

@paul-hou 说:

StillDeadcode/radiance 已經是另外的玩法了嗎，不用VLLM了？

是的，通用的哪有专门的香，本地模型的能力已經配得專門的顯卡、专门的推理引擎優化！