9月23日我更新了手头这份国内外大模型清单从GPT、Claude、Gemini到DeepSeek、通义、Kimi、豆包再到可以本地跑的Llama、Qwen系列全部按模型和应用两个维度重新梳理了一遍。为什么专门强调模型/应用维度因为现在的局面早就不是哪个模型最强的问题了而是在具体场景下哪个模型最合适、怎么把它落到产品里。这篇就当作我阶段性折腾的总结覆盖模型选型、本地部署、微调、应用集成和排坑思路想搞大模型技术选型或者做AI应用开发的朋友可以参考。先说下写这篇的动机。我最近半年一直在做AI应用相关的事情从底层跑模型到给APP集成智能功能都碰了一遍接触到不少同事、同行还在问热门大模型到底有哪些微调是不是一定要A100本地部署怎么选卡这类问题。所以这篇不打算写成那种罗列100个模型名称的水文而是把我实际摸过、用过的模型放在一起做横向对比同时把部署、微调、应用开发里容易踩坑的地方指出来尽量让看完的人能直接用得上至少不会在第一步选型就翻车。如果你是想做大模型应用开发的工程师或者刚准备把AI能力接进现有产品这篇可以帮你把模型侧和应用侧的全局图画出来。如果你是纯粹好奇大模型现状的也可以当一份带个人视角的盘点来看我不会堆术语能展开的地方都会展开。1. 模型全景国内外知名大模型怎么分、怎么选1.1 国外主流模型的现状截止到现在国外大模型基本可以分成闭源API派和开源权重派两拨。闭源派里OpenAI的GPT系列还是绕不开的参照物GPT-4o之后又迭代了好几版在多模态、长上下文和Agent调用上的完成度都相当高。我自己用GPT系列做复杂推理和函数调用类任务比较多它的工具调用协议现在基本成了行业事实标准。Anthropic的Claude则是另一个极端长文本理解、代码生成和写作质量非常突出Claude在30K以上token的上下文里还能保持稳定输出这一点很多模型做不到。Google的Gemini系列因为有自家搜索引擎和云生态的加持多模态能力和与Google生态的集成是最大卖点如果产品本身依赖YouTube、Google Drive或者Gmail的内容选Gemini会顺滑很多。开源派这几年也起来得很快Llama系列一直是开源社区的风向标从Llama 2到Llama 3再到后续版本社区生态极其繁荣。Mistral系列的MoE混合专家架构算是开源模型里的一个技术亮点推理成本控制得不错速度也快。还有一个容易被忽视的点是很多开源模型的中文能力在快速接近闭源模型比如Qwen系列在中文场景下性价比已经反超了不少闭源模型。所以如果你做中文场景、又有数据合规或者成本控制的压力开源模型完全是可以认真考虑的选项。从我的实际体验来说选国外模型有一个默认前提能访问到服务、愿意把数据交出去、并且接受按token计费。这三点在国内政企场景或者出海转内销场景里经常是硬伤所以境外模型虽好但落地时普遍要过合规这一关这在国内实际项目里太常见了。1.2 国内模型矩阵国内大模型现在的格局比较清晰闭源梯队基本是DeepSeek、通义千问、Kimi、豆包、智谱这些各自定位差异很大。DeepSeek走的是高性能低成本的路线模型能力开箱即用API价格压得很低实际体验下来在中文理解、代码生成上有很不错的水平。如果要接国内闭源API我个人会第一个考虑DeepSeek尤其是预算紧张、但还想体验接近第一梯队能力的时候。通义千问走的是全家桶路线从语言、多模态到视频生成都有背后有阿里云兜底生态集成比较完整企业客户很多。Kimi的特点一度是长文本到现在它的长文档解析能力依然是主打文献阅读、合同分析这类场景很合适。豆包是从字节跳动内部工具成长起来的和飞书、抖音生态联动很深在内容创作、办公辅助场景里普及率很高。智谱则更像国内学术派代表GLM系列迭代稳定在多模态和智能体方面也有持续投入。开源侧Qwen系列在国内开源模型里基本是统治级的存在不管是用Llama还是Mistral最后做中文任务时大概率会回到Qwen上。DeepSeek也开源了一些中间版本虽然主打不是开源生态但权重放出来以后社区反馈很好。国内还有零一万物、百川智能、书生·浦语这些也都有开源版本只是生态和应用广度跟Qwen没法比。国内模型还有一个显著特点很多模型不仅提供API还在各个平台上放了免费体验入口甚至免费API额度。这跟国外类似但对个人开发者和中小企业来说是巨大利好先免费试、再决定付费这个决策成本低多了。1.3 选型原则别只看榜单分数很多人在选模型时习惯盯着跑分榜比如某个综合能力榜上谁分数高就选谁。我的经验是跑分只能作为粗筛不能作为最终决策依据。第一个原因是跑分场景和真实使用场景差异太大。榜单测试通常集中在逻辑题、短问答、知识测试上但你的真实场景可能是从100页PDF里抽取特定格式的数据或者根据用户语音指令控制车机导航这种场景跑分不管用只能自己造一批测试样本去实测。第二个原因是成本和性能要一起看。一个模型跑分高10%但API价格贵一倍推理速度慢一倍很多时候并不值得。尤其在高并发、高频调用的应用里成本模型往往比能力模型更关键。比如一个智能客服应用每天百万次请求每次请求差几毫秒、每千token差几分钱累积下来就是巨大的成本差异。第三个原因是生态和周边工具成熟度。同一个模型A只有原始APIB有完善的SDK、调试工具、微调平台、社区案例选B的落地效率会高太多。这也是为什么Qwen、Llama这类模型在工程圈特别受欢迎——不只是模型本身好而是配套工具链完整。所以我的建议是先明确场景和约束成本、合规、上下文长度、中文能力、输出格式要求再初筛出2到3个候选模型最后用你自己手里的真实数据做一轮小规模评测再做最终决策。这比任何榜单都靠谱。2. 部署落地API、本地推理与硬件配置2.1 云端API最省事的方案如果需求是快速验证、对延迟和网络没有严苛要求直接调云端API是最省事的路径不用管GPU、不用管推理框架、不用管运维。主流云厂商现在都提供大模型API服务国外有OpenAI、Anthropic、Google等官方API也有一堆第三方托管平台把各家开源模型打包成API对外售卖。国内更直接阿里云、腾讯云、字节、智谱、DeepSeek等基本都能在几分钟内拿到API Key。使用云端API的核心里程碑是成本估算。一个很实用的估算经验一次普通的中等长度对话比如请求2000个输入token、生成500个输出token如果API价格是输入3元/百万token、输出15元/百万token那么单次成本大约为2000/10000003 500/100000015 0.006 0.0075 0.0135元一万次对话就是135元。很多新人死在看起来便宜的陷阱里就是因为没有把并发量和调用频次放大去算总账。另一个点是免费额度。现在绝大多数国内模型厂商都会送新用户免费体验额度有些还定期发代金券做原型验证完全够用。我见过不少人用这些免费额度把一个MVP跑通了才决定是否付费这个节奏是对的。2.2 本地部署从GGUF到推理框架本地部署大模型的诉求一般有两个数据敏感不能出内网或者高频调用、云端成本压不住。本地部署的典型路径是拿开源模型权重转成或直接下载GGUF量化格式再用llama.cpp、Ollama这类推理框架跑起来。GGUF这个格式的优势在于量化做得很好能把模型压缩到原来的一半甚至三分之一显存和内存占用大幅下降同时质量损失控制在可接受范围内。Ollama则做得更傻瓜化一条命令就能把Qwen、Llama这样的模型拉下来跑还自动搞定端口和API兼容层。硬件配置上我的建议是尽量买显存大的卡而不是只盯着性能跑分。模型部署的硬约束是显存容量7B参数模型在4bit量化下大约需要5GB到6GB显存14B模型大约需要10GB到12GB32B模型至少需要22GB以上70B模型就得靠多卡或者48GB以上的专业卡。如果你只是个人电脑本地部署一张24GB显存的消费级显卡比如RTX 3090/4090跑通7B到14B量化模型很舒服32B的则会比较紧张。还有一个实际经验CPU推理并不是完全不可用。如果你是纯CPU机器用llama.cpp跑7B量化模型速度大概是每秒几个token虽然慢但用来测试、调接口完全足够。我自己就干过在一台无GPU的旧服务器上临时拿CPU跑Qwen 7B搭demo能跑只是没法高并发别指望生产环境而已。2.3 GPU与驱动的那些细节本地部署除了硬件本身驱动和运行模式也是容易出幺蛾子的地方。NVIDIA显卡在Windows下有WDDM和TCC两种驱动模式Windows图形驱动模式下显存管理偏向桌面应用TCC模式则是纯计算模式没有显示输出功能专门给服务器、数据中心用的。对本地推理来说如果你的Windows机器既要当桌面用又要跑模型WDDM模式更合适如果这台机器就是专用来推理的不连显示器、不做图形任务切换到TCC模式能提升一点CUDA计算稳定性尤其是在多卡环境下。切换方法就是NVIDIA官方工具里的启用TCC模式选项但记住切了以后这个卡就没画面输出了。AMD显卡的情况要复杂一些比如有人问rx6750gre训练大模型行不行。我的回答是能跑但很折腾。AMD卡在Windows下的ROCm支持比较弱多数情况下得靠DirectML或者Vulkan做推理性能损失明显如果在Linux下用ROCm会好一些但支持列表和坑也不比N卡少。所以正经搞模型训练或长期推理我还是建议N卡省下的时间比显卡差价值钱得多。还有一个经常被忽略的问题是Windows的智能应用控制或SmartScreen拦截。本地推理程序经常要被杀毒软件或系统安全机制拦下来提示智能应用控制已阻止可能不安全的应用原因通常是推理程序不是签名应用、又是命令行工具容易被误判。解决方法是把这个程序目录加入信任区或关闭针对该目录的智能应用控制但注意不要盲目关闭整个系统的安全功能只放行你确认安全的推理目录即可。3. 微调实战把通用模型变成领域模型3.1 先确认要不要微调微调是大模型应用里被过度神化的一步。很多新手一上来就说要微调一个自己的大模型但实际上大多数业务场景压根用不到微调。什么时候应该先考虑提示词工程和上下文工程答案是任务定义清晰、输出格式固定、知识需求可以通过检索补充的时候。你可以先在Prompt里写清楚规则、给一两个示例如果效果已经很好那就没必要微调。只有在两种情况下才需要认真考虑微调一是模型本身的能力边界达不到任务要求比如专业文本理解、特定领域术语、特殊风格的模仿二是你希望模型稳定输出某种固定结构和风格而提示词怎么调都不稳。我自己的一个项目就是典型例子做一个医疗知识库问答系统刚开始想微调后来发现用RAG检索增强生成加提示词约束就解决了大部分问题真正需要微调的是非常窄的从化验单里抽取指定指标这种任务模型对生僻指标名总是识别不准微调之后准确率才明显提上来。所以微调不是必修课而是精准工具要用在刀刃上。3.2 微调的硬件、数据与参数如果确认要微调硬件和数据是两个先决条件。现在最常用的微调方式是LoRA低秩适配或QLoRA量化低秩适配原因是显存占用可控。LoRA只训练新增的小规模参数冻结原模型普通消费级显卡也能跑起来。举例来说7B模型用QLoRA在24GB显存下可以跑batch size为1或者2的微调14B模型也在24GB到32GB显存范围内可行。如果你只有8GB或12GB显存那最好选4B、7B级别的小模型。AMD的rx6750gre这种卡我不建议拿来训练虽然显存有12GB但生态支持太弱同样的配置在N卡上一天跑通的实验在A卡上可能要折腾一周。哪怕你的训练数据量不大我也推荐用云端GPU或租卡按小时付费比买卡划算太多。数据集是微调成功的核心没有之一。一般做任务微调几百到几千条高质量样本就够了关键是质不是量。我对数据集的清洗标准通常是每条数据都必须是你想要模型学到的真实输入输出宁可少而精不要多而杂同时必须覆盖边界情况和反面示例否则模型就只会套模板。数据格式上对话类任务用ChatML格式即带system、user、assistant标记的结构化对话最为通用。微调的超参数里比较重要的是学习率、epoch数和LoRA秩。常见起步配置是学习率1e-4到2e-4epoch数3到5LoRA秩8到32。不要一上来就搞rank 64甚至128秩越大不代表越好反而容易过拟合。还要记得给LoRA目标模块通常是注意力层的q_proj、v_proj设置正确的名字不同模型的模块命名不一样改错了就完全训练不起来。3.3 微调后的验证与部署微调完成后不能直接上线要先做效果验证。我的习惯是准备两类测试集一类是训练分布内的随机样本看模型有没有学会基本模式另一类是训练分布外的边界样本看模型有没有泛化能力。只看loss值没有意义loss降了不代表回答质量好一定要真正去看生成的文本质量。验证通过后LoRA权重要和基座模型合并导出再转成GGUF格式部署。我踩过的坑之一就是只保存了LoRA adapter部署时忘了合并加载模型后发现根本没有微调效果。正确做法是训练结束后先merge_and_unload把LoRA权重合回原模型再保存完整模型权重之后再做GGUF量化或者部署到Ollama。微调的另一个经典风险是灾难性遗忘——模型学会了新任务但把原本的通用能力忘了。缓解手段有几种在训练数据里混入一定比例的通用对话数据比如10%到20%、降低新任务的epoch数、在验证时同时测通用问答和领域任务的准确率。这个平衡问题在微调场景里几乎一定会遇到早做准备比事后补救强。4. 应用维度从AI应用到智能场景4.1 AI应用开发的整体路线模型选好、微调完成之后真正的考验才开始——怎么把它变成一个稳定可用的应用。AI应用开发和传统软件开发有一个很大的区别传统程序是输入-逻辑-输出逻辑是确定的AI应用是输入-模型推理-输出模型的行为有概率性所以应用层要做的工作更偏向于约束、纠错和兜底。一个完整的AI应用通常包含四层模型层、数据层、业务层、交互层。模型层负责推理能力数据层做RAG需要把知识库切分、向量化、存储检索业务层负责调用模型、解析结果、拼接业务逻辑交互层面向用户可能是聊天窗口、表单、API接口或者语音指令。从学习路线上来说我的建议是先学会调API感受模型的输出特性和提示词的威力然后学怎么把外部知识喂给模型RAG再学Agent与工具调用最后再碰微调。这个顺序最容易建立正反馈也最容易出成果。4.2 多端集成Android、桌面、小程序与鸿蒙应用落地绕不开端上的集成。现在比较常见的是云端API集成和端侧本地推理两种路径。Android端接云端API最省事直接HTTP请求或各家SDK如果要做端侧本地推理社区里最常见的方案是集成GGUF格式模型核心是把llama.cpp的Android端封装通过JNI融入App模型文件放在assets或者下载目录应用启动后预加载到内存。这一步的坑主要在JNI接口的编译llama.cpp的Android交叉编译如果版本不对很容易踩到NDK和ABI的坑。实际经验是直接用llama.cpp官方提供的Android构建脚本比自己折腾Makefile靠谱。桌面端的集成比较多样很多人做AI工具喜欢套一层Electron壳把后端推理服务跑在本地前端用Web技术做界面。Electron的好处是开发快、跨平台但坑是打包体积大、内存占用高。还有同事在做Electron应用移植鸿蒙我得说实话这条路并不好走因为鸿蒙的运行时是ArkTS体系Electron的Node层组件很多没法直接兼容与其硬塞进一个WebView容器不如评估一下把核心逻辑用ArkTS重写、通过鸿蒙的AI能力接口调用模型。过程更痛苦但后续维护更顺畅。小程序类应用也很常用。做uniapp的开发者应该深有体会上架安卓应用市场时隐私政策、权限声明、备案信息缺一不可尤其是涉及AI能力时部分应用市场会要求额外的算法备案或安全评估这个在项目排期时必须提前预留时间。我在审核环节被打回来三次每一次都是因为未说明AI生成内容的审核机制后来在应用内加了明显的AI生成内容标识才顺利过审。4.3 典型应用场景与RAG实战应用场景才是大模型价值真正落地的检验。我实际做过的和观察到的场景包括智能客服、知识库问答、代码生成与审查、办公文档处理、内容创作、多模态识别等。每一个场景都有对应的模型侧需求比如代码生成需要模型擅长结构化输出知识库问答需要长上下文和精准检索智能客服需要低延迟和高并发。在这些场景里RAG是绕不开的关键技术。RAG的基本思路分三步切分文档成小块、向量化存入向量数据库、检索相关块喂给模型生成答案。我觉得RAG体系里最常被低估的是切分这一步。很多团队直接用固定长度切文档效果很一般因为切块会把语义截断比如表格、代码、多级标题固定长度切分容易切在错误的地方。更好的做法是结构感知切分按段落、标题、表格边界来切再配合重叠策略。切块大小一定是根据场景调的比如合同问答的块可以稍大因为条款上下文紧密客服FAQ的块可以小一些方便精准命中。向量化模型的选择也直接影响检索效果。中文场景下用BGE这类专门的嵌入模型效果比通用模型的embedding好尤其是长尾词和专业术语。检索阶段做混合检索关键词检索向量检索再做一个重排能明显提高答案的准确性。这些细节叠加起来RAG系统的体感差距就拉开了。大模型的应用场景还不止于软件产品。车机导航领域模型可以做语音交互和目的地解析比如带我去最近充电站而且中途要经过便利店这种复杂语义传统规则引擎很难解析大模型就很自然。工业场景里模型用来做设备日志的异常诊断、维修知识问答也已经有很成熟的应用。这个维度随着模型能力增强还在持续拓宽。5. 常见问题与排查技巧实录5.1 运行环境与安装类问题AI应用开发中最常见的拦路虎其实是环境问题。安装Python管理器时碰到从python-manager-26.3.msix使用程序包安装失败这类错误其实本质上是Windows应用包签名或老版本冲突问题解决办法通常是把旧的Python版本完全卸载、手动清理%LOCALAPPDATA%\Microsoft\WindowsApps里残留的执行链路再用管理员权限重新安装基本能解决。如果还是不行就直接换非MSIX的安装包。另一个高频问题就是智能应用控制已阻止可能不安全的应用或阻止此应用的一部分。这个在大模型本地部署时出现频率很高因为很多推理工具是开源社区发布的exe没有商业签名。处理思路是先确认工具来源可靠比如从官方GitHub仓库下载然后在Windows安全中心的智能应用控制里把该目录加入排除项。不要图省事直接全局关闭保持系统对其他未知程序的安全防护还是必要的。还有同学问获取打开此ms-gamingoverlay链接的应用是什么情况。这其实跟大模型没关系是Windows的Game Bar相关链接协议没有注册应用导致的弹窗。但在做本地推理时如果这台机器装了Xbox Game Bar偶尔会和全屏GUI应用抢资源或弹提示。我是建议在做推理的机器上干脆关掉Game Bar和游戏覆盖层省得误导和干扰。5.2 部署与接口对接问题本地推理服务跑起来了接入应用时最容易有问题的是参数不匹配和并发控制。模型生成参数里温度、top_p、max_tokens这三个最常被调但这几个参数并不是越大越好。做客服场景温度建议0.3以下保证输出稳定做创意写作温度可以到0.8甚至更高多样性才有意义。max_tokens如果设太短长回答会被截断看起来像模型笨其实是参数没调好。并发控制也是部署端不得不面对的问题。GPU显存是有限的假设你的显卡跑7B量化模型的batch size上限是4那么并发超过4就必然排队或OOM。更合理的方案是在API服务层加一层队列或限流宁可让请求等待也不能让GPU直接崩掉。我有一次在客户现场演示时因为并发没控制住直接显存OOM整个演示全毁从那以后我任何部署环境第一件事就是确认并发上限。5.3 微调训练问题微调时的loss不下降或者剧烈震荡多数原因不是超参而是数据问题。最常见的三种情况数据里有大量重复样本导致模型在重复模式上过拟合训练集和验证集的分布不一致验证集loss奇高标签质量差模型学的是噪声。遇到loss问题我的第一反应永远是看数据而不是调参数。把训练集随机抽几十条出来人眼检查一遍往往原形毕露。显存不足也是微调的高频报错常见提示是CUDA out of memory。解决优先级一般是这样先把batch size降到1然后把gradient accumulation step设4到8损失不了太多效果再不行就用QLoRA的4bit量化比原模型省一半显存。如果这样还不行那就换小模型或者上云。大模型下载缓慢、连接不稳定也是部署群里每天都有人问的问题。国内访问Hugging Face经常超时解决办法是用国内镜像站把HF_ENDPOINT环境变量指到镜像地址或者直接从ModelScope下载权重速度稳定很多。这个细节在网上被反复提过但每次新手还是会卡在这一步所以我还是再写一遍。5.4 模型效果与安全问题排查有时候应用接好了模型回答的准确率却不理想。先别慌着换模型按这个顺序排查一遍先测提示词同样的输入用不同表述多试几次如果能靠提示词解决就说明模型能力够用再测RAG链路看检索回来的上下文对不对如果检索不到相关内容微调也救不回来最后才考虑微调。我见过太多团队跳步没有排查就直奔微调花了两周训完效果还是差最后发现是知识库压根没被正确检索到。内容安全方面也值得认真对待。大模型输出是不可完全预知的生产环境必须有输出过滤、敏感词检测和人工审核兜底。尤其面向C端的产品AI生成内容的标识和审核机制不只是合规要求也是保护用户和产品口碑的必要手段。我在应用里会加三层防护输入侧做意图过滤输出侧做内容安全分类重要场景再做人工复核。模型能力再强这道防线也不能省。6. 关于模型/应用维度的一些心得我把模型和应用分开理了一遍之后最大的感受是这个领域的节奏快到让人焦虑但底层方法论反而稳定。模型榜单每隔几个月就会翻新一遍应用形态从Chatbot卷到Agent再从Agent卷到端侧智能可落到工程层面无非还是选型、部署、调优、集成这四件事。把这四件事的套路吃透不管模型换了几轮你都能跟上节奏。我个人在实操中最深的体会是数据能力才是AI应用的核心竞争力。不管是RAG里的知识库治理还是微调里的数据集清洗最后决定体验天花板的永远是数据质量而不是你用了哪家的模型。把所有精力都花在追新模型上不如踏踏实实把数据管线建好。最后再分享一个我一直在用的小技巧每次引入一个新模型不要只测官方示例把你业务里最刁钻的50条真实输入整理成一个回归测试集每次换模型或调完参就跑一遍对比输出质量。这个习惯长期帮我避免了很多看起来换了新模型但实际更差了的尴尬。做AI应用这行稳定的基线比偶尔的惊喜重要得多工具和方法论都在变把基线维护好你就始终站在踏实的位置上。
从选型到落地：大模型部署、微调与AI应用集成实战指南
9月23日我更新了手头这份国内外大模型清单从GPT、Claude、Gemini到DeepSeek、通义、Kimi、豆包再到可以本地跑的Llama、Qwen系列全部按模型和应用两个维度重新梳理了一遍。为什么专门强调模型/应用维度因为现在的局面早就不是哪个模型最强的问题了而是在具体场景下哪个模型最合适、怎么把它落到产品里。这篇就当作我阶段性折腾的总结覆盖模型选型、本地部署、微调、应用集成和排坑思路想搞大模型技术选型或者做AI应用开发的朋友可以参考。先说下写这篇的动机。我最近半年一直在做AI应用相关的事情从底层跑模型到给APP集成智能功能都碰了一遍接触到不少同事、同行还在问热门大模型到底有哪些微调是不是一定要A100本地部署怎么选卡这类问题。所以这篇不打算写成那种罗列100个模型名称的水文而是把我实际摸过、用过的模型放在一起做横向对比同时把部署、微调、应用开发里容易踩坑的地方指出来尽量让看完的人能直接用得上至少不会在第一步选型就翻车。如果你是想做大模型应用开发的工程师或者刚准备把AI能力接进现有产品这篇可以帮你把模型侧和应用侧的全局图画出来。如果你是纯粹好奇大模型现状的也可以当一份带个人视角的盘点来看我不会堆术语能展开的地方都会展开。1. 模型全景国内外知名大模型怎么分、怎么选1.1 国外主流模型的现状截止到现在国外大模型基本可以分成闭源API派和开源权重派两拨。闭源派里OpenAI的GPT系列还是绕不开的参照物GPT-4o之后又迭代了好几版在多模态、长上下文和Agent调用上的完成度都相当高。我自己用GPT系列做复杂推理和函数调用类任务比较多它的工具调用协议现在基本成了行业事实标准。Anthropic的Claude则是另一个极端长文本理解、代码生成和写作质量非常突出Claude在30K以上token的上下文里还能保持稳定输出这一点很多模型做不到。Google的Gemini系列因为有自家搜索引擎和云生态的加持多模态能力和与Google生态的集成是最大卖点如果产品本身依赖YouTube、Google Drive或者Gmail的内容选Gemini会顺滑很多。开源派这几年也起来得很快Llama系列一直是开源社区的风向标从Llama 2到Llama 3再到后续版本社区生态极其繁荣。Mistral系列的MoE混合专家架构算是开源模型里的一个技术亮点推理成本控制得不错速度也快。还有一个容易被忽视的点是很多开源模型的中文能力在快速接近闭源模型比如Qwen系列在中文场景下性价比已经反超了不少闭源模型。所以如果你做中文场景、又有数据合规或者成本控制的压力开源模型完全是可以认真考虑的选项。从我的实际体验来说选国外模型有一个默认前提能访问到服务、愿意把数据交出去、并且接受按token计费。这三点在国内政企场景或者出海转内销场景里经常是硬伤所以境外模型虽好但落地时普遍要过合规这一关这在国内实际项目里太常见了。1.2 国内模型矩阵国内大模型现在的格局比较清晰闭源梯队基本是DeepSeek、通义千问、Kimi、豆包、智谱这些各自定位差异很大。DeepSeek走的是高性能低成本的路线模型能力开箱即用API价格压得很低实际体验下来在中文理解、代码生成上有很不错的水平。如果要接国内闭源API我个人会第一个考虑DeepSeek尤其是预算紧张、但还想体验接近第一梯队能力的时候。通义千问走的是全家桶路线从语言、多模态到视频生成都有背后有阿里云兜底生态集成比较完整企业客户很多。Kimi的特点一度是长文本到现在它的长文档解析能力依然是主打文献阅读、合同分析这类场景很合适。豆包是从字节跳动内部工具成长起来的和飞书、抖音生态联动很深在内容创作、办公辅助场景里普及率很高。智谱则更像国内学术派代表GLM系列迭代稳定在多模态和智能体方面也有持续投入。开源侧Qwen系列在国内开源模型里基本是统治级的存在不管是用Llama还是Mistral最后做中文任务时大概率会回到Qwen上。DeepSeek也开源了一些中间版本虽然主打不是开源生态但权重放出来以后社区反馈很好。国内还有零一万物、百川智能、书生·浦语这些也都有开源版本只是生态和应用广度跟Qwen没法比。国内模型还有一个显著特点很多模型不仅提供API还在各个平台上放了免费体验入口甚至免费API额度。这跟国外类似但对个人开发者和中小企业来说是巨大利好先免费试、再决定付费这个决策成本低多了。1.3 选型原则别只看榜单分数很多人在选模型时习惯盯着跑分榜比如某个综合能力榜上谁分数高就选谁。我的经验是跑分只能作为粗筛不能作为最终决策依据。第一个原因是跑分场景和真实使用场景差异太大。榜单测试通常集中在逻辑题、短问答、知识测试上但你的真实场景可能是从100页PDF里抽取特定格式的数据或者根据用户语音指令控制车机导航这种场景跑分不管用只能自己造一批测试样本去实测。第二个原因是成本和性能要一起看。一个模型跑分高10%但API价格贵一倍推理速度慢一倍很多时候并不值得。尤其在高并发、高频调用的应用里成本模型往往比能力模型更关键。比如一个智能客服应用每天百万次请求每次请求差几毫秒、每千token差几分钱累积下来就是巨大的成本差异。第三个原因是生态和周边工具成熟度。同一个模型A只有原始APIB有完善的SDK、调试工具、微调平台、社区案例选B的落地效率会高太多。这也是为什么Qwen、Llama这类模型在工程圈特别受欢迎——不只是模型本身好而是配套工具链完整。所以我的建议是先明确场景和约束成本、合规、上下文长度、中文能力、输出格式要求再初筛出2到3个候选模型最后用你自己手里的真实数据做一轮小规模评测再做最终决策。这比任何榜单都靠谱。2. 部署落地API、本地推理与硬件配置2.1 云端API最省事的方案如果需求是快速验证、对延迟和网络没有严苛要求直接调云端API是最省事的路径不用管GPU、不用管推理框架、不用管运维。主流云厂商现在都提供大模型API服务国外有OpenAI、Anthropic、Google等官方API也有一堆第三方托管平台把各家开源模型打包成API对外售卖。国内更直接阿里云、腾讯云、字节、智谱、DeepSeek等基本都能在几分钟内拿到API Key。使用云端API的核心里程碑是成本估算。一个很实用的估算经验一次普通的中等长度对话比如请求2000个输入token、生成500个输出token如果API价格是输入3元/百万token、输出15元/百万token那么单次成本大约为2000/10000003 500/100000015 0.006 0.0075 0.0135元一万次对话就是135元。很多新人死在看起来便宜的陷阱里就是因为没有把并发量和调用频次放大去算总账。另一个点是免费额度。现在绝大多数国内模型厂商都会送新用户免费体验额度有些还定期发代金券做原型验证完全够用。我见过不少人用这些免费额度把一个MVP跑通了才决定是否付费这个节奏是对的。2.2 本地部署从GGUF到推理框架本地部署大模型的诉求一般有两个数据敏感不能出内网或者高频调用、云端成本压不住。本地部署的典型路径是拿开源模型权重转成或直接下载GGUF量化格式再用llama.cpp、Ollama这类推理框架跑起来。GGUF这个格式的优势在于量化做得很好能把模型压缩到原来的一半甚至三分之一显存和内存占用大幅下降同时质量损失控制在可接受范围内。Ollama则做得更傻瓜化一条命令就能把Qwen、Llama这样的模型拉下来跑还自动搞定端口和API兼容层。硬件配置上我的建议是尽量买显存大的卡而不是只盯着性能跑分。模型部署的硬约束是显存容量7B参数模型在4bit量化下大约需要5GB到6GB显存14B模型大约需要10GB到12GB32B模型至少需要22GB以上70B模型就得靠多卡或者48GB以上的专业卡。如果你只是个人电脑本地部署一张24GB显存的消费级显卡比如RTX 3090/4090跑通7B到14B量化模型很舒服32B的则会比较紧张。还有一个实际经验CPU推理并不是完全不可用。如果你是纯CPU机器用llama.cpp跑7B量化模型速度大概是每秒几个token虽然慢但用来测试、调接口完全足够。我自己就干过在一台无GPU的旧服务器上临时拿CPU跑Qwen 7B搭demo能跑只是没法高并发别指望生产环境而已。2.3 GPU与驱动的那些细节本地部署除了硬件本身驱动和运行模式也是容易出幺蛾子的地方。NVIDIA显卡在Windows下有WDDM和TCC两种驱动模式Windows图形驱动模式下显存管理偏向桌面应用TCC模式则是纯计算模式没有显示输出功能专门给服务器、数据中心用的。对本地推理来说如果你的Windows机器既要当桌面用又要跑模型WDDM模式更合适如果这台机器就是专用来推理的不连显示器、不做图形任务切换到TCC模式能提升一点CUDA计算稳定性尤其是在多卡环境下。切换方法就是NVIDIA官方工具里的启用TCC模式选项但记住切了以后这个卡就没画面输出了。AMD显卡的情况要复杂一些比如有人问rx6750gre训练大模型行不行。我的回答是能跑但很折腾。AMD卡在Windows下的ROCm支持比较弱多数情况下得靠DirectML或者Vulkan做推理性能损失明显如果在Linux下用ROCm会好一些但支持列表和坑也不比N卡少。所以正经搞模型训练或长期推理我还是建议N卡省下的时间比显卡差价值钱得多。还有一个经常被忽略的问题是Windows的智能应用控制或SmartScreen拦截。本地推理程序经常要被杀毒软件或系统安全机制拦下来提示智能应用控制已阻止可能不安全的应用原因通常是推理程序不是签名应用、又是命令行工具容易被误判。解决方法是把这个程序目录加入信任区或关闭针对该目录的智能应用控制但注意不要盲目关闭整个系统的安全功能只放行你确认安全的推理目录即可。3. 微调实战把通用模型变成领域模型3.1 先确认要不要微调微调是大模型应用里被过度神化的一步。很多新手一上来就说要微调一个自己的大模型但实际上大多数业务场景压根用不到微调。什么时候应该先考虑提示词工程和上下文工程答案是任务定义清晰、输出格式固定、知识需求可以通过检索补充的时候。你可以先在Prompt里写清楚规则、给一两个示例如果效果已经很好那就没必要微调。只有在两种情况下才需要认真考虑微调一是模型本身的能力边界达不到任务要求比如专业文本理解、特定领域术语、特殊风格的模仿二是你希望模型稳定输出某种固定结构和风格而提示词怎么调都不稳。我自己的一个项目就是典型例子做一个医疗知识库问答系统刚开始想微调后来发现用RAG检索增强生成加提示词约束就解决了大部分问题真正需要微调的是非常窄的从化验单里抽取指定指标这种任务模型对生僻指标名总是识别不准微调之后准确率才明显提上来。所以微调不是必修课而是精准工具要用在刀刃上。3.2 微调的硬件、数据与参数如果确认要微调硬件和数据是两个先决条件。现在最常用的微调方式是LoRA低秩适配或QLoRA量化低秩适配原因是显存占用可控。LoRA只训练新增的小规模参数冻结原模型普通消费级显卡也能跑起来。举例来说7B模型用QLoRA在24GB显存下可以跑batch size为1或者2的微调14B模型也在24GB到32GB显存范围内可行。如果你只有8GB或12GB显存那最好选4B、7B级别的小模型。AMD的rx6750gre这种卡我不建议拿来训练虽然显存有12GB但生态支持太弱同样的配置在N卡上一天跑通的实验在A卡上可能要折腾一周。哪怕你的训练数据量不大我也推荐用云端GPU或租卡按小时付费比买卡划算太多。数据集是微调成功的核心没有之一。一般做任务微调几百到几千条高质量样本就够了关键是质不是量。我对数据集的清洗标准通常是每条数据都必须是你想要模型学到的真实输入输出宁可少而精不要多而杂同时必须覆盖边界情况和反面示例否则模型就只会套模板。数据格式上对话类任务用ChatML格式即带system、user、assistant标记的结构化对话最为通用。微调的超参数里比较重要的是学习率、epoch数和LoRA秩。常见起步配置是学习率1e-4到2e-4epoch数3到5LoRA秩8到32。不要一上来就搞rank 64甚至128秩越大不代表越好反而容易过拟合。还要记得给LoRA目标模块通常是注意力层的q_proj、v_proj设置正确的名字不同模型的模块命名不一样改错了就完全训练不起来。3.3 微调后的验证与部署微调完成后不能直接上线要先做效果验证。我的习惯是准备两类测试集一类是训练分布内的随机样本看模型有没有学会基本模式另一类是训练分布外的边界样本看模型有没有泛化能力。只看loss值没有意义loss降了不代表回答质量好一定要真正去看生成的文本质量。验证通过后LoRA权重要和基座模型合并导出再转成GGUF格式部署。我踩过的坑之一就是只保存了LoRA adapter部署时忘了合并加载模型后发现根本没有微调效果。正确做法是训练结束后先merge_and_unload把LoRA权重合回原模型再保存完整模型权重之后再做GGUF量化或者部署到Ollama。微调的另一个经典风险是灾难性遗忘——模型学会了新任务但把原本的通用能力忘了。缓解手段有几种在训练数据里混入一定比例的通用对话数据比如10%到20%、降低新任务的epoch数、在验证时同时测通用问答和领域任务的准确率。这个平衡问题在微调场景里几乎一定会遇到早做准备比事后补救强。4. 应用维度从AI应用到智能场景4.1 AI应用开发的整体路线模型选好、微调完成之后真正的考验才开始——怎么把它变成一个稳定可用的应用。AI应用开发和传统软件开发有一个很大的区别传统程序是输入-逻辑-输出逻辑是确定的AI应用是输入-模型推理-输出模型的行为有概率性所以应用层要做的工作更偏向于约束、纠错和兜底。一个完整的AI应用通常包含四层模型层、数据层、业务层、交互层。模型层负责推理能力数据层做RAG需要把知识库切分、向量化、存储检索业务层负责调用模型、解析结果、拼接业务逻辑交互层面向用户可能是聊天窗口、表单、API接口或者语音指令。从学习路线上来说我的建议是先学会调API感受模型的输出特性和提示词的威力然后学怎么把外部知识喂给模型RAG再学Agent与工具调用最后再碰微调。这个顺序最容易建立正反馈也最容易出成果。4.2 多端集成Android、桌面、小程序与鸿蒙应用落地绕不开端上的集成。现在比较常见的是云端API集成和端侧本地推理两种路径。Android端接云端API最省事直接HTTP请求或各家SDK如果要做端侧本地推理社区里最常见的方案是集成GGUF格式模型核心是把llama.cpp的Android端封装通过JNI融入App模型文件放在assets或者下载目录应用启动后预加载到内存。这一步的坑主要在JNI接口的编译llama.cpp的Android交叉编译如果版本不对很容易踩到NDK和ABI的坑。实际经验是直接用llama.cpp官方提供的Android构建脚本比自己折腾Makefile靠谱。桌面端的集成比较多样很多人做AI工具喜欢套一层Electron壳把后端推理服务跑在本地前端用Web技术做界面。Electron的好处是开发快、跨平台但坑是打包体积大、内存占用高。还有同事在做Electron应用移植鸿蒙我得说实话这条路并不好走因为鸿蒙的运行时是ArkTS体系Electron的Node层组件很多没法直接兼容与其硬塞进一个WebView容器不如评估一下把核心逻辑用ArkTS重写、通过鸿蒙的AI能力接口调用模型。过程更痛苦但后续维护更顺畅。小程序类应用也很常用。做uniapp的开发者应该深有体会上架安卓应用市场时隐私政策、权限声明、备案信息缺一不可尤其是涉及AI能力时部分应用市场会要求额外的算法备案或安全评估这个在项目排期时必须提前预留时间。我在审核环节被打回来三次每一次都是因为未说明AI生成内容的审核机制后来在应用内加了明显的AI生成内容标识才顺利过审。4.3 典型应用场景与RAG实战应用场景才是大模型价值真正落地的检验。我实际做过的和观察到的场景包括智能客服、知识库问答、代码生成与审查、办公文档处理、内容创作、多模态识别等。每一个场景都有对应的模型侧需求比如代码生成需要模型擅长结构化输出知识库问答需要长上下文和精准检索智能客服需要低延迟和高并发。在这些场景里RAG是绕不开的关键技术。RAG的基本思路分三步切分文档成小块、向量化存入向量数据库、检索相关块喂给模型生成答案。我觉得RAG体系里最常被低估的是切分这一步。很多团队直接用固定长度切文档效果很一般因为切块会把语义截断比如表格、代码、多级标题固定长度切分容易切在错误的地方。更好的做法是结构感知切分按段落、标题、表格边界来切再配合重叠策略。切块大小一定是根据场景调的比如合同问答的块可以稍大因为条款上下文紧密客服FAQ的块可以小一些方便精准命中。向量化模型的选择也直接影响检索效果。中文场景下用BGE这类专门的嵌入模型效果比通用模型的embedding好尤其是长尾词和专业术语。检索阶段做混合检索关键词检索向量检索再做一个重排能明显提高答案的准确性。这些细节叠加起来RAG系统的体感差距就拉开了。大模型的应用场景还不止于软件产品。车机导航领域模型可以做语音交互和目的地解析比如带我去最近充电站而且中途要经过便利店这种复杂语义传统规则引擎很难解析大模型就很自然。工业场景里模型用来做设备日志的异常诊断、维修知识问答也已经有很成熟的应用。这个维度随着模型能力增强还在持续拓宽。5. 常见问题与排查技巧实录5.1 运行环境与安装类问题AI应用开发中最常见的拦路虎其实是环境问题。安装Python管理器时碰到从python-manager-26.3.msix使用程序包安装失败这类错误其实本质上是Windows应用包签名或老版本冲突问题解决办法通常是把旧的Python版本完全卸载、手动清理%LOCALAPPDATA%\Microsoft\WindowsApps里残留的执行链路再用管理员权限重新安装基本能解决。如果还是不行就直接换非MSIX的安装包。另一个高频问题就是智能应用控制已阻止可能不安全的应用或阻止此应用的一部分。这个在大模型本地部署时出现频率很高因为很多推理工具是开源社区发布的exe没有商业签名。处理思路是先确认工具来源可靠比如从官方GitHub仓库下载然后在Windows安全中心的智能应用控制里把该目录加入排除项。不要图省事直接全局关闭保持系统对其他未知程序的安全防护还是必要的。还有同学问获取打开此ms-gamingoverlay链接的应用是什么情况。这其实跟大模型没关系是Windows的Game Bar相关链接协议没有注册应用导致的弹窗。但在做本地推理时如果这台机器装了Xbox Game Bar偶尔会和全屏GUI应用抢资源或弹提示。我是建议在做推理的机器上干脆关掉Game Bar和游戏覆盖层省得误导和干扰。5.2 部署与接口对接问题本地推理服务跑起来了接入应用时最容易有问题的是参数不匹配和并发控制。模型生成参数里温度、top_p、max_tokens这三个最常被调但这几个参数并不是越大越好。做客服场景温度建议0.3以下保证输出稳定做创意写作温度可以到0.8甚至更高多样性才有意义。max_tokens如果设太短长回答会被截断看起来像模型笨其实是参数没调好。并发控制也是部署端不得不面对的问题。GPU显存是有限的假设你的显卡跑7B量化模型的batch size上限是4那么并发超过4就必然排队或OOM。更合理的方案是在API服务层加一层队列或限流宁可让请求等待也不能让GPU直接崩掉。我有一次在客户现场演示时因为并发没控制住直接显存OOM整个演示全毁从那以后我任何部署环境第一件事就是确认并发上限。5.3 微调训练问题微调时的loss不下降或者剧烈震荡多数原因不是超参而是数据问题。最常见的三种情况数据里有大量重复样本导致模型在重复模式上过拟合训练集和验证集的分布不一致验证集loss奇高标签质量差模型学的是噪声。遇到loss问题我的第一反应永远是看数据而不是调参数。把训练集随机抽几十条出来人眼检查一遍往往原形毕露。显存不足也是微调的高频报错常见提示是CUDA out of memory。解决优先级一般是这样先把batch size降到1然后把gradient accumulation step设4到8损失不了太多效果再不行就用QLoRA的4bit量化比原模型省一半显存。如果这样还不行那就换小模型或者上云。大模型下载缓慢、连接不稳定也是部署群里每天都有人问的问题。国内访问Hugging Face经常超时解决办法是用国内镜像站把HF_ENDPOINT环境变量指到镜像地址或者直接从ModelScope下载权重速度稳定很多。这个细节在网上被反复提过但每次新手还是会卡在这一步所以我还是再写一遍。5.4 模型效果与安全问题排查有时候应用接好了模型回答的准确率却不理想。先别慌着换模型按这个顺序排查一遍先测提示词同样的输入用不同表述多试几次如果能靠提示词解决就说明模型能力够用再测RAG链路看检索回来的上下文对不对如果检索不到相关内容微调也救不回来最后才考虑微调。我见过太多团队跳步没有排查就直奔微调花了两周训完效果还是差最后发现是知识库压根没被正确检索到。内容安全方面也值得认真对待。大模型输出是不可完全预知的生产环境必须有输出过滤、敏感词检测和人工审核兜底。尤其面向C端的产品AI生成内容的标识和审核机制不只是合规要求也是保护用户和产品口碑的必要手段。我在应用里会加三层防护输入侧做意图过滤输出侧做内容安全分类重要场景再做人工复核。模型能力再强这道防线也不能省。6. 关于模型/应用维度的一些心得我把模型和应用分开理了一遍之后最大的感受是这个领域的节奏快到让人焦虑但底层方法论反而稳定。模型榜单每隔几个月就会翻新一遍应用形态从Chatbot卷到Agent再从Agent卷到端侧智能可落到工程层面无非还是选型、部署、调优、集成这四件事。把这四件事的套路吃透不管模型换了几轮你都能跟上节奏。我个人在实操中最深的体会是数据能力才是AI应用的核心竞争力。不管是RAG里的知识库治理还是微调里的数据集清洗最后决定体验天花板的永远是数据质量而不是你用了哪家的模型。把所有精力都花在追新模型上不如踏踏实实把数据管线建好。最后再分享一个我一直在用的小技巧每次引入一个新模型不要只测官方示例把你业务里最刁钻的50条真实输入整理成一个回归测试集每次换模型或调完参就跑一遍对比输出质量。这个习惯长期帮我避免了很多看起来换了新模型但实际更差了的尴尬。做AI应用这行稳定的基线比偶尔的惊喜重要得多工具和方法论都在变把基线维护好你就始终站在踏实的位置上。
