本地大语言模型Local LLMs在过去一年里从极客玩具变成了日常开发工具。很多人不再只把对话、代码补全和文本总结交给云端 API而是开始在自有机器上运行 7B、14B 甚至 32B 参数规模的模型。驱动这种变化的原因并不难理解隐私、成本、离线可用、可控性以及模型量化技术成熟后带来的硬件门槛下降。这篇文章围绕“开发者怎么用本地大语言模型”这个主题梳理典型使用场景、部署工具链、模型选型方法、最小可运行案例和常见问题排查路径帮助你在自己的电脑或内网服务器上跑通一套真正有生产力的本地 LLM 工作流。文章不追新版本号也不承诺“最强的部署方案”而是把选择权和判断方法交给你。每个示例都给出目的、操作、预期结果和关键参数解释。你在落地时可以根据自己的操作系统、显卡显存、内存和模型类型做调整。1. 为什么开发者开始认真使用本地大语言模型本地 LLM 的核心价值不在“跑一个模型”而在“把模型变成自己可以控制的基础设施”。理解这一点才能判断哪些场景适合本地部署哪些场景仍然应该使用云端 API。1.1 本地 LLM 解决的核心问题本地 LLM 是指把大语言模型的权重文件下载到本机或内网服务器通过推理引擎加载在本地完成文本生成、代码补全、文本分类、信息抽取等任务不需要将数据发送到外部 API 服务。它解决的第一类问题是数据隐私。企业内部的代码、合同、客户工单、财务说明、医疗文本等数据通常不允许进入外部模型服务。本地部署后数据只在你的机器和内网之间流转合规压力会小很多。第二类是成本控制。云端 API 按 token 计费高频调用、批量处理长文档时费用会快速上升。本地推理主要成本是硬件折旧和电费对持续运行的中低并发场景往往更可控。第三类是离线可用。建设工地、工厂车间、隔离网络、飞机、船舶等没有稳定互联网连接的环境仍然需要代码补全或文档问答能力本地模型是少数可行方案之一。第四类是可控性。本地模型可以自由微调、替换、模拟实验不会被上游模型的版本升级打断。你不需要担心某一天 API 的某个参数被废弃。1.2 本地部署与云端 API 的取舍本地 LLM 并不是云端 API 的完全替代两者各有利弊。维度本地 LLM云端 API数据出境数据不出内网数据进入服务商环境初始成本需要购买 GPU 或高内存机器无硬件成本单次调用成本主要是电费按 token 计费并发能力受本地显存、算力限制可弹性伸缩模型能力上限受机器资源限制一般跑中低参数量模型可使用最新大参数模型离线运行支持不支持维护负担需要自己处理升级、监控、告警服务商负责实际项目里的常见策略是“混合使用”敏感数据和批量离线任务走本地模型需要最高质量生成、对延迟不敏感的场景使用云端 API。不要把本地部署理解为省钱唯一解也不要认为本地模型一定弱到不可用。7B 到 14B 的量化模型在代码补全、短文本生成、结构化抽取上已经具备实用价值。2. 本地 LLM 的六大典型使用场景很多人问“本地 LLM 能干嘛”其实答案取决于使用场景。以下六个场景是目前开发者社区里反复出现的高频用法也对应不同的工程架构选型。2.1 编码辅助与代码审查本地代码模型是当前最成熟的落地场景。开发者把本地推理服务接入 VS Code、JetBrains 或 Neovim通过 Continue、Tabby、Fitten Code 等插件获取代码补全、函数生成、单元测试编写和 commit message 生成能力。与 GitHub Copilot 这类云端方案相比本地代码模型的优点是企业私有代码不会离开内网缺点是在复杂的跨文件重构、长上下文理解上小参数模型仍然明显弱于大参数云端模型。典型模型选择是 Qwen2.5-Coder、DeepSeek-Coder、CodeLlama 系列。硬件条件有限时优先选择 7B 级别量化模型。2.2 私有知识库问答与文档处理把内部 Wiki、产品手册、合同范本、运维文档切成片段做向量化后存入本地方量数据库再用本地 LLM 根据检索结果生成回答。这就是私有知识库问答RAGRetrieval-Augmented Generation的基本链路。这种场景适合部门内部资料检索、客服话术生成、新员工培训问答。它不需要模型记住所有知识只需要模型具备“根据给定片段总结并回答”的能力因此低参数模型就能获得不错效果。2.3 日志、邮件和文本内容总结本地 LLM 也经常被当作文本预处理和后处理工具。例如把千行异常日志压缩成 200 字原因摘要。把客户邮件归类并生成回复草稿。把会议录音转写文本整理成行动项。把长文档拆成结构化的摘要卡片。这类任务通常不需要复杂 Agent 编排一条 Python 脚本调用本地模型接口就能完成。关键是设置好 prompt 模板和输出格式避免模型自由发挥。2.4 离线环境下的对话助手在没有外部网络的环境中一个本地对话助手可以大幅减少重复性咨询工作。比如工厂设备维护人员用自然语言查询操作手册门诊前台查询预约流程机房值班人员查询故障处理预案。离线对话助手需要格外注意模型幻觉问题。建议在系统提示词中明确要求“只根据给定资料回答资料中没有的内容回答不知道”并在应用层面对回答内容做来源标注。2.5 作为 Agent 工具链中的本地推理内核越来越多开发者把本地 LLM 嵌入 Agent 工作流让它承担“计划拆分”“工具调用参数生成”“结果总结”等任务。例如让本地模型从用户指令中提取结构化参数然后代码逻辑去执行真正的 API 调用。让本地模型把复杂任务拆成多个步骤配合既有脚本串成自动化流水线。在数据分析场景中让本地模型把自然语言转换成 SQL 或 pandas 代码。这里不要期望本地小模型能像大模型一样自主规划复杂任务。更可行的方式是“用代码控制流程用模型处理语义理解”把模型当作一环而不是大脑。2.6 数据隐私训练与模型微调前的测试环境在把数据送入微调任务之前先在一台本地机器上用小模型验证 prompt 模板、数据清洗规则、标注格式是否合理。这种“先本地小模型试跑再决定是否批量处理”的流程可以节省大量成本也能避免数据泄露风险。3. 本地部署工具链从最省事到最灵活部署本地 LLM 的方式很多选择哪种不是越高级越好而是取决于你的使用习惯和运维能力。3.1 Ollama适合快速跑通场景Ollama 是目前最流行的本地推理工具之一。它把模型下载、模型管理和 OpenAI 兼容接口封装得非常简单一条命令就能拉起一个模型服务。ollama pull qwen2.5:7b ollama run qwen2.5:7bOllama 会自动处理模型格式、量化位置和基础运行时配置。启动后它默认监听127.0.0.1:11434并提供 OpenAI 风格的接口方便接入各类插件。适合人群想快速验证模型效果、不想折腾底层推理环境、需要快速接入编码插件或本地应用。3.2 LM Studio适合桌面端验证和可视化调试LM Studio 是图形化桌面应用支持从模型仓库下载 GGUF 格式模型并提供图形化参数面板、对话窗口和本地 OpenAI 兼容服务。你可以在界面里直接调整温度、top_p、上下文长度等参数观察模型输出变化。适合人群希望可视化操作、不熟悉命令行、需要快速对比多个模型效果的开发者。3.3 llama.cpp 与 GGUF 格式适合低资源机器llama.cpp 是一个使用 C/C 实现的推理引擎专为 CPU 和低显存环境优化GGUF 是它定义的模型存储格式。它的优点是跨平台、依赖少、量化支持成熟很多小内存机器也能运行。git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DLLAMA_CUBLASON cmake --build . --config Release如果使用 NVIDIA GPU编译时加上-DLLAMA_CUBLASON如果使用 Apple Silicon则使用-DLLAMA_METALON。编译完成后可以这样启动服务./llama-server -m /path/to/model.gguf \ --host 0.0.0.0 \ --port 8080 \ --ctx-size 8192 \ --n-gpu-layers 99适合人群需要精细控制推理参数、使用老旧 GPU 或纯 CPU 环境、希望深入理解推理过程的开发者。3.4 vLLM 与 SGLang适合本机高性能推理和多用户服务如果要在内网服务器上部署一个被多个开发者或应用同时调用的本地模型服务推荐使用 vLLM 或 SGLang。它们使用 PagedAttention、Continuous Batching 等技术能显著提升吞吐量尤其适合多用户并发场景。pip install vllm vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9vLLM 启动后会提供 OpenAI 兼容的/v1/chat/completions接口可以直接用 requests 或 OpenAI SDK 接入。适合人群内网多用户使用、需要稳定 API 服务、机器显存相对充足、有一定 Docker 和 Python 服务化经验。3.5 工具选型速查工具界面运行环境推荐场景难度Ollama命令行为主跨平台个人快速验证、接入插件低LM Studio图形化Windows / macOS桌面端模型对比和调试低llama.cpp命令行、C 编译跨平台、低资源机器精细控制、CPU 推理中vLLMPython 服务Linux NVIDIA GPU 为佳内网多用户 API 服务中高无论选择哪个工具都要记住一个原则工具只是启动模型的方式真正影响输出质量的是模型选择、prompt 设计和采样参数。4. 模型选型参数规模、量化等级和上下文长度本地 LLM 常说的“跑不跑得动”和“效果好不好”通常由三件事决定参数规模、量化等级、可用显存或内存大小。4.1 参数规模怎么选参数规模决定了模型基础能力也直接决定了显存和内存占用。下表是一个粗略参考参数规模典型模型例可用显存/内存参考适用场景1B-3BQwen2.5-3B、Llama-3.2-3B4GB-8GB简单对话、文本分类、日志摘要7B-8BQwen2.5-7B、Llama-3.1-8B6GB-12GB编码补全、RAG 问答、中等推理13B-14BQwen2.5-14B、CodeLlama-13B10GB-20GB复杂代码生成、较长的分析任务32BQwen2.5-32B、Yi-1.5-32B20GB-40GB高质量生成接近云端普通模型效果这只是一个粗略判断实际占用还取决于量化等级、上下文长度和推理引擎。选择策略建议是先选一个比需求高一个档次的模型再通过量化把占用降下来不要一开始就选最大模型。4.2 量化等级Q4_K_M、Q5_K_M、Q8 到底差多少量化是把模型权重从高精度如 16 位浮点压缩到低精度如 4 位整数的过程。GGUF 模型常见量化等级包括 Q4_K_M、Q5_K_M、Q8_0 等。量化等级相对内存占用生成质量损耗适合场景Q4_K_M低轻微通常可接受大多数本地部署首选Q5_K_M中低比 Q4 更接近原版显存足够时优先选择Q8_0中很小对质量敏感资源充足F16高接近原始精度显存充足追求最佳效果同样一个 7B 模型F16 可能需要约 14GB 显存Q4_K_M 可能只需要约 5GB 左右。Q4_K_M 是社区使用最广泛的折中选择。如果英文和代码任务偏多推荐先试 Q5_K_M 或 Q8_0因为量化等级对代码精度的影响有时会被低估。4.3 上下文长度和显存占用估算上下文长度越长模型能处理的输入输出内容越多但 KV Cache 占用的显存也越大。这也是很多开发者发现“模型能加载但一输长文本就显存溢出”的原因。KV Cache 占用可以用一个粗略公式估算KV Cache 大小 ≈ 2K 和 V × 层数 × 注意力头数 × 每头维度 × 上下文长度 × 每个元素字节数这个公式计算起来比较麻烦实际项目中更快的办法是直接看推理引擎启动时的日志。Ollama 和 llama.cpp 会打印 KV Cache 大小、总显存占用等提示信息。遇到内存不足时优先选择降低上下文长度例如从 8192 降到 4096。使用支持动态缓存回收的推理引擎例如 vLLM。使用显存更小的量化等级。把部分层从 GPU 卸载到 CPU。4.4 通用模型与专用模型怎么选如果你只需要代码补全优先选 Qwen2.5-Coder、DeepSeek-Coder 这类代码专用模型如果你需要综合对话、总结、推理都要做选通用指令模型如 Qwen2.5-Instruct、Llama-3.1-Instruct如果你需要中文效果突出优先考虑 Qwen 系列。不要迷信“大模型什么都能干”。本地部署中专用小模型往往比通用大模型在特定任务上更实用而且占用资源更少。5. 从零跑通一个本地代码助手这一节用一个最小可运行案例演示从环境检查到代码补全功能跑通的全过程。示例以 Ollama 和 Qwen2.5-Coder 7B 为主如果你使用其他推理引擎逻辑同样适用。5.1 环境准备和硬件检查在下载模型之前先确认自己的硬件条件。# Linux 下查看 GPU 显存 nvidia-smi # 查看内存 free -h # 查看 CPU 型号 lscpu如果使用 macOS可以在“关于本机”里查看统一内存大小。Apple Silicon 的 Mac 在运行 7B 量化模型时通常表现不错但 14B 以上模型需要留意内存压力。需要满足的最低参考配置7B 量化模型建议 8GB 以上可用显存或 16GB 以上内存。14B 量化模型建议 16GB 以上可用显存或 32GB 以上内存。32B 量化模型建议 24GB 以上可用显存纯 CPU 推理需要 32GB 以上内存且速度偏慢。如果你的机器不满足配置不要硬跑大模型可以先用 1B-3B 模型验证流程再考虑升级硬件或使用内网 GPU 服务器。5.2 用 Ollama 部署 Qwen2.5-CoderOllama 的安装方式很简单安装完成后直接拉取模型。ollama pull qwen2.5-coder:7b-instruct拉取完成后先验证模型能否正常对话ollama run qwen2.5-coder:7b-instruct在交互窗口输入请用 Python 写一个函数输入是文件路径列表输出是这些文件的总行数。正常情况会输出一段 Python 代码。如果你只想启动 API 服务而不进入交互窗口可以这样ollama serve默认服务地址是http://127.0.0.1:11434。用 curl 验证服务是否可用curl http://127.0.0.1:11434/v1/models返回结果中应该包含qwen2.5-coder:7b-instruct这个模型 ID。注意Ollama 的/v1/models是 OpenAI 兼容接口的子集完整能力需要查看你当前版本的文档不同版本支持的接口会有差异。5.3 配置编码插件接入本地模型这里以 VS Code Continue 插件为例。在 VS Code 中安装 Continue 扩展后打开 Continue 的配置文件config.json添加一个指向本地 Ollama 的模型配置{ models: [ { title: Qwen2.5 Coder 7B, provider: ollama, model: qwen2.5-coder:7b-instruct, apiBase: http://127.0.0.1:11434 } ] }保存配置后在 Continue 面板里选择该模型即可在编辑器里使用 Tab 补全代码、选中代码后让模型解释或生成测试。如果使用 JetBrains 系 IDE可以尝试接入本地 Ollama 或使用支持 OpenAI 兼容接口的插件例如 CODEX、Continue 等。不同插件配置项名称略有差异核心思路都是填写本地服务地址和模型名。5.4 验证一个最小闭环不要只验证“模型能聊天”要验证“代码补全是否真的被 IDE 使用”。建议做三件事新建一个 Python 文件输入def merge_two_sorted_lists(观察是否有补全候选。选中一段函数要求插件生成对应的 pytest 测试用例。要求模型解释一段带装饰器的 Python 代码确认输出不是从网上复制而是基于上下文生成。如果补全候选一直没有出现先看几个位置Ollama 服务是否启动。Continue 配置文件是否被正确加载。IDE 输出日志里是否有请求错误。模型是否还在加载中有时第一次请求需要等待几十秒。5.5 关键参数解释本地模型服务里经常出现几个参数常用的如下参数含义常见值调大影响调小影响temperature采样随机性代码任务 0.1-0.3对话 0.7输出更多样但更容易出错输出更确定但可能显得机械top_p核采样阈值0.8-0.95保留更多候选 token候选 token 更少更集中ctx-size / num_ctx上下文长度4096-8192能处理更长文本占用更多显存长文本可能被截断max_tokens最大生成长度512-2048输出更长耗时增加输出提前截断代码生成任务推荐使用较低 temperature对话和创意写作可以适当提高。不要把 temperature 设到 1.0 以上否则代码中很容易出现语法错误。6. 本机部署一个私有知识库问答服务知识库问答是本地 LLM 最有价值的场景之一。这一节演示一个最小 RAG 流程使用 Python、LangChain 和本地 Ollama 完成“导入文档 - 向量化 - 检索 - 生成回答”的完整闭环。6.1 为什么需要知识库而不是直接喂全文大语言模型的上下文窗口是有限的。一份 50 页产品文档可能远超 8K 上下文限制而且把全文塞进去会让模型在无关信息中迷失重点。RAG 的思路是把长文档切成多个小片段提前用向量模型把片段转成向量并存入向量数据库。用户提问时先在向量数据库里找到最相关的几个片段再把“用户问题 相关片段”一起交给本地 LLM 生成回答。这样做的优点是不依赖模型记住所有知识。增强回答的可追溯性可以定位到源文档片段。知识更新时只需要重新向量化新文档不需要重新训练模型。6.2 向量化、检索和生成的基本链路一条完整的 RAG 链路包含四个环节文档加载与切分读取 PDF、Markdown、TXT 等文件按固定长度和重叠区域切分成片段。向量化使用 embedding 模型把每个片段转成向量。向量检索用户提问时把问题转成向量在向量库中按余弦相似度或欧氏距离检索 TopK 片段。生成回答把检索到的片段拼接进 prompt交给 LLM 生成回答。embedding 模型和生成模型可以是两个不同的模型。如果资源有限embedding 可以选用较小的模型例如bge-m3或Qwen3-Embedding生成模型选用 7B 级量化模型。6.3 使用 LangChain 或 LlamaIndex 搭建最小流程这里用 LangChain 和 Ollama 演示。安装依赖pip install langchain langchain-community chromadb sentence-transformers然后编写一个 Python 脚本from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.llms import Ollama from langchain.chains import RetrievalQA # 1. 加载文档 loader TextLoader(company_manual.txt, encodingutf-8) documents loader.load() # 2. 切分文档 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) chunks text_splitter.split_documents(documents) # 3. 向量化并存入 Chroma embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-m3 ) vectorstore Chroma.from_documents( chunks, embeddings, persist_directory./chroma_db ) # 4. 连接本地 LLM llm Ollama( modelqwen2.5:7b, base_urlhttp://127.0.0.1:11434, temperature0.2 ) # 5. 构建检索问答链 qa_chain RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 3}) ) # 6. 提问 question 公司年假政策是什么 answer qa_chain.invoke({query: question}) print(answer[result])这段代码说明了 RAG 链路的大致写法实际项目需要处理的细节更多文档格式兼容PDF 需要额外使用PyPDFLoader等加载器。切分策略固定 500 字切分不一定最优要结合文档结构、标题、列表进行调整。持久化Chroma 的persist_directory参数会在本地保存向量库二次运行可以跳过重复向量化。答案质量需要把检索到的片段来源也返回给用户方便核对。6.4 运行验证和结果判断运行脚本后正常预期会得到一段基于company_manual.txt内容的回答。判断结果是否合格不只看回答是否通顺还要看回答是否包含文档中不存在的信息幻觉。检索到的 TopK 片段是否真的和问题相关。切分点是否把连贯语义切碎。如果检索片段不相关无论模型多强都无法给出正确答案。用一个简单的评估方法把k从 3 改成 1观察回答质量是否下降。如果明显下降说明检索链路才是瓶颈而不是生成模型。注意RAG 中生成模型的能力不需要太强关键在检索质量。先用好切分策略和向量检索再考虑换更大的生成模型。7. 常见问题排查本地 LLM 跑不起来的十个原因本地 LLM 部署的报错通常不是模型本身的问题而是环境、显存、配置和调用方式的问题。以下整理高频排查路径。7.1 显存不足现象启动推理服务时报CUDA out of memory或进程被系统杀死。可能原因模型量化等级过高。上下文长度设置过大。同时加载了多个模型。使用 CPU 和 GPU 混合部署时CPU 内存也不足。排查步骤查看 GPU 显存使用情况。把ctx-size或num_ctx从 8192 降到 4096。更换更低量化等级例如从 Q8 换成 Q4_K_M。确认没有其他进程占用显存。7.2 内存和 CPU 推理速度慢现象模型能输出但每秒只能生成几个 token完全无法用于交互。可能原因模型没有进入 GPU全部跑在 CPU 上。--n-gpu-layers设置的 GPU 层数太少。内存带宽不足。排查步骤查看推理日志确认模型层是否加载到 GPU。在 llama.cpp 中增大--n-gpu-layers参数在 Ollama 中检查num_gpu配置。如果纯 CPU 推理尽量使用 4bit 以下量化模型并把上下文长度控制在 2048 左右。7.3 模型输出重复、乱码或中途截断现象回答出现反复重复的句子、突然变成乱码或者生成了不完整的 markdown 代码块。可能原因temperature 过高采样不稳定。max_tokens设置太短输出被截断。模型本身就是低质量量化版本。系统中文字符编码处理有问题。排查步骤把 temperature 降到 0.2 或 0.1。把max_tokens从 256 增加到 1024。换一个量化等级更高的模型文件。检查终端编码确保 UTF-8。7.4 端口被占用或服务 502现象API 请求返回 connection refused 或 502 Bad Gateway。可能原因服务没有启动。服务启动在其他端口。代理环境变量干扰了本地请求。防火墙或 Docker 网络配置问题。排查步骤用curl访问本机接口地址。确认服务监听端口和代码里请求的端口一致。检查是否有HTTP_PROXY、HTTPS_PROXY环境变量指向外部代理导致本地请求失败。Docker 部署时确认端口映射和容器网络配置是否正确。7.5 插件连不上本地服务现象IDE 插件一直显示连不上模型但命令行请求服务正常。可能原因插件配置里的apiBase写错。Ollama 服务只监听了127.0.0.1而插件从远程或容器访问。插件使用了 HTTPS 访问本地 HTTP 服务。排查步骤检查插件日志确认实际请求 URL。在本机浏览器访问服务接口确认可用。如果需要跨机器访问在 Ollama 启动时设置OLLAMA_HOST0.0.0.0并配置防火墙规则。7.6 上下文窗口溢出现象输入长文档时报错提示超过最大上下文长度。可能原因模型原始上下文长度被限制。推理引擎的ctx-size设置小于输入长度。系统提示词、历史记录和当前输入加起来超过限制。排查步骤确认模型实际支持的上下文长度可以在模型卡或模型文件信息中查看。增大推理引擎的上下文参数。在应用层对历史消息做裁剪只保留最近几轮对话。7.7 常见问题速查表问题现象优先检查处理建议CUDA out of memory显存占用、量化、上下文降量化、减上下文响应极慢GPU 层数、CPU 推理调大 GPU 层数、换小模型回答乱码或重复temperature、max_tokens降温、加长 max_tokens服务无法访问端口、监听地址、代理检查监听和代理环境变量插件连不上apiBase、网络环境确认插件配置和服务地址长文本报错上下文长度限制加大 ctx-size 或裁剪输入8. 生产环境的本地 LLM 实践建议与扩展方向本地 LLM 从“跑通一个 demo”到“可靠服务”之间有不少工程化工作。这一节给出学习环境与生产环境的差异、发布前检查清单和后续扩展方向。8.1 学习环境、测试环境和生产环境的区别维度学习验证环境测试环境生产环境目标验证模型效果和链路可行性验证功能、性能和稳定性对外提供可靠服务硬件个人电脑中配 GPU 服务器按 QPS 和响应要求规划服务方式命令行交互单机 API 服务容器化、多副本、监控告警数据使用公开测试数据脱敏业务数据真实业务数据严格控制权限日志可忽略记录请求和响应摘要完整请求日志、错误日志、指标回滚不需要准备旧版本权重和配置必须设计模型和配置回滚方案安全本地使用内网访问认证、限流、数据脱敏不要在个人笔记本上直接跑生产流量。个人电脑的硬件稳定性、散热、磁盘IO都不适合长时间高负载运行。8.2 发布前检查清单在把本地 LLM 服务接入真实应用之前建议逐项检查模型权重来源是否可信是否记录了模型版本和量化等级。推理引擎版本和模型格式是否匹配。服务启动命令是否写成 systemd 或 Docker Compose 配置而不是手动执行。是否配置了日志采集和指标监控例如每请求延迟、失败率、显存使用率。是否在服务前面添加了认证和限流防止内网任意调用。是否设计了模型权重回滚方案。是否对输入内容做了敏感词过滤和长度限制。是否确认了数据不经过任何外部服务。是否准备了压测报告确认并发量在可接受范围。是否有值班和告警联系人。8.3 常用指标TTFT、TPS、QPS评估本地 LLM 服务性能时不建议只看“能跑就行”。建议关注以下指标指标全称含义优化方向TTFTTime To First Token发起请求到收到第一个 token 的时间减小 prompt 长度、优化 KV CacheTPSTokens Per Second每秒生成的 token 数换更大量化模型、升级 GPU、减少上下文QPSQueries Per Second每秒能处理的请求数使用连续批处理、增加副本在 vLLM 等支持 Continuous Batching 的推理引擎中QPS 和 TPS 之间需要权衡。并发请求多时单个请求的 TPS 会下降但整体 QPS 会提高。实际服务需要根据业务场景选择合适的并发控制策略。8.4 本地 LLM 后续可以延伸的方向跑通基础服务之后可以沿着以下方向继续深入模型微调用 LoRA 或 QLoRA 在业务数据上做轻量微调提升特定任务效果。函数调用与 Agent让本地模型学会输出 JSON 格式的 tool call接入内部工具。多模型路由根据任务复杂度自动选择本地小模型或云端大模型。离线供电与边缘部署把模型打包进 Docker 镜像部署到工控机或边缘服务器。可观测性建立请求级 trace把检索片段、生成时长、token 用量全部记录下来方便持续优化。对初学者最有价值的练习是先不追求跑大模型而是用 7B 模型把一个真实任务跑通记录它在不同量化等级、不同上下文长度下的输出质量差距。这个过程能帮你建立对模型能力、硬件需求和工程成本的真实直觉比盲目追求 70B 模型更有意义。本地 LLM 的价值不在于替代云端模型而在于让开发者拥有一个数据不出内网、成本可控、随时可实验的推理环境。把模型选型、推理引擎、RAG 链路、性能指标和排错方法掌握好就能在实际项目中做出真正可用的落地决策。