把你的实测交给我们，下一个人就少撞一次墙

第三列是形状示例，不是我们的数据——这一页一个真实数字都没有。 它示范的是"这一格该长什么样"：模型那格要给到能唯一确定一个权重的程度， 量化那格要写档位而不是"量化过了"。

同一张卡在网上有五种以上写法（7900XTX / 7900 XTX / RX 7900 XTX / Radeon RX 7900 XTX / gfx1100）。 把型号、显存、量化档归到同一个条目上是我们的活，不是你的—— 所以别为了"写规范"去查我们的内部字段名，那只会让你多花时间、还容易写错。

缺哪一项就如实缺着。我们的记录里允许有缺口，缺口会显示成一个横杠， 意思是"来源没说这一项"——它比一个猜出来的值有用得多。 反过来，「关了」是一个值：flash attention 关了就写"关了"，不要留空。

1. ① 原始日志（首选）

   把程序自己打印的那段日志原样贴上来，就是下面这种：

   llama_print_timings:        load time = 62270.78 ms
   llama_print_timings: prompt eval time = 60647.60 ms /   323 tokens (  187.76 ms per token)
   llama_print_timings:        eval time = 46631.52 ms /   202 runs   (  230.85 ms per run)

   这类日志只占我们见过的跑分内容的一小部分，但它的价值是压倒性的： 精度接近 100%，而且自带版本号与完整配置。我们不用去猜你用的是哪个 build、 ctx 开了多大——日志里本来就有。所以它排第一。

2. ② 跑的那条命令原文

   你敲的那一条命令，原样复制，参数一个都别删（包括你觉得无关紧要的）。 形状大致是下面这样：

   形状示例 · 照你实际跑的那条复制

   $llama-server --model Qwen3-32B-Q4_K_M.gguf --ctx-size 4096 --cache-type-k q8_0 --flash-attn on --n-gpu-layers 99复制

   命令是日志之外第二好的东西：它把"配置"这一组字段一次性说全了， 也让我们能看出你是不是用了别人不会用的参数。

3. ③ 可复现的最小信息

   没有原始日志、也说不清命令的时候，至少把这七项给全： 硬件、框架与版本、模型、量化、上下文长度、显存峰值、跑了几次。 少任何一项，别人（包括我们）就没法在同一条件下重跑一遍—— 而能不能被重跑，决定了这条数据将来能不能升到更高的可信级别。

只给一个 tok/s 数字，不算一份可用的提交。 一个没有配置、没有版本、没有样本量的速度值，我们既没法核对也没法比较， 最后只能放进"看不出来源"那一堆里——那对你、对下一个人都没有价值。 这句话在下一节的审核标准里会再出现一次：它不是建议，是会被驳回的情形之一。

L0 自报

自动汇聚的公开数据，站方没有机器去验证

L1 已复现

社区在真机上独立重跑过，含复现次数

L2 跨框架已验证

同硬件 + 同模型 + 同量化下的多框架实测对照

• 入库时一律是最低档（L0）。 这不是对你这份数据的不信任，而是这套分级的默认取值：新记录进来时， 我们还没有任何"别人也跑出过同样结果"的证据。缺失或读不出来的级别也一律按这一档处理 ——降级永远往"更不可信"的方向走，绝不因为字段缺失而放行。
• L1 / L2 只能由人工升级，机器不自动标。 升级的依据是记录之间的相互印证：别人在真机上独立重跑过、数字对得上， 或者同一台机器同一个模型在多个框架下跑出了同一个量级。 这里没有可以自动化的捷径——一旦机器能批量升级，这套分级当场失信， 而它失信之后，页面上所有数字都跟着变成不可信的。
• 投稿这个动作本身不改变档位。 你投一份数据上来，它会以最低档入库，和别人被采集进来的记录走同一条路。 级别只由"有没有被独立重跑过"决定，与"这条是谁交来的"无关—— 既不因为你亲手交而更高，也不因为我们自动采集而更低。

这一节刻意不给任何数字阈值。判定规则是站方唯一持有的那份， 改一次只在一个地方改；页面这边只保证你看到的那几行与它同步—— 两份说明放久了必然对不上，而对不上的时候没人会去核对哪一份是对的。

这句话是本页最重要的一句，所以它没有修饰。我们确实在自动采集公开数据， 但自动采集不等于自动发布：采集来的记录同样要有人看过、点过通过， 才会出现在页面上。你交来的记录走的是同一条队列、同一个开关—— 在它被放行之前，别人在站点上搜不到它。

三根轴互不顶替。「还没审」既不等于「还没被重跑过」，也不等于「不可信」—— 把这三件事压成一个字段，读者就没法判断一个数字到底卡在哪一步。 所以站点与对外接口只输出发布状态为「已通过」的记录； 其余记录仍在库里，只是不对外。

• 会被驳回的：缺原始来源。 我们要能点回你贴出这份数据的地方（issue、帖子、仓库文件都行）。 没有出处，我们既没法核对，也没法在将来发现它被更正时跟着改。
• 会被驳回的：只有数字没有配置。 单独一个速度值不构成一条记录——同一个模型换一个量化档就能差出一倍， 没有配置的数字没有可比性。
• 会被驳回的：配置与数字对不上。 例如显存峰值报得比那张卡本身的显存还大，或者上下文长度超出了模型的上限。 这类不一致通常只是一个笔误，但我们会先退回，不替你改。
• 会被驳回的：认不出是哪台机器、哪个量化档。 写法可以随便，但得让一个同样在折腾本地模型的人读出唯一一种解释。
• 会被驳回的：把别人的数字当成自己的实测。 转发一条别人的跑分没有任何问题——标明出处就行， 那正是"原始来源"这一栏的用途。当成自己的实测报上来，性质就变了。

每次审核动作都会留痕（谁、什么时候、通过还是驳回）。这不是为了追责， 而是为了同一条记录被反复讨论时能看出改过什么—— 数据被悄悄改掉而没人记得原样，是这类库最难补的一种损坏。

为什么没有：真正的投稿通道属于数据采集管道的一部分，是一个独立子系统 （入库、归一化、查重、与已有记录比对，都是它的活）。我们先把指南立起来， 因为缺指南比缺表单更耽误事——一份没有配置、没有出处的提交，交上来也进不了库， 那一次往返对双方都是浪费。

今天的通道只有一条：项目仓库的 Issue （临时通道）。开一条 Issue，把上面那八组信息贴进去， 一条 Issue 一份实测——这样别人可以在同一条 Issue 底下补自己的重跑结果， 而那正是让一份记录升到更高档位的方式。

• 要贴什么：照上面第一节的八组信息贴。原始日志最好， 日志太长就在 Issue 里折叠；命令原文和配置表照抄。 不要替我们做归一化——型号、量化档按你平时的写法写就行。
• 不要贴什么：不要只贴一个 tok/s 数字； 不要贴截图里只剩速度值的那一角（型号与版本往往正好被裁掉）； 不要贴别人的数字而不标出处。
• 交上来之后会发生什么：它会以最低档入库，和采集来的记录一样排队等审核。 通过之后，它会出现在 数据页、 以及它对应机器与模型的 能跑什么 与 怎么配 上—— 下一个人搜到这台机器时看到的就是你的数字。

通道上线之后，这一页会给出真正的入口，并撤掉上面这段说明。 在那之前，这里不会有任何看起来能提交、点下去没有反应的控件—— 本站已经因为"摆一个点下去是死路的入口"返工过两次。