国产大模型实战选型指南：27个真实业务场景测试复盘

1. 项目概述：一场没有硝烟的“大模型擂台赛”

最近三个月，我几乎把所有国产大模型的公开API、网页端、本地部署版本都跑了一遍——不是为了写评测报告，而是因为手头三个真实项目卡在了模型选型上：一个要给制造业客户做设备故障日志的自动归因分析，一个要为中小学语文老师生成符合课标要求的古诗文拓展题，还有一个是帮社区养老中心把老人手写的健康记录转成结构化电子档案。这三个场景，没有一个能被国外模型“开箱即用”解决。比如，让GPT-4解析“螺杆泵轴承异响频谱图+维修工手写‘2号泵轴向窜动大’”这种混合文本+专业术语+口语化描述的输入，它会一本正经地胡说八道；而通义千问对“部编版七年级下册《陋室铭》教学重难点”的响应，明显比Claude更贴合一线教师的真实备课逻辑。这让我意识到，“中国GPT”这个说法，从来就不是一句营销口号，而是由真实需求倒逼出来的技术分水岭：它必须懂中文语境里的潜台词，吃透行业术语的上下文，扛得住方言口音的语音转写，还得在政务、教育、医疗等强合规场景里不越界、不幻觉、不掉链子。所以这次“大比拼”，我完全抛开了参数榜单和宣传PPT，直接用27个真实业务片段当考题——从“把Excel里混着粤语拼音的客户投诉摘要成30字以内”到“根据卫健委最新糖尿病诊疗指南生成随访话术”，从“识别手写处方笺上的中药配伍禁忌”到“把法院判决书里的法言法语转成老年人能听懂的大白话”。最终跑下来，没有一个模型是全能冠军，但每个胜出者都在自己的“能力象限”里扎得极深。这篇文章，就是我把这轮实战测试的原始数据、踩坑记录、配置参数和交付脚本全部摊开写的复盘笔记，不吹不黑，只告诉你哪个模型在什么条件下能帮你省下多少开发时间。

2. 核心思路拆解：为什么不能照搬“国际评测标准”

2.1 真实业务场景才是唯一裁判

市面上常见的模型评测，比如MMLU、C-Eval、Gaokao-Bench，本质上都是“知识测验”。它们用标准化题目考察模型的百科知识广度、逻辑推理深度或考试答题能力。这就像用高考数学卷去评估一个汽车修理工——他可能解不出导数压轴题，但能三分钟判断出宝马X5变速箱异响是阀体故障还是油液老化。国产模型真正的战场，在于那些“非标任务”：

• 语义粘连处理：比如用户输入“上次说好月底前修好，结果拖到下个月三号，还收了我280块，发票也没给”，模型需要自动提取“承诺时间（月底前）→实际完成时间（下月三号）→违约天数（4天）→费用争议（280元）→凭证缺失（发票）”五个维度，且不能把“下个月三号”误判为“3号”（农历/公历混淆）。
• 领域术语动态校准：医疗场景中，“阴性”在检验报告里是正常结果，在中医诊断里却可能指“阳虚证候”；金融场景中，“平仓”在期货交易里是风控动作，在P2P回款里却是负面信号。模型必须根据上下文实时切换术语解释权重。
• 合规性硬约束：政务系统要求所有输出必须标注信息来源（如“依据《XX市养老服务条例》第十二条”），教育内容需自动规避超纲知识点（如初中作文辅导不能出现高中议论文的辩证法模型），这些不是“能力选项”，而是“启动开关”。

我设计的27道考题，全部来自这三类真实痛点。比如第14题：“将以下社区调解录音文字稿（含大量‘阿婆’‘侬讲’等沪语称呼、‘小赤佬’等情绪化表达）整理成规范调解笔录，要求：①隐去当事人真实姓名和身份证号 ②把方言口语转为普通话书面语 ③保留原始情绪强度标记（如‘拍桌子说’‘抹眼泪讲’）”。这道题，Qwen2-72B在实体脱敏准确率上达99.2%，但把“小赤佬”直译成“小家伙”导致调解员反馈“完全失真”；而Kimi-Max虽然用了“调皮的年轻人”这个更中性的译法，却漏掉了3处“拍桌子”的动作标记。最后胜出的是GLM-4-Flash，它用了一个精巧的双通道机制：先用轻量级方言识别模块做情绪锚点定位，再调用主模型做语义转换，确保“形神兼备”。

2.2 为什么必须放弃“单次推理最优”思维

很多团队在选型时陷入一个误区：追求单次API调用的响应质量。但在实际交付中，真正决定项目成败的是“端到端流程稳定性”。举个例子：我们给某三甲医院做的“门诊病历质控助手”，核心需求是自动识别病历中的逻辑矛盾（如“诊断：高血压3级”但“血压值：130/85mmHg”）。如果只看单次效果，Qwen2-72B的矛盾检出率高达92.7%，但它的token消耗极不稳定——遇到复杂病史描述时，会突然多生成300+字的无关分析，导致API计费暴增且触发医院系统的超时熔断。而DeepSeek-V2虽然单次检出率只有86.3%，但它通过预设的“三段式推理协议”（先定位关键数值→再匹配诊断标准→最后输出结构化结论），每次token消耗波动控制在±5%以内，配合我们自研的缓存层，整体服务可用率反而比Qwen高11.2个百分点。这说明，国产模型的竞争维度早已超越“谁更聪明”，转向“谁更可靠”：响应延迟的P99值、长文本处理的内存占用曲线、连续100次调用的幻觉率衰减趋势……这些工程指标，在真实生产环境里比“单次准确率”重要十倍。

2.3 本地化部署不是“退而求其次”，而是刚需

有客户问我：“你们为什么坚持推本地化部署？云API不是更省事？”我的回答是：当你的模型要处理的是“某军工企业设备维修手册PDF”或“某省医保局历史结算数据”，任何一次外部API调用都意味着数据出境风险。更现实的问题是网络抖动——我们曾在一个偏远县级医院部署试点，当地4G网络平均丢包率达17%，云API的超时错误率直接冲到43%。而本地部署的GLM-4-Air（4B参数量化版），在RTX4090单卡上实现23ms平均响应延迟，且支持离线运行。这里的关键认知转变是：国产模型的价值，不仅在于“替代GPT”，更在于构建“可控的数据处理管道”。就像我们给某省级政务云做的方案，核心不是模型本身，而是把Qwen2-72B封装成Docker镜像后，嵌入到他们已有的信创环境（麒麟OS+海光CPU+达梦数据库）中，所有输入输出都走内网消息队列，连模型权重文件都做了国密SM4加密。这种深度耦合能力，恰恰是国际模型无法提供的护城河。

3. 实操细节解析：27道考题背后的硬核参数与配置

3.1 考题设计方法论：从“业务切片”到“能力映射”

我把27道考题按业务域分成四类，每类对应不同的能力验证重点：

每道题都设置三级评分标准：

• 基础分（40分）：完成核心任务（如正确归类部门、输出故障步骤）；
• 进阶分（30分）：满足业务约束（如政务回复需带政策依据、医疗建议需标注证据等级）；
• 体验分（30分）：交互友好性（如自动补全模糊地址“浦东张江”→“浦东新区张江镇”，而非返回“未找到匹配地址”）。
  这种设计让评测结果直接对应商业价值：基础分决定“能不能用”，进阶分决定“要不要买”，体验分决定“客户愿不愿续费”。

3.2 关键参数调优实录：温度值不是玄学，是业务杠杆

很多人以为temperature参数只是控制“创意程度”，但在国产模型实战中，它是精准调节业务风险的杠杆。以金融合同审查为例：

• 当temperature=0.1时，模型严格遵循《金融消费者权益保护实施办法》，对所有模糊表述都标注“高风险”，但会漏掉新型违规话术（如把“保本”换成“净值波动趋近于零”）；
• 当temperature=0.7时，检出率提升22%，但开始出现“误伤”（如将合规的“历史业绩不代表未来表现”也标为风险）；
• 我们最终采用动态temperature策略：对监管明令禁止的关键词（如“保本”“无风险”）强制设为0.05，对灰色地带表述（如“稳健增值”）设为0.5，对创新产品描述（如“AI量化策略”）设为0.85。这套策略在某银行试点中，使人工复核工作量下降63%，且0误判记录。

另一个常被忽视的参数是max_tokens。在政务公文生成场景，我们发现：固定设为512会导致模型在结尾强行凑字数（如“综上所述，我们要……（此处应有32字）”），而设为256又常截断关键结论。解决方案是“语义截断”：先用轻量级分类器判断公文类型（通知/请示/函），再按类型加载预设的token预算表（通知类320字、请示类480字、函类220字），最后在生成时实时监控句法完整性——宁可少输出半句话，也不破坏“主谓宾”结构。这个细节让某市政府OA系统的公文采纳率从61%提升至89%。

3.3 提示词工程：不是写作文，是编译业务规则

给国产模型写提示词，本质是把业务规则“编译”成模型能执行的指令。以教育场景的古诗文拓展题生成为例，原始需求是“生成3道不同认知层次的题目”。如果直接写：“请生成3道关于《陋室铭》的题目”，结果可能是：

1. 《陋室铭》作者是谁？
2. 文中‘苔痕上阶绿’描写的是什么景象？
3. 请背诵全文。

这完全违背“认知层次递进”要求。我们的解决方案是构建三层提示词框架：
第一层：角色定义
“你是一名有15年教龄的初中语文特级教师，正在为部编版七年级下册《陋室铭》设计课堂练习，严格遵循布鲁姆认知目标分类法。”
第二层：规则约束
“题目必须覆盖记忆（Level1）、理解（Level2）、应用（Level3）三个层级，Level1题仅考查事实性知识（如作者、朝代），Level2题需解释概念关系（如‘斯是陋室’与‘惟吾德馨’的逻辑），Level3题必须创设真实情境（如‘假如刘禹锡来到现代社区服务中心，他会如何评价这里的办公环境？’）。”
第三层：输出控制
“每道题后必须标注认知层级代码（L1/L2/L3），答案单独成行并标注‘参考答案：’，禁止出现‘解析’‘说明’等额外文字。”

这套提示词在实测中使L3题目生成准确率从34%提升至91%。关键经验是：国产模型对“角色+规则+格式”的三段式指令响应极佳，但对开放式要求（如“请有创意”）几乎无效。这印证了一个底层逻辑：它们不是通用智能体，而是高度特化的“业务规则执行引擎”。

4. 主流模型实测对比：性能数据、适用场景与避坑指南

4.1 通义千问Qwen2系列：综合战力最强，但需警惕“过度发挥”

Qwen2-72B在27道考题中总分排名第一（加权得分92.4），尤其在政务和教育场景优势显著。其核心竞争力在于：

• 超长上下文处理：在128K上下文下，对《民法典》千页PDF的条款引用准确率达99.7%，远超其他模型（平均86.3%）；
• 多模态原生支持：无需额外插件即可解析扫描件中的表格+文字混合内容，我们在某社保局项目中，用它直接处理参保人手写申请表，字段识别F1值达94.2%；
• 开源生态完善：Qwen2-1.5B量化版可在树莓派5上运行，我们用它给乡村小学做了离线版成语接龙游戏，功耗仅3.2W。

但必须警惕两个典型陷阱：

提示：Qwen2的“思维链”模式（启用--enable-cot）在简单任务中会显著增加延迟（平均+210ms），且容易生成冗余解释。例如考题“计算2023年某市GDP增长率”，它会先输出“根据国家统计局公式：增长率=（本期值-基期值）/基期值×100%……”，再给出结果。在实时性要求高的政务热线场景，必须关闭此模式。
提示：其代码生成能力虽强，但对国产信创环境适配不足。我们曾用Qwen2生成麒麟OS的Shell脚本，结果包含大量Ubuntu特有的apt-get命令，需人工替换为dnf。建议在信创项目中，优先选用其“政务专用微调版”（需单独申请）。

4.2 月之暗面Kimi-Max：长文本王者，但小任务“杀鸡用牛刀”

Kimi-Max在200K上下文测试中展现统治级实力：处理某央企2000页《十四五数字化转型规划》时，能精准定位“云计算采购预算”在第17章第3节第2段，并关联到附件7的供应商资质要求。其“文档切片-向量检索-交叉验证”三步机制，使长文档问答准确率比Qwen2高8.6个百分点。

但它的短板同样鲜明：

• 小任务响应迟钝：在“将手机号1381234脱敏为1381234”这类简单操作上，平均延迟达1.2秒（Qwen2为0.18秒），因为模型会先加载全部上下文再执行；
• 领域微调成本高：我们尝试用500条医疗问诊数据微调Kimi-Max，发现需要至少32GB显存（A100），而同任务下GLM-4仅需16GB。这导致中小客户难以承担定制成本。

实操建议：Kimi-Max最适合“文档中枢”角色——作为企业知识库的统一入口，前端用轻量模型（如Qwen1.5-0.5B）做意图识别和简单查询，复杂文档分析才路由给Kimi-Max。我们给某律所做的方案中，就用这种架构把平均响应时间压缩到0.8秒以内。

4.3 智谱GLM-4系列：信创适配最深，但生态工具链待完善

GLM-4在国产芯片适配方面一骑绝尘：在海光C86处理器+昇腾910B的纯信创环境中，推理速度达到Qwen2-72B的1.8倍。其最大亮点是“安全沙箱”机制——所有输出自动经过三层过滤：

1. 政策合规层（拦截违反《生成式AI服务管理暂行办法》的表述）；
2. 行业红线层（医疗场景禁用“治愈”“根治”等词，金融场景禁用“稳赚”“保底”）；
3. 企业私有层（可上传自定义敏感词库，如某车企禁止提及“竞品车型参数”）。

但当前主要瓶颈在于工具链：

• 官方提供的LoRA微调工具仅支持PyTorch 2.0+，而某政务云仍运行CentOS 7.6（默认Python 3.6），需手动编译依赖；
• 其RAG功能需搭配专属向量数据库Zilliz Cloud，无法接入客户已有的Elasticsearch集群。

我们的应对方案是：用GLM-4-Flash（4B量化版）做核心推理，外围用Python脚本桥接现有系统。例如在某省医保局项目中，用Flask封装GLM-4 API，输入为医保结算XML，输出自动转为符合《医疗保障基金结算清单》格式的JSON，全程不触碰原始数据库。

4.4 百度文心一言ERNIE-4.5：垂直场景优化极致，但通用性受限

ERNIE-4.5在特定场景的“开箱即用”程度令人惊叹：

• 教育场景：内置教育部课标知识图谱，生成的试题自动标注“对应课标条目”（如“2022年版课标·第三学段·阅读与鉴赏·第4条”）；
• 政务场景：预装全国31省市政务服务事项库，输入“我要办食品经营许可证”，直接返回本地化办理指南（含窗口地址、预约电话、材料清单）；
• 工业场景：集成《GB/T 19001-2016质量管理体系》条款库，能自动将设备故障描述映射到具体条款（如“轴承异响”→“8.5.1生产和服务提供的控制”）。

但它的代价是“场景锁定”：一旦离开预置领域，性能断崖式下跌。在金融法律考题中，其合同审查准确率仅58.7%（Qwen2为86.3%），因为未加载银保监会最新监管文件。我们的经验是：ERNIE-4.5适合“场景明确、需求稳定”的项目（如某市教育局的统考命题系统），但不适合需要频繁扩展新领域的平台型项目。

4.5 深度求索DeepSeek-V2：工程化最成熟，但中文语义深度稍逊

DeepSeek-V2的最大优势是“拿来即用”的工程成熟度：

• API稳定性：P99延迟始终控制在320ms以内（其他模型平均580ms），且支持WebSocket长连接，避免HTTP频繁握手；
• 错误处理友好：当输入超长时，自动返回“建议截取前10000字符”，而非直接报错；
• 计费透明：按实际token计费（含空格和标点），不像某些厂商把system prompt也计入费用。

但在中文语义理解上存在明显短板：处理古诗文中的典故隐喻时，常把“庄生晓梦迷蝴蝶”直译为“庄子早晨做梦变成蝴蝶”，忽略“人生虚幻”的哲学意蕴。我们的解决方案是“双模型协同”：用DeepSeek-V2做基础信息抽取（如提取人物、时间、事件），再用Qwen2-7B做语义深化（解读典故内涵），最后用规则引擎融合输出。这种架构在某出版社古籍数字化项目中，使典故解读准确率从67%提升至93%。

5. 实操全流程：从环境搭建到上线交付的完整脚本

5.1 本地化部署：GLM-4-Air在RTX4090上的极简安装

我们选择GLM-4-Air（4B参数量化版）作为政务项目基准模型，因其在消费级显卡上的平衡性最佳。以下是经过23次环境重装验证的极简流程：

# 1. 创建隔离环境（避免CUDA版本冲突） conda create -n glm4 python=3.10 conda activate glm4 # 2. 安装核心依赖（注意：必须用官方指定版本） pip install torch==2.1.0+cu118 torchvision==0.16.0+cu118 --extra-index-url https://download.pytorch.org/whl/cu118 pip install transformers==4.35.0 accelerate==0.24.1 # 3. 下载量化模型（官方提供GGUF格式，兼容llama.cpp） # 从智谱AI官网获取下载链接（需企业认证），解压后得到： # glm-4-air.Q4_K_M.gguf # 4-bit量化，4.2GB # 4. 启动服务（关键参数说明） llama-server \ --model ./glm-4-air.Q4_K_M.gguf \ --ctx-size 32768 \ # 上下文长度，政务文档常用值 --batch-size 512 \ # 批处理大小，影响吞吐量 --n-gpu-layers 45 \ # 将全部层卸载到GPU（RTX4090有45层） --port 8080 \ --host 0.0.0.0 \ --embedding \ # 启用向量嵌入，用于RAG --chat-template chatglm3 # 强制使用ChatGLM3对话模板

注意：若遇到CUDA out of memory，不要盲目调小--ctx-size！实测发现，将--batch-size从512降至256，内存占用下降40%，但吞吐量仅损失12%。这是更优的平衡点。

5.2 API网关配置：用Nginx实现国产模型的“熔断-降级-限流”

在某市12345热线项目中，我们用Nginx构建了三层防护网：

# /etc/nginx/conf.d/glm4.conf upstream glm4_backend { server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; keepalive 32; # 保持长连接 } server { listen 8000; # 第一层：请求限流（防刷） limit_req zone=glm4_api burst=10 nodelay; # 第二层：熔断机制（错误率>5%时自动隔离） proxy_next_upstream error timeout http_500 http_502 http_503 http_504; proxy_next_upstream_tries 2; # 第三层：降级策略（当GLM-4不可用时，返回预置模板） location /v1/chat/completions { proxy_pass http://glm4_backend; proxy_intercept_errors on; error_page 500 502 503 504 = @fallback; } location @fallback { add_header X-Fallback "true"; return 200 '{"choices":[{"message":{"content":"系统繁忙，请稍后再试"}}]}'; } }

这套配置使高峰期API错误率从12.7%降至0.3%，且故障恢复时间缩短至8秒以内。关键经验是：国产模型的运维，必须像对待传统数据库一样设计容灾方案，不能寄希望于“云服务商保证SLA”。

5.3 RAG增强实战：用Milvus构建政务知识库的“三步法”

政务场景中，模型需实时调用最新政策文件。我们用Milvus 2.4构建知识库，核心是“三步清洗法”：
第一步：文档切片
不用简单的“按段落切分”，而是用正则识别政策文件结构：

# 识别“第一章 第一条”“（一）”“1.”等多级标题 pattern = r'(第[一二三四五六七八九十]+[章|节])|(（[一二三四五六七八九十]）)|(\d+\.)' chunks = re.split(pattern, doc_text) # 过滤掉纯标题，保留“标题+后续内容”组合

第二步：向量化
不用通用Embedding模型，而用政务微调版bge-reranker-large-zh，在政策条款相似度任务上准确率提升22%。
第三步：混合检索
不单靠向量相似度，而是加权融合：

• 70% 向量相似度（语义匹配）
• 20% 标题关键词匹配（如查询含“医保”，则优先返回标题含“医疗保险”的文档）
• 10% 发布时间权重（新规权重×1.5，旧规×0.8）

这套方案在某省人社厅试点中，政策咨询准确率从68%提升至94%，且平均响应时间仅增加0.3秒。

5.4 监控告警体系：用Prometheus抓取国产模型的“健康心跳”

我们为所有模型服务部署了定制化监控：

# prometheus.yml scrape_configs: - job_name: 'glm4' static_configs: - targets: ['localhost:8080/metrics'] # GLM-4内置metrics端点 metrics_path: '/metrics' # 自定义指标：幻觉率（通过规则引擎检测） - job_name: 'glm4-hallucination' static_configs: - targets: ['localhost:9090'] metrics_path: '/hallucination'

关键告警规则：

• glm4_hallucination_rate{job="glm4"} > 0.05（幻觉率超5%立即告警）
• glm4_gpu_memory_used_percent > 92（显存超92%触发扩容）
• glm4_request_duration_seconds{quantile="0.99"} > 2.0（P99延迟超2秒）

这套监控让我们在某次模型更新后，提前37分钟发现“新版GLM-4在处理‘乡村振兴’相关查询时幻觉率异常升高”，避免了大规模误输出。

6. 常见问题与独家排查技巧

6.1 “明明提示词写得很清楚，模型还是不按要求输出”——根本不是提示词问题

这个问题占我们技术支持请求的63%。真相往往是：模型在训练时见过太多“错误示范”。比如，当大量互联网文本中，“请生成一首诗”后面跟着的是五言绝句，模型就形成了“生成诗=五言绝句”的强关联。我们的排查流程：

1. 检查训练数据污染：用transformers库加载模型tokenizer，统计高频输出模式；
2. 注入对抗样本：在提示词末尾添加“<|NO_OUTPUT|>”，强制模型抑制常见模式；
3. 规则后处理：用正则强制校验输出格式（如“必须以‘答：’开头”）。

实操案例：某法院项目要求判决书摘要必须包含“原告诉求”“被告答辩”“法院认定”三部分。我们发现Qwen2总是漏掉“被告答辩”，根源是训练数据中73%的判决书摘要只写原告和法院部分。最终方案是在输出后加一道Python校验：

if not re.search(r'被告答辩.*?：', output): output = re.sub(r'法院认定', '被告答辩：\n\n法院认定', output, count=1)

6.2 “长文本处理时，后面的内容明显比前面差”——上下文压缩的隐形杀手

所有国产模型在长文本中都存在“位置偏差”：越靠近末尾的token，注意力权重越低。我们测试发现，Qwen2-72B在128K上下文中，最后10%内容的推理准确率比前10%低31%。解决方案不是“换模型”，而是“改结构”：

• 关键信息前置：在文档预处理阶段，用规则引擎把核心条款（如“违约责任”“争议解决”）提取到开头；
• 分段验证：将长文档切成512token区块，每个区块独立生成摘要，再用主模型融合；
• 位置强化：在提示词中显式标注“请注意：以下第3段内容为本次任务最关键依据”。

这个技巧让某集团合同审查项目的准确率提升至96.8%。

6.3 “模型输出越来越啰嗦，甚至开始编造不存在的条款”——温度值失控的连锁反应

这是模型“过热”的典型症状。我们发现，当连续多次调用同一模型且未清空历史时，其内部状态会累积“创作惯性”。解决方案是：

• 强制状态重置：每次API调用后，发送{"role":"system","content":"reset"}指令；
• 动态温度衰减：设置初始temperature=0.3，每连续5次调用后自动-0.05，最低至0.1；
• 输出长度钳制：用max_tokens硬限制，但配合stop=["。", "！", "？"]防止截断句子。

在某银行客服项目中，这套组合拳使平均响应字数从187字稳定在124±8字，且0次编造条款记录。

6.4 “同样的提示词，在不同模型上效果天差地别”——没有银弹，只有适配

很多团队幻想找到“万能提示词模板”。现实是：Qwen2吃透“角色+规则+格式”，Kimi-Max需要“先确认理解再执行”，GLM-4则对“安全约束前置”响应最佳。我们的适配口诀：

• Qwen2系：“你是XXX，必须做YYY，输出格式为ZZZ”；
• Kimi系：“请复述我的要求，确认无误后开始执行”；
• GLM系：“根据《生成式AI服务管理暂行办法》第X条，禁止YYY，现在执行ZZZ”。

这个差异源于各模型的训练数据分布——Qwen2更多来自开源代码和学术论文，Kimi-Max侧重长文档，GLM-4则深度融入政策法规语料。

6.5 “模型突然不响应，日志显示CUDA error”——显存碎片化的幽灵

在RTX4090上部署多模型服务时，我们遭遇过最诡异的问题：模型运行2小时后，突然报CUDA out of memory，但nvidia-smi显示显存占用仅65%。根源是CUDA内存分配器的碎片化。解决方案：

• 预分配显存池：启动时用export CUDA_CACHE_MAXSIZE=2147483648（2GB）；
• 定期重启worker：用Supervisor配置startretries=3，每4小时自动重启；
• 启用内存压缩：在llama-server中添加--mlock参数，防止内存交换。

这个技巧让某区政务云的模型服务连续运行147天无故障。

7. 交付物清单与成本测算：一份可直接拿去投标的方案

7.1 标准交付物（所有项目必含）

7.2 成本构成明细（以10万日调用量项目为例）

提示：在