部署即在本地電腦中下載并運行模型就像使用網絡上的大模型API一樣但區(qū)別在于模型是運行在本地的不收費也不會泄露信息。但模型可能很大本地電腦可能會內存不足這時候就需要量化來嘗試縮小模型存儲空間同時盡量避免模型性能損失。OllamaOllama是一個大模型部署工具用它只需要執(zhí)行幾個命令就可以在本地電腦下載和部署大模型。官網列出了非常多可以部署的模型有官方模型也有用戶訓練/調整過的模型。使用Ollama部署首先安裝Ollama本身然后執(zhí)行命令行。這里我們以Qwen3:0.6B為例進行安裝因為這是一個非常小的模型大部分電腦都可以輕松部署。# 下載模型到本地ollama pull qwen3:0.6b# 列出本地下載的模型ollama list# 輸出結果# NAME ID SIZE MODIFIED# qwen3:0.6b 7df6b6e09427 522 MB 50 seconds ago# 列出本地下載的模型ollama show qwen3:0.6b# 輸出結果# Model# architecture qwen3# parameters 751.63M# context length 40960# embedding length 1024# quantization Q4_K_M# ...部分內容省略可以看到我們下載了Qwen3:0.6B的模型這個模型是Ollama自己提供的。模型是Q4_K_M量化即主要使用4bit表示一個參數(shù)但重要的位置會采用更高的精度。模型文件大小是522MB上下文為40960也就是40K。然后我們運行這個模型# 運行模型ollama run qwen3:0.6b運行模型后命令行就進入多輪對話模式我們可以直接與這個模型進行交流。最后輸入/bye退出。HTTP接口形式使用前面的run命令或者直接使用serve命令可以開啟本地的HTTP服務通過接口可以調用模型。# 開啟本地模型HTTP服務ollama serve# 測試HTTP服務發(fā)送請求Invoke-RestMethod-Urihttp://localhost:11434/api/chat-MethodPost-Body{model:qwen3:0.6b,messages:[{role:user,content:你好}],stream:false}-ContentTypeapplication/json# 輸出結果# model : qwen3:0.6b# created_at : 2026-08-18T16:30:26.4658699Z# message : {roleassistant; content好的我理解您的需求。如果您有其他問題或需要幫助請隨時告訴我我會盡力解答。如果需要幫助請告訴我您想詢問的內容。; thinkingOkay, the user is asking in Chinese, but the original message is in English. ...省略 }# done : True# done_reason : stop# total_duration : 29896113900# load_duration : 296963600# prompt_eval_count : 17# prompt_eval_duration : 37064000# eval_count : 834# eval_duration : 29539272000Ollama默認在11434端口提供服務。通過結果可以看到模型成功的通過HTTP接口給出了回復。但/api/chat接口的協(xié)議是Ollama自己的Ollama也有提供其它更通用的協(xié)議例如OpenAI的這樣可以方便接入其它Agent。這里我們嘗試將其接入OpenCode模型API接入配置填寫如下base_urlhttp://localhost:11434/v1/,api_keyollamamodelqwen3:0.6b然后就可以在Agent中使用這個模型了。但是由于模型太小只有0.6B基本無法理解Agent注入的提示詞因此基本無法完成功能。而且如果本地電腦配置不高例如沒有顯卡的Windows電腦那么回復會非常慢。例如下圖左側是Qwen3:0.6b的回復右側是DeepSeek V4 Flash的回復左側都直接把工具提示詞回答了出來右側則準確的完成了任務列出了項目中的文件。?使用Python運行人工智能開發(fā)的主要語言是Python提供了PyTorch等豐富的人工智能工具和庫因此如果了解大模型那么還是要使用Python嘗試運行。下載模型和工具包這里我們使用國內的魔搭下載模型地址https://www.modelscope.cn/models/Qwen/Qwen3-0.6B 。這里下載的并不是模型經過量化后的版本而是原始發(fā)布的模型本身可以看到是Safetensors格式的編碼精度為BF16。# 安裝魔搭pipinstallmodelscope# 下載模型到指定目錄modelscope download--modelQwen/Qwen3-0.6B--local_dir./Qwen3-0.6B下載之后在模型中可以看到多個文件其中model.safetensors表示模型權重文件所有的參數(shù)都在這個文件中。由于是BF16格式一個參數(shù)用兩個字節(jié)表示因此文件大小約為1.4GB。模型中還有一些配置文件詞表文件和分詞規(guī)則等等這里先不介紹了。# torch為PyTorch是最流行的深度學習框架庫pipinstalltorch# transformers是Hugging Face的大模型工具庫pipinstalltransformers# transformers的可選依賴用于自動適配不同硬件pipinstallaccelerate加載模型fromtransformersimportAutoModelForCausalLM,AutoTokenizer# 模型目錄MODEL_DIR./Qwen3-0.6B# 加載分詞器tokenizerAutoTokenizer.from_pretrained(MODEL_DIR)# 加載模型Auto 根據 config.json 自動識別架構Qwen3ForCausalLMmodelAutoModelForCausalLM.from_pretrained(MODEL_DIR,torch_dtypeauto,# 按模型配置自動選擇精度此處為 bfloat16device_mapauto,# 自動分配到可用設備GPU無則 CPU)print(tokenizer)print(model)可以看到通過簡單的兩行代碼即可加載模型。其中transformers內置了很多開源大模型的適配工具它會識別模型配置文件自動選擇合適的模型處理方式。輸出結果如下?其中第一句話為模型加載的進度條如果電腦性能較差可能要花費一段時間才能加載完成。Qwen2Tokenizer是加載的分詞器叫做Qwen2是因為Qwen3和2使用了相同的分詞方案中間列出了一些參數(shù)和特殊用途的token表。Qwen3ForCausalLM是Qwen3的模型結構其中輸出了詞嵌入層28層解碼器等模型的大致結構。Qwen2Tokenizer和Qwen3ForCausalLM都是transformers內置的通過識別模型配置文件自動應用。多輪對話# 對話歷史列表messages[]whileTrue:# 讀取用戶輸入輸入 exit 退出循環(huán)user_inputinput(\n你)# 去除字符串首尾空白ifuser_input.strip()exit:break# 把用戶消息加入歷史對話中messages.append({role:user,content:user_input})# 將歷史對話按 Qwen3 模板轉為純文本# add_generation_prompt 在消息末尾附加模型回復的開始標記texttokenizer.apply_chat_template(messages,tokenizeFalse,add_generation_promptTrue,return_tensorspt)# 將文本編碼為輸入TokenID的列表(PyTorch tensor 格式)model_inputstokenizer(text,return_tensorspt)# 其余采樣參數(shù)取模型默認配置# max_new_tokens512 最多生成 512 個新 tokenoutputsmodel.generate(**model_inputs,max_new_tokens512)# 解碼出新增部分去掉輸入部分跳過特殊 tokenresponsetokenizer.decode(outputs[0][len(model_inputs[input_ids][0]):],skip_special_tokensTrue)# 把模型回復加入歷史用于下一輪對話的上下文messages.append({role:assistant,content:response})print(模型response)加載模型后使用上面的代碼可以實現(xiàn)多輪對話效果如下圖?下面我們來逐步分析代碼。首先是一個無限循環(huán)讀取用戶輸入如果輸入為exit則退出。然后輸入被放到messages中它存放著歷史用戶輸入(role為user)和模型輸出(role為assistant)的對話歷史。例如當進行第三輪對話時內容是這樣的太長的部分已省略[{role:user,content:你好},{role:assistant,content:think\n好的用戶發(fā)來“你好”我需要 ...省略\n/think\n\n你好有什么可以幫助你的嗎 },{role:user,content:你是誰},{role:assistant,content:think\n好的用戶問“你是誰”我需要 ...省略\n/think\n\n我是...省略。有什么可以幫助您的嗎 },{role:user,content:天空為什么是藍色的}]messages的格式實際上也是分詞器要求的格式。首先使用分詞器將messages套入模型對話模板處理成純文本。大模型實現(xiàn)多輪對話時如果需要理解上下文需要將前面的對話也一并讀取因此這里是所有歷史記錄。下面是處理之后text的輸出# 一輪對話text值|im_start|user 你好|im_end||im_start|assistant# 二輪對話text值|im_start|user 你好|im_end||im_start|assistant 你好有什么可以幫助你的嗎|im_end||im_start|user 你是誰|im_end||im_start|assistant注意這里分詞器將模型思考內容think/think省略了因為思考內容太長且保存意義不大。而且發(fā)現(xiàn)我們的內容前后有一些特殊符號這些是模型的對話模板格式有消息開始/結束標記角色標記等。不同的模型對話模板是不一致的。然后就是真正的分詞將文本分割為一個一個的token然后轉化為TokenID。輸出outputs內容如下{input_ids:tensor([[151644,872,198,108386,151645,198,151644,77091,198]]),attention_mask:tensor([[1,1,1,1,1,1,1,1,1]])}input_ids中是一個PyTorch tensor 格式的TokenID列表對照模型文件中的詞表可以將其轉換為前面的文本。之所以是二維結構和有attention_mask是因為它可以適配批量輸入不同對話同時進入模型這里我們使用不到因此忽略。下一步就是調用模型生成回復了輸入中**model_inputs是Python解包將上述的結構解開后作為函數(shù)的入參。輸出outputs結果如下tensor([[151644,872,198,108386,151645,198,151644,77091,198,151667,198,99692,3837,20002,28291,36407,99593,100908,...省略]])可以看到輸出也是TokenID列表而且注意觀察輸出中是包含了輸入的TokenID列表的。因此下面將tokenID解析為文本前需要將輸出中的輸入部分去掉再解析這里說明一下去掉的過程。outputs# tensor([[xxx, xxx, ...]]) 輸出TokenID二維列表outputs[0]# [xxx, xxx, ...] 輸出列表的第一行也是實際有數(shù)據的那行model_inputs# {input_ids: tensor([[xxx, xxx, ...]]) ... } # 輸入結構model_inputs[input_ids]# tensor([[xxx, xxx, ...]]) 輸入TokenID二維列表model_inputs[input_ids][0]# [xxx, xxx, ...] 輸入列表的第一行也是實際有數(shù)據的那行l(wèi)en(model_inputs[input_ids][0])# 9 輸入列表的第一行的長度len(model_inputs[input_ids][0]):# 9: Python語法可以將數(shù)組內部分內容截取outputs[0][len(model_inputs[input_ids][0]):]# 將outputs[0]的第9到最后一個元素截取出來通過上面的語法去掉輸入部分只將這次模型輸出的TokenID截取出來然后再給分詞器進行解碼同時去掉模板標記的特殊字符最后生成的response就是模型輸出的文本也就是我們前面看到的結果了。格式和量化簡介雖然都是同一個大模型Qwen3:0.6B但前面使用Ollama部署的模型格式和使用transformers加載的模型格式和文件大小是不相同的這與模型存儲格式與量化精度有關。存儲格式存儲格式主要與運行模型的訓練框架有關不同框架使用不同的存儲格式。存儲格式對應框架使用場景Safetensorstransformers最常用的格式GGUFllama.cppOllama等工具使用ONNXONNX Runtime跨平臺部署使用.pt .pth .binPyTorch訓練中使用.ckpt .pbTensorFlow訓練中使用pt和pb都是訓練中使用的格式并不直接作為大模型存儲分發(fā)的數(shù)據格式。Safetensors是純粹的數(shù)據格式即里面放的都是權重數(shù)據本身不包含可執(zhí)行代碼。還需要單獨的模型配置文件分詞器對話模板等。GGUF里面還可以包含分詞器對話模板模型配置文件等數(shù)據。ONNX不僅包含權重還包含了模型結構定義計算圖但不包含分詞器對話模板等。由于包含了模型結構因此直接使用ONNX運行時即可運行模型。其他的格式都需要框架本身內置模型結構例如前面的Qwen3ForCausalLM就是transformers中內置的模型結構。通用量化精度在之前的【AI】一文讀懂大模型生態(tài)分類/參數(shù)/結構/訓練/GPU/評測/排行/社區(qū)文章中我們了解到大模型參數(shù)量巨大運行時一般放到GPU內存即顯存中顯存一般和GPU都是整體的非常貴不像內存可以獨立添加更換。因此為了節(jié)約顯存或提高運算速度將參數(shù)的存儲位數(shù)壓縮同時希望壓縮后的數(shù)字與壓縮前的區(qū)別盡量小這就是量化的含義?；A的量化精度格式是通用的基本在所有的存儲格式和機器上都能運行。但有一些量化精度格式是部分存儲格式專用的里面有特定的算法處理。還有一些精度格式需要特殊的指令集才能處理因此只有部分較新的硬件才能運行。首先來看看通用的量化精度精度格式位數(shù)適配存儲格式適配機器FP32標準32位浮點數(shù)通用通用FP16標準16位浮點數(shù)通用通用前面FP32和FP16是兩個基礎格式實際上就是原樣存儲對應位數(shù)的浮點數(shù)。對應到C語言FP64就是doubleFP32是floatFP16則是_Float16C23標準引入。但這幾個格式占用內存空間很大如果希望每個數(shù)字占用空間更小且還能保證數(shù)值和原來近似就需要公共縮放因子了。精度格式位數(shù)適配存儲格式適配機器INT88位整數(shù)公共縮放因子通用GGUF除外通用INT44位整數(shù)公共縮放因子通用GGUF除外通用Q88位整數(shù)公共縮放因子僅GGUF通用Q44位整數(shù)公共縮放因子僅GGUF通用公共縮放因子是很多個數(shù)字共享的。使用INT8和INT4時需要將整數(shù)部分*縮放因子即可還原出原來的數(shù)字。但可想而知使用這種方式存儲的數(shù)字會有誤差損失。Q8和Q4是GGUF專用的格式與INT8和INT4結構類似只不過公共縮放因子共享的數(shù)據個數(shù)不同。雖然這是整數(shù)存儲但縮放因子并不是整數(shù)因此實際上真正的數(shù)值還是浮點數(shù)。K-Quant方法GGUF格式有一個專用的量化方式叫做K-Quant方法。它將256個數(shù)字分為一個超級塊使用兩級縮放因子達到盡量節(jié)約空間和減小誤差的效果。這里我們以Q4_K為例介紹一下?一個超級塊包含一個超級塊縮放因子和最小值這兩個對超級塊中所有的參數(shù)都生效超級塊中包含8個子塊每個子塊包含32個參數(shù)值每個子塊還包含一個子塊縮放因子和子塊最小值對子塊中的所有參數(shù)生效還原單個參數(shù)值的公式q為存儲的參數(shù)值 value (d × scales) × q - (dmin × mins)為什么要這么設計如果256個數(shù)字用同樣的縮放因子那么數(shù)值可以表示的誤差太大。如果每32個數(shù)字都用16bit的縮放因子和最小值那么不如K-Quant方法更節(jié)約空間。各種方式的空間舉例如下256個FP16 256*16 4096 bits每32個數(shù)字都用16bit的縮放因子和最小值 2564 816*2 1280 bitsK-Quant方法 2564 862 162 1152 bits以K-Quant方法量化的格式命名叫做QX_K其中X表示單個參數(shù)存儲的位數(shù)例如Q2_K, Q4_K等等。QX_K后面還能加后綴可以將模型按照重要程度使用不同的位數(shù)存儲例如使用Q6或者Q8存儲即混合精度_S 例如Q4_K_S 只對極少數(shù)最關鍵參數(shù)使用更高精度_M 例如Q4_K_M 更多參數(shù)使用更高精度_L 例如Q4_K_L 絕大多數(shù)層都使用更高精度新硬件精度前面講的K-Quant方法是使用CPU/GPU進行解析并沒有在硬件層面上做特殊支持。但有一些量化精度格式可以直接提供給專門的硬件指令集處理這樣節(jié)約存儲空間的同時計算效率也更高。但這種方式需要較新的硬件支持才行。首先我們介紹BF16它與FP16的存儲位數(shù)一致而是在內部結構上有區(qū)別。FP16的指數(shù)位更大與FP32相同相應的縮小了尾數(shù)位這樣數(shù)值表示的精細程度差但是表示的數(shù)字范圍更多與FP32相同。這樣對于大模型訓練時防止溢出更方便。兩者的區(qū)別如下?圖片來源于網絡通過圖中可以看到BF16就是FP32截斷了16位尾數(shù)部分。BF16和下面的其它精度格式在較新的硬件中可以直接使用硬件電路計算比程序處理要快得多。圖中還提到了FP8這也是一種需要硬件支持的格式它使用8位即可表示完整一個浮點數(shù)。FP8有E5M2和E4M3兩種除了固定的符號位不變外分別為5位指數(shù)2位小數(shù)和4位指數(shù)3位小數(shù)。FP8雖然精度不高但勝在節(jié)約空間。還有兩種硬件相關的精度格式MXFP8和MXFP4。MXFP8還是使用FP8作為每個參數(shù)存儲同時32個參數(shù)為一組共享一個8位的縮放因子。MXFP4只有4位1位符號2位指數(shù)1位尾數(shù)。還有32個元素共享同一個8位的指數(shù)。這兩個格式可以將一組數(shù)據直接提供給支持的硬件計算因此計算速度更快。精度轉換和torchao量化mmap使用transformers加載的模型在加載前后可以修改模型精度我們通過觀察電腦對應進程消耗的空間即可直觀感受到模型占用內存的大小。由于我目前的電腦是Windows且無顯卡因此模型是在電腦內存中運行通過資源管理器直接查看對應Python進程消耗的空間即可例如下圖。?首先我們將前面的代碼重新運行發(fā)現(xiàn)內存使用量為371MB。要知道模型參數(shù)量為0.6B我們以模型發(fā)布時的原始精度BF16直接運行的為何內存占用只有這么少呢因為讀取大模型文件時使用的是mmap這是一種由操作系統(tǒng)提供的虛擬內存地址技術。當大模型加載時并不直接將模型數(shù)據加載到內存中而是對硬盤中的模型數(shù)據進行映射提供給程序虛擬的內存地址。當大模型和用戶對話時如果讀到了存儲在硬盤中的部分操作系統(tǒng)會將這部分數(shù)據直接加載到內存中后面再次讀取同樣的數(shù)據就不需要從硬盤中讀取了。因此我們嘗試和大模型對話時可以在資源管理器看到內存明顯上漲硬盤也有較多讀取量CPU計算量也有突變。因此這371MB完全不能表示模型真正在內存中占用的大小。mmap技術是由操作系統(tǒng)提供Python封裝調用APItransformers中的safetensors包實際使用的。from_pretrained方法沒有直接提供關閉mmap的方式因此我們讀取大模型之后將大模型數(shù)據全部加載一遍放到內存中以此來感受大模型占用的空間大小。forpinmodel.parameters():p.datap.data.clone()在加載模型model后執(zhí)行上述代碼可以將參數(shù)全部放到內存中。對于Qwen3:0.6B默認的BF16格式此時使用的內存為1.5GB。因為除了模型之外還有Python本身模型框架等需要占用內存。轉換運行精度transformers支持在模型加載前和加載后轉換模型精度示例如下importtorch# 模型加載前轉換精度modelAutoModelForCausalLM.from_pretrained(MODEL_DIR,torch_dtypetorch.bfloat16,device_mapauto,# 自動分配到可用設備GPU無則 CPU)# 模型加載后轉換精度model.to(torch.float16)這種精度轉換不叫作量化而且也只有幾種選項可以選擇。如果轉換的精度與原精度不一致那么實際效果也是全部讀取一遍參數(shù)到內存中就不需要前面的clone內存了。實測再clone一遍內存占用量會更大一點。不同選項值和對應的資源管理器內存如下auto等這里省略。從表格可以看到內存使用量與存儲位數(shù)呈現(xiàn)明顯的正相關關系。選項值精度格式實際存儲位數(shù)資源管理器內存使用torch.bfloat16BF16161.5GBtorch.float16FP16161.5GBtorch.float32FP32322.6GBtorchao量化在模型加載前和加載后可以使用torchao對加載后的模型進行量化這里以INT8為例試一下。首先是在模型加載前就指定量化精度fromtransformersimportAutoModelForCausalLM,AutoTokenizer,TorchAoConfigfromtorchao.quantizationimportInt8WeightOnlyConfig,quantize_,PerGroup# 模型目錄MODEL_DIR./Qwen3-0.6B# 加載分詞器tokenizerAutoTokenizer.from_pretrained(MODEL_DIR)# 創(chuàng)建量化配置 granularity參數(shù)表示128個參數(shù)共享一個縮放因子quant_configInt8WeightOnlyConfig(granularityPerGroup(128))# 包裝成transformers可識別的格式quantization_configTorchAoConfig(quant_typequant_config)# 加載模型modelAutoModelForCausalLM.from_pretrained(MODEL_DIR,torch_dtypeauto,device_mapauto,quantization_configquantization_config,# 指定量化配置)前面介紹過INT8是整數(shù)但使用時要通過共享的縮放因子轉成浮點數(shù)運算。共享縮放因子的數(shù)量必須為模型向量維度可以整除的數(shù)字例如本模型必須被1024整除。雖然是INT8但只有線性層即模型結構中28層的參數(shù)被量化詞嵌入是沒有被量化的。使用這種方式運行的Qwen3:0.6B資源管理器內存消耗量為0.9GB。雖然內存小了但我實測推理速度更慢了因為運算時多了一個步驟INT8要先轉為FP16再進行計算我也沒有用GPU加速。使用這種方式量化的模型還可以直接保存成文件分詞器和模型單獨保存。保存后會在目錄中生成model.safetensors以及其它幾個配置文件。我們使用一開始的讀取模型代碼切換下目錄即可成功運行模型。# 模型保存目錄SAVE_MODEL_DIR./Qwen3-0.6B-int8# 保存量化模型model.save_pretrained(SAVE_MODEL_DIR)# 保存分詞器tokenizer.save_pretrained(SAVE_MODEL_DIR)如果加載模型時沒有量化還可以使用quantize_方法加載后再量化模型但這種方式量化后的模型無法保存為文件。fromtransformersimportAutoModelForCausalLM,AutoTokenizerfromtorchao.quantizationimportInt8WeightOnlyConfig,quantize_,PerGroupimportgc MODEL_DIR./Qwen3-0.6BtokenizerAutoTokenizer.from_pretrained(MODEL_DIR)modelAutoModelForCausalLM.from_pretrained(MODEL_DIR,torch_dtypeauto,device_mapauto,)# 創(chuàng)建量化配置quant_configInt8WeightOnlyConfig(granularityPerGroup(128))# 量化模型quantize_(model,quant_config)# 嘗試清理內存gc.collect()這種先加載再量化的方式我感覺意義不大因為模型已經以較高精度加載進來了再進行量化既耗時又多耗費內存。實測量化完之后可能因為無用數(shù)據還沒有被完全銷毀內存占用量是2.2GB等我開始對話后才逐漸降到1GB多比加載前量化的方式多耗費了很多內存。由于我這里使用Intel的CPU運行因此僅支持INT8的格式INT4會報錯。使用GPTQ/AWQ等量化方式一般在GPU上進行CPU效率較低且一些支持的工具已停止維護了因此這里不討論了。GGUF量化生成GGUF文件與GGUF格式和K-Quant方法綁定的大模型框架叫做llama.cpp這是一個C編寫的高性能大模型推理框架前面介紹的Ollama就是基于它開發(fā)的。注意一般只用作推理訓練還是使用transformers。它有直接通過命令行終端使用的工具也適配了各種編程語言使用。使用前面下載的模型文件量化為GGUF需要兩步第一步是將safetensors格式轉換為GGUF第二步才是量化。這里首先描述第一步。格式轉換工具在llama.cpp的GitHub上我們首先需要clone項目然后安裝依賴再執(zhí)行轉換。# clone llama.cpp項目gitclone https://github.com/ggml-org/llama.cpp# 創(chuàng)建Python局部虛擬環(huán)境到python-llama-venv文件夾避免安裝包污染全局python-mvenv python-llama-venv# 激活局部虛擬環(huán)境python-llama-venv\Scripts\activate# 安裝依賴pipinstall-rrequirements\requirements-convert_hf_to_gguf.txt下載后需要按照requirements文件安裝依賴。它的依賴版本條件寫的比較嚴格如果直接安裝會將全局Python安裝包給覆蓋掉因此先使用venv創(chuàng)建了一個虛擬環(huán)境這樣安裝的依賴包只影響局部。雖然版本條件嚴格但可能是為了非常多模型的兼容性。我這里實測不完全遵守版本也能成功轉換。安裝完成后執(zhí)行l(wèi)lama代碼中的python腳本即可完成轉換# outfile 表示輸出文件python convert_hf_to_gguf.py E:\llm\Qwen3-0.6B--outfileE:\llm\Qwen3-0.6B-model.gguf需要在創(chuàng)建的venv虛擬環(huán)境中執(zhí)行。注意這里輸出的僅有單個gguf文件這個文件中包含所有參數(shù)詞表對話模板配置文件等一個模型文件即可實現(xiàn)模型的分發(fā)。默認輸出的精度為BF16因此模型文件大小為1.5GB。?如何使用這個模型呢GGUF格式可以被前面介紹過的Ollama識別因此這里我們用Ollama嘗試部署模型。首先創(chuàng)建一個文件名稱為Modelfile沒有擴展名內容是GGUF的模型文件完整路徑FROM E:\llm\Qwen3-0.6B-model.gguf然后執(zhí)行命令行即可在Ollama部署該模型。注意Ollama會將這個模型復制到它的存儲目錄后續(xù)就不會使用我們這個路徑下的模型文件了。# 導入模型ollama create Qwen3-0.6B-GGUF# 運行模型ollama run Qwen3-0.6B-GGUF?llama運行GGUF這里我們類似前面的transformers使用llama.cpp提供的Python工具llama-cpp-python來運行模型。如果使用純CPU可以使用這個指令安裝pipinstallllama-cpp-python --extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cpu安裝之后執(zhí)行下面的代碼即可運行模型實現(xiàn)多輪對話。代碼與transformers的方式類似但是省略了加載分詞器的部分。fromllama_cppimportLlama MODEL_PATH./Qwen3-0.6B-model.gguf# 模型文件路徑# 加載模型llmLlama(model_pathMODEL_PATH,n_ctx4096,# 上下文大小n_threads8,# 指定 CPU 線程數(shù)verboseFalse,# 不打印詳細日志)# 保存對話歷史messages[]whileTrue:user_inputinput(你: ).strip()ifuser_input.strip()exit:break# 將用戶輸入加入歷史messages.append({role:user,content:user_input})# 調用模型拿到回答outputsllm.create_chat_completion(messagesmessages,max_tokens512,)responseoutputs[choices][0][message][content].strip()# 將助手回復加入歷史messages.append({role:assistant,content:response})print(f模型:{response}\n)雖然同樣都是BF16的模型但使用llama-cpp-python加載模型實測比transformers快多了。這是因為llama.cpp專為部署模型設計且針對CPU部署做了優(yōu)化。而transformers多半用于訓練場景。模型返回的output是一個嵌套的字典結構包含信息如下{id:chatcmpl-a4f95093-43f1-4033-baef-3ca6081ca213,// 標識符object:chat.completion,// 對象類型created:1788191746,// 創(chuàng)建時的時間戳model:./Qwen3-0.6B-model.gguf,// 使用的模型名稱choices:[// 模型生成的回復列表一般只有一個{index:0,// 在列表中的索引message:{role:assistant,// 角色模型固定為 assistantcontent:// 回復文本think\n 省略... \n/think\n\n你好有什么可以幫助你的嗎需要幫忙嗎,},logprobs:None,finish_reason:stop,// 生成結束的原因},],usage:{// 統(tǒng)計本次請求消耗的 Token 數(shù)量prompt_tokens:9,// 輸入提示詞消耗的 Token 數(shù)completion_tokens:112,// 輸出回復消耗的 Token 數(shù)total_tokens:121// 兩者總和},}同樣的運行模型也默認開啟了mmap這樣內存中是看不出來模型真正的運行占用內存大小的。好在llama-cpp-python可以直接配置關閉mmap。關閉后運行模型查看內存使用量為1.9GB。llmLlama(model_pathMODEL_PATH,n_ctx4096,n_threads8,verboseFalse,use_mmapFalse# 關閉mmap)量化Q8Q4Q2使用llama-cpp-python包無法量化模型這里我們直接下載預編譯好的可執(zhí)行文件來量化地址在 https://github.com/ggml-org/llama.cpp/releases 。根據我的電腦類型選擇了Windows x64 (CPU)。下載后解壓到目錄中執(zhí)行命令行然后等待一段時間就輸出新的模型文件了。# llama-quantize量化工具 輸入模型 輸出模型 量化精度.\llama-quantize.exe E:\llm\Qwen3-0.6B-model.gguf E:\llm\Qwen3-0.6B-q8-model.gguf Q8_0這里可以使用GGUF的多種量化類型我們嘗試了多種不同精度的模型并查看加載后的內存使用量量化精度位數(shù)模型文件大小實際運行內存BF16(轉換后未量化)16位1.4GB1.9GBQ8_08位767MB1.29GBQ4_K_M4位為主461MB980MBQ2_K2位331MB850MB我提問了幾個簡單問題實測Q4_K_M還是可以正常輸出的但Q2_K的輸出就只剩亂碼根本不可用了。參考Ollamahttps://ollama.com/Ollama qwen3:0.6bhttps://ollama.com/library/qwen3:0.6bOllama文檔 api/chathttps://docs.ollama.com/api/chatOllama文檔 OpenAI compatibilityhttps://docs.ollama.com/api/openai-compatibility【AI】一文讀懂大模型生態(tài)分類/參數(shù)/結構/訓練/GPU/評測/排行/社區(qū)https://jzplp.github.io/2026/llm-stru.html魔搭社區(qū)https://www.modelscope.cn/GitHub llama.cpphttps://github.com/ggml-org/llama.cppGitHub llama.cpp releaseshttps://github.com/ggml-org/llama.cpp/releases