拓冰网站定制 
实验室里一个原本用于内部文档整理的 LLM 服务突然被大量非预期请求打满。GPU 占用翻倍输出目录里多出很多没有来源标记的文件内部接口的调用频率也明显异常。排查后发现问题不是模型本身不行而是服务暴露得过于随意、没有身份认证、也没有速率控制。团队当时的第一反应是下线这个服务但第二反应更值得记录既然 LLM 已经在实验室里跑起来了为什么不能把它放进受控环境让它真正为实验室干活这篇文章就把这次从“风险源”到“工作流组件”的过程拆开来讲同时会回答一个很多人问过的问题ComfyUI 与 LLM 是否必须放在同一台电脑上。1. 事件复盘实验室里的 LLM 为什么会从工具变成麻烦很多团队都会遇到类似的情况为了测试方便直接在服务器上起了一个 LLM 服务监听地址写的是0.0.0.0谁都能访问甚至没有加任何身份校验。一开始只是几个人在测试流量不大问题不会暴露。但一旦服务被外部扫描器发现或者内部脚本因为配置错误开始疯狂调用服务器很快就会被拖垮。1.1 先看现象日志、资源占用和请求来源发现异常时不要急着杀进程。先保留现场按下面顺序看一眼服务日志里有哪些请求路径请求体是什么。请求来源是哪些 IP是走内网还是经过公网入口进来的。输出目录里是否有新文件文件命名是否符合预期。用nvidia-smi或系统监控工具查看 GPU 显存、内存和 CPU 占用曲线。查看进程列表和网络连接确认是否存在重复启动的实例。我当时的排查结果很明确大量请求都没有经过内部认证网关请求内容也明显不是团队主动提交的任务。这说明问题出在服务暴露和访问控制上而不是模型输出异常。先把入口和日志冻结再决定下一步。1.2 堵住非预期调用的第一步不是换模型遇到这种情况很多人的第一反应是换一个更强的模型这其实是错的方向。只要服务入口还是开放的换再强的模型也一样会被滥用。正确做法是先把访问链路收住停止监听在0.0.0.0改成只监听127.0.0.1或者放在内网网关后面。所有请求必须带 API Key 或者走统一的内部认证。加上速率限制避免单个来源把 GPU 占满。对输出目录和模型目录做权限隔离只允许指定服务账号读写。这些动作看起来不复杂但很有效。第一次做的时候可能会遇到一个问题服务改成监听本机之后原先通过局域网访问的同事都会连不上。这是好事说明访问入口确实收到了。后面如果需要跨机器调用再通过受控的 API 网关拨通而不是直接把端口暴露出去。1.3 为什么这个案例没有变成安全事故这次事件最终没有造成真正严重的问题有几个原因发现及时请求还没有大规模把数据带出内网。模型跑在本地没有把内部文档发到外部 API。日志和磁盘记录都在后续可以追溯请求来源。团队没有删日志保留了完整的过程数据。想强调一点日志不是用来应付审计的而是出了问题后能快速定位的第一手材料。实验室环境里宁可多留一点请求记录也不要为了省磁盘空间把日志周期调得太短。2. 从隔离到复用让 LLM 在受控环境里为实验室干活事件处理完之后团队面临一个选择是彻底关掉这个 LLM 服务还是重新把它纳管起来我们选了后者。原因很简单实验室里确实有大量文本处理需求几个同事之前已经依赖这个服务做文档摘要和日志整理。彻底关掉效率会明显下降。关键是把它放进一套受控规则里。2.1 重新定义使用场景什么活儿适合交给 LLM不是所有任务都适合用 LLM。我们在复用的第一阶段先列了一张任务清单实验记录摘要给每次实验的文本记录生成三行摘要。日志分类把系统日志粗分为“可忽略”“需要关注”“需要人工确认”三档。文档格式整理把杂乱文本按固定结构整理成简单字段。脚本生成建议用 LLM 生成一个初版 Python 脚本再由人来审核和修改。不适合的任务也很明确涉及敏感数据且未脱敏处理的文本不能直接交给 LLM数值计算和精确统计不能靠 LLM需要严格可复现的流程也不能把 LLM 输出当成最终结果。背后的逻辑是LLM 的输出有概率性同一段文本给两次结果可能不一样。所以它适合做辅助、分类、摘要、初稿不适合做最终判断。任何自动化流程里都要留一个人工复核的位置。2.2 选型不是越新越好本地框架要考虑依赖和资源很多人在选型时只看模型能力忽略了运行环境的约束。实验室服务器往往已经跑了数据库、监控、ComfyUI 等一堆服务GPU 显存和内存都有限。再塞一个重框架很容易把整台机器拖垮。给一个通用判断思路如果显存在 8GB 以下优先考虑轻量量化和低上下文长度。先保证能稳定跑通再考虑效果。如果显存 16GB 以上可以考虑更完整的本地推理框架但仍然要关注并发请求数量。如果有多卡服务器再考虑并行部署。单卡别硬撑。安装依赖前先确认能否装进现有 Python 或 Docker 环境避免依赖冲突。框架本身没有绝对的好坏关键在于是否匹配你的硬件和任务类型。实验室里够用就好不需要盲目追求最新版本。2.3 受控环境的核心参数端口、认证、模型路径以常见本地框架为例一个受控的 LLM 服务配置至少会包含下面这些字段service: host: 127.0.0.1 port: 11434 auth: internal-api-key model: path: /data/models/your-model context_length: 4096 gpu_layers: 24 security: max_requests_per_minute: 20 allow_origins: - http://127.0.0.1这里的核心不是端口和模型路径而是auth和max_requests_per_minute。没有认证入口就是开的没有速率限制一次误操作就可能把显存占满。至于具体字段名不同框架有差异落地时以你自己部署的框架文档为准。关键是理解每一项的作用而不是照抄。调用端可以先用一个简单的 curl 验证curl -X POST http://127.0.0.1:11434/api/generate \ -H Authorization: Bearer $API_KEY \ -d {model:your-model,prompt:请把这句话压缩成十个字以内的摘要}能返回正常结果再继续搭工作流。3. ComfyUI 与 LLM 是否必须同一台电脑部署边界和通信方式这个问题在社区里被问过很多次。先给结论不必须。ComfyUI 和 LLM 本质上都是本地服务它们可以放在同一台电脑里也可以分开部署各有取舍。3.1 ComfyUI 和 LLM 在同一台电脑上的典型情况很多人会在一台 GPU 工作站上同时跑 ComfyUI 和 LLM。ComfyUI 用于图像生成工作流LLM 用于写提示词、做图后描述、整理参数列表。单从功能上看这样很方便配置简单API 调用延迟也很低。但有一个很现实的坑显存。ComfyUI 加载图像模型会占显存LLM 推理也会占显存。如果两个服务同时加载模型很容易触发CUDA out of memory。尤其是 ComfyUI 里跑大分辨率图像时显存峰值会非常明显。这时候就算两个服务都能正常启动实际使用体验也会很差。如果你只是在做少量测试同机部署完全可行。方法是把两个服务都设置为按需加载模型或者分开时间段使用比如白天跑 ComfyUI晚上跑 LLM 批处理任务。3.2 分离部署时最需要确认的三件事如果你的设备有多台机器或者不想让图形任务和文本推理互相挤占资源分开部署是更稳的方案。但分离不是简单把另一台机器装上服务就行还要注意三件事网络连通性。ComfyUI 所在机器要能访问 LLM 服务的 API 地址跨机器调用时要确认防火墙、端口、API Key 都配置正确。数据边界。如果图片描述、提示词、生成结果要发给另一台机器上的 LLM要确认这些文本是否允许离开当前机器。内部敏感数据尽量不要跨机器传输。超时和并发。跨机器调用会有网络延迟批量任务时要调大超时时间并且做好失败重试否则很容易出现一部分任务失败。3.3 同机部署与分离部署对比部署方式优点缺点适合场景同机部署配置简单API 延迟低数据不离开本机显存和内存共享同时跑容易互相挤占单机测试、轻量任务、显存充足分离部署资源独立互不影响可以单独扩容配置更复杂网络延迟高需要管理权限批量任务、多人使用、长期稳定运行如果你的显卡只有一块且显存不大建议先用同机部署把流程跑通。如果发现任务经常因为显存不足失败再考虑把 LLM 或 ComfyUI 拆到另一台机器上。4. 把 LLM 接入实验室工作流的四个落地步骤事件处理完、服务也重新受控之后真正花时间的部分是把它接入现有工作流。这里不建议一上来就写完整系统。先做一条最简单的链路确认能跑通再逐步加东西。4.1 输入输出定义先画一条最简单的链路以“批量生成实验笔记摘要”为例。链路很简单输入一个文件夹里面有若干文本文件输出是另一个文件夹每个文件对应一个摘要文件。需要提前定好的东西有输入文件路径和输出文件路径。临时文件存放目录。支持的编码格式比如 UTF-8。摘要长度比如限制在 200 字以内。失败标记处理失败时写一个单独的错误文件不算成功。这条链路不用考虑复杂的并行先顺序跑。目的是确认模型、接口、目录权限、日志都能正常工作。4.2 用脚本串起数据流而不是用手敲实验环境里不建议每天手动复制粘贴文本到浏览器里跑。把过程写成脚本可重复执行也方便加日志。下面是一个通用示例框架import pathlib import requests API_URL http://127.0.0.1:11434/api/generate HEADERS {Authorization: Bearer API_KEY} def summarize_file(input_path: pathlib.Path, output_path: pathlib.Path) - bool: text input_path.read_text(encodingutf-8, errorsignore) if len(text.strip()) 10: return False payload { model: your-model, prompt: f请把下面的实验日志压缩成 200 字以内的摘要\n{text}, stream: False, } try: resp requests.post(API_URL, jsonpayload, headersHEADERS, timeout60) resp.raise_for_status() result resp.json() summary result.get(response, ) output_path.write_text(summary, encodingutf-8) return True except Exception as exc: print(f[ERROR] {input_path.name}: {exc}) return False这段代码只作为链路示例实际接口字段以你部署的框架为准。重点不是代码本身而是要保证每个文件处理成功或失败都有明确结果不会因为一个文件报错就中断整个任务。4.3 批处理与失败重试稳定性的基础批量任务比单条任务复杂主要复杂在失败重试和输出命名。建议按这个顺序做先拿 3 个样本文件跑一遍确认模型和接口正常。再处理全部文件但始终保留输入文件不动只写输出目录。输出文件名带上源文件名和时间戳避免重复运行互相覆盖。设置失败重试次数比如每个文件最多试 2 次。把失败任务和成功任务分开记录方便二次处理。还有一个容易忽略的点批量任务不要一上来就开很大并发。尤其在同一台 GPU 上并发过大会导致显存溢出或响应超时。先开 1 个并发跑一段时间观察 GPU 利用率再慢慢增大。4.4 日志和审计出了问题能追到请求自动化流程跑久了总会有一次输出异常。如果没有日志排查会非常痛苦。每条请求建议记录请求时间。输入文件路径。模型名称。响应状态。处理耗时。输出文件路径。失败原因。日志不需要很复杂一个文本文件或者 CSV 就行。关键是每次处理都有记录。出现问题时先查日志不要盲目重跑全部任务。5. 实际运行中的稳定性判断与排查链路LLM 服务部署好之后不能只看能不能启动还要看长时间运行稳不稳定。这里说几个我自己会重点盯的指标和排查顺序。5.1 稳定性指标响应时间、成功率、资源占用判断服务是否稳定不要靠感觉。不同规模的任务选几个指标看指标定义可接受的参考范围单次请求耗时从发送请求到收到完整响应的时间根据模型和显存变化通常几秒到几十秒成功率成功处理任务数 / 总任务数批量任务建议 95% 以上显存占用推理过程中 GPU 显存峰值不超过显卡总显存的 85%内存占用进程使用的系统内存观察是否持续增长输出一致性相同输入多次输出是否在可接受范围内摘要类任务允许语义一致但措辞不同如果一个任务经常超时先看上下文长度是不是太长再看并发是不是太高。如果内存持续增长可能是有内存泄漏不要忽略跑久了会很麻烦。5.2 常见故障和优先排查顺序我遇到的常见现象有三种任务卡住、输出为空、速度越来越慢。遇到问题时按这个顺序排查看服务日志。是否有超时、连接拒绝、模型加载失败等记录。看输入文件。编码是不是 UTF-8路径是否存在文件内容是否为空。看环境。GPU 是否被其他进程占满磁盘是否写满权限是否正确。看参数。上下文长度、超时时间、并发数是否设置合理。最后看框架兼容。是不是某个版本更新后接口字段变了。很多问题最后都出在输入文件编码和路径权限上尤其是 Windows 和 Linux 之间的目录分隔符、中文文件名、换行符差异。先排除这些基础因素再动模型参数。5.3 LLM 与 ComfyUI 同机时的显存分配建议如果你选择同机部署给几条具体建议不要让两个服务同时加载大模型。优先调整 ComfyUI 的 batch size 和分辨率先降低显存峰值。给 LLM 框架设置显存上限避免它把显存全部占满。使用watch -n 1 nvidia-smi观察两个进程的显存占用变化。如果频繁报显存不足就接受现实换更大显存的机器或者拆分部署。显存分配这种问题没有绝对参数因为不同模型、不同图像分辨率差别很大。关键是观察任务高峰时的显存曲线再决定怎么限制并发和批次。6. 可复用的实验室级 LLM 配置清单最后给一份我们整理后一直在用的配置清单。按照这份清单新机器部署时能少踩很多坑。6.1 服务端最小配置参考配置项建议值说明监听地址127.0.0.1默认不对外暴露端口独立端口避免和已有服务冲突例如 11434 或其他空闲端口身份认证API Key所有请求必须带 Key速率限制按业务量调整防止误操作打满资源模型路径单独目录不用根目录方便备份和权限隔离上下文长度4096 起步根据显存调整日志路径和代码目录分离方便日志轮转6.2 安全基线配置不开放任何无认证的公共端口。默认只监听本机跨机器调用走内部网关。API Key 定期轮换不要写在代码仓库里放到环境变量或密钥管理工具。所有请求都走日志日志保留至少一个月。敏感数据和未脱敏文本不进入 LLM prompt。模型文件和输出目录设置独立权限禁止普通用户随意读写。6.3 日常使用和维护建议改模型或改参数前先备份当前配置。小样本验证通过后再跑完整批量任务。批量任务运行期间定期看一次显存和成功率。每次跑完后检查输出目录里的失败记录不要直接忽略。不要轻易把实验数据发给外部 API本地能完成的任务就留在本地。这次事件给我最大的教训不是 LLM 本身带来多大风险而是任何本地服务只要缺少身份认证和访问控制都可能从帮手变成问题。反过来只要把入口收紧、资源限制好、日志留下来LLM 完全可以在实验室里稳定服务。至于 ComfyUI 和 LLM 要不要放在同一台电脑我的建议是先看显存和并发别急着照搬别人的部署。 从风险源到工作流组件：LLM安全部署与ComfyUI同机实践
实验室里一个原本用于内部文档整理的 LLM 服务突然被大量非预期请求打满。GPU 占用翻倍输出目录里多出很多没有来源标记的文件内部接口的调用频率也明显异常。排查后发现问题不是模型本身不行而是服务暴露得过于随意、没有身份认证、也没有速率控制。团队当时的第一反应是下线这个服务但第二反应更值得记录既然 LLM 已经在实验室里跑起来了为什么不能把它放进受控环境让它真正为实验室干活这篇文章就把这次从“风险源”到“工作流组件”的过程拆开来讲同时会回答一个很多人问过的问题ComfyUI 与 LLM 是否必须放在同一台电脑上。1. 事件复盘实验室里的 LLM 为什么会从工具变成麻烦很多团队都会遇到类似的情况为了测试方便直接在服务器上起了一个 LLM 服务监听地址写的是0.0.0.0谁都能访问甚至没有加任何身份校验。一开始只是几个人在测试流量不大问题不会暴露。但一旦服务被外部扫描器发现或者内部脚本因为配置错误开始疯狂调用服务器很快就会被拖垮。1.1 先看现象日志、资源占用和请求来源发现异常时不要急着杀进程。先保留现场按下面顺序看一眼服务日志里有哪些请求路径请求体是什么。请求来源是哪些 IP是走内网还是经过公网入口进来的。输出目录里是否有新文件文件命名是否符合预期。用nvidia-smi或系统监控工具查看 GPU 显存、内存和 CPU 占用曲线。查看进程列表和网络连接确认是否存在重复启动的实例。我当时的排查结果很明确大量请求都没有经过内部认证网关请求内容也明显不是团队主动提交的任务。这说明问题出在服务暴露和访问控制上而不是模型输出异常。先把入口和日志冻结再决定下一步。1.2 堵住非预期调用的第一步不是换模型遇到这种情况很多人的第一反应是换一个更强的模型这其实是错的方向。只要服务入口还是开放的换再强的模型也一样会被滥用。正确做法是先把访问链路收住停止监听在0.0.0.0改成只监听127.0.0.1或者放在内网网关后面。所有请求必须带 API Key 或者走统一的内部认证。加上速率限制避免单个来源把 GPU 占满。对输出目录和模型目录做权限隔离只允许指定服务账号读写。这些动作看起来不复杂但很有效。第一次做的时候可能会遇到一个问题服务改成监听本机之后原先通过局域网访问的同事都会连不上。这是好事说明访问入口确实收到了。后面如果需要跨机器调用再通过受控的 API 网关拨通而不是直接把端口暴露出去。1.3 为什么这个案例没有变成安全事故这次事件最终没有造成真正严重的问题有几个原因发现及时请求还没有大规模把数据带出内网。模型跑在本地没有把内部文档发到外部 API。日志和磁盘记录都在后续可以追溯请求来源。团队没有删日志保留了完整的过程数据。想强调一点日志不是用来应付审计的而是出了问题后能快速定位的第一手材料。实验室环境里宁可多留一点请求记录也不要为了省磁盘空间把日志周期调得太短。2. 从隔离到复用让 LLM 在受控环境里为实验室干活事件处理完之后团队面临一个选择是彻底关掉这个 LLM 服务还是重新把它纳管起来我们选了后者。原因很简单实验室里确实有大量文本处理需求几个同事之前已经依赖这个服务做文档摘要和日志整理。彻底关掉效率会明显下降。关键是把它放进一套受控规则里。2.1 重新定义使用场景什么活儿适合交给 LLM不是所有任务都适合用 LLM。我们在复用的第一阶段先列了一张任务清单实验记录摘要给每次实验的文本记录生成三行摘要。日志分类把系统日志粗分为“可忽略”“需要关注”“需要人工确认”三档。文档格式整理把杂乱文本按固定结构整理成简单字段。脚本生成建议用 LLM 生成一个初版 Python 脚本再由人来审核和修改。不适合的任务也很明确涉及敏感数据且未脱敏处理的文本不能直接交给 LLM数值计算和精确统计不能靠 LLM需要严格可复现的流程也不能把 LLM 输出当成最终结果。背后的逻辑是LLM 的输出有概率性同一段文本给两次结果可能不一样。所以它适合做辅助、分类、摘要、初稿不适合做最终判断。任何自动化流程里都要留一个人工复核的位置。2.2 选型不是越新越好本地框架要考虑依赖和资源很多人在选型时只看模型能力忽略了运行环境的约束。实验室服务器往往已经跑了数据库、监控、ComfyUI 等一堆服务GPU 显存和内存都有限。再塞一个重框架很容易把整台机器拖垮。给一个通用判断思路如果显存在 8GB 以下优先考虑轻量量化和低上下文长度。先保证能稳定跑通再考虑效果。如果显存 16GB 以上可以考虑更完整的本地推理框架但仍然要关注并发请求数量。如果有多卡服务器再考虑并行部署。单卡别硬撑。安装依赖前先确认能否装进现有 Python 或 Docker 环境避免依赖冲突。框架本身没有绝对的好坏关键在于是否匹配你的硬件和任务类型。实验室里够用就好不需要盲目追求最新版本。2.3 受控环境的核心参数端口、认证、模型路径以常见本地框架为例一个受控的 LLM 服务配置至少会包含下面这些字段service: host: 127.0.0.1 port: 11434 auth: internal-api-key model: path: /data/models/your-model context_length: 4096 gpu_layers: 24 security: max_requests_per_minute: 20 allow_origins: - http://127.0.0.1这里的核心不是端口和模型路径而是auth和max_requests_per_minute。没有认证入口就是开的没有速率限制一次误操作就可能把显存占满。至于具体字段名不同框架有差异落地时以你自己部署的框架文档为准。关键是理解每一项的作用而不是照抄。调用端可以先用一个简单的 curl 验证curl -X POST http://127.0.0.1:11434/api/generate \ -H Authorization: Bearer $API_KEY \ -d {model:your-model,prompt:请把这句话压缩成十个字以内的摘要}能返回正常结果再继续搭工作流。3. ComfyUI 与 LLM 是否必须同一台电脑部署边界和通信方式这个问题在社区里被问过很多次。先给结论不必须。ComfyUI 和 LLM 本质上都是本地服务它们可以放在同一台电脑里也可以分开部署各有取舍。3.1 ComfyUI 和 LLM 在同一台电脑上的典型情况很多人会在一台 GPU 工作站上同时跑 ComfyUI 和 LLM。ComfyUI 用于图像生成工作流LLM 用于写提示词、做图后描述、整理参数列表。单从功能上看这样很方便配置简单API 调用延迟也很低。但有一个很现实的坑显存。ComfyUI 加载图像模型会占显存LLM 推理也会占显存。如果两个服务同时加载模型很容易触发CUDA out of memory。尤其是 ComfyUI 里跑大分辨率图像时显存峰值会非常明显。这时候就算两个服务都能正常启动实际使用体验也会很差。如果你只是在做少量测试同机部署完全可行。方法是把两个服务都设置为按需加载模型或者分开时间段使用比如白天跑 ComfyUI晚上跑 LLM 批处理任务。3.2 分离部署时最需要确认的三件事如果你的设备有多台机器或者不想让图形任务和文本推理互相挤占资源分开部署是更稳的方案。但分离不是简单把另一台机器装上服务就行还要注意三件事网络连通性。ComfyUI 所在机器要能访问 LLM 服务的 API 地址跨机器调用时要确认防火墙、端口、API Key 都配置正确。数据边界。如果图片描述、提示词、生成结果要发给另一台机器上的 LLM要确认这些文本是否允许离开当前机器。内部敏感数据尽量不要跨机器传输。超时和并发。跨机器调用会有网络延迟批量任务时要调大超时时间并且做好失败重试否则很容易出现一部分任务失败。3.3 同机部署与分离部署对比部署方式优点缺点适合场景同机部署配置简单API 延迟低数据不离开本机显存和内存共享同时跑容易互相挤占单机测试、轻量任务、显存充足分离部署资源独立互不影响可以单独扩容配置更复杂网络延迟高需要管理权限批量任务、多人使用、长期稳定运行如果你的显卡只有一块且显存不大建议先用同机部署把流程跑通。如果发现任务经常因为显存不足失败再考虑把 LLM 或 ComfyUI 拆到另一台机器上。4. 把 LLM 接入实验室工作流的四个落地步骤事件处理完、服务也重新受控之后真正花时间的部分是把它接入现有工作流。这里不建议一上来就写完整系统。先做一条最简单的链路确认能跑通再逐步加东西。4.1 输入输出定义先画一条最简单的链路以“批量生成实验笔记摘要”为例。链路很简单输入一个文件夹里面有若干文本文件输出是另一个文件夹每个文件对应一个摘要文件。需要提前定好的东西有输入文件路径和输出文件路径。临时文件存放目录。支持的编码格式比如 UTF-8。摘要长度比如限制在 200 字以内。失败标记处理失败时写一个单独的错误文件不算成功。这条链路不用考虑复杂的并行先顺序跑。目的是确认模型、接口、目录权限、日志都能正常工作。4.2 用脚本串起数据流而不是用手敲实验环境里不建议每天手动复制粘贴文本到浏览器里跑。把过程写成脚本可重复执行也方便加日志。下面是一个通用示例框架import pathlib import requests API_URL http://127.0.0.1:11434/api/generate HEADERS {Authorization: Bearer API_KEY} def summarize_file(input_path: pathlib.Path, output_path: pathlib.Path) - bool: text input_path.read_text(encodingutf-8, errorsignore) if len(text.strip()) 10: return False payload { model: your-model, prompt: f请把下面的实验日志压缩成 200 字以内的摘要\n{text}, stream: False, } try: resp requests.post(API_URL, jsonpayload, headersHEADERS, timeout60) resp.raise_for_status() result resp.json() summary result.get(response, ) output_path.write_text(summary, encodingutf-8) return True except Exception as exc: print(f[ERROR] {input_path.name}: {exc}) return False这段代码只作为链路示例实际接口字段以你部署的框架为准。重点不是代码本身而是要保证每个文件处理成功或失败都有明确结果不会因为一个文件报错就中断整个任务。4.3 批处理与失败重试稳定性的基础批量任务比单条任务复杂主要复杂在失败重试和输出命名。建议按这个顺序做先拿 3 个样本文件跑一遍确认模型和接口正常。再处理全部文件但始终保留输入文件不动只写输出目录。输出文件名带上源文件名和时间戳避免重复运行互相覆盖。设置失败重试次数比如每个文件最多试 2 次。把失败任务和成功任务分开记录方便二次处理。还有一个容易忽略的点批量任务不要一上来就开很大并发。尤其在同一台 GPU 上并发过大会导致显存溢出或响应超时。先开 1 个并发跑一段时间观察 GPU 利用率再慢慢增大。4.4 日志和审计出了问题能追到请求自动化流程跑久了总会有一次输出异常。如果没有日志排查会非常痛苦。每条请求建议记录请求时间。输入文件路径。模型名称。响应状态。处理耗时。输出文件路径。失败原因。日志不需要很复杂一个文本文件或者 CSV 就行。关键是每次处理都有记录。出现问题时先查日志不要盲目重跑全部任务。5. 实际运行中的稳定性判断与排查链路LLM 服务部署好之后不能只看能不能启动还要看长时间运行稳不稳定。这里说几个我自己会重点盯的指标和排查顺序。5.1 稳定性指标响应时间、成功率、资源占用判断服务是否稳定不要靠感觉。不同规模的任务选几个指标看指标定义可接受的参考范围单次请求耗时从发送请求到收到完整响应的时间根据模型和显存变化通常几秒到几十秒成功率成功处理任务数 / 总任务数批量任务建议 95% 以上显存占用推理过程中 GPU 显存峰值不超过显卡总显存的 85%内存占用进程使用的系统内存观察是否持续增长输出一致性相同输入多次输出是否在可接受范围内摘要类任务允许语义一致但措辞不同如果一个任务经常超时先看上下文长度是不是太长再看并发是不是太高。如果内存持续增长可能是有内存泄漏不要忽略跑久了会很麻烦。5.2 常见故障和优先排查顺序我遇到的常见现象有三种任务卡住、输出为空、速度越来越慢。遇到问题时按这个顺序排查看服务日志。是否有超时、连接拒绝、模型加载失败等记录。看输入文件。编码是不是 UTF-8路径是否存在文件内容是否为空。看环境。GPU 是否被其他进程占满磁盘是否写满权限是否正确。看参数。上下文长度、超时时间、并发数是否设置合理。最后看框架兼容。是不是某个版本更新后接口字段变了。很多问题最后都出在输入文件编码和路径权限上尤其是 Windows 和 Linux 之间的目录分隔符、中文文件名、换行符差异。先排除这些基础因素再动模型参数。5.3 LLM 与 ComfyUI 同机时的显存分配建议如果你选择同机部署给几条具体建议不要让两个服务同时加载大模型。优先调整 ComfyUI 的 batch size 和分辨率先降低显存峰值。给 LLM 框架设置显存上限避免它把显存全部占满。使用watch -n 1 nvidia-smi观察两个进程的显存占用变化。如果频繁报显存不足就接受现实换更大显存的机器或者拆分部署。显存分配这种问题没有绝对参数因为不同模型、不同图像分辨率差别很大。关键是观察任务高峰时的显存曲线再决定怎么限制并发和批次。6. 可复用的实验室级 LLM 配置清单最后给一份我们整理后一直在用的配置清单。按照这份清单新机器部署时能少踩很多坑。6.1 服务端最小配置参考配置项建议值说明监听地址127.0.0.1默认不对外暴露端口独立端口避免和已有服务冲突例如 11434 或其他空闲端口身份认证API Key所有请求必须带 Key速率限制按业务量调整防止误操作打满资源模型路径单独目录不用根目录方便备份和权限隔离上下文长度4096 起步根据显存调整日志路径和代码目录分离方便日志轮转6.2 安全基线配置不开放任何无认证的公共端口。默认只监听本机跨机器调用走内部网关。API Key 定期轮换不要写在代码仓库里放到环境变量或密钥管理工具。所有请求都走日志日志保留至少一个月。敏感数据和未脱敏文本不进入 LLM prompt。模型文件和输出目录设置独立权限禁止普通用户随意读写。6.3 日常使用和维护建议改模型或改参数前先备份当前配置。小样本验证通过后再跑完整批量任务。批量任务运行期间定期看一次显存和成功率。每次跑完后检查输出目录里的失败记录不要直接忽略。不要轻易把实验数据发给外部 API本地能完成的任务就留在本地。这次事件给我最大的教训不是 LLM 本身带来多大风险而是任何本地服务只要缺少身份认证和访问控制都可能从帮手变成问题。反过来只要把入口收紧、资源限制好、日志留下来LLM 完全可以在实验室里稳定服务。至于 ComfyUI 和 LLM 要不要放在同一台电脑我的建议是先看显存和并发别急着照搬别人的部署。