Tabby 是不少团队在找“代码不出内网”的编程助手时先看的一个名字。它是一个自托管的 AI 编程助手，主打代码补全，也提供问答和聊天能力，常被看作 GitHub Copilot 的可本地部署替代方案。吸引力很直接：服务装在自己的服务器上，代码在内网完成推理，离线也能用，也没有遥测上传。对合规严格的团队来说，这个前提比补全多聪明几分更重要。
官方仓库信息
平台是 GitHub，组织是 TabbyML，项目名是 tabby，已积累超过 3.3 万颗星。项目提供 VS Code、JetBrains 系列等主流编辑器插件，并能索引接入的仓库，让补全参考项目上下文，而不是只按单文件猜测。
为什么有人选它
云端工具上手快，但代码要发到外部服务，金融、政务等场景常过不了内部审查。Tabby 把这道线划在内网里：官方提供 Docker 一条命令拉起的自包含服务，不依赖外部数据库或云后端，一台带显卡的机器就能跑起来，支持消费级显卡，可完全离线运行。同一套服务给多人共用，也更容易统一收口管理。
部署与运维这两笔账
第一笔是显卡账。后端代码模型要自己选，常见选择有 StarCoder、CodeLlama、DeepSeek-Coder、Qwen 系列代码模型等，补全质量的上限由所选模型决定。模型越大通常越好，也越吃显存；团队共用还要按并发留余量，常开机器的电费和散热都是长期成本。第二笔是运维账。Docker 拉起只是开始，仓库索引、模型切换、版本升级、显存排查都要自己维护。团队级的用户管理和更细的分析等能力属于企业版范围，部署前要分清开源自托管部分能做到什么，避免上线后才发现缺口。
真实坑点和使用边界
最明显的差距在补全质量。和云端前沿编程工具相比，本地小模型补短代码、补常规片段还行，遇到复杂跨文件推理就容易吃力，建议更需要人工复核。期待替换最强的云端体验，落差会很明显。它也不适合图省事：索引、模型、插件兼容都要持续跟进，没有云服务那种打开就用的省心。只有当“代码不能出内网”真实成立，团队也愿意承担机器和运维成本时，它的价值才会放大；为合规以外的原因自托管，账往往算不过来。
适合谁，不适合谁
适合有合规或内网要求的小团队、离线环境，以及想把补全服务统一收口的团队，这类团队宁愿接受补全弱一点，也要把代码留在内部。不适合追求最强补全质量的个人开发者，个人尝鲜直接用云端工具通常更划算；也不适合没有显卡服务器、或没人愿意承担运维的团队。决定前先用真实仓库试跑一周，看补全命中、响应速度和显存占用能否接受，再考虑常态化部署。
