在本地執行LLM
需要的顯示卡的VRAM會是KV快取+模型權重+啟用記憶體 數值以Qwen3.6-27B-FP8為例
KV快取=batch_size*seq_len*hidden_size*num_layers*2*dtype_size
batch_size:batch處理的token數
1
262144
hidden_size:KV部分的參數
4*256
num_layers:KV部分的層數
16
dtype_size:單一參數的資訊量
8bit
模型權重:num_parameters*dtype_size
num_parameters:模型參數
270億
啟用記憶體:模型權重的10~30%
需要的VRAM約為44GB,是兩張RTX3090
$ sudo systemctl start ollama
$ ollama run llama3
$ ollama run digitsflow/bonsai-8b
$ ollama launch codex-app
指令token長度
$ /set parameter num_ctx 8192
LLaMA推理程式碼的無外部依賴關係純C/C++實作 但也可用於其他大型語言模型上
https://www.youtube.com/watch?v=P8m5eHAyrFM
AgenticSeek
Auto-translate→Ollama(local LLM)
「本地LLM的成本是否會更低」的邊界,會因為使用的API與GPU執行率而大幅變動
粗估是每月110億tokens(每日5億tokens)以上才會較划算,其餘仍是使用API更優
本地LLM的優勢則在於
特化任務的精度
因此也會需要高品質的訓練資料
延遲
本地LLM的特徵是「穩定」,而非「平均快速」,這是平台API無法保證的點
使用頻率越高,這部分在使用者體驗上會更明顯
例如分離成多個精細、會頻繁執行的小型處理步驟
治理
在醫療、金融、行政等規範嚴格的領域,資料是否能送到外部API常會是首個門檻
因此比起便宜與否,能否在本地就完成更會變成需求