拿 LLM 当聊天机器人用其实连它 10% 的能力都没摸到。这是我在过去大半年里反反复复折腾各种模型、框架和部署方案之后最深的感受。很多人一提到 LLM 就直接想到网页对话框回答几句就结束了。但真正要把 LLM 嵌进自己的业务流程、工具链甚至产品里需要搞明白的东西远比“输入一句 Prompt”多得多——怎么选模型、怎么接 API、怎么省 token、怎么让它稳定输出结构化结果、怎么部署到自己的机器上每一步都有讲头。这篇文章就是围绕“LLM 使用方法”这个主题写的。我会从最底层的运行机制讲起然后依次拆解模型选型、API 接入、RAG 知识库、LLM as Judge、单元测试、ONNX 部署和性能优化这些实操环节。内容不追求面面俱到但每个环节我都给出了可复现的操作路径和踩坑记录适合刚准备把 LLM 从“演示玩具”变成“生产工具”的读者。看的时候不用着急按自己的基础跳着读就行。1. 先把 LLM 的运行机制看明白1.1 LLM 是什么它和深度学习是什么关系LLMLarge Language Model大语言模型本质上是基于深度学习的序列到序列模型绝大多数现代 LLM 都采用了 Transformer 架构。它的核心任务是“预测下一个 Token”——给定一段文本模型根据已有的词元序列预测最可能出现的下一个词元然后反复迭代直到输出完整的句子。所以回到那个经常被问到的问题LLM 是否属于深度学习答案非常明确——是。LLM 是深度学习在自然语言处理领域最直接的代表作它通过大规模语料预训练得到的权重本质上就是深度神经网络里的亿级甚至万亿级参数。很多人觉得 LLM 是某种全新的技术其实它背后用的还是“神经网络 反向传播 梯度下降”这套经典方法论只是模型规模大了几个数量级训练数据和算力也堆到了前所未有的级别。不过在实际使用中我建议大家不要纠结“它是不是深度学习”这种分类学问题真正要关注的是三个使用层面的特征LLM 是概率模型它输出的是“最可能的回答”不是“最正确的回答”。LLM 的知识截止时间是固定的除非接外部工具或知识库否则它无法知道训练之后发生的事。LLM 没有真正的逻辑推理能力它擅长的是模式匹配和分布拟合复杂逻辑需要靠工程手段来补足。这三个特征决定了你使用 LLM 时的大部分工程决策比任何概念定义都重要。1.2 Token 和上下文为什么 LLM 又贵又慢Token 是 LLM 处理文本的基本单位可以粗略理解成“半个词”或“一段字符”。英文文本大概 4 个字符一个 Token中文大概 1 到 2 个字一个 Token。你发的 Prompt 和模型返回的结果最后都会换算成 Token 来计费、计算耗时。我在实际项目里算是吃够了 token 计的亏。第一次做文档总结的时候直接把整份 PDF 全文塞给模型上下文窗口撑爆不说处理耗时直接拉到三四十秒成本也哗哗涨。后来才明白上下文越长模型需要注意力计算的规模就越大——这不仅是计费问题更是性能问题。要在成本、速度和效果之间找到平衡点我总结下来有三条硬经验不是所有内容都需要丢给模型。先用规则、正则、关键词把这些内容过滤一遍把真正需要的片段截取出来再送进模型。Prompt 本身也要设计成“精炼指令 焦点内容”禁止把背景介绍、参考案例、多余解释全塞进去。一个 2000 Token 的死长 Prompt 和一个 200 Token 的精炼 Prompt效果可能一样成本却差 10 倍。对重复性任务一定要看是否能让模型用固定模板输出减少回话里的冗余词。模型每多说一句废话都是你的钱。1.3 用“三个点”理解注意力机制Key、Query、Value有些人在讲 Token 的使用时用了“Key 我是谁、Query 我在找什么、Value 我能提供什么”这个比喻。这个说法虽然简化到不够严谨但用来入门注意力机制还挺贴切。这里我用自己的理解把 QKV 的关系说得准一点Query查询向量代表当前 Token 想问的“问题”。Key键向量代表其他所有 Token 的“身份标识”。Value值向量代表其他 Token 真正携带的“内容信息”。注意力机制运行的逻辑是当前 Token 发出 Query跟全序列里每个 Token 的 Key 做相似度计算得出“谁跟我相关、相关多少”的权重再用这个权重去加权求和所有 Value得到一个新的表征。整个过程可以类比成一个检索我带着问题在候选库里找找出最匹配的几条然后把匹配位置的内容融合进来。理解 QKV 对使用 LLM 有实际意义吗有而且不小。你写 Prompt 的时候本质上就是在引导模型构建注意力分布。把关键信息放在显眼位置、把任务指令放在靠前的地方、用明确的“请根据以上内容……”这种重置语其实都是在影响模型后续的注意力权重分布。这些不是玄学是可以观测的现象。2. 模型选型不要跟风按场景挑2.1 闭源 API 和开源模型怎么选现在市面上的 LLM 大体分成两类闭源 API如 OpenAI、Claude、国产的 DeepSeek、Qwen 等和开源权重模型如 Llama、Qwen、GLM 的开放版本。我自己选型时只看两个指标一是任务难度二是成本约束。任务难度低、数据不敏感比如内容分类、信息抽取、简单问答直接用闭源 API。省事、效果好、不用管部署和维护。任务难度高、需要长链路推理比如复杂的 Agent 任务、代码生成、多步规划优先考虑能力更强的闭源模型或顶级开源模型别在 7B 小模型上死磕。数据敏感、需要本地处理比如内部文档、隐私数据、医疗或金融信息就必须考虑部署开源模型到本地或私有云因为数据不出域是刚需。一个容易被忽略的点是“输出格式稳定性”。有些闭源 API 在 JSON 输出、结构化输出上做得很好有几家甚至提供了原生 JSON 模式。如果你要做的是机器对机器的数据交换就不用自己写一堆 prompt 约束格式省下很多调试时间这一点在选型时值得专门盯着看。2.2 榜单可以参考但别迷信 Open LLM Leaderboard很多人选模型时第一反应就是看榜单像 Open LLM Leaderboard 这种公开榜单确实有参考价值。榜单上跑分靠前的模型在特定基准测试上的确表现不错。但我劝你把它当参考就行别当结论。原因有四个第一榜单的评测集是公开的。某些模型用了大量与评测集高度重合的数据参与训练所以评测分数高得离谱一到真实任务就露馅。第二评测集覆盖的任务跟你真实场景往往不一样你可能需要的是中文理解而榜单侧重英文推理你可能需要长文档解析榜单只测短文本。第三同一个模型在不同推理框架、不同量化级别下效果可能相差很大榜单是在标准环境下测的跟你部署环境未必一致。第四分数只有相对意义A 模型 82 分、B 模型 80 分实际使用中可能毫无差别因为方差和随机性在那摆着。我的做法是把榜单当作“初筛”选两到三个候选然后用自己的真实业务数据构造测试集把模型跑一遍自己看效果。这个测试集不要求大十到二十条有代表性的 Case 就够重点是能代表你线上真实场景的输入形态。2.3 特殊任务和垂直模型spatial LLM 这类专业模型值得关注吗除了通用大模型现在也冒出一批面向特定领域的模型比如 Spatial LLM 这类专门处理空间理解任务的模型。它们针对特定数据类型和任务特征做了定向优化在各自领域确实能做到通用模型做不到的事。但是垂直模型也有明显的坑——适用范围窄、更新慢、社区活跃度低。如果你只需要在某个特定领域做小范围长期使用垂直模型可以作为优先候选。如果你的任务既有专业部分又有通用部分建议用“通用模型为主 垂直模型做 API 工具”的组合。比如空间任务可以让通用模型调用 GIS 或空间分析工具而不是直接让模型理解空间坐标数据这样工程上更可控、效果也更稳定。3. 接入与工具链把模型变成可用的服务3.1 先搭一个“统一入口”管理多家模型接入 LLM 的第一件事别急着对应单一的某一家 API。现在主流的模型各有各的长处有的推理强、有的中文好、有的代码强实际项目里几乎不可能只用一家。我建议用“统一入口”的架构把多家模型全部接到同一个网关后面对上层应用暴露统一的接口。具体操作上比较省力的方案是选用现成的模型管理工具或网关像 CC Switch 这类工具就是干这个的。在配置里加入 DeepSeek、Qwen、GLM 等不同模型的 API Key然后通过一个统一的协议格式转发请求。上层业务只认识一个接口不会因为切换模型而改动代码。我当时的配置思路比较简单每个模型对应一个别名比如primary、cheap、local。主要业务走primary批量低成本任务走cheap本地实验走local。哪天发现某个模型效果更好只需要在配置里把别名指向新的模型业务代码完全不用动。这个改造成本极低但收益非常大。3.2 第三方 API 的使用技巧和成本控制当你通过第三方 API 接入模型之后有几个技巧是我实测过非常管用的一是打开流式输出Stream。不流式的话哪怕一句话回复也要等模型全部生成完才返回打开流式输出之后用户可以边看到文字边等体验提升非常大。在代码层面就是给请求加一个streamtrue参数。二是用缓存。部分第三方 API 提供了缓存机制对相同输入的请求会直接返回缓存结果价格低到可以忽略。如果你刚好是做重复性任务比如批量处理原始数据时不断调用相同的配置缓存能帮你省下大部分费用。三是做好请求失败重试和超时控制。第三方 API 不是永远稳定特别是高峰期返回 429 限流或 5xx 错误都很常见。我一般在 SDK 里写一个重试机制收到网络错误或 5xx 就等 1 秒重试重试三次还不行再抛异常收到 4xx 则直接报错不重试因为那是参数或权限问题。四是设置每月预算硬上限。给不同环境设置不同的 Token 预算超了直接熔断宁可任务不跑也不能让账单失控。3.3 LLM 框架到底应该怎么用说到 LLM 框架LangChain 这类工具我身边用的人很多但我的态度很明确框架能帮你在前期加速但别被框架绑架。框架真正的价值有三点一是提供了统一的 Agent、Chain、Tool 抽象减少重复代码二是有大量现成的工具集成比如各种数据源加载器、输出解析器三是社区使用的教程和案例多遇到问题容易找到解决方案。但框架也有代价——抽象层太厚、版本更新频繁、Debug 困难。我见过不少项目明明只有简单需求硬生生引入了 LangChain 全家桶最后出了问题连是哪一层环节出错都找不到。我的经验是小任务直接裸写 API 调用加上一两百行工具代码就够大任务再用框架的抽象能力但只引入需要的那几个类不搞全家桶。另外LLM 框架还有一个隐藏坑它会帮你做很多隐式操作比如自动重试、自动记忆、自动格式化 Prompt。你以为你在调模型其实一直在调框架模型本身的参数都没机会碰到。所以早期做概念验证时最好绕过框架直接拿 SDK 写最小 Demo先把模型本身的边界摸清楚。4. 知识库与检索增强RAG 不是简单“塞资料”4.1 为什么 RAG 能解决知识时效和幻觉问题LLM 最让人头疼的两大问题就是“知识截止”和“幻觉”。RAGRetrieval-Augmented Generation检索增强生成是目前最主流的应对方案。RAG 的核心思路很简单不指望模型记住所有知识而是在模型回答之前先从你自己的知识库里检索出相关片段拿这些片段当作参考资料再让模型基于这些资料生成回答。整个过程分三步先把文档切块、流向向量库用户提问时把问题转成向量在库里做相似度搜索把命中的片段和问题拼在一起一起发送给模型。这个方案跟直接硬塞资料到 Prompt 里相比优势非常明显不需要塞下所有文档只检索出最相关的片段所以 Context 长度可以控制在合理范围。知识库可以随时更新不需要重新训练模型改一版文档进去就代表模型“知道”了这个文档。幻觉也大幅度减少因为模型有了明确的事实依据可以参考。我在实际使用中发现RAG 的瓶颈通常不在模型侧而在检索侧。用的嵌入模型太弱、文档切块太糙、检索结果不准都会让最后的回答效果大打折扣。所以做 RAG 时至少一半的精力要花在检索质量优化上。4.2 GraphRAG 和 LLM Wiki 的落地思路传统的 RAG 是“文档切块-向量检索”的模式它有一个天然缺陷跨文档的关联信息查不到。比如 A 文档提到某个人B 文档只在某句话里用了他名字的一个别名那向量检索很可能把 B 文档漏掉。GraphRAG 解决的就是这个问题。它在 RAG 的基础上增加了一个“知识图谱”的步骤先让 LLM 从文档里抽取实体、实体属性和实体之间的关系构建一张图结构的知识网络。检索的时候既做语义检索也做图谱检索沿着实体之间的关系把相关联的信息一并捞出来。这样能处理一些复杂的“多方关联”问题回答质量确实更高。LLM Wiki 这个概念大家讨论得也不少。它本质上就是把“Wiki”的组织方式引入 LLM 知识库——每个知识主题一个页面页面间有链接和标签形成结构化的知识网络。落地的时候我用过一个很实用的方案用 Markdown 文件组织知识每个文件一个主题文件头写标签和摘要主体写详细内容。通过把文件本身当作 Wiki 页面既能用 Git 做版本管理又能用脚本变成向量库的输入。4.3 本体 Ontology 在 RAG 里的价值原本“LLM”和“Ontology”这两个词很少会被放到一起讨论但最近“RAG GraphRAG LLM Wiki 本体”这个组合逐渐变成了知识库建设的热门方向。Ontology 是知识工程里的概念它定义了一个领域内有哪些概念、概念之间有哪类关系以及约束条件。中文互联网上能搜到好的中文知识本体资源不多但真要落地的时候用“轻量级本体”就够了。比如你做一个招聘知识库可以先定义“候选人、职位、公司、技能”四个概念以及“候选人应聘职位、职位属于公司、候选人掌握技能”三条关系。这相当于给知识库建了一个“骨架”让后续的抽取和检索都更有方向性。我在做知识库实战时是先让 LLM 根据采样的知识点生成一个草稿级本体然后人工修正再把规则灌给每个文档做信息抽取。这套方案比直接扔一堆文档进去建索引的效果好得多虽然前期多花了两三天时间但后续的每次查询质量都稳了很多。5. 从“聊天”到“干活”让 LLM 做判断和写代码5.1 LLM as Judge用模型来评估模型做 LLM 应用的人迟早会遇到一个问题怎么评价这个模型在某个场景下的表现是好是坏人工打分最准但费时费力尤其是迭代频繁的时候根本来不及标注大量样本。LLM as Judge 的思路是直接用另一个语言模型来当裁判给目标模型的输出打分或排序。具体做法是准备一组测试问题和参考答案让目标模型生成回答然后把“问题 参考答案 目标回答”一起丢给裁判模型让它按预设标准打分。我用这个方案跑了几个真实项目有几点经验一是裁判模型的能力不能差至少要比被测模型强一个级别否则裁判自己都可能产生幻觉。二是打分标准必须细化每一条标准都要有明确说明不能只写“回答是否准确”。三是防止位置偏差同时评价多个回答时每次交换顺序跑两遍取平均分。四是要定期抽查抽样让人类专家复核防止评分体系从一开始就跑偏。5.2 用 LLM 生成单元测试单元测试的编写对工程师来说永远是又必要又繁琐的工作。现在用 LLM 帮你写单测已经能从原型走向实际使用了。我的标准流程是把被测函数或模块的源码丢给模型同时提供测试框架的接口文档和项目里已有的几个测试用例作为范例然后让模型生成完整测试文件。中间会用类型的签名约束它只测输入输出不碰内部实现。真正落地时要注意几点生成的测试代码必须遵守项目的测试规范比如变量命名、断言风格模型生成的测试用例覆盖度高但边界条件可能想不全需要人工补生成的测试文件里有时会夹带未定义的 mock 对象跑一遍就挂所以要建一个“LLM 生成测试的专用流水线”让生成完自动跑一遍跑不过的反馈回模型要求修复。实测下来这个流程能节省大概 60% 的测试编写时间剩余的 40% 是修补和完善。5.3 结构化输出和工具调用把 LLM 嵌入业务系统时最难的不是让模型回答得“好”而是让模型回答得“规范”。业务系统需要的是 JSON、SQL、特定代码段而不是一堆自然语言。我的最佳实践是让模型使用“函数调用/工具调用”模式而不是让它自由发挥文字。在这个模式下我给模型定义好工具列表每个工具都包括名称、描述、参数结构。如果模型判断某个问题需要调用工具它会在输出中生成一个“工具调用请求”里面包含工具名和参数。系统侧解析这个请求执行对应工具再把返回值传回模型让它基于返回值继续生成最终答案。这个模式的好处是结构天然稳定不会出现“模型想输出 JSON 但没有遵守格式”的问题。我在接入第三方 API 时就用这个方法每个外部接口封装成一个工具模型只需要按工具列表调用就行。6. 部署与性能本地跑模型也没那么玄6.1 从 ONNX 到端侧部署本地部署 LLM 的需求越来越多特别是企业内部做私有化或者边缘端做推理的时候。ONNXOpen Neural Network Exchange是当前最常用的中间表示格式之一。把模型转成 ONNX 格式有几个非常现实的好处第一格式统一一套代码可以接入 PyTorch、TensorFlow 等多种训练框架导出的模型第二推理引擎ONNX Runtime轻量且跨平台CPU、GPU、移动端都能跑第三可以做一些计算图和量化方面的优化比直接跑原始模型更快。部署的路径大概是三步先在原始框架里导出 ONNX 文件然后用onnxruntime写推理代码最后针对目标硬件做优化。如果目标是 GPU用 CUDA 后端目标是 CPU开启线程数和指令集优化目标是移动端直接转成 INT8 量化。我这里插一句ONNX 部署第一个容易踩坑的地方是动态轴的定义特别是序列长度不定的时候必须把动态轴和固定轴区分清楚否则推理时偶尔报错。6.2 显存与推理优化AscendCL 内存使用注意事项如果你用的是国产 NPU 芯片比如昇腾就得直接和 AscendCL 打交道了。AscendCL 是昇腾平台的编程接口原理上跟 CUDA 类似。我在用 AscendCL 部署模型时主要注意三件事第一内存分配要用它自己的内存管理接口别用常规的 C/C 的 malloc 混着用第二输入输出的张量要拷贝到指定内存空间否则推理时会出现诡异报错第三模型加载之后中间激活值会占用大量内存要做细粒度的内存复用规划。如果显存紧张除了用 INT8 量化还可以考虑用算子融合和内存复用把两个算子的输入输出合并到同一块缓冲省掉中间的拷贝开销。6.3 生产环境里的调优经验把 LLM 部署到生产环境之后性能调优就是持续的活。我实测有效的调优顺序是这样的第一步把模型量化到合适的精度。对大多数任务来说INT8 就够了FP16 是性价比最低但最稳的选择INT4 适合极端低资源场景但效果打折。第二步开 KV Cache。KV Cache 是生成式推理的基本优化手段把历史 Token 的计算结果缓存下来避免每次生成新 Token 都重新算全部注意力。现在主流推理框架都默认开启。第三步按并发做动态批处理。多个请求同时到达时把它们合并到同一个 Batch 里推理能显著提高吞吐量。第四步加显存空闲监控。本地部署最怕 OOM一崩就是连锁反应。我在监控面板上加了显存占用曲线一旦发现接近临界值自动触发降低并发保护。第五步提前压测。部署上线之前用脚本模拟实际请求的并发量和输入长度测出模型能支撑的最大并发和单请求最大耗时压出边界值写进服务配置。7. 常见问题速查这些坑我替你踩过了问题表现可能原因排查方法解决方案请求一直报错provider rejected the request schema or tool payload工具调用的参数结构不符合预期打印实际请求的 schema 内容与模型要求的格式对比重新按接口文档构造工具定义确认所有字段名和类型一致同时接入多个模型效果忽好忽坏各家模型的指令理解风格不同固定测试集分别跑一遍找出差异不同模型使用不同 Prompt 模板而非统一模板模型回答得很长但没内容Prompt 缺乏输出长度约束检查生成的最大 Token 数在请求参数中限制max_tokens并在 Prompt 中提示“只输出结论”JSON 输出偶尔解析失败模型返回了 JSON 之外的内容打印原始输出看多了什么改用工具调用模式或加一条“只输出 JSON不要解释”的指令RAG 检索结果相关性差切块太粗或嵌入模型太弱检查 Top-K 命中结果缩小切块粒度、换更强的嵌入模型、加一层相似度阈值过滤本地部署时显存不足爆炸模型过大或 KV Cache 占用过高查看推理日志和显存曲线换量化模型、减小 Batch、关闭无用的算子优化模型输出幻觉严重缺少事实依据检查是否接入了 RAG 或工具需要用 RAG 提供参考材料尽量不用模型自由发挥知识这些坑里最值得多说两句的是第一个。provider rejected the request schema or tool payload这个错误我遇到了四五次每次都是同一个根因工具调用的参数 schema 和模型要求的格式对不上。常见原因是多了一个必填项没给、某个字段嵌套层级不对、或者是类型定义和模型参数要求不一致。排查这个错误的方法是直接打印发送给 provider 的完整请求结构逐字段对比文档。另外还要考虑一个细节不同的模型对工具调用支持的程度不同。有些模型对工具调用支持得很完整但有些模型的工具定义要求非常严格稍有偏差就会报这个错误。所以接入新模型时先用一个最小化的工具定义做冒烟测试确认通了之后再逐步加复杂度。还有一个容易被忽略的问题是多模型模板差异。不同模型的指令理解模式很不一样比如有的模型对 step-by-step 特别敏感有的模型更适合直接用一句话下指令。硬套一个 Prompt 模板效果可能像过山车一样忽高忽低。所以建议在项目开始时就建立一个“模型档案”记录每个模型在不同任务上的最佳 Prompt 写法。最后分享一点体会我折腾 LLM 这大半年最大的感受是模型能力本身已经不是瓶颈如何把模型变成稳定、可控、可观测的工具才是真正的工程挑战。每次遇到问题回归到“Token 怎么花、上下文怎么组织、结果怎么校验”这三个基本问题上基本都能找到答案。别迷信一篇文章就能学会所有东西自己拿着一个小任务按文中的链路走一遍踩几个坑再复盘比看一百篇总结都强。如果你现在正在做某个具体的 LLM 项目我建议你从小范围的一个环节做起把输入输出扎扎实实跑稳定再逐步扩大使用面这条路走下来最顺。