- 博客(66)
- 收藏
- 关注
RSS订阅原创 大模型备案材料清单逐项拆解（含易被退回的 8 处）
很多团队第一次做大模型备案，把材料当成一份"填表作业"：目录列了十几项，逐项填完、盖章、打包提交，然后等结果。结果往往是被退回，理由还常常只有一句"材料不完整"或"说明不充分"。安全评估报告里说"已建立内容审核机制"，那制度文件里就得有对应的审核流程，日志里就得有对应的记录，人员名单里就得有对应的岗位。：材料中主体名称出现两种写法（如"XX科技有限公司"与"XX科技有限责任公司"），或分支机构与总公司混用。主体资质证明"谁在负责"，模型与数据说明"管的是什么"，运行保障证明"日常真的在管"。
2026-11-11 14:13:56
416
原创 AI 生成内容的标识落地：水印、元数据、用户提示三件事
AI 内容标识不是加一个角标，而是一条从生成前提示、到内容渲染、再到文件元数据的完整链路。水印解决"看得见"，元数据解决"查得到"，用户提示解决"说得清"。C2PA（Content Credentials）是目前较有影响力的内容来源与编辑历史标准，用密码学签名把"谁生成、谁编辑过"写进清单。本文把这条链路拆成三件事：水印、元数据、用户提示，并给出可落地的检查点。一个常见的坑：只在预览页加水印，用户点"下载原图"拿到的是无水印版本。用户提示是最"软"的一环，但直接影响合规判定和用户感受。
2026-11-10 07:52:43
518
原创 GB 45438 深度合成内容标识：显式标识与隐式标识怎么做
随着生成式 AI 与深度合成技术的普及，一段文字、一张图片、一段音视频，都可能由模型生成或经过模型改写。真正容易出问题的地方，往往不是"要不要做"，而是"做在哪、做得够不够牢"。把标识写入纳入生成流水线的固定环节，覆盖全部内容形态，并保证标识在导出、转码、二次分发后依然存在，才是合规落地的关键。本文围绕"落地位置、技术实现、常见漏项"三个维度，把两类标识讲清楚，并给出可执行的工程实践建议。显式标识的关键是"在用户接触内容的场景中，以可感知的方式提示"。二者不是二选一，而是需要同时落地、互相配合。
2026-11-09 08:35:16
592
原创 B2B2C 模式：谁是服务提供者，谁承担备案义务
若甲方对服务形态作出实质性变更（包括但不限于更换底层模型、新增面向公众的功能模块、调整内容生成策略、变更服务对象范围），导致原备案覆盖范围不再适用的，甲方应及时重新履行备案义务；向公众提供生成式 AI 服务，它在监管视角下就是服务提供者，需要履行相应的备案/登记、安全评估、内容标识等义务。如果渠道商在调用 API 的基础上做了产品化包装、面向公众开放，那它就已经是服务提供者了，不能因为「底层模型不是我训练的」而主张自己不承担义务。模型方说：「用户是你们签的，钱是你们收的，服务是你们提供的，备案该你们来。
2026-11-06 08:48:46
566
原创 面向公众 vs 仅供内部使用：合规义务的分水岭在哪
面向公众提供服务时，往往需要向用户明确告知：这是什么服务、由谁提供、使用了什么技术、可能带来什么风险、用户有哪些权利。在讨论 AI 合规时，绝大多数团队的第一反应是"我们要满足哪些要求"：要不要做备案、要不要做内容审核、要不要做算法说明、要不要做安全评估。只要系统允许组织外部的人自行注册、申请账号、使用服务，无论是否收费、无论入口多隐蔽，实质上就已经面向不特定对象提供了服务。内部系统的使用者是已知的、有限的、可追责的，准入控制退化为账号权限管理，内容审核退化为业务复核，机制复杂度大幅下降。
2026-11-05 09:31:02
655
原创 微调、蒸馏、RAG 之后，要不要重新备案？三种改造方式的触发差异
它有自己的权重、自己的参数规模、自己的训练数据（教师模型的输出）、自己的能力边界。它和原模型的关系，类似“二次开发的模型”和“基座模型”的关系。微调的风险点相对“显性”——因为它有明确的训练动作、数据集和产出物，团队在执行时通常有清晰认知，合规人员也更容易被及时纳入流程。——因为它常常被包装成"模型压缩"“性能优化”“成本优化”，听起来像工程手段，不像合规动作。备案关注的核心是"你对外提供的生成式服务是什么"，所以三者都要评估，但评估的落点不一样。RAG 的直觉判断是“我没改模型，所以不用备案”。
2026-11-04 11:19:45
299
原创 开源模型自己部署，算备案还是登记？（附判定流程）
很多团队在内部立项时会有一个默认假设：模型权重是公开下载的，我只是把它部署在自己的服务器上，既没有训练新模型，也没有对外提供 API，那应该不需要走任何合规流程。实际上，如果客户是不特定的、可以自主申请开通的，仍然属于面向公众提供服务。需要说明的是，仅做 LoRA 微调是否算"实质性二次训练"，实操中存在一定弹性，建议以属地网信部门的沟通结论为准，不要自行判断为"不算"。注意，即使基础模型已在境内完成备案，你作为服务提供者仍需以自己主体名义完成登记或备案，不能"借用"基础模型提供方的备案编号直接对外服务。
2026-10-30 10:38:52
548
原创 「舆论属性或社会动员能力」到底怎么判定：一条门槛，同时决定算法备案与安全评估
它的立法出发点是：当算法决定了公众看到什么，算法本身就成了具有公共影响的基础设施，需要被记录、被审查、可追溯。所以备案的对象是「算法推荐服务提供者」，而限定条件是「具有舆论属性或社会动员能力」——因为只有这类服务，算法分发的结果才会外溢到公共舆论层面。判定清楚这条门槛，后续的备案填报、评估报告、整改动作才有明确的边界，也才不会在「要不要做」这个问题上反复摇摆。它的逻辑更直接：具备舆论属性或社会动员能力的服务，一旦被滥用，可能引发群体性事件、谣言扩散、公共秩序风险，因此需要在上线前做一次系统性风险自查。
2026-10-28 08:54:41
472
原创 只调用第三方已备案大模型 API，还需要备案吗？
微调后的模型是否算"你自己的模型"，取决于你是否改变了模型能力并对外提供服务。只调用第三方已备案模型 API 时，通常无需重复办理模型备案，但仍需评估自身是否构成"服务提供者"，并落实内容安全等基础义务。自研并对外提供服务，通常需要完成生成式 AI 服务备案、安全评估，并对训练语料来源合法性负责。很多开发者把"用大模型"当成一件事，实际上从合规视角看，至少可分为三种形态，义务差异很大。只调用第三方已备案大模型 API、不涉及模型训练与对外提供生成式 AI 服务，通常。按服务提供者评估备案与安全评估。
2026-10-27 09:15:28
406
原创 算法备案、大模型备案、算法登记：三轨制到底怎么判
三轨制到底怎么判？不是三选一，而是逐条判断是否触发——一个产品可能同时触发三条轨道；触发条件看"对象"——算法备案看推荐算法，大模型备案看生成服务，算法登记看深度合成；时点和周期差异巨大——大模型备案上线前完成、周期最长，必须最先启动。把第 5 节的流程图贴在立项文档里，把第 3 节的对照表发给产品经理，大部分"要不要备案"的争论就可以结束了。注：本文基于公开法规与实务经验整理，具体备案要求以属地网信部门的最新口径为准。法规和审核尺度会持续更新，建议在正式提交前与主管部门确认。
2026-10-23 11:41:51
703
原创 生成式AI服务上线前的合规清单：9 件事、按顺序做
fill:#333;important;important;fill:none;color:#333;color:#333;important;fill:none;fill:#333;height:1em;1. 明确服务属性与适用法规2. 建立内容安全治理机制3. 完成数据合规与个人信息保护4. 开展算法安全自评估5. 完成算法备案6. 完成安全评估与检测7. 建立用户投诉与举报处理机制8. 制定应急响应与处置预案9. 编制合规证明文件包并归档能力建设主线。
2026-10-21 11:17:40
379
原创 AI 智能体浏览器与桌面终端：用视觉理解解决客服跨系统查询难题
适用场景跨系统、无 API 的"查询-判断-录入"型重复工作（如客服、财务对账、运营报表）；规则复杂但可语义化描述、需要视觉理解的场景；数据敏感、要求本地化部署的行业（制造、金融、政务）。不适用/慎用场景高频、低延迟操作（如每秒多次点击）：视觉模型推理延迟 1.5-3s，不适合实时性要求 < 1s 的场景；强合规审计：虽然我们做了录屏回放，但"AI 自主操作"的合规边界仍需法务确认；页面频繁大改版：虽然比 RPA 抗改版强，但若每周改版，仍需持续维护视觉 prompt。代价与边界。
2026-09-29 08:44:33
367
原创 多模型聚合网关：企业级统一接入的落地实践与踩坑复盘
引入网关的代价：网关本身是新的单点，必须做高可用部署（至少 2 副本 + 健康检查）；LiteLLM 的 Python 实现有约 30~40ms 的自身开销，对延迟极度敏感的场景不友好；Redis 是限流与缓存的命脉，务必集群化并关闭淘汰策略；升级 LiteLLM 版本前需先在测试环境回归厂商适配层，避免上游 API 变更导致兼容性问题。适用场景：多厂商、多模型、多业务线接入的企业；对统一鉴权、审计、限流有强诉求；团队希望快速上线、不愿重复造轮子。不适用场景（不要照搬）
2026-09-29 08:43:20
486
原创 企业知识库 RAG 多路召回与重排：从 38% 命中率到 91% 的工程复盘
单条 query 全链路耗时约 220ms（向量召回 40ms + BM25 20ms + Rerank 150ms + 网络开销），相比之前单路向量召回的 1.8 秒反而更快——因为之前是把 Top-5 直接喂给 LLM，现在 Rerank 后 Top-5 质量更高，LLM 一次就能生成正确答案，减少了重试。早期方案 B 直接把向量分数和 BM25 分数相加排序，结果 BM25 分数普遍偏高，Top-5 几乎全被 BM25 占据，向量召回的语义优势被淹没。向量语义上接近，但 Top-5 里经常排不进。
2026-09-29 08:42:57
476
原创 MoE 混合专家架构落地：从全量激活到稀疏激活的推理成本优化实录
这么做的代价需要重新训练模型，2 周的训练周期和 80 张 A100 的算力投入不是每个团队都能承受的。精度损失虽然控制在 1 个点以内，但对精度极其敏感的任务（如数学推理、医疗诊断）仍然不可接受。引入 aux loss 和共享专家后，训练复杂度上升，需要额外的 profiling 和调参能力。适用场景推理 QPS 高、GPU 成本敏感的大模型服务平台，稀疏激活能直接砍掉一半算力成本。模型本身是 MoE 架构，且 router 训练质量可控（有 aux loss 兜底）。
2026-09-28 09:04:25
329
原创 Agent 智能体工作流编排实践：用 LangGraph 把告警处置从 22 分钟压到 47 秒
2025 年 Q2，我所在的研发效能平台组负责支撑公司 6 条业务线的持续交付。当时最痛的不是 CI/CD 流水线跑得慢，而是线上事故的处置链路太长。以订单服务为例，日均发布 40 次，每次发布后 30 分钟内出现异常告警的概率约为 18%。告警产生后，值班工程师平均需要 22 分钟才能完成"看告警 → 查日志 → 定位代码 → 回滚或修复"这一串动作，而其中约 60% 的时间浪费在"查日志、翻监控、对版本"这类机械操作上。我们最初尝试用传统自动化脚本（Shell + Python 定时任务）做告警后的自动
2026-09-28 09:02:10
348
原创 金融医疗数据脱敏与隐私计算：从字段打码到联邦建模的落地复盘
同一患者在"就诊记录表"和"医保结算表"里，身份证号被脱敏成不同的伪码——因为脱敏服务是无状态的，每次对同一明文生成不同结果。但业务方又要求合作方拿到"能用的数据"——商保要按病种算赔付率，科研要按年龄/地域做统计。——一旦需要还原（比如监管审计要查原始值），只能靠密钥重算，且无法做范围查询（比如"年龄 40-50 岁"没法在密文上直接算）。，原因是双方对"患者 ID"的编码规则不一致（一方用身份证号，一方用院内号）。另外，HMAC 脱敏不可逆，，用 Java 写个脱敏服务，按字段类型打码。
2026-09-28 08:31:04
531
原创 IPD 集成产品开发：信创背景下，软件产品需求评审流程数字化改造实践
IPD 在信创政企软件场景下的落地，不必追求完整理论体系，抓住需求评审、基线管理、变更管控三个环节做数字化改造，就能显著提升需求管理的规范性和可追溯性。需求统一进池，评审设置准入，通过即冻结基线变更必须申请、评估、留痕，形成版本追溯系统设计上，需求管理、评审工作台、基线版本管理三模块闭环落地时重点防范「需求理解不一致」和「基线管控流于形式」两个坑。
2026-09-28 08:24:08
483
原创 P2C 项目到成本：通信政企项目概算 / 预算 / 核算 / 决算四算数字化建模方案
P2C 的本质是以项目为主线的成本管理。传统财务核算以"会计科目"为主线，P2C 以"项目"为主线，把散落在合同、采购、考勤、报销里的成本数据，全部归集到项目维度上。
2026-09-24 08:54:21
267
原创 LTC 流程数字化落地：基于 AI Agent 实现商机自动研判，附系统架构设计
Agent 在 LTC 商机管理中的价值，不是替代业务人员做决策，而是把人从「信息检索」和「经验匹配」中解放出来，让销售和售前把精力放到真正需要人的判断力的事情上——比如客户关系经营、方案竞争策略。打分模型给出的是「参考」，最终决策仍然由评审委员会做出。Agent 辅助研判，人做最终决策。
2026-09-24 08:46:59
581
原创 ITR 落地实践：从工单积压到问题闭环的企业管理改造
最典型的场景：某门店收银机 POS 程序启动报错，门店店长提单后，一线客服判断不了是硬件还是软件问题，先派给网络组，网络组排查后转给应用组，应用组发现是数据库连接池耗尽，又转给 DBA。ITR 改造的本质是管理动作，技术只是放大器——如果团队没有"根因必填、方案必回填"的流程约束，再好的系统也会在三个月后重新变成"转不动的工单池"。召回逻辑：新工单进入后，用 BGE-M3 生成 1024 维向量，在 pgvector 里做余弦相似度检索，取 Top-5 历史工单，把"根因 + 解决方案"直接推给一线。
2026-09-23 11:16:56
563
原创 MaaS 平台架构落地：从单租户网关到多租户模型路由的演进
第三步，模型路由服务每 5 秒从 Prometheus 拉取各实例的显存利用率、GPU 利用率、队列深度三个指标，计算综合健康分，低于阈值（如显存利用率 > 92%）的实例从 APISIX 上游节点中临时摘除。路由服务每 5 秒拉取指标，某实例显存利用率在 91%-93% 之间波动时，会被反复摘除和恢复，导致连接频繁重建。最后一点：健康路由依赖 Prometheus 指标的实时性，指标采集延迟超过 10 秒时，摘除动作会滞后，建议在推理实例侧同时做一层本地限流兜底，避免网关摘除不及时导致实例 OOM。
2026-09-22 08:50:05
512
原创 长上下文与上下文压缩：法律研报分析场景下的工程实践
指标优化前（全量注入）优化后（分层压缩）提升尾部法条召回率61%88%+27pp单份平均耗时38 秒11 秒-71%单份 API 成本2.4 元0.6 元-75%并发支撑能力15 路触发 42945 路稳定运行3 倍同时，Redis 缓存命中后，重复分析同一案件的平均延迟进一步降到 2.3 秒，分析师可以实时交互式追问。文档长度超过模型有效注意力范围（实测约 6 万 token）、且对关键信息召回率有硬性要求的场景——法律、金融研报、医疗病历分析都属此类。
2026-09-22 08:33:44
391
原创 大模型 Agent 自主任务编排：电商客服地址解析从 12% 失败率到 2.1% 的落地复盘
tools.pyuser_id: str = Field(description="用户ID")order_id: str = Field(description="订单号")description = "核验用户身份与订单归属，返回是否匹配"# 调用内部用户服务，返回 "verified" 或 "mismatch"每个 Tool 的 description 要写清楚"什么时候该调用、参数是什么含义"，这直接决定模型编排的准确率。
2026-09-20 09:14:15
380
原创 金融转账“幽灵失败“排查实录：从本地消息表到 Seata TCC 的选型与权衡
分布式事务没有银弹。本地消息表解决"消息不丢"，TCC 解决"业务状态一致"，两者适用边界完全不同。我们这次踩的坑，本质是拿"消息可靠性方案"去解决"业务一致性"问题。适合照搬 TCC 的业务跨系统、跨数据库的写操作，且业务能清晰拆出"预留—确认—取消"三个阶段，比如转账、下单锁库存、积分扣减。对一致性要求高，但能接受"短暂不一致、最终一致"的金融/交易类业务。已有注册中心和配置中心，愿意为 Seata Server 多部署一套服务。不要照搬的业务单库事务或纯查询，本地事务足够。
2026-09-20 08:46:28
226
原创 边缘 AI 推理部署：安防零售场景下的模型裁剪与端侧落地实践
这个方案在 PoC 阶段跑通了，但一上生产就暴露问题——全国门店日均产生约 1.2 亿帧画面，中心集群的 GPU 利用率长期在 92% 以上，排队推理导致平均端到端延迟飙到 4.8 秒，高峰期甚至超过 7 秒。我们的检测任务只有 YOLOv8s 一个模型，单路 1080p 在 RK3588 上 INT8 推理约 28 ms，4 路并发（NPU 多核 + CPU 负载均衡）实测稳定在 35 ms/帧以内，完全满足 3 秒端到端要求。边缘推理不是替代云端，而是「边缘做实时过滤，云端做深度复核」的分层协同。
2026-09-17 08:55:18
283
原创 批流一体架构演进：数据中台实时化改造的落地复盘
口径一致性要求高：实时和离线必须对得上账，比如财务、履约、库存。既有离线数仓又有实时需求：不想推倒重来，希望渐进式演进。团队有 Flink 基础：批流一体本质是 Flink 能力，没有 Flink 经验会陡增学习成本。
2026-09-17 08:42:36
397
原创 HTAP 在实时风控中的落地：从 MySQL 读写分离到 TiDB 混合负载的改造复盘
POC 结果：ClickHouse 聚合查询性能极佳（报表查询从 30 秒降到 1.2 秒），但实时写入链路变长——交易数据要先写 MySQL，再通过 Binlog 同步到 ClickHouse，端到端延迟约 2~4 秒，仍然不满足实时风控的秒级新鲜度要求。TiDB 的 HTAP 架构天然支持"行存（TiKV）处理在线事务 + 列存（TiFlash）处理分析查询"，并且 TiFlash 通过 Raft Learner 实时同步数据，延迟通常在毫秒级。，否则刚发生的欺诈行为在风控规则里"看不见"。
2026-09-16 09:03:07
667
原创 物联网监控场景时序数据库选型：从 InfluxDB 迁移到 TDengine 的实战复盘
选型没有银弹。我们踩过的坑——时区、内存参数、子表数量——都是文档里写得清楚但容易被忽略的细节。建议任何团队在迁移前，先用真实数据量做 PoC，重点测写入吞吐、聚合 P99 和压缩比，再决定是否切换。
2026-09-16 08:51:55
500
原创 弹性伸缩与 HPA 自定义指标：电商大促下的容量治理实践
我们评估了三条技术路线，各有取舍。在集群中部署 Prometheus 采集业务指标，通过 prometheus-adapter 将其暴露为接口，HPA 直接消费。优点：生态成熟，Prometheus 已是可观测性标配，指标定义灵活。缺点：需要维护 adapter 的指标映射规则（rules配置），且 Prometheus 拉取周期（默认 30s）与 HPA 同步周期（默认 15s）叠加，端到端响应延迟约 45–60s，对突发流量仍偏慢。通过接口暴露业务指标，HPA 原生支持，不引入额外控制器。优点。
2026-09-15 11:19:31
496
原创 HNSW 调优实战：图像检索召回率从 78% 提到 96% 的踩坑复盘
什么场景该用业务有强类目差异，不同类目的图片相似度分布差异大（电商、图库、社交内容）；数据量足够大（千万级以上），单一大索引的内存和延迟不可控；对召回率敏感，且能接受粗召回 + 精排的两层架构。什么场景不要照搬数据量小（百万级以下），单一大索引 + 默认参数已经够用，分桶反而增加复杂度；对延迟极敏感（如实时交互检索），粗召回 + 精排的两层架构会多一次重排开销；向量区分度本身很高（如指纹、人脸），HNSW 默认参数召回率已经 95%+，调参收益有限。边界与遗留问题。
2026-09-15 11:11:43
590
原创 Function Calling 落地办公自动化：从 12% 解析失败到 99.2% 准确率的选型复盘
适用场景输入是非结构化自然语言，且表达方式高度多样（如报销备注、客服工单、会议纪要）。需要把文本映射到固定结构的业务字段，且字段数量有限（5~20 个）。对延迟不敏感（P95 可接受 2~3s），且已有 GPU 资源或可接受 API 成本。不适用场景输入本身已是结构化数据（如 JSON、CSV），用 Function Calling 是杀鸡用牛刀。需要毫秒级响应的场景（如实时风控），2s 延迟不可接受。字段数量超过 50 个且高度嵌套，模型容易漏参或幻觉，不如用传统信息抽取 + 规则兜底。
2026-09-14 09:18:07
490
原创 零售订单地址解析从 12% 失败率到 0.3%：数据湖仓一体在金融风控场景的落地复盘
适用场景：需要同时处理实时和批量数据、且对数据一致性要求高的场景。比如我们的地址解析，既有实时风控需求，又有离线分析需求，Lakehouse 的流批一体能力正好匹配。金融风控、实时推荐、IoT 数据处理都是典型场景。哪些业务不要照搬纯离线分析业务：没有实时性要求，传统数仓或数据湖就够用，引入 Lakehouse 只会增加运维复杂度和资源成本。数据量小的业务：日均数据量在百万级以下，实时计算和物化视图的常驻资源开销可能超过收益。团队无流式计算经验。
2026-09-14 08:23:19
391
原创 Embeddings 维度与精度权衡：内容平台向量召回从 768 降到 256 的实战复盘
适用场景内容平台、电商、社交等海量向量 + 高 QPS的场景，存储和延迟是硬约束。使用开源 Embedding 模型（bge、m3e、text-embedding 系列）且未做任何降维/量化的存量系统。相似度度量是余弦或内积，且对绝对分数不敏感、只关心排序的场景。不适用场景小规模向量库（<100 万条）：降维和量化的收益不明显，反而增加链路复杂度。对精度极度敏感且无法接受任何损失的场景（如医疗、金融风控的精确匹配）：int8 量化可能引入不可控误差，建议保留 float32。
2026-09-11 08:33:30
301
原创 向量库与图数据库融合：风控反欺诈的实时关联挖掘实践
团伙欺诈、设备农场、养号攻击这类"单点正常、整体异常"的风险。特征是实体之间有显式或隐式的关联，且欺诈团伙存活周期短、需要分钟级响应。金融、电商、社交平台的实时风控都适合。纯个体欺诈（比如单个人伪造收入证明）、低频高价值交易（一天就几笔，向量召回没有统计意义）、以及数据量极小（少于 10 万节点）的场景。这些情况用规则引擎或传统图数据库离线分析就够，引入向量 + 图融合是过度设计。向量召回依赖 embedding 质量，特征工程一旦变更必须做版本管理；图扩展的跳数不能太大（超过 3 跳会引入大量噪声）；
2026-09-11 08:29:31
368
原创 云上订单数据加密与 KMS 密钥管理：一次支付链路加密改造复盘
适用场景合规要求明确（等保、PIPL、GDPR）且需要密钥托管与审计的行业，如金融、电商、医疗。敏感字段量级大、需要定期密钥轮换的长期系统。已有云厂商 KMS 服务，且团队能接受 5-10ms 的 DEK 生成延迟。不适用场景纯内部系统、无合规要求、数据量极小（如千级以内），自研 AES 即可，KMS 引入的复杂度不划算。对延迟极度敏感（如 P95 < 10ms）且无法接受任何额外网络调用的高频交易系统，需评估信封加密的缓存策略是否足够。
2026-09-09 12:08:25
423
原创 大模型越狱防护：政企私有化部署的输入安全网关实践
越狱攻击的本质是"输入侧指令混淆"。模型无法可靠地区分"用户的正常提问"和"用户伪造的系统指令"。因此必须在模型之前加一道。
2026-09-09 11:53:08
253
原创 大模型推理成本优化：SaaS 客服场景下的量化与蒸馏实战
垂直领域判别式任务：短文本分类、意图识别、实体抽取、情感分析。这类任务用 7B 蒸馏模型完全够用。高吞吐、低延迟要求：客服、搜索排序、内容审核等实时性强的场景。成本敏感型 SaaS：毛利薄、对单次推理成本极度敏感的业务。
2026-09-09 10:17:29
569
原创 vLLM 推理优化实战：高并发推荐场景下把 P99 延迟从 480ms 压到 96ms
追求单请求极致延迟（如实时语音交互，要求首 token < 50ms）：TensorRT-LLM 的静态图优化更合适，单请求延迟比 vLLM 低约 15%；超长上下文（如 100K+ token 文档分析）：vLLM 的 PagedAttention 虽然省显存，但长序列下 prefill 仍是瓶颈，建议配合前缀缓存（）使用；小模型、低并发（如 1B 模型、QPS < 100）：框架开销占比高，直接用 Transformers 反而更简单。
2026-09-08 10:36:11
520
项目管理信息化建设方案-多套docx模板，覆盖18个行业（保险、党政、交通、教育、民政、能源、农业、生态环境、通信、卫生、文旅、银行、应急、证券、政法、制造、住建等）
2026-09-29
Go语言高并发服务与云原生技术实战：基于Gin/gRPC/Kubernetes的全栈项目开发指南
2026-09-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人