Please enable JavaScript.

Coggle requires JavaScript to display documents.

Local LLM - Coggle Diagram

- - - - 會自行操作 local git, commit
      - :green_cross:GitLab 無法操作
        
        需要搭配 SurceTree 處理
      - 對於 WinForm 專案，對於 sln 、專案檔、參考等等的處理差
      - 口語化描述需求後，最好先丟給 ChatBot 調整成 Aider 比較懂得寫法再餵給 Aider
  - - - Cline
        
        需要安裝 MCP 與 Gitlab 溝通
        
        :green_cross:測試無法抓到 MCP 提供的工具
        
        可能要 Linux 的版本才有支援
      - :green_cross:Continue
        
        這個比較像是 code 補全
      - Roo Code
        
        從 Cline Fork 出來的
        
        目前使用只能用 Ollama 搭配 Qwen3-Coder:30B，使用 SGLang 搭配 Qwen3 會因為丟出的格式不符合 Roo Code 的要求會出錯誤
    - - 對於 Local LLM 需要先安裝 XX 將 Local LLM 公開於網路之後 Cursor 才能使用！先放棄！
  - - - 搭配 Open-Webui 工具設定，利用 Python 撰寫與 GitLab 溝通
      - 因為是 ChatBot，每件事情都要講得很細，感覺像是在叫笨蛋寫程式，邏輯會對，但對於 sln 與專案檔的處理差
- - - - NVFP4 對比 FP4，FP4有點像是固定權重，NVFP4 有點像是動態權重
- - - - 因為是 AWQ ，5090 跑起來慢
    - - Gemine 建議用 Qwen2.5-Coder-32B-AWQ
    - - 可以有約 9GB 可以留給 KV Cache
        
        應該要有更多才對？
      - 搭配 Aider 體驗不錯
    - - 自己量化失敗，可能是版本相容性的問題
      - 是 BF16 ，會在執行時自動量化
    - - https://huggingface.co/nm-testing/DeepSeek-R1-Distill-Qwen-32B-NVFP4
      - 20.7 GB
      - FP4
      - 未來主力
        
        速度待測試
    - - https://huggingface.co/GetSoloTech/GPT-OSS-Code-Reasoning-20B
      - MXFP4
      - 13.8 GB
      - 通常 "Reasoning" 模型的指令遵循能力（Instruction Following）不如 "Instruct" 模型穩定。
    - - 未來主力
      - 它既是 Coder（懂 .NET 8, C#, SQL），也是 Instruct 模型（聽得懂「請先規劃再執行」的指令）。
      - 在 OpenHands 中，它可以同時扮演 PM（規劃）、Architect（架構）和 Engineer（實作），SGLang 的 RadixAttention 會負責在這些角色切換間共用 Context，速度極快。
  - - - :<3:目前使用最覺得在中文理解與回覆上最好的
  - - - AWQ：這是一種壓縮檔。GPU 在計算前，必須先執行一段「解壓縮程式（De-quantization Kernel）」把數據還原成 FP16，然後再計算。
      - AWQ 是一種為了「高併發服務（Serving）」設計的格式。它的強項是當有 100 個人同時連線時，它能維持很高的吞吐量（Throughput）
      - AWQ 量化格式 FP16
      - GPU 每次都要「先解壓縮、再計算」
      - :green_cross:慢到靠北
    - - NVFP4 (Blackwell 架構專屬)：這是 RTX 5090 的「母語」。
      - 5090 的 Tensor Core 硬體線路裡，物理上就設計了直接處理 FP4 的電路。
      - 不需要解壓縮，不需要轉換。數據送進去，答案直接出來。
      - :red_flag:NVFP4 快是因為它是「硬體直通」。它擁有 GGUF 的低延遲（甚至更低），同時擁有比 AWQ 更高的吞吐量。
      - 5090 原生最佳化 (最快)
    - - INT4
      - 針對「單人生產」優化，所以反應極快。
    - - MXFP4 (Microscaling FP4) 是一種「團購式」的壓縮技術，它是為了讓超大模型（如 120B）能塞進有限顯存而設計的開放標準
      - 縮放精度 (Scale)，E8M0 (僅限 2 的次方，較粗糙)
      - 精度損失較高 (因為 32 個人要配合一個標準)
- - - - 試著將 PAM 的 Table Schema 轉成 Markdown 檔案放入，但有快 2000 個檔案，效能不好
        
        後續將合併 Table Schema 成一個檔案測試
    - - 實際運作是在發送 API 請求時，偷偷把 System Prompt 塞進去