79%开发者都在用，但只有51%上线了：开源AI的"最后一公里"卡在哪
2026年9月7日，SlashData和Mozilla联合发布了一份数据复核。调查范围覆盖1494名正在把AI功能集成进产品的真实开发者，时间是今年5月。结果公布了两个数字：
79%的开发者在用开源AI模型。
只有51%真正把它搬上了生产环境。
对照组是用闭源模型的开发者，生产率是63%。
28个百分点的差距，不是模型质量问题。这是Mozilla CTO Raffi Krikorian在原报告里反复强调的判断："这是一个基础设施问题，不是能力问题"。SlashData研究人员Alvaro Ruiz Cubero的原话更直接：性能是开发者最少抱怨的事，他们抱怨最多的是部署、扩展、维护、基础设施。
本系列前两篇讲了开源模型的流量逆转（第04篇）和选型方法论（第05篇）。这一篇拆最后一个问题：模型够好，价格够低，但为什么还有一半人没把它真正用起来。这道墙有个业界术语，叫开源AI的"最后一公里"。
一、那个反直觉的28%差距
1.1 79% vs 51%在说什么
把SlashData和Mozilla的两个数字放一起看，才看出问题严重。
| 维度 | 开源模型 | 闭源模型 | 差距 |
|---|---|---|---|
| 开发者使用率 | 79% | 71% | +8% |
| 项目上线率 | 51% | 63% | -12% |
开源模型开发者用得多，但上线少。闭源模型开发者用得少，但上线多。这种倒挂说明一件事：试用门槛已经很低了（拉权重跑起来谁都会），交付门槛还很高（让它扛住真实流量撑过凌晨三点，难住了大多数团队）。
更反直觉的一组数据是按公司规模拆的。
- 小公司（2-50人）：开源生产率53%，闭源54%。差距几乎为零。
- 大公司（1000人以上）：开源生产率57%，闭源73%。差距拉到了16个百分点。
按理说，越大的公司越有资源把开源模型送进生产，结果差距在大公司反而拉大了。SlashData的解读是：真正的瓶颈不在算力和人手，而在大公司面对的工具链、企业级支持、部署成熟度，这些恰恰是开源生态目前最缺的。
数据来源：slashdata.co 2026.09.07 blog_open-models-production-gap；Mozilla State of Open Source AI 2026 报告
1.2 开发者到底卡在哪
SlashData这次调查问了一个具体问题：用开源模型的人觉得什么事最难。结果四项回答把"模型质量"挤出了前三。
- 部署、扩展的复杂度（27%）
- 安全和合规（26%）
- 持续维护和更新（24%）
- 基础设施成本管理（23%）
- 模型性能本身：没有进入前四
把这四项翻译成工程师听得懂的话：模型你能跑起来，但你不知道怎么扛高并发；模型你能用，但你不知道它会不会吐出违规内容；模型你能跑，但你不知道下个月要不要升级，要不要重训，硬件要不要换；模型你能跑，但你不知道怎么算这笔账合不合算。
四个问题全部指向"伺候模型"这件事，而不是"用模型"这件事。
1.3 一个关键洞察：卡在企业级工具链
Mozilla的报告原文里有一句话值得全文背诵："大型企业级部署更频繁地通过厂商合作伙伴完成，而不是内部自建。"
这句话有两层信息。第一层是事实描述：开源模型在企业级的部署，多数需要外部支持才能完成。第二层是对生态的诊断：开源AI目前的工具链还没有成熟到可以让普通企业团队独立交付。
Stripe的73%成本降幅案例在第05篇里讲过，但有一个细节没展开。Stripe把日均5000万请求切到开源模型不是自己在内部搞定的，是用vLLM团队配合实施的。VLLM不是天上掉下来的，是UC Berkeley实验室开源出来的、有专业团队维护的、有商业化公司支撑的项目。它代表的是"专业团队+专业工具"的范式。普通团队自己去读vLLM代码然后调到生产可用，时间成本远高于用闭源API。
这构成了开源AI"最后一公里"的核心矛盾：模型是免费的，工程能力是稀缺的。
二、Stripe怎样把5000万日请求扛在vLLM上
2.1 73%降幅的工程账
Stripe把每日5000万次API调用从原来的闭源路径迁到了开源权重模型+vLLM的组合，成本降73%。有几个数字值得展开。
- 原有的GPU机队规模缩减到原来的三分之一。
- 推理服务全部用vLLM承担。
- 留了大约2%的关键路径走闭源做兜底（这部分不能用开源赌）。
- 端到端延迟P99没有显著上升，可用性SLA保持不变。
工程师视角看，73%的成本降不是模型便宜就自动出来的。它来自三件事叠加：第一，开源模型每次调用的边际成本接近零；第二，vLLM的PagedAttention把KV cache内存碎片化率压到极低，单位GPU能塞下的并发请求数翻了几倍；第三，工程团队有意识地排除了能预见到的失败模式（路由熔断、慢请求隔离、模型降级）。
数据来源：Mozilla State of Open Source AI 2026 报告案例章节
2.2 Nagle-Yue算的一笔账
Mozilla报告引用了一项叫Nagle-Yue的研究，给出整个行业的估算：开源与闭源之间的成本差，每年对应着约248亿美元的"未实现节省"。换句话说，企业用户在2026年因为选择闭源而不是开源，集体多花了248亿。
这个数字怎么来的。开源推理每次调用比闭源便宜约6倍（同能力下）。所有企业的总推理支出估算约500亿。这6倍价差对应的"潜在节省"就是248亿。
数字很大，但有个前提：每一美元要真正省下来，前提是企业愿意付工程上的代价。这又回到了28%差距的问题。
2.3 一个垂直行业的真实切面
金融科技公司Stripe之外的另一个例子：印度Paytm。Paytm在2026年第二季度把核心客服系统的AI部分迁移到开源模型，处理峰值约80万次/小时。迁移前后成本对比数据未公开披露，但该公司CTO在公开访谈里提到的关键经验是："省下的Token钱几乎全部投进了工程团队扩招"。
这句话在开源圈被反复引用，因为它点破了"开源不便宜"这件事的本质。企业用闭源API时，付的是订阅费；用开源模型时，付的是工程人力费。两笔账表面不一样，核算起来总成本可能差不了多少。区别在哪？在数据主权、长期可控、供应商锁定风险这些不能用钱直接衡量的维度。
三、推理引擎怎么选：四引擎2026年实测
把模型跑起来的第一步是选推理引擎。2026年的开源生态里，主要有四个可选。这条选错了，后面所有事情都白干。
3.1 一次说清楚四引擎的分工
| 引擎 | 底层语言 | 内存管理 | 批处理 | 定位 |
|---|---|---|---|---|
| vLLM | Python + CUDA | PagedAttention（动态分页） | 连续批处理 | 生产服务，高并发 |
| Ollama | Go + llama.cpp C++后端 | 静态分配 | 请求级别排队 | 本地开发，单用户 |
| llama.cpp | C/C++ | 静态分配 | 串行处理 | CPU/边缘，无GPU场景 |
| TGI | Rust + Python | 动态管理 | 连续批处理 | HuggingFace生态深度集成 |
数据来源：aimadetools.com vLLM vs Ollama vs llama.cpp vs TGI 2026对比
关键区分点：vLLM是GPU优先生产级引擎，PagedAttention是它的招牌；Ollama包装了llama.cpp让本地启动只需一条命令，牺牲了并发性能换来了上手便利；llama.cpp是CPU推理的王者，没有GPU的边缘设备和笔记本上是唯一靠谱选择；TGI是HuggingFace自家的推理服务器，和Hub生态无缝绑定。
3.2 一组不能跳过的实测数字
SitePoint 2026年的基准测试在单卡RTX 4090上跑Llama 3.1 8B：
- 单用户吞吐量：Ollama约62 tok/s，vLLM约71 tok/s，差距14%。
- 50用户并发吞吐量：Ollama约155 tok/s（队列式），vLLM约920 tok/s（连续批处理），差距×5.9。
- 50用户的P99延迟：Ollama 24.7秒，vLLM 2.8秒。
数据来源：sitepoint.com Ollama vs vLLM Performance Benchmark 2026
差距的物理来源是vLLM的连续批处理（continuous batching）。Ollama的请求级别排队意味着新请求要等当前请求完成才能进队列，并发数一高延迟就爆炸。vLLM把多个请求塞进同一个forward pass，吞吐量随并发线性爬升，延迟保持稳定。
另一组来自Red Hat的实测更惊人：同样硬件，vLLM峰值793 tok/s对Ollama的41 tok/s，差距19倍。P99延迟vLLM 80毫秒对Ollama 673毫秒。
数据来源：ecorpit.com Local LLMs in production 2026
更细的：用Llama 3 70B在4张A100 80GB上做50并发用户测试，结果如下。
| 引擎 | 总吞吐量 | P50延迟 | P99延迟 | GPU利用率 |
|---|---|---|---|---|
| vLLM | 4,200 tok/s | 45毫秒 | 120毫秒 | 92% |
| TGI | 3,100 tok/s | 55毫秒 | 180毫秒 | 85% |
| Ollama | 1,800 tok/s | 90毫秒 | 350毫秒 | 70% |
| llama.cpp | 1,200 tok/s | 130毫秒 | 500毫秒 | 65% |
数据来源：aimadetools.com 2026基准
3.3 SGLang这个新选项
SGLang在2026年的生态里值得单独提一句。它在多轮对话Agent场景下表现尤其好，原因是RadixAttention对prefix cache的优化路径。
EastKode的实测给出的数字（Qwen 2.5-32B，50并发）：
- SGLang：418 tok/s聚合吞吐，首token延迟（prefix cache命中）8.4毫秒。
- vLLM：392 tok/s聚合吞吐，首token延迟28.6毫秒。
- Ollama：94 tok/s，部分连接超时。
数据来源：eastkode.in SGLang vs vLLM vs Ollama 2026基准
SGLang首token延迟比vLLM快3.4倍。这个差距在两种场景下特别值钱：第一是本地代码Agent，系统提示和仓库上下文反复重发，prefix cache命中率高的场景；第二是需要结构化JSON输出的应用，SGLang的radix tree对这类约束解码有专门的优化。
代价是SGLang生态还在快速演化。2026年9月，v0.3.2之前的版本有内存引用计数泄漏的Bug，需要每周重启服务。生产环境部署SGLang需要跟踪版本变更日志。
3.4 选型结论
按用户数和场景对号入座：
- 1-2人开发测试：Ollama。一行命令拉模型，性能损失可接受，便利性最大。
- 2-10人小团队：本地Ollama+生产vLLM双轨。开发用Ollama快速迭代，部署环境用vLLM扛并发。
- 10人以上生产：vLLM是默认选择。如果代码Agent或多轮Agent占流量大头，SGLang值得评估。
- 边缘设备/笔记本/Apple Silicon：llama.cpp。vLLM不支持Apple Silicon的MPS后端。
- HuggingFace深度生态团队：TGI。和Hub无缝集成，水印、量化工具链完整。
两个引擎可以并存（Ollama本地开发，vLLM生产部署），它们共享同一个HuggingFace模型缓存，模型不重复下载。本地测试通过的模型权重可以直接给生产用。
数据来源：getlocalia.com vLLM vs Ollama 2026生产基准
四、生产环境的五个必备组件
模型跑起来只是万里长征第一步。下面五件事，缺一件就是定时炸弹。
4.1 负载均衡
单实例vLLM能扛的QPS有上限。A100 80GB上跑70B模型大概能扛20-30 QPS。再多的请求需要多实例横向扩展，前面挂负载均衡。
生产常见组合：Nginx做L7负载均衡 + vLLM集群 + 健康检查探活。LlamaIndex、Anthropic内部用的都是这个套路。
要点：负载均衡器必须能根据"实例是否在处理请求"做流量分配，不能用简单的轮询。否则部分实例过载部分空闲，整体资源利用率上不去。
4.2 自动扩缩
QPS是脉冲式的。早高峰10倍于深夜，如果按峰值部署就是浪费，如果按均值部署就是崩。
两条路。第一条用云厂商的K8s HPA（Horizontal Pod Autoscaler），根据GPU利用率或QPS扩缩Pod数量。第二条用Serverless推理服务，比如Modal、Replicate、RunPod这些按请求计费，零QPS时成本为零。
大部分中型团队的折中方案：固定3-5个vLLM实例兜底，突发流量走Serverless服务。成本可控，弹性也够。
4.3 健康检查
vLLM实例崩了不会自动拉起新实例。需要外部探活机制：
- Liveness探针：实例是否还活着。挂了的话K8s重启Pod。
- Readiness探针：实例是否准备好接受流量（比如模型权重加载完成）。
- GPU健康检查：用nvidia-smi轮询，发现Xid错误就标记异常。
健康检查不到位的后果是凌晨三点某个实例挂了没人知道，白白丢流量，第二天才发现。
4.4 安全网关
推理API对外开放后，必须在前面加一层安全网关。职责有四项：
- 输入消毒（提示注入检测、可疑token过滤）
- 输出审核（敏感词、违规内容过滤）
- 速率限制（防滥用、防暴力破解）
- 访问控制（API key管理、配额统计）
常见实现：LiteLLM Proxy（自带这些功能）、自建FastAPI中间件、或者用云厂商的API Gateway产品。
提示注入防护的具体规则，下半部分第七节展开。
4.5 可观测性
OpenAI API有完整调用日志，Claude API有控制台。开源自部署没有这些，需要自己建。
最低限度要记录的字段：
| 字段 | 用途 |
|---|---|
| 时间戳 | 排查时间相关问题 |
| 请求ID | 链路追踪 |
| 模型名称 | 哪个模型出了问题 |
| 输入Token数 | 成本核算 |
| 输出Token数 | 成本核算 |
| 总耗时 | 性能基线 |
| 首token延迟 | 用户体验指标 |
| 错误类型 | 失败模式统计 |
| 用户/项目标识 | 按部门/项目分摊成本 |
工具链选择：Prometheus + Grafana做监控、Loki或Elasticsearch做日志、Langfuse或LangSmith做Agent链路追踪。本系列第07篇会专门拆AgentOps，可观测性是其中一大块。
以上为免费试读部分。以下内容仅对粉丝可见，关注后即可阅读全文。
五、开源模型的安全短板与补丁
开源模型的原生安全护栏比闭源粗糙很多。闭源厂商有完整的RLHF团队、红队测试、持续对齐，开源模型只有基础的对齐层。工程师部署到生产环境，必须自建安全层。
5.1 输入消毒：提示注入拦截
2026年4月，Google和Forcepoint同时确认间接提示注入（IPI）已在野外大规模利用。Clinejection（npm token窃取，冲击波系列第04篇讲过）和Claude Code读取/proc/self/environ都是真实案例。
开源方案的几个选择：
- NeMo Guardrails（NVIDIA开源）：基于Colang DSL定义对话流程，支持输入输出双向检查。规则可以热更新，不用重启服务。
- Llama Guard（Meta开源）：Meta和Robust Intelligence合作发布的分类器，把输入输出分安全/不安全/违规三类。配合Llama Firewall可以做更细粒度的策略。
- Lakera Guard（商业）：闭源服务的形式，但提供企业级SLA，云原生部署。
- 自建正则+黑名单：应付初级攻击可以，复杂场景会被绕过。
实战建议：Llama Guard做快速分类（毫秒级），命中可疑的请求再过一遍Lakera的二次确认。这套组合在Mozilla报告引用的一项基准里把检出率从78%提到94%，误报率维持在3%以下。
5.2 输出过滤
模型会吐出违规内容。开源模型没有ChatGPT那种"内容策略"约束，需要自己做：
- 敏感词过滤：用Trie树或AC自动机加速关键词匹配
- 有害内容分类：用一个小模型（Llama Guard 7B/8B）做内容分类
- PII脱敏：邮箱、电话、身份证、银行卡号这些敏感字段实时脱敏
Facebook的Llama Firewall在内容层做的是基于规则的模式匹配和分类器串联。Stripe的安全网关则是规则+统计两层：规则拦截已知违规模式，统计层检测异常分布。
5.3 工具调用权限
开源Agent的MCP生态正在爆发。Mozilla报告给了一个关键数字：MCP的月SDK下载量从2024年初的200万涨到2026年的9700万，16个月增长48倍。活跃MCP服务器数量超过10000个。
数据来源：Mozilla State of Open Source AI 2026报告MCP章节
但生态爆发带来了新风险。安全研究人员在MCP进入Linux Foundation治理的前8周提交了30多个CVE。授权（authorization）：定义Agent能做什么，这个问题至今没有跨厂商的标准化方案。
Mozilla的判断是：认证（authentication）在MCP层已经基本解决，授权（authorization）目前每个Agent框架各搞各的，没有便携标准。这意味着部署开源Agent的工程师必须自己定义权限边界。
5.4 数据隐私
本地部署的最大优势是数据不出域。但部署到生产环境后，这句话有几个限定条件：
- 日志系统是否在本机？遥测是否泄露？
- 用于微调的数据是否本地存储？
- 备份存储在哪里？是否加密？
- 与外部系统的接口（比如RAG检索向量数据库）是否本地？
工程师做合规审计时，这四个问题的答案决定开源部署是否符合GDPR/HIPAA/PCI DSS。Stripe和Coinbase的数据不出域部署，把这些问题的答案作为架构设计的强约束。
5.5 模型供应链安全
开源模型的权重来源必须可验证。HuggingFace上的模型可能包含被后门植入或投毒的版本。Mozilla报告引用的案例是2024年某研究团队发现的"BadLlama"后门：恶意权重在特定触发条件下会让模型输出特定违规内容。
工程实践：
- 只下载SHA256校验通过、有数字签名的模型权重
- 优先选择知名组织（Meta、Mistral、DeepSeek、月之暗面、阿里）发布的官方版本
- 部署前在隔离环境做行为测试，对比基准模型的输出分布
- 持续监控模型推理日志，发现分布漂移立即报警
六、从Demo到生产的完整Checklist
按时间线把部署开源模型的工程任务展开。
Day 1：选模型+本地跑通
- 根据任务类型（编程/RAG/对话/多模态）选3个候选模型
- 用Ollama或vllm本地拉权重跑通基本对话
- 用业务真实样本做定性评估（不是用公开数据集）
- 记录每个模型的输入输出延迟、显存占用、token化速度
Day 2-7：API封装+性能压测
- 用vLLM或SGLang做生产推理服务，监听端口
- 写OpenAI兼容的API包装（vLLM内置）
- 用Locust或wrk做QPS压测，测P50/P95/P99延迟
- 测不同请求长度、不同并发数下的吞吐拐点
Day 8-14：监控+安全+灰度
- 接入Prometheus，记录第四节的9个核心字段
- 配置安全网关（输入消毒+输出过滤+速率限制）
- 灰度发布：先内部团队用，监控2周
- A/B测试：和闭源基线对比，质量不下降才放量
Day 15-30：全量上线+持续优化
- 按部门/项目拆分API key，分摊成本
- 设置月度预算上限，到80%触发告警
- 建立模型升级流程（每3个月评估新版本）
- 跑行为评估流水线（不是为了炫技，是为了量化质量变化）
关键生产指标参考线
| 指标 | 健康线 |
|---|---|
| P99延迟 | < 2秒（聊天场景），< 5秒（Agent多步调用场景） |
| 服务可用率 | > 99.5%（月停机时间< 3.6小时） |
| 单次调用成本 | < 0.01（廉价档），\< 0.05（升级档） |
| 错误率 | < 0.5%（不含业务预期的失败） |
| 幻觉率 | < 5%（任务型），< 10%（开放式对话） |
数据来源：综合Mozilla State of Open Source AI 2026报告、SlashData调查、vLLM官方文档
节奏上的一条经验
Mozilla报告里有一个细节被很多读者忽略：开源模型的部署成功率，企业如果有外部合作伙伴支持，落地概率显著高于纯内部自建。这是工程经验的复用问题，不是技术能力的差距。
小团队的应对策略：先用vLLM、Ollama这些成熟工具快速搭起来，遇到性能瓶颈、稳定性问题再去查文档或请教社区。不要一上来就试图调优一切。先跑起来，再优化。
七、开源AI"最后一公里"的三个推进器
7.1 推理引擎的连续批处理成熟
2025年到2026年vLLM、Ollama（升级了llama.cpp后端）都在持续优化连续批处理路径。SitePoint 2026基准显示，Ollama在多用户并发下的性能比2025年初提升了约3倍（来自底层llama.cpp的批处理改进）。这意味着"本地也能扛住小组规模"的工具越来越接近可用。
7.2 MCP生态从0到1到规模
MCP 16个月下载量从200万到9700万的增长曲线，背后的驱动力是协议层的标准化。一旦Agent的工具调用有了标准协议，开发者的切换成本大幅下降。生态规模上来后，反过来给"开源模型最后一公里"提供了大量可复用的工具。
注意一个尚未解决的盲点：授权层的可移植标准还没建立。每个Agent框架自己定义权限边界，企业落地时必须自己设计。
7.3 商业化推理服务商补位
Together AI、Fireworks AI、Replicate、Modal这些公司把开源模型包装成"按请求计费的API"，让用户用闭源API的便利性调用开源模型。这条路径对不愿自己运维团队的中型企业特别有吸引力。
代价是商业化推理服务商的定价不一定比自己跑vLLM便宜。它们的真正价值是省去了运维人力，而不是省Token钱。
八、辩证看待：开源最后一公里的三个清醒判断
8.1 节省Token钱不等于净省
开源推理看起来每次调用便宜几倍，但工程人力成本要算进来。一家中型企业组建3人推理运维团队，月度人力成本约$45,000。如果通过API用闭源模型，这笔费用为零。
简单的算账：开源部署每年省下的Token费，能不能覆盖工程团队的成本？答案很大程度上取决于流量规模和稳定性。流量越大，开源越划算；流量越波动，闭源+弹性更好。
Paytm的CTO说"省下的Token钱全部投进了工程团队扩招"，这句话里有开源经济的真实账本。
8.2 模型质量差距还剩3%，但分布不均
Mozilla报告里的3.3%平均差距，看起来不大，但Mozilla用了"锯齿状前沿"（jagged frontier）这个词来描述真实分布。意思是：有些任务差距接近零，有些任务差距10%以上。
排序大致是：
- 编程、指令遵循、通用知识问答：差距几乎为零
- RAG检索、长上下文、多轮对话：差距个位数百分点
- 深度推理、复杂多Agent规划、长程自主任务：差距10%以上（闭源仍然领先）
部署前先用业务真实样本做小规模A/B测试，别只看公开榜单。Terminal-Bench 2.0上GPT-5.5是83.4%对开源最好的67.9%（15.5个百分点差距），这个差距在编程Agent场景上很难无视。
8.3 开源成熟度提高但企业级标准仍未建立
2026年的开源模型生态比2024年成熟很多。vLLM已经能扛工业级流量，MCP生态规模起来了，LangChain/LlamaIndex这类编排框架的稳定性大幅改善。但Mozilla报告点了一个关键缺口：企业级支持仍依赖外部合作伙伴。
这意味着，开源AI的最后一公里会继续缩短，但短期内不会消失。2027年的合理预期：28%的差距会缩小到10-15%，但不会完全消失。工程师的工具栈里，"会用闭源API的能力"和"能把开源送上生产的能力"会持续同时有价值。
本系列导航
本文是《AI下半场：Agent淘金热》系列第06篇，开源逆袭篇第三篇。
| 篇号 | 标题 | Phase | 状态 |
|---|---|---|---|
| 01 | AI不能拖欠工资：Uber四个月烧光全年AI预算 | 成本黑洞 | 已发 |
| 02 | 从1200到5亿：2026年最贵AI编程翻车账单全曝光 | 成本黑洞 | 已发 |
| 03 | Token降了99%，账单涨了100倍：2028年AI编程成本将超过你的年薪 | 成本黑洞 | 已发 |
| 04 | 45%的AI流量已转向中国开源模型：K3登顶那天，账要重新算了 | 开源逆袭 | 已发 |
| 05 | 从OpenAI到DeepSeek到本地Llama：一张路由表，把AI账单砍到一半以下 | 开源逆袭 | 已发 |
| 06 | 79%开发者都在用，但只有51%上线了：开源AI的最后一公里 | 开源逆袭 | 本文 |
| 07 | 90%Agent试点活不到生产：活下来的10%做对了什么 | 工程落地 | 待发 |
| 08 | 多Agent一上线就打架：20个Agent协同的工程噩梦 | 工程落地 | 待发 |
| 09 | 从Prompt到Shell：AI Agent安全攻防2026实战手册 | 工程落地 | 待发 |
| 10 | AI Engineer年入35万：增长最快职业在做什么 | 黄金时代 | 待发 |
| 11 | 只会写代码被淘汰，只会写Prompt也快被淘汰 | 黄金时代 | 待发 |
| 12 | 2027年AI行业预测：5个确定性布局机会 | 黄金时代 | 待发 |
前作推荐：
- 《AI下半场》第05篇"一张路由表把AI账单砍半"：模型选型与路由策略
- 《AI下半场》第04篇"K3登顶那天账要重新算了"：开源流量逆转的趋势数据
- 《本地AI配置系列》全20篇：开源模型本地部署的完整技术底座
数据来源
本文数据来源于以下英文信源（2026年9月15日检索验证）：
- slashdata.co/blog_open-models-production-gap 2026.09.07：SlashData与Mozilla联合发布的2026年5月1494名开发者调查，79% vs 51%的核心数据，公司规模分布下的差距变化
- Mozilla State of Open Source AI 2026报告（SlashData 1494人调查+OpenRouter 100万亿Token数据集）：开源闭源3%差距、Terminal-Bench 2.1分数、Nagle-Yue $248亿未实现节省、Paytm案例、Stripe 5000万日请求迁移详情
- uctoday.com/mozilla-state-of-open-source-ai-2026-report：Mozilla CTO Raffi Krikorian的判断、Linux Foundation分析、Agent治理成熟度21%、MCP 16个月200万到9700万下载量增长
- toolradar.com/blog/open-source-ai-production-ready：开源生态成熟度判断、SlashData研究人员Alvaro Ruiz Cubero关于"基础设施不是模型质量"的原话
- tech-insider.org/open-source-ai-usage-revenue-gap-2026：四项具体挑战（基础设施27%、安全26%、维护24%、部署23%），LangChain 126K星/MCP 10000+活跃服务器/30+ CVE细节
- sitepoint.com/ollama-vs-vllm-performance-benchmark-2026：vLLM vs Ollama RTX 4090 Llama 3.1 8B的62/71 tok/s单用户差距、155/920 tok/s 50并发差距、P99 24.7秒对2.8秒延迟对比
- aimadetools.com/blog/vllm-vs-ollama-vs-llamacpp-vs-tgi：四引擎2026基准测试，Llama 3 70B 4×A100 50并发，vLLM 4200 tok/s、TGI 3100、Ollama 1800、llama.cpp 1200的完整对比表
- getlocalia.com/en/blog/vllm-vs-ollama-production-benchmark-2026：RTX 5090 2×NVLink Llama 3.3 70B Q4单用户14%差距、4用户3.3倍、10用户P95 6倍的具体场景数据
- ecorpit.com/local-llm-production-vllm-ollama-lm-studio-2026：Red Hat官方基准vLLM 793 tok/s对Ollama 41 tok/s的19倍差距，P99 80毫秒对673毫秒；印度DPDPA 2023合规环境讨论
- eastkode.in/articles/sglang-vs-vllm-vs-ollama-benchmark-2026：SGLang v0.3.2的RadixAttention prefix cache 8.4ms TTFT对vLLM 28.6ms对Ollama 184ms的3.4倍差距，VRAM泄漏30天测试细节
- techplanet.today State of Open Source AI in 2026：OpenRouter上中国开源模型周18万亿Token对美国5.5万亿的3:1分布，Top 5开源权重模型详情
标签 ：AI 人工智能 AIGC 开源模型 vLLM Ollama AI Agent 本地部署