无双的技术博客 记录 AI、Linux、网络架构、FreeSWITCH 与企业数字化实践

归档

2026 年 07 月

The Core Logic of High-Quality Fine-Tuning Data Engineering: Why Data Quality Defines a Model's Ceiling Chinese version: 中文版 This is the first article
从微调是否必要、SFT/RL/GRPO 的学习方式,到高质量样本为什么比单纯堆数据量更关键.
70B模型配了4张80G卡,长文本一推就爆。查了一圈发现不是显存容量问题,是max_length设太大,kv cache按最坏情况预分配显存。上线前没做profiling,差点多花20万买卡。
设了gradient_accumulation_steps=8,理论有效batch=32,结果每个step的loss降得像火箭一样快,还以为学习率太高。排查了两天才发现DeepSpeed的配置覆盖问题,实际有效batch只有1。
吐槽向复盘:对接新运营商SIP中继时,认证机制、头域格式、号码转换轮流坑了我一遍。记录一下当时的排查思路和最终方案,给后来人避坑。
FreeSWITCH部署在华为防火墙后,公网对端能收到INVITE但ACK总丢,BYE之后通话还不释放。抓包一看,NAT已经改了Contact头,但Via和Record-Route里的IP却和实际出口对不上——防火墙的SIP ALG在改写时序和改写范围上各有一套自己逻辑,禁用它又怕影响对端NAT穿越。最后靠抓包定位ALG的改写盲区,手动在SIP配置里对齐NAT行为,解决问题。
FreeSWITCH对接传统PBX时,一方在NAT后出现单向通话或无声音。排查过程从STUN绑定响应入手,发现对端是对称型NAT导致的非对称路径拒绝。这篇文章复盘完整的排查链:SDP解析→ICE候选交换→STUN Binding→对称型NAT判定→TURN中继回退,重点剖析为什么最终选了TURN而不是其他方案。
容器网络场景下iptables NAT表加载失败的根因不在iptables本身,而在于内核模块依赖链未打通。本文从问题发现到根因定位完整还原排查路径,对比三种方案的生产环境适用条件,并给出具体实施步骤与边界case处理。
不是GRE比IPSec更好,而是这个组合在大多数企业站点间互联场景下功能覆盖最完整。组播支持、动态路由、NAT穿越能力、性能开销——这几个维度一拉平,答案就很清楚了。
在IPSec VPN隧道场景下,tcpdump只能看到ESP包,无法定位应用层延迟异常是加密开销还是网络丢包。本文从内核架构层面分析两者的能力边界,给出基于场景的决策框架,并附上性能开销实测数据与验证结论。