本机生成 DM DOKURO 风格配乐:三条路线的实测结论

起因是我给自己做的游戏配 boss 曲。目标定得很死:纯音乐,风格对标 DM DOKURO 在 Calamity Mod 里写的那批曲子。 机器是 7900 XT,20GB 显存。素材是官方 OST 45 首加附属/后 DM 时期 9 首,共 54 首,约 14 小时。 前后试过三条路线,全部停在半路。结论先放前面,细节在后面。 路线一:音频 MoE 最早的构想把 MoE 用在音乐生成上:一个总线专家常驻显存管协调,分专家驻内存,训到哪个调哪个进来;架构用 Transformer 混 Mamba。 实测不成立,三个原因。 MoE 的价值是隔离多域冲突。只有一个目标风格时,dense 的样本效率更高;要"多作曲家/多风格"才轮得到 MoE,而且是各专家从共享底座 fine-tune,不是从零。 按职能划分的"总线/编曲/弦乐/管乐/母带"不是 MoE,是专家系统流水线。MoE 要求专家同质,即同形状的 FFN 切片,靠 router 逐 token 挑;上面这些专家异质到不是同一种东西,没有可共享的 token 空间。 “旋律/和声/节奏"这种划分同样不成立。token 里每个位置同时带音高、时值、时序,三个维度不可分,router 学不到分解边界,训出来只是三个同质专家加路由噪声。 另有两处硬约束。窗口砍到 2–3 秒是自毁:DM 的 boss 曲基本是 4 小节 riff 循环,165bpm 下约 5.8 秒,2–3 秒窗口连一个 riff 都装不下。20GB 单卡在底座冻结、优化器卸载的前提下,可训参数 2B 封顶,而且"逐专家轮流驻显存"在梯度与优化器状态上就走不通。 ...

October 15, 2026 · 2 min · Zelystaric

中文 AI 味检测器:数据比架构重要

起因挺无聊的。有一阵觉得自己写的东西读着别扭,说不上哪不对,就是有股"AI 味"。加上网上中文文章里 AI 的占比肉眼可见地涨,就想做个工具,发博客之前能过一遍。 现成的用过,腾讯朱雀那种。给个分数,要问它为什么,答不上来,黑盒。需要的是能指着某一句说"这句像 AI"。所以最后还是自己训了一个。 模型不大,chinese-roberta 打底,一百来 MB。没有让它纯自己学,另外塞了一批能说清楚的特征,像破折号、冒号、括号里注名词、markdown 表格、几个套话词,还有句子长短的起伏。编码器一条路,特征一条路,最后拼起来判。 数据是最费劲的。能直接下的中文"人 vs AI"语料没多少,基本靠拼。人这边有 HC3、SemEval 的中文、中文维基,还有一份份攒的真人技术博客和公众号;AI 那边有开源模型生成的、GPT-4 的、也有拿本机模型现造的。切的时候按生成器留、按领域留,不这么切,数字好看但没意义。 做下来最深的感受是:架构不重要,数据对不对口才要命。只用问答数据训过的版本,同分布上准确率九成五,换一篇技术博客去测直接崩。补了同领域、同来源的样本之后,跨生成器才起来。 有个结论跟常见说法相反。都说括号里解释名词、破折号是 AI 特征,拿真人技术博客和 AI 的比,真人括号其实更多,因为要注原文名和年份,破折号也不少。真正稳的是套话密度、排比,还有句子长短太均匀。 除了分类,还加了一路叫"话语脚手架"的东西,专盯报幕句、对比句式、结尾的总结收口。有些文章词面洗得挺干净,行文的架子还在,人能感觉到,普通分类器却看不出来。拿它去测那篇 7900 XT,一段一段能指出问题在哪。 踩过一个坑。工具在长文上老把结果判成 AI,逐段拆开又都是人。原因是滑窗写法:直接切 token 的时候,把句首句尾的特殊符号也切掉了,模型拿到的是残缺输入。改成按字符切窗、重新 tokenize 就正常了。这类问题只在长文上复现,短文本测不出来。 代码在 GitHub:ZelyStaric/Simple_Chinese_Text_Ai_Detector 。脚本、特征、实验记录都在里面,数据和模型没传,一是大,二是版权。 AI 检测本身是个移动靶,去味工具一直在更新,今天抓得到明天未必。当参考可以,当唯一依据不行。能帮一篇文章挑出几处毛病,就够本了。

October 1, 2026 · 1 min · Zelystaric

7900 XT 跑本地大模型:硬件约束与走不通的路线

7900 XT 用了快两年,当初冲着 20G 显存,按跑 27B 模型的规划买的。 这半年基本都在跟它较劲。 先说硬件底子,不然后面讲不清。RDNA3 没有张量核,矩阵指令只剩 CU 上的 WMMA,规格 16×16×16,fp16/bf16/int8/int4。实测 bf16 峰值 16~17 TFLOP/s,跟 NVIDIA 的专用张量核不是一个量级。fp8、tf32 没有,TMA、cp.async、mbarrier 这些也都没有。所以预填是算力活,快不了;解码是带宽活,标称 722 GB/s,实测大概能跑到 56%。 NInfer 那个引擎原本只支持 NVIDIA sm_120a,挪到 ROCm / gfx1100 花了几天,能跑,输出对,PPL 正常。真正的难点在性能,比移植本身大得多。 MMA 没有硬件支持,只能用 SIMT 凑,拿 __shfl 手写 m16n8k16,结果对,但慢。q8 grouped 内核共享内存超 64 KiB,只能缩 tile,一缩并行度就没了。GDN 的 gating_proj 协作网格超上限,要限流。fp8 KV 预填直接崩,还是 64 KiB LDS 那道坎。 q4/q8 的线性测试会在 ~DeviceArena 走到 hipFree 的时候死锁。用 gdb 查过,是 ROCm 7.2.3 运行时自己的问题,跟 NInfer 无关,绕过即可。 另外两条没有做。WMMA 重写,RDNA3 只支持 16×16×16,fragment 布局跟 PTX 的 mma 是两回事,估 15~20 天。外挂 draft 投机,要动 Engine 架构,双模型、双 KV、draft/verify 都得改,也要十几天。这两条都没投时间。最后停在 prefill 249、decode 41.5 tok/s(带 MTP)。 ...

September 27, 2026 · 1 min · Zelystaric