INSIGHT如果社区搜索同时接入图片、视频或 OCR，统一实例会让视觉编码和文本解码互相争抢资源。可借鉴 EPD 解耦，按阶段独立扩缩容，并把图片编码耗时、文本 TTFT 和召回链路整体延迟作为联合 SLO，而不是只监控生成吞吐。

INSIGHTUGC 搜索的 query 很短但 RAG 上下文可能很长，FCFS 容易让长上下文请求阻塞短请求。工程上可将 TTFT 与 TBT 分开建模，使用队列实时信号调节 Decode 优先级，再把 prompt 长度和候选文档数作为 Prefill 的调度特征。

INSIGHT当社区搜索的长上下文请求共享前缀、但候选证据分散在不同缓存段时，仅优化命中率可能反而增加重算成本。可把缓存位置、attention kernel 代价和请求优先级联合评估，并用长尾 query 分桶检查缓存策略是否伤害 P99 延迟。

INSIGHT社区搜索的请求成本会随上下文和生成长度剧烈变化，按连接数或平均 QPS 做负载均衡不够。可以先接入 GPU 利用率、KV Cache 使用率、队列长度和 TTFT 四类指标，再按租户或 query 长度做加权路由，避免热门长 query 挤压短 query。

INSIGHT对长上下文问答或搜索 Agent，整请求重算会同时放大 GPU 成本和用户等待。可先在非关键流量上引入异步 shadow checkpoint，并按 KV Cache 大小、恢复时间和可接受重算窗口做分层；不要一开始就对所有短请求启用纠删码。

INSIGHT若社区端需要本地 embedding、轻量 reranker 或隐私过滤，云边协同比把全部请求送入云端更稳妥。可将短 query 的前处理留在边缘，把高成本生成/重排放到云侧，再用 speculative decoding 和链路带宽共同调参，避免只优化 GPU 而忽视网络尾延迟。

INSIGHT社区搜索通常更看重成本、弹性和生态兼容，专用 SRAM 路线未必适合直接替换通用 GPU。借鉴点是按上下文长度和 Prefill/Decode 比例做硬件画像；在采购前应同时测 embedding、reranker、生成模型三类负载，避免单一 token/s 指标误导。

INSIGHT对 UGC 搜索，模型服务的稳定性、数据合规和可回滚性与模型效果同等重要。建议把服务商评估拆成延迟/成本、灰度与回滚、日志脱敏、模型替换、离线评测五个门槛，并用真实搜索流量验证而不是只看 Demo。