这次我们不聊“大模型有多强”而是专门拆一拆“大模型落地时究竟会遇到哪些问题”。项目标题叫The LLMs Problems听起来像一份问题清单实际对应的是所有做 LLM 本地部署、二次开发、框架选型、多应用集成时绕不开的那些坑上下文截断、显存爆炸、幻觉输出、框架兼容、ComfyUI 怎么和 LLM 协作、批量任务怎么设计、接口怎么稳定调用。如果你正在本地跑开源模型、想把 LLM 集成到自己的工具链里或者纠结“ComfyUI 和 LLM 到底要不要装在同一台机器上”这篇文章可以直接收藏。下面从核心能力、环境准备、框架选型、部署启动、功能测试、接口调用、资源监控到排错清单完整过一遍。1. 核心能力速览先明确一点The LLMs Problems 不是一个单一的可执行程序它更像一个“LLM 落地问题全景图”。围绕它展开的内容覆盖以下能力维度。能力项说明项目定位梳理 LLM 本地部署、推理、集成、批量任务中的常见问题与解决方案涉及框架llama.cpp、Ollama、vLLM、Transformers、LangChain 等常见 LLM 工具链硬件需求视模型规模而定7B~14B 模型建议 8G 以上显存更大模型需要更高配置或量化方案启动方式命令行启动、API 服务启动、WebUI 可选主要功能模型推理、文本生成、接口调用、批量任务、多应用集成如 ComfyUI是否支持 API支持主流框架均提供 HTTP/OpenAI 兼容接口是否支持批量任务支持但需要自己设计队列、超时和重试机制适合场景本地部署学习、API 开发、内容管线集成、多机资源调度使用边界生成内容需要人工复核涉及隐私、版权素材时必须先获得授权这里的核心结论是LLM 本身不是问题问题全出在“怎么把模型放进你的生产环境”。框架选型、显存分配、接口协议、任务队列每一项都可能成为瓶颈。2. 适用场景与使用边界2.1 适合谁用想在本机跑通开源模型但不确定显存够不够的开发者。需要把 LLM 能力接入现有工具链比如自动化写作、数据清洗、内容摘要、知识库问答。正在使用 ComfyUI 做图像生成希望加入 LLM 做提示词优化、工作流解析或自动化调参。需要批量调用 LLM 做文本处理比如批量翻译、批量打标、批量审核初筛。2.2 能解决什么问题The LLMs Problems 关注的是“如何让模型真正跑起来、稳定出结果、能接进业务”。具体包括模型选择与量化级别之间的取舍。本地推理与云端 API 的切换逻辑。上下文窗口不足时怎么办。显存不够时如何用 CPU 或降低精度推理。不同框架之间接口不兼容怎么对齐。API 服务超时、限流、失败重试怎么设计。ComfyUI 这类外部应用如何通过接口远程调用 LLM。2.3 不适合什么场景需要毫秒级响应的实时系统本地 LLM 推理延迟通常不适合直接做在线客服。对输出准确性有严格要求、且没有人工复核环节的生产流程模型幻觉会造成风险。涉及用户隐私数据、商业机密数据的大规模处理如果没有私有化部署和访问控制不建议直接上云 API。2.4 合规与安全边界使用 LLM 时要特别注意不要将未脱敏的用户数据、内部文档直接传给第三方 API。生成内容的版权归属、误用风险由使用方承担责任。如果涉及人脸、声音、版权素材相关的多模态任务必须确认授权后再处理。本地部署模型不等于绝对安全模型权重、推理日志、接口访问都需要做访问控制。3. LLM 本地部署环境准备3.1 操作系统与基础组件从材料看LLM 本地部署的主流方式分为两种一种是用现成的推理框架直接运行量化模型一种是用 Python 生态加载原始权重。前者部署简单后者灵活度高。无论哪种方式先确认基础环境操作系统LinuxUbuntu/CentOS是主流选择Windows 可以跑但部分框架需要 WSL 或原生工具链。Python 版本建议 3.10 及以上部分框架对 3.12/3.13 的兼容性需要单独确认。包管理工具pip、conda 至少准备一个。Git用于拉取框架源码或模型仓库。3.2 GPU 与驱动检查本地跑模型前先检查显卡驱动和 CUDA 环境是否可用。# 查看显卡型号 nvidia-smi # 查看 CUDA 版本 nvcc --version如果没有 N 卡可以走 CPU 推理路线但速度会慢很多适合小模型和测试场景。如果有 N 卡重点看显存大小这决定了你能跑多大参数量的模型。3.3 磁盘空间模型权重文件体积差异很大7B 模型的量化版大约需要 4GB 到 8GB 磁盘。14B 模型量化版可能需要 10GB 以上。全精度权重体积更大动辄几十 GB。启动前先确认磁盘剩余空间预留至少两倍于模型文件的空间用于缓存下载和日志输出。3.4 端口规划API 服务需要占用端口常见的有 8000、8080、11434、7860 等。启动前检查端口是否被占用。# Linux / macOS lsof -i :8000 # Windows PowerShell netstat -ano | findstr :8000如果端口冲突换一个端口重新启动即可。4. LLM 框架选型与启动方式4.1 主流框架对比框架特点适合场景llama.cpp支持 CPU、GPU 混合推理量化支持好低配设备、边缘部署Ollama安装简单模型拉取方便带 OpenAI 兼容接口快速搭建本地 API 服务vLLM高吞吐推理PagedAttention 优化显存批量请求、服务化部署Transformers生态最全兼容大多数开源模型研究开发、模型评测从材料看Ollama 和 vLLM 是两条典型路线Ollama 偏个人开发与快速验证vLLM 偏服务化和高并发。二选一可以先从 Ollama 开始。4.2 Ollama 快速启动示例Ollama 的模型拉取和启动非常直接。先安装 Ollama然后拉取一个模型# 拉取模型以 Qwen2.5 7B 为例 ollama pull qwen2.5:7b # 启动交互式对话 ollama run qwen2.5:7b启动后可以立即在终端里测试模型的输出效果。Ollama 默认监听 11434 端口并提供一个 OpenAI 兼容的 API 接口。# 查看服务状态 curl http://127.0.0.1:11434/v1/models如果需要调整服务监听地址可以设置环境变量OLLAMA_HOSTexport OLLAMA_HOST0.0.0.0:11434 ollama serve注意监听0.0.0.0表示局域网内其他机器也可以访问生产环境需要配合防火墙或鉴权。4.3 vLLM 服务化启动示例vLLM 更适合需要高吞吐的批量场景。安装后可以用如下方式启动一个 OpenAI 兼容服务# 安装 vLLM pip install vllm # 启动服务 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --host 127.0.0.1 \ --port 8000 \ --gpu-memory-utilization 0.8参数说明--model模型名称或本地路径按实际下载的模型替换。--host监听地址建议本机测试用 127.0.0.1。--port服务端口。--gpu-memory-utilization允许使用的显存比例0.8 表示最多使用 80%。如果显卡显存不足vLLM 会启动失败或触发 OOM需要调低该比例或换更小的量化模型。4.4 Transformers 本地推理示例如果模型是 Hugging Face 格式可以直接用 Transformers 加载from transformers import AutoTokenizer, AutoModelForCausalLM model_name Qwen/Qwen2.5-7B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, device_mapauto) prompt 用一句话解释什么是大模型幻觉。 messages [{role: user, content: prompt}] inputs tokenizer.apply_chat_template(messages, return_tensorspt).to(model.device) outputs model.generate(inputs, max_new_tokens256) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))这种方式适合调试和研究不推荐直接用于高并发服务因为每次请求都占用大量显存且没有自动批处理优化。5. ComfyUI 与 LLM 的资源协同5.1 核心问题必须在同一台电脑上吗这是很多做图像生成的同学最关心的问题。结论是不需要。ComfyUI 本身是图像生成工作流工具它需要独立的 GPU 显存来跑 Stable Diffusion 或 Flux 等图像模型。LLM 推理同样需要大量显存。如果两个任务挤在同一张显卡上很容易出现显存不够用、生成图像时 OOM、跑 LLM 时被抢占资源的情况。更稳妥的做法是方案一同一台机器分时使用。把 ComfyUI 的 LLM 节点配置为远程 API 地址避免两个模型同时占用显存。方案二双机部署。ComfyUI 跑在图像生成机器上LLM 跑在另一台机器或云端 API 上通过 HTTP 接口通信。方案三同一台机器但 LLM 走 CPU 推理。适合小模型和低频调用ComfyUI 独占 GPU。5.2 ComfyUI 调用远程 LLM 的方式多数 ComfyUI 的 LLM 插件或自定义节点支持配置 API Base URL。只要你的 LLM 服务提供了 OpenAI 兼容接口ComfyUI 就可以通过一个 HTTP 请求连接到远程 LLM。典型配置流程在机器 A 启动 LLM API 服务记下地址例如http://192.168.1.100:11434/v1。在 ComfyUI 的 LLM 节点中填写该地址。配置模型名称比如qwen2.5:7b。在 ComfyUI 工作流里调用 LLM 生成提示词再传给图像生成节点。这样设计的好处是图像模型和语言模型互不抢占显存ComfyUI 工作流也能保持稳定。5.3 同机部署时的显存规划如果坚持单机跑两个模型需要先确认显卡显存。以一张 12G 显存显卡为例跑一个 7B 量化 LLM 约占用 6G 到 8G剩余显存再跑图像生成会非常紧张。更合理的方式是先跑 LLM把生成结果保存为文本文件。再启动 ComfyUI读取文本作为提示词。全程不要让两个模型同时驻留显存。如果是 24G 及以上显存可以尝试同时运行但依然建议先观察显存占用确保两个模型的总占用不超过显存上限。6. LLM 功能测试与效果验证6.1 基础生成测试先做最简单的生成测试确认模型能正常输出。以 Ollama 为例ollama run qwen2.5:7b 请用三句话介绍 Flask 框架。判断成功的标准模型能在合理时间内返回内容。输出与问题相关没有明显乱码。没有出现 CUDA OOM 报错。6.2 上下文长度测试测试模型在长文本场景下的表现。可以准备一篇 2000 到 5000 字的文档让模型做摘要。import requests url http://127.0.0.1:11434/api/generate payload { model: qwen2.5:7b, prompt: 请总结以下内容 long_text, stream: False } response requests.post(url, jsonpayload, timeout300) print(response.json().get(response, ))这里要注意 timeout 要设置得足够大长上下文生成经常需要几十秒以上。如果生成中断可能原因是上下文窗口不够或超时机制太短。6.3 幻觉与事实准确性测试可以使用同一个问题问多次观察输出是否稳定。举例问“2024 年巴黎奥运会开幕式的举办日期”这类有明确答案的问题。问“某个不存在的 API 的用法”这类容易产生幻觉的问题。如果模型在不存在的 API 上给出了详细但错误的用法说明模型存在幻觉倾向。生产环境必须增加人工复核或知识库约束。6.4 显存占用测试运行模型时用nvidia-smi观察显存变化。watch -n 1 nvidia-smi重点观察模型加载后的空闲显存占用。生成长文本时的峰值显存。同时跑多个并发请求时显存是否溢出。如果显存溢出可以降低生成长度、减小 batch size或换用更小的量化模型。6.5 稳定性测试连续发送 20 到 50 个请求观察是否有请求超时。服务是否崩溃。显存是否有持续增长即内存泄漏现象。稳定性测试发现服务崩溃时先查服务日志再看是否有进程残留。7. 接口 API 与批量任务7.1 OpenAI 兼容接口调用Ollama 和 vLLM 都提供 OpenAI 兼容接口。调用方式如下import requests url http://127.0.0.1:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: system, content: 你是一个严谨的技术助手。}, {role: user, content: 解释一下什么是 RAG。} ], temperature: 0.7, max_tokens: 512 } response requests.post(url, jsonpayload, timeout120) data response.json() print(data[choices][0][message][content])如果使用 vLLM把url换成http://127.0.0.1:8000/v1/chat/completions即可。7.2 curl 快速测试curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好}] }返回 JSON 中包含choices字段里面就是模型生成的文本。7.3 批量任务设计LLM 批量任务和图像批量任务不一样不能简单地把一堆任务一次性塞进显存。推荐的设计思路输入文件每行一个任务或一个目录下多个文本文件。逐条读取生成请求等待响应。失败请求记录到单独的日志文件稍后重试。控制并发数防止显存溢出。示例代码import json import time import requests API_URL http://127.0.0.1:11434/v1/chat/completions MODEL_NAME qwen2.5:7b def process_task(text): payload { model: MODEL_NAME, messages: [{role: user, content: text}], max_tokens: 512 } resp requests.post(API_URL, jsonpayload, timeout120) resp.raise_for_status() return resp.json()[choices][0][message][content] with open(tasks.jsonl, r, encodingutf-8) as f: tasks [json.loads(line) for line in f if line.strip()] results [] failed [] for task in tasks: try: result process_task(task[prompt]) results.append({id: task[id], result: result}) except Exception as e: failed.append({id: task[id], error: str(e)}) print(f[failed] {task[id]}: {e}) time.sleep(0.5) # 限制请求频率避免压垮本地服务 with open(results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) with open(failed.json, w, encodingutf-8) as f: json.dump(failed, f, ensure_asciiFalse, indent2)7.4 批量任务的重试策略对超时任务做指数退避重试比如第一次等 5 秒第二次等 10 秒。对显存不足OOM的任务暂停一段时间再继续。对已经确认失败且无法恢复的任务单独记录不阻塞后续任务。8. 资源占用与性能观察8.1 显存占用观察方法启动 LLM 服务后在另一个窗口执行nvidia-smi --query-gpuname,memory.used,memory.total,utilization.gpu --formatcsv -l 1每秒刷新一次可以直观看到模型加载后的基线显存、生成过程中的峰值显存以及 GPU 利用率。8.2 CPU 推理与 GPU 推理差异GPU 推理速度快生成流畅但模型大小受显存限制。CPU 推理可跑大模型但速度慢适合无显卡测试场景。混合推理部分框架支持将部分层放到 GPU、部分层放到 CPU牺牲速度换容量。如果只有 CPU建议选择量化级别高的小模型比如 7B 的 Q4 量化版。8.3 影响性能的关键参数模型参数量7B、14B、32B 对显存要求差异巨大。量化级别Q4 比 F16 省显存但输出质量可能有轻微损失。上下文长度长上下文会显著增加显存占用和生成延迟。max_tokens单次生成的最大长度越长等待时间越久。并发数并发请求越多显存和内存消耗越大。temperature影响生成多样性不影响性能但调高后结果不稳定。8.4 降低显存占用的方法使用量化模型比如 Q4_K_M、Q5_K_M。降低max_tokens和上下文长度。关闭流式输出或用流式输出但不在服务端缓存全部结果。减少并发请求数。使用 vLLM 的连续批处理特性而不是自己开多个进程。9. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后页面/接口打不开端口被占用或服务未启动查看服务日志和端口状态更换端口或重启服务显存不足 OOM模型太大或并发过高nvidia-smi 查看显存占用换量化模型、降低并发、减小上下文模型下载失败网络问题或存储空间不足检查磁盘和网络连接清理磁盘或用离线包导入生成速度极慢CPU 推理或上下文过长看硬件利用率和生成日志换 GPU 或减小上下文长度输出乱码模型权重损坏或 tokenizer 不匹配重新加载模型删除缓存重新下载API 请求超时timeout 设置过短或服务繁忙查看服务日志调大 timeout限制并发批量任务中途卡住单任务异常未处理检查失败日志加异常捕获和重试机制显存持续增长服务存在内存泄漏连续请求后观察内存定期重启服务或升级框架版本多个应用端口冲突启动参数未指定端口lsof 或 netstat 查看换用不同端口敏感信息泄露风险接口无鉴权、监听 0.0.0.0检查监听地址和访问日志加鉴权、限制 IP、用内网部署10. 最佳实践与使用建议10.1 部署阶段第一次测试先跑最小模型确认环境通了再换大模型。保留一套完整的启动命令和配置方便复现。模型文件、输入素材、输出结果分目录管理不要混在一起。每次换模型前记录显存基线和生成延迟方便横向对比。10.2 批量任务阶段批量任务一定要加日志记录每个任务的耗时和结果。失败任务要自动写入单独文件不要中断整个队列。控制并发数优先保证任务不失败再追求速度。批量任务跑完后检查失败文件重试确认失败的请求。10.3 接口服务阶段API 服务只监听内网地址不要直接暴露到公网。需要外部接入时加一层 API Key 鉴权。上游接入方要做好超时和降级方案LLM 服务不可用时不影响主流程。定期查看访问日志防止接口被滥用。10.4 内容安全阶段模型生成的代码、文档、图片描述都需要人工复核后使用。涉及用户隐私、商业数据的内容优先本地部署并对日志脱敏。涉及人脸、声音、版权素材的多模态内容必须确认授权。商用前建议做一轮效果测试确认输出质量满足业务要求。11. 总结与下一步The LLMs Problems 最值得做的事不是到处收集模型而是先把“问题清单”过一遍。先确认显卡显存能跑什么模型再选一个最顺手的框架然后从单次生成测试开始逐步过渡到 API 服务和批量任务。最先要验证的是你的硬件能不能稳定跑通一个 7B 量化模型。这个目标不达成后面所有框架、接口、批量任务都无从谈起。最容易踩的坑有三类一是模型和显存不匹配启动就 OOM二是长文本生成没设置足够长的 timeout任务中途断掉三是批量任务缺少异常处理一个失败任务把整个队列卡死。后续可以扩展的方向很多接入 RAG 做知识库问答、把 LLM 接到 ComfyUI 做自动化提示词生成、用 vLLM 做高并发服务化部署、用流式输出做打字机效果。每一步都值得单独开一篇文章细讲。建议把这篇文章收藏备用动手部署时对照着检查能省下不少排查时间。 LLM落地实战：从显存优化到框架选型与API集成的完整指南
这次我们不聊“大模型有多强”而是专门拆一拆“大模型落地时究竟会遇到哪些问题”。项目标题叫The LLMs Problems听起来像一份问题清单实际对应的是所有做 LLM 本地部署、二次开发、框架选型、多应用集成时绕不开的那些坑上下文截断、显存爆炸、幻觉输出、框架兼容、ComfyUI 怎么和 LLM 协作、批量任务怎么设计、接口怎么稳定调用。如果你正在本地跑开源模型、想把 LLM 集成到自己的工具链里或者纠结“ComfyUI 和 LLM 到底要不要装在同一台机器上”这篇文章可以直接收藏。下面从核心能力、环境准备、框架选型、部署启动、功能测试、接口调用、资源监控到排错清单完整过一遍。1. 核心能力速览先明确一点The LLMs Problems 不是一个单一的可执行程序它更像一个“LLM 落地问题全景图”。围绕它展开的内容覆盖以下能力维度。能力项说明项目定位梳理 LLM 本地部署、推理、集成、批量任务中的常见问题与解决方案涉及框架llama.cpp、Ollama、vLLM、Transformers、LangChain 等常见 LLM 工具链硬件需求视模型规模而定7B~14B 模型建议 8G 以上显存更大模型需要更高配置或量化方案启动方式命令行启动、API 服务启动、WebUI 可选主要功能模型推理、文本生成、接口调用、批量任务、多应用集成如 ComfyUI是否支持 API支持主流框架均提供 HTTP/OpenAI 兼容接口是否支持批量任务支持但需要自己设计队列、超时和重试机制适合场景本地部署学习、API 开发、内容管线集成、多机资源调度使用边界生成内容需要人工复核涉及隐私、版权素材时必须先获得授权这里的核心结论是LLM 本身不是问题问题全出在“怎么把模型放进你的生产环境”。框架选型、显存分配、接口协议、任务队列每一项都可能成为瓶颈。2. 适用场景与使用边界2.1 适合谁用想在本机跑通开源模型但不确定显存够不够的开发者。需要把 LLM 能力接入现有工具链比如自动化写作、数据清洗、内容摘要、知识库问答。正在使用 ComfyUI 做图像生成希望加入 LLM 做提示词优化、工作流解析或自动化调参。需要批量调用 LLM 做文本处理比如批量翻译、批量打标、批量审核初筛。2.2 能解决什么问题The LLMs Problems 关注的是“如何让模型真正跑起来、稳定出结果、能接进业务”。具体包括模型选择与量化级别之间的取舍。本地推理与云端 API 的切换逻辑。上下文窗口不足时怎么办。显存不够时如何用 CPU 或降低精度推理。不同框架之间接口不兼容怎么对齐。API 服务超时、限流、失败重试怎么设计。ComfyUI 这类外部应用如何通过接口远程调用 LLM。2.3 不适合什么场景需要毫秒级响应的实时系统本地 LLM 推理延迟通常不适合直接做在线客服。对输出准确性有严格要求、且没有人工复核环节的生产流程模型幻觉会造成风险。涉及用户隐私数据、商业机密数据的大规模处理如果没有私有化部署和访问控制不建议直接上云 API。2.4 合规与安全边界使用 LLM 时要特别注意不要将未脱敏的用户数据、内部文档直接传给第三方 API。生成内容的版权归属、误用风险由使用方承担责任。如果涉及人脸、声音、版权素材相关的多模态任务必须确认授权后再处理。本地部署模型不等于绝对安全模型权重、推理日志、接口访问都需要做访问控制。3. LLM 本地部署环境准备3.1 操作系统与基础组件从材料看LLM 本地部署的主流方式分为两种一种是用现成的推理框架直接运行量化模型一种是用 Python 生态加载原始权重。前者部署简单后者灵活度高。无论哪种方式先确认基础环境操作系统LinuxUbuntu/CentOS是主流选择Windows 可以跑但部分框架需要 WSL 或原生工具链。Python 版本建议 3.10 及以上部分框架对 3.12/3.13 的兼容性需要单独确认。包管理工具pip、conda 至少准备一个。Git用于拉取框架源码或模型仓库。3.2 GPU 与驱动检查本地跑模型前先检查显卡驱动和 CUDA 环境是否可用。# 查看显卡型号 nvidia-smi # 查看 CUDA 版本 nvcc --version如果没有 N 卡可以走 CPU 推理路线但速度会慢很多适合小模型和测试场景。如果有 N 卡重点看显存大小这决定了你能跑多大参数量的模型。3.3 磁盘空间模型权重文件体积差异很大7B 模型的量化版大约需要 4GB 到 8GB 磁盘。14B 模型量化版可能需要 10GB 以上。全精度权重体积更大动辄几十 GB。启动前先确认磁盘剩余空间预留至少两倍于模型文件的空间用于缓存下载和日志输出。3.4 端口规划API 服务需要占用端口常见的有 8000、8080、11434、7860 等。启动前检查端口是否被占用。# Linux / macOS lsof -i :8000 # Windows PowerShell netstat -ano | findstr :8000如果端口冲突换一个端口重新启动即可。4. LLM 框架选型与启动方式4.1 主流框架对比框架特点适合场景llama.cpp支持 CPU、GPU 混合推理量化支持好低配设备、边缘部署Ollama安装简单模型拉取方便带 OpenAI 兼容接口快速搭建本地 API 服务vLLM高吞吐推理PagedAttention 优化显存批量请求、服务化部署Transformers生态最全兼容大多数开源模型研究开发、模型评测从材料看Ollama 和 vLLM 是两条典型路线Ollama 偏个人开发与快速验证vLLM 偏服务化和高并发。二选一可以先从 Ollama 开始。4.2 Ollama 快速启动示例Ollama 的模型拉取和启动非常直接。先安装 Ollama然后拉取一个模型# 拉取模型以 Qwen2.5 7B 为例 ollama pull qwen2.5:7b # 启动交互式对话 ollama run qwen2.5:7b启动后可以立即在终端里测试模型的输出效果。Ollama 默认监听 11434 端口并提供一个 OpenAI 兼容的 API 接口。# 查看服务状态 curl http://127.0.0.1:11434/v1/models如果需要调整服务监听地址可以设置环境变量OLLAMA_HOSTexport OLLAMA_HOST0.0.0.0:11434 ollama serve注意监听0.0.0.0表示局域网内其他机器也可以访问生产环境需要配合防火墙或鉴权。4.3 vLLM 服务化启动示例vLLM 更适合需要高吞吐的批量场景。安装后可以用如下方式启动一个 OpenAI 兼容服务# 安装 vLLM pip install vllm # 启动服务 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --host 127.0.0.1 \ --port 8000 \ --gpu-memory-utilization 0.8参数说明--model模型名称或本地路径按实际下载的模型替换。--host监听地址建议本机测试用 127.0.0.1。--port服务端口。--gpu-memory-utilization允许使用的显存比例0.8 表示最多使用 80%。如果显卡显存不足vLLM 会启动失败或触发 OOM需要调低该比例或换更小的量化模型。4.4 Transformers 本地推理示例如果模型是 Hugging Face 格式可以直接用 Transformers 加载from transformers import AutoTokenizer, AutoModelForCausalLM model_name Qwen/Qwen2.5-7B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, device_mapauto) prompt 用一句话解释什么是大模型幻觉。 messages [{role: user, content: prompt}] inputs tokenizer.apply_chat_template(messages, return_tensorspt).to(model.device) outputs model.generate(inputs, max_new_tokens256) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))这种方式适合调试和研究不推荐直接用于高并发服务因为每次请求都占用大量显存且没有自动批处理优化。5. ComfyUI 与 LLM 的资源协同5.1 核心问题必须在同一台电脑上吗这是很多做图像生成的同学最关心的问题。结论是不需要。ComfyUI 本身是图像生成工作流工具它需要独立的 GPU 显存来跑 Stable Diffusion 或 Flux 等图像模型。LLM 推理同样需要大量显存。如果两个任务挤在同一张显卡上很容易出现显存不够用、生成图像时 OOM、跑 LLM 时被抢占资源的情况。更稳妥的做法是方案一同一台机器分时使用。把 ComfyUI 的 LLM 节点配置为远程 API 地址避免两个模型同时占用显存。方案二双机部署。ComfyUI 跑在图像生成机器上LLM 跑在另一台机器或云端 API 上通过 HTTP 接口通信。方案三同一台机器但 LLM 走 CPU 推理。适合小模型和低频调用ComfyUI 独占 GPU。5.2 ComfyUI 调用远程 LLM 的方式多数 ComfyUI 的 LLM 插件或自定义节点支持配置 API Base URL。只要你的 LLM 服务提供了 OpenAI 兼容接口ComfyUI 就可以通过一个 HTTP 请求连接到远程 LLM。典型配置流程在机器 A 启动 LLM API 服务记下地址例如http://192.168.1.100:11434/v1。在 ComfyUI 的 LLM 节点中填写该地址。配置模型名称比如qwen2.5:7b。在 ComfyUI 工作流里调用 LLM 生成提示词再传给图像生成节点。这样设计的好处是图像模型和语言模型互不抢占显存ComfyUI 工作流也能保持稳定。5.3 同机部署时的显存规划如果坚持单机跑两个模型需要先确认显卡显存。以一张 12G 显存显卡为例跑一个 7B 量化 LLM 约占用 6G 到 8G剩余显存再跑图像生成会非常紧张。更合理的方式是先跑 LLM把生成结果保存为文本文件。再启动 ComfyUI读取文本作为提示词。全程不要让两个模型同时驻留显存。如果是 24G 及以上显存可以尝试同时运行但依然建议先观察显存占用确保两个模型的总占用不超过显存上限。6. LLM 功能测试与效果验证6.1 基础生成测试先做最简单的生成测试确认模型能正常输出。以 Ollama 为例ollama run qwen2.5:7b 请用三句话介绍 Flask 框架。判断成功的标准模型能在合理时间内返回内容。输出与问题相关没有明显乱码。没有出现 CUDA OOM 报错。6.2 上下文长度测试测试模型在长文本场景下的表现。可以准备一篇 2000 到 5000 字的文档让模型做摘要。import requests url http://127.0.0.1:11434/api/generate payload { model: qwen2.5:7b, prompt: 请总结以下内容 long_text, stream: False } response requests.post(url, jsonpayload, timeout300) print(response.json().get(response, ))这里要注意 timeout 要设置得足够大长上下文生成经常需要几十秒以上。如果生成中断可能原因是上下文窗口不够或超时机制太短。6.3 幻觉与事实准确性测试可以使用同一个问题问多次观察输出是否稳定。举例问“2024 年巴黎奥运会开幕式的举办日期”这类有明确答案的问题。问“某个不存在的 API 的用法”这类容易产生幻觉的问题。如果模型在不存在的 API 上给出了详细但错误的用法说明模型存在幻觉倾向。生产环境必须增加人工复核或知识库约束。6.4 显存占用测试运行模型时用nvidia-smi观察显存变化。watch -n 1 nvidia-smi重点观察模型加载后的空闲显存占用。生成长文本时的峰值显存。同时跑多个并发请求时显存是否溢出。如果显存溢出可以降低生成长度、减小 batch size或换用更小的量化模型。6.5 稳定性测试连续发送 20 到 50 个请求观察是否有请求超时。服务是否崩溃。显存是否有持续增长即内存泄漏现象。稳定性测试发现服务崩溃时先查服务日志再看是否有进程残留。7. 接口 API 与批量任务7.1 OpenAI 兼容接口调用Ollama 和 vLLM 都提供 OpenAI 兼容接口。调用方式如下import requests url http://127.0.0.1:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: system, content: 你是一个严谨的技术助手。}, {role: user, content: 解释一下什么是 RAG。} ], temperature: 0.7, max_tokens: 512 } response requests.post(url, jsonpayload, timeout120) data response.json() print(data[choices][0][message][content])如果使用 vLLM把url换成http://127.0.0.1:8000/v1/chat/completions即可。7.2 curl 快速测试curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好}] }返回 JSON 中包含choices字段里面就是模型生成的文本。7.3 批量任务设计LLM 批量任务和图像批量任务不一样不能简单地把一堆任务一次性塞进显存。推荐的设计思路输入文件每行一个任务或一个目录下多个文本文件。逐条读取生成请求等待响应。失败请求记录到单独的日志文件稍后重试。控制并发数防止显存溢出。示例代码import json import time import requests API_URL http://127.0.0.1:11434/v1/chat/completions MODEL_NAME qwen2.5:7b def process_task(text): payload { model: MODEL_NAME, messages: [{role: user, content: text}], max_tokens: 512 } resp requests.post(API_URL, jsonpayload, timeout120) resp.raise_for_status() return resp.json()[choices][0][message][content] with open(tasks.jsonl, r, encodingutf-8) as f: tasks [json.loads(line) for line in f if line.strip()] results [] failed [] for task in tasks: try: result process_task(task[prompt]) results.append({id: task[id], result: result}) except Exception as e: failed.append({id: task[id], error: str(e)}) print(f[failed] {task[id]}: {e}) time.sleep(0.5) # 限制请求频率避免压垮本地服务 with open(results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) with open(failed.json, w, encodingutf-8) as f: json.dump(failed, f, ensure_asciiFalse, indent2)7.4 批量任务的重试策略对超时任务做指数退避重试比如第一次等 5 秒第二次等 10 秒。对显存不足OOM的任务暂停一段时间再继续。对已经确认失败且无法恢复的任务单独记录不阻塞后续任务。8. 资源占用与性能观察8.1 显存占用观察方法启动 LLM 服务后在另一个窗口执行nvidia-smi --query-gpuname,memory.used,memory.total,utilization.gpu --formatcsv -l 1每秒刷新一次可以直观看到模型加载后的基线显存、生成过程中的峰值显存以及 GPU 利用率。8.2 CPU 推理与 GPU 推理差异GPU 推理速度快生成流畅但模型大小受显存限制。CPU 推理可跑大模型但速度慢适合无显卡测试场景。混合推理部分框架支持将部分层放到 GPU、部分层放到 CPU牺牲速度换容量。如果只有 CPU建议选择量化级别高的小模型比如 7B 的 Q4 量化版。8.3 影响性能的关键参数模型参数量7B、14B、32B 对显存要求差异巨大。量化级别Q4 比 F16 省显存但输出质量可能有轻微损失。上下文长度长上下文会显著增加显存占用和生成延迟。max_tokens单次生成的最大长度越长等待时间越久。并发数并发请求越多显存和内存消耗越大。temperature影响生成多样性不影响性能但调高后结果不稳定。8.4 降低显存占用的方法使用量化模型比如 Q4_K_M、Q5_K_M。降低max_tokens和上下文长度。关闭流式输出或用流式输出但不在服务端缓存全部结果。减少并发请求数。使用 vLLM 的连续批处理特性而不是自己开多个进程。9. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后页面/接口打不开端口被占用或服务未启动查看服务日志和端口状态更换端口或重启服务显存不足 OOM模型太大或并发过高nvidia-smi 查看显存占用换量化模型、降低并发、减小上下文模型下载失败网络问题或存储空间不足检查磁盘和网络连接清理磁盘或用离线包导入生成速度极慢CPU 推理或上下文过长看硬件利用率和生成日志换 GPU 或减小上下文长度输出乱码模型权重损坏或 tokenizer 不匹配重新加载模型删除缓存重新下载API 请求超时timeout 设置过短或服务繁忙查看服务日志调大 timeout限制并发批量任务中途卡住单任务异常未处理检查失败日志加异常捕获和重试机制显存持续增长服务存在内存泄漏连续请求后观察内存定期重启服务或升级框架版本多个应用端口冲突启动参数未指定端口lsof 或 netstat 查看换用不同端口敏感信息泄露风险接口无鉴权、监听 0.0.0.0检查监听地址和访问日志加鉴权、限制 IP、用内网部署10. 最佳实践与使用建议10.1 部署阶段第一次测试先跑最小模型确认环境通了再换大模型。保留一套完整的启动命令和配置方便复现。模型文件、输入素材、输出结果分目录管理不要混在一起。每次换模型前记录显存基线和生成延迟方便横向对比。10.2 批量任务阶段批量任务一定要加日志记录每个任务的耗时和结果。失败任务要自动写入单独文件不要中断整个队列。控制并发数优先保证任务不失败再追求速度。批量任务跑完后检查失败文件重试确认失败的请求。10.3 接口服务阶段API 服务只监听内网地址不要直接暴露到公网。需要外部接入时加一层 API Key 鉴权。上游接入方要做好超时和降级方案LLM 服务不可用时不影响主流程。定期查看访问日志防止接口被滥用。10.4 内容安全阶段模型生成的代码、文档、图片描述都需要人工复核后使用。涉及用户隐私、商业数据的内容优先本地部署并对日志脱敏。涉及人脸、声音、版权素材的多模态内容必须确认授权。商用前建议做一轮效果测试确认输出质量满足业务要求。11. 总结与下一步The LLMs Problems 最值得做的事不是到处收集模型而是先把“问题清单”过一遍。先确认显卡显存能跑什么模型再选一个最顺手的框架然后从单次生成测试开始逐步过渡到 API 服务和批量任务。最先要验证的是你的硬件能不能稳定跑通一个 7B 量化模型。这个目标不达成后面所有框架、接口、批量任务都无从谈起。最容易踩的坑有三类一是模型和显存不匹配启动就 OOM二是长文本生成没设置足够长的 timeout任务中途断掉三是批量任务缺少异常处理一个失败任务把整个队列卡死。后续可以扩展的方向很多接入 RAG 做知识库问答、把 LLM 接到 ComfyUI 做自动化提示词生成、用 vLLM 做高并发服务化部署、用流式输出做打字机效果。每一步都值得单独开一篇文章细讲。建议把这篇文章收藏备用动手部署时对照着检查能省下不少排查时间。