陷阱1：词元服务器CPU过载，但监控只看GPU
本周多家RAG服务商反馈，知识库检索慢的根因不是GPU算力，而是词元（Token）服务器的CPU队列堆积。IDC机房的物理机往往混部了embedding模型与检索排序服务，当并发查询超过300 QPS时，CPU上下文切换成本陡增。建议本周执行：在Prometheus中新增node_cpu_seconds_total{mode="system"}告警，阈值设为15%。同时为embedding服务单独配置cgroup，限制其CPU核数不超过物理机一半，防止抢用排序线程。
陷阱2：带宽按峰值买，但忘了“突发窗口”
本周某金融客户知识库在下午3点出现批量文档导入，瞬时带宽占满10Gbps端口，导致在线问答延迟飙升到8秒。IDC运营商通常提供95/5计费，但RAG的文档解析与向量化任务对带宽是“脉冲式”需求。本周改造动作：在对象存储网关前加一层限速（如tc netem），将批量写入速率限制在带宽的60%。同时，将大文件切分为4MB分片，用消息队列削峰，避免同步压垮网络。
陷阱3：跨机柜网络延迟被忽视，导致RAG召回不一致
近期有运维社群爆料，某企业将知识库的向量索引放在A机柜，而词元服务器在B机柜，跨机柜的TOR交换延迟高达2ms，这导致每次检索都要额外等待网络往返。最佳实践：利用IDC的Spine-Leaf架构，将同一RAG链路的计算节点（词元服务器、向量库、排序服务）强制部署在同一Pod（或至少同一Leaf交换机下）。如果无法迁移，则启用RDMA over Converged Ethernet（RoCE）或降低TCP Nagle算法延迟。本周可先用ping -f -l 1400测试大包延迟，超过1ms就必须调整网络拓扑。
陷阱4：软件层重试机制放大网络抖动
本周某RAG产品在IDC网络瞬断（20ms）时，客户端SDK自动重试3次，结果把故障窗口放大了10倍。我们对比了主流向量数据库驱动，发现默认重试策略都是指数退避，但基值过小。本周配置建议：将SDK重试基值从100ms改为500ms，最大重试次数限制为2次。同时，在IDC出口路由上开启BFD（双向转发检测）并设定50ms检测间隔，让网络故障能被快速感知，而非靠应用层超时。
额外清单：本周必须做的3项健康检查
① 检查所有词元服务器的TCP重传率，若>0.5%，立即排查网卡驱动与MTU（建议9000）。② 对RAG的批量导入任务设置QoS，使用TC分类或VLAN优先级，确保在线查询流量始终处于EF队列。③ 在IDC控制台开启“带宽预警”，当连续5分钟利用率>80%时，自动触发告警并降级非核心的文档向量化任务。
最后提醒：本周有消息称，部分IDC开始对“按Token计费”的RAG租户征收额外网络流量费。建议核查账单中的“跨可用区流量”项目，如果超过总流量5%，就要考虑把知识库副本下沉到业务所在地机房。
0 留言