1. 从一堆模型里挑出能用的那个AI模型选型的底层逻辑1.1 选型不是比跑分是比匹配度很多人一上来就打开各种榜单看谁排第一就选谁。我早期也这么干过结果踩了不少坑。榜单上的分数是在特定数据集上跑出来的跟你实际业务场景里的表现可能差出十万八千里。一个在通用问答上得分很高的模型放到你垂直领域的客服场景里可能连基本的行业术语都理解不了。选型的第一步是先把自己的需求拆清楚。我一般会从四个维度来梳理任务类型是文本分类、信息抽取、对话生成、代码补全还是多模态理解不同任务对模型能力的要求完全不同。分类任务可能一个小模型就够了而复杂的推理生成任务则需要更大的模型。延迟要求用户能接受多长的等待时间在线客服场景通常要求首字延迟在1秒以内而离线批量处理任务可能几分钟都能忍。延迟要求直接决定了你能用多大的模型、能不能用某些推理加速方案。数据隐私等级数据能不能出你的服务器如果能接受调用外部API那可选范围就大很多如果数据绝对不能出内网那就只能考虑本地部署的开源模型。预算约束这个不用多说但很多人只算了推理成本忘了算人力成本、运维成本和试错成本。把这四个维度列清楚之后你会发现可选范围一下子就缩小了。比如你的场景是内网部署、延迟要求高、预算有限那基本就锁定在中小参数量的开源模型上了根本不用去看那些千亿参数的巨无霸。1.2 开源还是闭源一笔需要算清楚的账这个问题几乎每个团队都会纠结。我的经验是别一上来就站队先把账算清楚。闭源API的优势很明显开箱即用、不用管运维、模型持续更新。但劣势也突出按量计费在量大之后成本飙升、数据要出内网、定制化能力有限。开源模型的优势是可控性强、数据不出门、可以深度定制但你需要自己搞定部署、推理优化、版本升级这一整套事情。我一般会用一个简单的公式来估算年度总成本 推理算力成本 运维人力成本 模型迭代成本 合规成本闭源方案里推理算力成本就是API调用费用运维人力成本很低模型迭代成本几乎为零厂商帮你做了合规成本取决于数据出域的合规评估。开源方案里推理算力成本是GPU服务器的采购或租赁费用运维人力成本不低至少需要0.5到1个专职人员模型迭代成本包括微调训练和评估的投入合规成本相对可控。举个实际的例子一个中等规模的对话应用每天处理10万次请求每次请求平均消耗500个token。用闭源API的话按目前主流价格一年大概在十几万到几十万之间。用开源模型本地部署的话需要至少2张A100或者4张A10硬件采购成本在十几万到二十几万加上运维人力第一年总成本可能差不多但第二年开始开源方案的成本优势就出来了。当然这只是纯成本角度。实际决策还要考虑团队的技术能力、业务对模型更新的依赖程度、数据敏感度等因素。1.3 模型尺寸怎么选不是越大越好“大力出奇迹”在AI领域确实有一定道理但落到工程实践里模型尺寸的选择是一个需要精细权衡的问题。我通常会把模型分成几个档位来看参数量级典型代表适用场景硬件要求1B-3B小型开源模型文本分类、简单抽取、边缘部署单张消费级显卡即可7B-14B中等开源模型对话生成、摘要、代码补全单张A10/A10032B-72B大型开源模型复杂推理、长文本理解多卡并行100B超大模型/闭源API高难度推理、多模态多卡集群或API调用选尺寸的核心原则是在满足效果要求的前提下选最小的那个。为什么因为模型越大推理延迟越高、显存占用越大、单位算力成本越高。一个7B模型能搞定的事情用72B模型来做成本可能差10倍以上而效果提升可能只有几个百分点。实际操作中我会建议先从一个中等尺寸的模型开始做基线然后往上和往下各试一档看效果和成本的曲线拐点在哪里。很多时候你会发现7B模型加上好的提示词工程效果已经接近甚至超过没有优化过的14B模型。1.4 评测环节的实操心得选型的最后一步是评测。这里我想强调一个很多人容易忽略的点评测集一定要自己构建。公开榜单的评测集跟你的业务数据分布往往差异很大。我一般会从真实业务数据里采样500到1000条覆盖各种边界情况人工标注好标准答案然后拿这个自建评测集去跑候选模型。评测的维度也要根据业务来定。比如客服场景我会重点看意图识别准确率、回复的合规性、多轮对话的上下文保持能力、对模糊问题的处理能力。而代码生成场景我会看语法正确率、逻辑正确率、对特定框架的熟悉程度。还有一个实操技巧盲测。把不同模型的输出混在一起让标注人员不知道哪条是哪个模型生成的这样能有效避免品牌偏见带来的评分偏差。2. 技术框架怎么搭从原型到生产的完整链路2.1 整体架构的分层设计一个AI应用的技术框架我习惯把它分成四层来看最底层是基础设施层包括GPU服务器、网络、存储这些。这一层的选择相对标准化主要考虑算力够不够、网络带宽能不能满足分布式推理的需求、存储能不能支撑模型权重和数据的读写。往上是模型服务层负责模型的加载、推理、批处理、并发管理。这一层是技术框架的核心也是选型差异最大的地方。常见的方案有直接用推理框架比如vLLM、TGI部署模型、用模型服务框架比如Triton做统一管理、或者用云厂商的托管推理服务。再往上是应用编排层负责把模型能力跟业务逻辑串起来。这一层通常包括提示词管理、上下文管理、工具调用、多模型路由等功能。LangChain、LlamaIndex这些框架主要解决的就是这一层的问题。最上面是业务接口层对外提供API或者界面处理鉴权、限流、日志、监控这些横切关注点。分层的好处是每一层可以独立演进。比如你想换一个推理框架只要模型服务层的接口不变上层应用基本不用动。这种解耦在生产环境里非常重要。2.2 推理框架选型vLLM、TGI还是自己写推理框架的选择直接影响到你的推理效率、显存利用率和运维复杂度。我分别说一下几个主流方案的实际使用体验。vLLM是目前开源社区里最活跃的推理框架之一。它的核心优势是PagedAttention技术能显著提高显存利用率和吞吐量。实测下来在同样的硬件上vLLM的吞吐量通常比HuggingFace原生的推理管线高出好几倍。它的部署也很简单基本上几行命令就能起一个服务。缺点是对某些特殊模型架构的支持可能滞后一些而且定制化推理逻辑需要改源码。**TGIText Generation Inference**是另一个主流选择它的优势是跟HuggingFace生态集成得很好支持连续批处理和流式输出运维接口也比较完善。在稳定性方面TGI在生产环境里的表现让我比较放心。但它的吞吐量在极端场景下可能不如vLLM。自己写推理服务除非你有非常特殊的推理逻辑比如自定义的采样策略、非标准的模型结构否则我不建议。维护成本太高而且很容易在并发处理、显存管理这些细节上踩坑。我的建议是先用vLLM快速搭一个原型验证效果如果发现某些场景下不稳定或者不满足需求再考虑换TGI或者做定制化开发。2.3 应用编排层的关键设计决策应用编排层看起来只是“把模型调用串起来”但实际上有很多设计决策会影响到系统的可维护性和扩展性。提示词管理我见过太多团队把提示词硬编码在代码里改一个提示词就要重新部署。正确的做法是把提示词模板化、配置化最好能支持版本管理和A/B测试。我一般会用YAML或者JSON来管理提示词模板每个模板有唯一的ID和版本号方便追踪和回滚。上下文管理多轮对话场景下上下文窗口的管理是一个难点。全量保留会很快撑爆上下文长度简单截断又会丢失重要信息。我常用的策略是保留最近N轮对话原文加上对更早对话的摘要。摘要可以用一个小模型来生成成本很低。多模型路由在实际生产环境里往往不是只用一个模型。简单问题用小模型快速回答复杂问题路由到大模型。这种路由策略能显著降低成本。路由的判断可以用规则引擎也可以训练一个轻量级的分类器。工具调用当模型需要调用外部工具比如查数据库、调API时需要一套可靠的函数调用框架。这里的关键是错误处理和重试机制。模型生成的函数调用参数可能格式不对需要有校验和修正的逻辑。2.4 从原型到生产的鸿沟很多团队在原型阶段跑通了demo就觉得大功告成了。但从原型到生产中间有一道很深的鸿沟。并发处理原型阶段可能就你一个人在测试生产环境可能同时有几百上千个请求。推理服务的并发管理、请求队列、超时处理、降级策略这些都需要仔细设计。监控告警生产环境必须有一套完整的监控体系。我一般会监控这几个核心指标请求量、延迟分布P50/P95/P99、错误率、GPU利用率、显存占用、模型输出质量通过采样人工评估或者自动评估。任何一个指标异常都要能及时告警。灰度发布模型更新或者提示词修改不能一下子全量推上去。需要支持灰度发布先放量1%的流量观察一段时间没问题再逐步扩大。这要求你的架构支持多版本共存和流量切分。回滚机制出了问题要能快速回滚。这不仅是技术上的版本回滚还包括数据层面的回滚比如某些请求产生了副作用需要撤销。3. 成本控制每一分钱都要花在刀刃上3.1 推理成本的精算方法推理成本是AI应用运营成本的大头。要控制成本首先得知道钱花在哪里了。推理成本的核心公式是单次推理成本 (GPU小时成本 / 每小时处理请求数) × 平均每次请求的推理时间从这个公式可以看出降低成本有三个方向降低GPU小时成本、提高每小时处理请求数、减少每次请求的推理时间。降低GPU小时成本可以选择性价比更高的显卡比如用消费级显卡替代数据中心显卡但要注意稳定性和显存带宽的差异、使用竞价实例适合离线批处理任务、或者在不同云厂商之间比价。提高吞吐量这是最有效的降本手段。通过批处理batching、连续批处理continuous batching、量化quantization等技术可以在同样的硬件上处理更多的请求。vLLM的PagedAttention和连续批处理能把吞吐量提升好几倍。减少推理时间优化提示词长度更短的提示词意味着更少的计算量、使用投机采样speculative decoding、对输出长度做限制这些都能减少单次推理的时间。我实际测算过一个场景一个7B模型用FP16精度推理单张A10上大概能跑到每秒20-30个token。用了INT8量化之后速度提升到每秒40-50个token而效果下降不到1%。再配合连续批处理吞吐量还能再翻几倍。3.2 训练和微调成本的管控如果你需要微调模型成本控制同样重要。微调的成本主要包括数据标注成本、GPU训练成本、实验迭代成本。数据标注是很多人低估的一块。高质量的标注数据非常贵而且标注质量直接影响微调效果。我的经验是宁可少而精不要多而杂。1000条高质量标注数据往往比10000条低质量数据效果更好。另外可以考虑用大模型辅助标注让大模型先标一遍人工只做校验和修正能显著降低标注成本。GPU训练成本方面选择合适的微调方法很关键。全量微调需要大量显存和计算资源而LoRA、QLoRA这些参数高效微调方法能在单张显卡上完成微调成本降低一个数量级。实测下来LoRA在大多数场景下的效果跟全量微调差距很小但成本只有后者的十分之一。实验迭代成本容易被忽略。每次实验都要消耗GPU时间如果实验管理混乱重复实验和无效实验会浪费大量资源。我一般会用实验跟踪工具比如WB或者MLflow来管理每次实验的配置、结果和模型权重避免重复劳动。3.3 那些容易被忽略的隐性成本除了算力和人力还有一些隐性成本经常被忽略数据存储和传输成本模型权重、训练数据、日志数据这些加起来可能占用大量存储空间。特别是日志数据如果不做定期清理和归档会快速膨胀。我一般会设置日志的保留策略比如原始日志保留7天聚合后的统计指标保留90天。网络带宽成本如果你的服务是多区域部署的跨区域的数据传输会产生费用。模型推理的输入输出虽然单次不大但量大之后带宽成本也不容忽视。合规和安全成本数据加密、访问审计、安全扫描这些都需要投入。特别是在受监管的行业合规成本可能占到总成本的相当比例。试错成本选了一个不合适的模型或者框架迁移的成本可能很高。这也是为什么我在选型阶段会花大量时间做调研和验证。3.4 成本优化的实战技巧分享几个我在实际项目中验证过的成本优化技巧动态批处理根据请求的到达速率动态调整批处理的大小。请求少的时候用小批次降低延迟请求多的时候用大批次提高吞吐。vLLM和TGI都支持这种模式。模型分级不是所有请求都需要用大模型。我一般会用一个轻量级的分类器先判断请求的复杂度简单请求走小模型复杂请求走大模型。这个策略能降低30%-50%的推理成本。缓存策略对于重复性高的请求比如常见问题回答可以把结果缓存起来直接返回缓存结果不用调用模型。缓存的命中率取决于你的业务场景在客服场景里命中率可能达到20%-30%。输出长度控制在提示词里明确要求模型输出简洁的回答设置max_tokens参数限制最大输出长度。输出长度减少一半推理成本也差不多减少一半。量化部署INT8量化基本上不会损失效果INT4量化在大多数场景下效果损失也在可接受范围内。量化之后显存占用减少同样硬件能部署更大的模型或者服务更多的请求。4. 合规要求不能碰的红线和不必要的弯路4.1 数据合规的基本框架AI应用的数据合规核心是搞清楚三个问题数据从哪里来、数据怎么用、数据到哪里去。数据来源合规训练数据、微调数据、用户输入数据来源必须合法。特别是训练数据如果用了有版权争议的数据集后续可能面临法律风险。我一般会要求数据来源有明确的授权说明并且保留数据来源的记录。数据使用合规用户数据用于模型训练或者改进必须获得用户明确授权。在很多地区这要求在产品界面上有清晰的告知和同意机制。另外敏感数据比如个人身份信息、健康数据的使用有更严格的限制。数据出境合规如果数据要传输到境外或者使用境外的API服务需要评估是否符合数据出境的相关要求。这也是为什么很多企业选择本地部署开源模型的原因之一。4.2 模型输出内容的合规管控模型生成的内容可能包含不当信息这是AI应用特有的合规风险。管控手段主要有三层输入过滤在请求进入模型之前对输入内容做检测和过滤。比如检测是否包含敏感词、是否试图诱导模型生成不当内容。输出过滤模型生成的内容在返回给用户之前再过一遍过滤。这层过滤可以用规则引擎关键词匹配、正则表达式加上模型判断用一个小的分类模型来判断内容是否合规。人工审核对于高风险场景可以设置人工审核环节。比如医疗、金融领域的AI输出可能需要人工确认后才能发给用户。我实际搭建过的过滤系统一般是规则引擎打底覆盖明确的违规词加上一个轻量级的分类模型处理规则覆盖不到的边界情况。规则引擎的好处是响应快、可解释性强分类模型的好处是能处理变体和新出现的违规模式。4.3 合规与效果的平衡合规做太严会影响用户体验和模型效果做太松又有合规风险。这个平衡怎么找我的经验是分层处理。不同场景的合规要求不一样不能一刀切。比如内部使用的工具合规要求可以适当放宽面向公众的产品合规要求就要严格很多。另外透明化很重要。在用户协议和产品界面上清楚地说明AI的能力边界和可能的风险让用户有合理的预期。这不仅是合规要求也是建立用户信任的关键。还有一个实操技巧建立合规案例库。把遇到的合规问题和处理方式记录下来形成内部的知识库。这样新来的同事能快速上手遇到类似问题也有参考。4.4 合规审计与持续监控合规不是一次性的工作而是持续的过程。我一般会建立一套合规审计机制定期审计每季度对数据处理流程、模型输出、用户投诉做一次全面审计。实时监控对模型输出做实时采样发现异常及时告警。版本追踪模型版本、提示词版本、过滤规则的版本都要有记录方便追溯问题。应急响应制定合规事件的应急响应流程明确谁负责、怎么处理、怎么上报。这套机制看起来繁琐但真出问题的时候能帮你快速定位和解决避免小问题演变成大事故。5. 几个真实场景的完整拆解5.1 场景一中小企业的智能客服这个场景的典型需求是处理常见的客户咨询降低人工客服压力预算有限数据不能出内网。我的方案是用一个7B的开源模型INT8量化部署在单张A10上用vLLM做推理服务。应用层用LangChain做编排提示词模板化管理加上一个基于规则的输入输出过滤。成本方面硬件一次性投入大概两万左右每月电费和运维人力大概几千块。效果方面常见问题比如退换货政策、物流查询的自动解决率能达到70%以上复杂问题转人工。响应延迟在1秒以内用户基本无感知。踩过的坑一开始用了14B的模型效果确实好一些但延迟到了2秒以上用户体验明显下降。换成7B之后配合更好的提示词工程效果差距缩小到可以接受的范围但延迟降了一半。5.2 场景二内容平台的AI辅助创作这个场景的需求是帮助创作者生成文章大纲、润色文字、生成配图描述。用户量大对延迟敏感需要控制成本。方案是用闭源API做主力因为用户量大自建推理集群的成本反而更高配合一个本地的小模型做预处理比如意图识别、敏感词过滤。应用层做了多模型路由简单任务走小模型复杂任务走大模型。成本控制方面用了缓存策略相似请求直接返回缓存结果、输出长度限制、以及动态路由。实测下来综合成本比全部走大模型降低了40%左右。踩过的坑缓存策略一开始没做好失效机制导致用户修改了输入之后还返回旧的缓存结果。后来加了基于输入哈希的缓存键并且设置了合理的过期时间问题才解决。5.3 场景三金融行业的文档分析这个场景的需求是从大量金融文档中抽取关键信息生成摘要辅助分析师工作。数据高度敏感绝对不能出内网对准确性要求极高。方案是本地部署一个32B的模型用多卡并行推理。应用层做了严格的输入输出校验所有模型输出都要经过规则引擎和人工抽查。合规方面做了完整的数据加密、访问审计和操作日志。成本方面硬件投入比较大多卡服务器但考虑到数据敏感性和准确性要求这个投入是必要的。运维方面有专人负责模型更新和监控。踩过的坑32B模型在长文档上的推理速度很慢一份50页的文档要处理好几分钟。后来做了分段处理加摘要聚合的策略把长文档拆成小段分别处理再汇总结果速度提升了好几倍。6. 常见问题与排查技巧实录6.1 模型选型阶段的常见问题问题榜单上排名很高的模型实际效果却很差。排查思路先确认你的评测集跟榜单的评测集差异有多大。如果差异很大那榜单的参考价值就有限。然后检查你的提示词是否适配这个模型。不同模型对提示词格式的敏感度不一样有些模型需要特定的格式才能发挥最佳效果。问题模型在测试集上效果很好上线后效果下降明显。排查思路这通常是数据分布偏移导致的。测试集的数据分布跟真实线上数据不一致。解决办法是定期用线上数据更新评测集并且监控线上效果指标发现下降及时排查。6.2 部署和运维阶段的常见问题问题推理服务时不时超时。排查思路先看GPU利用率如果利用率很高90%以上说明算力不够需要扩容或者优化推理效率。如果利用率不高但延迟高可能是批处理策略有问题或者请求队列管理有问题。另外检查一下是否有内存泄漏长时间运行后显存占用持续增长。问题模型输出不稳定同样的输入有时候结果差异很大。排查思路检查temperature和top_p参数。如果temperature设置过高比如大于1输出的随机性会很大。对于需要稳定输出的场景建议temperature设为0或者很小的值。另外检查是否有并发请求之间的干扰比如共享了某些状态。6.3 成本控制阶段的常见问题问题月底账单远超预期。排查思路先看请求量是否超出预期再看单次请求的成本是否偏高。单次成本偏高可能是提示词太长、输出太长、或者批处理效率低。我一般会做一个成本分解表把成本按请求类型、按时间段、按模型版本拆开看找出成本异常的部分。问题量化之后效果下降明显。排查思路不是所有模型都适合量化。有些模型对量化很敏感INT8就会明显掉效果。可以尝试不同的量化方法GPTQ、AWQ、GGUF等或者只对部分层做量化。另外量化后的模型可能需要重新调提示词因为输出的风格可能会有变化。6.4 合规阶段的常见问题问题过滤规则太严正常请求也被拦截。排查思路过滤规则需要持续调优。我一般会先宽松一点上线然后根据误拦的案例逐步收紧。同时建立白名单机制对于确认安全的请求类型可以走快速通道。问题合规审计时发现数据流向不清晰。排查思路这通常是架构设计阶段没有考虑合规要求导致的。解决办法是补上数据流向图明确每个环节数据的来源、去向和处理方式。后续新系统设计时把合规要求作为架构设计的一部分而不是事后补。7. 我个人的一些经验体会做AI应用这几年最大的体会是技术选型没有标准答案只有适合当前场景的答案。同样的问题在不同的团队、不同的业务阶段、不同的资源条件下最优解可能完全不同。另一个体会是成本控制要从第一天就开始做。很多团队前期为了快速上线不太考虑成本等到量大了才发现成本失控这时候再改架构就很痛苦了。我一般会在项目初期就建立成本监控哪怕一开始量很小也要有成本意识。还有一点合规不是负担而是竞争力。在受监管的行业里能把合规做好的团队反而能获得更多信任和机会。我见过一些团队因为合规做得好在竞标中胜出。最后分享一个实用的小技巧建立自己的技术决策记录。每次做重要的技术选型时把当时的背景、考虑的方案、选择的理由、预期的效果都记录下来。过几个月回头看你会发现很多决策的逻辑已经模糊了这份记录能帮你快速回忆也能帮新同事理解现状。这个习惯我坚持了三年受益良多。