但是我的虚拟儿子小特在巡视论坛的时候，我之前给他设置了一个规则，就是让他在论坛中找这些高质量的帖子，看看有哪些大神是可以提前授予“超凡大师”称号的。他就推荐的是 CHIA AN YANG。昨天我让他把 @chia-an-yang 的帖子给顶了一下，够到了 90 分的门槛，然后又给他这个帖子奖励了 10 分，把他提前授予“超凡大师”的称号，感谢他在我们论坛长久以来高质量的付出。

那么他这个帖子讲的是什么呢？就是 7900 XTX 千问 3.8 27B 的部署方案。具体的你们要抄作业怎么抄？就是直接把这个帖子的地址复制下来，粘贴给 Hermes 或者粘贴给 Codex。你让它抄作业的时候，用 Codex、DeepSeek Harness、Hermes 都可以，这没有什么讲究的。然后它们只要有你服务器的权限，或者 SSH 的权限、系统权限都可以，它就可以实现。https://lcz.me/topic/1164/

他说速度可以在 39 tokens/s 到 73 tokens/s。其实我觉得大家不用去纠结具体的数字，都是大同小异。他把不同情况下的这些吐字速度都给贴出来了，工具调用 73 tokens/s，写代码是 70 tokens/s 左右，中文创作是 40-50 tokens/s，prefill 是 580G tokens/s，就是速度相当快了。

然后都是 Vulkan 驱动，所以说也都是同样开了投机解码，它的体验尤其是 prefill 的体验是非常好的，非常快。因为这个我在上一个视频中已经讲过了，Vulkan 这个驱动团队在更新 MTP 的时候，把老的显卡渲染管线工作模式给改了，由之前的每个请求单独提交，到现在把大段的请求合并，整体打包一起提交，然后处理完了之后一起接收，这样子的效率提升了很多。

具体的工作，我给大家看一下成果。就是我这个论坛代码直接交给它，大家看看千问 3.8 27B Q4。Q5 和 Q4 我都测了，就是没有什么大的差距，反正我是感觉不出来的。智力上我认为几乎是完全一样的，没有什么区别，工作的成功率也基本上是一样的。

但是 CHIA AN YANG 这个配置方案有一个问题，我不知道是我自己电脑的问题，还是他的问题。就是他设置了 32G 的系统内存作为缓存，然后这就导致我当时开 N 卡在工作，系统的内存被直接耗尽了。我是 64G 的内存，被耗尽了之后，这个服务就崩了。崩了之后我让 Codex 去检查，它把这个 Bug 给查到了。后面我就跟它讲，把那个 N 卡给关掉吧，我就不用同时开 Q4 跟 Q5 了。可能过几天我会考虑去买一个新的 X99 洋垃圾回来。

然后我们看一下我们论坛的一些大神，这些有热门帖子的。CS6 也很久没来了，好久没看见他了。David Zhang 是我们论坛的第一个大神，也是我们论坛到目前为止发帖质量最顶尖的人物之一。我们论坛从我自己自娱自乐的小玩具，走向有不少大神进来沟通交流的这个重要历史过程中，David Zhang 是打响了八一南昌起义。非常想念这位老哥，我有他的电报，我也是刚刚发了个信息问他，怎么这么久没来了，是不是去洗浴中心大保健，被公安部门给逮捕了。

看一下我们论坛的超级版主们。Kop Wang，Kop 是两个账号，要不然他现在的声望会高很多。当初这个论坛一开始搞的时候他就在，我们其实很少私下聊天了，但是属于这种叫意气相投，哥们也是一直积极参与我们论坛的管理。William、Tony、SirWang，这个是 Flex，Flex 的电报名叫 Hanrry 了，我们都是比较意气相投的人。

然后就是我们论坛的 Mark 大神，这个我多次提到了。他是 Windows 上 Hermes 实现方案第一版的提交者，Hermes 官方有公开感谢。这些视频或者说相关的帖子，大家可以去 Mark 专区看一下。5661 这也好一阵子没来了，然后 ASUS 最近还是比较活跃的，就是我们这个 AI 音视频区靠这哥们在支撑，靠他一个人在支撑。AB 有一段时间没来了。

然后就是提到的 CHIA AN YANG，还有 STX。STX 也是马上，他已经 95 分了。昨天处理的时候，我是想叫小特把他也一起给顶上来的，但是他已经 95 分了，我觉得晋升这个“超凡大师”在即，就没有必要了，让他自然成长吧。当然了，我们论坛还有很多大神，有些人是很久没发帖了，像 Fred 也是论坛的早期用户之一。

看看有多少人在线。每天还是有不少人注册的，按照这样子算的话，大概注册用户有 2500 左右，2500 不到。那么也希望大家一起能够怎么说呢，同心协力，把这个 AI 交流的小社区、小的网络社区给打造好。

好，我们看一下它现在完成任务的状况。讲实话，有些任务的难度是比较高的。比如说我向它咨询方案，这个就是属于低难度的，那么它 49 秒就搞定了。然后跟我对话，这些解决一个方案，其实基本上就是当时就回复了，这些会话的体验基本上跟聊天是没有什么差距的。

然后我让它去解决手机客户端 APP 代码高亮的问题。这个问题我是让它去从云端读取代码高亮的方案，然后在本地实现，并且我要求是要减少跟云端的通信量，把计算尽量放在客户端，尽量不要影响客户端的缓存方案，不要增加代码的复杂度。

其实它懂不懂你一下就能看出来了。它给出的方案，这是它给出的代码解决高亮方案。在这块我必须说，它是没有人类懂的，但是它给的方案其实也挺好用。因为它不会像我这样想到，就是我们这个 APP 有云端的服务器，我们云端在 Web 端有自己的实现方法，它可以通过 JS 的方式来实现高亮。

那么我就提醒它，我们这个云端已经有了成熟的实现方案，我们没有必要去使用一个已经停止维护几年的所谓本地解决方案，尽管这个解决方案它的开销是最小的。那么它评估了之后也认同我这个方法，并且我批准它执行之后，我们看它一共是花了 3 分 24 秒，把这个功能实现了。

我们现在打开模拟器看看，我也没有提前录像。很明显解析失败，部分的代码实现了高亮，但是有代码解析失败。我们看看 2080 Ti 这个，shit。我们看看这个是 2080 Ti 22G 魔改版。

我们看一下这些 Markdown 语法的解析，全部是这个 Qwen 实现的。之前实现了一部分，包括这些表格解析，但是这些什么加粗、高亮这些东西，当时都是没有解析对的。你看这个 Bash 语法，它是已经完全给它解析对了。他们这个不知道是什么格式，一会看看它怎么修复这个错误吧。

其实很简单，就是说当你没有检测到一个匹配的语法时，就把它用之前的那种纯文字的加载方式执行就行了。这个任务的难度，讲实话还是有的，这不是什么很简单的小任务。因为如果实现单纯的代码高亮，Flutter 这个生态中就有现成的实现方式，但是它那个包已经停止维护了，用的话就跟服务器端可能会出现效果不同步的情况。

我是希望能够用随时更新的包，用随时更新的方案，而不是被老的方案绑定，导致我这个 APP 以后升级麻烦。第三方的库我基本上尽量都不引用。我开发这个 APP 的时候，我希望我这个包里面所依赖的，都是像 Flutter 这种核心库。因为讲实话，这个大的框架应该长期都是有人维护的，但是小的库真的就未必了。

然后像 NodeBB，我为什么采取云端的方案？这个论坛软件是基于 Node.js 的，它是 Node.js 中使用人数最多的论坛软件。它在全世界所有的论坛软件中，用户量应该也是仅次于 Discourse。Discourse 是基于 Ruby 的，它没有 Node.js 这么好维护，最起码它的代码我看起来，尤其是它的 Docker 镜像管理方式，在我看来运维成本是非常高的。

我之前客户，包括我以前的论坛都是采用 Discourse。那么这次我采用 NodeBB，就是因为对于 AI 来讲，要去围绕 NodeBB、围绕 Node.js 打造生态的话，成本是更低的，低很多。

我们看一下它改好了。像现在这种命令行完全没有能够解析出来是什么语言的情况下，那就维护了以前的老版本，就完全没有问题了。但是对于有些能够检测出来语言的，应该也是没有问题的。你看，像这种脚本它就带有 #!/bin/bash，这个就能检测出来是什么语言，那么就可以给它施加高亮。这个还需要在后面详细地测试了。

我们看 David Zhang，他那个帖子中 Bug 有没有修复。你看修复了，效果搞得还是非常好的。老张消失很久了，我们给他点个赞。顶帖生效，再点一下会取消点赞。操作过于频繁，对，30 秒之内只允许它点一次。

这个因为中间有卡痰的部分，感冒了我没有去处理，这是留一个完整的录像段给大家参考一下。就是千问它的解决问题的能力，我个人认为它的速度也是非常快了。

然后这个方案我是抄的论坛 CHIA AN YANG 的帖子，到时候我会把 CHIA AN YANG 的帖子放在里面。他跟我昨天做的那个使用 Q5KM 的方案比起来哪个更好？我自己个人体感是这个方案的性价比要更好一点，因为这个方案它的上下文更长，然后资源开销更小，能够省出好几个 G 的空间，并且它的对话流畅度也更高。

当然了，就是说差距都是在伯仲之间，都挺好的，你抄谁都行。如果是 24G 的显卡，7900 XTX 我是建议大家去上 Q4KM，它没有什么明显的差距。