“Dont Scale Yet, Because of AI”这句话放在 AI 项目里意思是先不要急着扩展规模因为模型能力、数据质量、成本结构和基础设施都还在快速变化。很多团队最容易犯的错不是没有扩展意识而是在没验证清楚之前就先把并发调大、机器加多、任务队列拉长结果模型效果一塌糊涂问题还特别难定位。这篇文章不是反对 Scale而是想拆一下为什么 AI 项目里“Scale 之前”比“Scale 本身”更重要以及什么时候、用什么标准判断自己能不能进入扩展阶段。如果你正在做 AI 应用开发、模型部署、Agent 工程化或者刚把 AI 功能接入业务系统这篇文章会比较对路。尤其适合技术负责人、架构师、后端工程师和正在做技术选型的团队。下面我按实际落地的顺序把这件事拆开讲。1. “Dont Scale Yet”不是不扩展而是先解决三件事1.1 为什么 AI 项目急着 Scale 会放大问题传统后端系统扩展时只要数据库索引、缓存、接口设计没问题加机器通常能线性提升吞吐。但 AI 项目不一样。模型输出的稳定性、输入数据分布、上下文长度、推理延迟都会直接影响最终结果。你在单条数据上跑通的功能不代表放到批量任务里还能保持同质量你在测试集上看到的准确率不代表生产环境里用户输入进来还是这个准确率。如果急着 Scale最常见的情况是错误率很高但日志里看不出模型报错因为错误可能藏在前置数据清洗、分词、上下文截断、输出解析这些环节。并发一旦提高这些问题会被放大而且互相叠加排查成本直线上升。最后你花在查问题上的时间比省下来的运行时间还多。所以我对团队的提醒一直是Scale 没有错但要把“环境变化”和“模型效果变化”分清楚。在没有分清楚之前扩展规模只会让噪声变大。1.2 真正要先解决的三件事进入扩展阶段之前先确认三件事能不能稳定回答。第一可复现的流程。同一个输入给同一个模型版本是不是每次输出都一致或者说至少结果分布一致。如果不能复现后面的评测、对比、回归测试都无从谈起。第二可量化的评估。你得知道“模型效果好不好”是用什么指标判断的。是准确率、召回率、还是人工抽检通过率指标可以很简陋但不能没有。第三可接受的成本边界。单条推理成本是多少批量吞吐成本是多少任务失败重跑一次要额外花多少。先算清楚成本再谈扩展。这三件事没解决机器加得再多也只是把没有验证过的流程跑得更快。这句“Dont Scale Yet”真正的意思是先做小规模、可观测、可评估的验证等这三件事都有答案了再思考怎么扩展。2. 单机环境跑稳之前别急着上分布式2.1 单机跑通要检查哪些环节分布式环境里日志分散在多台机器依赖环境不容易保持一致数据分片还会引入额外问题。如果模型在单机上都没跑稳直接上分布式你会分不清是模型问题、数据问题还是网络问题。我建议先从最小可行的单机流程开始。最基础的一条路径是输入样例 - 模型推理 - 输出样例。看起来很简单但至少要确认四件事模型权重文件路径是否正确有没有加载到内存里依赖版本是否和你写的代码兼容输入数据格式是否符合模型预期文本要不要截断图片要不要 resize输出结果能不能被后续业务正确解析。这些环节单独看都不难但合在一起就很容易出错。尤其是模型文件路径和依赖版本很多人启动时报错第一反应是代码写错了最后发现是环境变量没配好或者某个库的版本太新接口变了。先跑单条任务用一条你能想到的代表性样例确认输入、输出、日志都正常。这一步通过了再考虑多条任务。2.2 低配置环境怎么判断够不够用很多 AI 模型对硬件有要求尤其大语言模型和视觉模型显存不够就启动失败或者推理时间特别长。低配置环境不是不能跑而是要把预期控制好。如果机器配置不高有几种做法降低输入长度比如文本截断到更短范围降低分辨率图片类任务先缩小图片尺寸减小 batch size一次只处理一条样本使用更小的量化版本模型如果原始模型有的话。但这些做法都要以效果不严重下降为前提。你可以在小样本上对比原始版本和低配版本的输出看差异是否可接受。不要一上来就把参数拉满也不要因为低配跑通了就认为生产环境可以这样跑。低配能跑通只能说明流程是通的不能说明吞吐和稳定性达标。2.3 启动失败和输出异常按这个顺序排查如果单机流程跑不通不要急着调模型参数先按顺序查效率会高很多。第一看现象。是启动直接报错还是启动成功但输出为空还是输出有内容但格式不对。现象不同排查路径完全不同。第二看输入。文件编码、路径、目录权限、上下文长度、图片尺寸、音频时长这些前置条件最容易被忽略。我见过很多次“模型输出乱码”的问题最后发现是输入文件编码不对。第三看环境。依赖版本、驱动版本、环境变量、磁盘空间、内存和显存占用。先用nvidia-smi或系统监控工具看资源使用情况能省很多时间。第四看参数。模型加载路径、batch size、并发数、超时时间、输出目录这些参数如果设置不合理也会导致任务看起来是“卡死”或“无响应”。第五才轮到工具或模型本身。比如当前模型版本是不是有已知限制某种格式是不是不支持某个功能是不是还在实验阶段。这里容易犯的错是一报错就去搜解决方案结果试了好几个答案都不对。先按这个链路走一遍通常更容易定位。3. 批量任务不是把并发调大而是设计队列、重试和输出管理3.1 从单任务复制成多任务最容易出问题单条任务跑通之后很多人会直接把脚本写成一个循环遍历所有输入文件然后调大并发数。这样容易出现三类问题。第一显存或内存不够。模型在推理时占用的显存是固定的并发太高会导致 OOM进程直接被系统杀掉日志里甚至没有明确报错。你以为任务还在跑实际已经断了。第二输出文件没有唯一命名。多个进程同时写同一个文件会互相覆盖或者写入半个文件就报错。第三失败后没有重试。某个输入格式特殊导致模型推理抛异常整个批量任务中断。后面所有数据都被挡住。所以批量任务不是“循环加并发”这么简单。你要把任务看成一条加工流水线输入列表、任务队列、执行单元、输出写入、失败处理每个环节都要单独考虑。3.2 用分批和队列控制资源占用不要一上来就开最大并发。更稳妥的方式是先用小批量跑一轮观察资源占用和耗时再逐步调大。一个很简单的策略是固定 batch size分批处理每批之间加一个极短的间隔。这样即使某个批次出了问题也不会影响前面已经写好的结果。下面是一段通用示例不针对任何具体工具重点看结构# 伪代码先把任务列表分批再逐批处理 import time BATCH_SIZE 4 # 先从小批次开始 RETRY_LIMIT 3 # 失败重试次数 tasks load_task_list(input/) for i in range(0, len(tasks), BATCH_SIZE): batch tasks[i:iBATCH_SIZE] for task in batch: for attempt in range(RETRY_LIMIT): try: result run_model(task) save_result(task, result) print(fsuccess: {task}) break except Exception as e: print(ferror: {task}, attempt{attempt1}, msg{e}) time.sleep(5 * (attempt 1)) time.sleep(1) # 给系统一点缓冲这段代码真正的关键点不是并发而是三个约束分批控制内存和显存避免一次性全部加载重试单条失败不会中断整个流程日志每条任务成功还是失败都有记录。如果你用的是更成熟的队列系统比如 Redis 队列、消息中间件思路也一样只是组件换了一下。批量任务首先要求稳定其次才是速度。3.3 失败重试和日志分开看批量任务里失败重试不能盲目无限重试。如果输入本身就非法重试多少次都会失败只会浪费资源。更合理的做法是区分“可重试错误”和“不可重试错误”可重试错误比如网络超时、临时磁盘满可以重试几次不可重试错误比如输入格式非法、模型权重缺失直接跳过并记录原因。日志也是一样。任务卡住时先确认资源占用和输出目录。如果你发现日志停在某个任务上同时显存被占满很可能是并发开高了如果显存正常但任务一直不结束可能要检查是不是输入数据量太大模型推理时间本身就很长如果输出目录里已经写了一些文件还要看编号有没有乱。我一般排查批量任务时会先看三样东西日志最后一行、当前进程资源占用、输出目录里的文件数量和时间戳。这三样能快速把问题范围缩小避免直接去改模型参数。4. 成本、延迟和稳定性必须分开评估4.1 不同阶段要用不同指标很多团队把一个指标从头用到尾比如“准确率”或者“并发数”。但在 AI 项目里不同阶段要看的指标是不一样的。单机验证阶段你主要看“能不能跑、输出是否合理、资源占用多少”。这个阶段不要过分纠结并发因为并发还没意义。批量阶段你要看“单位时间能处理多少条、失败率多少、重试率多少”。在这个阶段单条延迟不再是最重要的整体吞吐更重要。生产阶段你要同时关注“端到端延迟、可用性、成本、数据漂移”。如果一个系统在批量任务里跑得很好但在生产环境里用户请求是随机到达的高峰期和空闲期差距很大那你要重新评估弹性扩缩容而不是继续堆固定机器。所以不要只看一个数字。把成本、延迟、稳定性拆开看你会发现很多矛盾其实是阶段不同导致的。4.2 成本可接受的判断标准成本不能只算账单上的金额还要算单位有效输出的成本。我建议用这个思路估算单条有效成本 总运行成本 / 成功且质量达标的输出数量如果你跑了一千条任务有一百条失败两百条输出质量不达标那一千条任务的成本就要分摊到七百条有效结果上而不是一千条。这个数才更适合用来做扩展决策。不同方案之间对比也一样。不要只看单次调用价格还要看失败率、人工复核成本、重试成本。一个更贵但更稳定的方案在批量场景里可能反而更省钱。4.3 延迟和并发的取舍提高并发通常会导致单条延迟上升尤其是 GPU 推理或需要争抢磁盘 IO 的场景。这很正常但你要知道瓶颈在哪里。如果模型推理本身是瓶颈加并发只会让任务排队延迟上升但吞吐不一定提高。这时候要优化的方向可能是模型量化、剪枝、更小的输入长度或者用更强性能的硬件而不是单纯加并发数。如果瓶颈在数据读取或输出写入那加并发反而有效因为推理资源还没有被完全利用。判断方法很简单在并发从 1 调到 2、4、8 的过程中观察吞吐是否同步上升单条延迟是否飙升。如果吞吐不涨、延迟狂涨说明瓶颈在别的环节先不要继续加并发。5. AI 模型迭代太快扩展结构要预留重构空间5.1 别把模型 A 的特殊逻辑写死在业务代码里AI 模型更新频率很高可能一两个月就换一个版本。如果你把所有数据预处理、提示词模板、输出解析逻辑都写死在业务代码里那每次换模型都要改一大片代码而且容易改出问题。更合理的做法是把模型相关的东西尽量做成可配置的比如把提示词模板放到配置文件里把输出解析做成独立的处理器把不同模型的调用封装成统一接口。这样模型切换时业务层不需要大改只要替换新的适配器。不要过度设计但至少要留出“替换模型”的缝隙。哪怕只是一个很薄的抽象层也比将来把所有业务代码翻出来改要好。5.2 配置化、抽象层和依赖管理配置化的意思不是把所有参数都丢进配置文件而是把“和具体模型强相关、但业务层不关心”的项抽出来。比如 prompt 模板、温度参数、最大 token 数、输入截断规则这些可以放进配置而业务流程、状态转换、权限控制这些应该留在代码里。依赖管理也要单独注意。AI 项目的 Python 依赖很多版本稍微不对就可能出现接口不兼容。我会建议把项目依赖锁成一个固定文件并记录模型权重文件的版本和来源最好和代码一起打版本标签。这样出现问题的时候可以快速回滚到当时的状态。模型权重文件本身也要管理好。不要只保存一个“最新版”至少要保留上一个稳定版本。因为模型更新后如果效果不如预期你需要能快速切回旧版本。5.3 模型权重和版本备份怎么处理模型文件通常很大不适合直接放进 Git 仓库。可以用单独的存储目录管理但要建立明确的命名规则模型名称、版本号、日期、量化格式至少要包含这几个信息。举个例子一个合理的权重文件命名可以是这样chatmodel_v3_20250214_q8.gguf这种命名方式的好处是看到文件名就知道是什么模型、哪个版本、什么时候生成的、用什么格式。扩展的时候每台机器需要什么模型直接按名称拉取不容易混淆。对小的团队来说不需要一开始就上很复杂的模型管理平台但至少要有一个目录规范和一个记录模型变更的说明文档。文档不用长但必须写清楚这个权重对应哪个代码版本验证结果怎么样谁更新的什么时候更新的。扩展规模以后模型版本不清晰是一件非常痛苦的事。你可能会遇到线上服务跑着 A 版本离线任务用的 B 版本两边输出风格不一致最后对不上账。6. 什么时候才应该启动 Scale给一份判断清单6.1 启动扩展的六个前置条件把前面说的内容收敛成六个条件。如果以下六条都满足再考虑扩展否则先补功课。条件具体判断标准单条流程稳定同一输入多次运行输出和效果都在可接受范围评估指标明确有固定指标区分“好结果”和“差结果”而不是靠感觉批量跑通多任务连续运行不中断失败重试机制有效资源边界清楚知道当前配置下显存、内存、磁盘最多能支撑多少并发成本模型建立能算出单条有效输出的成本并且成本在预算内模型版本可控权重文件、代码版本、依赖版本都能随时回滚这六个条件不要求完美但每一项都要有初步答案。哪怕答案很粗糙也比没有答案强。6.2 扩展第一台机器时就要建立的规范很多人觉得扩展是“等系统做大了以后的事”但真正开始扩展第一台机器时就要把规范立起来。否则后面只会越来越乱。至少要做三件事统一服务启动方式比如用固定的启动脚本或部署配置不要每台机器手动配环境统一日志格式日志里要有任务 ID、模型版本、输入文件名、耗时、结果状态统一输出目录结构按日期或任务批次组织避免所有结果堆在一个文件夹里。这些看起来不像技术难点但扩展后它们决定你能不能快速定位问题。没有规范的话机器一多日志分散你根本不知道哪台机器在处理哪批任务。6.3 扩展后持续监控的核心指标扩展以后监控不能只看服务活没活着。至少要看这几项资源占用显存、内存、CPU、磁盘 IO这些指标能反映并发是否合理任务成功率成功数除以总任务数要排除重试后成功的部分看真实失败率端到端延迟从提交任务到输出完成的总耗时而不是单次推理耗时输出质量抽检定期人工抽检或自动评估防止模型更新后质量悄悄下降成本趋势每天或每周的总成本以及单条有效输出成本防止成本失控。监控的价值不是“实时报警”而是让你在规模扩大后还能保持判断力。数据能力不足时可以从最简单的日志统计开始但一定要坚持记录。等这些指标都稳定了再回头看“Dont Scale Yet”这句话会更有体会。扩展不是终点它只是验证结果的放大。真正值得花时间的是在扩展之前把流程、指标、成本、版本管理这些基础工作做扎实。其实很多时候不是工具能力不够而是前面几层没有处理干净就急着往下一层跑了。