创业公司做到一定阶段模型训练基本不是瓶颈了真正让人头疼的是“推理上线”这件事。字面意思谁都会说——把模型放到云端对外提供服务。但当你真正开始面对用户请求的时候“推理延迟”和“吞吐量”这两个词就像一对夫妻一样又爱又恨你调高了吞吐延迟立刻难看你死磕延迟账单立刻难看。很多AI创业团队前期把精力全砸在模型效果上到了部署环节才发现选型平台这件事做得好不好直接决定产品能不能规模化盈利。这篇文章就围绕“AI创业公司如何选择云端推理平台”这个主题用我做过不少推理服务上线的经验把延迟和吞吐这两个指标拆开揉碎讲讲为什么它们互相矛盾选平台时到底要看哪些硬指标现在市面上哪几类平台值得放进备选清单以及从选型到上线压测的实操路径是怎样的。不管你是刚起步正在调研的技术负责人还是已经被线上延迟搞到头大的算法工程师这篇都适合你慢慢看。1. 先搞清楚推理延迟和吞吐量到底在优化什么1.1 一组容易被混为一谈的概念很多刚接触推理服务的同学一开口就是“我要低延迟高吞吐”但真问起来延迟到底指什么、吞吐到底按什么算往往说不清。这事必须先掰扯明白不然选平台就是瞎选。推理延迟Latency最常用的统计口径有三类首Token延迟TTFTTime To First Token、单个Token生成之间的间隔TPOTTime Per Output Token、以及端到端完成一个完整请求的总耗时。对于聊天、搜索、Agent这种流式交互场景用户体感最强烈的其实是TTFT——你敲完问题页面上一片空白等了好久才冒出第一个字这种体验足以劝退用户。而对于离线批量处理场景比如批量生成摘要、批量打标签用户根本不在乎第一个Token多久出来在乎的是一批任务跑完总共耗时多久。吞吐量Throughput的统计口径也分两种一是每秒能处理的请求数Requests Per Second二是每秒能生成的Token数Tokens Per Second。这两个指标看着相似实际含义差别很大。比如一个短问答场景每次请求输出只有几十个Token那RPS更能反映承载能力但如果做长文生成每次输出上千Token那TPS才是决定你成本效率的核心指标。我见过不止一个团队拿RPS去压测一个长文本生成服务结果平台显示RPS很高就以为没问题实际上用户的平均等待时间已经超过了他们的SLA。这就是指标选错了的典型后果。1.2 为什么延迟和吞吐量常常打架这个矛盾要从大模型推理的底层机制说起。Transformer模型做生成本质是自回归式的每生成一个Token都要跑一遍完整的前向计算。这意味着生成的Token数量越多计算量就越大而且单个Token的生成强依赖前一个Token的结果没法像传统并行计算那样轻松拆开。为了提高吞吐量主流做法是“批处理”Batching——把多个用户的请求打包成一个Batch在GPU上一起算。这就像一辆公交车本来一辆车只拉一个人现在塞满一车人单个人的运输成本降下来了整批的运输效率上去了这就是吞吐量提升的来源。但代价是什么Batch越大这个Batch里的每个请求都要等整批计算完成才返回。极端情况下某个请求本来单独算只要1秒塞进一个很大的Batch后可能要等4到5秒才能拿到结果因为GPU的显存被占满了计算资源被一起耗着谁也别想先走。这就是“吞吐量上去了延迟恶化了”的经典场景。更麻烦的是现在主流推理框架都在用Continuous Batching连续批处理技术。它把批处理从“等一批全部结束再处理下一批”改成“动态插入新请求谁生成完了谁就走”极大提升了吞吐但也让单个请求的延迟波动变得更随机。所以你在平台上看到的P95延迟往往和P50相差很大这个波动性就是我们要评估和接受的部分。1.3 创业公司怎么定自己的指标优先级没有绝对正确的指标只有适合你业务形态的指标。这里分享一个我做选型时常用的判断框架如果你的产品是用户直接对着对话框打字聊天或者Agent需要反复调用模型做推理那延迟优先尤其是P95的TTFT和TPOT必须卡死。这类业务用户心智就是“即时反馈”模型思考超过3秒用户就开始不耐烦超过5秒就可能关页面。我在实际优化中通常给聊天类服务的P95端到端延迟设成不超过4秒TTFT不超过1秒。如果你的产品是To B的批量生成服务比如内容批量改写、数据分析报告生成、批量文档解析那吞吐优先。这类业务用户不坐在屏幕前干等你只要保证任务在指定时间内跑完就行。比如一份分析报告500个任务要求3小时内跑完那你的核心指标就是“总耗时”对应的就是吞吐量。如果你的产品是一半交互一半批量比如一个AI内容平台用户在线编辑时调用模型后台定时任务也要调用模型那就不能只看单一指标而是要做“流量分池”——在线交互流量走低延迟通道后台批量流量走高吞吐通道。这个后面实操部分我会详细讲平台选型时也要优先考虑能支持这种流量隔离方案的平台。2. 云端推理平台选型五大核心评估维度2.1 算力与GPU型号不是只有A100和H100很多人一聊推理就觉得非A100/H100不可这是被训练思维带偏了。推理和训练的算力画像差别很大推理更看重显存带宽和显存容量而不是纯粹的FP16算力。举个例子做轻量级对话模型比如7B或13B级别的模型用L4甚至A10这一类中端卡性价比往往比A100高得多。因为7B模型在FP16下大概需要14GB显存A10的24GB显存放得下而且A10的功耗低、单卡成本低在低并发场景下完全能Hold住。但如果做70B级别的模型服务那就不能单看卡了还得看平台支不支持张量并行Tensor Parallelism能不能把模型拆分到多张卡上多卡之间的互联带宽够不够。另一个容易忽略的点是显存类型。H100的HBM3显存和A100的HBM2e差距巨大直接反映在Token生成速度上。同样是70B模型H100的推理吞吐可能是A100的2到3倍。所以在平台对比时别只看“几张卡”要看具体卡型和显存带宽这会直接影响你每Token的成本。还有一点经验选平台时一定要问清楚GPU是否物理隔离。有些云平台为了把资源卖得更满会在同一张物理GPU上做虚拟化切分如MIG或类似技术多个租户共享一块卡。这种模式下你看到的“一张卡”实际算力可能被其他租户抢走了延迟波动非常明显。创业公司如果对延迟敏感优先选物理独占GPU的方案宁可单价贵一点也不要赌邻居不闹腾。2.2 冷启动与弹性伸缩第一个请求要等多久云端推理平台有一个特别磨人的指标叫“冷启动时间”。什么意思你部署好模型一段时间没有流量平台为了省成本把实例缩到0这时候突然来一个用户请求平台需要拉起一个实例、把模型权重加载进显存这个过程可能需要几十秒甚至几分钟。对于C端产品来说这个等待是完全不可接受的。所以选平台时你要问清楚三件事一是平台支不支持“保持最小实例数”。如果你想追求极致的成本效率希望流量低时缩到1个实例而不是0平台允不允许你自己设定这个下限。二是实例从启动到真正能接流量的时间有多长。不同框架加载模型的速度差别很大比如TensorRT-LLM的引擎加载通常比纯PyTorch快有的平台还做了模型预热warm-up启动后自动跑几个空请求让CUDA初始化完毕这些细节直接决定扩容速度。三是有没有“预置并发池”或者说“弹性池”。部分专业推理平台会提前在后台备好一些“热实例”用户请求暴增时能秒级接入而不是现拉虚拟机。这种机制对突刺流量特别有用但要额外付费属于用钱换体验的典型。我自己的建议是创业公司早期没必要追求极致的冷启动体验先接受5到15秒的冷启动时间但一定要在平台控制台里人工保有一个最小实例比如1个避免冷启动时间变成几分钟。2.3 推理框架与优化技术平台帮你做了多少事同一张GPU跑同一个模型不同推理框架的吞吐差距可能高达2倍以上。这个差距主要来自三项核心技术第一是Batch策略。最早的框架是静态Batch等一批请求凑齐了再一起算空闲时间浪费严重。现在主流框架如vLLM、TensorRT-LLM、SGLang都支持Continuous Batching能把GPU的空闲计算间隙填满吞吐提升非常明显。第二是KV Cache管理。长上下文对话会产生巨大的KV Cache如果管理不当显存会迅速耗尽平台不得不频繁做“显存整理”拖慢所有请求。vLLM的PagedAttention技术就是把KV Cache切成小块动态分配这一项设计让显存利用率大幅提升直接反映在吞吐量上。第三是量化与精度优化。同样的模型从FP16降到INT8显存占用减半吞吐提升接近一倍代价是效果有轻微损失。优秀的平台会内置量化方案比如FP8、INT8、INT4甚至提供AWQ、GPTQ这类感知量化算法让你能自由权衡效果和速度。所以在平台选型时不要只看它“支持部署模型”而是要问内置了哪些推理引擎支不支持vLLM或者TensorRT-LLM这些引擎的版本更新频率如何能不能自定义部署脚本有些平台为了稳定提供的推理引擎版本很老连PagedAttention都没有那你买再好的GPU也白搭。2.4 网络与地域延迟不只是GPU的事模型推理只是链路的一环用户的请求要经过DNS解析、负载均衡、API网关、推理服务最后再原路返回。地域选得不合适网络时延可能比推理本身还高。我踩过一个坑服务部署在美东用户主要在亚洲结果一个简单的对话请求光是网络往返就要400毫秒加上模型推理1秒整体TTFT接近1.5秒。后来把服务迁到亚洲区域网络往返降到80毫秒TTFT一下子回到800毫秒以内用户体感天差地别。所以选平台第一件事就是看机房节点覆盖区域。你的目标用户在哪服务优先部署在哪。如果目标用户是全球性的那就要考虑多区域部署同时还要评估平台是否提供跨区域的API网关和全球负载均衡能力。另外还有一个细节云平台内部网络和外部网络是两套逻辑。模型实例之间的通信走内网没问题但如果你在推理服务前面接了自己的API网关而这个网关部署在另一个云厂商那中间就要走公网延迟会明显增加。创业公司如果有多云部署需求最好把推理服务、网关、应用服务放在同一个云厂商生态内能省不少事。2.5 计费模式按秒计费还是按实例计费推理平台的计费模式大概分三类每一类背后对应完全不同的成本结构和优化策略。按实例计费按小时或按秒是传统云厂商的模式。你租一台GPU实例不管实例上跑不跑流量费用都照收。这种模式适合流量稳定、能预测的业务你可以在低谷期缩实例高峰期扩实例但需要自己做运维调度。优点是单价便宜缺点是弹性能力靠你自己。按Token计费是很多专业推理平台的模式。你按实际生成和输入的Token数付费平台自动帮你管理GPU资源和扩缩容。这种模式对创业团队极其友好尤其业务初期流量不确定时流量为零就费用为零完全不用操心闲置资源。缺点是单价通常比自建实例贵不少流量大到一定程度后你可能会肉疼。混合模式则介于两者之间。有的平台提供“无服务器推理”服务冷启动快按调用计费也有预留实例的选项你提前买一定时长的实例Term价格可以大幅优惠。我的建议是创业公司初期用按Token计费的方案跑通业务等流量曲线稳定了再切换到预留实例通常能把推理成本压下来30%到50%。3. 主流云端推理平台横向对比与推荐3.1 综合云平台适合已有云上业务的团队这类平台以AWS SageMaker、Azure Machine Learning、GCP Vertex AI、阿里云PAI为代表。它们最核心的优势是生态全面如果你公司整个后端就搭在某个云厂商上用它的推理服务能省去很多跨云调用的麻烦内网调用延迟更低数据隐私合规也更简单。以AWS为例SageMaker Inference支持实时端点Real-time Inference、无服务器推理Serverless Inference和异步推理Asynchronous Inference三种模式。实时端点适合延迟敏感的场景可以选多个实例做负载均衡无服务器推理按调用量付费秒级冷启动适合初期流量不确定的产品异步推理则适合离线批量任务。这个分类思路其实值得很多平台学习因为它是在帮用户按业务场景做选择而不是让你买一堆GPU自己折腾。GCP Vertex AI这边一个比较突出的特点是和Google的TPU生态整合紧密。如果你用的是Gemma这类Google系开源模型或者模型架构对TPU友好Vertex AI的性价比会很突出。顺便说一句Vertex AI的预测端点对自定义容器支持得不错你可以把整个vLLM服务硬塞进去灵活性较高。阿里云PAI在国内团队里口碑不错尤其如果你部署的是中文大模型阿里云生态内的通义系列模型有深度优化而且国内访问网络的稳定性好数据传输合规风险也小。国内团队如果目标市场就在境内用阿里云PAI或者同类国内综合云平台省心程度远超海外云。综合云平台最大的问题是“重”——控制台功能太多配置项复杂学习成本高。而且很多功能偏向企业级客户对创业公司灵活的部署方式支持不够。比如你想在SageMaker上跑一个自定义的vLLM容器虽然能实现但文档要翻半天远没有专业平台开箱即用。3.2 专业AI推理平台为LLM推理而生的新势力如果说综合云平台是“全能选手”那Together AI、Fireworks AI、Modal、Replicate、Baseten这些专业平台就是“单项冠军”。它们从第一天起就是为生成式AI推理设计的所以在推理延迟和吞吐量的优化上执行力普遍比传统云厂商更激进。Together AI和Fireworks AI的共同特点是自研了高性能推理引擎并且深度优化了主流开源模型。它们通常会在第一时间发布针对Llama、Mistral、Qwen等模型的中英文优化版配合专有集群吞吐表现非常亮眼。我记得有一次在两个平台上跑同一个70B模型单并发延迟相差不大但压到高并发时专业平台的TPS差不多是综合云平台默认配置的2倍这背后就是框架优化和调度策略的差距。Modal走的是“开发者体验”路线特点是用Python代码定义整个推理服务部署流程类似写脚本对工程师极其友好。它的自动扩缩容粒度很细冷启动可以做得很低零流量时缩到0流量来了能秒级拉起。缺点是控制能力相对受限如果你需要非常细粒度地调GPU参数、网络配置可能觉得不够自由。Baseten则偏向To B服务它有一个“稳定、可观测”的产品定位提供了比较完善的监控看板、告警体系和版本回滚机制。如果你要对外承诺SLABaseten这种平台会让你省心很多因为它的管理端各种指标都很透明出了问题能定位。这类专业平台的短板也很明显一是部分地区的数据合规问题比如用户数据需要留在境内那海外专业平台基本没法用二是长期成本偏高按Token计费在并发量上来后会变得很贵三是服务稳定性依赖单一公司一旦平台出故障或者业务调整你很难立刻迁移。3.3 国内平台与模型服务商在合规与性价比之间找平衡国内这几年也涌现了不少优秀的推理平台和服务商。除了阿里云PAI硅基流动SiliconFlow是很多开发者的心头好它提供低价的模型API服务同时也有云GPU部署方案尤其对开源社区的模型支持速度特别快很多新模型发布后一周内就能在上面找到部署好的服务。对于创业公司初期验证idea来说硅基流动的体验非常顺滑注册账号、选模型、拿Key、调用十分钟就能跑通。潞晨Cloud这类平台的特色在于“性价比”经常能看到它们针对特定模型推出极具竞争力的Token价格。如果你做的是对成本极其敏感的B端批量业务可以多关注这类平台的活动价格。但要注意低价背后有时是资源的冗余程度下降延迟和服务稳定性的表现需要自己真实压测验证不能只看宣传。还有一类平台是BigModel智谱AI开放平台、百炼阿里云这类模型厂商自有的API服务。它们直接提供自家模型的推理API质量和延迟最有保障因为模型是自己训的推理优化最到位。缺点是只能用它家的模型灵活性差一些如果你要部署第三方开源模型这类平台就不适用了。选择国内平台时我强烈建议在正式决策前来一轮实际压测不要只看官网参数。国内平台同型号GPU的“实际算力”很多情况下是打折的因为可能开了超卖或者共享资源池。你在压测时重点看P95延迟的稳定性而不是平均延迟。平均延迟好看没意义线上用户碰到的是最差的那一部分请求。3.4 平台对比速查表下面这张表是我在给团队做选型时常用来对标的一张速查表未必覆盖所有平台但核心维度和对比思路可以复用。平台类型代表平台核心优势核心短板适合场景计费特点综合云平台AWS SageMaker、Azure ML、GCP Vertex AI、阿里云PAI生态完善、与云上业务整合方便、内网调用低延迟配置复杂、推理框架更新相对保守已有云上业务的团队需要多服务协同按实例计时或按调用量计费灵活度高专业AI推理平台Together AI、Fireworks AI、Modal、Baseten推理优化激进、吞吐高、开箱即用、开发者体验好长期成本偏高、数据合规需评估、平台依赖性强创业初期快速上线或追求极致推理吞吐按Token计费为主部分支持预留实例国内模型API/GPU平台硅基流动、潞晨Cloud、百炼国内访问快、合规省心、模型上新快、API极简部分平台稳定性和资源隔离需压测验证目标用户在国内、创业初期验证场景按Token计费部分提供GPU实例租赁自有GPU云主机各大云厂商的GPU云服务器完全自主可控、成本上限可预测运维工作量大、优化和扩缩容全靠自己流量稳定、有专有运维能力的团队按实例计时需自行管理扩缩容4. 创业公司实操从选型到落地的完整路径4.1 第一步量化自己的延迟和吞吐需求平台选型最忌讳“我都要”你必须在开始谈价格之前就把自己的需求量化成一张表。这里的核心是明确三个数目标延迟、峰值吞吐、可接受的最坏延迟。以一个AI客服对话产品为例。假设用户发送一条消息后我们希望模型在1秒内开始输出首个Token即TTFT的P95不超过1000毫秒。同时单个回答的平均生成Token数大约是200那么单次请求端到端的P95延迟目标可以设为8秒用户能接受看到“正在输入”的等待。峰值吞吐方面根据现有用户量预估促销期的峰值请求数是每秒50个请求。有了这三个数你就有了计算的基础。以每秒50请求、每请求200个输出Token来算峰值输出Token速率就是每秒10000个Token。不同GPU和推理框架的实际吞吐能力差异很大但可以参考一个经验值一张配置合理的L4或A10级别GPU跑7B模型做到每秒800到1500个输出Token是正常的。按这个估算你大约需要6到13张中端GPU实例来应对峰值。这个计算不一定精确但能让你在跟平台销售谈话时心里有底知道对方报价的方案到底是性能充足还是够用而已。更重要的是这个量化过程能帮你判断某些平台宣传的“高性能实例”到底有没有必要买——如果峰值吞吐本来就不高买A100就是用十倍成本办十分之一的事。4.2 第二步设计一套标准化压测方案选平台只看文档参数肯定不行必须上真实流量压测。我建议团队内部搞一套标准压测脚本在所有候选平台上跑同样的压测才能公平对比。这里分享一段我之前用的压测脚本雏形基于Python的asyncio和httpx构造并发请求统计TTFT、总延迟和吞吐。代码很简化核心思路是“并发固定数量的请求记录每个请求的首响应时间和完整响应时间”。import asyncio import httpx import time import statistics CONCURRENCY 20 # 并发请求数 TOTAL_REQUESTS 200 # 总请求数 API_ENDPOINT https://your-endpoint/v1/chat/completions API_KEY your-api-key async def send_one(client, prompt, idx, results): payload { model: your-model, messages: [{role: user, content: prompt}], stream: False, max_tokens: 200, } headers {Authorization: fBearer {API_KEY}} start time.perf_counter() first_token_at None output_tokens 0 async with client.stream(POST, API_ENDPOINT, jsonpayload, headersheaders) as resp: async for line in resp.aiter_lines(): if not line.startswith(data:): continue data line[5:].strip() if data [DONE]: break # 这里根据返回结构做解析粗略统计 if first_token_at is None: first_token_at time.perf_counter() output_tokens 1 end time.perf_counter() results[idx] { ttft: (first_token_at - start) if first_token_at else None, total: end - start, output_tokens: output_tokens, } async def main(): prompts [请写一篇关于云端推理平台选型的短文200字左右。] * TOTAL_REQUESTS results [None] * TOTAL_REQUESTS async with httpx.AsyncClient(timeout60) as client: sem asyncio.Semaphore(CONCURRENCY) async def wrapped(idx): async with sem: await send_one(client, prompts[idx], idx, results) await asyncio.gather(*[wrapped(i) for i in range(TOTAL_REQUESTS)]) valid [r for r in results if r] ttfts [r[ttft] for r in valid if r[ttft]] totals [r[total] for r in valid] total_tokens sum(r[output_tokens] for r in valid) elapsed max(totals) - min(ttfts) print(f请求成功率: {len(valid)/TOTAL_REQUESTS:.2%}) print(fTTFT P50: {statistics.median(ttfts)*1000:.1f}ms, P95: {sorted(ttfts)[int(len(ttfts)*0.95)]*1000:.1f}ms) print(f端到端延迟 P50: {statistics.median(totals)*1000:.1f}ms, P95: {sorted(totals)[int(len(totals)*0.95)]*1000:.1f}ms) print(f吞吐量: {total_tokens/elapsed:.1f} tokens/s) if __name__ __main__: asyncio.run(main())压测时有一个容易被忽略的点不要只测一个并发值。建议至少测三组比如并发5、20、50分别对应日常、峰值、极端情况。这样你能看到平台在低负载和高负载下的延迟曲线如果某个平台在并发从20涨到50时P95延迟突然翻了5倍以上那说明它的调度能力有明显瓶颈后续业务增长会很危险。另外压测至少持续10分钟以上不要只压1分钟。很多平台的弹性扩容机制在短时间压力下不会真正触发只有持续高负载才能暴露真实的调度能力。我一般会压15分钟记录前3分钟稳定期的数据和后12分钟扩容后的数据对比一下平台扩了多少实例延迟是否回升。4.3 第三步平台试用与验证清单不要觉得压测跑完就万事大吉选平台之前最好把下面这份清单逐项过一遍。每一条都来自我在实际选型中踩过的坑第一项CPU和内存是否和GPU匹配。有的便宜实例GPU看着够用但CPU核数少、内存小在高并发下CPU会成为瓶颈Token生成速度上不去。特别是你去跑vLLM这类框架CPU要承担调度和预处理CPU弱了整个流程卡脖子。第二项GPU的宿主系统是否和你的推理框架兼容。比如TensorRT-LLM对驱动版本、CUDA版本要求很严格平台镜像如果不满足你部署时会非常痛苦。建议在选型阶段就带着自己最常用的推理框架镜像去试部署别等签约之后才发现兼容性问题。第三项监控和日志是否完善。上线之后你一定会遇到延迟波动问题这时候如果平台连每个请求的耗时拆解都看不到排查就是大海捞针。至少要有Token生成速度、并发请求数、错误率这些指标的监控面板并且要能按时间维度回溯。第四项API限流策略。每个平台都有自己的限流阈值有的按RPS限有的按TPM每分钟Token数限。要搞清楚默认限流值是多少是否支持调高调高是否需要额外付费。创业公司最怕就是上线后流量稍微起来突然被平台限流用户侧看到的就是服务雪崩。第五项数据持久化和模型加载速度。如果你需要在平台上同时部署多个版本的模型平台是否支持多版本管理、回滚、A/B测试流量分配。这些功能在你后续迭代模型时会频繁使用平台不原生支持的话自己实现特别费劲。4.4 第四步上线后的容量规划与成本优化平台选完、模型部署上线不代表工作结束。真正的成本优化和容量规划是持续的过程我分享几个被验证有效的思路。第一个思路是“流量分池”。前面提到过交互流量的延迟敏感、批量流量的吞吐敏感这两者在同一套推理集群上很难同时满足。我推荐在前期就设计两套部署一套跑专业平台或者综合云的实时端点专门服务在线交互请求允许一定的实例闲置成本另一套跑Spot实例或者抢占式实例跑批量任务。Spot实例价格通常是按需实例的三到五折批量任务对中断不敏感先杀掉重跑就行成本能压得很低。第二个思路是“模型分级”。不要用一个最大的模型服务所有请求。简单的意图识别、关键词提取用7B小模型就够了复杂的推理、长文生成才调度70B大模型。配合一个路由层根据请求类型自动分配不同模型整体推理成本能下降一半而且平均延迟也会降低因为大部分请求走的是小模型快车道。第三个思路是“缓存复用”。对AI应用来说相似请求的响应结果其实可以缓存。比如同一个知识库问答用户连续几天问同样的问题就能命中缓存完全不用跑模型推理。这个优化效果听起来很朴素但实际应用中缓存命中率高得吓人尤其在To B场景里很多问题就是反复问的。把缓存层做好相当于直接给推理平台减负吞吐压力也小了。第四个思路是“持续压测和告警”。上线不是终点我习惯每周跑一次定时压测配合平台监控观察延迟和吞吐是否有劣化趋势。有时候平台底层出了问题比如宿主机被邻居影响指标不会马上崩坏但P95会慢慢上浮。定时的压测和告警能让你更早发现问题避免等到用户抱怨才被动处理。5. 常见问题与排查技巧实录5.1 延迟突然飙升平台却没有明显的资源瓶颈指标这是我在实际运维中遇到最多的一类问题监控面板上看CPU、GPU内存利用率都不高但用户反馈响应特别慢P95延迟从1秒飙到10秒。第一反应先检查是不是网络链路问题。推理服务本身没问题但入口网关到推理服务的公网连接不稳定或者DNS解析出现故障都可能导致整体延迟飙升。可以用traceroute或者直接curl测试一下不同链路的耗时排除网络因素。如果网络正常就要怀疑是不是“长尾请求”拖慢了整体延迟。大模型推理中某些请求因为输出的Token特别长或者输入的Prompt特别长会占据GPU显存和计算资源更久导致同一批的其他请求被排队等待。这时候查看平台监控里的“按Token长度拆分的延迟分布”如果长Token请求占比上升那就是业务流量结构变化导致延迟恶化需要限制单请求的输入输出长度上限或者为长Token请求单独开一条部署链路。还有一种经常被忽视的情况KV Cache碎片化。运行时间久了显存里残留了大量碎片新请求分配不到连续显存只能等待系统整理或者复用旧的Cache块这会导致延迟随机抖动。解决办法是定期重启实例或者升级推理框架版本新版本在显存碎片整理上通常有优化。5.2 吞吐量上不去GPU利用率却很低另一种典型情况是反向的平台配置看着很豪华GPU的利用率却只有20%吞吐量远低于预期。这时候一般不是平台不行而是你的请求特征和推理框架的Batch策略没匹配上。首先要看请求的输入输出长度比。如果大部分请求输入很短、输出也很短比如做分类任务、输入一句话输出一个标签那模型的计算量很小但请求调度开销占比很大GPU大量时间花在等待和切换上。这种情况适合把请求做“排队聚合”在应用层攒够一批再一起发给推理服务提高Batch的效率。其次要检查推理框架的参数配置。以vLLM为例max_num_batched_tokens和gpu_memory_utilization这两个参数直接影响吞吐。如果max_num_batched_tokens设得太小框架就不会拼大的BatchGPU算力自然闲置如果gpu_memory_utilization设得太低可用于KV Cache的显存不足也会限制并发Batch的规模。我一般会把gpu_memory_utilization设到0.85以上因为推理服务不像训练那样需要大量临时显存留15%的余量足够。再一个容易被忽略的是并行度配置。如果你部署70B模型用了多卡张量并行卡间通信量很大如果平台的内网带宽不足多卡并行不升反降。经验值是A100/H100这类卡采用NVLink互联的话8卡以内的并行度基本能线性扩展但如果平台给的卡分布在不同的物理机上通过网络互联扩展效果会大打折扣这时候就要慎重加大并行度。5.3 成本失控账单超出预期创业公司最现实的痛就是成本很多业务不是技术跑不通是成本算不过来账。我见过不止一个团队初期被专业平台的按Token计费吸引觉得没流量就没成本结果业务做起来之后月账单高得惊人。成本失控通常有三种原因。第一个是没有设置调用上限。团队内部测试、数据回放、爬虫脚本都在消耗推理资源API调用量远超真实用户量。解决办法是在平台或网关层设置限流把每个Key的日均调用量卡死发现异常再临时调整。第二个原因是对长Prompt的输入Token量估计不足。按Token计费的平台输入Token和输出Token都算钱而且很多应用的输入Prompt因为加了各种上下文记忆、RAG检索结果一次请求的输入Token可能高达几千甚至上万。这时候即使输出很短每请求的成本也远高于你的估算。优化方向是精简Prompt或者用更小的模型做上下文压缩。第三个原因是“闲置实例没缩容”。如果你用的是按实例计费的方案但忘了配置空闲缩容那业务低谷期也会按小时扣钱。务必检查平台的自动扩缩容策略设置空闲时间阈值比如连续15分钟无请求自动缩容到最小实例数。长期来看自动缩容省下的钱可能比高并发优化省下的还多。5.4 一个稳妥的组合策略不要把所有鸡蛋放在一个篮子里最后分享一个我个人的经验。AI推理平台这两年变化太快今天性价比第一的平台三个月后可能就开始涨价或者服务质量下降。如果创业公司的整个推理链路绑定在单一平台上一旦平台出问题或者大幅调价你连转身的余地都没有。稳妥一点的做法是“主备双活”主平台承载日常流量备平台保持最小实例或至少完成过部署验证。平时流量都打主平台备平台只留冷备或者极小比例流量。这样万一主平台出故障你能在几小时内切换流量到备平台不至于完全停服。有人会觉得“双平台部署”是不是太浪费。其实不浪费因为备平台不需要承载大量实例你只需要保证部署配置是随时可用的甚至只在每两周手动跑一次冒烟测试就行。对于那些跑在Spot实例上的批量任务天然适合放在备平台平时就在那边跑着主平台出事了就把在线流量也切过去。说白了推理平台选型是一个没有“唯一正确答案”的决策它是一个不断权衡、不断调整的动态过程。作为创业团队能做的就是把自己的业务指标定义清楚用真实压测数据做决策同时在架构上保留一点冗余和灵活性。这样无论平台市场怎么变化你的产品都能从容应对。我个人在实际操作中的体会是延迟和吞吐量的矛盾本质上不是技术问题而是成本问题。平台选得好是让你的每一分钱都花在哪里清清楚楚选得不好就是钱花了、延迟还难看得要命。建议所有团队在正式签约之前一定花一周时间把自己最核心的场景跑一遍真实压测再配上合理的流量分池和成本监控这条路走扎实了推理服务就成功了一大半。