LangChain 已经不是 2024 年那个「Chain 套 Chain」的库了。主线包 langchain 走到 1.3.16，langchain-core 1.6.0，LangGraph 1.2.11，全部 MIT 许可，由 langchain-ai 维护，仓库在 github.com/langchain-ai/langchain。v1 之后 langchain 这个命名空间只留下 agents、messages、tools、chat_models、embeddings 五块，构建 agent 的唯一入口是 `from langchain.agents import create_agent`，它取代了原来 langgraph.prebuilt 里的 create_react_agent。定制不再靠继承和拼 Chain，而是靠 middleware —— 每个中间件挂在 before_model、after_model 这类执行点上，各管一件事：执行环境、上下文管理、规划与分派、容错、护栏、纠偏。跨供应商的差异被收进 content_blocks，reasoning、text、tool_call 这些块在 langchain-anthropic、langchain-openai、langchain-ollama 之间是同一套读法。
所以「LangChain 需要多大显存」这个问题，标准答案是 0GB。它是 Python 进程里的编排逻辑，跑在 CPU 上，Python 3.10 到 3.14 都支持。显存账全部落在你自己起的后端上：一个能可靠调用工具的对话模型，一个做向量化的 embedding 模型，讲究一点再加个重排。这几个才是要租卡的东西。以能查证的数字为准：openai/gpt-oss-20b 是 21B 总参 / 3.6B 激活的 MoE，MoE 权重走 MXFP4，模型卡明说「run within 16GB of memory」，一张 24GB 卡跑得很舒服；gpt-oss-120b 是 117B 总参 / 5.1B 激活，官方定位就是「fit into a single 80GB GPU」；Qwen3.8-27B 是 27B 稠密、原生 262,144 上下文、可用 YaRN 外推到 1M，bf16 光权重就要约 54GB，官方 FP8 版本压到约 27GB。这些数字乘出来是多少显存，你就该租多大的卡，中间没有魔法。
自建 LangChain 真正会崩的地方，也不在框架本身。最常见的三个：一是本地模型接上去后 bind_tools 看着正常、agent 却永远不调工具 —— 因为 vLLM 没开 `--enable-auto-tool-choice` 和对应的 `--tool-call-parser`，模型把工具 JSON 当普通文本吐了出来，循环自然不触发；二是老代码升到 1.x 后 `from langchain.chains import LLMChain` 直接 ImportError，旧 chains、旧 retrievers、indexing API、hub 模块和 langchain-community 的转出口全被搬去了 langchain-classic 1.0.8；三是私有化部署最忌讳的一条，LANGSMITH_TRACING 一旦为 true，prompt 和工具返回值就顺着链路发去了 LangSmith。这些坑都得在真机上撞一次才记得住，而撞它们需要的是一张随时能开、按秒计费、撞完就停的卡 —— NexGPU 在 51 个国家和地区有 1,175 个已验证可租节点、2,498 张 GPU，2,000+ 预置镜像里 PyTorch 和 vLLM 都是现成的。
01 —
你要装的版本，和你要喂的模型
上半段是 LangChain 技术栈本体，一张卡都不占；下半段才是真正把显存吃掉的后端。
| 版本 | 参数量 | 显存 | 上下文 | 说明 |
|---|---|---|---|---|
| langchain 1.3.16 | 框架本体，无权重 | 0GB，纯 CPU 编排 | 由后端模型决定 | create_agent 与 middleware 的主线包，MIT 许可，Python 3.10–3.14；命名空间收窄到 agents / messages / tools / chat_models / embeddings。 |
| langgraph 1.2.11 + langgraph-cli 0.4.31 | 运行时与 CLI | 0GB，状态落 Postgres | checkpointer 决定可回溯长度 | 有状态多轮 agent 的运行时。CLI 提供 langgraph new / dev / up / build / dockerfile，`langgraph up` 直接把服务拉进 Docker。 |
| langchain-classic 1.0.8 | 迁移兼容包 | 0GB | — | 旧 chains、旧 retrievers（含 MultiQueryRetriever）、indexing API、hub 模块、langchain-community 转出口都在这里。老项目升 1.x 报 ImportError 就装它。 |
| openai/gpt-oss-20b（后端候选） | 21B 总参 / 3.6B 激活 MoE | MXFP4 权重，模型卡称 16GB 内可跑 | 长上下文，按 --max-model-len 裁 | Apache 2.0。单卡 24GB 就能跑通完整 agent 循环，是验证 create_agent、middleware 和工具链路最划算的后端。 |
| Qwen/Qwen3.8-27B 与 -FP8（后端候选） | 27B 稠密（HF 参数计数含视觉塔约 28B） | bf16 权重约 54GB / FP8 约 27GB | 原生 262,144，YaRN 可外推至 1M | Apache 2.0，原生看图看视频，带 reasoning_effort 档位（xhigh / medium / low）与 preserve_thinking。vLLM 一行 `vllm serve "Qwen/Qwen3.8-27B"` 起服务。 |
| Qwen/Qwen3-Embedding-0.6B / 4B / 8B（检索侧） | 0.6B / 4B / 8B | fp16 约 1.2GB / 8GB / 16GB | 长文档切块后进 | LangChain RAG 的向量化后端，官方另有 GGUF 版本。0.6B 那档小到可以和别的服务挤同一张卡，别为它单独占推理卡的显存。 |
02 —
按你实际要跑的东西选卡
LangChain 不进这张表，进表的是它背后的模型 —— 下面每一档都按可查证的权重体积对齐显存。
跑通 create_agent 全链路：单卡 gpt-oss-20b 做工具调用验证
RTX 4090 24GB$0.540/卡·时
MXFP4 权重按官方说法 16GB 内装得下，24GB 还剩约 8GB 给 KV cache，够一个十来步、32K 上下文的 agent 循环跑完不 OOM。
只做检索侧：Qwen3-Embedding-0.6B 批量向量化知识库
Tesla T4 16GB$0.298/卡·时
0.6B 的 fp16 权重才约 1.2GB，把 embedding 拆到便宜卡上单独跑，别让它去挤推理卡本来要留给 KV cache 的那几个 GB。
生产级 agent 后端：Qwen3.8-27B-FP8 常驻服务
RTX A6000 48GB$0.817/卡·时
FP8 权重约 27GB —— 32GB 的卡确实装得进权重，但几乎不剩 KV cache，agent 多轮工具调用一累积就爆；48GB 才是这一档的安全线。
顶配：gpt-oss-120b，或 Qwen3.8-27B bf16 开长上下文
A100 PCIE 80GB$0.824/卡·时
gpt-oss-120b 官方就是照着单张 80GB 设计的，Qwen3.8-27B 的 bf16 权重约 54GB 也正好落这一档；同为 80GB，它只要 H100 SXM $3.582/卡·时 的约 23%。
03 —
从空实例到能调工具的 agent，四步
重点全在第一步的两个 flag 上 —— 漏了它们，后面三步看着都对，agent 就是不调工具。
- 01
起后端：vLLM 必须显式打开自动工具选择
`--enable-auto-tool-choice` 在 vLLM 里是强制项，`--tool-call-parser` 则按模型族选：Llama 3.1/3.2 用 llama3_json，Llama 4 用 llama4_pythonic，Mistral 用 mistral，Qwen 家族一般走 hermes，还有个通用的 pythonic。这两个 flag 任缺其一，模型会把工具 JSON 当普通文本吐出来，LangChain 收到的就是一条纯文本消息，agent 循环永远不进工具分支。起完服务先手工打一次带工具的请求，确认 finish_reason 真的是 tool_calls，别等 agent 静默失败。
vllm serve "Qwen/Qwen3.8-27B" --host 0.0.0.0 --port 8000 --enable-auto-tool-choice --tool-call-parser hermes --max-model-len 32768 --gpu-memory-utilization 0.90 - 02
装 LangChain 1.x，把版本钉死
钉版本不是洁癖：langchain-ollama 1.1.0 要求 langchain-core ≥ 1.2.21，deepagents 0.7.8 要求 langchain ≥ 1.3.15、langchain-core ≥ 1.6.0，而且它的 Python 下限是 3.11，比 langchain 自己的 3.10 高一档 —— 在 3.10 的镜像里装 deepagents 会直接解析失败。指向本地端点用 langchain-openai 的 OpenAI 兼容客户端就够了，base_url 填 vLLM 的 /v1，api_key 随便给个占位串。
pip install -U "langchain==1.3.16" "langgraph==1.2.11" "langchain-openai==1.6.0" - 03
用 create_agent 组装，而不是 create_react_agent
v1 之后 create_agent 是唯一推荐入口，接收 model、tools、system_prompt、response_format、state_schema、checkpointer、context_schema、middleware、name。要多轮记忆就挂 checkpointer，本地验证用 InMemorySaver，上生产换 Postgres 版。要结构化输出就传 response_format，但注意本地后端得支持受约束解码，否则 Pydantic 校验会随机失败 —— 这一点云端 API 帮你兜住了，自建没人兜。
from langchain.agents import create_agent from langchain_openai import ChatOpenAI llm = ChatOpenAI(model="Qwen/Qwen3.8-27B", base_url="http://127.0.0.1:8000/v1", api_key="EMPTY") agent = create_agent(model=llm, tools=[search], system_prompt="You are a research agent.") - 04
切断外发链路，再把服务拉起来
私有化部署的最后一道闸：LANGSMITH_TRACING 为 true 时，prompt、工具入参和返回值会随链路发往 LangSmith。要么关掉，要么把 LANGSMITH_ENDPOINT 指向你自己那套自托管实例，别默认它是关的。确认干净之后用 langgraph-cli 把服务打进 Docker 常驻，实例上开 SSH 或 Jupyter 都行，NexGPU 这两条通道加 web 终端、REST API、CLI 都是开箱可用的。
export LANGSMITH_TRACING=false && langgraph up
一周把 LangChain agent 跑通，账是这么算的
按一个典型自建组合算：推理侧 RTX 4090 24GB 跑 gpt-oss-20b，$0.540/卡·时；检索侧 Tesla T4 16GB 跑 Qwen3-Embedding-0.6B，$0.298/卡·时，合计 $0.838/时。一个小组开发五天、每天开机 8 小时，共 40 小时：0.838 × 40 = $33.52。模型权重加语料占 40GB 存储，按中位价 $0.414/GB·月 算 40 × 0.414 = $16.56/月。把 10GB 日志和评测结果拉回本地，出网中位价 $0.0081/GB，10 × 0.0081 = $0.08。首月合计约 $50.16。同样这套配置若 7×24 常驻，720 × 0.838 = $603.36 —— 差出来的十几倍不是单价问题，是你有没有在 agent 不跑的时候把实例停掉。NexGPU 按秒计量、按小时定价，无最低消费、无开通费、不需要申请配额，实例一停算力费立刻停，只有存储会一直计到你销毁它为止。要往上跳到 gpt-oss-120b 这种照着单张 80GB 设计的模型，A100 PCIE 80GB 是 $0.824/卡·时，大约只有 H100 SXM 80GB $3.582/卡·时 的 23%。
04 —