逐字稿文字預覽
OK 今天来讲一下千问 3.8 27B 这个模型我最近发现了一个新框架 这个框架叫 NInfer 在特定的长上下文再加 上 MTP 的场景里面啊官方和 社区的测试速度甚至能达到两倍 那我自己这张 4090 到底能快多少呢 看到最后你就知道了 上上个星期我不是 刚部署好千问 3.8 27B 嘛那时候用 的呢是 llama.cpp 也是为了优化卯足了劲儿 十几个小时的矩阵测试 就是为了得到最好的那一个参数 啊然后终于搞满意了固定下来了 200K 上下文 七八十 tokens 每秒 那 llama.cpp 在这个阶段呢 对于我自己的硬件而言基本上是被优化到顶了 但是呢就在前两天我发现全白测了 就是在研究 VLLM 或者 SGLang 这些框架的时候呢 我发现了一个叫做 NInfer 的东西 看大家的评价是非常的 疯狂什么直接暴涨两倍的速度四舍九入那将像 四舍九入 四舍五入那就相当于多给了我一张 4090 啊 嗯这还不赶紧部署起来试试 于是呢我就让 GPT-5.6 Sol 写 了一个详细的方案 一整套啊包括部署包括测试的方案 然后把整个 plan 丢给我服务器上的 DeepSeek V4 Flash 去干 V4 Flash 一个人是吭哧吭哧干了 五个小时包括配置包括 对 NInfer 的各种参数进行矩阵测试 之后再和 llama.cpp 进行矩阵对 比 我就出了个门 然后回来他就直接给我 交付了一份能用的最佳配置和整个对比 结果的报告 这感觉太爽了就 要知道就在四五个月前 这种事情都是不可能的那时候我是逮着 GPT 对线 手搓配置 vLLM 整整搓了好几天才跑起来 来啊那给不了解的小伙伴先解释一下所谓的 NInfer 其 其实就是类似于 llama.cpp 或者 vLLM 这种框架但它和那些都不一样啊它 不是那些的派生而是一个从零写的推理引擎 它特殊的地方就在于其 他的框架是要需要考虑 不同的模型不同的硬件 怎么兼容而 NInfer 特别的地方就在 于 它把模型和硬件这一条路径给固定死了 原版主要盯的就是 RTX 5090 这个 显卡 模型呢主要就是千问 3.8 这个家族 后面有大神把它移植到了 3090 上面后 来呢又有人 根据 3090 做了 4090 的优化那 我这次用的就是这个 4090 fork 所以基本上就是把 千问 3.8 27B 这一个模型和 RTX 4090 这一张显卡 这两个固定下来往死里优化 它不需要像 llama.cpp 那样去 考虑 他拿到一个 GGUF 之后要去看 一下它的架构是什么再解析 然后再根据设备去选 一个后端再去运行这一 整套啊 llama.cpp 是为了兼容很 多模型和设备嘛 所以不可避免的会有很多妥协还有一些小 bug 但 NInfer 就是这样一个极端优化极 端固定的概念就 一旦这一条路跑通了就 优化到极致之后就连参数它都基本上不变了 那我比喻一下啊我又要来了就是一个比喻 llama.cpp 它就像一辆很优秀的 丰田 S U V 你把它开去哪里 都可以啊全世界都有零件你去哪儿都能维修 雪地沙地山路上都可以啊速度呢也还行 那 vLLM 呢可以说它像一个 地铁系统啊它在乎的不是我一个乘客能跑多快 它在乎的是我每个小时 的总吞吐量可以把多少人给并行的运起来 它最经典的技术呢就是 PagedAttention 把 KV 缓存像虚拟内存一样分页管理啊 减少显存碎片 再配合一个 continuous batching 就是 连续批处理 非常适合高并发的服务 它现在呢也有 prefix caching 啊就是可以 把以前算过的前缀直接复用 然后呢就是 SGLang 这个是特别 强调复杂工作流里面的 缓存复用比如说他会去 考虑哪些货物可以共享 路线啊哪些可以缓存哪 些可以有共同的 prefix 怎么复用这 些状态 所以呢它可能就像一个智能物流中心 它很有代表性的技 术叫做 RadixAttention 粗 略理解一下它 就是把大量的请求的 prefix 组成一 棵树 然后呢重复的 prefix 它就不重复计 算了 所以它对于 agent 的 loop 来 讲有很 多东西都是重复的嘛非常有效 那那最后就是我这回尝试的 NInfer 它呢就是一辆 F1 赛车 你赛道就是这一个赛道发动机就这一台发动机 轮胎我都是这一组轮胎 变速箱悬挂什么的都不变就 就连天气啊我都给它固定住了 所有的都是已知条件然后就往死里去刷圈 这样极端优化的 结果呢就是我这样 一张 4090 24GB 的卡 NInfer 可以 把整个 256K 的模型原生上下文啊全都 塞进去 而且生成速度可以达到平均一百 tokens 每秒 关于速度啊这些测试我后面会再展开讲一下 啊其实千问 3.8 27B 这个模型它本 身也比较特殊啊它 它不是每一层都有巨大 的 KV 缓存它是一个混合架构 所以才能在 24GB 级别的卡上 把 256K 的上下文给开满就放在以前想 都不敢想 但这个缓存呢并不是就 说原始精度而是量化后的 Q4 呃但又不是 普通的 K4V4 而是 RK4V4-E8 那这个参数具体是什么 意思呢我就不展开讲了 讲了你也听不懂啊主要是因为呢我也看不懂 啊反正就是一种比普通 压缩精度要更好一点的 旋转跳跃的压缩方式它前面那个二代表的是 rotate 嘛 啊 所以可以在精度损失很 小的前提下可以比 Q8 或者 FP16 的 KV 缓存能更省显存 就它主要的目的其实不 是提速啊它反而是比 Q8 要慢一点点 它主要是为了用尽可能 小的质量代价把 KV 压的更小 好把完整的 256K 上下文全都塞进 24GB 里面 所以总结来说啊 别的框架是要模型和 硬件向框架妥协以获取兼容 但 NInfer 呢是把自己改成了 千问 3.8 的那个形状 特别是 4090 这个 fork 只为 千问 3.8 27B 一个人服务 这是什么样的硬件榨汁儿行为啊 所以如果你有对应的九 零系列的硬件真的可以去尝试一下 呃我都我想象了一下这个框架用来跑 4090 48GB 哦 那那应该是一种天下无双的体验 果如果有优化好的话啊 他我不知道他有没有单独为了 48GB 版 本优化 哎如果有大佬试过的话可以来评论区炫耀一下 让我长长见识 那 NInfer 整个部署好之后呢我 首先让它去做了一个小 任务去修改我的 A I 本地控制台 让他把自己的 profile 给加进去 我是做了这样一个网站 部署在我自己的服务器 上这样我可以非常简单 的去切换各种服务各种 模型或者就监控大模型的流量 那给我的第一个感受啊 就是它首 token 变慢了就 llama.cpp 里面 大概是五秒钟左右就会 出首 token 它要十二三秒但这 里得说清楚啊我这里拿 的是实际 Agent 跑的时候第一 轮冷请求看到的 TTFT 也就是首 token 延迟 如果我们真的去做那个 benchmark 去测试的话呢其实纯 prefill 的吞吐没有慢那么两倍啊 大概就是落后个两三成左右 那主要是这种冷启动的 情况下一次性灌一大堆 上下文进去的场景它是要慢一点 后续呢就是缓存命中越来越高之后会越用越低 一开始大概十几秒后面就是能达到几秒 然后呢就是速度啊用下来之后 我发现一些小任务能达到 130 tokens/s 左右 就我按照以前的体感啊给他派一个任务 然后我自己切去干别的事情了 结果没过一会儿他跟我 说干好了我就有点不习惯 就跟我以前的那个体感不太一样 然后呢长链开发现在是 稳定在一百多一点 tokens 啊这 也是一个非常不错的成绩 呃因为在上下文稍微长 一点之后呢 llama.cpp 你是即便 开 MTP 它的速度大概其实也就五六十个 tokens 每秒了 好一点的情况也只有七十 所以基本上就是一个一点五倍的速度提升 然后在这个速度之外还 有一点非常牛逼的就是 呢在 NInfer 框架里面把上下文开到 顶 也就是 256K 上下文全都塞进 去的情况下还剩 1.3GB 左右的显存也 就是说啊 我们可以把视觉模型也同时给开起来 llama.cpp 呢在我个人的这台机器 上对最多我是开到 208K 左右的上下文 然后再开一个视觉基本 上就是你看到那根红线 顶着跑了啊跑着跑着就就不太稳定啊 就是命悬一线那种感觉 就每次发一个请求我菊花都紧紧的 生怕它直接爆了 啊但开 NInfer 之后呢我就直接全上 下文 然后视觉模型同时开起来 呃所以总结下来孩子吃 了 NInfer 粉之后呢显存占用更 少了上下文更长了速度更快了这有三个优点 唯一的缺点就是冷 prefill 的速度 要降低百分之二三十 再然后就是关于功耗啊这个非常的重要啊 因为我这台机器 decode 的时候 整机墙上功耗最高是会到五百三四十瓦 但是 prefill 的阶段呢就没有那么 高 特别是当缓存命中的时 候有时候大概是两三百瓦这样 然啊当然这是我说这套 NInfer 再加上 4090 的这个配 置的实测 并不是说所有的或者你 的机器也是这样你自己也可以实测一下 你可以看我这个墙上功耗的实测就是用 llama.cpp 那几天 token 总量这几天用的都是差不多的都 是一个亿左右 llama.cpp 还要再少一点啊但是呢 一天下来墙上功耗 llama.cpp 是 六千瓦到七千瓦之间就 奔着七我感觉它有时候都要破七了 但换成 NInfer 之后呢我这两天 大概就是四点五到五千瓦时之间 所以这个就光电费的区 别按照我现在的电价来 粗算一下年化下来是能省一千块钱 就换了这么个框架而已 啊当然目前这个样本还比较少没有办法确定说 但就我体感而言它的那个发热的量还 还有风扇呼啸的时间都是要更少的 最后啊总结一下我的体 验最开始我用的是 llama.cpp 啊 部署完之后用了一阵子 跟在线 API 比起来就还是 有一点点慢就有一点点 比三点六要好很多了但是就还是 有那么一点点便秘的感觉 但换成 NInfer 之后这个一百 token 每 秒的速度啊这就相当可用了 呀呃因为之 前的 DeepSeek V4 Flash 呃我 用 Open Code Go 的那个 plan 它给到的速度也就是一百到一百五之间 当然你要跟最新的 DeepSeek V4.1 Flash 这种复写式生成的速度那肯定是没法比的 啊但反正啊总之这个优 化下来我个人是非常非 常满意的我现在是直接 把整个生产都切换到了 NInfer 上面 而且用起来非常稳定就 没有触发任何问题也没有觉得质量有下降 反而啊至少在我现在 这套配置里面 NInfer 是比 llama.cpp 更省心的 因为它很多容量或者设 置在启动的时候就已经 固定和校验好了超过预算就直接起不来 而不是跑一半突然给你来个 OOM 这个之前我在 llama.cpp 里面经 历过就是在长 session 里面会 会出现一些显存和 slot 管理上的问题 因为 llama 如果你默认不去设置 KV slot 你 你不把它固定在一的话它现在默认是四 然后用的是 unified KV 这个功能概念上很好我很喜欢 但是那个我目前的配置 好像有点硬件啊可能有点水土不服 啊反正就是上下文越长越不稳定最后会崩掉 那么目前啊本地部署对我个人来说 我觉得还差最后一个问题就是并发 目前呢我个人是不希望 损失上下文去搞并发的啊 因为就 4090 单张卡而言我现 在把上下文开到 256K 个人是 非常舒爽的一个状态特 别是在 agent 搞长链开发的时 候呢有的人会觉得说一 百二十八 k 上下文够用但 我个人啊就是觉得有点 不够我甚至希望再长一点 然后在保持这个上下文 的前提下有办法啊把并发给做起来那是更好 个啊希望有什么框架可 以这个打破一下物理定律 可以让 4090 二十四 G 搞一个啊 四个左右吧我也不贪心四个长上下文并发啊 上下文在 256K 左右生成速度都维持在 一百左右 的哼宛如做梦 啊但也不是不可能的我 不是痴人说梦你看现在软件的优化是真的 翻天覆地前几个月同样 的硬件更弱的模型就 千问 3.6 那个版本嘛我 是开了 MTP 都只有 40–50 tokens/s 那才过了这 么几个月 更强的三点八模型更快 的速度啊原生四五十 MTP 直接破百 搞得我上个星期跑了十 几个小时的矩阵测试啊好不容易定下来的参数 到今天已经没卵用了 了啊但没关系啊毕竟我 自己就是非常喜欢折腾这种事情嘛啊多 多折腾一下也有更多的话题可以跟你们聊 有空欢迎再来听我唠嗑下期再见
本次執行流程與問題處理
下達指令
預期流程
- 採用來源字幕（略過語音辨識）
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：3.9 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：44.6 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.6 秒
關係：依序執行
結果：完成
4. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.6 秒
關係：依序執行
結果：完成
5. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.7 秒
關係：依序執行
結果：完成
6. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.7 秒
關係：依序執行
結果：完成
7. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.7 秒
關係：依序執行
結果：完成
8. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：119.2 秒
關係：依序執行
結果：完成
9. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.2 秒
關係：依序執行
結果：完成
10. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.3 秒
關係：依序執行
結果：完成
手動來源字幕
自動來源字幕
Whisper 字幕
- 尚未產生
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.source.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。
- 音訊下載不穩定，需更新 cookies / PO token 後重試精進模式。