最近 AI 圈子里讨论最多的一个话题不是哪个模型又刷榜了而是“AI 发展是不是遇到瓶颈了”。注意这里说的瓶颈不是某个模型变笨了而是一连串信号叠加在一起下一代大模型的发布时间在拉长、公开评测集的分数增长明显放缓、算力投入越来越大但回报曲线不再像前两年那么陡连非技术圈的媒体也开始频繁讨论“创新趋缓”。前几天比尔·盖茨罕见地发长文讨论 AI 的远景与风险核心关注点就是AI 能力还能不能按过去两年的速度继续涨。这篇文章不是来唱衰或者唱多 AI 的。写这篇内容的目的是把“瓶颈”这个词拆开放到技术、工程、业务三个层面去分析瓶颈到底出现在哪里哪些信号是可靠的哪些说法是炒作以及最关键的问题——如果基础模型的能力增长真的放缓了做技术选型、做应用落地的团队应该怎么应对。文章后半部分会给出一套可复用的评估流程包括资源监控、回归测试、批量评测和接口验证的思路附可直接改用的脚本和命令。1. 核心争议AI 创新是否真的放缓先把“AI 创新放缓”这个说法拆成两个不同的命题因为很多讨论把这两件事混在一起。第一个命题基础大模型的“能力提升曲线”在放缓。这个命题有较多公开迹象支持。从 GPT-4 发布到后来的 GPT-4o、o1 系列再到各家的新一代模型虽然单点能力确实在提升但“发布间隔变长”和“代际差距缩小”是客观可感知的。在图像生成领域头部模型的迭代节奏也没有前两年那么激进。更明显的是推理成本复杂任务的推理预算反而在上升模型变强的方式从“加大预训练规模”转向“增加推理时计算”。第二个命题AI 整体创新在放缓。这个命题我认为不成立。从工程和产品角度看创新正在迁移从“把模型变大”转向“把模型用对”。今天大量团队的工作重心在 Agent 工作流、工具调用、RAG 架构、多模态工程化、模型路由和评测体系建设上。这些领域的创新速度不但没有放缓反而在加速。只是这类创新不像发布一个万亿参数模型那样有话题性。所以准确的说法是基础模型层面的“规模红利”进入平台期但 AI 系统的工程创新和应用创新仍在活跃。对绝大多数开发和业务团队来说后者比前者更能直接影响交付效果。2. 瓶颈信号技术层面正在发生什么2.1 数据墙是绕不开的物理约束大模型性能增长最依赖的要素是高质量数据。过去几年行业对公开高质量文本数据的消耗速度远大于数据的自然增长速度。这带来一个直接后果继续新增参数和算力边际收益会下降。表现在实际产品里就是“量变不再带来质变”。一个可观察的现象是各家模型在主流 benchmark 上的分数差距越来越小但同一套应用换到不同模型后真实业务效果差异很明显。这说明公开评测集已经不能完全反映模型的真实能力分布尤其不能反映长尾场景中的表现。2.2 评测体系正在失真榜单分数接近饱和是“创新放缓”最容易看到的证据之一。不少公开数据集的分数已经接近人类基线继续提升的空间很小。但这也带来一个副作用产品团队如果只看榜单做选型很容易被误导。真实业务里经常出现“榜单高分、实际拉胯”的情况比如遇到非常规格式的输入、上下文很长但信息密度低、需要稳定调用多个工具的场景模型表现会和 benchmark 产生明显偏差。2.3 架构层面的创新节奏放缓从 Transformer 提出到现在主流大模型架构的主体变化并不剧烈。混合专家模型、线性注意力、状态空间模型等方向都有进展但还没有出现一个能让训练效率或能力上限发生质变的全新范式。相比之下后训练阶段的技术创新更明显强化学习、偏好优化、推理时搜索、多智能体协作等正在成为拉开模型差距的主要手段。这其实是“瓶颈期”的典型表现基础范式稳定后竞争从“发明新架构”转向“优化已有架构的训练和推理管线”。对工程团队来说这不是坏事因为这意味着可复用的最佳实践变多了。3. Scaling Law 争议的本质不是失效是成本收益变化Scaling Law 的原始表述简单说就是模型参数量、数据量、算力三者按比例扩大时模型能力会稳定提升。这个规律在过去几年被反复验证也是大模型军备竞赛的底层信仰。现在的问题不在于 Scaling Law 是否失效而在于继续按这个方式扩大的成本收益比已经变得不划算。更准确的说法是数据规模的边际收益在下降单纯增加参数需要更多数据才能配平。推理计算的性价比正在成为新的关注点与其把所有知识压进预训练不如在推理阶段让模型多思考、多验证、多纠错。后训练质量对最终用户体验的影响已经远超增大预训练规模。所以把“创新放缓”理解为 Scaling Law“失败”其实并不准确。更稳妥的判断是行业正在从“大力出奇迹”阶段过渡到“精细化工程”阶段这种过渡期往往会带来两到三个季度的“产品体验原地踏步”感。对开发者来说这个阶段的直接含义是不能继续依赖“等下一代模型解决所有问题”这种工作方式。你需要建立自己的评测回归集、错误分析和任务分诊机制。4. 瓶颈期 AI 技术评估的通用方法当模型能力曲线变平技术选型就变得比追新更重要。下面是一套不依赖具体厂商的通用评估方法适合任何想落地 AI 功能的团队。4.1 评估维度评估维度具体观察内容优先级能力基线是否稳定完成核心业务任务高长尾鲁棒性面对非常规输入、异常格式时是否崩溃高延迟稳定性高并发下的 P95/P99 延迟高工具调用质量是否按格式返回、是否不胡调参数高幻觉频率关键信息错误率中成本模型每千 token 成本 推理时计算消耗中生态与兼容性是否支持 OpenAI 兼容接口、是否有稳定 SDK中合规情况数据使用条款、隐私处理、商用限制高4.2 给“瓶颈期选型”的几条实操结论第一不要只看跑分。把跑分当作入门筛选条件把长尾任务测试当作最终决策依据。第二同一任务至少要测三个模型。选择模型时建议在同一个业务数据集上对比至少三款不同规模的模型并且使用相同的提示词模板和解析逻辑。第三优先关注稳定消耗。即使模型能力上限不高只要在业务场景中稳定可预期也比偶尔爆发但经常出错的模型更适合生产环境。第四保留切换空间。如果项目用了某个闭源模型的 API建议把所有直连调用封装到独立模块里接口抽象为“模型无关”这样后续替换模型时不需要重构业务代码。5. 环境准备搭一个最小可用的评测环境如果你想把上面那套评估方法落地需要一个最小可用的评测环境。这里给出一个通用方案不依赖具体云厂商。核心组件包括一台带 GPU 的开发机或者至少一张 8GB 以上显存的显卡用于小模型本地验证闭源大模型走 API 时对本地显存要求不高。Python 3.9 以上环境。一个测试数据集建议从真实业务请求中脱敏抽样 50 到 200 条覆盖正常输入和异常输入。接口调用 SDK 或 HTTP 客户端。5.1 检查 GPU 资源nvidia-smi这条命令用来查看显卡型号、显存总量、当前占用和温度。如果机器上有多个进程占用显存用下面的命令可以按显存占用排序查看nvidia-smi --query-gpuindex,name,memory.total,memory.used,memory.free --formatcsv当显存不够时你可能看到的是CUDA out of memory而不是模型能力问题。评测前先确定资源水位避免误判。import subprocess import re def get_gpu_memory_map(): result subprocess.run( [nvidia-smi, --query-gpuindex,name,memory.used,memory.free,memory.total, --formatcsv], capture_outputTrue, textTrue, checkTrue, ) lines result.stdout.strip().splitlines()[1:] gpu_map [] for line in lines: parts [x.strip() for x in line.split(,)] gpu_map.append( { index: parts[0], name: parts[1], used: parts[2], free: parts[3], total: parts[4], } ) return gpu_map if __name__ __main__: for gpu in get_gpu_memory_map(): print(gpu)5.2 安装基础依赖以下是一个通用的依赖安装命令实际版本号请以你使用的框架文档为准pip install openai pandas requests tiktoken如果你的项目走本地部署例如使用 vLLM 或者 Ollama 启动本地模型需要额外安装对应服务端依赖。这里只做通用说明不建议在没有手册的情况下直接安装最新版框架容易踩坑。6. 功能测试与效果验证用回归集代替“感觉”瓶颈期最忌讳的做法是“凭感觉判断模型变好还是变差”。正确做法是建立一套固定回归集每次换模型、换提示词、换参数时都跑同一批测试用例比较输出差异。6.1 回归测试集设计回归集至少要包含三类样本标准样本典型业务输入期望模型稳定输出正确结果。边界样本超长文本、空输入、多语言混合、特殊字符、JSON 嵌套等。对抗样本容易引发幻觉的模糊问题、需要明确说“不知道”的问题。下面是一个 JSON 测试集的示例结构{ test_cases: [ { id: case_001, category: standard, prompt: Summarize the following meeting notes into three bullet points., input_text: ..., expected_keywords: [decisions, next steps, owner] }, { id: case_002, category: edge, prompt: Extract all dates from this text., input_text: , expected_behavior: reject_or_empty } ] }6.2 批量评测脚本示例下面是一个使用 OpenAI 兼容接口的批量评测脚本骨架。兼容 OpenAI 接口的服务都可以直接用只需要替换base_url、api_key和model三个参数。import json import time from openai import OpenAI # 配置服务地址和模型名实际使用时按项目替换 client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY, # 本地服务通常不需要真实密钥 timeout60, ) MODEL_NAME your-model-name def run_single_case(case): prompt case[prompt] if input_text in case and case[input_text]: prompt prompt \n\n case[input_text] start time.time() try: response client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperature0.2, max_tokens1024, ) latency_ms (time.time() - start) * 1000 content response.choices[0].message.content return {id: case[id], success: True, output: content, latency_ms: round(latency_ms, 2)} except Exception as exc: return {id: case[id], success: False, error: str(exc), latency_ms: round((time.time() - start) * 1000, 2)} def run_batch(test_file_path, output_file_path): with open(test_file_path, r, encodingutf-8) as f: data json.load(f) results [] for case in data[test_cases]: result run_single_case(case) results.append(result) print(f{result[id]}: success{result[success]}, latency{result.get(latency_ms)}ms) with open(output_file_path, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: run_batch(./test_cases.json, ./results.json)跑完这个脚本后你会得到三样东西每个用例是否成功。成功时的输出内容。每次请求的延迟数据。建议把结果保存为带时间戳的目录方便多轮对比eval_results/ 2025-01-15_modelA/ 2025-01-15_modelB/这样对比模型 A 和模型 B 时不需要靠记忆直接翻目录。6.3 判断成功标准不同任务的成功标准不一样。这里给几类常见判断思路抽取类任务期望信息是否出现是否没有多余内容。摘要类任务关键点是否覆盖不能只看是否通顺。工具调用类任务返回的 JSON 是否符合 schema参数是否在允许范围内。问答类任务答案是否正确同时要关注“不知道”的场景是否诚实拒绝。7. 接口 API 调用与批量任务把评估变成流水线基础模型能力进入平台期后真正拉开差距的是工程化能力。评估模型也好持续监控线上效果也好都离不开接口 API 和批量任务设计。7.1 通用 API 调用模板现在多数模型服务都提供 OpenAI 兼容接口所以下面的模板可以直接用于很多平台。使用前确认base_url、api_key、model是否正确。import requests url http://127.0.0.1:8000/v1/chat/completions headers { Authorization: Bearer EMPTY, Content-Type: application/json, } payload { model: your-model-name, messages: [ {role: system, content: You are a helpful assistant.}, {role: user, content: Explain the slowdown in AI progress in three sentences.}, ], temperature: 0.3, max_tokens: 512, } resp requests.post(url, headersheaders, jsonpayload, timeout120) print(resp.status_code) print(resp.json()[choices][0][message][content])如果使用官方 SDK方式和上一节的示例一致。两种方式任选其一。7.2 批量任务设计建议瓶颈期评估模型、做数据处理、跑内容生成都需要批量任务能力。一个完整批量任务流程至少包含四个环节输入管理把待处理的请求放入队列或目录建议每条记录带唯一 ID方便追踪失败项。并发控制不要一次性把几百个请求同时打给接口设置合理的并发数或速率限制避免触发服务端的限流。失败重试遇到超时、5xx、429 时使用指数退避重试。结果归档把成功和失败的结果分开存储方便复盘。下面是一个带重试逻辑的批量处理骨架import json import time import requests MAX_RETRIES 3 def call_with_retry(payload): for attempt in range(MAX_RETRIES): try: resp requests.post( http://127.0.0.1:8000/v1/chat/completions, headers{Authorization: Bearer EMPTY, Content-Type: application/json}, jsonpayload, timeout60, ) if resp.status_code 200: return resp.json() if resp.status_code in (429, 500, 502, 503): wait_time 2 ** attempt time.sleep(wait_time) continue return None except requests.exceptions.Timeout: time.sleep(2 ** attempt) return None7.3 批量任务失败排查批量任务最常出现的三个问题限流现象是大量 429 错误。解决方法是降低并发、增加退避等待时间。格式错误现象是部分任务返回 JSON 解析失败。解决方法是把模型输出先放到字符串字段里再做二次解析。超时现象是长文本任务或工具调用任务经常超时。解决方法是分片处理或者把超时时间调大。8. 资源占用与性能观察别把工程问题当成模型问题“模型能力下降”这类判断很多其实是资源或工程问题造成的误判。所以资源占用观察是模型评估里不能省的一环。8.1 显存占用怎么观察本地部署模型时用下面命令实时观察显存watch -n 1 nvidia-smi也可以在 Python 中周期性记录显存占用import subprocess import time def log_gpu_usage(interval_seconds5, total_seconds60): end_time time.time() total_seconds while time.time() end_time: result subprocess.run( [nvidia-smi, --query-gpuindex,memory.used,memory.free, --formatcsv], capture_outputTrue, textTrue, ) print(result.stdout.strip()) time.sleep(interval_seconds) if __name__ __main__: log_gpu_usage()显存占用会随以下几个因素变化输入长度越长KV Cache 占用越高。批量推理的 batch size 越大峰值显存越高。输出 max_tokens 设置越大生成期间显存占用越高。并发请求数越多显存占用越高。如果遇到显存不足优先降低 batch size、减少 max_tokens、缩短输入长度而不是直接判定“模型不行”。8.2 延迟稳定性要比平均延迟更重要评估模型时不建议只看平均延迟。一次请求慢 20 秒其他请求快 1 秒平均延迟会被拉低但实际体验仍然很差。建议记录 P50、P95、P99 分位数。P99 尤其重要因为它决定了你的服务在峰值流量下是否会大面积超时。下面是一个简单的延迟分位统计脚本import json import numpy as np with open(./results.json, r, encodingutf-8) as f: results json.load(f) latencies [r[latency_ms] for r in results if r.get(latency_ms)] print(P50:, np.percentile(latencies, 50)) print(P95:, np.percentile(latencies, 95)) print(P99:, np.percentile(latencies, 99)) print(Max:, max(latencies))如果 P99 远高于 P50说明服务在高负载下存在明显抖动。这时候要排查服务端并发配置、显存分配策略、磁盘 IO 和网络状况。8.3 判断“能力下降”还是“环境问题”下面是判断思路表现象更可能是能力问题更可能是环境问题短输入也频繁出错是否长输入才出错否是显存或上下文处理偶发超时否是并发或网络同一输入多次结果波动大是模型稳定性否高并发时崩溃否是资源不足换模型后大幅改善是选型问题否9. 常见误判与排查方法“AI 发展遇瓶颈”这个说法如果落到单个团队身上往往表现为一些具体的、可排查的误判。下面列几个最普遍的情况。误判表现可能原因排查方式应对思路觉得新模型不如旧模型提示词模板没有适配新模型用同一套提示词跑新旧模型回归集按模型微调提示词不要默认迁移跑分高但业务效果差公开 benchmark 与实际业务分布不一致用业务真实数据做脱敏回归建立业务专属评测集批量任务大量失败并发过高触发限流查看服务端返回状态码降低并发增加退避重试本地推理经常 OOM显存不足或 batch 太大nvidia-smi 观察显存减小 batch缩短输入接口偶尔很慢服务端负载不均记录 P99 延迟增加超时做重试模型输出格式不稳定提示词约束不足检查原始输出增加结构化输出约束或做二次解析校验同一任务结果忽好忽坏采样参数过高固定 temperature 对比业务场景中降低 temperature觉得数据质量不如从前训练数据被合成数据污染保留真实数据样本做抽检用真实数据构建验证集10. 给开发团队的使用建议瓶颈期最值得做的事情是从“追模型”转向“建体系”。这里给出几条具体建议。第一建立业务回归集。从真实请求中抽 50 到 200 条脱敏后固化到仓库中。每次换模型、调提示词、改参数都跑一遍。这条成本最低收益最大。一旦效果好与坏有了量化依据你的选型和升级决策就不会被单次案例带偏。第二保持模型无关抽象。把模型调用封装成独立服务或独立函数内部只暴露chat/message这类通用接口。这样即使闭源模型停服、涨价或效果回退替换时也只需要改一个适配层。第三多模型路由而不是单模型捆绑。在瓶颈期没有一个模型能在所有任务上都最优。可以在架构上按任务类型做路由简单抽取任务用小模型复杂推理用大模型图像相关任务走专用模型。这既能够降低成本也能减少单一模型的稳定性风险。第四做好合规和版权管理。在使用 API 处理业务数据时要确认数据是否允许发送给第三方模型服务涉及用户隐私、人脸、声音、版权素材的处理必须确认授权。模型生成内容在商用前也要做复核尤其是事实性内容。第五不要迷信“下一代模型解决一切”。模型迭代当然要跟但更重要的是一套可持续的评测、反馈、优化闭环。如果在团队里能把这套闭环跑起来就算行业创新节奏持续放缓半年你的业务照样能稳定推进。11. 总结瓶颈期的正确姿势回到“AI 发展遇瓶颈创新趋缓”这个议题。从公开信息和技术趋势看基础大模型在架构和数据两个层面确实进入了更平缓的增长阶段但这不意味着 AI 创新停滞。大量创新正在从“模型能力突破”转移到“工程化落地、系统效率、产品体验和评测方法论”上。对开发者来说这不是坏消息。模型能力平台期意味着选型和经验可以沉淀不再需要每三个月重构一次。真正的竞争力来自你对业务的理解、对模型边界的判断以及一套可靠的评测和回归机制。如果你现在正纠结“要不要换新模型、怎么做技术选型”建议先做一件事把过去一个月业务里真正失败的 50 个请求收集起来脱敏后做成回归集用候选模型逐个跑一遍。跑完你自然会知道瓶颈在模型、在提示词还是在自己的工程架构里。这个动作比任何榜单和新闻都更接近真相。