Colocation et FPGA
≈banaliséLouez un rack à côté du moteur d'appariement et mettez votre logique dans le silicium. Le budget de latence (chaque nanoseconde du fil à l'ordre) décide si vous gagnez la course. En 2026, une course aux armements capitalistique gagnée par quelques-uns.
Voir en mouvement
À remarquer. Sur une voie particulier, le fil seul fait des centaines de microsecondes, donc vous avez perdu la course avant même que votre logique tourne. La colocation effondre le terme réseau ; un FPGA effondre le terme calcul. Chacun est une décision de capital, et ensemble ils définissent qui peut jouer au jeu de la vitesse.
Qu'est-ce que la colocation, et qu'achète vraiment un cross-connect ?
La colocation, c'est louer un espace de rack pour votre serveur à l'intérieur du datacentre de la place elle-même, à côté du moteur d'appariement. Un cross-connect est le câble physique qui relie votre rack au réseau de la place. Ensemble, ils suppriment le délai de propagation lié à la distance (les millisecondes que la lumière met à parcourir un site distant) et ne vous laissent que les microsecondes intra-bâtiment. C'est le gain de latence unique le plus important et le plus simple.
L'intuition, c'est la vitesse de la lumière elle-même. Dans la fibre, la lumière couvre environ un kilomètre toutes les 5 µs, donc un serveur à 100 km de la place porte environ 0,5 ms (500 µs) de délai aller-retour que vous ne pouvez tout simplement pas battre : la lumière est la lumière, et aucune astuce logicielle ne rivalise avec la suppression de la distance. Entrez dans le bâtiment et ces ~0,5 ms s'effondrent vers zéro. Vous le ressentez dans le constructeur de budget ci-dessus : faites glisser le curseur « distance à la place » du cloud (centaines de km) à la colo (≈0) et regardez le segment de propagation dominer la barre, puis disparaître.
Les places vendent la colocation comme un produit réglementé à accès égal, et vont souvent plus loin en égalisant les longueurs de câble pour que le cross-connect de chaque client colo soit à la même distance physique du moteur d'appariement, ce qui veut dire qu'être un rack plus proche ne confère aucun avantage. L'égalité des conditions est le produit ; vous payez pour en faire partie. Ce que cela coûte, c'est un loyer récurrent rack/électricité/cross-connect plus les frais de connectivité aux flux et à la saisie d'ordres : un coût fixe substantiel, du genre qui dicte l'économie à marges minces de cette activité. La formulation honnête : la colocation est un ticket d'entrée pour toute stratégie sensible à la latence et un pur achat, sans savoir-faire dedans, seulement de la dépense. C'est l'exemple le plus clair de l'infrastructure comme prix d'entrée, et non comme avantage.
Pourquoi le micro-ondes et le mmWave entre datacentres : la géographie à la vitesse de la lumière
Entre deux datacentres distants (disons les places actions près de New York et les places futures près de Chicago), la lumière voyage environ 50 % plus vite dans l'air que dans la fibre de verre, et une liaison micro-ondes file sur un chemin de grand cercle plus droit et plus court. C'est pourquoi les firmes bâtissent des réseaux micro-ondes et mmWave pour grappiller des millisecondes sur les routes inter-places : la géographie de la planète devient un actif de latence.
La physique offre deux gains à la fois. La fibre est du verre, et la lumière dans le verre se déplace à environ 200 000 km/s, contre environ 300 000 km/s dans l'air ; pire, la fibre suit les routes et les emprises plutôt que des lignes droites. Une chaîne de relais micro-ondes va presque tout droit, dans l'air, donc elle bat la fibre à la fois sur le milieu et sur le chemin. Sur la route Chicago–New Jersey, c'est une différence de centaines de microsecondes : décisif pour la vitesse inter-places.
Les arbitrages sont réels : le micro-ondes porte bien moins de bande passante que la fibre et se dégrade sous forte pluie et brouillard, donc il est réservé aux déclencheurs critiques en latence (un petit signal urgent) tandis que les données en masse passent encore par la fibre ; le mmWave (onde millimétrique) et les liaisons laser/optique en espace libre poussent cela plus loin sur des sauts plus courts. C'est une vraie course aux armements, en grande partie fermée aux nouveaux entrants : les meilleures routes sont détenues, les droits de tour sont rares et coûteux, et les firmes (et les fournisseurs réseau spécialisés) qui les détiennent les défendent. On n'entre pas dans le jeu du micro-ondes par hasard ; vous louez de la capacité sur le réseau de quelqu'un d'autre, si tant est que vous puissiez en obtenir. Conceptuellement, c'est l'illustration la plus pure que la vitesse du HFT est bornée par la physique, et que la frontière restante consiste à acheter une géographie rare, pas à écrire un meilleur code ; c'est ce qui alimente l'arbitrage de latence inter-places.
Qu'est-ce qu'un FPGA, et quand vaut-il mieux que le logiciel ?
Un FPGA (field-programmable gate array) est une puce que vous câblez en logique matérielle sur mesure. Mettre la logique du chemin chaud (décodage, carnet, déclencheur) dans un FPGA la fait tourner en silicium parallèle, faisant passer le tick-to-trade des microsecondes du logiciel aux dizaines à centaines de nanosecondes, « wire-to-wire ». Cela ne vaut le coup que lorsque la stratégie a vraiment besoin de ce palier, car le coût de développement est brutal.
L'intuition : le logiciel exécute des instructions l'une après l'autre sur un CPU généraliste ; un FPGA est le circuit, faisant le travail dans des portes parallèles dédiées sans surcoût de chargement d'instruction. Pour une tâche fixe, simple et critique en latence (reconnaître un motif dans le flux et déclencher), c'est énormément plus rapide et bien plus déterministe (jitter très bas) que n'importe quel CPU. Le bouton « logiciel vs FPGA » dans le budget ci-dessus le rend visible : le segment de logique de stratégie s'effondre des dizaines de µs au chiffre unique et en dessous, tandis que le compteur de coût bondit, rendant tangibles les rendements décroissants.
Le cycle de vie du trade explique pourquoi c'est pénible. Le développement FPGA se fait dans un langage de description matérielle (Verilog/VHDL, ou synthèse de haut niveau), avec des cycles de compilation et de synthèse lents, un débogage difficile, et des spécialistes rares et coûteux. Le flux de travail est donc : prototyper et valider la stratégie en logiciel et la backtester, prouver qu'elle a besoin de la vitesse, puis porter seulement la boucle interne la plus serrée et la plus stable sur le FPGA. On n'itère pas la recherche sur un FPGA ; on lui confie une chose finie et simple. La norme hybride en découle : la plupart des systèmes « FPGA » sont des hybrides, où le FPGA gère le chemin rapide wire-to-wire (parser, contrôler le risque, déclencher un ordre pré-armé) tandis qu'un CPU gère l'état de stratégie plus riche et plus lent. Le FPGA fait le réflexe ; le logiciel fait la réflexion.
Statut 2026 : les cartes réseau FPGA et les frameworks tick-to-trade sont désormais des produits (cartes de lignée Solarflare/Xilinx, IP de fournisseurs) si bien que la capacité est achetable, mais l'intégration, les relations avec les places et l'équipe de spécialistes ne sont pas bon marché, et la frontière absolue reste aux firmes qui le font en interne. C'est le plafond du palier de vitesse, et il est en grande partie fermé à un constructeur indépendant.
Qu'est-ce qu'un budget de latence tick-to-trade, et comment en construire un ?
Un budget de latence est la décomposition additive du tick-to-trade (le temps total du paquet de données de marché entrant à l'ordre sortant) en ses étapes : propagation, NIC/noyau, décodage, logique de stratégie, risque, passerelle. Vous le construisez en listant la contribution de chaque étape en nanosecondes, puis en attaquant le segment le plus grand en premier. Il vous dit où passe le temps et ce que chaque achat de vitesse rapporte vraiment.
L'intuition, c'est que la latence est une somme, pas une chose unique. Si la propagation est de 500 µs et votre logiciel de 5 µs, optimiser le logiciel est inutile tant que vous ne vous colocalisez pas ; le budget le rend évident en plaçant les segments côte à côte, donc vous optimisez le plus grand. Les étapes canoniques sont chacune attaquables indépendamment : propagation (distance → supprimer avec la colocation) ; NIC + noyau (→ contournement du noyau) ; décodage (→ protocole binaire) ; logique de stratégie (→ chemin chaud logiciel ou FPGA) ; risque pré-négociation (en ligne) ; et la passerelle d'ordres (saisie d'ordres binaire).
La méthode est une boucle : mesurer (voir mesurer la latence), trouver le plus grand segment, décider si l'avantage de la stratégie justifie le coût de le réduire, répéter. Le budget est aussi un outil de justification de coût : il transforme « doit-on acheter un FPGA ? » en « combien vaut l'économie d'une nanoseconde pour cette stratégie ? », et c'est la discipline qui empêche un nouvel entrant de brûler du capital à courir après une vitesse dont une stratégie n'a pas besoin. C'est exactement ce que le constructeur de budget ci-dessus rend tangible : la barre empilée, la ligne cible, le compteur de coût, et les trois préréglages (« Particulier/cloud », « Colo + contournement du noyau », « FPGA tick-to-trade »).
Alors, un nouvel entrant peut-il vraiment lutter sur la vitesse en 2026 ?
Sur la frontière absolue (nanoseconde wire-to-wire, routes micro-ondes, FPGA en interne), non. Ce palier exige du capital, des spécialistes matériels, une géographie rare et des relations avec les places, et il est défendu par quelques firmes qui s'affrontent. Ce qu'un nouvel entrant peut faire, c'est atteindre par l'achat une infrastructure microseconde de niveau parité et lutter sur autre chose que la vitesse brute.
La hiérarchie honnête, en 2026, comprend trois paliers. La frontière nanoseconde (pur arbitrage de latence contre les joueurs les plus rapides) est de fait fermée ; ne bâtissez pas une activité sur l'idée de battre les acteurs en place en vitesse. Le logiciel/FPGA colocalisé en microsecondes (tenue de marché plus rapide, stratégies sensibles à la file sur les places transparentes) est disputable si vous pouvez vous offrir la colocation et avez l'ingénierie, mais vous achetez la parité, pas un avantage : l'avantage doit venir de la stratégie. La milliseconde et plus lent (stat arb, tenue de marché plus lente, inter-places, et surtout crypto et marchés de prédiction) est vraiment ouvert à un constructeur indépendant compétent, car là la vitesse n'est pas la contrainte qui mord ; ce qui compte, c'est la qualité de la recherche, les données et l'exécution.
La conclusion stratégique à laquelle ce guide ne cesse de revenir : choisissez un jeu où la vitesse n'est pas l'avantage. L'ouverture de 2026 est la bande microseconde-et-plus-lent, où les mêmes maths de microstructure tiennent mais où la course aux armements d'infrastructure ne vous barre pas la route. La vitesse est un coût à contrôler, pas un fossé à gagner. Voir le HFT est-il encore rentable en 2026.
Exemple travaillé
Prenons l'exemple de vitesse classique, le cas inter-places futures de Chicago ↔ actions du New Jersey, comme un budget de latence au dos d'une enveloppe, daté de 2026 et reproductible dans le constructeur ci-dessus (à titre d'illustration ; les latences de route réelles et les frais de colo sont commerciaux et changent).
La distance est d'environ 1 200 km en grand cercle. Sur fibre (lumière dans le verre environ 5 µs/km, suivant une route non droite plus proche de 1 300 km), cela fait environ 6,5 ms dans un sens ; sur micro-ondes (lumière dans l'air environ 3,33 µs/km, un quasi-droit de 1 200 km), environ 4 ms dans un sens. L'avantage du micro-ondes est de l'ordre de 2+ ms par tronçon : colossal en termes HFT, et la raison entière pour laquelle les réseaux micro-ondes ont été construits.
À l'intérieur du datacentre, en colocation, la propagation tombe à environ zéro et le budget est dominé par votre propre pile : un chemin logiciel à contournement du noyau fait environ 2–7 µs de tick-to-trade (issu de la pile à faible latence), un chemin FPGA wire-to-wire environ des dizaines à des centaines de nanosecondes. La décision que les chiffres imposent est tranchée. Si votre stratégie dépend de réagir au mouvement de Chicago avant que d'autres n'agissent dessus dans le New Jersey, il vous faut la route micro-ondes (rare, détenue) et un FPGA pour agir à l'arrivée, tous deux de palier frontière, tous deux en grande partie fermés. Si votre stratégie marche avec une réaction à la milliseconde dans une seule place, vous n'avez besoin de rien de tout cela : colocation optionnelle, FPGA inutile. Le budget vous dit dans quel monde vous êtes avant de dépenser un centime. Les chiffres sont schématiques et datés de 2026 ; vérifiez-les contre les chiffres actuels des fournisseurs et la spécification de colocation de la place. Pédagogique seulement, pas un conseil en investissement.