LangChain中LLM模型选型的五大实操维度与避坑指南

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-7B，tokenizer算出来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! I'll search for the latest iPhone specs. Here's 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显存，一块3090（24GB）能同时跑3个实例做负载均衡；而DeepSeek-Coder-33B，330亿参数，Q4量化后也要18GB，3090只能勉强跑一个，且推理速度慢一倍。更隐蔽的成本是“内存带宽瓶颈”：Llama-3-70B在A100 80GB上跑，显存够，但PCIe带宽成了短板，batch_size=1时延迟尚可，一旦并发请求增多，显存没爆，但延迟飙升到5秒以上。LangChain里，llm.invoke()默认是同步阻塞，高并发下，一个慢请求会拖垮整个服务。解决方案有两个层面：一是模型侧，选对量化格式。GGUF（llama.cpp用）比GGML更优，Q4_K_M比Q5_K_S在精度和体积上更平衡；二是LangChain侧，用AsyncLLMChain或RunnableWithFallbacks，给慢模型配个快速fallback（比如用Phi-3-mini先给个草稿答案）。我见过最痛的案例：某客户坚持要用gpt-4-32k做实时会议纪要，结果发现API调用费用一个月超5万，换成本地Qwen2-72B+vLLM推理引擎，硬件投入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应用代码。更大的坑在数据上：你用LangChain+gpt-3.5-turbo构建一个内部知识库，员工上传的PDF里含有客户合同扫描件，这些数据会不会被OpenAI用于模型训练？OpenAI的Enterprise协议明确说不会，但Free或Pay-as-you-go账户，默认是可能的。我的建议：涉及敏感数据（财务、HR、客户信息），一律走私有化部署，用Ollama拉取llama3:8b或qwen2:7b，数据不出内网。LangChain的Ollama类配置极其简单，base_url="http://localhost:11434"一行搞定，比折腾transformers+accelerate省心太多。许可证不是玄学，是上线前必须和法务过一遍的checklist。我附一张常用模型许可对比表，帮你一眼看清红线在哪：

提示：不要只看模型主页的“License”标签，务必点开LICENSE文件原文。很多模型在README.md里写“MIT License”，但LICENSE文件里藏着一行小字：“except for the weights, which are under Custom License”。

3. LangChain里调用LLM的七种姿势：从API到本地，哪条路最稳？

知道了模型的五大维度，下一步就是把它接入LangChain。别以为llm = ChatOpenAI(model_name="gpt-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？得开verbose=True，日志里全是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 endpoint，openai_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:8b，30秒内一个8B模型就在本地跑起来了，LangChain用Ollama类对接，三行代码：

from langchain_community.llms import Ollama llm = Ollama( model="llama3:8b", base_url="http://localhost:11434", temperature=0.3 )

它之所以稳，是因为它把模型加载、量化、推理、HTTP服务全包了。你不用管CUDA版本、不用装llama.cpp、不用编译transformers。但Ollama不是万能的。第一，它只支持GGUF格式模型，而Hugging Face上大部分模型是safetensors或bin，得先用llama.cpp的convert.py脚本转换，这个过程对新手不友好。第二，Ollama的stream=True流式输出，在LangChain的llm.stream()里，有时会卡在第一个token，原因是Ollama的HTTP chunked encoding和LangChain的AsyncIterator不完全兼容。我的fix：在Ollama初始化时，加num_ctx=4096（显式设置上下文），并确保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_CUDA=on开启CUDA，-DLLAMA_METAL=on开启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_layers=40就满了，再多会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(prompt+model_name)，有效期设为1小时。对FAQ类高频查询，命中率能到70%，用户体验直线上升。

3.6 姿势六：自建vLLM服务——高并发场景的“核武器”

当你的QPS（每秒查询数）超过50，Ollama和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是32768，Llama-3-8B是8192，填错直接fail。vLLM不是给新手准备的，但一旦调通，它就是你应对流量洪峰的底气。

3.7 姿势七：LiteLLM——统一API的“交通警察”，让所有模型用同一套代码

你不可能永远只用一个模型。开发用llama3:8b（快、便宜），测试用Qwen2-72B（准、全），上线用gpt-4-turbo（稳、强）。如果每换一个模型，都要重写llm = XXX()，项目会失控。LiteLLM就是为此而生。它是一个代理层，你调用litellm.completion()，传model="gpt-3.5-turbo"或model="ollama/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 坑1：Tokenizer不匹配导致的“幻觉式截断”

现象：用HuggingFacePipeline加载Qwen2-7B，llm.invoke("请总结以下内容：[2000字文本]")，返回的答案只有前500字，且结尾是“...（此处省略）”。检查日志，没报错。
原因：Qwen2的tokenizer是Qwen2Tokenizer，而HuggingFacePipeline默认用AutoTokenizer.from_pretrained()，它有时会错误加载成LlamaTokenizer，导致max_length参数被错误解释。
解法：显式指定tokenizer：

from transformers import AutoTokenizer, AutoModelForCausalLM from langchain_huggingface import HuggingFacePipeline tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2-7B-Instruct", trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2-7B-Instruct", trust_remote_code=True) pipe = pipeline("text-generation", model=model, tokenizer=tokenizer, max_length=4096) llm = HuggingFacePipeline(pipeline=pipe)

4.2 坑2：Ollama的num_ctx不生效，上下文还是被截断

现象：Ollamallama3:8b，num_ctx=8192，但输入7000 tokens的文本，依然被截。
原因：Ollama的num_ctx只在模型首次加载时生效。如果你之前用默认4096跑过，Ollama已缓存了模型，新参数不生效。
解法：ollama rm llama3:8b，彻底删除，再ollama run --num_ctx 8192 llama3:8b。或者，更稳妥，用ollama create自定义Modelfile：

FROM ./llama3.Q4_K_M.gguf PARAMETER num_ctx 8192

然后ollama create my-llama3 -f Modelfile。

4.3 坑3：ChatOpenAI的temperature=0，结果还是随机

现象：设了temperature=0，但连续两次llm.invoke("1+1=")，一次回2，一次回2.（带小数点）。
原因：OpenAI的temperature=0不是绝对确定性，它还有top_p（默认1.0）和frequency_penalty（默认0）在起作用。
解法：把所有随机性参数锁死：

llm = ChatOpenAI( model_name="gpt-3.5-turbo", temperature=0, top_p=1, frequency_penalty=0, presence_penalty=0, seed=42 # OpenAI 1.0+ 新增，保证完全确定性 )

4.4 坑4：LlamaCpp加载70B模型，Python进程直接被OOM Killer干掉

现象：llm = LlamaCpp(model_path="llama3-70b.Q4_K_M.gguf")，Python进程消失，系统日志显示Out of memory: Kill process 12345 (python) score 850 or sacrifice child。
原因：LlamaCpp默认把整个模型加载到RAM，70B Q4模型约35GB，你的机器只有32GB内存。
解法：启用mmap（内存映射）：

llm = LlamaCpp( model_path="llama3-70b.Q4_K_M.gguf", n_gpu_layers=1000, # 全部GPU n_ctx=4096, verbose=False, use_mmap=True, # 关键！ use_mlock=False )

use_mmap=True让模型文件不全读进内存，而是按需加载，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_prompt=True) thread = Thread(target=model.generate, kwargs={"inputs": inputs, "streamer": streamer}) thread.start() for new_token in streamer: print(new_token, end="", flush=True)

4.6 坑6：HuggingFaceEndpoint调用超时，但模型明明秒回

现象：llm.invoke("hi")，等10秒后报ReadTimeout，但用curl直接调HF endpoint，200ms返回。
原因：LangChain的HuggingFaceEndpoint默认timeout=10秒，但HF的wait_for_model=True参数会让它在模型冷启动时多等几秒。
解法：显式缩短timeout，并关闭等待：

llm = HuggingFaceEndpoint( endpoint_url="https://xxx.aws.endpoints.huggingface.cloud", huggingfacehub_api_token="xxx", timeout=5, # 缩短 task="text-generation", model_kwargs={ "wait_for_model": False, # 关键！ "max_new_tokens": 512 } )

4.7 坑7：Ollama在Mac M2上跑llama3:70b，比CPU还慢

现象：ollama run llama3:70b，time命令显示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_METAL=1 make -j ./main -m models/llama3-70b.Q4_K_M.gguf -p "Hello" -ngl 1000

实测，手动编译的Metal版比Ollama快40%。

4.8 坑8：LiteLLMfallback时，第二个模型也失败，整个链崩了

现象：fallbacks=["gpt-3.5-turbo", "ollama/llama3:8b"]，OpenAI超时，切到Ollama，但Ollama服务宕机，litellm.completion()抛出Exception，LangChain Chain中断。
原因：LiteLLM的fallback是单层的，它不处理fallback链的异常。
解法：写一个重试装饰器：

import tenacity @tenacity.retry( stop=tenacity.stop_after_attempt(3), wait=tenacity.wait_exponential(multiplier=1, min=1, max=10) ) def robust_invoke(llm, prompt): return llm.invoke(prompt)

把robust_invoke用在你的Chain里，比依赖LiteLLM的fallback更可靠。

4.9 坑9：ChatPromptTemplate里用{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需要format="llama3"参数：

from langchain_community.chat_models import ChatOllama llm = ChatOllama( model="llama3:8b", format="llama3", # 关键！告诉Ollama用llama3格式 temperature=0.3 )

4.10 坑10：HuggingFacePipeline的max_length设太大，OOM

现象：pipeline(..., max_length=16384)，模型加载成功，但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_tokens=1024替代max_length。

4.11 坑1