企业官网建设流程全解析

目录

一、把口号还原成工程问题

（一）三种错误比法会同时把问题问歪

1. 只比参数量

2. 只比单价

3. 只比出不出内网

（二）六个对照维度，每一个都要有判定动作

（三）贯穿场景：一套坐席工单助手

二、先看清调用拓扑，再谈落在哪一端

（一）Java 应用并不直接面对模型

（二）三种落地形态，形态不是品牌

（三）Java 侧真正该抽象的是端点，不是品牌

三、质量：同一份评测集上，差距从哪里来

（一）质量不是参数量一条线

1. 六个可分开度量的点

2. 工单场景里最常见的误判

（二）任务分层，不要用同一档模型扛所有调用

（三）没有对照集就没有选型

1. 样本、指标与流水线

2. 对照时最容易做错的，以及何时必跑

2.1 必跑的改动

2.2 抽测与不必全量的改动

四、隐私：出域不等于泄密，不出域也不等于安全

（一）数据出域有三条路径，风险并不相同

1. 提示词出域、留在域内、专有云

2. 真正敏感的不是模型在哪

3. 传输、处理、留存要分开谈

（二）四道闸门必须装在接入层

（三）合同、留存与审计是三页纸，不是一枚徽章

五、延迟：拆成三截，才能决定超时写多少

（一）网络、排队、生成，三种口径不要混用

1. 三截各自计什么

1. 三截各自计什么

2. 本地并不总是更快

2. 本地并不总是更快

（二）两条曲线：并发爬升与输出变长

（三）超时必须写成一条链

六、并发：真实容量单位是槽位，不是 QPS

（一）本地卖显存，云端卖限额

1. 两边的容量单位

1. 两边的容量单位

2. 为什么应用层压测会测错

2. 压测为什么会测错

（二）排队、批处理、拒绝，三种消化方式要显式

（三）不要用业务线程去等生成

七、部署成本：交叉点按任务画，不要画一张总图

（一）两套账本，同一条时间轴

（二）交叉点演算要带五个修正

1. 曲线只说明方法

2. 演算必须带上的五个修正

（三）隐藏成本在账单上看不见

八、运维复杂度：复杂度不能消灭，只能决定由谁承担

（一）六件事，两边各有一份值班表

1. 值班表要对齐

2. 两边各自容易低估什么

（二）把权重当成发布物，而不是网盘文件

（三）故障域要错开，主路径必须能降级

九、Java 接入层：换模型不该换业务

（一）同一套客户端，两套端点

1. 兼容方言作为默认

2. 多 Bean、测试替身与密钥

（二）路由层把选型做成运行时决策

（三）失败语义对齐，两边不能各说各的错误

十、三种形态各自的落地边界

（一）开发机上的本地进程

（二）机房推理集群

（三）云端模型即服务

十一、混合路由：把两行写进同一张可测试的表

（一）四种健康形态，外加一种不健康

1. 四种健康形态

2. 叠加之后仍然要可测试

（二）熔断与回退，探活用合成请求

十二、判定、误区与落地节奏

（一）逐项判定随任务翻转

（二）十二条误区，共同特征是跨维度挪用优势

（三）四阶段落地，对照先于固定资产

1. 四阶段与出口判据

2. 不要提前做的事，以及两种收敛

十三、一页总览

（一）十条主干判断

（二）路由表代替立场

参考资料

（一）框架、方言与本地推理

（二）质量、延迟与容量口径

（三）隐私、合规与安全工程

（四）成本、混合架构与工程讨论

干货分享，感谢您的阅读！

能在开发机上用私有权重跑通一次对话，并不等于这笔调用该永远留在机房；能用云端旗舰模型写出漂亮的回复，也不等于这条链路该把工单原文送出域。

Java 应用真正要做的，不是在“本地”和“云端”两个阵营里站队，而是在质量、隐私、延迟、并发、部署成本与运维复杂度六张表上，把每一次调用路由到当时正确的那一端。

本次我们沿着一套坐席工单助手走完整条链路：从错误的比法、四层调用拓扑、三种落地形态，到评测门禁、脱敏闸门、超时链、槽位容量、交叉点演算、值班表、熔断限速与四阶段落地节奏。

能本地不等于该本地，能上云不等于该上云——选型的产物是一张可测试的路由表，不是一句立场。

一、把口号还原成工程问题

讨论开始之前，先把题目里两个词的边界说清楚。本次说的本地模型，不是“笔记本上的聊天窗口”，而是推理发生在你控制的故障域里：开发机上的进程、机房里的 GPU 集群、专有云里的独享租户，都属于这一侧。本文说的云端模型，也不是某家品牌，而是推理发生在供应商的多租户服务里：按词元或按调用计费，弹性由对方提供，数据至少要经过对方的网关。两者中间还有一条常被漏掉的形态——把开源权重放到供应商的 VPC 或专有云推理里——隐私接近本地，弹性接近云端，运维介于两者之间。后文会把它单独标出来，不混进“纯云端”里比较。

Java 应用在这场讨论里的位置很特殊。模型不跑在 JVM 里，GPU 调度也不由 Spring 容器完成。业务代码面对的是一次 HTTP 调用、一套超时、一组错误码、一份用量字段。这意味着：选型争论经常发生在权重这一层，而 Java 团队真正能改、也必须改的，是接入层。接入层设计对了，本地换云端是一次配置与回归；接入层设计错了，换端点会变成一次重构。

（一）三种错误比法会同时把问题问歪

1. 只比参数量

第一种比法是只比参数量。把七十亿参数的开源权重和云端两千亿参数的旗舰模型直接对打，结论永远是云端更聪明。可工单场景里占比最高的调用，往往是意图分类、字段抽取、是否含敏感信息这类短上下文任务。这些任务的验收口径是枚举有没有写对、JSON 能不能落库，不是聊天好不好看。参数量在这里是错的尺子。尺子错了，后面所有“本地不够聪明、必须上云”的结论都会被放大。

2. 只比单价

第二种比法是只比单价。把云端按词元计费和本地显卡一次性投入直接相减，会漏掉电费、空闲、值班、报废、失败重试和坐席返工。单价低不等于账单低，账单低也不等于单位业务成本低。本地在流量不够时会被空闲惩罚，云端在失败重试时会被放大惩罚。用“一次调用多少钱”做决策，三个月后一定对不上财务口径。

3. 只比出不出内网

第三种比法是只比数据出不出内网。数据不出机房并不等于安全：本机日志、共享显卡、未脱敏的提示词、被提示注入带走的字段，都还在。出域也并不等于泄密：合同里的训练使用权、区域、留存周期、子处理方，加上发送前的字段白名单与审计，可以把风险压到法务可接受的范围。把隐私问题压缩成“出不出内网”一个开关，会同时高估本地、低估云端的可治理空间。

有效的对照只有一种做法：同一份业务、同一套评测集、同一组并发与延迟口径，把本地与云端各跑一遍，再看差在哪里。只比入门示例会把差异压成零，只比特性清单会把“有”当成“能用”，只比社区热度会把活跃度当成适配度。对照必须能被观察，不能只被讨论。

（二）六个对照维度，每一个都要有判定动作

质量、隐私、延迟、并发、部署成本、运维复杂度，这六个词经常出现在同一张对比表里，但表头往往只有“优 / 劣”两列。优劣势是形容词，选型需要的是动词：怎么测、测什么、测完如何阻断发布。

质量的判定动作是同一份两百条评测集各跑三遍，看字段级准确、拒答率、结构化成功率、工具选对率。隐私的判定动作是列出提示词里会出现的字段，逐项标出域，看泄漏率与审计还原时长。延迟的判定动作是在目标并发下打满十分钟，看首字与整段的 P95，而不是看均值。并发的判定动作是把显存槽位或云端限额当成容量单位来压，看排队与拒绝码。部署成本的判定动作是用三个月真实流量回放，算单位工单成本与交叉点。运维复杂度的判定动作是数一数升级一次要动几个人、回滚要几分钟、故障域有几个。

六个维度按暴露时刻排列。质量和隐私第一周就会被问到；延迟第二周会在联调里暴露；并发第一个月会在预发里暴露；成本第三个月会在账单上暴露；运维第六个月会在第一次升级事故里暴露。越晚暴露的维度越贵。前两个维度错了可以换模型，后四个维度错了通常要重做接入层、容量与值班制度。

贯穿全文的三问可以先记在这里。第一问：这件事值不值得用更强的模型？质量差如果评测集上看不见，就不要为“感觉更聪明”付账。第二问：这件事能不能出域？能出域不等于该出域；不能出域也不等于必须自建推理集群。第三问：这件事的失败由谁兜？本地挂了是你的故障域，云端挂了是供应商的故障域，账单形状与恢复时间表完全不同。

（三）贯穿场景：一套坐席工单助手

抽象讨论需要一个落点。本文沿用一套面向客服坐席的工单助手——它同时具备三类资产、五种调用形态、一条必须能降级的主路径，是少数能把六个维度一次性长出来的题目。

三类资产分别是企业知识库、工单结构化抽取、带副作用的内部接口。知识库大约十二万个片段，失败代价是坐席拿到一条不存在的政策、对客户做了错误承诺。结构化抽取要把一封邮件变成类目、优先级、实体与摘要，失败代价是字段脏、落不了库。内部接口包括查单、改单、发通知，失败代价是不可回滚的副作用。

五种调用形态对模型档位的要求并不相同。意图分类与敏感信息预检要快、要稳、要结构化；工单抽取要 Schema 约束；带检索的回复草稿要引用、要可编辑；工具处置要选对工具、要人在环；夜间批量摘要对延迟不敏感、可以排队。同一条业务链路上，这五种形态对质量、隐私、延迟、并发的要求并不相同——这才是“不要一刀切”的真正理由。

为什么用工单助手而不是聊天机器人？聊天机器人只考生成好不好。工单助手同时压着六件事：字段要落库，所以结构化输出必须稳定；处置有副作用，所以工具调用必须可回滚；坐席是最终责任人，所以人在环必须是一等公民；承诺有时限，所以延迟与降级必须可控；成本要归到单张工单，所以每一次调用都要能记账。这六件事正好把本地与云端的差异全部照出来。

文中出现的耗时、词元单价、显卡价格、准确率、并发槽位均为量级示意，用来说明相对关系与设计意图，不是任何具体工程的实测参数。框架与推理引擎以 2026 年 9 月的公开发行版为坐标。落地时应以自身压测、评测结论与法务口径为准。

二、先看清调用拓扑，再谈落在哪一端

（一）Java 应用并不直接面对模型

整条链路可以分成四层。最上面是业务服务：工单、坐席工作台、批处理任务，它们只认自己的端口与契约。第二层是模型接入层：路由、限流、脱敏、超时、记账，Spring AI 的ChatClient或自研门面都落在这里。第三层是推理端点：OpenAI 兼容的 HTTP，或厂商 SDK；本地可能是 Ollama、vLLM，云端可能是各家网关。最下面才是权重与硬件：GGUF 或 Safetensors，消费级卡、数据中心卡或云租户里的 GPU。真正消耗显存与电的是第四层，真正消耗 Java 团队设计精力的是第二层。

这个分层有一个直接推论：把供应商类型泄漏进业务包，本地换云端就会变成一次重构；把供应商类型收进接入层，换端点只是一次配置与回归。后文所有关于 Spring AI、多ChatModel、错误翻译的讨论，都建立在这句话上。

选型争论经常发生在第四层——“我们要不要自训一个模型”“要不要上七十亿还是三百亿”——而 Java 团队在第一周就能做、也最该做的，是把第二层搭干净。第二层不干净，第四层无论选哪边，失败都会以业务异常的形式冒出来，排障时却找不到是路由错了、脱敏错了，还是权重本身不行。

（二）三种落地形态，形态不是品牌

第一种形态是开发机上的本地进程，代表是 Ollama、llama.cpp。容量单位是本机显存或统一内存，并发接近串行，运维几乎为零，定位是开发、评测、小流量内网。不要把它直接当成生产推理层。

第二种形态是机房或专有云里的推理集群，代表是 vLLM、SGLang、TGI。容量单位是 GPU 槽位与连续批处理，并发可到百级，取决于显卡与量化。运维上驱动、权重分发、值班都要有。定位是稳态高 QPS、数据不出域。空闲时固定成本不会自动消失。

第三种形态是云端模型即服务。容量单位是限额、配额、区域容量，并发有弹性，突发可以买到。你只运维接入层与密钥。定位是质量、峰值、尚未定型的任务。出域、限流、涨价都是外部事件。

还有一条常被漏掉的中间态：把开源权重放到供应商的专有云或 VPC 推理里。网络不出你的专线或对等连接，合同与审计要单独谈，不能套用公有模型即服务的默认条款。它适合不能自建 GPU、又不能出公网的团队。后文把它视为“本地”的一种托管实现，而不是“云端旗舰”的一种打折。

三种形态的对照点不在品牌，在值班、失败时你能做什么、账单形状、Java 侧看到什么。开发机挂了，开发自己看日志；集群挂了，平台或算法值班；云端挂了，你看状态页、换区域、等恢复。账单分别是电费可忽略、折旧加电加机位、按词元或按调用。Java 侧分别看见本机端口、内网负载均衡、公网或专线 HTTPS。典型误用也不同：把联调进程当生产、用旗舰权重扛分类、用旗舰模型做向量化。

（三）Java 侧真正该抽象的是端点，不是品牌

业务端口应该长期稳定，只认三件事：发消息、收消息、拿到用量。推荐的门面形状很瘦：complete(req)与stream(req)，请求里带任务档位、数据密级、消息列表，响应里带文本或结构化对象、引用、用量、路由标签、追踪号。禁止在这个端口上出现供应商类型与模型名。

接入层是可变的：路由、超时、重试、熔断、降级、脱敏、限额、审计、耗时分解。这里才允许出现ChatModel类型。端点适配是可替换的：OllamaChatModel、OpenAI 兼容端点、vLLM 的/v1/chat/completions、各家云端 SDK。差异用额外请求体与错误翻译消化。换端点不应改业务测试。

可移植性的真实边界需要说破。协议层——尤其是 OpenAI 兼容 HTTP——可以抹平大约七成差异：消息角色、流式事件、工具调用的基本形状。抹不平的三成才是选型时要记账的：上下文窗口、结构化输出的强制程度、工具循环的默认上限、限流码、用量字段是否完整。所以“换模型只改配置”只在同一档位、同一协议方言里成立。跨档位或跨方言必须走对照回归。

Spring AI 把 Ollama 既做成了独立的聊天模型，也允许走 OpenAI 兼容端点。生产上更建议把兼容端点作为默认方言，把原生 Ollama 选项留给确实需要keep_alive、num_ctx、think这类专有能力的场景。方言统一之后，本地集群与云端网关才能共用同一套错误翻译与流式解析。

三、质量：同一份评测集上，差距从哪里来

（一）质量不是参数量一条线

1. 六个可分开度量的点

工单评测集上，差距通常落在六个可分开度量的点，而不是落在“谁的参数更多”。

指令遵循：按给定 JSON 填字段，本地中小模型最容易在枚举值上跑偏。工具选对：该不该调、调哪一个，旗舰云端显著更稳，本地要靠更窄的工具面来补偿。长上下文：政策对照、多轮协商，窗口大小与“真的读到了”是两件事。拒答纪律：无依据不许硬答，过强会拒掉能答的，过弱会幻觉。语言与术语：内部缩写、产品名，开源权重不一定覆盖，可用术语表补偿。稳定性：同一输入三次结果，温度、种子、采样比“更聪明”更影响落库。

2. 工单场景里最常见的误判

工单场景里最常见的误判有四条。把“会聊天”当成“会抽字段”——聊天好看、枚举写错，落库照样失败，结构化成功率必须单独统计。把“会检索”当成“会引用”——本地模型更容易把检索片段改写成不存在的条款，必须把引用来源当验收项。把“参数量大”当成“工具用得好”——工具选错的代价比句子不够漂亮高一个数量级，评测集里要有故意模棱两可的样本。量化会吃掉一部分质量——Q4 和 Q8 在分类任务上可能看不出差别，在多步工具调用上差别会被放大；换量化等于换模型，要重跑门禁。

质量对照还有一个容易被忽略的切片：清晰样本与模棱两可样本必须分开看。本地中档在清晰工单上往往不差，崩溃发生在缺字段、多意图、条款冲突的那一截。平均值会把崩溃藏起来。按切片看，才能决定“这一档任务该不该升云”，而不是“整个助手该不该升云”。

（二）任务分层，不要用同一档模型扛所有调用

工单链路上至少有四档任务。L0 是规则或小分类：意图、敏感级、是否含个人身份信息，推荐本地小模型或纯规则，延迟预算是毫秒到百毫秒，失败代价极低。L1 是结构化抽取：类目、优先级、实体、摘要，推荐本地中档加 Schema 约束，未校验就升云是反模式。L2 是带检索的草稿：引用政策生成可编辑回复，本地中档打底，质量不够再升，无命中仍硬答是反模式。L3 是多步工具处置：查单、改单、通知、协商，云端或强本地加人人在环，开放自治、无白名单是反模式。

升级的合法理由只有三条：评测集上的分差超过门禁阈值；上下文窗口不够，截断会丢关键条款；本地熔断或排队超过延迟预算。不构成升级理由的包括：模型名听起来更新、演示更好看、某次聊天感觉更聪明、竞品宣传参数量更大。升级必须带标签：谁升的、升到哪、花了多少、有没有回头对照。

降级的合法理由也只有三条：请求含禁止出域字段；云端限流、超时或区域故障；该任务在评测集上本地已经够用。降级不是认输。分类、抽取、向量化这三类任务，长期放在本地几乎总是更划算。降级路径要预先写好：规则、缓存、排队、人工，而不是临时在捕获异常时返回“稍后再试”。

向量化与重排值得单独说一句。它们是高 QPS、模型小、几乎不该走云端按词元计费的典型任务。很多团队用旗舰聊天模型做嵌入，质量和成本都会同时变差。嵌入模型默认本地，生成模型再按档位路由，这是混合架构里最先应该切开的一刀。

（三）没有对照集就没有选型

1. 样本、指标与流水线

评测门禁的最低配置并不奢侈：两百条样本、四个指标、三类必跑时机。样本配比可以用清晰可抽取四成、模棱两可两成、需检索才能答两成、应拒答或含敏感一成、工具选择易错一成作为起点，再按自己的工单分布调整。四个门禁指标是字段级准确、带引用的可采纳率、工具选对率、禁止出域泄漏率，任一回落超过阈值即阻断。三类必跑时机是换模型或换量化或换提示词、换端点方言或参数默认值、路由规则或脱敏规则变更。不要等用户投诉才发现回落。评测流水线与发布流水线解耦，避免门禁把常规发布拖成通宵。

2. 对照时最容易做错的，以及何时必跑

对照时最容易做错的三件事：用聊天观感代替指标，演示三轮很好看，两百条里字段准确可能已经掉了八个点；用供应商排行榜代替自己的集，排行榜的任务分布很少等于你的工单分布；只对比平均值，崩溃藏在切片里。

2.1 必跑的改动

换云端旗舰型号必跑，本地 Q8 改 Q4 必跑，提示词加一句约束必跑——约束能同时提高拒答率与降低幻觉，方向事先不知道。

2.2 抽测与不必全量的改动

只改接入层超时抽测即可，扩容一块同型号 GPU 不必全量质量回归。超时会把成功变成失败，影响可采纳率，所以仍要抽测；同型号扩容只改变容量，质量不应变，跑一组延迟与并发回归即可。

四、隐私：出域不等于泄密，不出域也不等于安全

（一）数据出域有三条路径，风险并不相同

1. 提示词出域、留在域内、专有云

第一条路径是提示词出域。用户原话、检索片段、工具结果进入供应商日志与上下文缓存。这是最常见、也最容易被忽略的一条。对策是发送前脱敏、字段白名单、合同约定不用于训练、留存周期写死。

第二条路径是权重与日志留在域内。推理在机房，提示词仍可能进日志、进核心转储、进共享显卡的其他租户。“本地”不是免责声明。对策是日志脱敏、禁止把原文打到信息级日志、GPU 隔离、访问审计。

第三条路径是专有云或 VPC 推理。权重在供应商托管的专属租户，网络不出你的专线或对等连接。合同与审计要单独谈，不能套用公有模型即服务的默认条款。

2. 真正敏感的不是模型在哪

工单助手里真正敏感的不是“模型在哪”。手机号、身份证、银行卡、收货地址、内部风控评分——这些字段一旦进入提示词，就进入了模型上下文，可能进入下一轮对话，可能被工具回传放大。所以第一问不是本地还是云端，而是：这些字段有没有必要出现在提示词里。能在检索层过滤掉的，就不要送到生成层；能哈希或掩码的，就不要原文。

3. 传输、处理、留存要分开谈

合规上要分开的三件事是传输、处理、留存。传输问是否 TLS、是否专线、是否出境。处理问供应商是否将数据用于训练、是否有子处理方、区域是否可选。留存问日志、缓存、标注集各留多久，谁有权查阅，如何删除。这三件事在云端默认条款里往往写在不同文档。落地前应取得书面确认，而不是只看产品页上的企业级安全徽章。

（二）四道闸门必须装在接入层

识别、分级、处理、审计，四道闸门顺序执行。识别用规则加小模型预检，覆盖手机号、证件、卡号、地址，漏检比误杀更危险，结果写入请求标签。分级由数据所有者定义公开、内部、受限、禁止出域，分级决定能不能升云；分级是数据的属性，不是模型的属性。处理是掩码、哈希、删除、改写，能不送就不送，必须送的用可逆令牌，令牌表不出接入层。审计记录谁、何时、哪条链路、哪一档，发送前的指纹而不是原文，五分钟内能还原一次调用，保留周期按密级分。

提示词里写“请忽略隐私信息”不是闸门。模型会忽略这句话，字段却已经出域了。识别可以错，但必须可观测：漏检率进门禁，误杀率进体验指标。分级必须由数据所有者定义，开发不能现场拍板“这张工单看起来不敏感”。处理必须可测试：给定一段含手机号的文本，断言出域载荷里不再出现原文。审计必须能回答：上周三谁把这批客户联系方式送进了哪一个端点。

敏感字段在日志里的处理，与接口响应里的处理，应当用同一套类型口径。手机号、身份证、银行卡、姓名、邮箱、地址，各自有明确的掩码方式；密钥、令牌、连接串禁止出现在配置文件与代码仓库。这些不是云端特有的要求，本地推理网关的访问日志同样适用。本地如果把提示词原文打进信息级日志，隐私账本上并不比把原文送给供应商更好看。

（三）合同、留存与审计是三页纸，不是一枚徽章

云端隐私真正要谈的是训练使用权、区域与出境、留存周期、子处理方、删除与导出、事故通报。谈不下来时，工程对策分别是默认按“会用于训练”设计并脱敏后再发送、禁止出域的任务不升云、接入层不落原文只落指纹、把子处理方写进评估表、自己保留可删除的审计索引、自己的检测不能只靠对方通报。

本地并不能跳过这张表。把模型放进机房之后，训练使用权变成“谁能把日志导出到笔记本”；区域变成“这台 GPU 是否与其他业务混部”；留存变成“推理网关的访问日志有没有原文”。差别只在于：云端的对手是供应商法务，本地的对手是自己的运维习惯。后者往往更松。所以隐私条款应该写成一份对内对外通用的清单。本地勾自建、云端勾供应商，但每一行都要有人签字。

五、延迟：拆成三截，才能决定超时写多少

（一）网络、排队、生成，三种口径不要混用

1. 三截各自计什么

1. 三截各自计什么

网络往返在云端是公网或专线的几十毫秒，本地内网通常小于五毫秒，TLS 握手、DNS、代理都算，流式连接建立也算一次。排队与调度在本地是显存槽位满了就排，在云端是限额、区域容量、限流，这一截随并发非线性上升，P95 比均值敏感得多。生成分为首字与后续：首字是预填充加调度，后续是每词元耗时乘以长度，长输出把整段延迟拉长。流式只能改善体感，改善不了完成时刻。

坐席体感主要由首字决定；落库与超时主要由整段决定；批处理只关心完成时刻。三种口径不要混用一张图。Java 同步调用占用线程的时间跟的是整段，流式接口何时写出第一字节跟的是首字，超时预算必须按尾延迟来设。

2. 本地并不总是更快

2. 本地并不总是更快

一个反直觉的事实：在交互式工单里，本地并不总是更快。模型更大、量化更低、显卡更旧时，生成本身可以吃掉网络省下来的那几十毫秒，还倒贴。所以“本地一定低延迟”只在“模型档位相当、显卡不排队”这两个前提下成立。选型对比必须在目标并发下测，而不是在空闲开发机上测。Java 同步请求线程被整段延迟占满。首字再快，只要接口是阻塞的，两百个坐席同时点发送就会先打满你的线程池，而不是先打满 GPU。

（二）两条曲线：并发爬升与输出变长

把同一条抽取请求放到两条延迟曲线上看，形状会把口号拆掉。首字延迟在低并发时本地更快，槽位满后陡升；云端基数更高，爬升更平。那个陡升点就是你该扩卡、限流或把溢出切到云端的位置。整段延迟随输出变长时，本地中档在短输出上占优，云端旗舰在长输出与工具调用上占优。短抽取任务里旗舰只是更贵、未必更快。

数字是量级示意。真正要画的是你自己的两条曲线：横轴用你们的峰值并发和平均输出长度，纵轴用 P95。Java 侧如果用阻塞调用，左图的陡升会先表现为线程池耗尽，再表现为 GPU 排队——排障时不要看反了。很多“本地变慢了”的事故，根因其实是应用线程池先死，推理进程还很空。

（三）超时必须写成一条链

业务截止、接入层、端点 HTTP、流式空闲，四次时钟职责不同，超时也不同。业务截止按坐席可感知的数秒来，超时之后返回可编辑草稿或转人工，严禁把超时当成功空串。接入层比业务截止更短一截，超时之后换备用端点或降档，严禁无限重试把峰值放大。端点 HTTP 再短一截，超时之后取消请求、释放线程，严禁等连接池自己耗尽。流式空闲按连续数秒无增量切断，记一次半失败，严禁一直挂着占线程。

本地超时的典型原因是显存槽位满、模型刚被换出内存、上下文被开到窗口上限。对策是限制上下文、限制并发、预热、把溢出切到云端，而不是把超时调到六十秒。云端超时的典型原因是区域限流返回慢错误、长工具循环没有被你的上限刹住、公网抖动叠加会话复用失败。对策是区分各类状态码，有的该换区域，有的该排队，有的该降档，不要用同一套重试对付所有失败。

六、并发：真实容量单位是槽位，不是 QPS

（一）本地卖显存，云端卖限额

1. 两边的容量单位

1. 两边的容量单位

一块消费级卡同时能跑的请求数，往往是个位数到十几。连续批处理把槽位利用率打上去，开发机上的本地进程默认更接近“来一个处理一个”。上下文越长，槽位越少，这是非线性的。扩容路径是换更大显存、多卡、降量化、降窗口。云端则同时存在每分钟请求数、每分钟词元、并发连接三种限额。突发可以被吸收，但有冷却和排队。同一区域的容量是共享的，故障日大家一起挤。扩容路径是提额、多区域、多供应商、降档分流。限额打满时的错误码必须被翻译成你的拒绝语义。

2. 为什么应用层压测会测错

2. 压测为什么会测错

Java 团队最容易犯的错：用压测工具把 QPS 打到应用层还能响应，就宣布模型层也能扛。应用层有线程池和连接池，模型层的槽位比这薄一个数量级。正确的压法：把并发加到槽位打满，观察拒绝码、排队和 P95，再决定是扩卡、限流还是溢出到云端。容量规划的输入不是平均 QPS 乘以平均时长，而是同时在生成的请求数乘以平均上下文。后者才会碰到显存。

P95 突然翻倍，在本地通常意味着槽位耗尽开始排队，在云端通常意味着限额或区域抖动。大量拒绝码，在本地是推理引擎主动拒绝，在云端是供应商限流。首字变慢、整段还行，多半是冷启动或换出内存。短请求也变慢，多半是长请求占满批处理窗口，或被大客户挤占容量。这些现象都应该先映射到槽位，再映射到应用线程。

（二）排队、批处理、拒绝，三种消化方式要显式

能排队的不要打满线程；能批处理的不要来一条推理一条；该拒绝的不要默默拖到超时。排队时请求进有界队列，队列深度就是你对外的等待承诺，深度要按延迟预算反推，超时的请求要从队列里拿掉。连续批处理是机房集群的主战场，短请求不要和长请求混池，长请求会拖累短请求，要用分桶或优先级。拒绝是保护不是故障：队列满或槽位满时立刻返回可识别错误，让接入层决定降档、切云端还是转人工。把拒绝记进指标，比把超时记进平均值更诚实。

和 Java 线程池的对应关系几乎一一映射。推理侧的槽位相当于最大工作线程，等待队列相当于有界阻塞队列，拒绝相当于中止策略。差别在于：线程池耗尽时，你还可以降级成不调用模型、走规则；GPU 槽位耗尽时，本地没有魔法，只能拒绝或往云端溢。因此接入层必须同时看到两张容量图：应用线程池和水线、推理槽位和水线。只盯着容器的两百个请求线程，会在 GPU 早已经打满的时候还往里灌。有界队列是红线。无界队列会把延迟预算吞掉，最后表现为偶发超慢，排障极难。夜间批量摘要与白天坐席请求不要进同一条队列。批量可以等，坐席不能等。分队列比分模型更先要做。

（三）不要用业务线程去等生成

同步阻塞适合内部批处理与短抽取，风险是坐席高峰打满请求线程，必须配独立线程池与有界队列，超时用带截止时间的获取。虚拟线程可以降低占用，降不了 GPU 排队。流式写出适合回复草稿与长解释，收益是改善首字体感，代价是连接更长，超时要按空闲切，且与结构化一次返回冲突；取消必须一路传到端点，否则槽位泄漏。异步隔离是生产默认推荐：业务线程只提交，工作池执行，队列满立刻失败，不阻塞对外接口，观测把提交等待、执行、写出三段分开。

线程池必须显式配置核心数、最大数、有界队列、拒绝策略，禁止用工厂方法创建无界池，禁止在业务代码里为一次调用临时建池。满则拒绝，拒绝走溢出路由，不要让调用者线程去跑推理。不要在控制器线程里直接阻塞到整段结束。这些是 Java 并发的红线，在模型接入层同样成立，只是被打满的不再只是 CPU，还有 GPU。

七、部署成本：交叉点按任务画，不要画一张总图

（一）两套账本，同一条时间轴

本地账本按月看折旧、电与机位、值班人天、失败占用的容量、空闲。云端账本按月看词元费、超额与突发、失败重试放大、密钥与限额维护、评测回归。一次成功抽取，本地付的是槽位时间加电，云端付的是输入加输出词元。一次失败重试，本地再占一次槽位，云端可能再付一次全额。一次评测回归，本地夜间可消化，云端按条计费要进预算。一次峰值小时，本地可能拒绝或排队，云端可能涨到限额。一次空闲夜晚，本地折旧照计，云端接近为零。

单位业务成本等于该任务当月全部费用除以当月成功工单数。不要用单次调用单价代替它。成功工单数做分母，是为了把失败、评测、空闲都摊进去。只拿成功调用的单价比，本地永远显得更贵，云端永远显得更便宜，或反过来——都是错觉。

（二）交叉点演算要带五个修正

1. 曲线只说明方法

示意曲线上，云端近似线性，本地高固定、缓升，中间有一个交叉点。交叉点左边云端更划算，右边本地更划算。方法对，报价单不对——你要用自己的折旧与词元单价重画。

2. 演算必须带上的五个修正

五个修正缺一不可。调用量用成功业务量，不是 HTTP 次数，一次工单可能触发分类、抽取、检索、草稿四次调用。本地曲线要加空闲，单班坐席的卡夜间是空的，交叉点会右移。云端曲线要加失败放大与评测。质量差如果导致坐席返工，返工工时比词元费贵，交叉点可能根本不存在——该用云端的任务就不要为了过交叉点硬搬回来。向量化、重排这类高 QPS 小模型，交叉点几乎总在很左边，应默认本地；旗舰推理的交叉点可能永远到不了，应默认云端。按任务画，不要画一张总图。

（三）隐藏成本在账单上看不见

失败放大、评测与回归、提示词膨胀、人员值班、切换与锁定、质量返工，这六笔在本地和云端都会出现，只是科目名字不同。超时重试、工具循环、用户连点，在云端直接变成现金，在本地变成槽位被无效占用。门禁每月都要跑。检索片段、对话历史、工具结果会让输入词元往往比输出更贵，两边都要做预算裁剪。本地要懂驱动与权重的值班，云端要懂限额与故障通报的值班，都不是零运维。云端默认值一变全链路回归，本地驱动一升可能全体停，退出成本要提前记账。坐席改草稿的时间、错误承诺的客诉，常常是最大的隐藏项。

把这六笔写进成本模型之后，很多“本地一定更便宜”或“云端一定更贵”的结论会翻转。翻转不是坏事。它说明原来的结论建立在不完整的账本上。工程上最有效的降本手段往往不是换部署位置，而是缩短提示词、刹住工具循环、把分类留下本地、把失败变成可识别的拒绝而不是重试。这四件事在两种部署形态里都成立，应该先做。

八、运维复杂度：复杂度不能消灭，只能决定由谁承担

（一）六件事，两边各有一份值班表

1. 值班表要对齐

版本、容量、观测、发布、故障、人员，本地和云端都要有人接。本地面对的是权重文件、量化档、推理引擎、驱动，云端面对的是模型名、接口版本、默认值变更公告。本地看可分配显存、槽位、换入换出，云端看延迟分位、限流、区域失败。本地金丝雀一张卡再扩到池，云端按流量百分比切模型名。本地故障是卡挂、驱动挂、进程内存耗尽，云端故障是区域挂、限流、内容过滤误杀。人员要求分别是会看显卡状态的值班，和会看供应商状态页的值班。

2. 两边各自容易低估什么

本地运维最容易低估的是：驱动、推理引擎、权重三者必须作为一个版本一起发布，只升其中一样，故障无法回滚到可复现状态；显存碎片会让“还有空闲”的卡跑不进新请求，观测要看可分配显存，不只看利用率百分比；模型文件分发不是一次拉取，校验和、灰度、回滚都要有。云端运维最容易低估的是：默认值变更不会发破坏性变更公告，温度、最大词元、内容过滤阈值都可能静默变化；状态页说正常，你的区域仍可能局部拥塞，自己的探测比状态页更早；密钥轮换、限额告警、模型名废弃，都是你的发布日历，不是供应商的。

（二）把权重当成发布物，而不是网盘文件

版本坐标是三元组：任务档位、端点、权重哈希或模型快照号。调用必须带齐，日志、评测、回放都靠它对齐。发布动作是先在影子流量上打分，过门禁再切一小股流量，观察延迟与拒答切片，异常则一键切回坐标，禁止先全切再看聊天效果。回滚动作是本地保留上一份权重与引擎，云端保留上一档模型名，路由规则本身也要版本化。回滚时长是运维指标，目标是十分钟内回到上一坐标。

一次调用落库的最小版本字段还应包括路由规则版本、提示词版本、脱敏规则版本、门禁是否通过、影子分、流量桶。缺任何一项，三个月后都无法回答“那天为什么变笨了”。云端尤其如此：供应商把模型名留着、把背后的权重换了，你若没有自己的快照号与影子分，事故会变成无头案。

（三）故障域要错开，主路径必须能降级

本地故障域是单卡、单机、单交换机、单机房电力，爆炸半径是这一池子的所有任务，恢复动作是重启、回滚权重、切到云端溢出。你能做冗余卡、分池、预热、自动切流，做不到让一块卡在过热时仍保持原槽位。云端故障域是区域、账号限额、内容过滤策略、上游容量，爆炸半径是所有升云流量，恢复动作是换区域、换模型、降回本地、转人工。你能做多供应商、探测、缓存、降档，做不到让对方的区域立刻好起来。

所以混合不是“两个都用更安全”，而是“两个故障域不要重叠在同一条不可降级的主路径上”。本地抽取的备用是规则模板或上一版缓存，禁止只有一块开发机上的进程。云端草稿的备用是本地中档草稿加坐席编辑，禁止只有一个区域的一个旗舰名。工具处置的备用是转人工确认，禁止模型直接打生产写接口。夜间摘要的备用是积压到次日低峰，禁止必须在高峰与坐席抢槽位。

九、Java 接入层：换模型不该换业务

（一）同一套客户端，两套端点

1. 兼容方言作为默认

Spring AI 允许原生对接本地进程，也允许把本地推理伪装成 OpenAI 兼容端点。生产默认更推荐后者：基址指向集群的/v1，密钥可以是占位，模型名写入版本坐标，专有项走额外请求体。官方接口会拒绝未知字段，兼容端点才会吃。云端用同一套属性、不同的基址与密钥。不要在业务代码里用条件分支切换这两段，用两个命名的聊天模型 Bean 加路由。

2. 多 Bean、测试替身与密钥

两个起步依赖会注册两套自动配置。直接注入单个客户端必冲突。为每个端点声明命名 Bean，路由层按任务档位选取。测试里用脚本替身替换这两个 Bean，不要在单测里真打 GPU 或公网。原生本地起步依赖适合开发机最小可用，以及确实需要专有选项的场景；生产集群更建议兼容端点，让本地与云端说同一种方言。

密钥、令牌、连接串禁止硬编码。云端密钥进凭据服务，本地内网端点进配置中心，都能刷新、都能轮换、都能审计。日志里打印请求对象时，必须走脱敏，不能把提示词原文、手机号、证件号打出去。这些要求与是不是本地无关。

（二）路由层把选型做成运行时决策

输入是任务档位、数据密级、本地健康度与排队、云端限额剩余、该请求的截止时间。规则顺序执行：禁止出域则只走本地或拒绝；本地熔断则允许出域的升云；质量门禁该档本地已够则维持本地；截止时间不够走旗舰则降档或转人工；其余按影子分与成本阈值。输出是端点加版本、是否脱敏后再发、超时链、失败时的下一跳、记账标签。

路由规则必须可测试：给定密级、健康度、剩余预算，断言走哪一端。不要把规则写在注释里。影子流量是路由的方向盘。没有影子分，路由会退化成“本地挂了才切云”，那只是故障转移，不是选型。密级一票否决必须有审计字段证明请求没有出域。本地错误率在短窗口内越过阈值，熔断开，允许出域的切云。抽取字段准确的影子分仍高于门禁，就不要因为演示更好看而升档。排队预计超过剩余预算，短任务切云或降档，长任务转人工。云端持续限流，则回本地并限流入口。

（三）失败语义对齐，两边不能各说各的错误

业务只认五类结论：可重试瞬时、应降档、应拒绝、应回滚、成功但低质。典型本地原因分别是槽位短时打满、该模型不会填枚举、禁止出域且本地挂、权重损坏或驱动不匹配、量化过低或窗口截断。典型云端原因分别是限流与区域抖动、内容过滤误杀、账号停用或密钥失效、模型名下线、默认温度被改。调用方该做的分别是退避一次并计入放大、换低档或规则、转人工不要重试、切上一坐标、不落自动处置并进抽检。

翻译层有三条纪律。不要把所有服务器错误都变成同一类运行时异常，调用方无法决定是该等、该换还是该停。不要把模型说无法回答翻译成成功状态再让前端当成功展示，拒答是一种明确结论，要有自己的码。不要在业务包里解析供应商的错误体，今天本地返回加载失败，明天云端返回内容过滤，后天集群返回空选项——解析逻辑必须停在适配器。每一次翻译都要保留原始码在审计字段里，排障需要，业务分支不需要。

十、三种形态各自的落地边界

（一）开发机上的本地进程

它擅长拉权重、换模型、看对话，给单测和联调一条真链路，验证提示词和结构化输出，在无公网环境工作，让新人建立对模型的手感。它不擅长高并发连续批处理、稳定的多卡调度、和生产一致的限流码、细粒度的槽位隔离，也不适合作为唯一生产推理层。Java 对接时基址指向本地端口，生产请改走兼容路径，保活避免冷启动，不要在生产自动拉取权重，模型名写进版本坐标。

个人开发能用而且应该用，固定一个量化档写入项目文档。集成测试能用，用测试容器，禁止测试去打开发者笔记本。预发小流量要谨慎，流量一过槽位就迁到集群引擎。生产坐席不建议作为主路径，可以留作开发与应急演示，不接流量。生产批处理不建议，批处理更吃批处理引擎的利用率。最小可用有边界，越界的代价是把联调手感当成容量规划。

（二）机房推理集群

连续批处理、兼容入口、量化与切分、多卡与隔离、预热与保活、观测四件套，这六件事构成“本地生产”四个字的通常含义。多路解码共享一次前向，短请求不要和长请求混池。Java 侧几乎不必换方言，工具调用、流式、用量才能对齐，退出成本才低。每一次量化或张量切分都等于换模型，必须重跑门禁。一张卡一个池或硬件级隔离，禁止无关业务抢同一张卡，故障域才能切开。进程起来不等于能打满，首批请求会特别慢，发布流程要含预热。可分配显存、槽位、首字延迟、拒绝，缺一件就会误判扩容，和应用指标分开看板。

集群形态的决策标准不是“我们买得起卡”，而是“我们组织得起值班、版本和容量规划”。买得起但值不了班，最后会退化成一台一直开着的昂贵开发机。Java 应用与推理集群必须分池部署。把推理引擎塞进同一个容器，驱动和虚拟机发布会互相拖累。接入层只通过内网负载均衡看见它。这样扩卡、换权重、滚版本都不必动业务发布。

（三）云端模型即服务

你买到的是旗舰档的指令遵循与工具能力、突发弹性、多区域与内容安全基线、不必自己管驱动、新模型的第一周可试用。你买不到的是提示词不出供应商边界、默认温度与过滤阈值永不变、无限额永不限流、与本地完全一致的错误码、对内部术语的开箱即懂。Java 侧必做密钥进凭据服务、限额与费用告警、区域与模型名可配置、内容过滤误杀可观测、合同条款对过评测集。

选型时把云端拆成三问。质量问：在我的评测集上，它比本地中档高出的那几分，值不值得按词元付。弹性问：我的峰值是短时的还是全天的，短时峰值适合云端，全天高位更该算交叉点。约束问：出域、留存、区域、子处理方，法务能不能签，签不了就不要用演示环境的密钥直接上生产。三问都通过，云端是加速器。任一问失败，云端只适合做对照和溢出，不适合做主路径。专有云推理可以回答其中的约束问，但通常回答不了弹性问的全部，也回答不了零运维。把它标成第三种形态，不要混进纯云端里比较。

十一、混合路由：把两行写进同一张可测试的表

（一）四种健康形态，外加一种不健康

1. 四种健康形态

按任务分工：低档本地、高档云端，最常见、最好测，边界写在档位表上。按密级分工：禁止出域走本地，公开内容可升云，密级来自数据而非模型。按健康度溢出：本地熔断才切云，这是备援不是选型，必须限速避免雪崩。按影子分对照：双跑一小股流量，分差稳定再切主路径，用来做真正的选型。第五种不健康是在同一段业务代码里随机挑一个端点：无法回归、无法记账、无法解释事故。

2. 叠加之后仍然要可测试

四种形态可以叠加：密级一票否决，任务给默认端点，健康度负责溢出，影子分负责调默认。叠加之后规则仍须可列表、可测试、可版本化。叠加到人脑已经算不清，就该收回去。按任务要有每档一条固定样本的端点断言，最容易做错的是把草稿和抽取塞进同一档。按密级要有含个人身份信息的样本禁止出现云端审计，最容易做错的是密级在提示词里口头声明。按健康度要注入本地失败并断言切流且限速，最容易做错的是失败即全量切云打爆限额。按影子分要看对照窗口内分差的置信区间，最容易做错的是样本太少就把主路径切走。

（二）熔断与回退，探活用合成请求

闭合态走主路径，打开态走备用路径，半开态放一小股探活。进入打开的条件是窗口内失败次数超限，离开靠冷却时间。半开探活成功则闭合，失败则打开。本地探活不能用真实请求。真实请求带着用户数据，也带着延迟预算，用它探活等于让坐席当健康检查。探活应用固定的合成请求：短提示、已知输出、不含个人身份信息。探活失败不要重试用户请求，直接走打开态的备用路径。探活成功也不要立刻全切，按百分比爬升。

云端作为备用时必须自带限额。本地一熔断，全部流量冲进云端，会把限额打满，备用路径也死。备用路径要有自己的每秒上限、词元预算、熔断器自己的错误率。超限的请求转人工或规则，不要排队到业务截止之后。这是混合架构最常见的二次事故。两次故障叠在同一分钟里，比单边故障更难排：日志里既有本地槽位耗尽，又有云端限流，根因其实是切流没有限速。

十二、判定、误区与落地节奏

（一）逐项判定随任务翻转

在工单助手这个场景里，指令遵循与抽取在清晰样本上接近、模棱两可时云端更稳；工具选对在工具面一宽时本地掉得更快；隐私可控本地默认更强、云端靠合同补；交互首字在低并发且不排队时本地占优；峰值弹性云端显著更强；单位成本在高稳态过交叉点后本地更稳，在低流量时空闲会惩罚固定投入；运维负担本地留给自己；上线速度云端第一周一定更快；退出成本可以用兼容端点把两边都压下来。

条形是相对判断，不是基准测试得分。换一个项目，至少三项会翻转：纯内网批处理会让弹性不再重要；纯开放内容会让隐私不再一票否决；工具面极窄的抽取会让云端的工具优势用不上。所以这张图只能当工单助手的起点，不能当通用排行榜。你要画的是自己那十行。

（二）十二条误区，共同特征是跨维度挪用优势

本地一定更快——空闲时成立，槽位满时不成立。本地一定更安全——日志、混部、未脱敏提示词仍在。云端一定更贵——低流量、含返工时往往更便宜。参数量大一定更好——抽取和分类经常相反。开发机进程能生产——能联调不等于能扛坐席。换配置就能换模型——窗口、默认值、错误码仍会穿透。提示词能当脱敏——字段已经出域了。平均延迟能指导超时——必须用 P95 和超时占比。QPS 能代表容量——容量单位是槽位。混合一定更稳——两个故障域叠加会二次事故。评测集可以上线后再建——没有对照就没有选型。法务徽章等于合规——训练、留存、子处理方要逐条签。

误区的共同特征是：把一个维度上的优势，当成了所有维度上的结论。纠正方法也很简单：回到六张表，每一张表用自己的口径说话，不允许用质量赢来给隐私免责，不允许用隐私赢来给延迟免责，不允许用延迟赢来给成本免责。

（三）四阶段落地，对照先于固定资产

1. 四阶段与出口判据

对照周固定评测集与字段契约，云端旗舰与本地中档各跑一遍，出口是四张切片表而不是观感。接入周做门面、脱敏、超时链、用量字段，两个命名聊天模型，禁止泄漏到业务包，出口是单测不打真模型也能过契约。小流量周按对照结果选定主路径，影子流量继续打另一侧，出口是 P95、拒答、泄漏率达标。混合周只上必要的路由规则，熔断、限速、人工回退齐套，出口是故障演练能在十分钟切回。

2. 不要提前做的事，以及两种收敛

不要在第一周同时买卡、签云端合同、写路由引擎。对照周可以开始写评测集、接两个端点的最小调用，不要提前买一架子卡、签多年合同、上多智能体。接入周不要在业务包里写死模型名。小流量周不要全量切旗舰先看效果。混合周不要随机分流，也不要无合成探活的自动切流。

如果对照周已经显示本地中档在抽取上不差、云端只在高档工具调用上领先，那么你可能永远不需要自建推理集群——低档用开发级本地或小卡，高档用云端，中间加脱敏。反过来，如果全天稳态并发已经高、数据基本禁止出域、评测集上中档够用，交叉点会很靠左，这时再谈买卡才有意义。节奏的要点是：先产生对照数据，再产生固定投入。倒过来是最贵的一种冲动。

十三、一页总览

（一）十条主干判断

十条主干判断可以收在一页上。对照必须有评测集，没有切片表，选型只是口味。任务先分档，分类、抽取、草稿、处置不是同一档模型。抽象停在接入层，业务包里不许出现供应商类型。隐私看路径，出域、留内、专有云风险不同。闸门在发送前，提示词不是脱敏。延迟拆三截，网络、排队、生成分开看 P95。容量单位是槽位，不是应用层 QPS。成本看单位工单，空闲、失败、返工都要进分母。混合必须可测试，熔断带限速，探活用合成请求。版本是发布物，权重、提示词、路由规则一起回滚。

（二）路由表代替立场

对 Java 应用来说，真正要设计的不是站队，而是一条带密级、档位、健康度与账单标签的路由。评测集给出质量，闸门给出隐私，槽位给出并发，交叉点给出成本，值班表给出运维。六张表齐了，选型自然收敛。缺任何一张表，争论都会回到口号。

能在开发机上跑通，只证明协议是通的。该不该本地，要看这六张表在你的工单分布上怎么填。能调通云端旗舰，只证明质量上限买得到。该不该上云，同样要看这六张表。两边都能跑，并不自动等于两边都该跑；两边都该跑的时候，也并不自动等于随机挑一边跑。路由表代替立场。这就是这篇选型文章想留下的全部东西。

参考资料

（一）框架、方言与本地推理

• Spring AI 参考文档：Ollama 聊天模型
• Spring AI 参考文档：OpenAI 聊天模型（含兼容端点与额外请求体）
• Spring AI 入门与 BOM
• Ollama 官方文档
• Ollama 模型库
• vLLM 文档：OpenAI 兼容服务器
• vLLM 文档：连续批处理与性能
• Hugging Face Text Generation Inference
• SGLang 文档
• llama.cpp 仓库

（二）质量、延迟与容量口径

• NVIDIA 开发者博客：大模型推理的吞吐与延迟
• OpenAI API 参考：聊天补全
• LangChain 文档：模型评测思路（可与自建门禁对照）
• RAGAS 评测框架
• Prometheus 客户端 Java
• Micrometer 文档
• Resilience4j 熔断器

（三）隐私、合规与安全工程

• OWASP LLM 应用十大风险
• NIST 人工智能风险管理框架
• 国家互联网信息办公室：生成式人工智能服务管理暂行办法
• 个人信息保护法（中国人大网）
• 欧盟通用数据保护条例门户
• Microsoft Learn：云端与本机 AI 模型的选择
• Spring Security 参考文档

（四）成本、混合架构与工程讨论

• 混合云边推理：延迟、隐私与成本的权衡
• 阿里云开发者社区：本地部署与云端调用的综合考量
• 本地部署 Ollama 与 Spring AI 的最小可用方案
• Spring AI 接入多家模型的配置讨论
• 云模型与本地模型的企业架构选择
• 端云双轨路由与熔断降级的工程拆解
• OpenTelemetry 文档
• JDK 21 虚拟线程（JEP 444）