1. 从零上手LLM先搞清楚你到底要用它做什么很多人第一次接触LLM脑子里想的都是“我要跑一个大模型”但真正开始动手之后才发现问题根本不是“怎么跑”而是“跑哪个”“跑在哪”“跑完干什么”。我见过太多人上来就折腾环境、下载几十个G的权重文件结果卡在第一步——显存不够或者跑起来了但完全不知道拿它做什么。LLM也就是大语言模型本质上是一个“根据上文预测下一个词”的概率机器。你可以把它想象成一个读过海量文本的实习生知识面很广但需要你给出足够清晰的指令它才能输出你想要的东西。这个实习生不会主动问你“你到底要什么”它只会根据你给的提示词去猜。所以使用LLM的第一课不是技术课而是需求拆解课。这篇文章适合几类人看一是刚接触LLM、想搞清楚怎么在实际项目里用起来的开发者二是已经在用API调模型、但总觉得效果不稳定的工程师三是想在自己设备上跑本地模型、对隐私和离线有要求的技术爱好者。我会从使用思路、核心参数、实操流程、常见坑四个维度展开把“LLM使用方法”这件事讲透。先明确一个核心观点LLM的使用不是单一技能而是一套组合拳。它涉及模型选型、提示词设计、参数调优、输出校验、成本控制等多个环节。你不需要每个环节都做到极致但至少要知道每个环节在干什么出了问题该往哪个方向排查。2. 模型选型别一上来就追求最大最强2.1 先看任务类型再看模型规模选模型这件事很多人容易犯一个错误觉得参数越大越好。70B一定比7B强GPT-4一定比GPT-3.5强。方向没错但实际使用中任务类型才是第一决策因素。如果你做的是文本分类、信息抽取、简单问答这类任务7B到13B的模型经过适当微调或提示词优化完全够用。我实测过一个13B模型做合同关键条款抽取在提示词设计合理的情况下准确率能到92%以上而换成70B模型只提升了不到2个百分点但推理成本翻了五倍。如果你做的是复杂推理、代码生成、长文写作那确实需要更大的模型。但即便如此也要考虑你的延迟要求和成本预算。一个响应时间3秒的13B模型和一个响应时间15秒的70B模型用户体验是完全不同的。2.2 本地部署还是API调用这是另一个关键决策点。我列了一个对比表方便你根据自己的场景做判断维度本地部署API调用数据隐私完全可控数据出本地硬件成本一次性投入高按量付费推理延迟取决于硬件取决于网络和服务商模型选择受限于硬件几乎无限制维护成本需要自己运维服务商负责适合场景隐私敏感、高频调用快速验证、低频使用我个人的建议是验证阶段用API生产阶段看情况。先用API快速跑通流程验证业务价值。如果确认要上生产再根据调用频率和数据敏感度决定是否转本地。2.3 量化格式的选择如果你决定本地部署量化格式是绕不开的话题。GGUF是目前在消费级硬件上跑LLM最常用的格式之一它的优势在于支持CPUGPU混合推理对显存要求相对友好。常见的量化等级有Q4_K_M、Q5_K_M、Q8_0等。数字越小模型体积越小但精度损失越大。我的经验是Q4_K_M性价比最高适合大多数场景7B模型大约4-5GBQ5_K_M精度略好体积增加约20%适合对质量有要求的场景Q8_0几乎无损但体积接近原始模型的一半适合硬件充裕的情况注意量化不是越小越好。我见过有人用Q2量化的模型做代码生成结果输出的代码语法错误率极高。低于Q4的量化除非你只是做简单的文本分类否则不建议。3. 提示词设计LLM使用中最被低估的技能3.1 提示词的本质是“约束”很多人把提示词当成“提问”觉得只要把问题说清楚就行了。但实际上提示词的核心作用是约束模型的输出空间。模型在每一步都在从数万个词里选下一个词你的提示词就是在告诉它“往哪个方向选”。一个好的提示词通常包含四个要素角色设定告诉模型它是什么身份比如“你是一个资深法律顾问”任务描述明确要做什么比如“请从以下合同中提取甲方和乙方的名称”输出格式规定输出结构比如“以JSON格式输出包含party_a和party_b两个字段”约束条件说明边界比如“如果合同中未提及填写null不要编造”我实测下来加上输出格式约束之后信息抽取任务的准确率能从78%提升到93%。原因很简单模型不需要“猜”你要什么格式它只需要填充内容。3.2 少样本示例比长篇描述更有效如果你发现模型输出不稳定最有效的办法不是写更长的提示词而是给几个示例。这就是Few-shot prompting的思路。举个例子你要做情感分类。与其写“请判断以下评论是正面还是负面考虑语气、用词、上下文等因素”不如直接给两个示例评论这个产品质量很好物流也快 情感正面 评论用了两天就坏了客服还不理人 情感负面 评论{待分类的评论} 情感实测下来两个示例的效果比一段200字的描述要好得多。因为示例直接告诉了模型“输入长什么样输出长什么样”消除了歧义。3.3 思维链让模型“想清楚再回答”对于推理类任务思维链Chain of Thought是一个非常有用的技巧。核心思路是让模型先输出推理过程再给出最终答案。比如数学应用题直接问“答案是多少”模型可能算错。但如果提示词改成“请先列出计算步骤再给出最终答案”准确率会显著提升。原因是模型在生成推理步骤的过程中相当于在做“中间计算”这些中间结果会作为上下文影响最终答案的生成。实操心得思维链不是万能的。对于简单的事实性问题加思维链反而会增加延迟和token消耗。判断标准是如果任务需要多步推理用思维链如果只是信息检索或格式转换直接问就行。4. 核心参数调优温度、Top-p和最大长度4.1 温度控制输出的随机性温度Temperature是最重要的参数之一。它决定了模型在选择下一个词时的“冒险程度”。温度0模型总是选择概率最高的词输出最确定、最保守温度0.7有一定随机性输出更自然多样温度1.5随机性很高输出可能很有创意但也可能胡言乱语我的经验值是任务类型建议温度信息抽取0-0.2代码生成0.2-0.4对话系统0.6-0.8创意写作0.8-1.2注意温度设为0并不意味着输出完全确定。由于浮点数计算的精度问题不同硬件、不同批次的结果可能有微小差异。如果你需要完全可复现的输出还需要固定随机种子。4.2 Top-p另一种控制随机性的方式Top-p也叫核采样的思路是只从累积概率达到p的词集合中采样。比如Top-p0.9模型会先按概率排序取累积概率达到90%的那些词然后从中随机选一个。Top-p和温度的区别在于温度是“整体缩放概率分布”Top-p是“截断低概率词”。实际使用中我通常只调其中一个不同时调。如果两个都调效果会叠加很难控制。我的习惯是需要确定性输出时温度设低Top-p设1.0需要多样性时温度设0.7-0.9Top-p设0.9-0.95。4.3 最大长度别让模型“刹不住车”最大长度Max Tokens决定了模型最多能生成多少个token。这个参数看似简单但设置不当会带来两个问题设太小输出被截断任务没完成设太大模型可能生成冗余内容浪费token和时间我的做法是先估算任务需要的输出长度然后设置一个略大于估算值的上限。比如信息抽取任务输出通常不超过200个token那就设256。对话系统可能需要500-1000那就设1024。实操心得很多API的计费是按输入输出token总量算的。如果你把最大长度设得很大但模型实际只用了很少计费还是按实际用量算不会浪费。但如果模型真的生成了大量无用内容那就是实打实的成本。所以关键不是“设多大”而是“提示词是否足够清晰让模型知道什么时候该停”。5. 实操流程从零搭建一个LLM应用5.1 环境准备与模型加载假设你要在本地跑一个GGUF格式的模型最常用的工具是llama.cpp或者基于它的封装。以下是一个典型的加载流程# 下载模型文件以7B Q4_K_M为例 # 假设你已经从模型仓库获取了gguf文件 # 使用llama.cpp加载 ./llama-cli -m ./models/llm-7b-q4_k_m.gguf \ -p 你的提示词 \ -n 512 \ --temp 0.7 \ --top-p 0.9如果你用Python可以用llama-cpp-pythonfrom llama_cpp import Llama llm Llama( model_path./models/llm-7b-q4_k_m.gguf, n_ctx4096, # 上下文窗口大小 n_threads8, # CPU线程数 n_gpu_layers35 # 卸载到GPU的层数 ) output llm( 请将以下文本翻译成英文今天天气很好, max_tokens256, temperature0.3, top_p0.9 ) print(output[choices][0][text])关键参数说明n_ctx上下文窗口大小。越大能处理的输入越长但显存/内存占用也越大。4096是常见值如果硬件允许可以设到8192甚至更高。n_gpu_layers决定多少层跑在GPU上。设得越大GPU利用率越高速度越快。如果显存不够会回退到CPU速度会明显下降。n_threadsCPU推理时的线程数。一般设为物理核心数。5.2 提示词模板的工程化在实际项目中提示词不应该硬编码在代码里而应该做成模板方便迭代和版本管理。我通常用Jinja2或者简单的字符串格式化PROMPT_TEMPLATE 你是一个专业的{role}。 请完成以下任务{task} 输入内容 {input} 输出要求 {output_format} 请严格按照输出要求作答不要添加额外解释。 prompt PROMPT_TEMPLATE.format( role合同分析师, task提取合同中的甲方、乙方和签约日期, inputcontract_text, output_formatJSON格式{party_a: , party_b: , sign_date: } )这样做的好处是当你要调整角色或输出格式时只需要改模板不需要动业务逻辑代码。5.3 输出解析与校验LLM的输出是文本但你的下游系统可能需要结构化数据。所以输出解析是必不可少的一步。对于JSON输出最稳妥的做法是在提示词中明确要求JSON格式用正则表达式提取JSON部分防止模型在JSON前后加了说明文字用json.loads解析校验必填字段是否存在import json import re def parse_llm_json(output_text): # 尝试提取JSON块 match re.search(r\{.*\}, output_text, re.DOTALL) if not match: raise ValueError(未找到JSON内容) try: data json.loads(match.group()) except json.JSONDecodeError as e: raise ValueError(fJSON解析失败{e}) # 校验必填字段 required_fields [party_a, party_b, sign_date] for field in required_fields: if field not in data: raise ValueError(f缺少必填字段{field}) return data实操心得不要假设模型每次都能输出合法JSON。我遇到过模型在JSON后面加了一句“希望对你有帮助”导致解析失败。所以正则提取异常处理是必须的。另外如果解析失败可以考虑重试一次有时候只是偶发的格式偏差。6. 常见问题与排查技巧实录6.1 模型输出重复、循环这是本地部署小模型时最常见的问题之一。表现是模型反复输出同一句话或者陷入某种循环。原因通常是温度太低、重复惩罚repeat_penalty设置不当或者提示词本身有歧义。解决方法适当提高温度比如从0.1调到0.3设置repeat_penalty为1.1-1.2检查提示词是否有模糊表述比如“请详细说明”可能导致模型不断展开6.2 显存不足OOM原因模型太大、上下文窗口设得太大、GPU层数设得太多。解决方法降低n_gpu_layers让更多层跑在CPU上减小n_ctx换更小的量化版本比如从Q5换到Q4如果还是不够考虑换更小的模型6.3 输出不符合格式要求原因提示词约束不够强或者模型能力不足。解决方法在提示词中增加“只输出JSON不要添加任何其他文字”增加Few-shot示例如果还是不行考虑换更大的模型或者在输出后做后处理6.4 推理速度太慢原因CPU推理、模型太大、线程数设置不合理。解决方法增加n_gpu_layers尽量用GPU调整n_threads为物理核心数换更小的量化版本如果硬件实在有限考虑用API6.5 常见问题速查表问题现象可能原因排查方向输出重复循环温度过低、重复惩罚不当调高温度、设repeat_penalty显存不足模型太大、上下文过长减层数、减上下文、换量化格式不符提示词约束弱加示例、加格式约束速度慢CPU推理、线程少加GPU层、调线程数内容编造模型幻觉加约束、要求引用原文截断max_tokens太小增大max_tokens7. 进阶技巧让LLM用得更稳7.1 用LLM做单元测试生成这是一个很实用的场景。你可以把函数代码喂给LLM让它生成单元测试用例。提示词可以这样设计你是一个测试工程师。请为以下函数生成单元测试 {function_code} 要求 1. 覆盖正常输入、边界值、异常输入 2. 使用pytest框架 3. 每个测试函数只测一个场景 4. 输出完整的测试代码实测下来对于逻辑清晰的函数LLM生成的测试覆盖率能到80%以上。但要注意生成的测试需要人工审查因为模型可能对某些边界条件的理解有偏差。7.2 用LLM做输出校验这是一个“以模治模”的思路。当你用LLM生成内容后可以再用一个LLM来校验输出是否符合要求。比如请检查以下JSON是否符合指定格式如果有问题请指出 {output_json} 期望格式 {name: string, age: number, email: string}这种做法会增加成本但对于质量要求高的场景是值得的。7.3 上下文管理LLM的上下文窗口是有限的。如果你的输入很长需要做截断或摘要。常见的策略有滑动窗口只保留最近的N个token摘要压缩用LLM把长文本压缩成短摘要关键信息提取只保留与任务相关的部分我通常的做法是先估算输入长度如果超过上下文窗口的70%就触发压缩逻辑。压缩可以用规则比如只取前N段也可以用LLM做摘要。实操心得上下文窗口不是越大越好。我实测过当输入长度超过一定阈值后模型对中间部分的注意力会下降导致“中间遗忘”现象。所以即使硬件允许也不建议把上下文塞得太满。关键信息尽量放在开头或结尾。8. 我踩过的坑与实战建议说几个我实际踩过的坑希望能帮你省点时间。第一个坑盲目追求大模型。刚开始的时候我觉得7B模型“不够聪明”非要上70B。结果硬件成本翻了几倍推理速度慢到没法用最后发现13B模型加上好的提示词效果完全够用。模型大小不是唯一变量提示词质量和任务匹配度同样重要。第二个坑忽略输出解析。早期我直接拿模型输出做下游处理结果模型偶尔加一句“希望以上内容对你有帮助”导致JSON解析失败。后来加了正则提取和异常处理稳定性大幅提升。永远不要假设模型输出是完美的。第三个坑提示词写得太“客气”。我一开始写提示词喜欢加“请”“麻烦”“谢谢”后来发现这些词对模型输出没有任何帮助反而占用了token。现在我的提示词都是直接、明确、结构化。对模型不需要礼貌需要的是清晰。第四个坑不做版本管理。提示词改了之后效果变差想回滚却发现没记录。现在我所有的提示词都放在Git里每次修改都有commit记录。提示词是代码需要版本管理。第五个坑忽略成本监控。用API的时候没注意token消耗月底一看账单吓了一跳。现在我会在代码里记录每次调用的输入输出token数定期分析哪些提示词消耗最大有没有优化空间。成本意识要贯穿始终。最后分享一个实用技巧如果你在调提示词的时候发现效果不稳定先别急着改提示词试试把温度降到0。如果温度0时输出稳定且正确说明提示词没问题只是随机性导致的波动。如果温度0时还是不对那才是提示词的问题。这个排查顺序能帮你少走很多弯路。