影片筆記：NInfer + 千问3.8 27b = 1.5倍速@256K上下文(单张4090 24GB)

<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->

⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

• 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

一句話總結

講者實測在單張 RTX 4090 (24GB) 顯存上，使用針對千問 3.8 27B 與 NVIDIA 硬體極端優化的 NInfer 框架，成功在 256K 長上下文下實現約 100-130 tokens/s 的生成速度，相比原有使用的 llama.cpp 提升約 1.5 倍，並解決了顯存溢出與穩定性問題，但代價是較高的冷啟動延遲。

核心重點

1. 性能大幅提升：NInfer 在 256K 上下文場景下，生成速度達 100-130 tokens/s，相較於 llama.cpp 的 50-70 tokens/s，速度提升約 1.5 倍。
2. 顯存效率與併發能力：NInfer 能在 24GB 顯存內完整容納 256K 原生上下文，並剩餘約 1.3GB 顯存，允許同時運行視覺模型；而 llama.cpp 在 208K 上下文加視覺模型時極易發生 OOM（顯存溢出）。
3. 極端優化策略：NInfer 並非通用兼容框架，而是從零撰寫的推理引擎，針對特定模型（千問 3.8 家族）與硬體（RTX 4090/3090/5090）進行固定路徑的極致優化，比喻為「F1 賽車」。
4. 冷啟動延遲較高：NInfer 的首 Token 延遲（TTFT）約需 12-13 秒（因一次性灌入大量上下文），顯著慢於 llama.cpp 的約 5 秒，但隨緩存命中後速度會提升。
5. 功耗與穩定性優勢：NInfer 日均功耗較低（4.5-5 kWh vs llama.cpp 6-7 kWh），且運行更穩定，避免了 llama.cpp 在長會話中因 KV Slot 管理導致的崩潰問題。

詳細大綱

一、 背景與動機

• 講者先前使用 llama.cpp 部署 千問 3.8 27B，經過十幾個小時的參數矩陣測試，固定了 200K 上下文，速度約 70-80 tokens/s。
• 發現 NInfer 框架，社區評價稱速度可翻倍，決定進行測試。
• 使用 GPT-5.6 Sol 撰寫部署與測試方案，並交由伺服器上的 DeepSeek V4 Flash 執行配置與對比測試，僅花 5 小時即完成最佳配置報告。

二、 NInfer 框架特性解析

• 核心概念：
• 非 llama.cpp 或 vLLM 的派生，而是從零撰寫的推理引擎。
• 極端固定與優化：不追求通用兼容，而是將「模型」與「硬體」路徑固定死。
• 原版針對 RTX 5090 與千問 3.8 家族；講者使用的是移植至 3090 後再針對 4090 優化的 fork 版本。
• 比喻說明：
• llama.cpp：像 Toyota SUV，兼容性好，哪裡都能修，速度尚可，但需妥協。
• vLLM：像地鐵系統，重視吞吐量（Throughput），使用 PagedAttention 管理 KV 緩存，支援 Continuous Batching。
• SGLang：像智能物流中心，強調複雜工作流中的緩存複用，使用 RadixAttention 將請求前綴組成樹狀結構以減少重複計算。
• NInfer：像 F1 賽車，針對單一賽道、單一引擎、單一輪胎進行極致優化，所有條件已知，只為刷圈速。

三、 技術細節：千問 3.8 27B 與顯存管理

• 混合架構：千問 3.8 27B 並非每一層都有巨大 KV 緩存，採用混合架構，使得在 24GB 顯存上運行 256K 上下文成為可能。
• 量化技術：
• 使用 RK4V4-E8 量化方式（非普通 Q4/V4）。
• 目的非提速，而是以最小質量代價壓縮 KV 緩存，使其比 Q8 或 FP16 更省顯存。
• 速度可能比 Q8 稍慢，但能將完整 256K 上下文塞入 24GB 顯存。

四、 實測對比結果 (NInfer vs. llama.cpp)

• 速度表現：
• NInfer：短任務約 130 tokens/s，長鏈開發穩定在 100+ tokens/s。
• llama.cpp：即使開啟 MTP，速度約 50-60 tokens/s，好情況 70 tokens/s。
• 結論：NInfer 速度提升約 1.5 倍。
• 首 Token 延遲 (TTFT)：
• NInfer：冷請求首 Token 約 12-13 秒（因一次性灌入大量上下文）。
• llama.cpp：約 5 秒。
• 註解：純 prefill 吞吐量差異約 20-30%，主要差異在冷啟動場景；隨緩存命中，NInfer 速度會降至幾秒級別。
• 顯存與併發能力：
• NInfer：256K 上下文下剩餘 1.3GB 顯存，可同時開啟視覺模型。
• llama.cpp：208K 上下文加視覺模型時，顯存處於臨界點，易崩潰。
• 功耗與成本：
• llama.cpp：日均功耗 6-7 kWh，峰值 530-540W。
• NInfer：日均功耗 4.5-5 kWh，峰值較低，發熱與風扇噪音較少。
• 估算：按當前電價，年化可節省約 1000 元。
• 穩定性：
• llama.cpp：預設使用 Unified KV 功能，在長會話中易出現顯存與 Slot 管理問題，導致崩潰。
• NInfer：啟動時已固定參數，超預算直接無法啟動，運行中更穩定，無 OOM 問題。

五、 總結與展望

• 體驗轉變：從 llama.cpp 的「便秘感」轉變為 NInfer 的「可用且穩定」，速度達 100 tokens/s 已足夠日常 Agent 開發使用。
• 未來願景：講者希望未來能有框架打破物理定律，在 4090 24GB 顯存上實現 256K 上下文與 4 路併發，且維持 100 tokens/s 速度。
• 技術迭代感慨：軟體優化進步神速，前幾個月千問 3.6 開 MTP 僅 40-50 tokens/s，如今千問 3.8 原生支援 MTP 即可破百，舊參數測試已失效。

工具 / 模型 / 名詞整理

• 模型：
• 千問 3.8 27B (Qwen 3.8 27B)
• 千問 3.6 (Qwen 3.6)
• DeepSeek V4 Flash
• DeepSeek V4.1 Flash
• 框架/軟體：
• NInfer
• llama.cpp
• vLLM
• SGLang
• Open Code Go (提及用於生成 plan 的工具)
• 硬體/組件：
• RTX 4090 (24GB)
• RTX 3090
• RTX 5090
• 4090 48GB (提及的硬體版本)
• 技術/術語：
• MTP (Multi-Token Prediction)
• PagedAttention
• Continuous Batching
• Prefix Caching
• RadixAttention
• KV Cache / KV Slot
• Unified KV
• GGUF
• TTFT (Time To First Token)
• Prefill / Decode
• OOM (Out Of Memory)
• Q4 / Q8 / FP16
• RK4V4-E8 (量化參數)
• 256K / 200K / 128K (上下文長度)
• tokens/s (每秒令牌數)

操作流程整理

1. 前期準備與測試方案制定：

• 講者使用 GPT-5.6 Sol 撰寫部署與測試方案。
• 將方案交由伺服器上的 DeepSeek V4 Flash 執行配置與對比測試。
• 僅花 5 小時即完成最佳配置報告。

1. 環境部署與參數設定：

• 使用移植至 3090 後再針對 4090 優化的 NInfer fork 版本。
• 設定 千問 3.8 27B 模型，採用 RK4V4-E8 量化方式以壓縮 KV 緩存。
• 設定上下文長度為 256K。

1. 實測執行與對比：

• 執行冷啟動測試，記錄首 Token 延遲（TTFT）。
• 執行長鏈開發測試，記錄生成速度（tokens/s）。
• 監控顯存使用情況，確認是否發生 OOM。
• 監控日均功耗與峰值功耗。

1. 結果分析與優化：

• 對比 NInfer 與 llama.cpp 的速度、顯存、功耗與穩定性。
• 確認 NInfer 在剩餘 1.3GB 顯存下可同時開啟視覺模型。
• 評估穩定性，確認無 OOM 問題。

值得注意的限制或風險

1. 冷啟動延遲高：NInfer 的首 Token 延遲（TTFT）約需 12-13 秒，顯著慢於 llama.cpp 的約 5 秒，這是由於一次性灌入大量上下文所致。
2. 非通用框架：NInfer 針對特定模型與硬體進行極端優化，不追求通用兼容，可能無法直接應用於其他模型或硬體組合。
3. 量化速度影響：使用 RK4V4-E8 量化方式可能使速度比 Q8 稍慢，但能將完整 256K 上下文塞入 24GB 顯存。
4. 參數固定限制：NInfer 啟動時已固定參數，若超預算直接無法啟動，缺乏動態調整的靈活性。

逐字稿辨識疑點

• 千問 3.8 27B：逐字稿中多次提及「千問 3.8」，通常千問系列版本號為 1.5, 2, 2.5 等，「3.8」可能為口誤或特定內部版本，需查證是否為「千問 2.5」或「千問 3」之誤聽，或確實存在該版本。
• GPT-5.6 Sol：模型名稱「GPT-5.6」與「Sol」組合非常規，可能為聽寫錯誤，實際可能指代某特定模型版本或工具名稱，需查證。
• RK4V4-E8：此量化參數格式非常見標準命名，可能為講者口述的特定內部參數或聽寫錯誤，需查證是否為某種特定量化格式（如 Q4_K_M 等）的誤讀。
• Open Code Go：提及使用此工具生成 plan，需查證是否為正確的工具名稱，或為「Open Code」與「Go」語言或其他工具的混雜。
• 四舍九入：講者口誤說「四舍九入」，後修正為「四舍五入」，筆記中已記錄為口誤。
• 菊花都紧紧的：俚語，指緊繃狀態，非技術術語。

可延伸追問

1. NInfer 框架的開源情況如何？是否提供詳細的文檔與使用指南？
2. RK4V4-E8 量化方式的具體實現原理是什麼？如何平衡質量與顯存佔用？
3. 對於其他非千問系列的模型，NInfer 是否支持移植與優化？
4. 在實際生產環境中，NInfer 的長期穩定性表現如何？是否有已知的 Bug 或限制？
5. 如何進一步優化 NInfer 的冷啟動延遲，以改善用戶體驗？