"本地部署 = 合规"是一个危险的等号。本地化只解决了数据流向这一个问题，模型许可证、训练数据来源、信创名录是另外三个独立问题，而且事后无法用技术手段补救。这篇按"要不要上本地—显存怎么算—工程怎么接—怎么验收"的顺序把账算全。
先判断该不该上，再谈怎么上
满足任意两条就该认真评估：数据明确不能出内网（唯一不可替代的理由）；云端账单大到半年到一年能买台 GPU 机器；业务受不了外网抖动；现场无外网；要求长期锁定模型版本。
三条常见伪理由要戳破："本地免费"——只是成本结构从按量变成固定，用不满就是浪费；"本地更安全"——只管住了数据流向；"效果差不多"——你能跑动的参数量级（单卡通常 7B~32B）往往远小于云端旗舰。还有一行最容易被低估的成本：云端换模型是分钟级，本地换模型是小时到天级——下载几十 GB 只是开始，还要重跑质量回归和并发压测。所以本地方案的模型选型必须一次定准。
显存账：四块构成，别只算第一块
总占用 = 模型权重 + KV Cache + 激活中间张量 + 框架开销。权重好算：7B @ Q4_K_M 约 4.5 GB，Q8 约 7.5 GB，14B @ Q4_K_M 约 9 GB。真正打崩生产环境的是 KV Cache——它随上下文长度和并发数线性增长，是最常被漏算的一块。预留公式：权重 + KV（按最大上下文 × 并发）+ 2 GB 起步的运行时开销，Windows 桌面还要再扣掉显示占用。
增量提醒（换模型的回归清单）：每次换量化版本，固定跑三件事——30 条真实业务 prompt 的质量对比（判定：回答结构不塌、关键实体不丢）；并发压测（判定：目标并发下首 token 延迟增幅 <50%）；长上下文冒烟（判定：最大窗口长度输入不 OOM）。三件全过才允许切流量。
Spring AI 侧的接入要点
Java 技术栈用 Spring AI 接 Ollama 是最短路径：引入 starter，spring.ai.ollama.base-url 指向内网 Ollama 地址，ChatClient 注入即用。两个工程细节：一是超时要放宽，本地模型长回答的首 token 延迟比云端高，默认超时会误杀；二是结构化输出用 BeanOutputConverter 时，7B 级模型对复杂 schema 的遵从率明显低于云端，嵌套字段要压扁，枚举要在 prompt 里显式列出。
合规侧再查三件事并留档：模型许可证是否允许商用、训练数据来源声明、是否需进信创名录。这三项任何一项存疑，流程就该停在法务环节，而不是"先跑起来再说"。
上线判定
四条全过才算落地：数据流向验证（内网抓包确认无外联请求，Ollama 进程的出网连接为空）；显存水位（峰值占用 <总量 90%，留并发余量）；质量回归（上述三件套）；回滚预案（云端 API 作为降级通道保留，配置开关一键切换）。本地化不是终点，可控才是。
评论0