前阵子帮社团学弟搭可以离线跑的课程问答小工具，翻了一圈Python生态下的轻量大模型部署方案，发现没有哪个是万能的，各有各的适配场景，索性把实际摸过的几个摊开说，连带着可直接跑的步骤一起放出来。
单脚本跑通的轻量选择
首先说最省事儿的llama-cpp-python，说白了这个库就是把大模型推理的核心逻辑用C++写好封装成Python包，没有一堆杂七杂八的依赖，CPU环境也能顺畅跑，具体响应速度看设备配置，普通笔记本跑量化小模型基本不需要等太久。安装的时候注意根据自己的硬件加编译参数就行：
pip install llama-cpp-python
# N卡开GPU加速的话用这个命令装
CMAKE_ARGS="-DLLAMA_CUBLAS=on" pip install llama-cpp-python写代码的时候也不用搞复杂的配置，指定好本地gguf格式的模型路径就能跑：
from llama_cpp import Llama
llm = Llama(model_path="./qwen2-1.5b-instruct-q4_0.gguf", n_ctx=2048)
output = llm.create_chat_completion(
messages = [{"role": "user", "content": "解释下什么是物联网MQTT协议"}]
)
print(output['choices'][0]['message']['content'])这个方案的优点是装好就能用，单文件脚本就能跑，没有多余的常驻进程；缺点是封装得比较“死”，如果要改推理逻辑、加自定义插件会比较费劲，适合只是快速写个离线小工具、机器配置一般（甚至没有独显）的场景。
别上来就下载大参数模型，q4量化的1.5B、7B级别模型在普通笔记本上跑的响应速度就够日常用，找模型的时候优先选gguf格式的资源就对了。
适合二次开发的生态路线
如果后续要给模型加外接知识库、接自定义工具、甚至做微调适配，那HuggingFace生态的Transformers路线会更合适。这个方案的优点是文档全、社区案例多，几乎所有开源大模型都原生支持这个框架，想改注意力机制、加LoRA适配器都有现成的接口；缺点是依赖包比较多，PyTorch、accelerate这些包装的时候容易出版本冲突，默认配置下资源开销会比llama-cpp-python高一些。
安装的时候把核心依赖装全就行：
pip install transformers accelerate torch auto-gptq基础调用的代码也不复杂，指定好本地量化模型路径，框架会自动分配设备：
from transformers import AutoTokenizer, AutoModelForCausalLM
tokenizer = AutoTokenizer.from_pretrained("./Qwen2-1.5B-Instruct-GPTQ-Int4")
model = AutoModelForCausalLM.from_pretrained(
"./Qwen2-1.5B-Instruct-GPTQ-Int4",
device_map="auto"
)
inputs = tokenizer("用一句话说清Python生成器的作用", return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=128)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))如果是做课程设计、二次开发类的项目，选这个路线前期虽然装包麻烦点，后面改功能的时候会顺很多，不用被封装层限制。
多场景共用的服务化方案
要是你同时在写好几个用到大模型的脚本，或者要给局域网里的其他设备、前端页面提供AI接口，那Ollama配Python SDK的方案更划算。这个方案是把模型加载成一个常驻的本地服务，所有调用请求都走接口访问，不用每次跑脚本都重新加载模型，省不少重复的内存开销，而且它自带OpenAI兼容接口，之前写的调用GPT的代码几乎改个地址就能用。
部署的时候先去官网用一行命令装好Ollama客户端，拉取需要的模型，再装Python SDK：
# 拉取轻量版通义千问模型
ollama pull qwen2:1.5b
# 安装Python依赖
pip install ollama调用代码也很简洁：
import ollama
response = ollama.chat(model='qwen2:1.5b', messages=[
{'role': 'user', 'content': '给我列3个居家物联网改造的低成本方案'},
])
print(response['message']['content'])这个方案的缺点是需要单独维护Ollama的常驻进程，自定义模型内部逻辑的灵活度不如原生Transformers，更适合多应用共用模型的场景。
反正我自己现在写个几十行的临时小脚本就用llama-cpp-python，要改模型逻辑做项目就切Transformers，搭局域网共享服务就开Ollama，从来没觉得哪个方案是能打所有场景的，选的时候先想清楚自己要做啥，比搜所谓的“全网最佳方案”靠谱多了。
评论一下？