这两天 AI 圈有一场争论值得技术人停下来看一眼一边是前 OpenAI 研究员公开看空大模型公司认为训练成本、推理成本和开源追赶会让这轮商业模式走到尽头另一边是 Dwarkesh 的回应——AGI 会自己找工作。这句话听起来像概念炒作但拆开看它其实在说大模型的价值不在于“卖模型”而在于“能不能直接干活、干完活自动结算”。这篇文章不站队只做三件事把两边的论点拆成可验证的事实把“AGI 找工作”翻译成工程问题再给一套从本地部署到 API 接入再到批量任务的落地路径。无论你是做大模型应用开发、模型部署还是关心 Agent 方向成本控制都可以顺着这条链路跑一遍确认哪些说法是真实的哪些还停留在预期里。先给结论这场争论短期内不会影响你看得见摸得着的技术选型。但“AGI 会自己找工作”一旦落地它对工程架构的要求会非常具体——模型需要有工具调用能力服务需要稳定暴露 API任务需要支持批量执行资源占用需要可观测。这些才是真正值得提前准备的东西。1. 核心议题速览维度说明争议焦点大模型公司是否具有长期商业价值看空方观点前 OpenAI 研究员理由集中在训练/推理成本、API 降价、开源模型追赶反驳方观点AGI 会自己找工作价值从“卖模型订阅”转向“按任务结算”本质技术问题大模型能否从聊天工具演变为可自主拆解、执行、验证任务的 Agent本文关注的技术链路本地部署 - API 接入 - 批量任务 - 资源监控适合读者AI 应用开发、模型部署、成本优化、Agent 方向工程师这场争论表面上讨论的是投资逻辑实际上讨论的是技术路线大模型公司的护城河到底是“模型参数”还是“模型与真实工作流之间的连接能力”从工程角度看后者更值得押注。因为模型能力会被开源追赶但一个已经跑通的任务闭环替换成本远高于替换一个模型权重。所以这篇文章把重点放在“怎么把模型变成能干活的服务”上。先看争论双方到底在争什么再落到技术实操。2. 这场争论到底在争什么2.1 看空大模型公司的三条核心理由看空方最核心的判断是大模型公司的成本结构撑不起当前估值。训练一次前沿模型需要数万张 GPU 和数月时间推理阶段每次请求也要消耗大量算力。如果用户付费意愿跟不上算力消耗商业模型就很难闭环。第二点是 API 价格战。过去两年主流模型 API 的价格下降速度非常快尤其是在开源模型能力追上来之后闭源模型不再拥有绝对的定价权。价格下降对开发者是好事但对靠卖 API 算收入的公司来说意味着单用户价值在缩水。第三点是开源模型的追赶。7B、14B 量级的开源模型在通用对话、文本处理、代码生成上已经能做到接近商用模型的体验。很多企业和开发者开始优先尝试本地部署这直接削弱了“必须订阅闭源模型”的刚性需求。这三条理由放在一起结论指向一个方向如果把大模型公司当成“卖模型的公司”它的长期利润率确实需要打问号。2.2 反驳方AGI 会自己找工作Dwarkesh 的回应则换了一个坐标系不要只看“卖模型”的生意要看 AGI 能不能直接创造劳动力价值。“AGI 会自己找工作”的意思是未来的 AI 不是一个被动的 API而是一个能主动接任务、调用工具、完成交付并产生经济回报的 Agent。这个论点成立的前提是模型必须从“生成文字”进化到“完成任务”。任务意味着目标、步骤、工具、验证和交付。比如你让它“查一下这周服务器日志里的错误并汇总成报告”它需要先调用日志查询工具再分析结果最后生成报告。这个过程不是一次对话而是一个包含多个步骤的工作流。如果这个闭环能稳定跑通AI 的价值就不受“订阅费”限制而是可以直接按任务结算。到那时大模型公司卖的不是模型而是能够完成任务的劳动力。这是两种完全不同的商业模式也是反驳方认为看空逻辑不成立的根本原因。2.3 技术人应该怎么看待这场争论作为工程师不需要急着站队但可以从这场争论里提炼出技术方向模型能力会持续增强但真正的应用瓶颈在于如何把模型接入真实系统。争论双方都没有否认 AGI 长期存在只是对商业路径判断不同。对开发者来说这意味着两件事第一模型选型要保留可替换性不要被某一家绑定第二要把精力放在任务编排、工具调用、批量执行这些通用工程能力上这些能力不管哪个模型胜出都能复用。换句话说这场争论真正值得关注的问题是你的系统是否已经具备让模型“干活”的基础设施如果没有现在开始搭比争论 AGI 什么时候到来更有意义。3. 把“AGI 会自己找工作”拆成工程问题3.1 模型能力只是起点“AGI 会自己找工作”听上去是单一模型的能力但工程上它需要一整套系统支撑。模型本身负责理解自然语言、生成计划、产生输出真正让“找工作”成立的是任务执行环境模型能看到什么、能调用什么、能操作什么。一个常见的误区是把模型当数据库用问什么答什么。但在任务场景里模型需要知道接下来该做什么需要被允许调用外部工具需要把大任务拆成小步骤。这些能力不是模型参数变大就自动出现的而是要靠应用层设计。所以在工程上“AGI 找工作”的第一步是定义清楚模型能访问的工具边界。比如是否允许读取文件、是否允许执行代码、是否允许调用搜索接口。工具边界越清晰Agent 的稳定性越高。3.2 工具调用与函数调用工具调用的技术基础是 Function Calling。主流模型 API 都支持在请求里声明一组工具模型在回答时会返回一个结构化的调用指令应用层再根据指令去执行真正的函数。这个能力对“找工作”至关重要。没有工具调用模型只能输出建议有了工具调用模型才能替你操作真实系统。比如你告诉模型“检查一下磁盘剩余空间”模型不直接算而是返回一个调用disk_usage()的指令你的代码执行这个函数再把结果回传给模型。从工程角度这意味着服务端要维护一份工具清单、统一参数格式、处理调用失败的情况。模型本身只是决策大脑执行手脚在你的应用层。这也是为什么同一个模型在不同 Agent 框架里表现差异很大——差异不在模型在工具层的工程实现。3.3 Agent 闭环的四个环节一个能“自己找工作”的 Agent完整工作流通常包含四个环节第一是任务理解。把用户模糊的需求解析成明确的目标和约束条件。第二是任务规划。把大目标拆成多个小步骤决定先后顺序。第三是工具调用。针对每个步骤调用合适的 API、脚本或外部服务。第四是结果验证。检查工具返回结果是否符合预期失败则重试或调整方案。这四个环节里前三步已经有很多开源框架实现了但第四步“结果验证”往往是工程上最容易被忽略的。没有验证机制Agent 会在错误结果上继续执行导致错误被放大。所以如果你想往 Agent 方向走建议优先设计验证环节每个步骤的结果怎么判断成功、失败重试多少次、重试是否需要换策略。这比堆模型参数更能提升实际效果。4. AGI 落地前提本地部署大模型能力4.1 为什么需要本地部署“AGI 会自己找工作”如果落地到企业场景首先遇到的就是数据边界问题。很多数据不能出内网模型必须本地部署。其次是成本问题如果每天的调用量大长期使用云端 API 的费用会显著高于本地推理。本地部署大模型还有两个隐藏优势延迟可控和离线可用。内网环境下推理延迟通常比公网 API 更稳定而且可以规避网络抖动带来的偶发超时。对于批量任务场景本地部署还能避免并发配额限制。当然本地部署不是没有代价。硬件投入、运维成本、模型更新维护都需要人力。以下给出的是通用部署流程模型文件、GPU 驱动和推理框架请以实际环境为准。4.2 本地部署通用流程以当前常见的开源模型部署工具 Ollama 为例部署流程大致如下# 安装 Ollama具体安装方式以官方文档为准 curl -fsSL https://ollama.com/install.sh | sh # 下载一个 7B 量级的开源模型 ollama pull qwen2.5:7b # 启动服务 ollama serve启动后默认服务地址是http://127.0.0.1:11434这个地址同时提供兼容 OpenAI 格式的 API 接口可以直接被 LangChain、Dify 等工具调用。如果你已经有其他推理框架部署思路类似启动一个本地服务暴露 HTTP 接口加载模型权重。关键不在于选哪个框架而在于确认服务端口、接口格式和模型名称三个参数。# 验证服务是否启动成功 curl http://127.0.0.1:11434/v1/models如果返回 JSON 列表说明服务已经正常运行。接下来就可以用 API 方式调用本地模型了。5. 大模型 API 与模型服务接入实践5.1 API 服务地址与兼容性本地部署完成后模型服务就是一个标准的 HTTP 服务。大多数推理框架会提供/v1/chat/completions接口与 OpenAI API 格式保持一致。这样做的最大好处是应用层不需要针对不同模型写不同调用代码换模型只需要改地址和模型名。接口调用需要确认三个核心参数API 地址、模型名称、请求体格式。请求体通常包含model字段指定使用哪个模型messages字段传入对话历史temperature字段控制输出随机性。{ model: qwen2.5:7b, messages: [ { role: user, content: 把下面的任务拆成可执行步骤检查服务器日志并输出错误汇总 } ], temperature: 0.2 }5.2 使用 Python 调用 OpenAI 兼容接口当服务端地址可访问、接口格式确认后就可以用 Python 发起请求。以下是调用本地模型服务的示例import requests url http://127.0.0.1:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: user, content: 把这句话翻译成英文磁盘空间不足需要清理日志文件。} ], temperature: 0.2 } response requests.post(url, jsonpayload, timeout120) print(response.json()[choices][0][message][content])这段代码的作用是验证本地服务能正常响应请求。如果返回结果正常说明本地推理链路已经打通后续可以把 URL 和模型名统一抽到配置文件里。5.3 从单次调用到可用服务单次调用成功只是第一步。实际工程中要处理超时、重试、并发、日志和监控。建议把 API 地址、模型名、超时时间、重试次数统一放到配置文件中model: name: qwen2.5:7b api_url: http://127.0.0.1:11434/v1/chat/completions timeout: 120 max_retries: 3 temperature: 0.2这样切换模型时只需改配置文件不需要改业务代码。对于“AGI 找工作”场景稳定的 API 服务是所有上层应用的基础。6. 批量任务与 Agent 自动化设计6.1 批量任务的典型场景大模型在批量任务场景中能显著提效。典型场景包括批量文档摘要、批量翻译、批量日志分析、批量代码审查、批量数据清洗。这些任务的特点是输入数量大、单条任务逻辑相对固定、对实时性要求不高。批量任务和单次调用的区别在于批量任务必须考虑失败恢复、并发控制和输出管理。如果 1000 条任务跑到第 800 条时失败不能从头开始而应该从断点继续。6.2 批量任务脚本示例下面是一个通用的批量任务脚本模板实际使用时需要根据输入来源和输出格式调整import time import requests API_URL http://127.0.0.1:11434/v1/chat/completions MODEL_NAME qwen2.5:7b MAX_RETRIES 3 def run_task(prompt, task_id): payload { model: MODEL_NAME, messages: [{role: user, content: prompt}], temperature: 0.3 } for attempt in range(MAX_RETRIES): try: resp requests.post(API_URL, jsonpayload, timeout120) resp.raise_for_status() content resp.json()[choices][0][message][content] print(f[{task_id}] 成功第 {attempt 1} 次尝试) return content except Exception as e: print(f[{task_id}] 失败第 {attempt 1} 次{e}) time.sleep(2) return None # 从列表读取任务 tasks [ 总结下面这段文字..., 把这段代码改成异步实现..., ] for idx, task in enumerate(tasks): result run_task(task, idx) time.sleep(1) # 控制请求频率这段脚本有几个关键点每次请求都带任务 ID 用于日志追踪失败自动重试且指数退避每条任务完成后短暂 sleep 避免请求过密。批量任务跑得慢没关系跑得稳更重要。6.3 批量任务工程化要点批量任务要工程化还需要考虑队列和日志。简单场景可以用 Python 列表遍历更复杂的大规模场景建议引入消息队列把任务分发做成分批消费避免单机内存堆积。日志设计也非常重要。建议给每条任务写一行结构化日志包含任务 ID、状态、耗时、失败原因。这样即使跑挂也能定位到具体是哪一条任务、什么原因失败、是否已经成功写入结果。另外批量任务必须支持断点续跑。最简单的做法是处理前把输入记录读到内存每条任务处理成功后把索引写入进度文件下次启动时跳过已完成部分。这个设计在数据量大时能节省大量时间。7. 资源占用与性能观察7.1 显存和内存观察本地部署大模型最关心的就是资源占用。启动服务后可以用nvidia-smi实时查看显存使用情况nvidia-smi -l 2这条命令每 2 秒刷新一次可以观察到模型加载后的显存占用、GPU 利用率和温度。如果服务启动后显存不足进程会被系统杀掉或回退到 CPU 推理推理速度会明显下降。以 7B 量级的量化模型为例常见部署场景下显存占用通常在 6G 到 10G 之间但这不是固定值需要以实际模型版本、量化位数和上下文长度为准。显存占用需以本机实测为准不要只看模型参数大小。7.2 影响推理性能的因素推理性能受四个因素影响最大模型大小、量化方式、上下文长度和并发数。模型越大单次推理越慢量化位数越低显存占用越少但输出质量可能有轻微下降上下文越长每次请求需要处理的 token 越多延迟越高。并发数需要谨慎控制。本地 GPU 的算力是固定的并发太高会导致请求排队单条延迟反而增加。建议先用单并发测试基准延迟再逐步增加并发找到延迟和吞吐量的平衡点。CPU 推理和 GPU 推理的差异也要清楚。CPU 推理在小模型上勉强可用但延迟明显偏高GPU 推理适合对延迟敏感的应用。如果只是离线批量任务CPU 也可以接受但整体吞吐量要提前压测。7.3 如何控制成本成本优化可以从三个方向入手第一个是选择合适大小的模型不要大材小用第二个是控制上下文长度只传必要信息第三个是减少无效重试优化提示词避免模型频繁答偏。另外批量任务可以利用本地 GPU 空闲时段集中执行。比如下班后启动批量脚本第二天查看结果这样可以错开办公时段的资源竞争。“AGI 找工作”也一样任务执行时间越灵活资源利用率越高摊薄下来的成本越低。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后页面或接口无法访问端口被占用或服务未启动检查日志和curl http://127.0.0.1:11434/v1/models更换端口或重启服务模型文件缺失或加载失败模型下载不完整或路径错误查看启动日志确认模型名称和路径重新 pull 模型检查磁盘空间GPU 显存不足导致进程退出模型过大或上下文太长nvidia-smi观察显存占用换小模型、降低量化位数、缩短上下文CUDA 或驱动不匹配推理框架与驱动版本不兼容nvidia-smi和框架版本检查升级驱动或更换推理框架版本请求超时单次推理时间过长或并发过高查看服务日志和平均延迟调大超时时间降低并发数API 调用返回错误请求参数或接口地址不正确对比官方接口文档和返回信息修正模型名、消息格式或地址批量任务中途失败单条任务触发异常检查任务 ID 对应的日志增加重试机制做断点续跑输出质量不稳定提示词不清晰或温度参数过高先小样本人工检查输出优化提示词降低 temperature排查问题的基础是先看日志。本地推理服务的日志通常会输出模型加载时间、请求处理时长和错误信息。遇到问题不要反复猜测先截取日志再对照表格逐步排查。9. 最佳实践与合规边界9.1 工程化建议第一次跑通链路时先用小模型、小批量、短上下文测试避免因为参数过大导致环境问题掩盖了逻辑问题。建议保留一套最小可运行配置包括固定的模型版本、固定的 API 地址和一份可复现的启动脚本。任务目录规划也很重要。建议把模型文件、输入素材、输出结果、日志分别放在独立目录不要混在一起。批量任务要加日志和失败重试接口服务要限制访问范围不要把本地推理服务直接暴露到公网。9.2 合规与授权本地部署模型时要注意模型本身的开源许可证和商用限制。不同模型对商用场景有不同约束使用前应确认授权范围。如果输入数据包含个人隐私、商业敏感信息或版权素材必须确认处理方式符合相关法规和企业内部数据安全要求。“AGI 会自己找工作”在真实业务中会接触到大量数据数据过滤、脱敏和审计缺一不可。9.3 安全边界模型服务暴露在网络上时需要设置访问控制避免被未授权调用消耗算力。API Key 要妥善保管不要硬编码在代码仓库里。批量任务涉及人脸、声音、版权素材时必须确认授权发布或商用前要做效果复核。要明确一点模型输出可能存在事实错误不能不加验证直接用于生产。“AGI 找工作”的能力越强越需要安全护栏——这不是限制它而是保证它在可控范围内创造价值。10. 总结与下一步这场“前 OpenAI 研究员看空大模型公司”和“AGI 会自己找工作”的争论短期很难有定论。但从技术角度看值得立刻动手的确定性方向有三个本地部署能力、API 接入能力、批量任务工程化能力。建议先默认选一个 7B 量级的开源模型在本地跑通对话接口再用批量脚本处理一批真实业务数据最后观察显存占用和单条耗时。这一步做完你对“AGI 能不能自己找工作”的判断会比任何争论都更有依据。最容易踩的坑是跳过小规模实验直接上大模型和长上下文导致显存不足、接口超时最后把问题归咎于模型能力。正确的顺序永远是小模型跑通 - 换大模型 - 加批量 - 加监控。这套路径可以一直复用不管未来是候选模型还是 Agent 框架更新底层能力不会白搭。如果你正在构建基于大模型的应用建议把这篇文章里的 API 地址、批量脚本、资源监控命令存成一份自己的部署清单。AGI 什么时候来不好说但工程能力早一天就绪后面切换任何模型都会更快。
从“AGI 找工作”到工程落地：大模型服务部署与批量任务实践
这两天 AI 圈有一场争论值得技术人停下来看一眼一边是前 OpenAI 研究员公开看空大模型公司认为训练成本、推理成本和开源追赶会让这轮商业模式走到尽头另一边是 Dwarkesh 的回应——AGI 会自己找工作。这句话听起来像概念炒作但拆开看它其实在说大模型的价值不在于“卖模型”而在于“能不能直接干活、干完活自动结算”。这篇文章不站队只做三件事把两边的论点拆成可验证的事实把“AGI 找工作”翻译成工程问题再给一套从本地部署到 API 接入再到批量任务的落地路径。无论你是做大模型应用开发、模型部署还是关心 Agent 方向成本控制都可以顺着这条链路跑一遍确认哪些说法是真实的哪些还停留在预期里。先给结论这场争论短期内不会影响你看得见摸得着的技术选型。但“AGI 会自己找工作”一旦落地它对工程架构的要求会非常具体——模型需要有工具调用能力服务需要稳定暴露 API任务需要支持批量执行资源占用需要可观测。这些才是真正值得提前准备的东西。1. 核心议题速览维度说明争议焦点大模型公司是否具有长期商业价值看空方观点前 OpenAI 研究员理由集中在训练/推理成本、API 降价、开源模型追赶反驳方观点AGI 会自己找工作价值从“卖模型订阅”转向“按任务结算”本质技术问题大模型能否从聊天工具演变为可自主拆解、执行、验证任务的 Agent本文关注的技术链路本地部署 - API 接入 - 批量任务 - 资源监控适合读者AI 应用开发、模型部署、成本优化、Agent 方向工程师这场争论表面上讨论的是投资逻辑实际上讨论的是技术路线大模型公司的护城河到底是“模型参数”还是“模型与真实工作流之间的连接能力”从工程角度看后者更值得押注。因为模型能力会被开源追赶但一个已经跑通的任务闭环替换成本远高于替换一个模型权重。所以这篇文章把重点放在“怎么把模型变成能干活的服务”上。先看争论双方到底在争什么再落到技术实操。2. 这场争论到底在争什么2.1 看空大模型公司的三条核心理由看空方最核心的判断是大模型公司的成本结构撑不起当前估值。训练一次前沿模型需要数万张 GPU 和数月时间推理阶段每次请求也要消耗大量算力。如果用户付费意愿跟不上算力消耗商业模型就很难闭环。第二点是 API 价格战。过去两年主流模型 API 的价格下降速度非常快尤其是在开源模型能力追上来之后闭源模型不再拥有绝对的定价权。价格下降对开发者是好事但对靠卖 API 算收入的公司来说意味着单用户价值在缩水。第三点是开源模型的追赶。7B、14B 量级的开源模型在通用对话、文本处理、代码生成上已经能做到接近商用模型的体验。很多企业和开发者开始优先尝试本地部署这直接削弱了“必须订阅闭源模型”的刚性需求。这三条理由放在一起结论指向一个方向如果把大模型公司当成“卖模型的公司”它的长期利润率确实需要打问号。2.2 反驳方AGI 会自己找工作Dwarkesh 的回应则换了一个坐标系不要只看“卖模型”的生意要看 AGI 能不能直接创造劳动力价值。“AGI 会自己找工作”的意思是未来的 AI 不是一个被动的 API而是一个能主动接任务、调用工具、完成交付并产生经济回报的 Agent。这个论点成立的前提是模型必须从“生成文字”进化到“完成任务”。任务意味着目标、步骤、工具、验证和交付。比如你让它“查一下这周服务器日志里的错误并汇总成报告”它需要先调用日志查询工具再分析结果最后生成报告。这个过程不是一次对话而是一个包含多个步骤的工作流。如果这个闭环能稳定跑通AI 的价值就不受“订阅费”限制而是可以直接按任务结算。到那时大模型公司卖的不是模型而是能够完成任务的劳动力。这是两种完全不同的商业模式也是反驳方认为看空逻辑不成立的根本原因。2.3 技术人应该怎么看待这场争论作为工程师不需要急着站队但可以从这场争论里提炼出技术方向模型能力会持续增强但真正的应用瓶颈在于如何把模型接入真实系统。争论双方都没有否认 AGI 长期存在只是对商业路径判断不同。对开发者来说这意味着两件事第一模型选型要保留可替换性不要被某一家绑定第二要把精力放在任务编排、工具调用、批量执行这些通用工程能力上这些能力不管哪个模型胜出都能复用。换句话说这场争论真正值得关注的问题是你的系统是否已经具备让模型“干活”的基础设施如果没有现在开始搭比争论 AGI 什么时候到来更有意义。3. 把“AGI 会自己找工作”拆成工程问题3.1 模型能力只是起点“AGI 会自己找工作”听上去是单一模型的能力但工程上它需要一整套系统支撑。模型本身负责理解自然语言、生成计划、产生输出真正让“找工作”成立的是任务执行环境模型能看到什么、能调用什么、能操作什么。一个常见的误区是把模型当数据库用问什么答什么。但在任务场景里模型需要知道接下来该做什么需要被允许调用外部工具需要把大任务拆成小步骤。这些能力不是模型参数变大就自动出现的而是要靠应用层设计。所以在工程上“AGI 找工作”的第一步是定义清楚模型能访问的工具边界。比如是否允许读取文件、是否允许执行代码、是否允许调用搜索接口。工具边界越清晰Agent 的稳定性越高。3.2 工具调用与函数调用工具调用的技术基础是 Function Calling。主流模型 API 都支持在请求里声明一组工具模型在回答时会返回一个结构化的调用指令应用层再根据指令去执行真正的函数。这个能力对“找工作”至关重要。没有工具调用模型只能输出建议有了工具调用模型才能替你操作真实系统。比如你告诉模型“检查一下磁盘剩余空间”模型不直接算而是返回一个调用disk_usage()的指令你的代码执行这个函数再把结果回传给模型。从工程角度这意味着服务端要维护一份工具清单、统一参数格式、处理调用失败的情况。模型本身只是决策大脑执行手脚在你的应用层。这也是为什么同一个模型在不同 Agent 框架里表现差异很大——差异不在模型在工具层的工程实现。3.3 Agent 闭环的四个环节一个能“自己找工作”的 Agent完整工作流通常包含四个环节第一是任务理解。把用户模糊的需求解析成明确的目标和约束条件。第二是任务规划。把大目标拆成多个小步骤决定先后顺序。第三是工具调用。针对每个步骤调用合适的 API、脚本或外部服务。第四是结果验证。检查工具返回结果是否符合预期失败则重试或调整方案。这四个环节里前三步已经有很多开源框架实现了但第四步“结果验证”往往是工程上最容易被忽略的。没有验证机制Agent 会在错误结果上继续执行导致错误被放大。所以如果你想往 Agent 方向走建议优先设计验证环节每个步骤的结果怎么判断成功、失败重试多少次、重试是否需要换策略。这比堆模型参数更能提升实际效果。4. AGI 落地前提本地部署大模型能力4.1 为什么需要本地部署“AGI 会自己找工作”如果落地到企业场景首先遇到的就是数据边界问题。很多数据不能出内网模型必须本地部署。其次是成本问题如果每天的调用量大长期使用云端 API 的费用会显著高于本地推理。本地部署大模型还有两个隐藏优势延迟可控和离线可用。内网环境下推理延迟通常比公网 API 更稳定而且可以规避网络抖动带来的偶发超时。对于批量任务场景本地部署还能避免并发配额限制。当然本地部署不是没有代价。硬件投入、运维成本、模型更新维护都需要人力。以下给出的是通用部署流程模型文件、GPU 驱动和推理框架请以实际环境为准。4.2 本地部署通用流程以当前常见的开源模型部署工具 Ollama 为例部署流程大致如下# 安装 Ollama具体安装方式以官方文档为准 curl -fsSL https://ollama.com/install.sh | sh # 下载一个 7B 量级的开源模型 ollama pull qwen2.5:7b # 启动服务 ollama serve启动后默认服务地址是http://127.0.0.1:11434这个地址同时提供兼容 OpenAI 格式的 API 接口可以直接被 LangChain、Dify 等工具调用。如果你已经有其他推理框架部署思路类似启动一个本地服务暴露 HTTP 接口加载模型权重。关键不在于选哪个框架而在于确认服务端口、接口格式和模型名称三个参数。# 验证服务是否启动成功 curl http://127.0.0.1:11434/v1/models如果返回 JSON 列表说明服务已经正常运行。接下来就可以用 API 方式调用本地模型了。5. 大模型 API 与模型服务接入实践5.1 API 服务地址与兼容性本地部署完成后模型服务就是一个标准的 HTTP 服务。大多数推理框架会提供/v1/chat/completions接口与 OpenAI API 格式保持一致。这样做的最大好处是应用层不需要针对不同模型写不同调用代码换模型只需要改地址和模型名。接口调用需要确认三个核心参数API 地址、模型名称、请求体格式。请求体通常包含model字段指定使用哪个模型messages字段传入对话历史temperature字段控制输出随机性。{ model: qwen2.5:7b, messages: [ { role: user, content: 把下面的任务拆成可执行步骤检查服务器日志并输出错误汇总 } ], temperature: 0.2 }5.2 使用 Python 调用 OpenAI 兼容接口当服务端地址可访问、接口格式确认后就可以用 Python 发起请求。以下是调用本地模型服务的示例import requests url http://127.0.0.1:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: user, content: 把这句话翻译成英文磁盘空间不足需要清理日志文件。} ], temperature: 0.2 } response requests.post(url, jsonpayload, timeout120) print(response.json()[choices][0][message][content])这段代码的作用是验证本地服务能正常响应请求。如果返回结果正常说明本地推理链路已经打通后续可以把 URL 和模型名统一抽到配置文件里。5.3 从单次调用到可用服务单次调用成功只是第一步。实际工程中要处理超时、重试、并发、日志和监控。建议把 API 地址、模型名、超时时间、重试次数统一放到配置文件中model: name: qwen2.5:7b api_url: http://127.0.0.1:11434/v1/chat/completions timeout: 120 max_retries: 3 temperature: 0.2这样切换模型时只需改配置文件不需要改业务代码。对于“AGI 找工作”场景稳定的 API 服务是所有上层应用的基础。6. 批量任务与 Agent 自动化设计6.1 批量任务的典型场景大模型在批量任务场景中能显著提效。典型场景包括批量文档摘要、批量翻译、批量日志分析、批量代码审查、批量数据清洗。这些任务的特点是输入数量大、单条任务逻辑相对固定、对实时性要求不高。批量任务和单次调用的区别在于批量任务必须考虑失败恢复、并发控制和输出管理。如果 1000 条任务跑到第 800 条时失败不能从头开始而应该从断点继续。6.2 批量任务脚本示例下面是一个通用的批量任务脚本模板实际使用时需要根据输入来源和输出格式调整import time import requests API_URL http://127.0.0.1:11434/v1/chat/completions MODEL_NAME qwen2.5:7b MAX_RETRIES 3 def run_task(prompt, task_id): payload { model: MODEL_NAME, messages: [{role: user, content: prompt}], temperature: 0.3 } for attempt in range(MAX_RETRIES): try: resp requests.post(API_URL, jsonpayload, timeout120) resp.raise_for_status() content resp.json()[choices][0][message][content] print(f[{task_id}] 成功第 {attempt 1} 次尝试) return content except Exception as e: print(f[{task_id}] 失败第 {attempt 1} 次{e}) time.sleep(2) return None # 从列表读取任务 tasks [ 总结下面这段文字..., 把这段代码改成异步实现..., ] for idx, task in enumerate(tasks): result run_task(task, idx) time.sleep(1) # 控制请求频率这段脚本有几个关键点每次请求都带任务 ID 用于日志追踪失败自动重试且指数退避每条任务完成后短暂 sleep 避免请求过密。批量任务跑得慢没关系跑得稳更重要。6.3 批量任务工程化要点批量任务要工程化还需要考虑队列和日志。简单场景可以用 Python 列表遍历更复杂的大规模场景建议引入消息队列把任务分发做成分批消费避免单机内存堆积。日志设计也非常重要。建议给每条任务写一行结构化日志包含任务 ID、状态、耗时、失败原因。这样即使跑挂也能定位到具体是哪一条任务、什么原因失败、是否已经成功写入结果。另外批量任务必须支持断点续跑。最简单的做法是处理前把输入记录读到内存每条任务处理成功后把索引写入进度文件下次启动时跳过已完成部分。这个设计在数据量大时能节省大量时间。7. 资源占用与性能观察7.1 显存和内存观察本地部署大模型最关心的就是资源占用。启动服务后可以用nvidia-smi实时查看显存使用情况nvidia-smi -l 2这条命令每 2 秒刷新一次可以观察到模型加载后的显存占用、GPU 利用率和温度。如果服务启动后显存不足进程会被系统杀掉或回退到 CPU 推理推理速度会明显下降。以 7B 量级的量化模型为例常见部署场景下显存占用通常在 6G 到 10G 之间但这不是固定值需要以实际模型版本、量化位数和上下文长度为准。显存占用需以本机实测为准不要只看模型参数大小。7.2 影响推理性能的因素推理性能受四个因素影响最大模型大小、量化方式、上下文长度和并发数。模型越大单次推理越慢量化位数越低显存占用越少但输出质量可能有轻微下降上下文越长每次请求需要处理的 token 越多延迟越高。并发数需要谨慎控制。本地 GPU 的算力是固定的并发太高会导致请求排队单条延迟反而增加。建议先用单并发测试基准延迟再逐步增加并发找到延迟和吞吐量的平衡点。CPU 推理和 GPU 推理的差异也要清楚。CPU 推理在小模型上勉强可用但延迟明显偏高GPU 推理适合对延迟敏感的应用。如果只是离线批量任务CPU 也可以接受但整体吞吐量要提前压测。7.3 如何控制成本成本优化可以从三个方向入手第一个是选择合适大小的模型不要大材小用第二个是控制上下文长度只传必要信息第三个是减少无效重试优化提示词避免模型频繁答偏。另外批量任务可以利用本地 GPU 空闲时段集中执行。比如下班后启动批量脚本第二天查看结果这样可以错开办公时段的资源竞争。“AGI 找工作”也一样任务执行时间越灵活资源利用率越高摊薄下来的成本越低。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后页面或接口无法访问端口被占用或服务未启动检查日志和curl http://127.0.0.1:11434/v1/models更换端口或重启服务模型文件缺失或加载失败模型下载不完整或路径错误查看启动日志确认模型名称和路径重新 pull 模型检查磁盘空间GPU 显存不足导致进程退出模型过大或上下文太长nvidia-smi观察显存占用换小模型、降低量化位数、缩短上下文CUDA 或驱动不匹配推理框架与驱动版本不兼容nvidia-smi和框架版本检查升级驱动或更换推理框架版本请求超时单次推理时间过长或并发过高查看服务日志和平均延迟调大超时时间降低并发数API 调用返回错误请求参数或接口地址不正确对比官方接口文档和返回信息修正模型名、消息格式或地址批量任务中途失败单条任务触发异常检查任务 ID 对应的日志增加重试机制做断点续跑输出质量不稳定提示词不清晰或温度参数过高先小样本人工检查输出优化提示词降低 temperature排查问题的基础是先看日志。本地推理服务的日志通常会输出模型加载时间、请求处理时长和错误信息。遇到问题不要反复猜测先截取日志再对照表格逐步排查。9. 最佳实践与合规边界9.1 工程化建议第一次跑通链路时先用小模型、小批量、短上下文测试避免因为参数过大导致环境问题掩盖了逻辑问题。建议保留一套最小可运行配置包括固定的模型版本、固定的 API 地址和一份可复现的启动脚本。任务目录规划也很重要。建议把模型文件、输入素材、输出结果、日志分别放在独立目录不要混在一起。批量任务要加日志和失败重试接口服务要限制访问范围不要把本地推理服务直接暴露到公网。9.2 合规与授权本地部署模型时要注意模型本身的开源许可证和商用限制。不同模型对商用场景有不同约束使用前应确认授权范围。如果输入数据包含个人隐私、商业敏感信息或版权素材必须确认处理方式符合相关法规和企业内部数据安全要求。“AGI 会自己找工作”在真实业务中会接触到大量数据数据过滤、脱敏和审计缺一不可。9.3 安全边界模型服务暴露在网络上时需要设置访问控制避免被未授权调用消耗算力。API Key 要妥善保管不要硬编码在代码仓库里。批量任务涉及人脸、声音、版权素材时必须确认授权发布或商用前要做效果复核。要明确一点模型输出可能存在事实错误不能不加验证直接用于生产。“AGI 找工作”的能力越强越需要安全护栏——这不是限制它而是保证它在可控范围内创造价值。10. 总结与下一步这场“前 OpenAI 研究员看空大模型公司”和“AGI 会自己找工作”的争论短期很难有定论。但从技术角度看值得立刻动手的确定性方向有三个本地部署能力、API 接入能力、批量任务工程化能力。建议先默认选一个 7B 量级的开源模型在本地跑通对话接口再用批量脚本处理一批真实业务数据最后观察显存占用和单条耗时。这一步做完你对“AGI 能不能自己找工作”的判断会比任何争论都更有依据。最容易踩的坑是跳过小规模实验直接上大模型和长上下文导致显存不足、接口超时最后把问题归咎于模型能力。正确的顺序永远是小模型跑通 - 换大模型 - 加批量 - 加监控。这套路径可以一直复用不管未来是候选模型还是 Agent 框架更新底层能力不会白搭。如果你正在构建基于大模型的应用建议把这篇文章里的 API 地址、批量脚本、资源监控命令存成一份自己的部署清单。AGI 什么时候来不好说但工程能力早一天就绪后面切换任何模型都会更快。