先说说我写这篇东西的起因。这两年大模型相关的词一天一个样身边总有人拿着API Key问我LLM到底怎么用我一开始以为他们问的是调用方法后来发现真正的问题根本不在调用而在不知道该拿它解决什么问题、怎么判断它做得好不好、出了问题找谁背锅。这个标题看起来是个入门问题但实际上牵扯到模型选型、Token机制、部署方案、业务接入架构、效果评测一整条链路。这篇文章我不打算教你怎么写Prompt那东西网上到处都是。我想聊的是LLM从能聊天到真正进入业务这段时间里我在一线反复踩过的坑、总结出的方法以及所有关键决策背后的理由。无论你是刚上手的技术负责人还是已经在用LLM但总觉得哪里不对劲的开发者这篇应该能帮你把思路理顺。1. 选模型先于调Prompt用榜单和场景锁定基座很多人的习惯是先把某个模型接进来然后花大量时间去调Prompt效果不行就怪自己咒语没念好。这个顺序其实是错的。Prompt能优化的是表达方式但模型的出身、能力边界、知识截止时间、推理风格这些东西是Prompt改不掉的。正确顺序应该是先根据业务场景选好基座模型再针对基座做提示词工程。1.1 为什么先从榜单看起从Open LLM Leaderboard到实际业务的换算网上有大把榜单可以参考Open LLM Leaderboard这类公开榜单确实是个不错的起点。它会把模型按综合分排个序看起来很简单但我建议你千万别直接把榜首模型搬进业务。原因很简单榜单测的是通用能力你的业务要的是特定能力。我一般会把榜单当筛子用而不是当结论用。第一步在榜单里筛出几个参数规模合适、许可协议允许商用、社区活跃度足够的候选模型。第二步用我自己的业务数据去测。注意这里说的测试不是跑一两个案例看感觉而是准备一套固定题目量化打分。很多团队忽略了这个环节结果模型上线后才发现常识问答很强但一碰到你业务里的专业术语就胡说八道。1.2 按场景拆解需求通用对话、长文档、结构化输出对模型的要求完全不同我自己在做选型时会先把需求拆成几个维度。如果是客服、闲聊、通用知识问答考察重点就是语言流畅度和知识广度这类需求对模型大小不敏感小参数模型也能表现很好。如果是长文档分析、合同审查、论文总结那么上下文长度和长文本中信息定位能力就是第一优先级很多小模型虽然宣传支持长上下文实际用起来中段信息会丢。如果是做结构化输出、信息抽取、工具调用那你得重点看模型的指令遵循能力和输出格式稳定性。这几个维度不是并列的它们之间有优先级。核心原则是先满足硬性约束再看综合分。什么叫硬性约束比如你的业务要求处理100页以上的PDF那上下文长度就是硬性约束综合分再高塞不进去就是不行。再比如你的下游系统需要模型严格输出JSON格式那格式稳定性就是硬性约束你总不能靠Prompt让一个格式能力弱的模型天天碰运气。1.3 一个小测试集定生死我的模型选型实测方法具体怎么测我说一个我自己用得比较顺的方法。准备20条真实业务输入覆盖正常情况、边界情况、错误输入三类。正常情况大概12条边界情况5条比如超长文本截断、空字段、同义表达。错误输入3条比如完全无关的内容、恶意输入、格式错误。然后定义3个打分维度回答准确率、格式规范率、无效调用率。准确率很好理解结果对不对。格式规范率指的是模型输出能不能被下游直接解析这个经常被忽略但它决定了你要不要写一堆清洗代码。无效调用率更关键它统计模型在哪些输入下直接摆烂、答非所问或者抛出异常。这三个数字出来以后候选模型的高低其实就一目了然了。我见过太多团队选了个综合分最高的模型结果无效调用率超高每次都要靠外部兜底逻辑去补补到最后比换模型的成本还高。2. Token不只是计费单位key/query/value才是连接业务的那根线如果要我说LLM使用中最被低估的概念那一定是Token。大多数人对Token的认知停留在计费单位上每次调用都在心疼钱。但Token的深层含义远不止价格它决定了模型怎么理解你的输入、怎么组织输出以及你的业务应该怎么设计交互逻辑。2.1 把Token拆成我是谁、我在找什么、我能提供什么有一个理解Token的方法我觉得特别适合给团队做培训就是把Token的语义角色拆成三个问题key、query和value。key回答的是我是谁也就是这个Token在当前上下文里代表什么实体、什么身份、什么状态。query回答的是我在找什么也就是这段文本的意图和指向。value回答的是我能提供什么也就是模型基于这个Token能够回忆起和生成什么内容。我举个具体业务例子。假设你做一个企业知识库问答系统用户问上季度的销售数据怎么样。这里销售数据就是一个key模型需要识别出它指的是哪个表、哪个维度、哪个时间范围。怎么样就是query模型需要理解用户的真实诉求是总结、对比还是异常分析。而最终生成的华东区增长了15%华北区下降了3%就是value。这个拆解能帮你干什么它能帮你设计Prompt结构。既然Token天然可以分为key、query、value三种语义角色那你在写Prompt时就应该把每个部分的目的说清楚让模型更容易进入正确的语义角色。2.2 上下文长度、计费与性能三者在Token维度上的博弈Token数量直接影响三个东西上下文窗口、调用成本、响应速度。这三者是个三角关系你很难同时占满。上下文窗口决定你一次能塞多少内容。但注意窗口长不代表模型真的都能用到很多模型在长上下文中会出现迷失在中间的问题。你喂1万字进去模型往往只记得开头和结尾中间内容会被选择性忽略。计费上输入Token和输出Token往往价格不一样而且输入Token里有一个隐含成本你每次调用都要把历史对话、系统提示词、参考文档统统重发一遍这部分钱是隐性的很多人算成本时只算输出Token结果月底账单吓一跳。性能方面Token越多首字延迟越高吞吐越差。尤其是做流式输出时长上下文的处理时间会明显拖慢用户体验。所以我的建议是不要追求把所有东西都塞进上下文而要追求把必要的东西精炼后塞进上下文。你可以给上下文分一个优先级。系统提示词和用户输入是最高优先级必须保留。参考文档不是全部要用只提取与当前问题相关的片段。历史对话不是越长越好超过一定轮数就该做摘要压缩。2.3 控制Token消耗的实操手段压缩、缓存与结构化输出控制Token消耗有三类手段从易到难排列。第一是压缩。输入侧压缩指的是在做RAG时不要一股脑把检索到的整篇文章都塞进Prompt而是先做一次摘要或抽取把有效信息提炼出来。输出侧压缩指的是给模型设定输出格式和长度限制比如max_tokens设小一点。有人担心设置max_tokens会截断输出这个担心是对的所以你需要让模型先给结论再给过程把最重要的内容放前面。第二是缓存。如果你的业务里有一段固定不变的系统提示词或者用户经常问相同的问题可以考虑做语义缓存。简单说就是把输入内容做向量化计算相似度如果命中缓存就直接返回之前的结果不走模型调用。据我实测在客服、FAQ场景中语义缓存的命中率可以达到三成以上成本直接打七折响应时间从秒级变成毫秒级。第三是结构化输出。让模型以JSON或者固定模板输出表面上看起来更啰嗦实际上反而省Token。因为结构化输出能减少模型自由发挥的空间避免它生成一堆你没用到的话。比如你要抽取客户信息直接要求输出固定字段的JSON比让它自由写一段分析要省得多。结构化输出的另一个好处是方便你做后续处理不用写正则硬抠。3. 调用与部署API、开源框架与本地推理的取舍说到LLM的使用方法绕不开一个关键决策用商业API还是自己部署开源模型这俩没有孰优孰劣只有适不适合。但我在实际项目里发现很多团队在这个选择上犯了方向性错误要么一开始就图省事全上API结果业务量大了成本失控要么迷信自部署结果运维成本远超API费用。3.1 API派和部署派的核心差异先说API派。优点非常明显上手快、效果有保障、不用管显卡和推理优化。像市面上主流的几个大模型API综合能力通常强于开源模型尤其在小样本理解和复杂推理上。缺点也很明显一是费用随调用量线性增长业务一旦跑起来账单可能比服务器还贵二是数据隐私敏感数据出域这件事在很多行业是合规红线三是厂商依赖一旦上游接口调整或者限流你连还手的余地都没有。部署派用的是开源模型加自己的推理框架。最大的优势是边际成本低固定成本投完之后调用越多单次成本越便宜。数据完全在自己手里合规上更容易交代。但缺点同样扎心需要GPU资源需要懂推理优化的人需要处理并发、显存、模型版本升级等一系列问题。而且开源模型的能力天花板确实比头部商业模型低一截尤其在中文复杂指令和多轮对话上。3.2 本地推理的常见路径从ONNX到量化如果决定自部署我建议你认真研究一下ONNX Runtime和量化这两个东西。ONNX是一种跨平台的模型格式把模型转换成ONNX格式后可以在不同硬件和框架上统一推理。我之前试过把一个开源模型转成ONNX再用ONNX Runtime做CPU推理。老实说CPU推理速度确实不如GPU但胜在部署简单、依赖少、资源占用低适合一些对延迟不敏感的内部工具。如果追求性能那就得上GPU加量化。量化就是把模型的权重从高精度压缩到低精度。常见的路线是INT8和INT4。量化后模型体积能缩小到原来的四分之一甚至更少显存占用大幅下降推理速度明显提升。代价是精度轻微下降但在业务场景里这点精度损失往往可以忽略。我实测过一个7B级别的模型INT4量化之后显存从16G级别降到6G左右原来根本跑不动的机器也能凑合跑了。选哪种部署方式我建议你按两个维度判断。一是延迟要求如果交互要求实时就得上GPU推理如果批处理能接受几秒甚至几十秒的输出CPU或者低配GPU完全够用。二是团队运维能力部署一个模型不是跑起来就完了还要监控、还要调优、还要处理训练框架升级带来的兼容性问题没有运维能力的团队硬上自部署会是灾难。3.3 部署中最容易忽略的并发与显存问题部署踩坑里我见过最多的问题是只测单条延迟不测并发。模型推理和普通Web服务完全不同GPU显存是共享的并发一高显存不够用就会频繁触发换入换出延迟从300毫秒直接飙到3秒。这里有一个粗略估算方法。先测出单请求占用的显存量再用显存总量除以单请求占用得到最大并发数。然后看业务峰值QPS如果峰值QPS大于最大并发数那排队是必然的。这时你有三个选择换更小参数的模型、上量化、加机器。别想着靠排队解决用户体验一差你再怎么优化Prompt都救不回来。另一个容易忽略的点是批量推理。如果你的业务对实时性要求不高可以把多条请求拼成一个批次喂给模型推理框架会自动做padding和并行计算吞吐量能翻好几倍。这个优化做起来不难但收益非常明显。4. 把LLM接入业务网关、工作流与失败兜底模型选好了、部署方案也定了下一步是把LLM接进业务。这是整个链路里最容易被低估的一环。很多人都以为接个模型就是发个HTTP请求、解析一下返回结果但实际上LLM调用天然具备高延迟、高失败率、输出不确定性这些特点如果不加一层设计它会成为整个系统里最脆弱的组件。4.1 为什么业务侧需要一个LLM网关LLM网关这个概念这两年很火但我更愿意把它看作业务与模型之间的缓冲层。它的核心职责有四个。第一是统一入口。如果你的业务里接了多个模型比如主模型用A厂商备用模型用B厂商某个子任务用开源小模型那业务方不应该各自去对接不同的API协议和鉴权方式。网关把这一切统一掉业务只需要调用网关的接口网关负责路由到具体模型。第二是流量治理。模型API的限流是常态尤其是并发一高上游会返回429或者超时。网关可以做多级限流、排队、重试。第三是成本管控。网关可以按业务线、按用户维度去统计Token消耗甚至做预算上限的控制。没有网关你根本说不清哪条业务线烧了多少钱。第四是质量监控。在网关卡一道把所有请求和响应记录下来后续做评测、做badcase分析才有数据来源。4.2 请求流程设计重试、限流、熔断与降级LLM请求流程的设计我建议你把它当成一个分布式系统来打磨。先说重试。模型调用偶尔失败很正常网络抖动、上游超时、限流都会导致失败。但要小心不是所有失败都值得重试。上游返回4xx这类客户端错误重试没用再试还是报错。只有5xx、超时、限流这类问题重试才有意义。重试还要考虑退避策略从几百毫秒开始按倍数增加防止雪崩。再说熔断。如果某个模型连续失败超过阈值应该直接把它降级为不可用走备用模型或者返回兜底结果。熔断的关键是阈值不要设得太死比如最近1分钟内错误率超过30%就熔断10秒这期间让系统缓一缓避免对上游做无效的重复请求。降级策略在不同的业务里差别很大。有的业务可以接受模型不可用时返回一个固定提示有的业务需要降级到规则引擎还有的业务可以排队等模型恢复。我建议你在设计阶段就把降级预案写清楚而不是等线上出了问题再拍脑袋。4.3 可观测性记录每一次模型调用的输入输出这是我最想强调的一点。模型是不确定系统你没法像调普通接口那样靠日志分析问题。唯一能依靠的就是完整的调用记录。一个合格的模型调用日志至少应该包含这些字段请求时间、耗时、输入内容、输出内容、Token用量、模型版本、是否命中缓存、错误信息。有了这些数据你才能回答几个关键问题模型输出质量为什么变差了是不是上游模型偷偷换了版本某个具体用户的问题为什么老出错Token成本为什么突然涨了实际做的时候我见过有人把输入输出原样打印到日志里这在内部工具里问题不大但如果涉及C端用户隐私就必须做脱敏。还有一个细节是采样的比例超高频场景下全量记录日志本身就有成本可以设置按百分比采样但至少要保证每天的样本量覆盖到所有类型的请求。5. LLM as Judge用模型评测模型的正确姿势最后一个话题我想聊聊评测。很多人把LLM接入业务之后最大的困惑不是跑不起来而是怎么知道它好不好。人工评测太慢客观指标在多轮对话、内容生成这类开放性任务上又不好用。于是就有了LLM as Judge这种思路——用一个能力更强的模型去评判另一个模型的输出质量。5.1 什么是LLM作为评判者它解决了什么问题其实就是让模型当裁判。你给定一个打分标准把候选答案和标准答案喂给Judge模型让它按维度打分或者做对比排序。这个方法能解决三个问题。一是规模化人工评1000条要一个团队干一天Judge模型几分钟就处理完了。二是标准化模型打分的标准相对一致不会像人工那样前后尺度不一。三是可追溯每次评分都能留下推理依据你回头看badcase时能知道Judge是因为什么给的差评。但Judge也不是万能的。它最大的风险是偏见——有些模型天生偏好冗长答案有些偏好结构化的答案还有些跟着顺序走把排后面的答案天然打低分。这些偏见如果不处理评测结果就会失真。5.2 评测集的构造与评价维度构造评测集我有几个经验。第一评测集必须从真实业务样本里抽而不是自己编。自己编的题再难也脱离真实分布测出来的分不能代表线上效果。第二评测集要有陷阱题。比如包含歧义问题的、需要模型主动追问的、包含错误前提的。这些陷阱题最能暴露模型的真实水平。第三定期更新。业务在变用户的问题在变评测集也需要持续迭代否则模型越训越好、你的评测却停在过去。评价维度方面我一般会关注三到五个维度。准确性答案是否与标准答案一致。完整性是否漏掉了必要信息。格式合规率是否遵循输出格式要求。安全性是否对危险输入做了拒绝。还有稳定性同样的输入跑多次输出是否一致。每个维度单独打分最后按业务权重合成总分。这个合成的权重也需要从业务出发比如客服场景完整性和格式合规率权重高数据抽取场景准确性和稳定性权重高。5.3 当Judge不可信校验机制与人工抽检Judge模型给出的分数你不能盲目信任。我至少会做三道校验。第一道标准答案对照。对客观性强的任务Judge的评分要和标准答案做交叉验证。如果Judge给了高分但实际答案完全跑偏那就说明Judge本身有问题需要换更强的模型或者调整评测方式。第二道人工抽检。哪怕全流程自动化我建议每批次至少抽5%到10%的结果让真人复核用人工的尺度去校准打分标准的漂移。第三道连续一致性检测。同一个评测集跑两遍看Judge给出的分差有多大。如果同一个模型跑两次评测分差很大评测方案本身就不稳定得分没有参考价值。我自己的体会是LLM as Judge这套方法当做快速筛选器非常好用但最终模型能不能上线还是要人工再过一遍关键样本。把机器评测和人工抽检结合起来才能既享受规模化评测的效率又守得住质量的底线。最后分享一个使用LLM的小技巧。无论你用的是哪个模型、哪套框架建议你从第一天起就给每一条模型调用打上版本号。模型的升级、Prompt的调整、参数的改动都要和调用日志里的版本号对应起来。这样一旦线上效果出现波动你能用最快的速度定位是不是某个版本变更导致的。我在项目里靠这个习惯少加了好几次班凡是上线过LLM业务的团队迟早都会栽在不知道哪次改动引起的效果变化上。提前搞一套版本和评测的对应机制能帮你省掉大量排查问题的时间。