1. 从算力到生态AI出海这盘棋到底在下什么2025年过完春节没多久我跟几个做AI基础设施的老朋友聚了一顿。席间聊到一个很明显的感受前两年大家出海张口闭口都是“我手里有多少张卡”“能拿到多少P的算力”而现在再聊话题已经变成了“你的Agent框架能不能接住海外客户的业务流”“你的模型在东南亚小语种上的表现怎么样”。这个转变不是偶然的它背后是整个中国AI出海逻辑的一次结构性切换。所谓“AI出海”说白了就是把国内打磨过的AI能力——不管是底层算力调度、大模型本身还是上层Agent应用——输出到海外市场去落地赚钱。这件事在2023到2024年主要靠“算力叙事”撑着谁的GPU多、谁的价格低谁就有话语权。但到了2025年单纯拼算力的边际收益已经肉眼可见地在下降。原因很简单算力正在变成一种相对标准化的商品而真正拉开差距的是你能不能把算力、模型、场景和本地生态串成一条能跑通的链路。这篇内容适合三类人看。第一类是正在或准备做AI出海的技术负责人你需要知道现在的竞争焦点已经从“有没有卡”变成了“能不能协同”第二类是做大模型部署和Agent开发的工程师你会关心具体怎么选型、怎么调优、怎么把成本压下来第三类是对这个赛道感兴趣的产品和商业同学你想搞明白这波出海到底靠什么赚钱、坑在哪里。我会尽量把技术细节讲透同时把商业逻辑也掰开揉碎因为AI出海这件事纯技术视角和纯商业视角都会看偏。先给一个我自己的判断2025到2026年中国AI出海的核心命题不是“算力反超”而是“生态协同”。算力是入场券不是护城河。真正能让你在海外站稳的是你能不能把模型能力、Agent框架、本地化数据和合规运营捏成一个整体。下面我分几个层面把这件事拆开讲。2. 算力这层窗户纸反超的真相与它的天花板2.1 算力指标到底该怎么看别被TOPS忽悠了聊算力之前得先把指标这件事说清楚。我见过太多人在选卡的时候只盯着一个TOPS数字结果买回来发现跑自己的模型根本不是那么回事。算力指标有好几个维度混着看很容易踩坑。先说明白几个常见指标的区别。TOPSTera Operations Per Second衡量的是整数运算能力通常用于推理场景的粗略对比TFLOPSTera Floating-point Operations Per Second衡量浮点运算训练场景更看重这个而FP8、FP16、INT8这些精度标识直接决定了同一张卡在不同精度下的有效算力差异巨大。举个例子一张卡标称FP16算力是100 TFLOPS切到FP8可能翻倍到200 TFLOPS但如果你用的是INT4量化实际吞吐又是另一回事。我拿一个实际场景说明。假设你要部署一个70B参数的大模型做推理用FP16精度模型权重就要占大约140GB显存。如果单卡显存不够就得考虑张量并行或者量化。这时候你算有效算力不能只看卡的峰值TFLOPS还要看显存带宽、卡间互联带宽比如NVLink的速率、以及你的推理框架对并行的支持程度。我实测下来同样两张卡互联带宽差一倍推理吞吐能差出40%以上这个差距比单纯算力数字的差距更致命。提示选算力的时候先明确你的主场景是训练还是推理是FP16还是FP8/INT8然后再去对比有效算力。峰值TOPS只是营销数字别当决策依据。2.2 国产算力反超的叙事哪些是真的哪些是水分这两年“算力反超”的说法很热我得客观说几句。在某些特定维度上国内确实做到了领先比如特定精度下的推理吞吐、某些定制化芯片的能效比、以及大规模集群的调度效率。但“反超”这个词本身容易让人误解好像是一个全面的、线性的超越实际上不是。真实情况是在推理侧尤其是针对国产大模型做深度优化的推理芯片性价比确实有竞争力部分场景下单位算力的成本比进口方案低不少。但在训练侧尤其是超大规模预训练需要的互联带宽和软件生态成熟度上差距依然存在。而且算力反超这件事很大程度上依赖的是“软硬协同优化”——也就是你的推理框架、算子库、量化方案跟特定硬件深度绑定后跑出来的成绩。换个模型、换个框架优势可能就没了。我踩过的一个坑是早期迷信某个“算力反超”的宣传把一套基于特定芯片优化的推理方案直接搬到另一个模型上结果性能直接腰斩。后来才明白那些漂亮的benchmark都是在特定条件下调出来的通用性没那么强。所以我的经验是看算力反超的宣传一定要问清楚在什么模型上、什么精度下、什么batch size、什么并发条件下测的。脱离这些前提谈反超都是耍流氓。2.3 算力怎么变成钱三种出海变现路径的实操对比算力本身不赚钱算力变成服务才赚钱。出海场景下我观察到三条比较清晰的变现路径各有各的门道。第一条是算力租赁也就是把GPU集群按小时或按卡时租给海外客户。这条路门槛相对低但利润薄而且竞争激烈。关键不在于你有多少卡而在于你的调度效率和稳定性。我见过一个团队卡不多但自研了一套细粒度的调度系统能把碎片化的算力拼起来卖利用率做到85%以上反而比那些卡多但利用率只有50%的团队赚得多。第二条是模型推理服务也就是MaaSModel as a Service。客户不关心你用什么卡只关心调你的API能不能稳定、便宜、低延迟地出结果。这条路的核心是推理优化和成本控制。用vLLM这类框架做PagedAttention和连续批处理能把吞吐拉高好几倍。我实测过同样的硬件用vLLM对比朴素推理吞吐能差3到5倍这个差距直接决定了你的毛利。第三条是Agent应用层也就是基于大模型能力做具体的业务Agent比如客服、编程助手、数据分析助手。这条路天花板最高但难度也最大因为你要懂海外客户的业务流还要处理本地化数据和合规问题。但一旦跑通客户粘性极强因为Agent是嵌进业务流程里的替换成本很高。变现路径核心能力毛利水平主要风险算力租赁调度效率、稳定性低价格战、利用率波动模型推理服务推理优化、成本控制中模型迭代快、客户迁移Agent应用业务理解、本地化高合规、交付周期长3. 大模型与Agent出海的技术底座怎么搭3.1 大模型选型不是越大越好而是越合适越好出海做大模型第一个决策就是选什么模型。我的观点很明确不是越大越好而是越合适越好。什么叫合适三个维度——能力够用、成本可控、合规可过。能力够用指的是在你的目标场景上模型的表现在可接受范围内。比如你做的是东南亚市场的客服Agent那模型对印尼语、泰语、越南语的支持就比它在MMLU上多考几分重要得多。我见过团队花大价钱部署了一个榜单排名很高的模型结果在目标市场的小语种上表现拉胯最后不得不换模型重来。成本可控指的是推理成本和微调成本都在预算内。一个70B的模型即使做了INT4量化推理成本也比7B模型高一个数量级。如果你的场景不需要那么强的推理能力用7B甚至更小的模型配合好的提示词工程和RAG效果可能差不多但成本差好几倍。合规可过指的是模型的来源、训练数据的合规性、以及输出内容的安全性要符合目标市场的要求。这一点在出海场景下极其重要不同市场对数据隐私、内容审核的要求差异很大。选模型的时候一定要把合规成本算进去别等落地了才发现过不了审。注意模型选型不要只看benchmark一定要在你的真实业务数据上做A/B测试。榜单上的分数和实际业务表现之间往往隔着一条鸿沟。3.2 本地部署还是API调用一笔算清楚的经济账这是每个出海团队都会纠结的问题大模型到底是本地部署还是直接调API我的答案是——看规模看场景看长期规划。先算一笔账。假设你要服务一个中等规模的海外客户日均请求量100万次平均每次请求输入500 token、输出200 token。如果调API按目前主流的价格大概每百万token几美元到十几美元不等一天的成本可能在几百到上千美元。如果本地部署你需要至少2到4张高端卡硬件成本一次性投入几万到十几万美元加上电费、运维、人力分摊到每天可能也是几百美元。看起来差不多但有几个关键变量。第一规模效应。请求量越大本地部署的边际成本越低因为硬件是固定投入。当你的日均请求量超过某个阈值我经验里大概是几百万次以上本地部署的经济性就明显优于API。第二数据敏感性。如果客户的数据不能出境或者对数据隐私要求极高那本地部署几乎是唯一选择。这时候成本不是首要考虑合规才是。第三迭代速度。API的好处是模型更新快你不用自己维护。本地部署的话每次模型升级你都要重新部署、重新调优这个人力成本不能忽略。我自己的做法是前期用API快速验证场景跑通业务流当请求量稳定且规模上来后逐步把核心场景迁移到本地部署。这样既控制了前期风险又能在规模起来后把成本压下去。用Ollama做本地部署的快速验证是个不错的起点它把模型下载、量化、推理都封装好了几行命令就能跑起来。但生产环境我建议用vLLM因为它的吞吐和并发能力更适合线上服务。3.3 Agent框架怎么选从LangChain到自研的取舍Agent是2025年出海最热的方向但Agent框架的选择让很多人头疼。市面上框架很多LangChain、AutoGPT、以及各种国内外的开源方案到底怎么选我的经验是不要一上来就上重框架。LangChain功能全但抽象层多调试起来很痛苦而且版本迭代快经常升级就breaking change。我早期用LangChain做一个简单的客服Agent光是把它的各种chain和memory机制搞清楚就花了一周后来发现其实核心逻辑用几百行代码就能写清楚。我的建议是分阶段来。验证阶段用最轻量的方式直接调模型API自己写prompt和工具调用逻辑把业务流跑通。这个阶段重点是验证场景不是搭架构。生产阶段如果业务逻辑复杂、需要多Agent协作、需要复杂的记忆和规划能力再考虑引入框架或者自研一套适合自己业务的轻量框架。这里要区分几个概念很多人搞混。Agent是一个能自主决策、调用工具、完成任务的智能体Skill是Agent可以调用的一个具体能力比如查天气、发邮件Harness是包裹在Agent外面的执行环境负责管理Agent的生命周期、错误处理、资源限制。搞清这三个的区别你在设计系统的时候就不会把职责混在一起。我见过把工具调用逻辑写死在Agent主循环里的代码后来想加个新工具就要改核心逻辑维护成本极高。3.4 Agent Evals出海场景下怎么衡量Agent到底行不行Agent做出来了怎么知道它好不好这就涉及Agent Evals评估。出海场景下评估比国内更复杂因为你要面对多语言、多文化、多合规要求。我的评估框架分三层。第一层是功能正确性Agent能不能正确理解意图、调用正确的工具、给出正确的答案。这一层可以用标注好的测试集来跑看准确率和召回率。第二层是鲁棒性面对模糊输入、恶意输入、边界情况Agent会不会崩溃或者给出危险输出。这一层要专门构造对抗样本。第三层是业务指标比如客服Agent的解决率、编程Agent的代码通过率、数据分析Agent的洞察质量。这一层最接近真实价值但也最难量化。我踩过的一个坑是早期只关注功能正确性测试集上准确率95%上线后客户投诉不断。后来发现是鲁棒性没做好用户换个说法Agent就懵了。所以评估一定要三层都覆盖尤其是出海场景语言和文化的差异会让鲁棒性问题放大。4. 生态协同出海真正的护城河在哪里4.1 算力、数据、模型、场景四要素怎么串成闭环前面讲了算力、模型、Agent但这些单独拿出来都不构成护城河。真正的护城河是生态协同——把算力、数据、模型、场景四个要素串成一个能自我强化的闭环。这个闭环怎么转我拿一个具体的出海场景说明。假设你做的是面向东南亚电商的客服Agent。算力层你在当地或者靠近当地的数据中心部署推理集群保证低延迟。数据层你积累当地语言的客服对话数据这些数据是别人拿不到的。模型层你用这些数据对基础模型做微调让它在当地语言和业务场景上表现更好。场景层你把微调后的模型封装成Agent嵌进电商的客服流程解决实际问题。然后Agent在真实场景中产生的数据又回流到数据层继续优化模型。这个飞轮转起来后来者就很难追。这个闭环的关键在于数据回流。很多团队做完部署就结束了没有建立数据回流的机制导致模型永远停留在初始状态无法适应业务变化。我建议从第一天就把数据采集和回流的设计做进去哪怕前期数据量小也要把管道搭好。4.2 本地化不是翻译文化、合规、支付的三重门出海最容易低估的就是本地化。很多人以为本地化就是把界面翻译成当地语言这是大错特错。真正的本地化要过三重门文化、合规、支付。文化这重门指的是你的Agent要理解当地的文化习惯、表达方式、甚至幽默感。比如同样一句客服回复在有些市场要正式礼貌在另一些市场可以轻松随意。这个不是翻译能解决的需要当地的数据和人工反馈来调。合规这重门指的是数据隐私、内容审核、AI伦理等方面的要求。不同市场差异巨大有的要求数据本地存储有的要求AI生成内容必须标注有的对特定内容有严格限制。这些合规要求会直接影响你的技术架构比如数据存储位置、内容过滤模块的设计。支付这重门指的是当地的支付习惯和结算方式。这个看似跟技术无关但直接影响你的商业化。我见过技术做得很好的团队因为没搞定当地支付通道收入迟迟起不来。提示本地化一定要找当地的人参与不管是产品、运营还是数据标注。纯靠国内团队远程想象一定会踩坑。4.3 从单点工具到平台生态出海产品的演进路径出海产品一般会经历三个阶段单点工具、解决方案、平台生态。单点工具阶段你提供一个具体的能力比如一个翻译Agent、一个编程助手。这个阶段门槛低竞争激烈但适合快速验证和获客。解决方案阶段你把多个能力打包成针对特定行业的解决方案比如面向跨境电商的整套AI客服方案。这个阶段客户粘性开始建立因为替换成本变高了。平台生态阶段你开放自己的能力让第三方开发者基于你的平台构建应用。这个阶段天花板最高但难度也最大需要强大的技术底座和生态运营能力。我的建议是不要跳过任何一个阶段。我见过团队一上来就想做平台结果基础能力都没打磨好平台成了空中楼阁。踏踏实实从单点工具做起跑通一个场景再横向扩展最后才是平台化。4.4 团队配置出海AI团队需要什么样的人最后聊聊团队。出海AI团队的配置跟国内团队很不一样有几个角色特别关键。本地化产品经理必须懂当地市场能判断什么功能是刚需、什么合规红线不能碰。多语言数据工程师负责数据的采集、清洗、标注尤其是小语种数据这个人才很稀缺。推理优化工程师负责把模型在目标硬件上跑到最优直接决定成本。合规专家这个角色很多团队早期不重视等出了问题才补代价很大。我的经验是早期团队可以精简但这几个能力必须有人覆盖哪怕是兼职或者外部合作。尤其是合规千万别省这个钱。5. 实操避坑那些文档里不会写的经验5.1 部署踩坑实录从Ollama到vLLM的迁移我拿一个真实的迁移案例来说。早期我们用Ollama做本地验证很方便一条命令拉模型自动量化开箱即用。但到了生产环境问题就来了。Ollama的并发能力有限请求一多就排队延迟飙升。而且它的批处理策略比较保守吞吐上不去。迁移到vLLM的过程也不是一帆风顺。vLLM的PagedAttention对显存管理很高效但配置参数需要调。比如gpu_memory_utilization这个参数设太高会OOM设太低浪费显存。我实测下来0.9左右是个比较稳的值但具体要看你的模型大小和卡的数量。还有max_num_seqs控制同时处理的序列数设太小吞吐上不去设太大显存不够。这些参数没有万能值要在你的实际负载下压测调优。迁移后同样的硬件吞吐提升了大概4倍延迟降低了60%。这个收益是实打实的但前提是你愿意花时间调参和压测。5.2 成本失控的五个常见原因AI出海最容易失控的就是成本。我总结了五个常见原因都是血泪教训。第一算力利用率低。卡买了但跑不满钱在烧但产出少。解决方法是上调度系统把碎片算力拼起来用。第二推理没有优化。用朴素推理跑大模型成本是优化后的好几倍。vLLM、TensorRT-LLM这些工具该上就上。第三模型选型过大。用70B模型干7B就能干的活成本差一个数量级。先想清楚场景需要多强的能力。第四数据存储和传输成本被忽略。出海场景下跨境数据传输和存储的成本不低尤其是数据量大的时候。架构设计时就要考虑数据放在哪里。第五合规成本低估。合规不是一次性的是持续的。内容审核、数据审计、认证维护都是持续投入。5.3 常见问题速查表问题现象可能原因排查方向解决建议推理延迟突然飙升并发过高、显存不足看GPU利用率和显存占用调max_num_seqs加卡或量化Agent输出不稳定提示词不鲁棒、温度过高检查prompt和temperature降低温度加few-shot示例小语种效果差训练数据不足看目标语言的测试集表现补充本地数据微调成本超预算利用率低、模型过大算单位请求成本优化推理换小模型合规审核不通过数据存储位置、内容过滤对照当地要求逐条检查调整架构加过滤模块5.4 我个人的几条硬核心得最后分享几条我自己的心得都是踩坑踩出来的。第一别迷信榜单信你的业务数据。榜单是别人的场景你的场景只有你自己知道。第二算力是手段不是目的。别为了堆算力而堆算力算力要服务于场景。第三本地化要趁早。别等产品做完了才想本地化那时候改造成本极高。第四合规是底线不是成本。把合规当成产品的一部分来设计而不是事后补丁。第五生态协同是长期活。别指望一两个月就建成生态这是个持续投入的过程但一旦转起来护城河就很深。这个赛道变化很快我上面说的很多东西可能过几个月就要更新。但底层逻辑是不变的算力是入场券模型是工具场景是战场生态是护城河。谁能把这四样串起来谁就能在出海这盘棋里走得更远。