大模型本地部署实战：从工具选型、显存计算到生产级落地避坑指南

上周有个前同事来找我说他照着一篇教程在公司的台式机上装了Ollama十五分钟就拉下来一个7B模型兴奋得不行。结果第二天把接口接到内部系统里三个人同时用就开始转圈他跑过来问我是不是显卡买小了我说先别急着怪显卡。大模型本地部署在2026年已经不是稀奇事了随便搜一篇文章都能跑通但跑通和跑好是两码事。工具选型选错了再贵的卡也白搭量化方案选错了模型答非所问你会以为是它笨其实是你在部署环节就埋了雷。这篇文章算是我这几年做本地化部署的完整总结从到底要不要本地部署的账到Ollama、llama.cpp、vLLM、SGLang这些主流工具的优缺点对比再到显存怎么算、实操链路怎么走、踩坑怎么排尽量一次讲透。适合谁看个人玩家想在自己电脑上跑模型、中小企业技术负责人想把私有知识库和Agent落到内网、以及刚接触部署的AI应用开发同学。如果你只是想尝鲜看前两章就够了如果你想把它接到业务系统里建议全文看完再动手。1. 动手之前先算清三笔账隐私、成本和场景1.1 数据隐私本地部署不是可选项而是合规项很多人觉得本地部署的理由是省钱我在实际项目里看到的真实理由恰恰相反——绝大多数是数据出不去。医疗机构的病历数据、金融系统的交易流水、企业内部未公开的研发文档这些东西哪怕打上马赛克也不敢往云端API里发。调用云厂商的大模型API本质上是把文本数据交给了第三方服务就算对方承诺不用于训练合规审计这一关也过不去。2026年很多行业对数据出域的监管比前几年更细企业内部连打字到网页里都要审批更别提结构化地批量调用外部接口了。所以我的第一个建议是如果你的数据有保密要求本地部署不是技术选型问题是合规底线问题。这时候不用纠结该不该部署要纠结的只是用什么工具、怎么部署。1.2 算经济账本地部署到底贵不贵再说省钱这件事我得泼一盆冷水本地部署不是省钱神器甚至很多时候更贵。云API按token计费2026年的价格已经被卷到很低了。一个中等规模的模型日常批量调用一千次任务一年算下来可能就是几千块钱的事。但你买一张顶级显卡两万多起步加上机器、电源、散热、电费回本周期往往以年计。更别提模型更新换代你年初部署的模型年中可能就有新版本要不要再掏钱升级硬件那什么情况下本地部署才划算我把账拆开看调用量大且持续每天上万次推理调用云端API的token成本会明显高于硬件摊薄成本推理延迟敏感云端接口的网络往返和排队等待不可控本地部署可以稳定压低首token延迟数据进出量大比如要批量处理几十万份文档做离线分析先把数据传到云端再等结果网络带宽和存储成本都很难看。如果你只是每天偶尔问几个问题说真的用API体验更好别折腾本地部署。1.3 2026年还在本地部署的都是哪些人结合我接触过的项目和社区里的反馈2026年本地部署的用户画像大概分四类第一类是个人玩家。手上有一张消费级显卡跑Qwen或DeepSeek的蒸馏版模型用来做本地写作辅助、翻译、代码补全或者接一个Home Assistant做家庭智能中枢。这类人追求的是隐私和可玩性模型不用太大7B到14B就够。第二类是中小企业的技术负责人。他们的诉求很明确把私有知识库、内部工单系统、客服助手接到一个本地大模型上流程用Dify这类编排工具串起来模型藏在内网数据不出机房。这类部署对稳定性和并发有一定要求通常会用vLLMSGLang配合Dify。第三类是边缘计算和硬件厂商。在Jetson Orin这类嵌入式设备上部署端侧模型做检测、OCR、离线语音交互功耗和体积是核心约束。第四类是科研和微调团队。他们对模型权重有完全掌控的需求要能反复加载、训练、导出甚至要自己改推理代码本地部署是实验环境的一部分。如果你不属于任何一类只是想给电脑装上AI那我劝你先别装了容易三分钟热度。2. 工具选型硬核对比六大方案挨个过堂2.1 Ollama入门神器的真实上限Ollama是现在绝大多数人本地部署的起点原因很简单一条命令装好一条命令下载模型跑起来就是一个OpenAI兼容的本地API。它对新手极度友好内置了llama.cpp的推理引擎GGUF模型格式也是社区最流行的。但它的边界必须说清楚。Ollama的设计目标是个人桌面跑模型不是生产服务扛并发。它的服务端对并发请求的处理方式是排队模型默认情况下一个模型实例同时只能处理有限请求多出来的请求只能排队等待。我用4090跑7B INT4模型实测单人使用非常好生成速度能到每秒90到120个token但并发拉到4个以上队列延迟会明显上升体验断崖式下降。另外Ollama的高级配置藏得比较深靠环境变量控制比如OLLAMA_NUM_PARALLEL可以调并行请求数OLLAMA_MAX_LOADED_MODELS控制常驻模型数量。如果你只是自己用默认配置就够了如果你想给团队用建议先做好压力测试。我的结论Ollama适合个人电脑、原型验证、以及并发不超过3到5的内部小范围使用。别一上来就指望它是生产环境。2.2 llama.cpp / llama-server极客和旧硬件的救星llama.cpp是这个领域的老祖宗最初的目标就是让大模型在普通CPU上跑起来它定义了GGUF格式也是各种量化方案的底层实现。到今天它依然是轻量级部署的首选引擎。它的优势有三点一是单二进制文件没有Python依赖没有Docker也能跑二是CPU和GPU混合推理做得极好显存不够时可以把一部分层放到内存虽然慢但不崩三是量化支持最完善K-quants系列量化格式Q4_K_M、Q5_K_M、Q8_0等就是它家生态标准。llama-server是llama.cpp自带的HTTP服务端启动方式非常直白llama-server -m /models/qwen3-14b-q4_k_m.gguf \ --host 0.0.0.0 --port 8080 \ --n-gpu-layers 99 \ -c 8192-c是上下文长度--n-gpu-layers控制把多少层放到GPU。如果你显卡显存不够把层数调小剩下的层跑CPU速度慢一点但不至于跑不起来。它的短板也很明显没有模型管理生态下载模型、更新版本都得自己来服务化能力弱没有vLLM那套连续批处理机制高并发撑不住。所以它适合的场景是老旧机器、CPU推理、嵌入式设备或者你想搞清楚底层原理自己折腾的情况。2.3 vLLM生产环境吞吐担当如果你的目标是给多人提供稳定的API服务vLLM几乎是绕不开的选项。它的核心是PagedAttention和Continuous Batching两个技术PagedAttention把KV Cache像操作系统的虚拟内存一样分页管理显存利用率大幅提升Continuous Batching让不同请求可以在同一个批次里动态进出吞吐量比朴素实现高出好几倍。vLLM的启动方式通常是这样docker run --gpus all \ -v /models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen3-32B-Instruct \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1几个关键参数我要重点说--max-model-len是上下文上限直接影响显存占用--gpu-memory-utilization控制模型最多吃多少显存留一点给系统以免OOM--tensor-parallel-size是多卡并行时用的单卡写1。vLLM对OpenAI接口的兼容性是最好的这意味着你原来写的OpenAI SDK代码几乎可以原样改个base_url就能连上。它的缺点是配置项多显存管理策略偏激进预分配对不熟悉的人来说上手门槛比Ollama高不少。量化支持早期很弱近两年才逐渐完善。2.4 SGLang前缀缓存和新架构激进派SGLang是这两年成长最快的新锐推理框架最大的卖点是RadixAttention前缀缓存。通俗讲如果你的使用场景里大量请求共享同样的前置上下文——比如RAG场景中所有问题都先拼接同一段知识库内容或者Agent场景里多轮对话反复携带系统提示词——SGLang会把这段公共前缀的KV Cache缓存复用起来首token延迟能降一大截。同样的场景放在vLLM里因为前缀没有专门优化每次都要重新算一遍。实际对比数据我记得很清楚同样在A100上跑一个14B模型RAG场景下SGLang的请求吞吐量能比vLLM高30%到50%首token延迟优势更明显。如果你的核心应用是知识库问答或者Agent工作流SGLang值得重点考虑。它的缺点是文档更新太快版本迭代激进很多配置参数在不同版本里变来变去踩坑了得去GitHub翻issue。团队如果没有一定技术能力建议谨慎跟进。2.5 Dify / Open WebUI应用层不能缺的那块拼图很多人部署完模型就卡住了模型跑起来了但怎么用命令行敲太原始浏览器页面没有更别提做知识库和Agent了。这时候需要应用层工具。Open WebUI是开箱即用的Web界面长得像ChatGPT支持多用户、聊天记录、文档上传支持对接Ollama和OpenAI兼容API。个人或小团队部署一个体验立刻提升一个档次。Dify则更进一步它不只是一个聊天界面而是把模型接入、知识库、工作流、Agent编排、API发布串成一整条链。2026年做企业私有化AI应用Dify基本是标配选择。它支持配置任意OpenAI兼容的模型API你把本地部署的vLLM地址填进去就能在Dify里搭一个带知识库的客服机器人。我的建议是部署模型是第一步但大部分人真正要的其实是一个能用的应用。工具链要不要配齐直接决定项目最后是demo还是产品。2.6 一张选型表三分钟定方向工具核心定位上手难度并发能力显存策略适合谁我的推荐Ollama个人/桌面/原型极低弱常驻加载新手、个人玩家入门首选llama.cpp轻量/CPU/边缘中弱到中按需分配老机器、嵌入式有基础再上vLLM生产API服务中高强预分配团队、服务器生产主力SGLang高性能API服务高强预分配RAG/Agent高并发高端进阶Open WebUIWeb界面低取决于后端—个人/小团队加上它Dify应用编排平台中取决于后端—企业知识库/Agent企业标配选型逻辑很直接先看你是个人还是团队再看你是要demo还是要生产。个人和demo选Ollama团队和生产直接上vLLMRAG和Agent场景多就认真考虑SGLang界面和应用层用Open WebUI和Dify补齐。3. 显存算账先搞清楚你的机器上限在哪3.1 模型权重占用速算法在做任何部署之前先算显存。计算方法很简单模型参数量乘以每个参数占用的字节数。FP16半精度每个参数2字节INT8量化每个参数1字节INT4量化GGUF Q4系列每个参数约0.5到0.6字节举例说明模型规模FP16INT8INT4Q4_K_M7B/8B14~16GB7~8GB4~5GB13B/14B26~28GB13~14GB7~8GB32B60~64GB30~32GB17~20GB70B130~140GB65~70GB35~40GB注意这只是权重本身的占用推理时还有KV Cache、激活值、临时缓冲区等额外开销所以实际显存需求建议在这个基础上再预留20%到30%。以7B FP16为例理论权重14GB跑起来通常要17GB到18GB才稳。3.2 KV Cache是隐形大头KV Cache是很多人部署翻车的第一原因因为它不随模型固定而是随你的输入上下文长度线性增长。计算公式大致是每token的KV Cache显存 2 × 层数 × KV头数 × 头维度 × 每元素字节数。拿常见13B模型举例假设32层、8个KV头GQA分组查询注意力、头维度128、FP16存储每token占用 2 × 32 × 8 × 128 × 2字节 131072字节也就是128KB。上下文长度4K时KV Cache约512MB上下文拉到32K时直接变成4GB。一个7B模型FP16权重才14GBKV Cache就可能吃掉4GB这还没算激活值。所以为什么我一直强调别盲目开长上下文你开32K上下文等于变相把模型换成了一个大一号的版本。选模型的时候注意看它是否用了GQA。GQA能显著减少KV头数量把KV Cache压到原来的几分之一这也是为什么现在的开源模型几乎都标配GQA。3.3 显卡、Apple Silicon、Jetson Orin分别能跑到哪一步以2026年的主流硬件我按路线整理一下NVIDIA消费级显卡路线RTX 4090 24GB跑7B INT4非常轻松14B INT4也能流畅32B INT4勉强能跑但上下文得压到4K以内生成速度会降到每秒20到30个token体验一般。RTX 5090 32GB比4090多了8GB显存和更高带宽32B INT4可以稳定使用14B FP16也能直接跑是目前个人部署甜点级硬件。多卡方案两张24GB卡拼起来跑70B INT4是可行的但要注意多卡推理有PCIe通信开销速度比单卡下降不少不是所有模型都能线性扩展。Apple Silicon路线 M系列统一内存架构让显存很大M系列顶配128GB甚至192GB内存都能给GPU用跑70B量化模型是真实可行的。但瓶颈在内存带宽M系列跑大模型的实际速度取决于带宽而不是核心数量。128GB内存的机器跑70B Q4生成速度大约每秒15到25个token能接受但称不上快。好处是功耗低、安静、一体机适合个人工作室。Jetson Orin路线 Orin NX和AGX是边缘部署的主流选择。AGX 64GB版本可以跑14B INT4模型功耗控制在几十瓦适合车载、巡检机器人、离线语音交互这类场景。它的推理引擎是TensorRT-LLM性能优化很好但配置复杂需要专门学习。3.4 CPU纯跑速度换空间的备选路线没有GPU就别部署了吗也不一定。llama.cpp让纯CPU跑模型成为可能关键是内存要够。32GB内存跑7B INT4大约每秒2到4个token看文本还能忍对话会显得很迟钝64GB内存跑14B INT4速度更慢每秒1到2个token。这种速度能做什么批量离线分析、文本分类、翻译任务可以因为不要求实时交互。或者说你只是想在服务器上验证一个模型效果不打算给人用CPU路线也可以。如果非要CPU实时对话建议选4B或更小的模型Q4量化后占用不到3GB内存速度能到每秒8到12个token勉强能聊天。4. 从下载到上线一条完整的本地部署实操链路4.1 环境准备驱动和容器检查不管你选哪条路线第一步永远是检查环境。NVIDIA显卡先确认驱动和CUDA可用nvidia-smi看到显卡型号和驱动版本就OK。注意nvidia-smi显示的CUDA Version只是驱动支持的版本不代表容器里的CUDA版本别搞混。接下来建议直接用Docker统一环境比在宿主机上堆Python依赖省心太多。确认Docker能调用GPUdocker run --rm --gpus all nvidia/cuda:12.4-base-ubuntu22.04 nvidia-smi能输出显卡信息就说明容器GPU环境正常。这一步如果过不了后面全卡住先排查NVIDIA Container Toolkit装没装。4.2 选模型和量化别下载回来才发现不对模型选择上2026年我日常推荐几款通用对话和写作选Qwen系列的中小尺寸比如8B、14B或32B代码能力可以看DeepSeek系蒸馏模型需要特定领域能力再看社区微调版。下载渠道优先走两条Ollama模型库适合个人快速拉取一条命令搞定ModelScope这类国内模型社区适合下载完整模型文件做精细化部署我用它比较多因为国内访问稳定且模型版本权威下载体验好。GGUF文件后缀里那串字符要认识后缀含义我的选型建议Q4_K_M4bit混合量化质量和体积的平衡点显存紧张首选Q5_K_M5bit量化质量接近未量化显存够就选它Q8_08bit量化质量几乎无损精度敏感场景F16半精度原版显存非常充裕时一个容易踩的坑同一个模型有Instruct版、Base版、Chat版之分。日常对话和API服务选Instruct版它经过指令微调会听话Base版是预训练底座只会续写不会对话。看到模型名不带Instruct就直接拿来聊天的人不在少数然后吐槽模型太笨了。4.3 启动推理服务Ollama和vLLM两条路线个人路线Ollama拉取并启动ollama pull qwen3:14b ollama run qwen3:14bollama run进入交互对话确认效果没问题后让它作为后台服务常驻ollama serve服务默认监听11434端口OpenAI兼容接口是http://localhost:11434/v1。团队路线vLLM启动docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen3-14B-Instruct \ --max-model-len 16384 \ --gpu-memory-utilization 0.9启动日志里看到Starting vLLM server和Uvicorn监听8000端口的输出就说明服务起来了。第一次启动会加载模型权重7B模型大概要等几十秒到一两分钟别以为卡死了。4.4 验证接口并接入Open WebUI/Dify服务启动后用一条curl验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/Qwen3-14B-Instruct, messages: [{role: user, content: 你好介绍一下你自己}], max_tokens: 256 }能正常返回内容接口就通了。接下来两种接法接Open WebUI用Docker一条命令docker run -d -p 3000:8080 \ -e OPENAI_API_BASE_URLhttp://host.docker.internal:8000/v1 \ -e OPENAI_API_KEYempty \ ghcr.io/open-webui/open-webui:main浏览器打开3000端口就能在一个类ChatGPT界面里和你的本地模型对话了。接Dify进入控制台的模型供应商页面填一个OpenAI API兼容的供应商配置把API Base地址填成http://vllm-container-ip:8000/v1API Key随便填一个占位符就行。之后就能在Dify里创建知识库、搭Agent工作流了。这一步做完本地大模型就不再是命令行玩具而是一个可以被业务系统调用的真正服务了。5. 部署后必踩的坑OOM、上下文爆炸与并发卡死5.1 显存OOM的完整排查链路本地部署翻车率最高的问题就是CUDA out of memory。我见过太多人第一反应是模型太大了换小模型但真正常见的原因是配置不当。排查顺序应该是这样的第一步看显存到底被谁吃了nvidia-smi重点看两个数Memory-Usage和Processes那一栏到底哪个进程占显存。很多人本地跑着好几个模型常驻新模型加载时自然OOM。第二步看模型权重加KV Cache是不是超了。我前面给的速算法在这里用得上确认权重占用、计算上下文长度对应的KV Cache、再加上20%余量三项加起来对比你的显存总量。第三步调整参数而不是换模型vLLM的--gpu-memory-utilization从0.9降到0.7强行留出缓冲把--max-model-len从32768降到8192显存立刻释放几个GB把量化从Q8降到Q4权重直接减半。我经历过的典型案例一台4090跑14B INT4模型权重8GB看起来24GB显存很充裕但我把上下文开到了32KKV Cache吃掉近10GB再加激活值和CUDA context开销直接OOM。把上下文降到8K之后显存占用只有13GB左右稳如老狗。所以遇到OOM先动上下文这是最容易被忽视但最有效的解法。5.2 上下文长度不是想开多大就多大很多人有一个误解模型宣称支持128K上下文我就应该开128K。理论上没错但物理上要看显存和速度。前面算过KV Cache的账长上下文直接吃显存。更麻烦的是上下文越长推理速度越慢。因为生成每个token时模型都要重新计算和读取前面所有token的KV Cache。32K上下文比4K上下文慢不是一点半点是好几倍。我的经验数值在4090上跑7B INT44K上下文时每秒能到100个token拉到32K上下文下降到每秒40左右显存占用还多了几个GB。如果你只是日常聊天8K绰绰有余RAG场景建议先评估单次请求最长大概多少token留20%余量就够了。另外一个实用技巧如果主流场景用不到长上下文在--max-model-len或Ollama的OLLAMA_CONTEXT_LENGTH里把它写成实际需要值而不是模型支持的最大值。这样等于把显存和速度都省下来了。5.3 并发上不去先分清瓶颈在哪并发问题有三个常见表现对应三种根因第一种表现并发一高请求排长队但显存还有富余。这往往是Ollama的串行处理导致的。解决方向一个是调OLLAMA_NUM_PARALLEL增加并行数另一个是干脆换vLLM它天生为并发设计。第二种表现并发一高直接OOM。这是并行请求各自分配KV Cache导致的显存被多个请求的上下文瓜分。解决方向是限制并发数或减小单请求上下文长度。第三种表现显存没满并发也上去了但每个请求都慢。这是算力瓶颈说明GPU计算资源已经饱和加并发解决不了问题只能换更强的卡或更小的模型。怎么快速判断是哪种先看nvidia-smi的GPU-Util如果跑满100%说明算力饱和再看显存占用如果接近上限说明是显存瓶颈如果两项都没满但请求还是排队就是服务端软件层面的并发机制限制。vLLM里几个并发相关参数值得记一下--max-num-seqs控制单批次最多处理多少请求默认通常256实际受显存约束--max-num-batched-tokens限制单批次总token数这两个参数要和上下文长度一起调不能单独拉满。5.4 量化质量损失INT4到底行不行量化是省显存的法宝但省下来的显存是有代价的。INT4量化会把每个权重压缩到4bit左右这期间必然有精度损失。问题在于损失多大以及你的场景能不能忍。先说原理。量化相当于把连续的高精度数值映射到离散的低精度阶梯上。模型权重里大多数值分布在一个比较窄的范围内但存在少量极端离群值这些离群值对模型能力影响很大。Q4_K_M这类K-quants量化方案专门处理了离群值分布问题用混合精度策略把重要的行、列保留更高精度所以整体质量比早期朴素4bit量化好很多。我的实际体感日常对话、文本总结、翻译这类生成任务7B模型Q4_K_M和Q8_0的差距几乎感觉不出来偶尔有措辞差异但数学推理、代码生成、长文档精确提取这类任务Q4的失误率会明显上升。比如让模型从合同里提取特定条款Q4可能出现遗漏或幻觉换Q8就稳定很多。所以我的原则是显存允许就上Q8显存紧张用Q4_K_M但凡是精度敏感的任务都要在正式上线前对一批测试集做人工或自动评估别想当然。最稳的做法是同一个模型下载Q4和Q8两个版本关键场景跑一遍对比成本不高效果直观。6. 部署只是起点微调、多模态与收尾建议6.1 从本地部署走向本地微调部署解决的是能不能用微调解决的是合不合用。一个通用模型拿来做特定行业任务效果往往停留在能用但不够好这时候就该考虑微调了。2026年的微调框架选型我推荐优先看LLaMA-Factory。它支持LoRA、QLoRA、全参微调多种模式Web界面操作对数据和训练目标有图形化配置新手也能一周内跑通。技术团队如果不喜欢图形界面可以用Axolotl或Transformers TRL走脚本路线。硬件上有个认知要纠正微调比推理吃显存得多。因为训练时除了权重还要保存梯度和优化器状态。LoRA是突破口它只训练少量低秩适配参数显存需求大幅下降。QLoRA更进一步把基础模型以4bit加载24GB显存就能微调14B模型这对个人用户是重大利好。一个最小可用的微调流程是这样准备几百到几千条任务数据格式是问题-答案或输入-输出在LLaMA-Factory里加载模型、挂LoRA、设置学习率和训练轮数训练完导出LoRA权重再合并回基础模型最后把合并后的模型部署回vLLM或Ollama。这套链路我跑过很多次最大的经验是数据质量远比数据量重要几百条高质量样本的效果经常超过几万条噪音数据。6.2 多模态模型本地部署的三个特殊点2026年本地部署早就不仅限于纯文本模型了。视觉语言模型、语音识别、文生图都已经能跑在消费级硬件上但多模态部署有三个特殊点容易踩坑。第一显存占用更大。视觉模型除了文本token还要处理图像token一张图会被切分成几百个patch每个patch都要走一遍模型层KV Cache占用暴涨。同样参数规模的视觉模型实际显存需求比纯文本高30%到50%。第二推理链路更长。真实项目里很少只跑一个模型往往是语音识别模型把音频转成文字再送大模型理解最后走语音合成输出。多个模型串联意味着显存要同时分配给好几个模型调度复杂度上来了很容易出现内存碎片化问题。第三框架支持度差异大。vLLM和SGLang对视觉模型的支持在近两年已经成熟但如果用的冷门模型不能直接跑就得回退到Transformers原生推理性能损失明显。选模型之前先查目标框架的官方文档确认支持列表比买回来再折腾强多了。我的建议是多模态项目第一次跑通时务必先把每个子模型单独验证一遍再串联否则出了问题你根本不知道是哪一个环节崩的。6.3 我最后想说的几句大实话做了这么多年部署我最深的体会是部署不是一锤子买卖而是一套需要持续维护的基础设施。模型会更新量化方案会改进推理框架版本迭代飞快。你今年部署的Ollama配置明年可能就有更好的默认参数你今天用的vLLM镜像过几个月就要升级。所以从第一天开始就把模型文件目录、推理服务的启动脚本、显存监控命令整理成文档是非常值得的投资。还有一件事建立基线。把模型的响应延迟、显存占用、测试集准确率记录下来每次升级模型或改参数前先看基线改完对比基线才能知道改动是变好还是变坏。我见过很多人靠感觉调参调完也不知道自己改了什么、效果如何全凭玄学。最后分享一个实操建议先跑小模型再上大模型。不论你的目标最终是70B还是更大第一步都先用一个7B或8B模型把全链路跑通——下载、部署、接界面、接业务API、做监控。小模型跑通了换成大模型只是换一个文件和几个参数的事小模型都跑不通大模型只会更让你崩溃。这条路径我推荐给所有来找我问部署的人基本没翻过车。