1. 先说清楚LFM2.5-1.2B到底是个什么样的模型1.1 1.2B参数意味着什么最近我在整理本地推理工具链顺手把LFM2.5-1.2B这个1.2B参数的轻量模型拖了下来用llama.cpp和ollama分别跑了一遍。结果挺有意思在普通CPU平台上量化后的模型能做到每秒15个token左右的生成速度作为一个小体量模型这个速度已经足够撑起不少实际任务。先说“1.2B参数”这个概念。很多人一听到“B”这个单位就觉得模型很大其实1.2B指的是12亿个参数放在今天的大模型圈子里属于不折不扣的“小个子”。作为对比现在稍微主流一点的模型动辄7B、13B甚至70B。参数规模小最直接的好处就两个内存占用小、推理速度快。具体到运行环境LFM2.5-1.2B的原始FP16权重大概在2.4GB左右这个数字其实已经挺亲民了但如果你做一下量化比如转成GGUF格式的Q4_K_M文件体积能压到700MB到800MB之间。这是什么概念一台只有16GB内存、没有独立显卡的办公主机跑起来绰绰有余哪怕是树莓派或者某些低功耗的迷你主机只要内存够也不是不能玩。所以这类1.2B模型天然适合三类场景一是离线环境下的文本处理数据不出本机二是边缘设备或者老旧笔记本上的轻量级AI服务三是想要快速验证一个想法、不想为了一次测试就去调云端大模型API的场景。1.2 “thing模型”到底指什么标题里提到“它是thing模型”这个说法我在社区讨论里见过几次。从我个人的理解来看thing系列指的是一类强调快速响应、低资源占用的小体量模型风格它们在设计上更偏向“够用就好”不会为了刷榜单去堆参数而是把注意力放在推理速度、指令跟随能力和部署友好性上。实测下来的体感也确实是这样。LFM2.5-1.2B生成出来的句子比较干净用词不绕弯让它做文本分类、关键词抽取、简单的问答对话表现得相当利索。你问它一个常识性问题它能给出基本正确的回答你给它一段文本让它总结要点它也能给出结构化的结果。但你也别对它抱有不切实际的期望。1.2B的参数量决定了它的知识储备和复杂推理能力有限让它写一篇深度分析文章、做复杂的数学推导、处理多轮长对话它很快就露馅。这就像一个干活麻利的实习生日常杂务处理得又快又好但遇到需要资深专家坐镇的难题还是得换更重的模型上。我自己的定位很明确它就是本地推理管线里的“快枪手”负责那些延迟敏感、内容简单直接的任务把重活留给云端或者更大参数的模型。1.3 为什么这个体量还值得专门写一篇也许会有人问既然有大模型可以用为什么还要折腾本地小模型这个问题我每次写这类文章都会被问到。真实原因其实很朴素不是所有场景都有条件用云端大模型。举几个实际例子。我在一个模拟项目里做日志敏感信息的脱敏每天要处理几万条日志如果每条都调云端接口先不说钱的问题单是网络往返的延迟就受不了更别提数据出域完全不可接受。用本地小模型跑15个token每秒的生成速度完全够用输入输出都在本机完成安全边界清清楚楚。还有边缘设备场景。设备没有公网或者网络质量不稳定你不可能指望它去连云端API。这时候一个能塞进内存的1.2B模型往往就是性价比最高的解决方案。所以LFM2.5-1.2B这种体量的模型不是说它比大模型强而是在特定的约束条件下它是“可用”和“可控”之间最好的平衡点。接下来我把两条部署路线的完整过程都写出来你自己看情况选。2. 为什么我最终选了llama.cpp和ollama这两条腿走路2.1 两者定位完全不同在动手之前我觉得有必要先说明一下这两个工具到底有什么区别因为很多人一开始会把它们搞混。llama.cpp是一个纯C编写的推理引擎核心价值是“把模型高效地跑起来”。它对硬件的控制非常细线程数、批量大小、上下文长度、KV cache尺寸、内存锁定等等参数都能手动调。适合那些希望精确控制推理过程、自己定制服务的人。代价是配置门槛高一些很多细节得自己摸索。ollama则是把“模型管理推理服务”打包成了一个非常友好的上层工具。它更像一个模型运行管家你告诉它要跑哪个模型它负责下载、加载、提供OpenAI兼容的API接口一行命令就能起服务。开箱即用的体验对新手极其友好而且它同样支持从GGUF文件导入自定义模型。这两个工具并不冲突。llama.cpp是“发动机”ollama是“整车”。你可以只研究发动机也可以直接开车上路。我个人的做法是两条腿走路需要抠性能细节时用llama.cpp需要快速搭服务或者做测试时用ollama。2.2 选型前的硬件评估在下载任何模型文件之前我建议你先确认一下手里的硬件条件。别急着跑先花两分钟看一眼参数能省下后面一堆折腾。我的测试机是一台普通的中端机器一颗6核12线程的处理器16GB内存没有独立显卡操作系统是常规的x86_64 Linux。说实话这样的配置在现在遍地32GB内存的折腾党眼里算寒酸但它恰恰代表了很大一部分普通用户的情况——大家不会有专门的推理服务器就是拿手头电脑跑一下。有几个关键点需要提前确认CPU是否支持AVX2指令集。llama.cpp在x86平台上有不少针对AVX2的优化如果你的CPU太老不支持推理速度会明显变慢甚至某些预编译包直接跑不起来。内存容量够不够。模型本身是一回事KV cache是另一回事。1.2B模型量化后虽然只要七八百兆但如果你把上下文拉到8192甚至更多KV cache会额外吃掉几百兆到1GB。16GB内存跑这个模型没有压力8GB也能勉强撑住但别同时开一堆大程序。存储别选机械硬盘。模型文件虽然不大但加载时如果硬盘读速太慢启动时间会让人怀疑人生。SSD是基本要求。2.3 实际场景决定用哪个搞清楚了工具定位和硬件条件之后我建议你按照自己的实际场景来选择场景推荐工具理由第一次接触本地推理想最快看到效果ollama两条命令就能跑起来几乎零门槛自己写程序调用本地模型服务ollama 或 llama.cpp的server模式都提供HTTP API接口简单需要精细调参、压榨硬件极限llama.cpp线程、批大小、上下文全部可手动控制离线环境部署、不想有额外依赖llama.cpp编译产物就是一个静态二进制极其干净需要管理多个模型、随时切换ollama模型按名管理切换非常方便这两个工具我都留着平时做实验可能碰ollama多一点但一遇到性能瓶颈或者要在受限环境里部署立刻切回llama.cpp。而且你完全可以把同一个GGUF文件同时给两个工具用模型文件是共享的不冲突。所以不存在“二选一”的问题我的建议是都装。3. llama.cpp路线从编译到实测一把梭3.1 下载源码和编译的通用姿势我优先说llama.cpp因为它的可控性是ollama比不了的。开始之前先明确一点我这里的步骤不是某个具体版本的教程而是适用于绝大多数近期版本的操作流程。第一步是从开源代码仓库拉取llama.cpp源码。这一步需要你本机装了git和基本的编译工具链gcc、cmake等。操作如下git clone llama.cpp仓库地址 cd llama.cpp然后创建构建目录用CMake配置并编译cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j 6这里的-j 6是并行编译任务数填你的CPU核心数就行。编译完成后可执行文件会放在build/bin/目录下里面有几个常用的llama-cli用于命令行对话和文本生成llama-server用于启动一个HTTP推理服务。为什么不直接下载别人编译好的二进制原因很简单本地编译能针对你的CPU做指令集优化。llama.cpp在编译时会根据CPU特性启用不同的优化路径自己编出来的版本往往比通用预编译包更快启动时的报错也少。虽然多花几分钟编译时间但后面用起来省心很多。3.2 GGUF量化格式怎么选模型格式方面llama.cpp使用GGUF格式这个格式最大的特点是把模型权重量化打包成了一个单独文件加载简单、跨平台。但GGUF内部还有不同量化等级选错了会直接影响速度和效果。LFM2.5-1.2B的GGUF文件一般会有好几个版本常见的包括Q4_K_M、Q5_K_M、Q8_0和F16。这几个我分别在测试机上跑过结论很明确量化格式文件大小约推理速度质量损失我的建议F162.4GB较慢无不推荐除非内存非常充裕Q8_01.3GB中等几乎无损对质量敏感时选用Q5_K_M900MB较快很小可以凑合用Q4_K_M750MB最快可接受日常首选我个人最终选了Q4_K_M。这几乎是社区公认的“甜点量化”体积控制得好质量损失在大多数任务里感知不明显而速度比Q8_0能快15%到20%。你可能担心量化会明显降低模型质量。以这个1.2B的小模型来说Q4_K_M和原始F16的差异在大多数基础任务上并不明显只有做那种需要精确复述、细节很多的文本处理时能感觉到一点点差距。但换来的是显著的速度提升这笔账我觉得划算。3.3 实测命令与15 token/s的由来编译完成、模型文件也准备好之后就可以开始实测了。我用的是llama-cli完整命令大概长这样./build/bin/llama-cli \ -m ~/models/lfm2.5-1.2b-q4_k_m.gguf \ -p 用简洁的语言解释一下什么是程序化交易 \ -n 256 \ -t 6 \ -c 4096 \ --temp 0.7参数解释一下-m指定模型文件路径-p指定输入提示词-n生成的最大token数量-t使用的线程数我填了6对应物理核心数-c上下文长度设为4096日常任务足够了--temp温度参数控制随机性命令跑起来之后模型会先处理提示词然后逐token生成输出。我跑了多次平均生成速度基本稳定在每秒15个token上下。这个“15 token/s”是个什么概念一句话大约10到20个token也就是说模型每秒能生成大半句话阅读流畅度谈不上但基本不会让你干等。如果你只是做文本分类、关键词抽取这类短输出任务首token延迟加上几百毫秒的生成时间体感上几乎是即时响应。4. ollama路线一条命令到对外API4.1 把GGUF模型导入ollamallama.cpp跑通之后我在想如果只是想快速起一个测试服务每次都敲那么长一串命令也太烦了。这时候ollama的优势就体现出来了。ollama支持从GGUF文件直接创建模型核心是一个Modelfile。假设你的GGUF文件在~/models/lfm2.5-1.2b-q4_k_m.gguf先在工作目录创建一个文本文件名字就叫Modelfile内容如下FROM ./lfm2.5-1.2b-q4_k_m.gguf然后在同一目录下执行ollama create lfm2.5 -f Modelfileollama会把这个GGUF文件导入到自己的模型仓库里并给它起个名字叫lfm2.5。执行完成后你输入ollama list应该就能看到它了。之后运行就极其简单ollama run lfm2.5直接在交互式命令行里跟模型对话。第一次运行ollama需要加载模型会稍微慢一点之后就快了。这里有一个细节值得注意如果你的GGUF文件自带了模型对话模板信息Modelfile里不用写TEMPLATE就能正常工作但有些文件不具备这个信息回复格式可能会乱。真遇到这种情况再回头在Modelfile里手动加一个模板即可我这里先不展开。4.2 Modelfile里几个值得调的参数ollama的Modelfile不只是用来导入模型的它还能配置模型的运行参数。我个人建议至少把下面几个参数写进去FROM ./lfm2.5-1.2b-q4_k_m.gguf PARAMETER num_ctx 4096 PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER top_k 40 PARAMETER num_predict 512num_ctx上下文窗口长度跟llama.cpp里的-c对应。不要设太大内存占用会涨1.2B模型配4096是合理的甜点值。temperature温度。0.7是通用值做确定性任务可以降到0.3甚至更低生成创意内容可以调到0.9。top_p和top_k采样参数控制候选token的范围。保持默认也可以但写上可以避免一些模型自带默认值偏激进的问题。num_predict单次生成的最大token数相当于llama.cpp的-n。改完Modelfile之后需要重新执行一次ollama create才能生效注意是覆盖式创建不会破坏原文件。4.3 后台服务和API使用模型跑通之后更多人需要的是一个可以被外部程序调用的接口。ollama天然提供这个能力。先启动服务ollama serve默认情况下ollama会监听127.0.0.1:11434提供OpenAI兼容的接口。测试一下curl http://localhost:11434/api/chat -d { model: lfm2.5, messages: [{role: user, content: 用一句话介绍你自己}], stream: true }返回的是一段JSON格式的流式输出。如果你写的是后端服务直接按OpenAI的调用习惯发请求就行接口格式几乎一致迁移成本很低。这一点是我在实际使用中最喜欢ollama的地方——本地模型和云端模型之间切换代码层面几乎不用改。5. 每秒15个token背后速度到底受什么影响5.1 我的测试环境与基准标题里的“每秒15个token”是很吸引人的数字但你得清楚这个数字是在什么条件下测出来的。我把自己的基准说得精确一点方便你对照自己的硬件。测试环境6核12线程CPU16GB内存模型用Q4_K_M量化上下文4096线程数设为6生成长度固定在200个token。测速方式很简单就是让模型连续生成一段长文本统计总耗时取每秒生成的token数。为了避免首token延迟的干扰我取的是生成过程稳定后的平均值。在这个条件下LFM2.5-1.2B的稳定生成速度在我机器上是每秒14到16个token之间浮动取中位数就是15。如果你机器比我好比如有8核、内存带宽更大跑到20以上并不难如果是个四核老平台可能只有8到10。5.2 影响速度的关键因素我调参试了很多组合发现真正能把速度拉下来或者拉上去的因素其实就那么几个。第一个是线程数。这个最容易理解但也最容易踩坑。推理时多线程并行计算是实打实快的但线程数不是越多越好。超过物理核心数之后增加的线程只会带来上下文切换开销速度反而下降。我测试机是6核12线程设6到8之间速度最好设12反而慢。第二个是上下文长度。这里主要指KV cache的大小。上下文越长每一步预测时需要扫描的KV cache就多计算量也跟着涨。很多人跑小模型喜欢把上下文拉到8192甚至更长结果速度莫名其妙掉了30%原因就在这里。第三个是量化精度。Q4_K_M比Q8_0快Q8_0比F16快这个在前面已经验证过了。量化等级越高参与计算的数据量就越大CPU的运算压力自然就上去了。第四个是批大小。llama.cpp有个-b参数控制“一次同时处理多少个token的prompt”。处理长输入时批大小大一点会快但也会占用更多内存。对1.2B这个体量默认值通常已经不错不用刻意调。第五个是内存带宽。这是很多人忽略的一点。CPU推理时模型权重需要从内存不断读入CPU内存带宽不够的话计算核心再强也白搭。这也是为什么同样一颗CPU插双通道内存比单通道快很多。5.3 实测调优对比下面这张表是我在测试机上实测的几组对比你可以直观感受一下参数对速度的影响配置线程数上下文量化实测速度A64096Q4_K_M14-16 tok/sB44096Q4_K_M10-12 tok/sC62048Q4_K_M15-17 tok/sD68192Q4_K_M11-13 tok/sE64096Q8_011-13 tok/sF124096Q4_K_M12-14 tok/s配置A就是我最后的日常配置。配置C速度最快但上下文短了实用性受限配置D虽然上下文长但速度掉得明显小模型长上下文的收益也不高不划算。所以我的最终建议是线程数取物理核心数上下文取4096量化用Q4_K_M。这个组合在大多数普通配置上都能达到“不拖后腿”的速度体验。5.4 和其他体量模型的横向感受为了让你对“15 token/s”有更直观的感知我再说说这档体量和更大模型的对比感受。因为在同样一台机器上我也跑过3B、7B级别的模型差距非常明显。3B量级的小模型量化后在这台机器上的速度大概是每秒6到8个token能用但已经能感觉到明显的“逐字输出”节奏。7B级别就更夸张了即使在Q4量化下也只有每秒3到5个token用来做有来有回的对话勉强可以但稍微长一点的生成任务就会让人不耐烦。所以1.2B跑出15 token/s在CPU推理这个领域算是“轻快”级别的表现了。这让我在处理高频、短文本任务时完全没有延迟焦虑也更愿意把它常驻在后台而不是每次需要时才临时拉起来。6. 跑这一路的坑能避一个是一个6.1 内存不足时的诡异表现我在测试时踩到的第一个坑就是内存估算失误。我一开始只盯着模型文件大小觉得“750MB而已随便跑”结果在加载时直接被告知内存分配失败。后来才知道问题出在KV cache上。我不小心把上下文拉到了16384这个参数会让KV cache占用大幅上涨再加上程序本身的基础开销16GB内存居然也有点紧张。更坑的是内存不足时llama.cpp的报错信息并不直观有时候只是运行变得极慢你根本想不到是内存问题。所以特别提醒小模型不等于可以随意拉上下文。1.2B模型配4096上下文是甜点值追求长文本请掂量自己的内存。6.2 复读机问题跑本地模型时最常遇到的现象之一就是“复读机”模式上下文变长之后模型开始反复重复刚才说过的话有些时候甚至卡在同一句话上出不去。这个问题我在LFM2.5-1.2B上也遇到过。原因通常是采样参数没调好。解决办法比较直接设置重复惩罚参数llama.cpp里是--repeat-penalty 1.1ollama的Modelfile里对应PARAMETER repeat_penalty 1.1。设置之后模型对重复内容的输出概率会被压制复读现象基本消失。如果惩罚设置到1.1之后还复读可以检查一下上下文是不是太长了。小模型在很长的上下文里很容易失去焦点反而更爱兜圈子缩短上下文往往比调参数更有效。6.3 后台服务占资源与并发处理把模型常驻后台提供服务时还有一个问题容易忽略默认情况下ollama每处理一个请求就占一份内存。如果你同时并发多个请求内存和CPU占用会快速上升。我的做法是在启动服务前设置环境变量把并发数限制住export OLLAMA_NUM_PARALLEL1 export OLLAMA_MAX_LOADED_MODELS1 ollama serveOLLAMA_NUM_PARALLEL1表示同时只处理一个请求多余的排队等。对于本地小模型串行处理其实最稳定并发带来的吞吐提升有限反而容易把机器拖垮。如果是llama.cpp的server模式可以用--parallel参数控制并行数逻辑类似。6.4 提示词模板决定成败最后一个坑也是最容易被新手忽略的就是提示词模板。很多人在ollama里导入GGUF之后直接问问题发现模型回复驴唇不对马嘴第一反应是“模型坏了”。其实大概率是模板问题。不同模型对输入格式的要求不一样有的期望User: xxx\nAssistant:有的期望带system角色。如果你的GGUF文件没内置模板就需要手动在Modelfile里补充。我这里给一个比较通用的模板写法作为参考TEMPLATE {{- if .System }}System: {{ .System }} {{ end }}User: {{ .Prompt }} Assistant: 设置之后再ollama create重建一次模型。你会发现效果立竿见影——同样的提问之前答非所问现在一下就正常了。这算是我踩过几次坑之后养成的一个习惯拿到一个新的GGUF文件先确认它有没有内置聊天模板再去调采样参数。顺序反了的话会在错误的方向上浪费很多时间。 
长河君 · 2026/10/20 3:56:59 · 阅读 1.2k 1.2B小模型CPU本地推理实战：llama.cpp与ollama部署与调优
1. 先说清楚LFM2.5-1.2B到底是个什么样的模型1.1 1.2B参数意味着什么最近我在整理本地推理工具链顺手把LFM2.5-1.2B这个1.2B参数的轻量模型拖了下来用llama.cpp和ollama分别跑了一遍。结果挺有意思在普通CPU平台上量化后的模型能做到每秒15个token左右的生成速度作为一个小体量模型这个速度已经足够撑起不少实际任务。先说“1.2B参数”这个概念。很多人一听到“B”这个单位就觉得模型很大其实1.2B指的是12亿个参数放在今天的大模型圈子里属于不折不扣的“小个子”。作为对比现在稍微主流一点的模型动辄7B、13B甚至70B。参数规模小最直接的好处就两个内存占用小、推理速度快。具体到运行环境LFM2.5-1.2B的原始FP16权重大概在2.4GB左右这个数字其实已经挺亲民了但如果你做一下量化比如转成GGUF格式的Q4_K_M文件体积能压到700MB到800MB之间。这是什么概念一台只有16GB内存、没有独立显卡的办公主机跑起来绰绰有余哪怕是树莓派或者某些低功耗的迷你主机只要内存够也不是不能玩。所以这类1.2B模型天然适合三类场景一是离线环境下的文本处理数据不出本机二是边缘设备或者老旧笔记本上的轻量级AI服务三是想要快速验证一个想法、不想为了一次测试就去调云端大模型API的场景。1.2 “thing模型”到底指什么标题里提到“它是thing模型”这个说法我在社区讨论里见过几次。从我个人的理解来看thing系列指的是一类强调快速响应、低资源占用的小体量模型风格它们在设计上更偏向“够用就好”不会为了刷榜单去堆参数而是把注意力放在推理速度、指令跟随能力和部署友好性上。实测下来的体感也确实是这样。LFM2.5-1.2B生成出来的句子比较干净用词不绕弯让它做文本分类、关键词抽取、简单的问答对话表现得相当利索。你问它一个常识性问题它能给出基本正确的回答你给它一段文本让它总结要点它也能给出结构化的结果。但你也别对它抱有不切实际的期望。1.2B的参数量决定了它的知识储备和复杂推理能力有限让它写一篇深度分析文章、做复杂的数学推导、处理多轮长对话它很快就露馅。这就像一个干活麻利的实习生日常杂务处理得又快又好但遇到需要资深专家坐镇的难题还是得换更重的模型上。我自己的定位很明确它就是本地推理管线里的“快枪手”负责那些延迟敏感、内容简单直接的任务把重活留给云端或者更大参数的模型。1.3 为什么这个体量还值得专门写一篇也许会有人问既然有大模型可以用为什么还要折腾本地小模型这个问题我每次写这类文章都会被问到。真实原因其实很朴素不是所有场景都有条件用云端大模型。举几个实际例子。我在一个模拟项目里做日志敏感信息的脱敏每天要处理几万条日志如果每条都调云端接口先不说钱的问题单是网络往返的延迟就受不了更别提数据出域完全不可接受。用本地小模型跑15个token每秒的生成速度完全够用输入输出都在本机完成安全边界清清楚楚。还有边缘设备场景。设备没有公网或者网络质量不稳定你不可能指望它去连云端API。这时候一个能塞进内存的1.2B模型往往就是性价比最高的解决方案。所以LFM2.5-1.2B这种体量的模型不是说它比大模型强而是在特定的约束条件下它是“可用”和“可控”之间最好的平衡点。接下来我把两条部署路线的完整过程都写出来你自己看情况选。2. 为什么我最终选了llama.cpp和ollama这两条腿走路2.1 两者定位完全不同在动手之前我觉得有必要先说明一下这两个工具到底有什么区别因为很多人一开始会把它们搞混。llama.cpp是一个纯C编写的推理引擎核心价值是“把模型高效地跑起来”。它对硬件的控制非常细线程数、批量大小、上下文长度、KV cache尺寸、内存锁定等等参数都能手动调。适合那些希望精确控制推理过程、自己定制服务的人。代价是配置门槛高一些很多细节得自己摸索。ollama则是把“模型管理推理服务”打包成了一个非常友好的上层工具。它更像一个模型运行管家你告诉它要跑哪个模型它负责下载、加载、提供OpenAI兼容的API接口一行命令就能起服务。开箱即用的体验对新手极其友好而且它同样支持从GGUF文件导入自定义模型。这两个工具并不冲突。llama.cpp是“发动机”ollama是“整车”。你可以只研究发动机也可以直接开车上路。我个人的做法是两条腿走路需要抠性能细节时用llama.cpp需要快速搭服务或者做测试时用ollama。2.2 选型前的硬件评估在下载任何模型文件之前我建议你先确认一下手里的硬件条件。别急着跑先花两分钟看一眼参数能省下后面一堆折腾。我的测试机是一台普通的中端机器一颗6核12线程的处理器16GB内存没有独立显卡操作系统是常规的x86_64 Linux。说实话这样的配置在现在遍地32GB内存的折腾党眼里算寒酸但它恰恰代表了很大一部分普通用户的情况——大家不会有专门的推理服务器就是拿手头电脑跑一下。有几个关键点需要提前确认CPU是否支持AVX2指令集。llama.cpp在x86平台上有不少针对AVX2的优化如果你的CPU太老不支持推理速度会明显变慢甚至某些预编译包直接跑不起来。内存容量够不够。模型本身是一回事KV cache是另一回事。1.2B模型量化后虽然只要七八百兆但如果你把上下文拉到8192甚至更多KV cache会额外吃掉几百兆到1GB。16GB内存跑这个模型没有压力8GB也能勉强撑住但别同时开一堆大程序。存储别选机械硬盘。模型文件虽然不大但加载时如果硬盘读速太慢启动时间会让人怀疑人生。SSD是基本要求。2.3 实际场景决定用哪个搞清楚了工具定位和硬件条件之后我建议你按照自己的实际场景来选择场景推荐工具理由第一次接触本地推理想最快看到效果ollama两条命令就能跑起来几乎零门槛自己写程序调用本地模型服务ollama 或 llama.cpp的server模式都提供HTTP API接口简单需要精细调参、压榨硬件极限llama.cpp线程、批大小、上下文全部可手动控制离线环境部署、不想有额外依赖llama.cpp编译产物就是一个静态二进制极其干净需要管理多个模型、随时切换ollama模型按名管理切换非常方便这两个工具我都留着平时做实验可能碰ollama多一点但一遇到性能瓶颈或者要在受限环境里部署立刻切回llama.cpp。而且你完全可以把同一个GGUF文件同时给两个工具用模型文件是共享的不冲突。所以不存在“二选一”的问题我的建议是都装。3. llama.cpp路线从编译到实测一把梭3.1 下载源码和编译的通用姿势我优先说llama.cpp因为它的可控性是ollama比不了的。开始之前先明确一点我这里的步骤不是某个具体版本的教程而是适用于绝大多数近期版本的操作流程。第一步是从开源代码仓库拉取llama.cpp源码。这一步需要你本机装了git和基本的编译工具链gcc、cmake等。操作如下git clone llama.cpp仓库地址 cd llama.cpp然后创建构建目录用CMake配置并编译cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j 6这里的-j 6是并行编译任务数填你的CPU核心数就行。编译完成后可执行文件会放在build/bin/目录下里面有几个常用的llama-cli用于命令行对话和文本生成llama-server用于启动一个HTTP推理服务。为什么不直接下载别人编译好的二进制原因很简单本地编译能针对你的CPU做指令集优化。llama.cpp在编译时会根据CPU特性启用不同的优化路径自己编出来的版本往往比通用预编译包更快启动时的报错也少。虽然多花几分钟编译时间但后面用起来省心很多。3.2 GGUF量化格式怎么选模型格式方面llama.cpp使用GGUF格式这个格式最大的特点是把模型权重量化打包成了一个单独文件加载简单、跨平台。但GGUF内部还有不同量化等级选错了会直接影响速度和效果。LFM2.5-1.2B的GGUF文件一般会有好几个版本常见的包括Q4_K_M、Q5_K_M、Q8_0和F16。这几个我分别在测试机上跑过结论很明确量化格式文件大小约推理速度质量损失我的建议F162.4GB较慢无不推荐除非内存非常充裕Q8_01.3GB中等几乎无损对质量敏感时选用Q5_K_M900MB较快很小可以凑合用Q4_K_M750MB最快可接受日常首选我个人最终选了Q4_K_M。这几乎是社区公认的“甜点量化”体积控制得好质量损失在大多数任务里感知不明显而速度比Q8_0能快15%到20%。你可能担心量化会明显降低模型质量。以这个1.2B的小模型来说Q4_K_M和原始F16的差异在大多数基础任务上并不明显只有做那种需要精确复述、细节很多的文本处理时能感觉到一点点差距。但换来的是显著的速度提升这笔账我觉得划算。3.3 实测命令与15 token/s的由来编译完成、模型文件也准备好之后就可以开始实测了。我用的是llama-cli完整命令大概长这样./build/bin/llama-cli \ -m ~/models/lfm2.5-1.2b-q4_k_m.gguf \ -p 用简洁的语言解释一下什么是程序化交易 \ -n 256 \ -t 6 \ -c 4096 \ --temp 0.7参数解释一下-m指定模型文件路径-p指定输入提示词-n生成的最大token数量-t使用的线程数我填了6对应物理核心数-c上下文长度设为4096日常任务足够了--temp温度参数控制随机性命令跑起来之后模型会先处理提示词然后逐token生成输出。我跑了多次平均生成速度基本稳定在每秒15个token上下。这个“15 token/s”是个什么概念一句话大约10到20个token也就是说模型每秒能生成大半句话阅读流畅度谈不上但基本不会让你干等。如果你只是做文本分类、关键词抽取这类短输出任务首token延迟加上几百毫秒的生成时间体感上几乎是即时响应。4. ollama路线一条命令到对外API4.1 把GGUF模型导入ollamallama.cpp跑通之后我在想如果只是想快速起一个测试服务每次都敲那么长一串命令也太烦了。这时候ollama的优势就体现出来了。ollama支持从GGUF文件直接创建模型核心是一个Modelfile。假设你的GGUF文件在~/models/lfm2.5-1.2b-q4_k_m.gguf先在工作目录创建一个文本文件名字就叫Modelfile内容如下FROM ./lfm2.5-1.2b-q4_k_m.gguf然后在同一目录下执行ollama create lfm2.5 -f Modelfileollama会把这个GGUF文件导入到自己的模型仓库里并给它起个名字叫lfm2.5。执行完成后你输入ollama list应该就能看到它了。之后运行就极其简单ollama run lfm2.5直接在交互式命令行里跟模型对话。第一次运行ollama需要加载模型会稍微慢一点之后就快了。这里有一个细节值得注意如果你的GGUF文件自带了模型对话模板信息Modelfile里不用写TEMPLATE就能正常工作但有些文件不具备这个信息回复格式可能会乱。真遇到这种情况再回头在Modelfile里手动加一个模板即可我这里先不展开。4.2 Modelfile里几个值得调的参数ollama的Modelfile不只是用来导入模型的它还能配置模型的运行参数。我个人建议至少把下面几个参数写进去FROM ./lfm2.5-1.2b-q4_k_m.gguf PARAMETER num_ctx 4096 PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER top_k 40 PARAMETER num_predict 512num_ctx上下文窗口长度跟llama.cpp里的-c对应。不要设太大内存占用会涨1.2B模型配4096是合理的甜点值。temperature温度。0.7是通用值做确定性任务可以降到0.3甚至更低生成创意内容可以调到0.9。top_p和top_k采样参数控制候选token的范围。保持默认也可以但写上可以避免一些模型自带默认值偏激进的问题。num_predict单次生成的最大token数相当于llama.cpp的-n。改完Modelfile之后需要重新执行一次ollama create才能生效注意是覆盖式创建不会破坏原文件。4.3 后台服务和API使用模型跑通之后更多人需要的是一个可以被外部程序调用的接口。ollama天然提供这个能力。先启动服务ollama serve默认情况下ollama会监听127.0.0.1:11434提供OpenAI兼容的接口。测试一下curl http://localhost:11434/api/chat -d { model: lfm2.5, messages: [{role: user, content: 用一句话介绍你自己}], stream: true }返回的是一段JSON格式的流式输出。如果你写的是后端服务直接按OpenAI的调用习惯发请求就行接口格式几乎一致迁移成本很低。这一点是我在实际使用中最喜欢ollama的地方——本地模型和云端模型之间切换代码层面几乎不用改。5. 每秒15个token背后速度到底受什么影响5.1 我的测试环境与基准标题里的“每秒15个token”是很吸引人的数字但你得清楚这个数字是在什么条件下测出来的。我把自己的基准说得精确一点方便你对照自己的硬件。测试环境6核12线程CPU16GB内存模型用Q4_K_M量化上下文4096线程数设为6生成长度固定在200个token。测速方式很简单就是让模型连续生成一段长文本统计总耗时取每秒生成的token数。为了避免首token延迟的干扰我取的是生成过程稳定后的平均值。在这个条件下LFM2.5-1.2B的稳定生成速度在我机器上是每秒14到16个token之间浮动取中位数就是15。如果你机器比我好比如有8核、内存带宽更大跑到20以上并不难如果是个四核老平台可能只有8到10。5.2 影响速度的关键因素我调参试了很多组合发现真正能把速度拉下来或者拉上去的因素其实就那么几个。第一个是线程数。这个最容易理解但也最容易踩坑。推理时多线程并行计算是实打实快的但线程数不是越多越好。超过物理核心数之后增加的线程只会带来上下文切换开销速度反而下降。我测试机是6核12线程设6到8之间速度最好设12反而慢。第二个是上下文长度。这里主要指KV cache的大小。上下文越长每一步预测时需要扫描的KV cache就多计算量也跟着涨。很多人跑小模型喜欢把上下文拉到8192甚至更长结果速度莫名其妙掉了30%原因就在这里。第三个是量化精度。Q4_K_M比Q8_0快Q8_0比F16快这个在前面已经验证过了。量化等级越高参与计算的数据量就越大CPU的运算压力自然就上去了。第四个是批大小。llama.cpp有个-b参数控制“一次同时处理多少个token的prompt”。处理长输入时批大小大一点会快但也会占用更多内存。对1.2B这个体量默认值通常已经不错不用刻意调。第五个是内存带宽。这是很多人忽略的一点。CPU推理时模型权重需要从内存不断读入CPU内存带宽不够的话计算核心再强也白搭。这也是为什么同样一颗CPU插双通道内存比单通道快很多。5.3 实测调优对比下面这张表是我在测试机上实测的几组对比你可以直观感受一下参数对速度的影响配置线程数上下文量化实测速度A64096Q4_K_M14-16 tok/sB44096Q4_K_M10-12 tok/sC62048Q4_K_M15-17 tok/sD68192Q4_K_M11-13 tok/sE64096Q8_011-13 tok/sF124096Q4_K_M12-14 tok/s配置A就是我最后的日常配置。配置C速度最快但上下文短了实用性受限配置D虽然上下文长但速度掉得明显小模型长上下文的收益也不高不划算。所以我的最终建议是线程数取物理核心数上下文取4096量化用Q4_K_M。这个组合在大多数普通配置上都能达到“不拖后腿”的速度体验。5.4 和其他体量模型的横向感受为了让你对“15 token/s”有更直观的感知我再说说这档体量和更大模型的对比感受。因为在同样一台机器上我也跑过3B、7B级别的模型差距非常明显。3B量级的小模型量化后在这台机器上的速度大概是每秒6到8个token能用但已经能感觉到明显的“逐字输出”节奏。7B级别就更夸张了即使在Q4量化下也只有每秒3到5个token用来做有来有回的对话勉强可以但稍微长一点的生成任务就会让人不耐烦。所以1.2B跑出15 token/s在CPU推理这个领域算是“轻快”级别的表现了。这让我在处理高频、短文本任务时完全没有延迟焦虑也更愿意把它常驻在后台而不是每次需要时才临时拉起来。6. 跑这一路的坑能避一个是一个6.1 内存不足时的诡异表现我在测试时踩到的第一个坑就是内存估算失误。我一开始只盯着模型文件大小觉得“750MB而已随便跑”结果在加载时直接被告知内存分配失败。后来才知道问题出在KV cache上。我不小心把上下文拉到了16384这个参数会让KV cache占用大幅上涨再加上程序本身的基础开销16GB内存居然也有点紧张。更坑的是内存不足时llama.cpp的报错信息并不直观有时候只是运行变得极慢你根本想不到是内存问题。所以特别提醒小模型不等于可以随意拉上下文。1.2B模型配4096上下文是甜点值追求长文本请掂量自己的内存。6.2 复读机问题跑本地模型时最常遇到的现象之一就是“复读机”模式上下文变长之后模型开始反复重复刚才说过的话有些时候甚至卡在同一句话上出不去。这个问题我在LFM2.5-1.2B上也遇到过。原因通常是采样参数没调好。解决办法比较直接设置重复惩罚参数llama.cpp里是--repeat-penalty 1.1ollama的Modelfile里对应PARAMETER repeat_penalty 1.1。设置之后模型对重复内容的输出概率会被压制复读现象基本消失。如果惩罚设置到1.1之后还复读可以检查一下上下文是不是太长了。小模型在很长的上下文里很容易失去焦点反而更爱兜圈子缩短上下文往往比调参数更有效。6.3 后台服务占资源与并发处理把模型常驻后台提供服务时还有一个问题容易忽略默认情况下ollama每处理一个请求就占一份内存。如果你同时并发多个请求内存和CPU占用会快速上升。我的做法是在启动服务前设置环境变量把并发数限制住export OLLAMA_NUM_PARALLEL1 export OLLAMA_MAX_LOADED_MODELS1 ollama serveOLLAMA_NUM_PARALLEL1表示同时只处理一个请求多余的排队等。对于本地小模型串行处理其实最稳定并发带来的吞吐提升有限反而容易把机器拖垮。如果是llama.cpp的server模式可以用--parallel参数控制并行数逻辑类似。6.4 提示词模板决定成败最后一个坑也是最容易被新手忽略的就是提示词模板。很多人在ollama里导入GGUF之后直接问问题发现模型回复驴唇不对马嘴第一反应是“模型坏了”。其实大概率是模板问题。不同模型对输入格式的要求不一样有的期望User: xxx\nAssistant:有的期望带system角色。如果你的GGUF文件没内置模板就需要手动在Modelfile里补充。我这里给一个比较通用的模板写法作为参考TEMPLATE {{- if .System }}System: {{ .System }} {{ end }}User: {{ .Prompt }} Assistant: 设置之后再ollama create重建一次模型。你会发现效果立竿见影——同样的提问之前答非所问现在一下就正常了。这算是我踩过几次坑之后养成的一个习惯拿到一个新的GGUF文件先确认它有没有内置聊天模板再去调采样参数。顺序反了的话会在错误的方向上浪费很多时间。