# 影片筆記：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 小時即完成最佳配置報告。
2.  **環境部署與參數設定**：
    *   使用移植至 3090 後再針對 4090 優化的 **NInfer** fork 版本。
    *   設定 **千問 3.8 27B** 模型，採用 **RK4V4-E8** 量化方式以壓縮 KV 緩存。
    *   設定上下文長度為 256K。
3.  **實測執行與對比**：
    *   執行冷啟動測試，記錄首 Token 延遲（TTFT）。
    *   執行長鏈開發測試，記錄生成速度（tokens/s）。
    *   監控顯存使用情況，確認是否發生 OOM。
    *   監控日均功耗與峰值功耗。
4.  **結果分析與優化**：
    *   對比 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 的冷啟動延遲，以改善用戶體驗？