AI投资飙升，但仅1%企业声称部署“成熟”。前段时间各家调研机构的数据都在往这个方向上指：一边是AI相关的预算、算力采购、招聘岗位翻着倍地涨，一边是企业自己的评估体系里，真正敢给自家AI部署打上“成熟”标签的，少得可怜。我这些年帮不少企业做过AI落地的POC和正式交付，对“投资热”和“落地冷”之间的巨大落差感触很深。很多公司确实真金白银地砸下去了，也跑通了不少demo，但一到生产环境就卡住：不是模型跑不起来，而是跑起来之后没人敢对效果和稳定性负责。
这篇文章就围绕“为什么投资这么热、成熟度这么低，以及部署这件事到底难在哪”展开，把我自己在实际项目中反复踩过的坑、总结过的方案，还有排查问题的思路一次讲清楚。内容主要面向正在帮企业做AI落地决策的工程师、架构师，也适合负责技术选型或者已经买了显卡但还没真正上线的团队参考。没有太多理论铺垫，都是我做项目时一步一步试出来的经验。
1. AI投资热与部署成熟度差距的现状
1.1 “1%成熟”到底说明什么问题
很多文章引用这个“1%”的时候，都默认读者知道“成熟”是什么意思。但我在实际接触企业时发现，大家对这个词的理解差异非常大。有的企业觉得“能用一个网页问答工具跑起来”就算部署成功，有的企业把“模型能应用到一条核心业务链路上，稳定运行三个月不出事故”才算起步。
所谓“成熟”，我更愿意用这几个维度来定义：一是模型服务可以承载真实业务流量，而不是只服务少数测试人员；二是有完整的监控、告警、日志和回归评估机制；三是模型更新、数据回流、故障恢复都有固定的流程；四是整个系统的成本和资源利用率是可量化、可预测的。拿这个标准去看，1%其实不夸张。
调研里另一些数字也能对上这个判断——比如部署难度高、内部AI技能不足、数据接入成本高，这些常年占据企业AI落地障碍的前几位。投资热体现在采购层面上，成熟度低体现在运营层面上。简单说，钱花出去了，但能长期持续稳定“干活”的系统少。
1.2 钱都花在哪，又卡在哪
从资本和采购端看，AI投资飙升的逻辑其实很简单。GPU服务器供不应求，云GPU实例价格居高不下，AI岗位薪资持续上涨，企业在预算表上写的都是几百万甚至上千万的计划。但真正落到部署侧，钱并不直接等于能力。
我见过一家制造业客户，采购了八张高端显卡，准备给产线做视觉检测模型。结果模型选型阶段就拖了两个月，因为一直纠结是直接用开源模型还是找厂商定制；随后标注数据又花了三周；真正部署到产线边缘设备的时候，发现工业相机的接口协议和推理服务的对接文档完全对应不上。硬件、软件、数据、业务系统四个环节，只要有一个断裂，前面花的钱就全部处于“待机”状态。
另一个常见的卡点是团队配置。有能力做大模型选型和环境搭建的人，往往不了解具体业务流程；懂业务的人又不懂模型接口怎么调。最后的结果就是demo做得漂亮，生产环境没人敢碰。
1.3 “能跑”和“能用”之间隔着一整条流水线
很多人误以为部署AI等于“把模型文件加载起来，调用一下推理接口”。实际上生产级部署至少包含模型服务化、推理优化、接入层改造、数据管道、评估与监控、权限与合规、故障恢复七个子系统。
用一个比喻：模型文件只是引擎，部署是把引擎装进车架、接上油路电路、配上仪表盘和安全气囊的过程。发动机能点火，跟车能安全上路完全是两码事。我见过太多团队卡在“引擎已经能点火”这一步，然后误以为只差“多踩两脚油门”。实际上，光是把模型封装成一个稳定的API服务，就已经涉及并发控制、超时处理、显存管理、失败重试、灰度发布这些工程问题。
2. 部署成熟度上不去的深层原因
2.1 误区：装了模型不等于完成了部署
这里我得先泼一盆冷水：能启动模型，连“部署完成”的十分之一都算不上。我在很多企业里看到的情况是：用Ollama或者FastAPI把模型跑起来，试了几个问题觉得效果不错，就开始准备上线，结果上线第一天就被真实流量打崩了。
因为这中间缺的东西太多了。静态的模型加载只是第一步，后面还有请求排队策略、batch策略、并发上限、降级方案。比如一个知识库问答系统，早高峰几十个人同时提问，如果不对并发做控制，显存和内存会直接被打满，响应时间从几百毫秒漂移到几十秒，用户立刻就会觉得“AI不行”。而这些负载测试、容量规划的工作，恰恰是“从能跑到成熟”的核心部分。
所以我做项目时，第一步永远不是选模型，而是先做需求拆解：这个系统要给谁用、什么时候用、最多多少人同时用、能容忍多慢的响应、数据多久更新一次。答案不同，部署方案完全不同。
2.2 部署架构的隐形门槛
说到部署架构，很多人第一反应就是GPU显存够不够，其实这只是门槛的起点。真正的隐形门槛在推理框架的选择上。同样的模型，用不同的推理引擎跑，性能差距可能有三到五倍。
我常用的推理后端包括vLLM、Text Generation Inference（TGI）、SGLang，还有针对边缘设备优化的TenserRT-LLM。它们在PagedAttention、连续批处理、量化支持这些特性上差异很大。拿vLLM举例，它通过PagedAttention机制大幅提升了显存利用率，同时引入continuous batching让多个请求可以动态共享一次前向传播的计算，压测场景下吞吐量比naive的FastAPI+HuggingFace接口高出一大截。
但是反过来，vLLM对模型的支持范围、与某些自定义算子的兼容性又有限制。你在本地用Transformers库测试得好好的模型，搬到vLLM上可能会报算子不支持。这些坑不实际跑一遍压测，根本发现不了。
2.3 数据接入是比模型更深的坑
如果让我只讲一个“部署不成熟”的最常见原因，我会选数据接入。模型选型错了可以换，推理框架不合适可以调，但数据管道有问题，整个系统就是空中楼阁。
以典型的企业知识库问答系统为例。假设你要用RAG架构，把几十份产品文档、技术支持记录喂给模型做回答。光是把这些文档切块、向量化、存进向量数据库，就已经有一堆细节：文档格式五花八门，PDF里的表格提取出来经常是乱序的；docx里带批注、修订记录，文本清理不干净会影响召回效果；不同语言混排的文档切块策略完全不一样。而且企业数据不是静态的，每周都有新文档进来，增量更新怎么设计、旧版本的向量怎么清理，都是部署方案里必须回答的问题。
我见过最典型的翻车场景：团队花了很多精力把模型调到“看起来没问题”，但一接上真实文档库，召回内容相关性断崖式下跌。后来发现是切块的大小和重叠度设置不合理——块太长，语义混杂；块太短，上下文信息丢失。这些只能在数据接入阶段反复调参，不是换个模型就能解决的。
2.4 评估机制的缺失
另一个严重但容易被忽视的问题是：很多企业根本没有任何模型评估机制。对“成熟”的定义没有数据支撑。
我在一家企业做诊断时问他们：“你们怎么判断模型这周比上周好了还是坏了？”对方说“我们主要靠人工测试，经常试几个问题看看感觉”。这种状态在生产上是不可持续的。模型迭代、提示词调整、RAG参数调整之后，必须有一套固定的基准测试集和评分体系。
一套能用的评估方案不复杂：准备一到两百条覆盖典型场景的评测样本，定义好客观评分标准；把每次模型调整后的输出结果记录下来，做A/B对比。再进一步，可以引入LLM-as-judge，用一个大模型来辅助评分，但需要先校准判断标准。没有这些，部署成熟度就是一笔糊涂账。
3. 手把手：从零到可用的部署流程
3.1 部署前的需求拆解与模型选型
前文说了需求拆解是第一步，这一步做不好，后面全是白忙活。需求拆解至少要产出几个明确结论：最大并发用户数、可接受的响应延迟（P95）、每日调用量、数据更新频率、是否涉及敏感数据。
选型的时候我习惯列一个表来做对比，重点看模型尺寸、量化级别、硬件配置和预估吞吐。举个例子：
模型版本 | 量化级别 | 推荐显存 | 适用场景 | 常伴部署成本 7B | FP16 | 16-24GB | 通用问答、轻量分析 | 低 7B | INT4/AWQ | 8-12GB | 大并发、边缘 | 中（调优成本高） 14B | FP16 | 32-40GB | 较强推理、中文任务 | 中 32B-70B | INT4/INT8 | 48-80GB | 高质量对话、复杂推理 | 高
我最近在项目里比较常用Qwen系列的7B和14B模型，在中文业务场景的性价比非常高。DeepSeek系列里的蒸馏模型也常在私有化部署里出现，配合vLLM做服务化在消费级显卡上表现也算稳定。但我不建议一上来就追求大模型，先用小模型把流水线跑通，再考虑升级方案，这个顺序更稳妥。
3.2 最小环境搭建与首次推理
环境搭建阶段，我强烈建议用Docker，而不是直接在宿主机上裸装依赖。不是说你不会在裸机上装PyTorch和CUDA，而是生产环境需要可复现、可回滚、可迁移，Docker能把这一堆复杂度封装起来。
以vLLM部署Qwen2.5-7B-Instruct为例，一个最小可用方案是这样的：
docker run --runtime nvidia --gpus all \ -p 8000:8000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9启动之后，通过8000端口访问/v1/chat/completions，就能得到兼容OpenAI格式的推理接口。这个“兼容OpenAI格式”的意义非常大，意味着你用LangChain、Dify或者企业自研的接入层，不需要为每个模型单独写适配器。统一接口标准是部署工程化的重要基础。
有个参数要特别解释：--gpu-memory-utilization 0.9表示允许vLLM最多占用90%的显存。剩下10%留给计算图、CUDA context和其他进程。如果设成1.0，一旦有别的进程申请一点显存，就会直接OOM，得不偿失。
3.3 推理性能调优的关键参数
跑通只是第一步，接下来要压测和调优。我先给一个常用参数字段参考。
--max-model-len：决定最大输入+输出长度。设太大会浪费显存，设太小则无法处理长文档。我的习惯是从8192起步，按实际文档长度调整。--tensor-parallel-size：多卡并行时的张量并行度。单卡能放下的时候不用设太大，不然通信开销反而拖慢速度。--max-num-seqs：同时处理的序列数量，直接影响并发吞吐。需要结合显存和单序列长度一起算。--enable-prefix-caching：在多轮对话或RAG场景中可以复用公共前缀的KV Cache，有效减少计算量。- 温度
temperature和top_p：这两个是解码参数，影响随机性。在知识库问答里，我通常会把温度调到0.1到0.3之间，减少无关发挥。
调优不能靠拍脑袋。我会先用hey、wrk或者简单的Python脚本打一轮并发请求，观察吞吐量（tokens/s）和P95延迟。压测结果出来后再逐步调整上面的参数，比如发现显存占用太低、吞吐没有跑满，可以增大--max-num-seqs或并发数。
3.4 从单机推理到服务化改造
模型服务跑通之后，还要把它放进企业技术栈里。这一步里我见过最多的错误是直接把推理端口暴露给内部应用，连鉴权和限流都没有。
一个标准的部署拓扑至少要包含：API网关（负责鉴权、限流、路由）、推理服务（vLLM或TGI）、向量数据库（如果做RAG）、监控系统（Prometheus+Grafana即可满足多数场景）、日志采集。网关层我会用比较成熟的开源方案比如APISIX或Kong，限流策略按照压测测出的吞吐上限来设置，一旦超过阈值就拒绝多余请求而不是让它们把服务拖死。
还要做模型实例的健康检查和存活探针。如果模型服务无响应，网关要能自动摘除节点并触发告警。这些细节在演示环境里没有，但在生产环境缺一个都会出大事。
4. 常见问题与排查技巧实录
4.1 显存OOM：先分清真OOM还是假OOM
显存溢出是出现频率最高的问题。但很多人一看到OOM就慌了，其实要先分两种情况。
真OOM最常见的原因是并发请求过多、单请求序列过长。排查时先用nvidia-smi看显存占用曲线，再结合vLLM日志里max_num_seqs和max_model_len的配置反算一下：请求总数 × 平均序列长度 × 每token显存占用，如果超过显存总量，就降并发或减长序列。
假OOM往往是显存碎片化导致的。比如服务刚启动时显存够用，跑了几个小时之后出现OOM，但nvidia-smi显示总占用并不满。这种情况先看是不是频繁加载和释放大块显存导致的碎片，可以试着重启服务，或者开启vLLM的--swap-space参数，把部分KV Cache换到CPU内存，缓解显存压力。
4.2 推理速度慢：瓶颈定位四步法
响应慢这件事，绝大多数时候不是“模型跑得慢”，而是“别的地方卡住了”。我总结了一个四步定位法：
第一步，看网络层。先确认请求到推理服务的耗时占比，别把网络延迟算到模型头上。第二步，看排队时间。当并发高时，请求在vLLM调度队列里排队，此时日志里的time_per_token正常，但E2E延迟很高，说明是并发超过处理能力了。第三步，看批处理大小。如果batch size只有1，吞吐会很难看，需要确认vLLM的连续批处理是否生效。第四步，看输入长度。超长输入会让prefill阶段耗时暴涨，需要评估是否需要本地先做检索压缩，只把相关片段发给模型。
4.3 输出不稳定：不是玄学
有次客户反馈：“同一个问题，上午和下午的答案不一样，你们是不是模型坏了。”排查之后就发现，是服务的解码参数被某个调用方改掉了，系统里不同的请求用了不同的temperature值。答案不稳定的根源，要么是解码参数不一致，要么是system prompt里带了和业务无关的干扰内容，要么是RAG召回的上下文变了。
解决这个问题的经验是：把解码参数在网关层统一设置，不允许业务方自定义；将system prompt版本化，每次变更都回归评测；RAG召回的top_k和score阈值固定下来，并且把每次召回的文档版本记录下来，方便追踪。
4.4 多用户并发下的抖动问题
单用户测试时一切正常，多个用户同时使用就时不时报错，这是典型的并发问题。常见的坑有几个：
一是Python GIL。如果你用简单的FastAPI+Transformers直接跑推理，并发一高就会卡在GIL上，所以生产环境一定要用vLLM这类并发优化过的推理框架。二是连接数限制。下游系统如果同时建立了大量连接，很容易触发文件描述符限制，报Too many open files。三是数据库连接池。RAG系统的向量数据库连接池配置太小，并发一高就排队。
排查并发问题时，我的建议是先看全链路日志的时间戳分布，画出请求排队区间，然后再逐层定位。别一上来就怀疑模型本身。
5. 从1%迈向成熟的路径与个人体会
5.1 量化“成熟”的四个指标
我接项目时喜欢直接跟客户约定四个量化指标，把“成熟”这个模糊词变成一个可验收的目标：
- 可用性（SLA）：核心服务月度可用时间不低于99.5%
- 延迟（P95）：线上业务请求的P95延迟控制在3秒以内（视具体场景定）
- 成本：每千token的综合成本，包含GPU摊销、电力和人工运维，要有基线值
- 资源利用率：GPU平均利用率不低于40%，避免买了卡闲置
这四个指标一旦达成，企业的AI系统就不算“实验品”，而是可以承载业务的正式资产。
5.2 我给企业的路线图
所有刚起步的企业，我都建议走“POC-试点-规模化”三步，别想着一步到位。POC阶段的目标是花最小的成本验证“这个场景适不适合用AI”，只测20个核心问题，用现成API完成即可，不碰自有数据。试点阶段接入企业内部数据，限定小范围用户，跑通RAG、鉴权、监控这些工程链路。规模化阶段才考虑放开用户范围、横向扩展、优化成本和性能。
按我的经验，POC到试点是最容易烂尾的一段。因为POC是技术问题，试点是技术+流程+组织问题。试点阶段必须拉上业务方一起定评估标准，否则技术团队做得再high，业务方不认账，项目依然会被判死刑。
5.3 个人体会：哪些钱不该急花，哪些坑最隐蔽
最后分享几条我用真金白银换来的经验。第一，不要急于买最好的显卡。先拿一两张卡把整个工程链路跑通，再按压测结果决定是否扩容。很多项目的瓶颈根本不在算力。第二，不要把“模型能力”和“系统能力”混为一谈。方案评审时多问一句：“如果模型响应失控，系统有没有兜底逻辑？”第三，一定要做回滚预案。模型升级之前把旧版本镜像和参数快照存好，一旦线上效果回退，能快速恢复。
我的一个真实体会是：AI部署成熟度低，很大程度不是技术鸿沟，而是工程习惯的鸿沟。模型在快速迭代，但部署它所需要的稳定性、可观测性和流程规范，跟做任何一套正经软件系统没有本质区别。谁先按软件工程的规矩来对待AI部署，谁就能比那99%的企业更早一点摸到“成熟”的门槛。
