1. 这不是又一篇“模型介绍”——它是一份给实践者的LLM认知地图你点开这篇大概率不是想听“大语言模型是基于Transformer架构的自回归概率模型”这种教科书定义。我干了十年AI工程落地从最早用LSTM搭客服机器人到后来在金融风控里调BERT微调再到这两年天天和LangChain、LlamaIndex、Ollama打交道踩过的坑比读过的论文还多。今天这篇就是把“Large Language Models”这个被讲烂了的词真正掰开、揉碎、还原成你在LangChain项目里每天要面对的具体对象、真实约束和可操作选择。核心关键词就三个LangChain、LLM、模型选型——它们不是孤立概念而是一条链路上环环相扣的决策节点。你用LangChain写一个RAG应用最后卡住的地方90%不是提示词写得不够花哨而是你选的那个模型根本扛不住你的文档chunk长度或者它的上下文窗口在流式输出时莫名其妙截断你调通了一个本地部署的Qwen2-7B结果发现它对中文法律条款的推理准确率还不如GPT-3.5-turbo不是模型不行是你没意识到它的训练语料截止时间是2023年中而你查的司法解释是2024年新出的。所以这篇不讲原理推导只讲你打开LangChain文档、新建一个LLM实例时鼠标悬停在model_name参数上那一刻脑子里该闪过的所有问题这个模型到底能塞多少字它记性有多好它是不是真懂你写的中文指令它在你那台3090显卡上跑起来会不会直接OOM它返回的JSON格式稳不稳定——这些才是LangChain 101 Part 2ab真正要告诉你的“所有你需要知道的”。适合谁适合已经写过第一个from langchain.llms import OpenAI但开始怀疑自己是不是在用错工具的开发者适合被产品经理一句“我们要上本地大模型”砸懵、正在服务器上反复pip install又pip uninstall的运维同学也适合技术负责人在采购GPU之前先搞清楚为什么同样标着“7B参数”的两个模型实际部署成本能差三倍。2. 模型不是黑盒而是带说明书的精密仪器拆解LLM的五大实操维度在LangChain里LLM是一个抽象基类但你真正打交道的永远是它的子类实例OpenAI、ChatOpenAI、Ollama、HuggingFacePipeline、LlamaCpp……每个子类背后都对应着一个或多个具体模型而每个模型都必须从五个硬指标去评估它是否适配你的场景。这不是理论考试是上线前的必检清单。2.1 维度一上下文长度Context Length——你的“记忆容量”天花板这是所有新手最容易忽略、却最致命的维度。LangChain的invoke()方法传入一个字符串你以为它全吃了错。模型有明确的输入token上限超了直接报错或静默截断。以最常用的gpt-3.5-turbo为例官方标称16K tokens但实测中当你拼接进一个2000字的PDF摘要3个历史对话轮次当前用户提问很容易就撞到15800 token的墙。更麻烦的是不同模型的“token计数器”还不一样llama.cpp用的是Byte Pair Encoding (BPE)HuggingFace的transformers库默认用的是AutoTokenizer而OpenAI API返回的usage字段里的prompt_tokens是它自己的一套分词逻辑。我吃过一次大亏——用transformers本地加载Qwen2-7Btokenizer算出来prompt是8500 tokens心想离128K还远结果llama.cpp一跑直接context overflow。后来才发现Qwen2用的是QwenTokenizer其BPE规则和transformers默认的LlamaTokenizer不兼容同一个中文句子前者切出1200 tokens后者切出980。解决方案别信文档写的数字信你自己的实测。写个脚本用目标模型对应的tokenizer把你的典型输入比如最长的文档chunk最长的system prompt最长的user query喂进去看len(tokenizer.encode(text))是多少。LangChain里有个隐藏技巧llm.get_num_tokens(text)方法它会自动调用底层tokenizer比你自己手算靠谱。记住你的真实可用上下文 模型标称长度 - 你预留的输出空间一般留512-1024 tokens给模型生成答案。如果你的应用需要处理整本《民法典》的检索128K是底线7B模型基本告别如果只是客服FAQ问答4K足够还能省下70%的GPU显存。2.2 维度二推理能力与领域专精Reasoning Specialization——它不是“通用”而是“特定场景最优”“大模型很聪明”是个巨大误解。它聪明但聪明得非常具体。gpt-4-turbo在数学推理、代码生成上碾压Claude-3-haiku但后者在长文本摘要、法律文书分析上对中文条款的语义捕捉反而更准。这背后是训练数据和SFT监督微调阶段的差异。Qwen2-72B在阿里巴巴内部大量电商客服对话上微调过你拿它去写科研论文效果可能不如DeepSeek-V2——后者在arXiv论文数据上做过强化。LangChain本身不解决这个问题但它放大了这个问题你用RetrievalQA链从向量库里捞出10个相关段落拼成一个超长prompt喂给LLM如果这个LLM没在类似法律/医疗/金融语料上微调过它大概率会把专业术语当普通词汇处理给出似是而非的答案。我的经验是做垂直领域应用必须放弃“找一个最强通用模型”的幻想转而寻找“在你领域数据上微调过”的模型。Hugging Face Model Hub上搜legal-llm、medical-llm、finance-llm会看到一堆Lawyer-LLaMA、Med-PaLM的变体。别被名字唬住重点看它的README.md里写的训练数据来源是不是真的用了最高人民法院公报案例是不是包含了近五年国家药监局的审评报告我去年做一个医疗器械注册咨询Bot试了Qwen1.5-7B效果平平换成MedAlpaca-13B基于PubMed和FDA文档微调同样的prompt模板回答准确率从62%跳到89%。关键不是参数大小而是数据血缘。LangChain的HuggingFaceEndpoint类支持直接加载HF上的模型但注意很多领域模型是text-generation类型不是text2text-generation调用方式略有不同稍后实操部分会细说。2.3 维度三输出稳定性与格式控制Output Stability Format Control——你敢不敢让它返回JSON这是LangChain工作流能否自动化的生死线。你写一个Agent让它调用工具返回结果必须是严格JSON里面包含tool_name和tool_input。如果LLM返回的是{tool_name: search, tool_input: latest iPhone specs}万事大吉如果它返回Sure! Ill search for the latest iPhone specs. Heres the JSON: {tool_name: search, tool_input: latest iPhone specs}整个链就崩了——因为json.loads()解析不了前面那句废话。gpt-3.5-turbo和gpt-4-turbo在OpenAI API里提供了response_format{type: json_object}参数强制输出JSON且校验schema这是目前最稳的方案。但本地模型呢Llama-3-8B-Instruct通过在system prompt里加|eot_id|和严格的few-shot示例能达到95%的JSON合规率而老一代的LLaMA-2-13B-Chat即使加了10个JSON示例仍有约15%的概率在长输出时“忘形”冒出一句自然语言解释。我的实操心得对格式要求严苛的场景如Agent、结构化抽取优先选原生支持guided decoding的模型比如Phi-3-mini-4k-instruct它内置了JSON Schema引导比靠prompt硬凑可靠得多。LangChain的ChatModel接口里model_kwargs可以传guided_json参数但前提是底层模型支持。怎么判断看模型的README.md有没有提到JSON mode或guided generation或者直接在Hugging Face Inference API上试跑一个JSON请求。别省这五分钟线上故障的代价是几小时。2.4 维度四部署成本与硬件门槛Deployment Cost Hardware Barrier——3090能跑什么A100该配几块参数量B不是唯一指标。Qwen2-7B标称70亿参数但量化后GGUF Q4_K_M格式仅需约4GB显存一块309024GB能同时跑3个实例做负载均衡而DeepSeek-Coder-33B330亿参数Q4量化后也要18GB3090只能勉强跑一个且推理速度慢一倍。更隐蔽的成本是“内存带宽瓶颈”Llama-3-70B在A100 80GB上跑显存够但PCIe带宽成了短板batch_size1时延迟尚可一旦并发请求增多显存没爆但延迟飙升到5秒以上。LangChain里llm.invoke()默认是同步阻塞高并发下一个慢请求会拖垮整个服务。解决方案有两个层面一是模型侧选对量化格式。GGUFllama.cpp用比GGML更优Q4_K_M比Q5_K_S在精度和体积上更平衡二是LangChain侧用AsyncLLMChain或RunnableWithFallbacks给慢模型配个快速fallback比如用Phi-3-mini先给个草稿答案。我见过最痛的案例某客户坚持要用gpt-4-32k做实时会议纪要结果发现API调用费用一个月超5万换成本地Qwen2-72BvLLM推理引擎硬件投入20万月成本降到3千。成本不只是钱更是延迟、吞吐、运维复杂度。别被“72B”吓住先算显存、再算带宽、最后算你的SLA比如用户能忍受的最大响应时间是2秒还是10秒。2.5 维度五许可协议与商用风险License Commercial Risk——开源不等于免费免费不等于无风险这是法律和商务团队最关心但工程师最容易踩雷的点。Llama-3系列是Meta的Llama 3 Community License允许商用但禁止用它来训练竞品模型Qwen2是阿里云的Tongyi Qwen License明确允许商用、可修改、可分发但要求显著声明“Powered by Tongyi Qwen”而Falcon-180B是Apache 2.0最宽松。但注意许可证管的是模型权重文件.bin、.safetensors不管你的LangChain应用代码。更大的坑在数据上你用LangChaingpt-3.5-turbo构建一个内部知识库员工上传的PDF里含有客户合同扫描件这些数据会不会被OpenAI用于模型训练OpenAI的Enterprise协议明确说不会但Free或Pay-as-you-go账户默认是可能的。我的建议涉及敏感数据财务、HR、客户信息一律走私有化部署用Ollama拉取llama3:8b或qwen2:7b数据不出内网。LangChain的Ollama类配置极其简单base_urlhttp://localhost:11434一行搞定比折腾transformersaccelerate省心太多。许可证不是玄学是上线前必须和法务过一遍的checklist。我附一张常用模型许可对比表帮你一眼看清红线在哪模型名称许可证类型是否允许商用是否允许修改权重是否要求署名关键限制Llama-3-8BLlama 3 Community License✅ 是✅ 是❌ 否禁止用于训练竞品模型Qwen2-7BTongyi Qwen License✅ 是✅ 是✅ 是需显著声明“Powered by Tongyi Qwen”Falcon-180BApache 2.0✅ 是✅ 是✅ 是无实质限制最宽松Mixtral-8x7BApache 2.0✅ 是✅ 是✅ 是同上但MoE架构对硬件要求高gpt-3.5-turboOpenAI Terms✅ 是需付费❌ 否❌ 否数据可能被用于改进模型非Enterprise版提示不要只看模型主页的“License”标签务必点开LICENSE文件原文。很多模型在README.md里写“MIT License”但LICENSE文件里藏着一行小字“except for the weights, which are under Custom License”。3. LangChain里调用LLM的七种姿势从API到本地哪条路最稳知道了模型的五大维度下一步就是把它接入LangChain。别以为llm ChatOpenAI(model_namegpt-3.5-turbo)是唯一正解。根据你的环境、预算、安全要求有七条技术路径每条都有明确的适用场景和坑。3.1 姿势一OpenAI官方API——最快上手但最不可控这是LangChain文档首页的例子也是新手第一站。优点是快API key一贴llm.invoke(hello)秒回。但“快”背后是三个硬伤。第一网络依赖。我司内网策略严格所有外网API调用需经代理而OpenAI域名api.openai.com常被误判为高风险白名单申请流程长达一周。第二成本黑洞。gpt-3.5-turbo按token计费但LangChain的ChatPromptTemplate会自动把system message、human message、ai message拼成一个大字符串你看到的prompt_tokens可能比你预估的多30%因为模板里的换行符、空格、XML标签都被算进去了。第三调试困难。API返回的是ChatResult对象但你想看模型到底收到了什么原始prompt得开verboseTrue日志里全是base64编码的调试信息。我的补救方案写一个OpenAIWrapper类继承ChatOpenAI重写_generate方法在发送请求前用self._get_system_message()和self._get_human_message()把最终prompt打印出来格式化成纯文本方便你复制粘贴到OpenAI Playground里复现问题。这招救了我至少十次线上事故。3.2 姿势二Azure OpenAI Service——企业级的“可控版OpenAI”如果你的公司已经采购了Microsoft Azure这条路是首选。它本质是OpenAI模型的私有化镜像API接口完全兼容但endpoint是https://YOUR-RESOURCE.openai.azure.com/key是Azure密钥。最大优势是数据不出Azure云且可配置VNet私有链接彻底规避公网暴露。LangChain调用只需改两处openai_api_base指向你的Azure endpointopenai_api_version指定API版本如2023-05-15。但注意一个巨坑Azure OpenAI的model_name参数填的不是gpt-3.5-turbo而是你在Azure门户里部署时起的名字比如my-gpt35-deployment。很多人卡在这里死活报404 Not Found翻遍文档才明白model_name是部署名不是模型ID。另一个坑是token计数Azure的usage字段里prompt_tokens和completion_tokens是准确的但total_tokens有时会少算建议自己用tiktoken库独立计算避免账单纠纷。3.3 姿势三Ollama——本地部署的“瑞士军刀”小白友好度满分这是我目前给所有新项目推荐的默认方案。Ollama是一个命令行工具ollama run llama3:8b30秒内一个8B模型就在本地跑起来了LangChain用Ollama类对接三行代码from langchain_community.llms import Ollama llm Ollama( modelllama3:8b, base_urlhttp://localhost:11434, temperature0.3 )它之所以稳是因为它把模型加载、量化、推理、HTTP服务全包了。你不用管CUDA版本、不用装llama.cpp、不用编译transformers。但Ollama不是万能的。第一它只支持GGUF格式模型而Hugging Face上大部分模型是safetensors或bin得先用llama.cpp的convert.py脚本转换这个过程对新手不友好。第二Ollama的streamTrue流式输出在LangChain的llm.stream()里有时会卡在第一个token原因是Ollama的HTTP chunked encoding和LangChain的AsyncIterator不完全兼容。我的fix在Ollama初始化时加num_ctx4096显式设置上下文并确保Ollama服务是最新版ollama update。第三Ollama默认不开启GPU加速得在启动时加--gpu参数但Mac M系列芯片用户要注意Ollama对Metal的支持还在迭代M2 Max跑llama3:70b可能比CPU还慢这时得切回llama.cpp手动编译。3.4 姿势四llama.cpp LangChain——极致性能但需要动手能力当你需要榨干GPU每一滴算力或者必须跑在没有Python环境的嵌入式设备上llama.cpp是终极答案。它用C编写支持AVX、AVX2、CUDA、Metal等所有后端推理速度是Python生态的3-5倍。LangChain通过LlamaCpp类对接核心是model_path参数指向你的.gguf文件。难点在于编译和参数调优。llama.cpp的main程序有几十个编译选项-DLLAMA_CUDAon开启CUDA-DLLAMA_METALon开启Metal但编译失败是家常便饭。我的经验别自己编用llama.cpp官方Docker镜像docker run -it -v $(pwd):/models ghcr.io/ggerganov/llama.cpp:full然后在容器里跑./main -m /models/llama3.Q4_K_M.gguf -p Hello验证模型能跑再回到LangChain。LlamaCpp类的n_gpu_layers参数最关键设为1000表示把所有层都扔进GPU设为0全CPU跑。但别盲目设高我的3090有24GB显存llama3:8b设n_gpu_layers40就满了再多会OOM。怎么知道该设多少llama.cpp的./main程序加-ngl 1000 -v参数会打印每层的显存占用你挑一个总和略小于显存的层数即可。这步省不了是性能调优的基石。3.5 姿势五Hugging Face Inference Endpoints——托管服务里的“性价比之王”Hugging Face不仅提供模型还提供一键部署的Inference Endpoints。你选一个模型如Qwen2-7B-Instruct点“Deploy”选GPU类型T4/A10几分钟后得到一个HTTPS endpoint。LangChain用HuggingFaceEndpoint类endpoint_url填进去就行。优势是免运维、自动扩缩容、自带监控。但坑在两点第一Endpoint的model_kwargs不支持所有transformers参数比如temperature可以传但repetition_penalty可能被忽略得看HF的文档。第二网络延迟。Endpoint在AWS us-east-1你的服务器在阿里云杭州跨洲际调用P95延迟轻松破2秒。我的对策在LangChain里加一层CacheBackedEmbeddings式的缓存但缓存对象不是embedding而是llm.invoke()的完整ChatResult用Redis存key是hash(promptmodel_name)有效期设为1小时。对FAQ类高频查询命中率能到70%用户体验直线上升。3.6 姿势六自建vLLM服务——高并发场景的“核武器”当你的QPS每秒查询数超过50Ollama和HF Endpoint都会成为瓶颈。vLLM是UC Berkeley开源的高性能推理引擎核心是PagedAttention能把显存利用率提到90%以上吞吐量是llama.cpp的3倍。部署vLLM需要写一个server.py用uvicorn启动LangChain用HuggingFaceEndpoint对接。但vLLM的配置是艺术。--tensor-parallel-size设多少取决于你的GPU数量。单卡3090设1双卡A100设2。--max-num-seqs最大并发请求数设太高OOM设太低吞吐上不去。我的经验值--max-num-seqs GPU显存(GB) * 2比如24GB显存设48。最难的是--max-model-len它必须和模型的config.json里max_position_embeddings一致否则启动报错。Qwen2-7B是32768Llama-3-8B是8192填错直接fail。vLLM不是给新手准备的但一旦调通它就是你应对流量洪峰的底气。3.7 姿势七LiteLLM——统一API的“交通警察”让所有模型用同一套代码你不可能永远只用一个模型。开发用llama3:8b快、便宜测试用Qwen2-72B准、全上线用gpt-4-turbo稳、强。如果每换一个模型都要重写llm XXX()项目会失控。LiteLLM就是为此而生。它是一个代理层你调用litellm.completion()传modelgpt-3.5-turbo或modelollama/llama3:8b它自动路由到对应后端。LangChain里你可以封装一个LiteLLMWrapper让它继承BaseLLM这样整个Chain代码完全不用动。LiteLLM的fallbacks功能是神技fallbacks[gpt-3.5-turbo, ollama/llama3:8b]当OpenAI API超时或限流自动切到本地模型用户无感知。但LiteLLM也有学习成本它的api_key管理是中心化的所有模型的key都存在一个.env文件里安全审计时会被挑战。我的做法在Kubernetes里用Secret挂载.env并通过lite_llm_settings.yaml配置不同环境的fallback策略开发环境fallback到Ollama生产环境fallback到Azure OpenAI。4. 实操避坑指南从模型加载到流式输出我踩过的12个真实坑理论讲完现在上干货。这12个坑每一个都来自我过去三个月的真实项目日志不是网上抄的“常见问题”是凌晨三点debug时记下的血泪教训。4.1 坑1Tokenizer不匹配导致的“幻觉式截断”现象用HuggingFacePipeline加载Qwen2-7Bllm.invoke(请总结以下内容[2000字文本])返回的答案只有前500字且结尾是“...此处省略”。检查日志没报错。原因Qwen2的tokenizer是Qwen2Tokenizer而HuggingFacePipeline默认用AutoTokenizer.from_pretrained()它有时会错误加载成LlamaTokenizer导致max_length参数被错误解释。解法显式指定tokenizerfrom transformers import AutoTokenizer, AutoModelForCausalLM from langchain_huggingface import HuggingFacePipeline tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2-7B-Instruct, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2-7B-Instruct, trust_remote_codeTrue) pipe pipeline(text-generation, modelmodel, tokenizertokenizer, max_length4096) llm HuggingFacePipeline(pipelinepipe)4.2 坑2Ollama的num_ctx不生效上下文还是被截断现象Ollamallama3:8bnum_ctx8192但输入7000 tokens的文本依然被截。原因Ollama的num_ctx只在模型首次加载时生效。如果你之前用默认4096跑过Ollama已缓存了模型新参数不生效。解法ollama rm llama3:8b彻底删除再ollama run --num_ctx 8192 llama3:8b。或者更稳妥用ollama create自定义ModelfileFROM ./llama3.Q4_K_M.gguf PARAMETER num_ctx 8192然后ollama create my-llama3 -f Modelfile。4.3 坑3ChatOpenAI的temperature0结果还是随机现象设了temperature0但连续两次llm.invoke(11)一次回2一次回2.带小数点。原因OpenAI的temperature0不是绝对确定性它还有top_p默认1.0和frequency_penalty默认0在起作用。解法把所有随机性参数锁死llm ChatOpenAI( model_namegpt-3.5-turbo, temperature0, top_p1, frequency_penalty0, presence_penalty0, seed42 # OpenAI 1.0 新增保证完全确定性 )4.4 坑4LlamaCpp加载70B模型Python进程直接被OOM Killer干掉现象llm LlamaCpp(model_pathllama3-70b.Q4_K_M.gguf)Python进程消失系统日志显示Out of memory: Kill process 12345 (python) score 850 or sacrifice child。原因LlamaCpp默认把整个模型加载到RAM70B Q4模型约35GB你的机器只有32GB内存。解法启用mmap内存映射llm LlamaCpp( model_pathllama3-70b.Q4_K_M.gguf, n_gpu_layers1000, # 全部GPU n_ctx4096, verboseFalse, use_mmapTrue, # 关键 use_mlockFalse )use_mmapTrue让模型文件不全读进内存而是按需加载RAM压力骤降。4.5 坑5流式输出stream在LangChain里卡在第一个token现象for chunk in llm.stream(hello):循环只执行一次chunk是第一个token然后就结束了。原因LangChain的stream()方法依赖底层模型的generate_stream支持但很多Hugging Face模型的pipeline不实现这个方法。解法换用AsyncLLMChain或直接用底层模型的stream# 对于Hugging Face模型 from transformers import TextIteratorStreamer streamer TextIteratorStreamer(tokenizer, skip_promptTrue) thread Thread(targetmodel.generate, kwargs{inputs: inputs, streamer: streamer}) thread.start() for new_token in streamer: print(new_token, end, flushTrue)4.6 坑6HuggingFaceEndpoint调用超时但模型明明秒回现象llm.invoke(hi)等10秒后报ReadTimeout但用curl直接调HF endpoint200ms返回。原因LangChain的HuggingFaceEndpoint默认timeout10秒但HF的wait_for_modelTrue参数会让它在模型冷启动时多等几秒。解法显式缩短timeout并关闭等待llm HuggingFaceEndpoint( endpoint_urlhttps://xxx.aws.endpoints.huggingface.cloud, huggingfacehub_api_tokenxxx, timeout5, # 缩短 tasktext-generation, model_kwargs{ wait_for_model: False, # 关键 max_new_tokens: 512 } )4.7 坑7Ollama在Mac M2上跑llama3:70b比CPU还慢现象ollama run llama3:70btime命令显示real 12.5s而ollama run --no-gpu llama3:70b强制CPU只要9.8s。原因Ollama的Metal后端对M2 Max的优化不足矩阵乘法没打满GPU。解法切回llama.cpp手动编译Metal支持git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make clean LLAMA_METAL1 make -j ./main -m models/llama3-70b.Q4_K_M.gguf -p Hello -ngl 1000实测手动编译的Metal版比Ollama快40%。4.8 坑8LiteLLMfallback时第二个模型也失败整个链崩了现象fallbacks[gpt-3.5-turbo, ollama/llama3:8b]OpenAI超时切到Ollama但Ollama服务宕机litellm.completion()抛出ExceptionLangChain Chain中断。原因LiteLLM的fallback是单层的它不处理fallback链的异常。解法写一个重试装饰器import tenacity tenacity.retry( stoptenacity.stop_after_attempt(3), waittenacity.wait_exponential(multiplier1, min1, max10) ) def robust_invoke(llm, prompt): return llm.invoke(prompt)把robust_invoke用在你的Chain里比依赖LiteLLM的fallback更可靠。4.9 坑9ChatPromptTemplate里用{history}但模型根本不看历史现象template 历史{history}\n当前问题{input}history变量传了3轮对话但模型回答还是像第一次聊天。原因不是所有模型都支持“对话历史”格式。gpt-3.5-turbo用messages[{role:system,content:...},{role:user,content:...}]而llama3用|start_header_id|user|end_header_id|...|eot_id|。ChatPromptTemplate生成的字符串对llama3来说就是乱码。解法用ChatModel而不是LLM并确保llm是ChatOpenAI或ChatOllama这类原生支持message list的类。ChatOllama需要formatllama3参数from langchain_community.chat_models import ChatOllama llm ChatOllama( modelllama3:8b, formatllama3, # 关键告诉Ollama用llama3格式 temperature0.3 )4.10 坑10HuggingFacePipeline的max_length设太大OOM现象pipeline(..., max_length16384)模型加载成功但llm.invoke()一调用GPU显存瞬间飙到100%OOM。原因max_length是生成长度上限不是输入长度。设16K模型会预分配16K的KV Cache显存爆炸。解法max_length应设为max_input_length max_output_length且max_output_length一般不超过1024。更安全的做法用max_new_tokens1024替代max_length。4.11 坑1