1. 场景不是口号从100个实战案例看企业AI需求的真实分布先交代一个背景。我这两年一直在做一件事把企业级AI落地的案例攒成库从制造、金融、教育、零售到医疗陆续整理了100个真实场景每次交付完项目就把需求、方案、踩坑记录沉淀下来。这个过程中被问得最多的问题不是技术怎么实现而是AI大模型到底能干什么——或者说老板给了个模糊方向技术负责人不知道从哪下手。我一开始也以为企业AI的难点在模型效果上后来发现真正卡脖子的地方在场景定义。同一个Qwen、DeepSeek或者GLM用在不同场景里架构选型、推理延迟、数据回流方式完全是不同的。这100个场景跑下来我把它们归成了三类后面聊的几乎所有技术选型都在围绕这三类展开。1.1 三类典型场景知识密集、流程密集、端侧密集第一类是知识密集型占比最高大概一半。典型形态是智能客服、企业内部知识库问答、文档审阅助手、合规风控辅助。这类场景的核心特征是数据以非结构化文本为主用户问题开放答案质量依赖模型对上下文的组织能力。难点不在能不能答在于“答得稳不稳、出错了怎么办、答案能不能溯源”。第二类是流程密集型占三成左右。典型形态是工单自动分类、合同条款抽取、发票信息结构化、供应链预测辅助决策。这类场景要求模型输出的格式极其严格经常要对接下游业务系统比如直接把抽取结果写进ERP或者CRM。真正的问题不是模型聪明不聪明而是你的解析层能不能把模型输出稳定转成结构化数据。第三类是端侧密集占两成但增长最快。典型形态是移动端的离线翻译、会议实时转写摘要、IoT设备上的异常检测、摄像头边缘侧的文字识别。这类场景有一个共同约束不能把数据传到云端或者网络环境不可靠。于是模型得跑在用户的手机上或者边缘设备里这就直接引出了本地部署和端侧集成的话题。1.2 场景驱动选型的决策链路我是个非常反对先选模型再找场景的人。很多团队上来就问我GPT和Claude哪个好我说你先告诉我你的场景属于哪一类。梳理了这么多案例之后我把决策链路固定成了四步定义场景的输入输出形态——输入是文本、图片还是传感器数据输出是自由文本、分类标签还是结构化字段确定延迟和可用性红线——客服场景可以接受两秒首字延迟工业质检的实时识别窗口可能只给300毫秒这决定了你到底该用云端大模型还是端侧小模型评估数据的出域约束——客户数据能不能上公有云决定了你只能做本地部署还是要租专有云环境算成本边界——按Token付费的API方案和一次性买GPU服务器的本地部署方案两年总拥有成本可能差出一个数量级。这个链路我在每一个案例里都套用过非常管用。比如有一个能源行业的案例客户要做一个设备故障诊断问答系统原始想法是接公有云大模型API后来一问现场数据有严格的出域限制最后改成在客户内网用两台工作站部署了量化版的13B模型推理质量虽然没有云端大模型那么高但满足了合规要求项目才真正落地。2. 本地部署的第一道选择题模型格式、量化粒度与硬件预算本地部署AI大模型是这100个场景里被问得最频繁的话题之一尤其是最近半年关注度直线上升。但很多第一次做本地部署的人一上来就被一堆概念搞晕GGUF是什么Q4_K_M和Q8_0差多少7B模型到底要多大显存。这一节我就把这些问题一次性讲清楚。2.1 GGUF为什么成了本地部署的事实标准首先要理解一个背景模型训练和模型推理用的格式不一样。训练出来的原始权重是FP16或者BF16的一个7B模型光权重就有14GB左右如果带KV Cache跑起来的内存占用直奔20GB。这在服务器上勉强能接受到了普通人的电脑上根本跑不动。于是就有了量化这个思路——把权重从16位浮点数压缩到8位、4位甚至更低。而GGUF就是目前本地部署生态里最主流的量化封装格式。它由llama.cpp项目推动把模型权重、分词器、超参数、注意力结构信息全部打包进一个文件里好处是部署极其简单——你不需要额外准备配置文件也不用担心版本不匹配一个文件拷过去就能跑。我建议所有入门本地部署的人第一步就是去找对应模型的GGUF版本而不是去Hugging Face下载原始权重再自己量化。自己量化不是不行但需要处理校准数据集、评估量化误差属于进阶操作新手阶段完全没必要。2.2 量化等级怎么选效果和资源的平衡点GGUF文件名里的Q4_K_M、Q5_K_S、Q8_0这些标记代表的是不同的量化策略。我整理了一个常见量化等级的对照表这是我实际部署时反复参考的量化标记含义平均bit数/权重7B模型近似体积效果损耗Q4_K_M4位量化中等尺寸4.5~4.8约4.1GB较小适合大多数场景Q5_K_M5位量化中等尺寸5.3~5.5约4.8GB很小推荐首选Q6_K6位量化6.0~6.2约5.4GB极小Q8_08位线性量化8.0~8.5约7.2GB几乎无损F16半精度原始权重16约14GB无损实际使用中我的经验是如果你显存在6GB以下选Q4_K_M是最稳妥的方案速度和效果都还能兼顾如果显存在8GB以上直接上Q5_K_M效果肉眼可见地好一点显存超过12GB可以考虑Q6_K甚至Q8_0但这已经不是本地部署的主流场景了。2.3 按参数规模估算硬件配置很多朋友拿着一台16GB内存的笔记本问我能不能本地跑7B模型我通常的回答是能跑但很勉强。这里有一个简单的估算公式7B模型Q5量化后权重约5GB推理时的KV Cache保守按3GB算加上操作系统和程序开销最少需要16GB内存才能跑得流畅。如果是13B模型Q5量化权重约8GB加上KV Cache建议直接上32GB内存。如果是服务器场景显存的计算逻辑是类似的。我最近帮一个制造业客户做的私有化部署选型是13B模型配一张24GB显存的显卡Q5量化后权重8GB留给KV Cache和上下文的显存还很充裕128并发请求下首字延迟稳定在1.5秒以内整体体验已经接近云端API的效果。2.4 部署完之后的验证清单本地部署不是模型能加载出来就算完事我每次都按一个固定清单做验证连续对话50轮以上确认上下文窗口的内存不会无限增长上传一份该行业的真实文档做知识问答确认回答不会胡说八道幻觉问题用并发工具模拟10个用户同时访问看首字延迟和显存峰值的波动检查日志里有没有异常token输出或者推理线程崩溃。之前有个案例模型加载正常、单轮对话也正常但一进入多轮对话就内存溢出。排查后发现是上下文窗口设置过大、KV Cache预留不足。所以本地部署不是能跑就行一定要做完整的验证否则上线后出问题你都不知道从哪查起。3. SSE流式输出让大模型回答逐字出现的工程实现说完了模型部署接下来是100个场景里另一个高频硬需求怎么把大模型的回答实时渲染到用户界面上。用过ChatGPT的都知道答案是逐字蹦出来的而不是等半天一次性出全文。这个体验背后就是SSEServer-Sent Events技术。很多第一次做大模型应用开发的同事在这里踩了坑。这次我把完整实现拆开讲。3.1 为什么选SSE而不是轮询或者WebSocket大模型推理有一个显著特点生成第一个token需要的时间比较长但后续每个token的生成速度很快。如果用传统的轮询方式前端每隔几秒问一次后端好了没不仅浪费网络请求体感也差。用WebSocket当然可行但WebSocket是双向通信对于AI对话这个场景有点大材小用而且服务端需要维护长连接状态复杂度高不少。SSE的精髓在于它是纯单向的服务器推送前端只需要用一个HTTP连接就能持续收到数据流。大模型服务端的输出天然是token一个一个来的SSE天然匹配这个形态实现起来比WebSocket简单得多还天然支持HTTP的缓存、代理和重试机制。所以我用了快两年SSE在AI应用层从未换过方案。3.2 后端封装一个基于FastAPI的实现示例我平时常用Python做AI服务层FastAPI配合SSE非常顺手。核心思路是后端拿到用户的输入prompt之后调用大模型的流式接口然后逐段把结果通过SSE推给前端。我贴一段核心代码from fastapi import FastAPI from fastapi.responses import StreamingResponse from llm_client import chat_stream app FastAPI() app.post(/v1/chat) async def chat(request: dict): prompt request.get(prompt, ) conversation_id request.get(conversation_id, ) # 生成器每次产出SSE格式的数据 def event_generator(): # 先给一个会话开始事件 yield fevent: conversation_created\ndata: {conversation_id}\n\n # 从大模型流式获取token async for token in chat_stream(prompt, conversation_id): # 注意SSE的数据格式data: 开头两个换行结尾 yield fdata: {token}\n\n # 结束标记 yield data: [DONE]\n\n return StreamingResponse( event_generator(), media_typetext/event-stream, headers{Cache-Control: no-cache, X-Accel-Buffering: no} )这里面有几个细节我要特别强调。第一media_type必须是text/event-stream这是浏览器识别SSE的硬标准。第二那个X-Accel-Buffering: no极其重要如果你用Nginx做反向代理默认会缓冲整个响应体再发给客户端那流式就变成了一次性输出前端再也等不到逐字渲染的效果。第三每个事件之间要用空行分隔这是SSE协议的格式要求。3.3 前端处理EventStream与AbortController中断控制后端推过来了前端怎么接如果把SSE当作普通的Ajax请求用浏览器原生Fetch你会发现一个问题Fetch的response.text()会等所有数据到齐才返回根本拿不到中间状态。所以必须用response.body.getReader()逐块读取或者直接使用EventSource接口。但EventSource不支持自定义Header比如鉴权token这时候要么用URL参数带token要么就和我一样直接基于Fetch手动解析流。前端核心代码我写了一个可复用的封装模块关键逻辑如下async function fetchSSE(url, options {}) { // AbortController用于中断请求比如用户点击停止生成 const controller new AbortController(); const response await fetch(url, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${options.token} }, body: JSON.stringify(options.body), signal: controller.signal }); if (!response.ok) throw new Error(HTTP ${response.status}); const reader response.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); // SSE事件以 \n\n 分隔按分隔符逐个解析 const events buffer.split(\n\n); buffer events.pop(); for (const event of events) { if (!event.startsWith(data:)) continue; const data event.slice(5).trim(); if (data [DONE]) return controller; try { const json JSON.parse(data); options.onMessage?.(json); // 收到token后的回调 } catch (e) { console.error(解析SSE数据失败, e); } } } return controller; } // 使用时 const controller await fetchSSE(/v1/chat, { token: xxx, body: { prompt: 你好, conversation_id: 123 }, onMessage: (data) { renderToken(data.content); // 把增量token渲染到页面 } }); // 用户在界面上点停止 document.getElementById(stopBtn).onclick () controller.abort();这里面最容易被忽略的是AbortController。我的经验是任何带停止生成按钮的AI界面都必须在请求创建时把controller保留下来因为浏览器Fetch接口在中断之后不会自动做任何清理如果你不做abort后端可能还在继续生成token、白白消耗资源。3.4 流式输出踩坑记录最后集中说几个我实战中遇到过的坑按照踩坑频率排序代理层缓冲这是最大的坑。从Nginx到Cloudflare再到各种API网关默认都做响应缓冲。请务必在网络链路每一层都关闭缓冲。Nginx关法我已经写在上面的Header里了。乱码和断字中文字符是多字节的网络流边界可能把一个汉字拆成两半。所以一定要用TextDecoder并开启{stream: true}同时维护一个buffer解析完的事件从buffer中移除。我一开始没这么干直接按块decode结果经常出现半个汉字变成乱码。心跳保活SSE默认连接空闲一定时间后某些超级代理会把连接回收。解决办法是让后端每隔15秒发一个注释行: heartbeat\n\n前端可以忽略这类事件。我之前没做心跳结果长内容回答到一半连接被网关掐断了。异常中断的用户体验如果生成过程中断用户界面应该明确展示生成已中断而不是让光标一直闪烁。我在每个项目的前端状态管理里都会加一个sseStatus字段取值是pending/streaming/done/aborted/error这样前端可以针对不同状态做不同的UI反馈。4. Android端集成GGUF端侧推理的选型与性能调优前面提到的场景分类里端侧密集是增长最快的部分。而安卓端集成GGUF模型则是这块里最具体的需求。经常有人拿着android app集成ai大模型gguf来问这节就把选型、集成、调优一次性讲透。4.1 端侧跟云端不是二选一而是协作关系先说一个原则性问题端侧推理不是为了替代云端而是为了让那些不能上云的场景能有AI能力。比如工业企业外勤人员的离线巡检、银行客户经理在偏远地区的贷款资料初审这类场景要么网络不稳定要么数据敏感要么流量成本高。我实际处理过的一个案例是某零售连锁企业的门店盘点助手。门店网络经常断但盘点需要拍照识别货架商品如果等网络恢复再传云端识别一趟盘点要拖两小时。后来方案改成端侧跑一个小模型做初步识别只把置信度低的结果上传云端复核盘点时间压缩到四十分钟。这个案例让我确定了一件事端侧集成不是为了炫技是为了解决真实的环境约束。4.2 llama.cpp在Android端的接入步骤Android端跑GGUF模型最成熟的底层方案就是llama.cpp它提供了Android平台的编译产物和Java/Kotlin绑定。我建议的接入方式是使用社区维护的llama.cpp-android项目集成步骤大致如下第一步在build.gradle中添加依赖把llama.cpp编译好的so库和Java类引入项目。dependencies { implementation com.github.ggerganov:llama.cpp:master-SNAPSHOT }如果你的项目对包大小敏感也可以自己用NDK编译精简版so库。不过默认的编译产物已经做了架构区分armeabi-v7a、arm64-v8a只保留arm64-v8a能大幅减小APK体积。第二步把量化好的GGUF模型文件放到assets/models/目录或者首次启动时从服务器下载。我强烈建议大模型文件不要打进APK里应用商店对包体积有严格限制50MB以上的安装包转化率会明显下降。正确做法是首次进入功能页时像下载地图包一样增量拉取。第三步初始化模型并加载对话。Kotlin代码的核心逻辑如下// 加载模型注意这里的参数决定显存占用 val model LlamaModel( context, LlamaModel.LoadParams( modelPath absolutePathToModel, nCtx 4096, // 上下文长度 nGpuLayers 1, // 使用GPU加速的层数0表示纯CPU nThreads 4 // 推理线程数 ) ) // 执行对话获取流式输出 val result model.complete( LlamaModel.CompleteParams( prompt 请总结这段文档..., nPredict 512, // 最大生成token数 temperature 0.7f, topK 40, topP 0.95f ) ) for (token in result) { runOnUiThread { renderToken(token) } }这里有个特别重要的参数是nCtx。它代表上下文窗口大小直接决定KV Cache的内存占用。在手机上我通常建议设2048到4096不要盲目追求大窗口。很多人的端侧App崩溃就是因为把nCtx设成了10000而手机的运行内存根本扛不住。4.3 端侧模型的性能实测数据我知道大家最关心的是实际速度。这里给一组我在中端安卓手机骁龙778G级别8GB内存上测过的数据用的是7B模型的Q3_K_S量化版本模型量化等级大小首token延迟生成速度Llama-3-8BQ3_K_S约3.2GB1.8秒约9 token/sQwen2.5-7BQ4_K_M约4.3GB2.4秒约7 token/sQwen2.5-3BQ4_K_M约2.0GB0.7秒约18 token/s看得出来参数规模对速度的影响是决定性的。在我的实际场景里除非业务确实需要7B甚至更大的模型能力否则我优先推荐3B级别的Qwen2.5速度在手机上可接受效果也足够处理结构化抽取和摘要这类任务。我还测过更激进的三位量化Q2_K速度能到12 token/s左右但那模型的输出质量已经开始崩了宁可切小模型也别用超低位量化。4.4 端侧推理的效果边界与降级策略端侧跑模型还有一个现实问题能力天花板明显。7B模型在手机上的推理质量和云端70B模型差距是全方位的——长文理解、复杂推理、指令遵循都会有肉眼可见的差距。所以我在做架构设计时都会加端云协同降级策略端侧先跑一遍如果模型输出的置信度低于阈值或者用户显式请求深度分析就自动转云端API。这个策略的好处是离线场景能用在线场景效果也不打折。具体实现上我通常在端侧模型后面接一个简单的评分器比如对回答长度、关键词覆盖度打分分数低于阈值就弹提示正在联网获取更精准结果。这招在客服辅助场景里特别好用用户的等待成本极低但对回答质量的提升是实打实的。5. AI应用层的工程化封装交互逻辑的技术栈和接口设计聊完模型和端侧回到一个所有大模型应用开发者都绕不开的问题怎么把AI交互逻辑封装成可以复用的模块而不是让业务代码里到处散落着prompt拼接和流式解析。我在100多个场景里迭代了三版封装方案这里把最终版拿出来讲。5.1 为什么必须做独立封装如果你只是做个Demo直接在前端调用大模型API完全没问题。但到了企业级应用至少有四个原因逼着你做独立封装第一模型的接口形态不统一。有的服务商提供OpenAI兼容接口有的是自定义格式有的是流式非流式两套接口。如果业务代码直接耦合这些细节以后换模型供应商就是一次伤筋动骨的改造。第二鉴权和安全诉求。API密钥绝不能存在客户端必须在后端统一管控、统一审计。第三可观测性需求。企业上线项目需要知道每个用户的调用量、每条回答的Token消耗、单次请求的耗时分布。如果调用散落在各个业务模块这些指标根本统计不齐。第四业务规则注入。比如企业知识库问答要先做权限过滤只能让用户检索到他有权限的文档。这类逻辑放在业务层里非常合理但必须有个统一的入口。5.2 统一接口设计业务层只认一个ChatService我的封装思路是整个AI交互被抽象成一个ChatService业务层完全不关心背后接的是哪个大模型、走SSE还是WebSocket、是云端还是本地部署的私有化环境。这里给一版极简但又足够用的Java接口定义基于这个思路的代码我在Spring Boot项目里用过多次public interface ChatService { // 流式对话通过回调接受增量token void chatStream(ChatRequest request, StreamCallback callback); // 中断指定会话的生成 void abortConversation(String conversationId); // 非流式对话适合后端内部的场景 ChatResponse chatOnce(ChatRequest request); } public record ChatRequest( String conversationId, String prompt, ListChatMessage history, MapString, String metadata // 携带用户身份、业务标签等 ) {} public interface StreamCallback { void onToken(String token); void onDone(String conversationId); void onError(Exception e); }这里值得说明的是metadata字段。在企业级场景里它非常重要——你可以把用户ID、部门ID、业务线标识塞进去AI服务层就能基于这些信息做权限过滤、成本分摊、精细化计量。我见过太多团队因为最开始没预留这个字段后面做数据报表和权限控制时不得不大改结构。5.3 基于什么技术栈来组织AI交互逻辑技术栈的选择直接决定这套封装好不好维护。我的推荐组合是这样的服务端Java Spring Boot团队上手快生态成熟和现有企业系统对接方便或者Python FastAPI如果团队算法背景强Python揉算法更顺手。在两个技术栈里我都实现过原则上选团队最熟悉、运维体系最匹配的那个。模型访问层统一封装为OpenAI兼容接口本质原因是开源生态里大多数推理框架如vLLM、Ollama、llama.cpp的server模式都提供OpenAI兼容的HTTP服务客户端按这个协议封装底层随便换。异步和流式Spring Boot用WebFlux或Spring MVC的异步响应Python用FastAPI的StreamingResponse。缓存Redis做多级缓存。高频问题比如退货政策是什么直接命中缓存不需要每次调模型成本节省非常可观。我在一个电商售前咨询项目里加了一层Redis缓存重复问题的占比大概有18%这一层就把整个项目的模型调用成本降了接近五分之一。所以我一再强调AI应用的钱省在架构设计上而不是省在选便宜模型上。5.4 封装层的额外能力降级、熔断和审计架构设计完毕还需要给封装层加上三个企业级必备的能力。降级能力依赖的模型供应商不可用时自动切换到备用的本地部署模型。我在金融客户那里做的一个项目要求可用性99.9%单单依赖一个外部模型API显然做不到所以策略是外部API超时3秒后自动降级到内网自建模型用户基本无感知。熔断能力连续调用失败达到阈值比如1分钟内超过20次失败自动熔断不再发请求给模型服务商过30秒后放行少量流量探测恢复情况。这个逻辑和微服务里的熔断器一模一样实现时可以借Camel或者Resilience4j这类现成组件。审计能力所有的输入输出都要落日志。企业级项目出了AI生成内容违规的事故没有日志你连事故原因都查不清。我在封装层强制把完整的输入、输出、模型参数、耗时、Token数都写入日志系统用ELK或者Splunk做索引查询。6. 运维视角大模型运维工程师到底在运维什么最后一个话题写给那些对AI大模型运维感兴趣、或者正打算入行的朋友。最近高频搜索里反复出现ai大模型运维大专生能学会吗ai大模型运维工程师怎么样说明很多人在观望这个方向。我结合自己交付和运维大模型项目的经验聊聊这个岗位的真实日常和工作重心。6.1 大模型运维的职责边界不是说两句prompt就叫运维首先澄清一个误区大模型运维不是帮业务部门写写Prompt、调调对话那叫应用配置。真正的AI大模型运维工作核心围绕三个方面展开。第一个方面是基础设施运维。GPU服务器的驱动、CUDA版本、显存健康状态、多卡通信NVLink或者RoCE网络的稳定性这些都在你的职责范围里。和传统运维最大的区别是GPU卡是会坏的但很多时候不是物理损坏而是显存ECC错误累积导致的性能退化。所以大模型运维要建立一套针对GPU的专项监控比如实时采集显存温度、利用率、功耗、ECC错误计数。第二个方面是模型服务运维。模型用vLLM或者Triton部署成服务之后你要关注推理的延迟分布、吞吐量、排队长度、KVCache命中率。一个特别容易被忽视的指标是GPU利用率并不是越高越好——推理服务和训练不同它受限于显存带宽如果你的模型是batch size为1的在线服务GPU利用率可能只有30%左右但每个请求的响应速度是关键指标。第三个方面是数据与版本管理。模型文件非常大一次更新可能是几十GB怎么灰度发布怎么回滚怎么保证线上模型和数据版本能一一对应这些都超出了传统运维的范畴是需要专门设计的。6.2 大模型运维的监控指标清单经过多个项目的提炼我整理了一份大模型服务运维的监控清单新入行的同事可以照着搭层级监控项参考阈值说明硬件GPU温度80°C超温会导致降频推理变慢硬件显存剩余10%接近打满时要做容量规划硬件ECC错误计数持续增长需关注可能是显存颗粒劣化前兆推理首token延迟P95 2秒过大说明模型排队严重或服务过载推理生成吞吐视模型而定不足时考虑增大batch或换GPU服务请求成功率99.5%单体故障或者OOM都会影响成功率资源GPU利用率20%-80%低于或高于都不健康成本每千token成本视预算而定和缓存命中率联动分析这里面最反直觉的是GPU利用率不是越高越好。很多人刚上手时看到GPU利用率100%就开心以为服务饱和了。但在推理服务里GPU利用率100%往往意味着请求排队单请求延迟飙升。真正健康的状态是利用率适中、请求延迟稳定所以不要只盯一个指标要多个指标联动看。6.3 回应大专生能学会吗我的真实看法关于学历和能力的问题我从面试者和带人的角度看说点实在的。大专学历从事大模型运维理论上完全可行因为这个方向更看重工程动手能力和排障韧性而不是学术背景。我团队里就有大专出身、现在能把整个推理集群管得明明白白的运维工程师。但能不能入行取决于三个基础第一Linux功底要扎实。GPU服务器清一色Linux环境你不会shell脚本、看不懂系统日志寸步难行。第二网络基础要过关。大模型分布式推理涉及分布式通信如果你不懂TCP/IP、RDMA这些概念出了问题会无从下手。第三资料阅读能力——不是英文阅读而是读NVIDIA官方文档和开源项目issue区的耐心。很多问题官方文档里已经写得很清楚就看你能不能沉下心去查。我的建议是这类岗位的学习路线不用一上来就啃深度学习理论先围绕Ollama和vLLM这两个项目把部署、压测、监控跑通再去看GPU硬件原理和CUDA官方文档。这比啃《动手学深度学习》对入行更有用。7. 一点个人扩展想法把100个场景变成你自己的方法库这一路整理下来我最大的体会是AI大模型的落地真正的分水岭不在模型而在工程化能力。同一个模型有的人集成完上线即崩有的人能稳定扛住生产流量差别全在细节——SSE有没有关掉代理缓冲、端侧模型有没有做好降级策略、交互层有没有留好审计日志。所以我的建议是无论你是在做第一个AI Demo还是在为企业设计完整的AI中台都可以参照我上面讲的思路先画一张架构图问自己四个问题我的场景属于知识密集、流程密集还是端侧密集数据出域约束是否强制我选择本地部署或端侧模型我的AI交互层是否和具体模型供应商解耦上线之后我能否回答每条回答花了多少钱、耗时多久、质量如何这四个问题回答清楚了项目的架构基本就不会跑偏。最后分享一个小经验。不要指望一个模型通吃所有场景做技术选型时多留一条降级方案。云端大模型效果最好但成本高且有断供风险本地部署成本可控但质量有降级。最好的方案往往是组合拳高价值、重质量的需求走云端常规、敏感的需求走本地边缘、离线的需求走端侧。这套打法就是我从这100个企业级场景里总结出的最值钱的经验。